早上過來，一客戶工作人員反映有個庫中的使用者被鎖掉，讓我排查下原因。

當時直接反應就是使用者密碼錯誤，嘗試次數過多導致使用者被鎖。

客戶給我生成了listener.log，

我在庫上檢視使用者被鎖時間：

select username,lock_date from dba_users where username='xxx'; 

發現被鎖使用者的時間資訊已經不存在，原因是使用者已經被客戶解鎖，所以檢視dba_users中已經看不到使用者被鎖時間的資訊。

這個時候通過查看錶user$來解決這個問題：

select name,ltime from user$ where name ='XXXX';

檢視ltime的具體時間點後，在listener.log這個監聽日誌中定位當時是哪個程式連線，和業務人員確認是一個晚上跑批的定時任務。。。

本以為一切順利，結果客戶一再肯定說密碼沒有設定錯誤，也打開了一些配置檔案，確認了密碼沒有錯誤的問題。

我就惆悵了，難道被SQL注入攻擊了，又讓安全組那邊查了下審計資訊，也沒有發現異常。

我就一個人一點點的看listener.log，發現每天時間點都有那個跑批程式出現，user$中顯示4月3號2點10分01秒鎖的賬戶，但昨天才解鎖，那麼這未解鎖的幾天，按道理講跑批程式都是應該沒有成功的。客戶又找來了相關開發人員，一個個排查，原來存在多個跑批程式，上次程式釋出的過程中，有個跑批程式密碼沒有更改。。。。。。

我也是醉了。由於客戶一開始很是肯定，認為密碼配置沒有問題，我也就信了，都要開始考慮是不是踩了某個log方面的bug，比如當時中介軟體連線oracle存在異常，或者密碼延遲之類的，導致賬戶被鎖了。。。。。。。

給自己提了個醒，很多時候我們所肯定的只是我們確實知道的東西，萬一有某一方面我們沒有涉及到，那麼就可能問題出現在該方面。排查問題的過程要全面，從點到面，毫無死角。