Oracle mechanics

04.12.2014

ORA-8103 при использовании BCT на standby db

Filed under: Active Data Guard,bugs,Oracle — Игорь Усольцев @ 22:59
Tags: ,

После восстановления очередной тестовой бд с использованием инкрементальных бэкапов, сделанных с использованием Block Change Tracking (BCT) на standby версии 11.2.0.3 получили при попытке последовательно прочитать определённые блоки таблицы:

SQL> select/*+ full(t)*/ count(*) from U2.CALL_STAT t;
 
select/*+ full(t)*/ count(*) from U2.CALL_STAT t
 
ORA-08103: object no longer exists

SQL> analyze table U2.CALL_STAT validate structure;
 
analyze table U2.CALL_STAT validate structure
 
ORA-08103: object no longer exists

, при этом в трейсах можно видеть фактический источник ошибки:

kcbzibmlt: dump suspect buffer, err=8103
buffer tsn: 17 rdba: 0x120d87c0 (72/886720)
scn: 0x0000.00000000 seq: 0x01 flg: 0x05 tail: 0x00000001
frmt: 0x02 chkval: 0x12cd type: 0x00=unknown                 -- *
Hex dump of corrupt header 4 = CORRUPT
Dump of memory from 0x000000028DAD8000 to 0x000000028DAD8014
...
Hex dump of block: st=4, typ_found=0                         -- *
Dump of memory from 0x000000028DAD8000 to 0x000000028DAD9000
...
Dump of buffer cache at level 8 for tsn=17 rdba=302876544
BH (0x9fcfbcb8) file#: 72 rdba: 0x120d8780 (72/886656) class: 1 ba: 0x9d44f000
  set: 34 pool: 3 bsz: 4096 bsi: 0 sflg: 1 pwc: 0,25
  dbwrid: 1 obj: 940841 objn: 940841 tsn: 17 afn: 72 hint: f -- **
...

— указание на объект бд/objn в заголовке блока присутствует (**), а тип данных — неизвестен / unknown (*), что достаточно точно совпадает с Bug 17929240 : ORA-8103 / ORA-1555 AFTER RMAN RESTORE USING INCREMENTAL FROM STANDBY DB, где в качестве основного/рекомендованного workaround-а указывается отключение BCT, что замедлит backup

При этом, как показано выше ANALYZE TABLE VALIDATE STRUCTURE из-за такого рода повреждений блоков не применим, но при допустимости потери нескольких битых блоков (на тесте, например), проблема хорошо фиксируется процедурами пакета DBMS_REPAIR:

SQL> BEGIN
  2    DBMS_REPAIR.admin_tables (
  3      table_name => 'REPAIR_TABLE',
  4      table_type => DBMS_REPAIR.repair_table,
  5      action     => DBMS_REPAIR.create_action,
  6      tablespace => 'USERS');
  7  
  8    DBMS_REPAIR.admin_tables (
  9      table_name => 'ORPHAN_KEY_TABLE',
 10      table_type => DBMS_REPAIR.orphan_table,
 11      action     => DBMS_REPAIR.create_action,
 12      tablespace => 'USERS');
 13  END;
 14  /
 
PL/SQL procedure successfully completed

SQL> SET SERVEROUTPUT ON
SQL> DECLARE
  2    v_num_corrupt INT;
  3  BEGIN
  4    v_num_corrupt := 0;
  5    DBMS_REPAIR.check_object (
  6      schema_name       => 'U2',
  7      object_name       => 'CALL_STAT',
  8      repair_table_name => 'REPAIR_TABLE',
  9      corrupt_count     =>  v_num_corrupt);
 10    DBMS_OUTPUT.put_line('number corrupt: ' || TO_CHAR (v_num_corrupt));
 11  END;
 12  /
 
number corrupt: 2
 
PL/SQL procedure successfully completed
 
SQL> select * from REPAIR_TABLE where object_name = 'CALL_STAT';
 
 OBJECT_ID TABLESPACE_ID RELATIVE_FILE_ID   BLOCK_ID CORRUPT_TYPE SCHEMA_NAME  OBJECT_NAME   CORRUPT_DESCRIPTION                            REPAIR_DESCRIPTION           MARKED_CORRUPT CHECK_TIMESTAMP
---------- ------------- ---------------- ---------- ------------ ------------ ------------- ---------------------------------------------- ---------------------------- -------------- ---------------
    940841            17               72     886720         6129 U2           CALL_STAT  Block Checking: DBA = 302876608, Block Type =  mark block software corrupt  FALSE          16.10.2014 17:0
                                                                                             data header at 0xd16b4002c                                                                                
                                                                                             kdbchk: fsbo(0) wrong, (hsz 14)                                                                           
 
    940841            17               72     886721         6129 U2           CALL_STAT  Block Checking: DBA = 302876609, Block Type =  mark block software corrupt  FALSE          16.10.2014 17:0
                                                                                             data header at 0xcf875702c                                                                                
                                                                                             kdbchk: fsbo(0) wrong, (hsz 14)                                                                           
 

SQL> DECLARE
  2    v_num_fix INT;
  3  BEGIN
  4    v_num_fix := 0;
  5    DBMS_REPAIR.fix_corrupt_blocks (
  6      schema_name       => 'U2',
  7      object_name       => 'CALL_STAT',
  8      object_type       => Dbms_Repair.table_object,
  9      repair_table_name => 'REPAIR_TABLE',
 10      fix_count         => v_num_fix);
 11    DBMS_OUTPUT.put_line('num fix: ' || TO_CHAR(v_num_fix));
 12  END;
 13  /
 
num fix: 2
 
PL/SQL procedure successfully completed

SQL> BEGIN
  2    DBMS_REPAIR.rebuild_freelists (
  3      schema_name => 'U2',
  4      object_name => 'CALL_STAT',
  5      object_type => DBMS_REPAIR.table_object);
  6  END;
  7  /
 
PL/SQL procedure successfully completed
 
SQL> select skip_corrupt from dba_tables where table_name = 'CALL_STAT';
 
SKIP_CORRUPT
------------
DISABLED
 
SQL> BEGIN
  2    DBMS_REPAIR.skip_corrupt_blocks (
  3      schema_name => 'U2',
  4      object_name => 'CALL_STAT',
  5      object_type => DBMS_REPAIR.table_object,
  6      flags       => DBMS_REPAIR.skip_flag);
  7  END;
  8  /
 
PL/SQL procedure successfully completed
 
SQL> select skip_corrupt from dba_tables where table_name = 'CALL_STAT';
 
SKIP_CORRUPT
------------
ENABLED

, после чего ANALYZE TABLE по-прежнему не проходит:

SQL> analyze table U2.CALL_STAT validate structure;
 
analyze table U2.CALL_STAT validate structure
 
ORA-01498: block check failure - see trace file

, но уже с другими симптомами:

*** 2014-10-16 17:18:38.503
table scan: segment: file# 74 block# 574208
            skipping corrupt block file# 72 block# 886720
table scan: segment: file# 74 block# 574208
            skipping corrupt block file# 72 block# 886721
...
*** 2014-10-16 18:17:16.591
skipping corrupted block at rdba: 0x120d87c0
skipping corrupted block at rdba: 0x120d87c1

А вот запросы к почти целой таблице (ну, минус пара блоков) ожидаемо начинают выполняться без ошибок:

SQL> select/*+ full(t)*/ count(*) from U2.CALL_STAT t;
 
  COUNT(*)
----------
  29627218

После этого можно:

  • проверить указанным способом все остальные сегменты бд, и привести т.о. бд в условно-функционнальное состояние
  • создать SR в подтверждение вышеприведённого бага
  • отключить BCT и ждать патча / решения

Однако, коллега Руслан Бикбаев не успокоился и предположил, а затем успешно проверил / подтвердил предположение о том, что полученные проблемы на нашей системе были связаны с тем, что режим BCT обычно включался на standby уже после того, как был сделан нулевой инкрементальный бэкап, что формально не противоречит руководству и логике BCT

После включения BCT на standby до старта level 0 incremental backup, проблем ORA-8103 на восстановленной тестовой бд не наблюдалось

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

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

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 такие блоггеры, как: