Одно время серьезно набил руку вот на какой задаче - по ряду таблиц в результате компрессии и ораклового бага побились несколько строк. В результате чего пользователи при фулскане по таким таблиц получали ORA-01410.
Рассмотрим самый тяжелый случай - когда нет ни бэкапов, ни индексов (в этом случае проиндексированные колонки можно получить при сканировании по индексу). В данном случае единственный вариант - найти проблемный ROWID и "обогнуть" его с двух сторон, вычленив неповрежденные данные.
Для начала снимем трейс по проблемному запросу, для того чтобы получить исходные данные:
alter session set db_file_multiblock_read_count=1;
alter session set events 'immediate trace name trace_buffer_on level 1048576';
alter session set events '10200 trace name context forever, level 1';
alter session set events '1410 trace name errorstack forever, level 10';
alter session set tracefile_identifier='ORA1410';
и запускаем проблемный запрос
select count(1) from test.testtable;
Находим в трейсе запись вроде этой:
ktrget2(): started for block <0x0645 : 0x3ce2c85b> objd: 0x00f842bb
env: (scn: 0x0a21.9a61c1d8 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00 statement num=0 parent xid: xid: 0x0000.000.00000000 scn: 0x0000.00000000 96sch: scn: 0x0000.00000000 mascn: (scn: 0x0a1f.ccec0b27)
OBJD MISMATCH typ=6, seg.obj=16270011, diskobj=16268354, dsflg=100001, dsobj=16270011, tid=16270011, cls=1
По полученному значению получаем Block_number и Relative_fno:
select dbms_utility.data_block_address_file(to_number('3ce2c85b', 'xxxxxxxx')) file#,
dbms_utility.data_block_address_block(to_number('3ce2c85b', 'xxxxxxxx')) block# from dual;
FILE# BLOCK#
243 2279515
Дополнительно находим data_object_id проблемного объекта:
select data_object_id from dba_objects where owner = 'test' and object_name = 'testtable';
data_object_id
----------------------
16402245
По полученным значениям формируем ROWID:
select dbms_rowid.rowid_create(rowid_type => 1,object_number => 16402245,relative_fno => 243,block_number => 2279515,row_number => 0) from dual;
ROWID=AA+kdFADzAAIshbAAA
Ну и, собственно, то, о чем я упоминал вначале - огибаем проблемную строку со всех сторон:
insert into test.testtable_nocorrupt
select /*parallel(8)*/ * from test.testtable
where rowid<'AA+EK7ADzAAIshbAAA';
insert into test.testtable_nocorrupt
select /*parallel(8)*/ * from test.testtable
where rowid>='AA+EK7ADzAAIshcAAA';
Хотелось бы отметить, что подобных проблем, скорее всего, удалось бы избежать, имея выставленные параметры БД db_block_checking/db_block_checksum = 'Full' или db_ultra_safe = 'data_and_index', что несколько нагрузило бы процессор (~5%, хотя это обсуждаемо), но дало бы дополнительную надежность.