看来什么东西都有可能有出问题的一天。上次是IBM的中端存储,这次是EMC的高端,DMX1500也会出现错误。而且涉及了oracle数据库应用。这次又有事情做了。
DMX1500 的一块逻辑盘和热备盘同时发生错误。导致此逻辑盘和热备盘上对应的逻辑块同时不可访问。造成了主机存储方面的IO丢失。数据变得不一致了!
一大早,就接到了**客户的电话,丁工和我说,他们的***平台数据库突然无法访问了,报插入数据错误,之后他们的应用工程师再尝试启动数据库,数据库成功启动了,但是应用在插入数据的时候变得很慢,而且经常会报错:
我说,好的,让我先查看下日志信息,再看看问题的严重性:
从日志信息中,很快我找到了故障时间段的错误信息,如下:
Tue Aug 17 21:38:50 2010
KCF: write/open error block=0x235abd online=1
file=18 /ora_vg1/oradata/XRAPUSER_DATA_10
error=27063 txt: 'IBM AIX RISC System/6000 Error: 5: I/O error
Additional information: -1
Additional information: 8192'
Tue Aug 17 21:38:50 2010
Errors in file /oracle/admin/qbxtdb/bdump/qbxtdb_dbw0_303140.trc:
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01114: IO error writing block to file 18 (block # 2316989)
ORA-01110: data file 18: '/ora_vg1/oradata/XRAPUSER_DATA_10'
ORA-27063: number of bytes read/written is incorrect
IBM AIX RISC System/6000 Error: 5: I/O error
Additional information: -1
Additional information: 8192
DBW0: terminating instance due to error 1242
Instance terminated by DBW0, pid = 303140
这套库是一套运行在AIX 平台的 10G (10.2.0.4)数据库。从错误信息可以看出,
当前数据库运行在非归档模式下的,因为数据库某个数据文件(因为media error)无法访问,导致数据库对文件的读写IO丢失。最终因为错误1242,DBW0这个进程把数据库Instance down下来了。
相关错误信息如下:
[oracle@~]$oerr ora 01114
01114, 00000, "IO error writing block to file %s (block # %s)"
// *Cause: The device on which the file resides is probably offline. If the
// file is a temporary file, then it is also possible that the device
// has run out of space. This could happen because disk space of
// temporary files is not necessarily allocated at file creation time.
// *Action: Restore access to the device or remove unnecessary files to free
// up space.
[oracle@~]$oerr ora 01110
01110, 00000, "data file %s: '%s'"
// *Cause: Reporting file name for details of another error
// *Action: See associated error message
[oracle@~]$oerr ora 27063
27063, 00000, "number of bytes read/written is incorrect"
// *Cause: the number of bytes read/written as returned by aiowait
// does not match the original number, additional information
// indicates both these numbers
// *Action: check errno
[oracle@~]$oerr ora 1242
01242, 00000, "data file suffered media failure: database in NOARCHIVELOG mode"
// *Cause: The database is in NOARCHIVELOG mode and a database file was
// detected as inaccessible due to media failure.
// *Action: Restore accessibility to the file mentioned in the error stack
// and restart the instance.
我在查看了下当前数据文件的信息情况,如下所示:
SQL> run
1* select file#,checkpoint_change# from v$datafile
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1.1321E+13
2 1.1321E+13
3 1.1321E+13
4 1.1321E+13
5 1.1321E+13
6 1.1321E+13
7 1.1321E+13
8 1.1321E+13
9 1.1321E+13
10 1.1321E+13
11 1.1321E+13
FILE# CHECKPOINT_CHANGE#
---------- ------------------
12 1.1321E+13
13 1.1321E+13
14 1.1321E+13
15 1.1321E+13
16 1.1321E+13
17 1.1321E+13
18 1.1321E+13
19 1.1321E+13
20 1.1321E+13
20 rows selected.
SQL> spool off
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1.1321E+13
2 1.1321E+13
3 1.1321E+13
4 1.1321E+13
5 1.1321E+13
6 1.1321E+13
7 1.1321E+13
8 1.1321E+13
9 1.1321E+13
10 1.1321E+13
11 1.1321E+13
FILE# CHECKPOINT_CHANGE#
---------- ------------------
12 1.1321E+13
13 1.1321E+13
14 1.1321E+13
15 1.1321E+13
16 1.1321E+13
17 1.1321E+13
18 0
19 1.1321E+13
20 1.1321E+13
20 rows selected.
因为数据库运行在非归档模式下,和客户沟通之后,数据库没有过备份,我的第一个反应就是,这种情况下,要救下数据库估计已经很困难了。
此时EMC的工程师也从上海灰来了,他们从DMX控制台的确发现了磁盘碎片错误,并已经定位了原因。
EMC张工和我沟通,说磁盘故障原因是“DMX1500 的一块逻辑盘和热备盘同时发生错误。导致此逻辑盘和热备盘上对应的逻辑块同时不可访问。造成了主机存储方面的IO丢失,数据变得不一致了!"
张工想了解当前的数据库故障和坏块的对应关系,为了配合他,我查询了下此数据库和EMC存储的对应关系。
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/ora_vg1/oradata/XRAPUSER_DATA_10
20 rows selected.
从上面可以看到文件的位置为 /ora_vg1/oradata/XRAPUSER_DATA_10 ,
可以看到此文件对应的挂载点为 /ora_vg1
从操作系统查看此挂载点对应了lv:
df -k
得到了下面的关心信息:
/dev/fslv00 501350400 406594416 19% 8 1% /ora_vg1
可见对应的lv为 fslv00
查看此lv信息,它对应的 vg为 ora_vg1,信息如下
# lsvg -l ora_vg1
ora_vg1:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
fslv00 jfs2 15300 15300 10 open/syncd /ora_vg1
loglv01 jfs2log 1 1 1 open/syncd N/A
使用lspv 观察ora_vg1对应的底层pv信息,如下:
Lspv
hdiskpower82 00c450b5a76eb888 ora_vg1 active
hdiskpower83 00c450b5a768f372 ora_vg1 active
hdiskpower84 00c450b5a772b316 ora_vg1 active
hdiskpower85 00c450b5a76d1a1e ora_vg1 active
hdiskpower86 00c450b5a7746e41 ora_vg1 active
hdiskpower87 00c450b5a76c5d8e ora_vg1 active
hdiskpower88 00c450b5a7737d64 ora_vg1 active
hdiskpower89 00c450b5a76b4c87 ora_vg1 active
hdiskpower90 00c450b5a7728526 ora_vg1 active
hdiskpower91 00c450b5a76ab4af ora_vg1 active
从上可以得出,hdiskpower82-91 ,都是”故障嫌疑盘“
我们需要从EMC上查看进一步的信息,
查看这几个 pv对应的DMX 底层信息,如下:
powermt display dev=all
Pseudo name=hdiskpower82
Symmetrix ID=隐藏
Logical device ID=036A
state=alive; policy=SymmOpt; priority=0; queued-IOs=0
==============================================================================
---------------- Host --------------- - Stor - -- I/O Path - -- Stats ---
### HW Path I/O Paths Interf. Mode State Q-IOs Errors
==============================================================================
1 fscsi1 hdisk190 FA 9cA active alive 0 0
0 fscsi0 hdisk86 FA 8cA active alive 0 0
从上面的信息得出下面的内容
036A 036E 0372 0376 037A 037E 0382 0386 038A 038E
上面ID的磁盘都为疑似故障盘。
果然,张工根据这个信息,进一步查看了存储的底层信息,发现037A这块盘存在故障。关于故障原因,张工又给了更细的说法:
037A代表了 037A/037B/037C/037D 这四块盘。
其中037A和 0370(以036E开头的盘)是镜像关系,但恰好这两块盘都在一个磁盘上。当此磁盘故障发生的时候,037A发生了fracture 坏块故障,而它的镜像盘0370也故障了。正常情况下,镜像盘可以替代故障盘,而这种情况导致了它无法接管盘。当发生了无法接管等故障之后,EMC 存储控制器为了防止进一步对这块盘的破坏操作,就把对于这块盘的IO锁住了。而因为IO 被锁住,相关数据盘的信息丢失了,进一步反映到上层ORACLRE数据库应用,数据库文件发生了media err 错误。
其实处理这种问题,如果数据库在归档模式下是很好做的,oracle metalink有下面的note详细阐述了解决问题的过程:
ORA-00376 and ORA-01110 Database File Unavailable [ID 160705.1]
--------------------------------------------------------------------------------
Modified 12-AUG-2003 Type PROBLEM Status PUBLISHED
fact: Oracle Server - Enterprise Edition
symptom: Database file is unavailable
symptom: ORA-00376: file %s cannot be read at this time
symptom: ORA-01110: data file %s: '%s'
cause: Datafile or tablespace to which the datafile belongs is offline
fix:
1. Check the fuzzy column of v$datafile_header to check if the file maybe is in
backupmode. If so bring the tablespace that contains the file mentioned in the
error out of backupmode:
ALTER DATABASE TABLESPACE <tsname> END BACKUP;
2. Check v$datafile (status and enabled field) to see if the datafile needs
recovery and if it's offline. Bring the datafile back online:
ALTER DATABASE DATAFILE <datafile> ONLINE;
3. Check all_tablespaces to see if the tablespace is offline. Bring the
tablespace back online:
ALTER TABLESPACE <tablespace> ONLINE;
4. Do a recover of the datafile or tablespace:
RECOVER DATAFILE '<fullpath>/<filename>';
or
RECOVER TABLESPACE <tsname>;
or
RECOVER DATABASE;
Remark: This will always work when in ARCHIVELOG mode, on condition you still
have all the needed archive logs files. When in NOARCHIVELOG mode it depends
if the on-line redologs still contain sufficient information to perform the
recovery.
可以看到,因为在非归档模式下,而错误发生在昨天,这种大访问量的数据库经过一天的运行之后,联机日志早就切换过很多次了。而联机日志 (Online redolog) 包含的可以修复media err故障的信息早就已经丢失了!
我拟定了下面的方案:
1>、根据数据文件查找对应的表空间,进一步找到这个表空间对应的用户名。
2>、对这个用户进行备份。
3>、把这个用户数据备份导出到别的库,查看抢救到的数据情况。
SQL> select a.name,b.name from v$datafile a ,v$tablespace b where a.ts#=b.ts#;
可以看到,我们感兴趣的表空间是, XRAPUSER。这个表空间对应了下面的几个文件:
/oracle/oradata/XRAPUSER_DATA_01
/oracle/oradata/XRAPUSER_DATA_02
/oracle/oradata/XRAPUSER_DATA_03
/oracle/oradata/XRAPUSER_DATA_04
/oracle/oradata/XRAPUSER_DATA_05
/oracle/oradata/XRAPUSER_DATA_06
/oracle/oradata/XRAPUSER_DATA_07
/ora_vg1/oradata/XRAPUSER_DATA_08
/ora_vg1/oradata/XRAPUSER_DATA_09
/ora_vg1/oradata/XRAPUSER_DATA_10
下面命令查询这个表空间对应的用户信息:
对应的用户为:
QL> select username,default_tablespace from dba_users;
USERNAME DEFAULT_TABLESPACE
------------------------------ ------------------------
ZTCX XRAPUSER
QBUSER XRAPUSER
可见我们感兴趣的用户为:
ZTCX 、QBUSER
客户和我们确认,ztcx 只是一个测试用户,而他们关心的是QBUSER这个用户的数据能抢救回来多少?
我马上用toad 登上去查看了下这个表空间下的数据容量、大概有200G左右。
因为这套库没有备份,又没有开启归档,当前情况下,只有尽量从失败的数据文件抢救数据出来了。
鉴于数据库当前是打开状态,且当前表空间XRAPUSER 运行也是正常的。
我建议用户用下面的脚本对数据进行备份,并时刻关注备份情况:
nohup exp qbuser/password file='/ora_vg2/exp/qbuser.dmp' owner=qbuser log=qbuser.log &
在等待备份结束的时候,我抽空回公司干了点小活,最近我接手的项目接近尾声,也到了关键的时候,有很多事情需要沟通和处理。
正当我在公司忙得热火朝天的时候,又接到一个电话,丁工说:”程工,这次问题大了,我们的核心业务系统也出现问题了!你赶快过来一趟吧。“