一波三折：DBA需要头脑冷清思路清晰解决故障以幸存

杨廷琨（yangtingkun）

云和恩墨 CTO

高级咨询顾问，Oracle ACE总监，ITPUB Oracle数据库管理版版主

这是一则生产环境的真实维护过程，由于RAC的测试环境空间不足，因此规划给ASM扩展空间，然而在给ASM添加新的磁盘空间时又出现了故障，这类问题在很多用户的生产环境中可能也会遇到。

空间扩展的操作步骤如下：

在RAC环境的节点1上启动了DBCA工具来管理ASM设备； 由于新增的裸设备在ASM图形界面下看不到； 通过root用户将裸设备的访问权限授予了操作系统上的Oracle用户； 这时，从图形界面的候选磁盘中已经可以看到这些裸设备了； 通过图形界面将裸设备加到了磁盘组中。

但是这个操作引发了两个错误：分别是ORA-15032和ORA-15075。

首先看看在Oracle官方文档上是如何描述这两个错误的：

ORA-15032: not all alterations performed Cause: At least one ALTER DISKGROUP action failed. Action: Check the other messages issued along with this summary error. ORA-15075: disk(s) are not visible cluster-wide Cause: An ALTER DISKGROUP ADD DISK command specified a disk that could not be discoveredby one or more nodes in a RAC cluster configuration. Action: Determine which disks are causing the problem from the GV$OSM_DISK fixedview. Check operating system permissions for the device and the storage sub-systemconfiguration on each node in a RAC cluster that cannot identify the disk.

其实ORA-15075错误中的信息已经足够明显了。根据这个错误进行分析应该就能很快找到问题的原因。但是由于发生了其他的意外，导致解决问题的方向发生了偏差。

这个错误导致了奇怪的现象：根据错误信息判断，操作已经失败了，但是检查发现这些裸设备在DBCA的ASM配置中已经可见了。

当正在检查这两个错误信息时，同事告诉我节点2上的实例连不上了。

通过操作系统命令检查发现数据库实例2已经关闭了，不过这个节点上的ASM实例仍然存在。

这个现象的怪异之处在于：对ASM的操作引起的错误，当前ASM实例没有出错，却有另外一个数据库实例被关闭。

检查alert文件如下，显著的信息显示是控制文件访问出错：

$ tail -500 alert*

List of nodes:

……

Thu Mar 29 17:25:36 2007

SUCCESS: disk DISK_0017(17.4042303525) added to diskgroup DISK

SUCCESS: disk DISK_0018(18.4042303520) added to diskgroup DISK

SUCCESS: disk DISK_0019(19.4042303521) added to diskgroup DISK

SUCCESS: disk DISK_0020(20.4042303522) added to diskgroup DISK

SUCCESS: disk DISK_0021(21.4042303523) added to diskgroup DISK

SUCCESS: disk DISK_0022(22.4042303524) added to diskgroup DISK

Thu Mar 29 17:29:45 2007

SUCCESS: diskgroup DISKwas dismounted

SUCCESS: diskgroup DISKwas dismounted

Thu Mar 29 17:29:46 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_lmon_2789.trc:

ORA-00202: control file:'+DISK/testrac/control01.ctl'

ORA-15078: ASM diskgroupwas forcibly dismounted

Thu Mar 29 17:29:46 2007

LMON: terminating instancedue to error 204

Thu Mar 29 17:29:46 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_pmon_2754.trc:

