转：RAC-添加磁盘不当导致的故障

最近一个生产库挂了

数据库挂了的原因是因为数据库的文件系统对应的磁盘全部掉了，但是看到后台日志

ORA-00204这个错误，还是百度了一下看到杨长老的文章，于是收入到自己博客，

下面的故障时在RAC下面添加磁盘不当导致数据库宕了。

这是一则生产环境的真实维护过程，由于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 files

that 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朋友们共勉。

原文： https://blog.csdn.net/qq_34556414/article/details/80844431