最近遇到一個奇怪的事情，每天晚上22點到第二天8點，使用系統經常會報錯。數據庫是Oracle，三個實例組成的RAC，中間件是weblogic。
1.從中間件層面上看，這種錯誤意識是weblogic連不上數據庫後，自動重連都連不上，就會出現這種問題。
<2019-10-29 下午10時57分37,679秒 CST> <Received exception while creating connection for pool “ggDataSource”: IO 錯誤: Connection reset by peer, Authentication lapse 1 ms…>
2.從數據庫日誌上可以看到，數據庫的監聽接收到了中間件的連接，不過超時了，10.10.65.15是報錯weblogic的IP。
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.65.15)(PORT=21716))
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.65.15)(PORT=21722))
nt main err code: 0
ns main err code: 12535
WARNING: inbound connection timed out (ORA-3136)
3.數據庫服務器接收有效的客戶端連接請求，但客戶端需要很長時間進行身份驗證（默認60s）。有可能DB服務器負載很重，因此無法在指定的超時內完成客戶端登錄。
- 這是臨時解決問題的辦法：修改"sqlnet.ora"，然後把監聽重啓一下
SQLNET.EXPIRE_TIME=20
TCP.CONNECT_TIMEOUT=300
SQLNET.OUTBOUND_CONNECT_TIMEOUT=300
SQLNET.INBOUND_CONNECT_TIMEOUT=300
5.分析數據庫報告發現負載很小。
6.由於數據庫服務器上沒有安裝nmon，於是安裝上，5s採集一次，從22點開始運行，8點結束。採集的文件很大，需要找一臺內存比較大的服務器分析。發現IO經常到2GB/s，當IO發生瓶頸的時候數據庫的alert日誌有大量的WARNING: inbound connection timed out (ORA-3136)。
7.問題已經很明顯了，這幾臺服務器上有別的進程在消耗IO。找運維廠家確認，這三個服務器上，每臺有5個實例。爲今之計，只有每個實例通過獲取AWR報告確認，是那臺消耗的IO最多。
總結：現場的環境往往是不可知的，運維廠家的水平參差不齊，只能靠當前信息一步步分析。加超時的配置並不是治本的方法，找到IO的瓶頸纔是。