一次enq: TX - index contention等待事件处理

收到告警短信：

BOMC一般告警,告警2次,最后告警时间：03-03 22:21,监控对象：/XX系统/数据库/ORACLE数据库/XXX.XX.XX.XX*XXXDB_LE_DBS/ORACLE实例/XXX.XX.XX.XX*XXXDB2_LE_DBS,告警内容:实时检查,ip:XXX.XX.XX.XX,程序长时间持有锁数量大于1,当前值为2[BOMC]

一般数据库存在锁为正常情况，也可判断为瞬时值，但是持续收到三次的告警信息，于是登录数据库检查一下情况。

检查数据库等待事件：

查看到涉及到相同的SQL语句，等待事件为enq: TX - index contention，请求模式为4，并且与gc cr块争用（Gc cr request 表示2节点中访问的数据并不在本地缓存中，需要从1节点的缓存中读取并传输到本地的过程引起的一致性读等待）。

查看到SQL语句是插入数据事务操作，咨询相关人员每天为定时插入数据操作，并且确认存在业务堆积情况，首先确认可以先杀该会话。

杀完会话后，还是持续有会话连接进来，并且涉及等待时间同上面一致。

对于mos上面对enq: TX - index contention等待事件的解释（Troubleshooting 'enq: TX - index contention' Waits (文档 ID 873243.1)）：

一般出现在对表的高并发的DML操作时，当一个事务需要向一个索引块插入数据时，该索引块正好发生了索引分裂，则插入事务需要等待分裂事务；

或者采取更简便的方法，收集问题时段的AWR报告，检查部分指标：

紧急处理：

a)     降低应用并发度，降低index争用；

b)     使用反向索引重建，或使用hash分区重建索引；

c)     如索引字段使用sequence，可考虑增加sequence cache来增加键值跳度避免争用。

根据上面的思路，通过SQL_TEXT语句定位涉及该等待事件的对象，查询是否有其他的会话对这个对象高并发操作：

既然当前还是存在等待事件，那么直接通过视图查询信息：

查找正在执行的对象信息
select sid,serial#,sql_id,machine,program,status from v$session where sql_id in(select sql_id from v$sql_plan where OBJECT_NAME=upper('XXXX_201803'));

通过对象定位，可以看到节点1开启并行度为10对这个表进行删除数据，且根据参数CPU该并行度也存在不合理设置，并且program为sqlplus发起的语句会话。可以判断出是人为操作或者是定时任务运行该语句。同时可以在主机层面发现存在多个ora_p进程，可以反向定位SQL.

咨询该业务人员，该操作为清理历史数据部署的定时任务脚本。说明情况及KILL的风险后确认可以对该会话KILL。

根据实际业务注意评估回滚事务相关信息，加快回滚速度参数FAST_START_PARALLEL_ROLLBACK = HIGH，undo信息。

业务侧kill该会话，数据库KILL会话。对这个会话进行处理后，节点二的enq: TX - index contention等待时间消失，业务反馈没有延迟情况。

虽然该等待事件已经处理了，但是从SQL语句看出并行删除是很大的事务操作，查看该事务回滚情况：

事务回滚后，后续处理：

该等待一般由于业务繁忙导致，通过降低并发或调整索引可以避免，反向索引由于对范围查询有一定影响，需要进行评估，hash索引分区也可以一定程度避免争用。

根据该情况，业务侧对这个定时脚本进行调整：调整并行度，并且减少删除数据条数循环，加快删除提交。

PS:后续注意事项部分继续更新。