EMC 故障情况下ORACLE 救火行动(之一)
来源:互联网 发布:人民网网络舆情订购 编辑:程序博客网 时间:2024/05/17 23:00
看来什么东西都有可能有出问题的一天。上次是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 & 在等待备份结束的时候,我抽空回公司干了点小活,最近我接手的项目接近尾声,也到了关键的时候,有很多事情需要沟通和处理。 正当我在公司忙得热火朝天的时候,又接到一个电话,丁工说:”程工,这次问题大了,我们的核心业务系统也出现问题了!你赶快过来一趟吧。“
- EMC 故障情况下ORACLE 救火行动(之一)
- EMC 故障情况下ORACLE 救火行动(之二)
- EMC 故障情况下ORACLE 救火行动(之三)
- EMC 故障情况下ORACLE 救火行动实践记录(之一)
- emc硬盘和sps故障
- 巡检结果(ORACLE EBS AIX EMC)
- Oracle之一键获取总体情况 动态
- AIX系统下RAC故障之一--CRS服务启动失败(coredump)
- (2010-06-06)oracle重启故障之一:ORA-01102: cannot mount database in EXCLUSIVE mode
- 依直觉采取行动(下)
- plsql配置(不安装oracle的情况下)
- Oracle之一键获取数据库总体情况 awr等报表
- Oracle之一键获取数据库总体情况 静态
- 电磁兼容性(EMC)
- EMC
- EMC
- EMC
- EMC
- linux下,自动telnet到远程主机上运行的脚本
- |与||的区别
- hibernate配置文件hibernate.cfg.xml的详细解释
- 日记0819
- NCRE-引言
- EMC 故障情况下ORACLE 救火行动(之一)
- NCRE-数据库应用系统生命周期
- tput 指令入門
- 有限元法,有限差分法和有限体积法的区别
- 列表树递归无限分级
- 定点c程序之二:定点加减法
- Java I love you
- AspNetPager使用方法
- Lucene