兩個月前，某天半夜，突然收到告警，系統常駐進程掛了。先登入系統拉起進程後，過一會又會掛掉
檢查日誌，發現是數據庫報錯
ORA-00060: deadlock detected while waiting for resource
而且掛掉的點進程是兩個開啓了多進程處理的，另外幾個點是單進程處理，就沒有問題。於是將其先切換爲單進程處理方式，後運行正常。
於是首先懷疑兩個進程間出現了互鎖，然後導致oracle識別到死鎖，並返回異常。
但是多進程處理，對數據做了區分，是不會出現兩個進程同時處理一張表的情況，之前也一直運行良好，沒有問題啊。難道又bug被出發了？
後來瞭解到，當時產生告警時，正在做內存庫的某些操作，可能會查詢相關表，而且會導致掛掉的程序執行一種update操作
難道其他程序的查詢會和更新操作衝突嗎？ 顯然不可能
仔細排查相關排查代碼並沒有發現異常，又將生產庫數據導入測試庫，也沒有重現問題。
由於找不到問題原因，問題擱置了一個月，本月同一天，多進程處理的點，又出現異常退出情況，錯誤與上個月在時間地點現象上都一致，那麼可以確定是由於那種update操作，就會出現異常，可是上次在測試庫上怎麼就無法重現呢？百思不得其解~~
在測試環境上重現一行行跟蹤相關代碼都沒有發現出問題
會不會測試環境和生產環境有什麼不一樣的嗎？在排查了代碼和數據庫之後終於發現了不同，驚訝的發現，在生產庫上，被update的那個字段上建了一個bitmap索引！！！而測試庫上是沒有的！！！
於是認爲，極有可能是由於該索引引起的互鎖現象。在測試庫上也建上該索引後，終於重現問題了~~
後來溝通得知，這個索引是由於要以該字段做查詢，而且該字段只有兩種取值，爲提高查詢效率，於是就建了位圖索引
結論：
這個問題其實是個很簡單的問題，卻大費周折，花費大量的精力，可以看出自己處理問題中的不足之處
1. 排查原因時，糾結在代碼bug上，甚至懷疑數據庫的處理機制問題，卻沒有幾隻擴大全面排查範圍
2. 對於特殊場景沒有足夠重視，（因爲是某種update操作纔會導致問題，所以應該始終圍繞這個場景思考問題）
3. 先入爲主。因爲該表是自己建的，而位圖索引是同事建了，事先不知，所以先入爲主認爲表沒有問題，而沒有檢查
4. 在測試環境上重現時，沒有仔細檢查與生產環境是否完全一致，就做了測試，導致無法重現問題。讓思路更加複雜話，甚至認爲是數據庫環境的問題。