Oracle mechanics

21.12.2011

ORA-00600 [ktbdchk1: bad dscn] — как найти повреждённые индексы

Filed under: Backup and Recovery,bugs,database,Oracle — Игорь Усольцев @ 00:04
Tags: , , ,

Пример практического проявления 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 системах — т.е. фикс включен в версию, но требуется отдельное действие, чтобы «разрешить» это исправление

Добавить комментарий »

Комментариев нет.

RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Блог на WordPress.com.

%d такие блоггеры, как: