连接主机和存储的核心交换机重启引起的一场血案

总结了一下，希望大家能够从中汲取教训...

[@more@]

为了保护客户的信息我用user1替换了客户使用的用户，用ABCDE代替了所涉及到的2张处理的表。
首先要感谢恩墨科技eygle和催化给予的大力支持和帮助...
2周过去了，我尽可能的还原一下当时的情况，因为我也不在现场，正好在北京出差...
环境：aix5.2单机 oracle：9204单实例大约500g大小的db，应用sap
备份情况：有一份前1、2天的db备份(归档日志似乎没有)在磁带上，但是从未验证过是否可以顺利恢复...而且之后的归档似乎已经不全了...(由于磁盘空间紧张
系统差不多用了有10年了，一直比较稳定，当然从现在来看隐患不少，很多设备也相对陈旧或者过时...另外很显然都是单点...
似乎删除了很多)
应该是12月9号早上一个客户反应系统由于连接主机和存储之间的核心交换机重启导致
db不能正常打开，具体原因是：congrolfile丢失一个，当前redo丢失...
我远程连上去看到的情况是controlfile已经都存在，客户反应是通过之前保留下来的脚本
重新创建了...但是我看到的情况感觉不是...因为我发现v$datafile里记录的很多
datafile的checkpoint_change#比v$datafile_header里记录的对应的datafile的checkpoint_change#
要小，于是我先尝试发出recover database;提示隐约记得是需要使用using backup controlfile...
最后发出recover database using backup controlfile;开始顺利恢复...直到需要寻找当前redo，由于当前redo丢失，
所以只能再次发出recover database using backup controlfile until cancel；
最后的提示已经记不清楚了...
尝试alter database open resetlogs；以后一直hang，然后通过另外的sqlplus连上去查看发现提示
连接到一个idle instance，事实上很显然实例已经down了，查看alert以及相关的trace文件，发现
一些600错误，顾不上细查，强加隐含参数_allow_resetlogs_corrution=true尝试打开db，问题依旧直接hang事实上instance已经
crash...从各种情况分析这个库给我的感觉是不能通过常规方式打开了...
事实上最终这个库崔华以非常规方式打开了，挽救了几乎是100%的数据，由于事故发生在晚上10点左右，业务相对较少，所以情况
相对来说还是要简单的多...打开之后错误很多，差不多可能都是600，后来崔华都一一处理掉了...在这里
首先是感谢，其次是崇拜了...处理过程有机会他能和大家分享的话就更好了...
下面是他处理之后发现2张大表（1张7g左右一张39左右的表里面存在一些问题）全表扫描提示：ora-08103,通过分析
发现其实存在block corruption,但是oracle提供的检查折断的常规方式都检查不到甚至检查
不下去：
1.dbv检查这2张表所在的表空间包含的120多个dbf没有任何错误
2.rman里backup check logical validate database之后v$database_block_corruption里没有任何记录
3.dbms_repair.check_object执行之后错误如下：
--========================
SQL> DECLARE
2 num_corrupt INT;
3 BEGIN
4 num_corrupt := 0;
5 DBMS_REPAIR.CHECK_OBJECT (
6 SCHEMA_NAME => 'users1',
7 OBJECT_NAME => 'ABCDE',
8 REPAIR_TABLE_NAME => 'REPAIR_TABLE',
9 corrupt_count => num_corrupt);
D 10 BMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
11 END;
12 /


DECLARE
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [4555], [0], [], [], [], [], [], []
ORA-06512: at "SYS.DBMS_REPAIR", line 284
ORA-06512: at line 5
--========================
4.analyze table table_name validate structure;

ERROR 位于第 1 行:
ORA-08103: object no longer exists
--=======================
下面是我最终锁定这几个corruption block的步骤，昨天崔华整理了更详细更专业的过程查找这几个block，没有和他
商量我暂时也不方便贴出来了。

SQL> alter session set events '8103 trace name errorstack level 3' ;

会话已更改。

SQL> set time on
18:28:21 SQL> set timing on
18:28:25 SQL> select count(*) from users1.ABCDE;
select count(*) from users1.ABCDE
*
ERROR 位于第 1 行:
ORA-08103: object no longer exists


已用时间: 01: 06: 25.09
19:34:59 SQL>
19:34:59 SQL>
trace文件中我发现下面这段信息中的：file#=f8, block#=17be1, blocks=8非常可疑，
转化之后发现是248号文件的97249个block。
--============================
SO: 70000012d2bda90, type: 4, owner: 70000012d297e00, flag: INIT/-/-/0x00
(session) trans: 0, creator: 70000012d297e00, flag: (100041) USR/- BSY/-/-/-/-/-
DID: 0001-0016-00000002, short-term DID: 0000-0000-00000000
txn branch: 0
oct: 3, prv: 0, sql: 70000013bd33dc0, psql: 70000013bd33dc0, user: 26/XYS
O/S info: user: yxf, term: QM-87B852802340, ospid: 1780:6068, machine: WORKGROUPQM-87B852802340
program: sqlplus.exe
application name: SQL*Plus, hash value=3669949024
last wait for 'db file scattered read' blocking sess=0x0 seq=14393 wait_time=1740
file#=f8, block#=17be1, blocks=8
temporary object counter: 0
--=================================
SQL> select to_number('17be1','xxxxxxxxx') from dual;

TO_NUMBER('17BE1','XXXXXXXXX')
------------------------------
97249

dump block 97249所在的一个extent所在的８个block，发现从97254开始一直到97256
的dump信息都存在问题，而且file#大家都看到了是0,摘取了几个dump的信息如下：
SQL> alter system dump datafile 248 block min 97249 block max 97256;

系统已更改。

