Smon死锁引发的数据库宕机

由于alert日志中出现大量的row cache enqueue lock等待，并且数据库中存在大量的建表删表操作， 因此运维人员判断可能是因为ID2319957.1- Sessions Hang on "row cache lock" (dc_objects) While Creating & Dropping a Table Concurrently导致数据库hang死，但因为客户的数据库环境row cache lock告警在alert中一直是频繁存在的，因此客户并不信任分析结果，因此便有了这次故障分析的案例。 

根据客户的描述，简单将故障当天情景重现：

故障当天早上8点10，客户应用侧反映系统健康运行时长及在线用户数指标中断。

8点30发现部分应用侧节点出现HTTP无法访问告警。

8点38发现系统登录页面可以正常访问，但登录失败。

8点47接到数据库运维人员通知，发现数据库出现大量活动会话，但数据库处于hang死状态，运维人员请求重启数据库。

9点20数据库重启完毕。

9点21重启各个业务节点，9点38业务节点重启完毕，业务恢复正常。

原因分析：

根据客户提供的alert日志、ssd trace文件以及数据库版本：10.2.0.5，我们分析原因如下：

21日6点40，数据库运行遇到BUG(Bug 11738097 CHECKPOINT NOT HAPPENING AND SMON PROCESS HUNG WITH WAIT EVENT 'ENQ: RO - FAST), SMON出现ENQ: RO自死锁（同一会话之间出现不正常的死锁），导致CHECKPOINT无法正常进行。8点06分，数据库实例1出现日志切换（LOG FILE SWITCH），由于CHECKPOINT未完成，因此LOG FILE SWITCH无法完成，在系统日志出现：

Thu Mar 21 08:06:24 CST 2019

Thread 1 cannot allocate new log, sequence 256000

Checkpoint not complete

  Current log# 2 seq# 255999 mem# 0: /oradata/CWGKVPD/redo2_1

  Current log# 2 seq# 255999 mem# 1: /oradata/CWGKVPD/redo2_2

此时系统中的写操作均无法完成，等待日志切换完成。所有新会话无法连接到数据库，修改操作均无法完成。已经连上的会话可以进行只读操作。

综上所述，数据库BUG导致了CKPT无法正常完成检查点，最终导致日志切换无法正常完成，导致最终宕机。

详细分析过程如下：

第一步：将alert日志中出现ssd trace通过ASS生成可读性好的日志文件。

第二步：根据alert日志的中的告警时间点和我们已生成的ASS日志文件，可整理出如下时间序列的可疑事件表：

Alert告警信息	分析
1号节点03:16分出现kill session信息	Oracle自己主动将会话杀死，问题不大
1号节点03:42分出现WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=231告警并产生相关的ssd trace	通过生成的ASS日志文件，可发现3个可疑点： 5:  waiting for 'rdbms ipc message'    [Latch received-location:] 229:waiting for 'row cache lock'       [Rcache object=0x36f0c99e0,] 231:last wait for 'ksdxexeotherwait'   [Rcache object=0x36f0c99e0,]      Cmd: Create Table 经分析： 5号后台进程在等待DRM同步的相关消息，经确认，为正常情况。 229和231进程均在等待资源号为0x36f0c99e0的dc_objects的row cache lock，经确认，并不会影响系统的正常使用。
2号节点3点52分出现WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=127 告警并产生相关的ssd trace	通过生成的ASS日志文件，可发现6个可疑点: 15: waiting for 'rdbms ipc message' 16: waiting for 'enq: RO - fast object reuse'[Enqueue RO-00020010-00000001] 60: waiting for 'enq: RO - fast object reuse