Вы здесь

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

Пример практического проявления 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 INDEXseg/obj: 0x4a06f  csc: 0x786.2fa19d28  itc: 164  flg: E  typ: 2 - INDEXseg/obj: 0x19749f  csc: 0x786.fa7e074  itc: 120  flg: E  typ: 2 - INDEXseg/obj: 0x4a5bb  csc: 0x786.2ae4966b  itc: 1  flg: E  typ: 2 - INDEXи получить имена индексов из словаря:SQL> select * from dba_objectswhere 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;' 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_idfrom dba_extents ewhere (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 для любых объёмных сегментов — см. dbverify2) команда ANALYZE, которая в принципе может диагностировать logical block corruption в этом случае делает это довольно своеобразным образом (и применима только если проблемная таблица или индекс уже известны) — при запуске по битому индексу:SQL> ANALYZE INDEX SCOTT.BROKEN_INDEX_N5 VALIDATE STRUCTURE online; выполняется бесконечно, заполняя alert.log сообщениями типа:...ANALYZE INDEX SCOTT.BROKEN_INDEX_N5 VALIDATE STRUCTURE onlineORA-01555 caused by SQL statement below (SQL ID: 5zgxrygv0f44a, SCN: 0x0786.6884c5d1): ANALYZE INDEX SCOTT.BROKEN_INDEX_N5 VALIDATE STRUCTURE onlineORA-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 системах — т.е. фикс включен в версию, но требуется отдельное действие, чтобы «разрешить» это исправление

Menu: 

Post new comment

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Разрешённые HTML-теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.
3 + 3 =
Решите эту простую математическую задачу и введите результат. Например, для 1+3, введите 4.