1.故障现象和描述

1.1 相关信息

16号17时，由于专网1的Rac数据库宕机，导致程序故障，数据无法上传至专网1数据库，影响同步到内网2，业主业务数据受到影响。

最近周末生产平台的Rac数据库宕机，专网 RAC数据库 （数据库集群双机热备）连接报错，如图表1.1所示

图1.1

1.2 故障现象描述

查看Rac数据库的状态，其中ora.rac01.ons节点和ora.rac02.on和ora.wxpt.db节点处于OFFINE状态。

根据手册重启数据库实例和节点,其中ora.rac01.ons 节点和 ora....SM1.asm节点启动失败，多次尝试都是失败。如下图表1.2.1、1.2.2、1.2.3、1.24所示

图表2.2.1 图表1.2.2 图表1.2.3 图表1.2.4

2.故障分析和解决

2.1 故障解决方案

1.     根据手册，关闭-启动数据库节点，多次尝试其中ora.rac01.ons 节点 和ora....SM1.asm

和ora.rac02.ons 节点 和ora....SM2.asm 节点无法启动成功。

2.   RAC节点出现故障，排查从系统时间、日志空间、共享盘三个方面分析。

本次故障处理，对监听日志做了查看，发现监听日志超过了4G,决定备份监听日志，重建日志空间

日志的路径：

/app/oracle/product/10.2/db/network/log/

查看日志大小

ls -l /app/oracle/product/10.2/db/network/log/

重建日志命令

su -oracle

lsnrctl set log_status off

mv listener_rac01.loglistener_rac01.log.back.20200815

lsnrctl set log_status on

       清除监听日志，再根据手册步骤重启数据库，ora....SM1.asm 可以ONLINE，ora.rac01.ons多次启动失败。查看CPU占用情况，发现ons节点占用过高，CPU负载

决定重启Rac服务器，192.168.2.45的服务器系统启动长时间无响应，机房手动重启后成功。

2.2 数据库CPU过载

图2.2.1 图2.2.2

Rac1数据库的CPU负载查看，从2020.8.15号下午7点之后开始CPU过载，如图2.2.1 所示。

正常数据库负载率为34%左右，如图2.2.2是8月14号的CPU平均负载率

图2.2.3 图2.2.4

Rac2数据库的CPU负载查看，从2020.8.15号下9点之后开始CPU过载，如图2.2.3所示

正常数据库负载率为50%左右，如图1.2是8月14号的CPU平均负载率

 

2.3 DBA解决方案

2.3.1重数据库相关命令

（oralce 11.2g）

数据库osn和Asm节点 offline 状态

su – grid

which crsctl

看下路径

然后用root 用户，crsctl stop crs -f 

再crsctl start crs

常用命令

ps -ef|grep

d.bin

more /etc/passwd

(oracle 10.2 g)本次事故使用下面的命令解决

root 用户

find / -name crsctl 查看crsctl执行命令

find / -name crs_stop  查看命令路径 + all (crs_stop-all)

find / -name crs_start  查看命令路径 + all (crs_start -all)

根据DBA给命令8月16日10时恢复数据库，所有节点ONLINE

2.3.2 日志分析

导出oralce 的awr运行日志：

sqlplus '/as sysdba'

@?/rdbms/admin/awrrpt;

发现有部分snapId 节点缺失（如图2.3.2所示）

图表2.3.2.1

说明oralce 10.2g的数据库运行存在不正常的情况。

分析oralce 的alert 和bdump日志

/app/oracle/admin/wxpt/bdump/alert_rac01

/app/oracle/admin/wxpt/bdump/wxpt1_lgwr_29362.trc

/app/oracle/admin/wxpt/bdump/wxpt1_lmd0_29338.trc

/app/oracle/admin/wxpt/bdump/wxpt1_lms0_29340.trc

3.故障原因和结论：

DB给出结论Rac的其中一个节点因为Bug（内部报错） 导致数据库的核心进程挂掉，导致了这次的宕机现象。（如图3.1所示）

图3.1

分析日志发现16年到今天共计发生过59次这种情况，除了这次，最近的是7月12日，但是没有导致核心进程挂掉。

由于数据库版本较老，DB无法找到具体BUG。

不考虑官方服务的话，建议升级数据库使用版本11.2.0.4g。

数据库升级工作量较大，涉及到业务测试等。