EMC 故障情况下ORACLE 救火行动（之一）

最新推荐文章于 2021-04-14 19:41:27 发布

傻儿哥

最新推荐文章于 2021-04-14 19:41:27 发布

阅读量6.4k

点赞数

分类专栏： AIX STORAGE ORACLE 文章标签： emc oracle 数据库 file database action

本文链接：https://blog.csdn.net/csucxcc/article/details/5825075

版权

ORACLE 同时被 3 个专栏收录

106 篇文章 0 订阅

订阅专栏

AIX

45 篇文章 0 订阅

订阅专栏

STORAGE

24 篇文章 1 订阅

订阅专栏

看来什么东西都有可能有出问题的一天。上次是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#
---------- ------------------
        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>';

RECOVER TABLESPACE <tsname>;

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 &

在等待备份结束的时候，我抽空回公司干了点小活，最近我接手的项目接近尾声，也到了关键的时候，有很多事情需要沟通和处理。

正当我在公司忙得热火朝天的时候，又接到一个电话，丁工说：”程工，这次问题大了，我们的核心业务系统也出现问题了！你赶快过来一趟吧。“

傻儿哥

关注

0
点赞
踩
8

收藏

觉得还不错? 一键收藏
2
评论
EMC 故障情况下ORACLE 救火行动（之一）

看来什么东西都有可能有出问题的一天。上次是IBM的中端存储，这次是EMC的高端，DMX1500也会出现错误。而且涉及了oracle数据库应用。这次又有事情做了。DMX1500 的一块逻辑盘和热备盘同时发生错误。导致此逻辑盘和热备盘上对应的逻辑块同时不可访问。造成了主机存储方面的IO丢失。数据变得不一致了！一大早，就接到了**客户的电话，丁工和我说，他们的QBXT平台数据库突然无法访问了，报插入数据错误，之后他们的应用工程师再尝试启动数据库，数据库成功启动了，但是应用在插入数据的时候变得很慢，而且经常会报错：
复制链接

扫一扫