20180831 2018-08-31 10:21【严重】主机名:zjhzbjwgzhzg02,实例名:sdh2,等待事件:log file sync,平均每秒个数:271,数据库存在较多异常
20180831 2018-08-31 10:19【严重】主机名:zjhzbjwgzhzg01,实例名:sdh1,等待事件:gc buffer busy acquire,平均每秒个数:269,数据库存
20180831 2018-08-31 10:24【严重】主机名:zjhzbjwgzhzg02,实例名:sdh2,等待事件:log file sync,平均每秒个数:279.5,数据库存在较多异
20180831 2018-08-31 10:46【严重】主机名:zjhzbjwgzhzg01,实例名:sdh1,等待事件:read by other session,平均每秒个数:152,数据库存在
20180831 2018-08-31 10:52【严重】主机名:zjhzbjwgzhzg01,实例名:sdh1,等待事件:log file sync,平均每秒个数:172.5,数据库存在较多异
20180831 2018-08-31 10:49【严重】主机名:zjhzbjwgzhzg02,实例名:sdh2,等待事件:gc buffer busy acquire,平均每秒个数:324,数据库存
20180831 2018-08-31 10:49【严重】主机名:zjhzbjwgzhzg02,实例名:sdh2,等待事件:gc buffer busy acquire,平均每秒个数:324,数据库存
今天收到了一大堆告警短信,是一套RAC数据库,接下来进行处理。
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
可以看到这里的等待事件比较多严重的事件比如log file sync,gc buffer busy acquire/release
之后用top命令查看cpu使用率,看看是否有特别消耗cpu的语句导致的等待事件。
可以看到外部链接也不是特别多,CPU消耗的也不是特别严重,外部链接也不是特别多。
这个时候去数据库后台日志看看
可以看到在09.49的时候盘掉了,于是这个时候再去查盘。
可以看到盘掉了,于是将盘拉起来了。盘掉了不会导致集群和数据库宕掉。
盘挂上去之后再去查看等待事件,发现等待事件减少了不少,和存储那边的人确认了一下确实是存储有问题导致的掉盘。
可以从上面看出,有些等待事件并不是劣质SQL语句导致的,可能是数据库故障导致的。