一波三折: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朋友们共勉。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-04-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

关于dblink锁定带来的问题(r3笔记第20天)

可能在一些分布式环境中,有一些数据访问都需要用到db link。从某种程度上来说dblink是很方便,但是从性能上来说还是有一些的隐患。如果两个环境之间的网络情...

2645
来自专栏杨建荣的学习笔记

dataguard中MRP无法启动的问题分析和解决(r5笔记第82天)

自己手头有一套dataguard环境,因为也有些日子没有用了,结果突然心血来潮准备启动起来学习一下,突然发现在敲了命令 recover managed stan...

2608
来自专栏小文博客

使用树莓派搭建最安全tor科学上网?

3123
来自专栏杨建荣的学习笔记

dg的奇怪问题终结和分区问题答疑 (r7笔记第77天)

今天来说几个问题,一个是对昨天《让我焦灼的四个问题》的升华,不能起博眼球的题目,技术分析给大家兜底了,你们看看有没有类似的问题。 还有几个小问题说说今天的感受和...

3365
来自专栏杨建荣的学习笔记

关于Oracle重启数据库的一个bug(r5笔记第50天)

关于drop database在oracle中是致命的操作,这个操作自己在测试环境中体验过,会完全删除数据文件,因此这个操作非常敏感但是实用性不强,不过话说过来...

3384
来自专栏杨建荣的学习笔记

关于segment的一个小问题

今天统计数据的时候,发现一个奇怪的小问题,通过segment去判断一个表的大小,然后查表的count,有一个表明明在,但是从segment里面去查的时候查不出来...

3378
来自专栏杨建荣的学习笔记

停止数据库没有响应的问题分析(r9笔记第51天)

昨天写了一篇停库没有响应的问题分析,其实对于我来说,还是有些不太踏实,里面有几点需要改进。 因为是测试环境,所以操作的时候就随意了一些,如果是生产环境,直接ki...

3174
来自专栏杨建荣的学习笔记

Data Guard实现故障自动切换(二)(r11笔记第40天)

今天下午我的一个朋友碰到了一个Data Guard的问题,大体是主备网络出现问题,因为环境中配置了自动切换,结果备库就自动切换为了主库,这样就成了“双主”...

34510
来自专栏杨建荣的学习笔记

dataguard switchover的自动化脚本实现 (r5笔记第48天)

data guard的主要功能就是作为备库来同步主库的数据变化,一般使用中物理standby使用的比较多。data guard显示威力的一个场景就是switho...

3385
来自专栏施炯的IoT开发专栏

Windows 10 IoT Serials 2 - Windows 10 IoT RTM 升级教程

    7月29日,微软推出了Windows 10 for PC的正式版,其版本号是Build 10240。近两天官方说已经有4700万的下载安装量,同时这个数...

2227

扫码关注云+社区