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

最近一个生产库挂了

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

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

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

这是一则生产环境的真实维护过程,由于RAC的测试环境空间不足,因此规划给

ASM扩展空间,然而在给ASM添加新的磁盘空间时又出现了故障,这类问题在很多

用户的生产环境中可能也会遇到

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

在RAC环境的节点1上启动了DBCA工具来管理ASM设备;

由于新增的裸设备在ASM图形界面下看不到;

通过root用户将裸设备的访问权限授予了操作系统上的Oracle用户;

这时,从图形界面的候选磁盘中已经可以看到这些裸设备了;

通过图形界面将裸设备加到了磁盘组中。

 

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

 

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

ORA-15032: not all alterations performed

原因: 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

原因: 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

成功: disk DISK_0017(17.4042303525) added to diskgroup DISK

成功: disk DISK_0018(18.4042303520) added to diskgroup DISK

成功: disk DISK_0019(19.4042303521) added to diskgroup DISK

成功: disk DISK_0020(20.4042303522) added to diskgroup DISK

成功: disk DISK_0021(21.4042303523) added to diskgroup DISK

成功: disk DISK_0022(22.4042303524) added to diskgroup DISK

Thu Mar 29 17:29:45 2007

成功: diskgroup DISKwas dismounted

成功: diskgroup DISKwas dismounted

Thu Mar 29 17:29:46 2007

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

现在-00202: control file:’+DISK/testrac/control01.ctl

ORA-15078: ASM diskgroupwas forcibly dismounted

Thu Mar 29 17:29:46 2007

柠檬水: terminating instancedue to error 204

Thu Mar 29 17:29:46 2007

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

现在-00204: error in reading(block , # 块 ) 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:

现在-00204: error in reading(block , # 块 ) of control file

Thu Mar 29 17:29:46 2007

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

现在-00204: error in reading(block , # 块 ) 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:

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

Thu Mar 29 17:29:47 2007

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

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

Thu Mar 29 17:29:47 2007

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

现在-00204: error in reading(block , # 块 ) of control file

Thu Mar 29 17:29:52 2007

Instance terminated by LMON, pid = 2789

 

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

$ sqlplus “/ 作为sysdba”

已连接到空闲例程

的SQL> 启动

现在-01078: failure inprocessing system parameters

现在-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

现在-01034: ORACLE notavailable

ORA-27101: shared memory realm does not exist

SVR4 Error: 2: No such file or directory

 

那么到底是怎么回事呢?如果仔细一行一行来分析告警日志其实这时alert文件中已经

明显包含了导致错误的原因

成功: diskgroup DISK was dismounted

成功: diskgroup DISK was dismounted

Thu Mar 29 17:29:46 2007

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

现在-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:

现在-00204: error in reading(block 35, # 块 1) of control file

现在-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:

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

Thu Mar 29 17:29:47 2007

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

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

Thu Mar 29 17:29:47 2007

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

现在-00204: error in reading(block , # 块 ) 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

原因: 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 个字节

固定尺寸 2030296 个字节

可变大小 503317800 个字节

数据库缓冲区 1627389952 个字节

重做缓冲区 14745600 个字节

现在-00205: ?????????, ??????, ???????

 

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

现在-00205: error in identifying control file, check alert log for more info

原因: 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实例问题解决

$ 它的 –

Password:

Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad6s1

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad6s3

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad6s4

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad6s5

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad6s6

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad6s7

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad7s1

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad7s3

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad7s4

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad7s5

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad7s6

# 甲骨文:oinstall/dev/rdsk/c2t500601603022E66Ad7s7

$ sqlplus “/ assysdba

的SQL> shutdown

现在-01507: 未装载数据库

ORACLE 例程已经关闭

 

$ srvctl stop asm -nracnode2

$ srvctl start asm -nracnode2

$ sqlplus “/ assysdba

已连接到空闲例程

的SQL> 启动

ORACLE 例程已经启动

Total System Global Area 2147483648 个字节

固定尺寸 2030296 个字节

可变大小 469763368 个字节

数据库缓冲区 1660944384 个字节

重做缓冲区 14745600 个字节

数据库装载完毕

数据库已经打开

本来很简单的一个问题却大费周折这个教训说明解决问题的时候须冷静地分析和判断

否则很容易被一些其他的信息干扰而误入歧途从而导致在解决问题时走上弯路

尤其是如果在误入歧途的过程中执行了破坏性或不可逆转的操作则可能产生运维

事故由此可见DBA在诊断分析和处理问题时保持头脑的清醒和冷静是多么的重要

与DBA朋友们共勉

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

发表评论