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

Источник: habrahabr

Brass_nn

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

CA Unicenter как основа оптимизации работы ИТ-инфраструктуры предприятия.

Сравнение версий Crystal Enterprise.

Компьютер и сердце.

Cisco выпускает новый экзамен CCDA.

Web-сайт компании как инструмент подбора персонала.

Главная » Новости