10:50分左右，REMS2系统发出系统性能告警，1套RAC的Active Session数量超过了200……
收到告警之后，甲方DBA专家进入战位，查找原因。可是——现在的Active Session数量已经恢复了，往事不可追啊……
REMS2 DPA出场～
查看故障时间段，Active Session变化情况：

大概从10:48左右，Active Session持续增高，到10:53之后，由大概200左右，迅速恢复正常。我们使用DPA的BST History功能模块，查看问题最严重时，系统的Active Session都在干什么……

可以发现，多个会话，在执行SQL ID为appfxqvj6scuv的SQL，因为无法获取enq：TM而被堵塞，这些会话本身又堵塞了其他的会话。
Oracle中，一个DML操作，除了会以独占模式持有行级别的TX锁外，还需要持有表级别TM锁的共享模式，以防止在DML过程中，表的结构定义被修改（关于Oracle Enqueue、Lock机制此处不做过多描述）。现在这些会话无法获取到共享模式的TM锁，那说明什么？ 说明TM锁被别的会话以独占模式持有，还没有释放……
到这里，已经很清晰了，有人在业务高峰时期做了DDL操作，那么是改了表结构、还是建了索引呢？
使用DPA的Top SQL模块，检查一下该时间段的SQL操作，如果有DDL操作，应为肯定耗时较长，会被记录下来……

再次轻松几分钟诊断故障原因！ 哦耶