Ошибка при экспорте ORA-01578 : Oracle

VitorJ · █ 23.11.2015 15:58

Добрый день!
Физический упал сервер на магазине из бэкапов только "холодный"
Восстановили на другом сервере, попробовали сделать экспорт
Получили следующее

Код:

EXP-00056: ORACLE error 1578 encountered
ORA-01578: ORACLE data block corrupted (file # 17, block # 59170)
ORA-01110: data file 17: 'D:\ORACLE\PRODUCT\10.2.0.4\ORADATA\MARKETG\USERS01.DBF'

но при выполнить запрос типа

Код:

SELECT e.segfile#, e.segblock#, e.file#, e.block#, do.data_object_id, ds.* FROM dba_segments ds, sys.uet$ e, dba_objects do WHERE ds.header_file = e.segfile# and ds.header_block = e.segblock# and e.file#=17 and 59170 between e.block# and e.block#+e.length-1 and ds.owner=do.owner and ds.segment_name=do.object_name;

получаем
no rows selected

Подскажите в чем может быть проблема?
возможно ли, что винт попался битый?

OlegON · █ 23.11.2015 16:04

Проблема в том, что посреди файла данных дырка. Я уже не раз тыкал в то, что пользоваться холодным бекапом постоянно и в автомате НЕЛЬЗЯ. Причин появления дырки может быть чуть меньше миллиона. И оптимизатор на ентерпрайзе их лечит в автомате, но только те, которые появляются после его первого бекапа, на стандарте верещит сразу, как они появляются, т.е. можно их убрать вручную.

Битый винт, как правило, сопровождается еще кучей ошибок рядом на тему OS error и руганью в журнале Windows. А это ... хз теперь, что послужило причиной.

VitorJ · █ 23.11.2015 16:09

Это понятно, что холодный бэкап это зло, других просто нет физический, тот винт на который RMAN делал бекапы сдох, со слов админа и восстановлению не подлежит, хотя я его забрал, думаю попробовать перекинуть электронику.
Вопрос возможно ли исправить эту беду, оптимайзера на этой БД не было.

VitorJ · █ 23.11.2015 16:11

С запросом я намудрил конечно
вот запрос

SQL код:

 select ds.owner, ds.segment_name, ds.partition_name, ds.segment_type, ds.tablespace_name, e.ktfbueextno, f.file#, e.ktfbuebno, e.ktfbueblks * ds.blocksize, e.ktfbueblks, e.ktfbuefno from sys.sys_dba_segs ds, sys.x$ktfbue e, sys.file$ f where e.ktfbuesegfno = ds.relative_fno and e.ktfbuesegbno = ds.header_block and e.ktfbuesegtsn = ds.tablespace_id and e.ktfbuesegtsn = f.ts# and e.ktfbuefno = f.relfile# and f.file#=17 and 59170 between e.ktfbuebno and e.ktfbuebno + e.ktfbueblks - 1;

вот ответ

SQL код:

 OWNER
------------------------------
SEGMENT_NAME
--------------------------------------------------------------------------------
PARTITION_NAME                 SEGMENT_TYPE       TABLESPACE_NAME
------------------------------ ------------------ ------------------------------
KTFBUEEXTNO      FILE#  KTFBUEBNO E.KTFBUEBLKS*DS.BLOCKSIZE KTFBUEBLKS
----------- ---------- ---------- ------------------------- ----------
 KTFBUEFNO
----------
SUPERMAG
SMOBJECTCHANGE
                               TABLE              USERS

OWNER
------------------------------
SEGMENT_NAME
--------------------------------------------------------------------------------
PARTITION_NAME                 SEGMENT_TYPE       TABLESPACE_NAME
------------------------------ ------------------ ------------------------------
KTFBUEEXTNO      FILE#  KTFBUEBNO E.KTFBUEBLKS*DS.BLOCKSIZE KTFBUEBLKS
----------- ---------- ---------- ------------------------- ----------
 KTFBUEFNO
----------
          1         17      59145                   1048576        128
        17

OlegON · █ 23.11.2015 16:24

Если бы оптимайзер был, ты бы вовремя узнал, о том, что там что-то сдохло. Ну, или админ, не суть. Вместо холодного бекапа должен был быть правильный.
Вот это вот неформатированное непонятного происхождения разглядывать влом, ты посмотри, я тут выкладывал, как сбойные сегменты смотреть, он может быть не один. Потом, имея на руках список сегментов, решай, что с ними делать. Я, кстати, выкладывал, как в некоторых случаях можно либо проигнорировать сбойную запись, либо достать данные таблицы из индекса, искать, извини, некогда.

VitorJ · █ 25.11.2015 14:13

Спасибо! Нашел описание на форуме, проблему решил!
Тему можно закрыть!