ORACLE位图索引导致的ORA-00060: deadlock detected while waiting for resource

两个月前，某天半夜，突然收到告警，系统常驻进程挂了。先登入系统拉起进程后，过一会又会挂掉

检查日志，发现是数据库报错

ORA-00060: deadlock detected while waiting for resource

而且挂掉的点进程是两个开启了多进程处理的，另外几个点是单进程处理，就没有问题。于是将其先切换为单进程处理方式，后运行正常。

于是首先怀疑两个进程间出现了互锁，然后导致oracle识别到死锁，并返回异常。

但是多进程处理，对数据做了区分，是不会出现两个进程同时处理一张表的情况，之前也一直运行良好，没有问题啊。难道又bug被出发了？

后来了解到，当时产生告警时，正在做内存库的某些操作，可能会查询相关表，而且会导致挂掉的程序执行一种update操作

难道其他程序的查询会和更新操作冲突吗？ 显然不可能

仔细排查相关排查代码并没有发现异常，又将生产库数据导入测试库，也没有重现问题。

由于找不到问题原因，问题搁置了一个月，本月同一天，多进程处理的点，又出现异常退出情况，错误与上个月在时间地点现象上都一致，那么可以确定是由于那种update操作，就会出现异常， 可是上次在测试库上怎么就无法重现呢？百思不得其解~~

在测试环境上重现一行行跟踪相关代码都没有发现出问题

会不会测试环境和生产环境有什么不一样的吗？在排查了代码和数据库之后终于发现了不同，惊讶的发现，在生产库上，被update的那个字段上建了一个bitmap索引！！！而测试库上是没有的！！！

于是认为，极有可能是由于该索引引起的互锁现象。在测试库上也建上该索引后，终于重现问题了~~

后来沟通得知，这个索引是由于要以该字段做查询，而且该字段只有两种取值，为提高查询效率，于是就建了位图索引

结论：

这个问题其实是个很简单的问题，却大费周折，花费大量的精力，可以看出自己处理问题中的不足之处

1. 排查原因时，纠结在代码bug上，甚至怀疑数据库的处理机制问题，却没有几只扩大全面排查范围

2. 对于特殊场景没有足够重视， （因为是某种update操作才会导致问题，所以应该始终围绕这个场景思考问题）

3. 先入为主。因为该表是自己建的，而位图索引是同事建了，事先不知，所以先入为主认为表没有问题，而没有检查

4. 在测试环境上重现时，没有仔细检查与生产环境是否完全一致，就做了测试，导致无法重现问题。让思路更加复杂话，甚至认为是数据库环境的问题。