资讯专栏INFORMATION COLUMN

RAC双节点crash回复一例

IT那活儿 / 1288人阅读
RAC双节点crash回复一例

客户现场两节点库crash告警。运维人员紧急将数据库拉起,应用恢复。但启动后alert log 报错ORA-16191和ORA-01031,为DataGuard主备库密码文件不一致所致, 重建密码文件后, 故障解决。

 分析alert log发现:16:32,节点1读取控制文件发现坏块,紧接着16:33分实例无法正常读取控制文件导致crash,然后实例2在16:35关闭。经检查控制文件并未存在坏块,初步判定为数据库短暂读取控制文件失败导致BUG。 

发起SR,经SSC人员及SR后台专家共同确认为bug 11698676,该bug与bug  9549042为重复bug,并在patch 9549042上被fixed。 

2. 故障分析/处理

2.1 故障处理 

  4月5日16:34, ssyy库两节点相继crash, 紧急接入后确认两实例已被彻底关闭、监听仍然开启,紧急startup将两实例拉起,应用恢复连接至生产库。

  重启实例后,检查节点1 alert log 发现: 

Check that the primary and standby are using a password file

and remote_login_passwordfile is set to SHARED or EXCLUSIVE, 

and that the SYS password is same in the password files.

returning error ORA-16191

    提示为SYS主备库上密码文件不一致导致, 于是决定主库重建密码文件,并将新生成的密码文件拷至备库节点应用(操作前备份原密码文件,并更改主库SYS密码).

  分别在primary-rac两个节点上执行密码文件创建语句.

orapwd file=/oracle/db/oracle/product/11.1.0/db/dbs/ssyydb1 entries=5 force=y  password=*********

orapwd file=/oracle/db/oracle/product/11.1.0/db/dbs/ssyydb2 entries=5 force=y  password=*********

       分别将ssyydb1和ssyydb2依次拷至standby-rac节点1和节点2.   

  primary-rac1节点alert log 仍持续报错:

Errors in file /oracle/db/diag/rdbms/ssyy/ssyy1/trace/ssyy1_arc2_4134.trc:

ORA-01031: insufficient privileges

PING[ARC2]: Heartbeat failed to connect to standby drdb. Error is 1031.

     此时,主库节点1无法向备库节点1传送archive log. 查询MOS,ORA-01031仍为主备库密码文件不一致导致,怀疑主库归档进程使用了主机缓存密码文件导致,因归档进程为非关键进程,kill -9 后会重新启动,对当前数据库无影响。 

  依次kill主库节点1和节点2所有归档进程,节点1仍持续报错ORA-01031。

  sqlplus连接确认主备库上SYS密码已更改.

  检查新生成的密码文件是否已被应用:

--主库节点

SQL> select * from  v$pwfile_users;

USERNAME                       SYSDB SYSOP SYSAS

------------------------------ ----- ----- -----

SYS                            TRUE  TRUE  FALSE

--备库节点

SQL> select * from  v$pwfile_users;

no rows selected

     显然,主库密码文件已被应用,备库密码文件未被应用。

     仔细检查备库密码文件, 文件名未满足orapw<$ORACLE_SID>命名规则, 密码文件沿      用主库密码文件,但备库实例名区别于主库实例名。

     修改备库密码文件名:

mv $ORACLE_HOME/dbs/ssyydb1 $ORACLE_HOME/dbs/orapwdrdb1 

mv $ORACLE_HOME/dbs/ssyydb2 $ORACLE_HOME/dbs/orapwdrdb2

     持续观察几分钟,ORA-01031错误未解决. 

  查询MOS,参照ORA-1031 for Remote Archive Destination on Primary (Doc ID 733793.1)解决方案操作.

1. Make sure parameter REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE or SHARED in both databases.  


2. Copy the password file again from primary : 


a. Defer the log_archive_dest_2 on primary: 

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = DEFER; 


b. Copy/ftp the password file from primary to standby and rename it accordingly on the standby database. Creating the password file on standby with orapwd-utility is not supported for 11g anymore.

Make sure that name of password file on both primary and standby is : orapw. Name of the password file is case sensitive. If SID of database on standby is prod then name of the password file should be orapwprod, orapwPROD will not work. 


c. Enable the log_archive_dest_2 on primary: 

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE; 


