处理因ASM实例异常导致RAC第一节点实例异常终止故障

简介:
 遭遇RAC第一节点实例由于ASM实例异常导致数据库实例非正常停止,记录在此。

1.故障现象
两节点RAC第一节点实例停止,经检查ASM实例亦异常终止

2.故障分析
检查数据库实例及ASM实例的的alert寻找处理思路。
1)alert日志内容
Sun May  8 06:59:06 2011
Errors in file /oracle/app/oracle/admin/racdb/bdump/racdb1_asmb_21478.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Sun May  8 06:59:06 2011
ASMB: terminating instance due to error 15064
Sun May  8 06:59:06 2011
Errors in file /oracle/app/oracle/admin/racdb/bdump/racdb1_lms1_21275.trc:
ORA-15064: communication failure with ASM instance
Sun May  8 06:59:06 2011
Errors in file /oracle/app/oracle/admin/racdb/bdump/racdb1_lgwr_21283.trc:
ORA-15064: communication failure with ASM instance
Sun May  8 06:59:06 2011
Errors in file /oracle/app/oracle/admin/racdb/bdump/racdb1_lms0_21271.trc:
ORA-15064: communication failure with ASM instance
Sun May  8 06:59:06 2011
Errors in file /oracle/app/oracle/admin/racdb/bdump/racdb1_lmon_21267.trc:
ORA-15064: communication failure with ASM instance
Sun May  8 06:59:06 2011
Errors in file /oracle/app/oracle/admin/racdb/bdump/racdb1_lmd0_21269.trc:
ORA-15064: communication failure with ASM instance
Sun May  8 06:59:06 2011
System state dump is made for local instance
System State dumped to trace file /oracle/app/oracle/admin/racdb/bdump/racdb1_diag_21263.trc
Sun May  8 06:59:06 2011
Errors in file /oracle/app/oracle/admin/racdb/bdump/racdb1_mman_21279.trc:
ORA-15064: communication failure with ASM instance
Sun May  8 06:59:07 2011
Shutting down instance (abort)
License high water mark = 7
Sun May  8 06:59:07 2011
Trace dumping is performing id=[cdmp_20110508065906]
Sun May  8 06:59:11 2011
Instance terminated by ASMB, pid = 21478
Sun May  8 06:59:12 2011
Instance terminated by USER, pid = 4110
Mon May  9 13:44:05 2011

2)trace文件中截取到如下故障内容
kjctseventdump-end tail 14 heads 0 @ 0 14 @ -1115894656
 DEFER MSG QUEUE ON LMS1 IS EMPTY
 SEQUENCES:
  0:0.0  1:2933.0
error 15064 detected in background process
ORA-15064: communication failure with ASM instance

3)ASM日志中记录了如下内容
Thu Feb 10 19:17:58 2011
NOTE: cache recovered group 1 to fcn 0.20162635
Thu Feb 10 19:17:58 2011
NOTE: opening chunk 1 at fcn 0.20162635 ABA
NOTE: seq=79 blk=1597
Thu Feb 10 19:17:58 2011
NOTE: cache mounting group 1/0xBA97DAE1 (ORADATA) succeeded
SUCCESS: diskgroup ORADATA was mounted
Thu Feb 10 19:18:01 2011
NOTE: recovering COD for group 1/0xba97dae1 (ORADATA)
SUCCESS: completed COD recovery for group 1/0xba97dae1 (ORADATA)
Thu Feb 10 19:18:01 2011
Starting background process ASMB
ASMB started with pid=17, OS id=7767
Thu Feb 10 19:21:06 2011
NOTE: ASMB process exiting due to lack of ASM file activity
Sun May  8 06:48:33 2011
Shutting down instance (abort)
License high water mark = 6
Instance terminated by USER, pid = 20819

初步判断是由于ASM出现异常导致的此次故障。但是和这里的提示“NOTE: ASMB process exiting due to lack of ASM file activity”没有关系。这个提示仅仅是一个提示而已,在ASM日志中的其他地方也有多次出现。

3.尝试故障处理
1)尝试启动ASM无果。

2)手工启动ASM实例可以成功
racdb1@racdb1 /home/oracle$ export ORACLE_SID=+ASM1
+ASM1@racdb1 /home/oracle$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Sun May 8 13:43:06 2011

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters and Data Mining options

NotConnected@> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown
NotConnected@> startup;
ASM instance started

Total System Global Area  130023424 bytes
Fixed Size                  2071000 bytes
Variable Size             102786600 bytes
ASM Cache                  25165824 bytes

3)但启动数据库实例时抛出“ORA-01105”和“ORA-38767”错误。
racdb1@racdb1 /home/oracle$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Sun May 8 13:43:53 2011

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

