Как избавиться от ORA-01410, вычленив неповрежденные данные

Одно время серьезно набил руку вот на какой задаче - по ряду таблиц в результате компрессии и ораклового бага побились несколько строк. В результате чего пользователи при фулскане по таким таблиц получали 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%, хотя это обсуждаемо), но дало бы дополнительную надежность.