RMS恢复-鲜为人知的坑

近期由于工作原因加上本人有些懈怠已经很久没有更新了。

前几天某同事做了一个在调试adg的时候做了一个很常规的切归档（alter system switch logfile；）操作，突然收到告警session飙升一千多，同时收到告警数据库断开，正值两会，精神一下绷起来了。经过一番查询和跟他沟通，确认了我们没有人为故障。

事情说在前面，故障发生在3月8日20:17-20:22。

检查这段时间的session，发现有些会话量级很高。

 用比较笨方法查看级联阻塞（这里举例）

 

 

 通过查看阻塞源为rms0进程，且等待事件为SGA: allocation forcing component growth。

查看rms trace 在20:17分在读取redo04，而这个redo04并非是20:17的active归档。

通过alter可以看到数据库listener在20:19分重启了，在21分恢复正常了。

 

 查询mos

 

当前数据库版本为12.2，rms等待事件为 SGA: allocation forcing component growth并且阻塞会话event为latch:shared pool ，确定触发bug31700234。原因是：前一天数据库重启过，重启完成之后rms进程用来恢复集群，而在此工作中阻塞了session，造成系统故障。

解决方案：

① set _buddy_instance=0 on all instances

② apply patch 31700234