故障发生的经过

这也是之前的一个处理case, 事故发生在早上8点左右，业务高峰期，客户的沟通群里，消息几百条，各个厂商都在抱怨，系统无法使用。 登录到数据库服务器，第一时间看了负载不高，随即马上登录到数据库，查看当前的等待事件。 发现有大量的 行级锁等待：enq:Tx-row lock contention。 第一时间判定大概率研发SQL导致的，恢复业务you'xian立即批量 kill了造成锁的SQL会话，半个小时候后，同样的情况又出现，大量的行级锁，无奈之下，顶着压力，慢慢找问题，期间为了缓解业务使用，多次进行了kill 会话的操作。

处理问题的那段事件，第一时间判断是SQL问题，短时间内让研发看代码，然后修改并迭代， 这是不可能的。之前的经验出现过很多次，DBA和研发之间，互相推诿的情况屡见不鲜，研发更多的是希望从数据库层面，能优化掉就优化掉，最好不需要修改代码，而DBA往往是希望从代码角度进行优化，毕竟仅仅从数据库优化是有限的，而且有些代码明确的违反了数据库的设计原则，DBA也需要从原则上坚持其权威性。回到那次故障的处理过程中， 当时数据库频频需要kill会话来缓解业务，可想而知，当时的压力有多大，具有强大的心理素质是DBA的基本要求之一。

功夫不负有心人，在查看表结构的时候，发现有一张表，建立了位图索引，这是一个突破点，一般情况下，在高并发的OLTP的业务环境下，这是禁止使用的。 随即问了驻厂的实施工程师，发现这个索引是最近新建的。 OMG，确定了原因之后，立马删除了索引，情况有了明显改善。

故障分析

从下面的AWR报告来看，当时负载不高

连接数和会话数当前都只有700多。目前数据库设置的最大值可达到2000以上。

目前数据库的等待事件，主要的等待都花在了enq:Tx-row lock contention 行级锁等待。

当前的数据库会话信息

Oracle数据库，数据库一般不会出现insert之间互相阻塞，所以怀疑是不是有特殊类型，发现表OUTPAYMT列SUBMITFLAG创建了位图索引。

bitmap index与b-tree索引不同，bitmap index索引键值指向多行，因此当发生DML时，oracle会锁定索引包含的多行记录，Oracle官方解释位图索引是为数据仓库或环境设计，适用于

1.低基数，distinct值小于表的行数，越小越好，

2.只读表或不做DML操作，bitmap index不适用OLTP系统。

目前看这个表的列SUBMITFLAG 只存了两个值-1和0。

解决方案及建议

删除这个位图索引，改成普通b-tree索引，业务系统恢复正常。

B-TREE索引，一般情况下选择普通的b-tree索引，也是oracle默认的索引。

位图索引的使用场景： 位图索引， 对于不同的值很少的列，且数据量较大，且DML操作很少，这种情况可以选择使用位图索引。比如性别，只有男和女 且DML操作也会很少，此时选择位图索引，效率可能会更高。