ORA-00204: error in reading(block , # blocks ) of control file

Thu Mar 29 17:29:46 2007

System state dump ismade for local instance

Thu Mar 29 17:29:46 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_lms1_2797.trc:

ORA-00204: error in reading(block , # blocks ) of control file

Thu Mar 29 17:29:46 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_lms0_2793.trc:

ORA-00204: error in reading(block , # blocks ) of control file

System State dumped totrace file /data/oracle/admin/testrac/bdump/testrac2_diag_2756.trc

Thu Mar 29 17:29:47 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_j001_677.trc:

ORA-00204: 读取控制文件时出错(块 , # 块 )

Thu Mar 29 17:29:47 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_j000_3675.trc:

ORA-00204: 读取控制文件时出错(块 , # 块 )

Thu Mar 29 17:29:47 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_rbal_2982.trc:

ORA-00204: error in reading(block , # blocks ) of control file

Thu Mar 29 17:29:52 2007

Instance terminated by LMON, pid = 2789

尝试重启系统，看看会产生何种错误信息，这一次看到的显示信息居然又是参数文件的读取错误：

$ sqlplus "/ as sysdba"

已连接到空闲例程。

SQL> startup

ORA-01078: failure inprocessing system parameters

ORA-01565: error in identifyingfile '+DISK/testrac/spfiletestrac.ora'

ORA-17503: ksfdopn:2Failed to open file +DISK/testrac/spfiletestrac.ora

ORA-15077: could notlocate ASM instance serving a required diskgroup

SQL> shutdown

ORA-01034: ORACLE notavailable

ORA-27101: shared memory realm does not exist

SVR4 Error: 2: No such file or directory

那么到底是怎么回事呢？如果仔细一行一行来分析告警日志，其实这时alert文件中已经明显包含了导致错误的原因：

SUCCESS: diskgroup DISK was dismounted

SUCCESS: diskgroup DISK was dismounted

Thu Mar 29 17:29:46 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_lmon_2789.trc:

ORA-00202: control file:'+DISK/testrac/control01.ctl'

ORA-15078: ASM diskgroupwas forcibly dismounted

Thu Mar 29 17:29:46 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_lmon_2789.trc:

ORA-00204: error in reading(block 35, # blocks 1) of control file

ORA-00202: control file:'+DISK/testrac/control01.ctl'

ORA-15078: ASM diskgroup was forcibly dismounted

ASM的磁盘组首先已经DISMOUNT了，所以后面对于ASM中文件的访问当然会出现问题，只不过我们在阅读日志时，注意力很容易被明显、易懂、熟悉的吸引，往往就忽略了真实的问题所在，这就是人的选择性注意力关注吧：

Errors in file /data/oracle/admin/testrac/bdump/testrac2_j001_677.trc:

ORA-00204: 读取控制文件时出错(块 , # 块 )

Thu Mar 29 17:29:47 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_j000_3675.trc:

ORA-00204: 读取控制文件时出错(块 , # 块 )

Thu Mar 29 17:29:47 2007

Errors in file /data/oracle/admin/testrac/bdump/testrac2_rbal_2982.trc:

ORA-00204: error in reading(block , # blocks ) of control file

Thu Mar 29 17:29:52 2007

Instance terminated by LMON, pid = 2789

看到这个ORA-204错误信息，想当然地认为这是导致问题的原因。

其实如果查看随后的启动报错信息就可以看出问题：

ORA-15077: could not locate ASM instance serving a requireddiskgroup。

Oracle官方文档对这个错误的描述为：

ORA-15077: could not locateASM instance serving a required diskgroup Cause: The instance failed to perform the specified operation because it could notlocate a required ASM instance. Action: Start an ASM instance and mount the required diskgroup.

在遇到这个案例时，还同时遭遇了另外一个思维陷阱：此前刚刚碰到一个Bug，这个Bug的关键报错信息恰好也是 ORA-17503: ksfdopn:2 Failed to open file +DISK/testrac/spfiletestrac.ora。于是忽略了以上的关键信息，而把关注点转移到Bug上，并认为这次碰到的问题可能和上次有关。

参数文件不能读取，怎么办呢？当时就去尝试使用本地pfile文件启动数据库：

SQL> startup pfile=/export/home/oracle/inittestrac2.ora

ORACLE 例程已经启动。

Total System Global Area 2147483648 bytes Fixed Size 2030296 bytes Variable Size 503317800 bytes Database Buffers 1627389952 bytes Redo Buffers 14745600 bytes

ORA-00205: ?????????, ??????, ???????

出现了报错后，又一次被误导，去检查ORA-00205报错信息。

ORA-00205: error in identifying control file, check alert log for more info Cause: The system could not find a control file of the specified name and size. Action: Check that ALL control files are online and that they are the same filesthat the system created at cold start time.

直到发现控制文件本身并没有问题—实例1一直正常运行。这时才意识到自己“误入歧途”。

仔细检查所有的报错信息以及导致错误产生的原因——添加磁盘组的操作，终于发现了问题的真正原因：当时在给裸设备授权的时候，只在节点1进行了授权，而没有在节点2进行授权，因此节点1上的DBCA配置的ASM实例可以成功地将裸设备加到磁盘组中，而在节点2上同样的操作由于缺少权限，导致了磁盘组DISMOUNT，最终导致了数据库实例的关闭。

于是在节点2上对裸设备进行授权，重启ASM实例，问题解决。

$ su -

Password:

Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s1

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s3

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s4

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s5

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s6

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad6s7

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s1

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s3

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s4

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s5

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s6

# chown oracle:oinstall/dev/rdsk/c2t500601603022E66Ad7s7

$ sqlplus "/ assysdba"

SQL> shutdown

ORA-01507: 未装载数据库

ORACLE 例程已经关闭。

$ srvctl stop asm -nracnode2

$ srvctl start asm -nracnode2

$ sqlplus "/ assysdba"

已连接到空闲例程。

SQL> startup

ORACLE 例程已经启动。

Total System Global Area 2147483648 bytes Fixed Size 2030296 bytes Variable Size 469763368 bytes Database Buffers 1660944384 bytes Redo Buffers 14745600 bytes

数据库装载完毕。

数据库已经打开。

本来很简单的一个问题却大费周折。这个教训说明解决问题的时候须冷静地分析和判断，否则很容易被一些其他的信息干扰而误入歧途，从而导致在解决问题时走上弯路。

尤其是，如果在误入歧途的过程中，执行了破坏性或不可逆转的操作，则可能产生运维事故。由此可见，DBA在诊断、分析和处理问题时，保持头脑的清醒和冷静是多么的重要。

与DBA朋友们共勉。