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


你可能感兴趣的:(ORACLE)