SQL>
--================================
buffer tsn: 6 rdba: 0x00017be6 (0/97254)
scn: 0x0000.00000000 seq: 0x01 flg: 0x05 tail: 0x00000001
frmt: 0x02 chkval: 0x7ae1 type: 0x00=unknown
Hex dump of corrupt header 4 = CORRUPT
Dump of memory from 0x000000011023D000 to 0x000000011023D014
11023D000 00020000 00017BE6 00000000 00000105 [......{.........]
11023D010 7AE10000 [z...]
buffer tsn: 6 rdba: 0x00017be7 (0/97255)
scn: 0x0000.00000000 seq: 0x01 flg: 0x05 tail: 0x00000001
frmt: 0x02 chkval: 0x7ae0 type: 0x00=unknown
Hex dump of corrupt header 4 = CORRUPT
Dump of memory from 0x000000011023D000 to 0x000000011023D014
11023D000 00020000 00017BE7 00000000 00000105 [......{.........]
11023D010 7AE00000 [z...]
buffer tsn: 6 rdba: 0x00017be8 (0/97256)
scn: 0x0000.00000000 seq: 0x01 flg: 0x05 tail: 0x00000001
frmt: 0x02 chkval: 0x7aef type: 0x00=unknown
Hex dump of corrupt header 4 = CORRUPT
Dump of memory from 0x000000011023D000 to 0x000000011023D014
11023D000 00020000 00017BE8 00000000 00000105 [......{.........]
11023D010 7AEF0000 [z...]
End dump data blocks tsn: 6 file#: 248 minblk 97249 maxblk 97256
--=======================================================
SQL> select object_id,data_object_id from dba_objects where object_name='ABCDE'
;

OBJECT_ID DATA_OBJECT_ID
---------- --------------
45221 45221
--通过构造rowid来尝试查询数据再现了错误号：ORA-08103
SQL> select dbms_rowid.rowid_create(1,45221,248,97257,1) from dual;

DBMS_ROWID.ROWID_CREATE(1,45221,248,
------------------------------------
AAALClAD4AAAXvpAAB

SQL> select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvpAAB';
select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvpAAB'
*
ERROR 位于第 1 行:
ORA-08103: object no longer exists


SQL> select dbms_rowid.rowid_create(1,45221,248,97258,1) from dual;

DBMS_ROWID.ROWID_CREATE(1,45221,248,
------------------------------------
AAALClAD4AAAXvqAAB

SQL> select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvqAAB';
select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvqAAB'
*
ERROR 位于第 1 行:
ORA-08103: object no longer exists


SQL> select dbms_rowid.rowid_create(1,45221,248,97259,1) from dual;

DBMS_ROWID.ROWID_CREATE(1,45221,248,
------------------------------------
AAALClAD4AAAXvrAAB

SQL> select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvrAAB';
select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvrAAB'
*
ERROR 位于第 1 行:
ORA-08103: object no longer exists


SQL> select dbms_rowid.rowid_create(1,45221,248,97260,1) from dual;

DBMS_ROWID.ROWID_CREATE(1,45221,248,
------------------------------------
AAALClAD4AAAXvsAAB

SQL> select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvsAAB';
select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvsAAB'
*
ERROR 位于第 1 行:
ORA-08103: object no longer exists


SQL> select dbms_rowid.rowid_create(1,45221,248,97261,1) from dual;

DBMS_ROWID.ROWID_CREATE(1,45221,248,
------------------------------------
AAALClAD4AAAXvtAAB

SQL> select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvtAAB';
select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvtAAB'
*
ERROR 位于第 1 行:
ORA-08103: object no longer exists


SQL> select dbms_rowid.rowid_create(1,45221,248,97262,1) from dual;

DBMS_ROWID.ROWID_CREATE(1,45221,248,
------------------------------------
AAALClAD4AAAXvuAAB

SQL> select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvuAAB';
select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvuAAB'
*
ERROR 位于第 1 行:
ORA-08103: object no longer exists


SQL> select dbms_rowid.rowid_create(1,45221,248,97263,1) from dual;

DBMS_ROWID.ROWID_CREATE(1,45221,248,
------------------------------------
AAALClAD4AAAXvvAAB

SQL> select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvvAAB';
select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvvAAB'
*
ERROR 位于第 1 行:
ORA-08103: object no longer exists


SQL> select dbms_rowid.rowid_create(1,45221,248,97264,1) from dual;

DBMS_ROWID.ROWID_CREATE(1,45221,248,
------------------------------------
AAALClAD4AAAXvwAAB

SQL> select count(*) from users1.ABCDE where rowid='AAALClAD4AAAXvwAAB';

COUNT(*)
----------
1

SQL>
--=======================
大致锁定了表里的block之后接下来就是处理了，原本我是想通过直接修改block里的block折断
标记：seq_kcbh(第14个byte)来让oracle能够通过上面提到的4种方式识别到这几个corrupted block，后来
崔华通过BBED直接修改了block的checksum(第16个byte),之后通过DBMS_REPAIR.CHECK_OBJECT
顺利识别到了，后来直接跳过去了，然后就是开始创建index，之前由于出现600等一些错误把这
2个表上的index都drop掉了，重建index之后也是报8103错误不能创建成功。
截至昨天本次故障处理告一段落了，不过遗撼的是早晨再次收到客户的反馈:应用程序中捕获到了
oracle中的错误：ora-01578 orace data block corrutped (file# 248 block# 97259),这个block明明
昨天已经标记为corrupted了，为什么还是去访问了呢？不过客户反应倒是应用似乎没有中断...貌似没有影响
使用...暂时说不清楚了，隐约的感觉这个库的问题后续还会或多或少暴露出来一些...
最后由衷的告诉大家：千万记得做好备份、时刻验证备份的有效性，备份不管做多少都不过分...
--=======================
下面是崔华通过bbed在修改block的checksum值的一个过程，从dump出来这些corruted block的信息来看这些
block上似乎没有任何信息：
--============================
SAPDB raprd 91> bbed parfile=par.txt
Password:

BBED: Release 2.0.0.0.0 - Limited Production on Sun Dec 19 14:47:48 2010

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

************* !!! For Oracle Internal Use only !!! ***************

BBED> set file 248 block 97263
FILE# 248
BLOCK# 97263

BBED> dump
File: /oracle/PRD/sapdata5/btabd_120/btabd.data120 (248)
Block: 97263 Offsets: 0 to 511 Dba:0x3e017bef
------------------------------------------------------------------------
00020000 00017bef 00000000 00000105 7ae80000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> set offset 16
OFFSET 16

BBED> dump
File: /oracle/PRD/sapdata5/btabd_120/btabd.data120 (248)
Block: 97263 Offsets: 16 to 527 Dba:0x3e017bef
------------------------------------------------------------------------
7ae80000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> modify /x 7ae9
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /oracle/PRD/sapdata5/btabd_120/btabd.data120 (248)
Block: 97263 Offsets: 16 to 527 Dba:0x3e017bef
------------------------------------------------------------------------
7ae90000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>
--==============================
最后补充一点undo是手动管理方式，rollback segment可能很多都存在问题，rollback
segment里当时是不是有事务我也不得而知了...
昨天其实还处理一个600错误，通过诊断是发生在1个大约10个g上的一个表上的index存在问题，
drop index之后重建就可以访问了，以后估计这个库断断续续还可能出现一些问题，毕竟跑了1周多了，
感觉问题应该不会太多了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/19602/viewspace-1043343/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/19602/viewspace-1043343/