Connected to an idle instance.

NotConnected@> startup;
ORACLE instance started.

Total System Global Area 8388608000 bytes
Fixed Size                  2086096 bytes
Variable Size            1644170032 bytes
Database Buffers         6727663616 bytes
Redo Buffers               14688256 bytes
ORA-01105: mount is incompatible with mounts by other instances
ORA-38767: flashback retention target parameter mismatch

4.再次尝试故障处理
对除VIP之外的CRS资源进行重启,此时仍然无法启动ASM实例和数据库实例。

5.最后的处理方法
最后尝试重启第一个节点的所有CRS资源,终于将RAC的第一个节点的所有资源启动完毕。

6.小结
通过一系列的故障处理尝试,最终恢复了RAC数据库故障。

Good luck.

secooler
11.05.08

-- The End --




本文转自einyboy博客园博客,原文链接:http://www.cnblogs.com/einyboy/archive/2012/08/23/2651960.html,如需转载请自行联系原作者。

目录
相关文章
|
Oracle 关系型数据库 数据库
一次解决RAC实例状态为“Stuck Archiver”的经历
一个客户反映Oracle数据库恢复后,有一个数据文件报错
327 0
|
2月前
|
存储 Oracle 关系型数据库
数据库数据恢复—Oracle ASM磁盘组故障数据恢复案例
Oracle数据库数据恢复环境&故障: Oracle ASM磁盘组由4块磁盘组成。Oracle ASM磁盘组掉线 ,ASM实例不能mount。 Oracle数据库故障分析&恢复方案: 数据库数据恢复工程师对组成ASM磁盘组的磁盘进行分析。对ASM元数据进行分析发现ASM存储元数据损坏,导致磁盘组无法挂载。
|
7月前
|
存储 Oracle 关系型数据库
RAC创建ASM磁盘组时配置多路径和UDEV
RAC创建ASM磁盘组时配置多路径和UDEV
1452 7
|
7月前
|
文字识别 运维 Oracle
asm 磁盘故障处理日志
asm 磁盘故障处理日志
66 2
RAC 增加4块 asm 磁盘
增加磁盘之前的asm状态
|
Oracle 关系型数据库 测试技术
GoldenGate 对asm磁盘的访问的两种方式:asm实例连接和API(dblogreader)两种方式的对比
GoldenGate在抽取数据的时候要读取online redo里的数据,online redo很多时候是储存在asm磁盘里,对asm磁盘的访问有两种方式
190 0
|
Oracle 关系型数据库 数据库
RAC中,控制文件的快照文件必须能够被所有节点的数据实例访问到 ORA-00245
RMAN在使用控制文件备份的时候,备份开始点需要最新的检查点信息以及文件头信息。
115 0
利用访问日志在ASM中定位异常延迟问题
阿里云服务网格ASM会在工作负载中注入Sidecar以实现对流量劫持,并按照用户的配置对流量进行修改、路由。因此,Sidecar处理和转发带来的额外时间开销会导致请求的延迟有一定的增长。除延迟方面的影响外,在节点性能充足的情况下,Sidecar通常不会对并发能力有显著的影响。本文将介绍利用访问日志在服务网格ASM中排查耗时异常的通用方法和思路。  一、在请求路径上确定耗时异常的组件 查看访问日志中
105 0
|
运维 负载均衡 Kubernetes
阿里云服务网格ASM网关与应用型负载均衡实例ALB集成
背景阿里云服务网格ASM可以简化服务治理,保障服务间通信的认证安全以及提供网格可观测性能力等需求,降低开发与运维的工作负担。对于网络插件类型为Terway的阿里云容器服务 ACK集群作为数据面集群的场景,阿里云服务网格ASM支持集成应用型负载均衡实例(ALB)。前提条件创建阿里云服务网格ASM企业版实例。创建网络插件类型为Terway阿里云容器服务 ACK实例。ACK实例的CCM(Cloud Co
351 0
阿里云服务网格ASM网关与应用型负载均衡实例ALB集成
|
监控 NoSQL Java
ASM字节码编程 | 用字节码增强技术给所有方法加上TryCatch捕获异常并输出!
最简单粗暴的可能就是硬编码在方法中,收取执行耗时以及出入参和异常信息。但这样的成本实在太大,而且有一些不可预估的风险。 可以选择切面方式做一套统一监控的组件,相对来说还是好一些的。但也需要硬编码,同时维护成本不低。 市面上对于这样的监控其实是有整套的非入侵监控方案的,比如;Google Dapper、Zipkin等都可以实现,他们都是基于探针技术非入侵的采用字节码增强的方式进行监控。
439 0
ASM字节码编程 | 用字节码增强技术给所有方法加上TryCatch捕获异常并输出!