Пример практического проявления Bug 8895202 – ORA-1555 / ORA-600 [ktbdchk1: bad dscn] in Physical Standby after switch-over [ID 8895202.8] и действий, которые могут помочь в разрешении возникающих проблем.
Проблема (неоднократно наблюдалась после switch-over Physical Standby database to the Primary database role): в блоках индексов itl (Interested Transaction List) commit SCN оказывается больше чем block SCN
Практические симптомы:
- в 11.1.0.7 – ORA-00600 [ktbdchk1: bad dscn] при попытке изменения повреждённых индексных блоков (при операциях INSERT/UPDATE)
- в 11.2.0.2 – к предыдущей ошибке добавляется ORA-1555 при выполнении запросов, в плане которых используется индекс с «битыми» блоками
Сообщение об ошибке в alert.log в последнем случае выглядит весьма примечательно (Query Duration=0 sec или несколько секунд):
ORA-01555 caused by SQL statement below (SQL ID: 06mwy7ua78adg, Query Duration=0 sec, SCN: 0x0786.62a03def)
Баг зафиксирован и описан для версий 11.1.0.7 и далее, полное избавление намечено сделать в версии 12.1 :)
В описании можно найти порядок “лечения”, остаётся найти и обезвредить (например, с помощью ALTER INDEX REBUILD [ONLINE PARALLEL N]) индексы, затронутые проблемой
Итак, найти индексы с проблемными блоками можно по ошибкам (т.е. постфактум, по “симптомам болезни”):
1) в трейсах ORA-600 [ktbdchk1: bad dscn] – по записям для сегментов типа INDEX с флагом E[rror]:
$ grep 'seg/obj:' ORCL_ora_8885.trc | grep INDEX seg/obj: 0x4a06f csc: 0x786.2fa19d28 itc: 164 flg: E typ: 2 - INDEX seg/obj: 0x19749f csc: 0x786.fa7e074 itc: 120 flg: E typ: 2 - INDEX seg/obj: 0x4a5bb csc: 0x786.2ae4966b itc: 1 flg: E typ: 2 - INDEX
и получить имена индексов из словаря:
SQL> select * from dba_objects
where data_object_id in (
to_number('4a06f', 'xxxxxxx'),
to_number('19749f', 'xxxxxxx'),
to_number('4a5bb', 'xxxxxxx'))
/
2) по записям ORA-01555 со странными значениями Query Duration в alert.log:
ORA-01555 caused by SQL statement below (SQL ID: 06mwy7ua78adg, Query Duration=7 sec, SCN: 0x0786.62a03def): SELECT DIST.*...
и далее, по SQL_ID получить и перестроить все используемые в плане выполнения запроса индексы:
SQL> select distinct 'alter index '||object_owner||'.'||object_name||' rebuild online parallel 8;'
2 from dba_hist_sql_plan where sql_id in ('06mwy7ua78adg') and operation = 'INDEX'
3 /
'ALTERINDEX'||OBJECT_OWNER||'.
--------------------------------------------------------------------------------
alter index SCOTT.BROKEN_INDEX_N5 rebuild online parallel 8;
alter index SCOTT.BROKEN_INDEX_N3 rebuild online parallel 8;
Как превентивно вычислить все блоки, затронутые проблемой?
1) как и описано в документе поддержки, только запуск утилиты dbverify* по всем файлам бд может дать полный список проблемных блоков:
SQL> select 'dbv USERID=''system/manager'' FILE='''||file_name||''' LOGFILE=dbv'||file_id||'.log' from dba_data_files where tablespace_name not like '%UNDO%'; $ dbv USERID='system/manager' FILE='+DATA/ORCL/datafile/users.5081.765722115' LOGFILE=dbv18.log $ ... $ grep -r 'failed with check code 6056' *.log dbv18.log:Page 3063232 failed with check code 6056 ...
– получем список файлов (по номеру лога) и ошибочных – check code 6056 – блоков (page в логе dbv = номеру блока), остаётся найти и перестроить повреждённые индексы:
SQL> select e.file_id, e.relative_fno, e.segment_type, e.owner, e.segment_name, e.partition_name, e.tablespace_name, x.err_id 2 from dba_extents e 3 where (e.file_id = 18 and 3063232 between e.block_id and e.block_id + e.blocks - 1) 4 / FILE_ID RELATIVE_FNO SEGMENT_TYPE OWNER SEGMENT_NAME PARTITION_NAME TABLESPACE_NAME ------- ------------ ------------- ------ ---------------- --------------- --------------- 18 18 INDEX SCOTT BROKEN_INDEX_N5 USERS SQL> alter index SCOTT.BROKEN_INDEX_N5 rebuild online parallel 4;
*) при запуске DBVERIFY в версии 11.2 на уровне отдельных объектов по прежнему выдаётся ORA-01000 для любых объёмных сегментов – см. dbverify
2) команда ANALYZE, которая в принципе может диагностировать logical block corruption в этом случае делает это довольно своеобразным образом (и применима только если проблемная таблица или индекс уже известны) – при запуске по битому индексу:
SQL> ANALYZE INDEX SCOTT.BROKEN_INDEX_N5 VALIDATE STRUCTURE online;
- выполняется бесконечно, заполняя alert.log сообщениями типа:
... ANALYZE INDEX SCOTT.BROKEN_INDEX_N5 VALIDATE STRUCTURE online ORA-01555 caused by SQL statement below (SQL ID: 5zgxrygv0f44a, SCN: 0x0786.6884c5d1): ANALYZE INDEX SCOTT.BROKEN_INDEX_N5 VALIDATE STRUCTURE online ORA-01555 caused by SQL statement below (SQL ID: 5zgxrygv0f44a, SCN: 0x0786.6884c5d1): ...
при запуске по таблице с битым индексом:
SQL> ANALYZE TABLE SCOTT.MY_TABLE VALIDATE STRUCTURE CASCADE online;
падает с ORA-01555 как только доходит до проблемного индекса
3) в этом случае команда RMAN validate check logical database неприменима и отрабатывает без ошибок – rman не умеет диагностировать логически битые блоки с logical SCN inconsistency
В версии 11.2.0.2 проблема исправляется установкой параметра _ktb_debug_flags=8 на всех Primary и Standby системах – т.е. фикс включен в версию, но требуется отдельное действие, чтобы “разрешить” это исправление