d. Switch 2-3 log files on primary : 

SQL> ALTER SYSTEM SWITCH LOGFILE; 


e. Check the status of log_archive_dest_2 on primary. 

SQL> SELECT STATUS,ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID =2; 

STATUS    ERROR 

--------- ----------------------------------------------------------------- 

VALID 

     持续跟踪主库节点alert log ,在持续ORA-01031报错3-5分钟后, 主库节点均能正常向备库节点传送archive log,备库实例也能正常应用archive log, 主库节点1和节点2 alert log 也未曾重现ORA-01031和ORA-16191.

     至此,故障全部解决! 

2.2 crash分析 

    

    首先,检查两节点syslog,无异常,排除主机因素。

     实例1 alert log:

Fri Apr 05 15:58:52 2013

Archived Log entry 34220 added for thread 1 sequence 12072 ID 0x9441c6d1 dest 1:

Fri Apr 05 16:32:39 2013

Read from controlfile member /dev/oravg/rlv_cntl1 has found a corrupted block (blk# 4, cf seq# 0)

Hex dump of (file 0, block 4) in trace file /oracle/db/diag/rdbms/ssyy/ssyy1/trace/ssyy1_lmon_22418.trc

Corrupt block relative dba: 0x00000004 (file 0, block 4)

Bad check value found during control file block read

Data in bad block:

type: 21 format: 2 rdba: 0x00000004

last change scn: 0x0000.00000000 seq: 0x1 flg: 0x04

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail: 0x00001501

check value in block header: 0x8f5d

computed block checksum: 0x2

Re-read from controlfile member /dev/oravg/rlv_cntl1 returned valid block 4

Hex dump of (file 0, block 4) in trace file /oracle/db/diag/rdbms/ssyy/ssyy1/trace/ssyy1_lmon_22418.trc

Errors in file /oracle/db/diag/rdbms/ssyy/ssyy1/trace/ssyy1_lmon_22418.trc:

ORA-00202: control file: /dev/oravg/rlv_cntl1

Errors in file /oracle/db/diag/rdbms/ssyy/ssyy1/trace/ssyy1_lmon_22418.trc  (incident=888259):

ORA-00227: corrupt block detected in control file: (block 4, # blocks 1)

ORA-00202: control file: /dev/oravg/rlv_cntl1

Incident details in: /oracle/db/diag/rdbms/ssyy/ssyy1/incident/incdir_888259/ssyy1_lmon_22418_i888259.trc

Fri Apr 05 16:33:24 2013

Errors in file /oracle/db/diag/rdbms/ssyy/ssyy1/trace/ssyy1_lmon_22418.trc:

ORA-00227: corrupt block detected in control file: (block 4, # blocks 1)

ORA-00202: control file: /dev/oravg/rlv_cntl1

LMON (ospid: 22418): terminating the instance due to error 227

     16:32:39,实例1在读控制文件/dev/oravg/rlv_cntl1的时候出错,发现坏块。

     16:33:24,实例1因无法正常读取控制文件导致实例crash。 

     检查三个控制文件,未发现坏块。

ssyy1: dbv file=/dev/datavg02/rlv_cntl1 blocksize=16384

ssyy1: dbv file=/dev/datavg02/rlv_cntl2 blocksize=16384

ssyy1: dbv file=/dev/datavg02/rlv_cntl3 blocksize=16384

     

     查看节点2 crsd.log: 16:35:23由于数据库异常offline,CRS停掉实例2.

2013-04-05 16:32:42.179: [  CRSRES][6345673] Resource recovery not purged:ora.ssyy.ssyy2.inst

2013-04-05 16:32:42.205: [  CRSRES][6345673] ora.ssyy.ssyy2.inst target set to OFFLINE before stop action

2013-04-05 16:32:42.206: [  CRSRES][6345673] StopResource: setting CLI values

2013-04-05 16:32:42.252: [  CRSRES][6345673] Attempting to stop `ora.ssyy.ssyy2.inst` on member `ssyy2`

2013-04-05 16:33:40.826: [    CRSD][54] SM: rE2Ec: 4

2013-04-05 16:33:40.896: [  CRSRES][6345681] ora.ssyy.db target set to OFFLINE before stop action

2013-04-05 16:33:40.896: [  CRSRES][6345681] StopResource: setting CLI values

2013-04-05 16:33:42.288: [    CRSD][6345681] SM:dE2Ec: all E2E cmds done. 0

2013-04-05 16:35:23.123: [  CRSRES][6345695] Resource recovery not purged:ora.ssyy.db

2013-04-05 16:35:23.124: [  CRSRES][6345695] `ora.ssyy.db` is already OFFLINE.

2013-04-05 16:35:23.173: [  CRSRES][6345673] Stop of `ora.ssyy.ssyy2.inst` on member `ssyy2` succeeded.

     

     初步怀疑为bug导致, 发起SR,经SSC人员及SR后台专家共同确认,命中bug 11698676。

     该bug与bug 9549042为重复bug, 在当前HP-UX Itanium 64 bit 平台下,有现成patch 9549042。

2.3 解决方案 

     官方建议,尽快打patch 9549042, 以规避此crash故障再现。


文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/130244.html

相关文章

  • ORACLE19C IPV4+IPV6栈配置实验

    点击上方IT那活儿公众号,关注后了解更多内容,不管IT什么活儿,干就完了!!!一背景为了满足海量地址分配需求,IPV6替代IPV4已成为必然。新部署的ORACLE数据库已经直接使用IPV6,已部署的ORACLE数据库也正在更改IPV4使用IPV6。数据库更改IPV4使用IPV6还涉及主机和客户端网络更改,如果同时实施所有网络更改,客户端多且网络比较复杂的环境,业务停机时间会很长从而影响业务正常使用...

    社区管理员 评论0 收藏0
  • ReactiveCocoa--RACDelegateProxy

    摘要:上面的代码片段就明确指定的会被执行。虽然这个类在实际使用中作用不大,但是在内部像都会用到其实这里我们也可以通过这样方法实现 基本信息 父类 NSObject 子类 无 类含义 RAC代理类 遵循的协议 无 属性 RACDelegateProxy *rac_delegateProxy; 参考vincenttsai 这个类平常...

    Hwg 评论0 收藏0
  • WKCrashSDK - crash拦截工具

    摘要:具备期发生的层级提示。这里划重点拦截时,存在部分三方库的不能拦截,以及系统的相机相册无需拦截,否则会出现无效的提示,在我的项目已经进行了白名单过滤。后续我会抽空将其加入豪华午餐注如从中直接拖入,则默认开启除了拦截外的其他种类型的拦截。 前言 由于线上始终出现部分未知原因崩溃问题,遂遵循网易出的crash拦截机制,自实现了一个crash拦截工具,现已上线运行数月,累计拦截闪退···总之很...

    silencezwm 评论0 收藏0
  • 【Mysql】mysql 基于GTID复制

    摘要:比传统复制更加安全。恢复备份,开启命令。全局和级别都可用,全局表示所有服务器拥有,级别表示当前拥有所有。基于的复制上面的设置并不适用于基于的复制。由于文件可能不完整,所以需要抛弃已接收的文件。 一、GTID的概述: 1、全局事物标识:global transaction identifieds。 2、GTID事物是全局唯一性的,且一个事务对应一个GTID。 3、一个GTID在一个服务器...

    mumumu 评论0 收藏0
  • Hadoop namenode高可用性分析:QJM核心源代码解读

    摘要:但有了副本就引入了新的问题,多个副本之间的一致性怎么保证,这是分布式存储必须解决的问题。关于作者彭荣新,上海欧电云信息科技有限公司架构师,个人对分布式存储,并发等底层相关的技术比较感兴趣,一直在学习的路上。 背景介绍HDFS namenode 在接受写操作时会记录日志,最早 HDFS 日志写本地,每次重启或出现故障后重启,通过本地镜像文件+操作日志,就能还原到宕机之前的状态,不会出现数据不一...

    琛h。 评论0 收藏0
  • DBASK问答集萃(2)

    摘要:新晋技术专家下面是墨天轮部分新晋的技术专家。大家可以点击往期阅读墨天轮技术专家邀请函了解详情,申请成为我们的技术专家,加入专家团队,与我们一起创建一个开放互助的数据库技术社区。新关联公众号墨天轮是一个开放互助的数据库技术社区。 引言 近期我们在DBASK小程序增加了数据库 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的专题栏目和一些新的技术...

    liuchengxu 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<