【每日一记9】+第11天 数据库死锁故障的分析过程

1. 背景概述
   监控告警频繁提示系统xx数据库死锁增长个数高于当前阈值_当前值1.00。下面是详细的故障分析诊断过程，以及详细的解决方案描述。

2. 故障分析
2.1 故障现象
    登录到系统，从数据库到alert日志可以发现的确存在很多ORA-60的信息，截取部分如下：

2.2 故障根源

  查看trc内容，发现是自身导致的阻塞，几个trc都类似，下面截取其中一个trc跟踪日志的关键内容：

    可以发现都是delete from tx_xxxx_xxxxx_xxxx这张表，死锁现象是Single resource deadlock，而且TYPE是TM，综合分析这种现象，大多就是外键没有索引导致。

进一步获取建表语句查看约束部分，发现只有主键，没有外键：

查询ZJY用户下所有存在外键的表：

  进一步分析，其中T8_BOND_ACC_XXXXXXX的外键就是引用了TX_XXXX_XXXXX_XXXX的主键ID列：

select dbms_metadata.get_ddl('TABLE','T8_BOND_ACC_XXXXXXX','ZJY') from dual;

REFERENCES "ZJY"."TX_XXXX_XXXXX_XXXX" ("ID") ON DELETE CASCADE ENABLE

2.3 故障处置

  业务闲时，在T8_BOND_ACC_XXXXXXX表的外键列TX_XXXXX_XXXX_ID上创建索引，再观察告警情况。

create index TX_XXXXX_XXXX_ID on T8_BOND_ACC_XXXXXXX(TX_XXXXX_XXXX_ID) online;

    虽然本次告警信息未发现其他表的全局死锁问题，但从Oracle的设计层面来看，建议在在所有7个表的外键列上都创建对应的索引，防止后续在其他表大量DML时出现同类问题。

此外，复盘的时候发现，trc跟踪日志的这一部分信息：

----------resource 0x5bf1f1c38----------------------

resname       : [0x11ecf][0x0],[TM][ext 0xfffdbbf8,0x0][domid 0x4]

这里的[0x11ecf]转换为10进制，就是对应的外键无索引对象的object_id。

每天学习一点点，每天进步一点点。

每天学习一点点，每天进步一点点。

每天学习一点点，每天进步一点点。

每天学习一点点，每天进步一点点。

每天学习一点点，每天进步一点点。

每天学习一点点，每天进步一点点。

每天学习一点点，每天进步一点点。

每天学习一点点，每天进步一点点。

每天学习一点点，每天进步一点点。