一:
12c遷移19c工程,針對大數據相關定時作業進行性能對比,發現部分作業連接19c 出現 Socket read timed out 問題,并且可以復現,該部分作業連接12c并無異常
初步排查情況如下:
1)在執行到某部分sql時jdbc拋出Error: java.io.IOException: SQLException in nextKeyValue 錯誤,導致的原因是Caused by: java.sql.SQLRecoverableException: IO Error: Socket read timed out
2)jdbc堆棧信息無ora錯誤,看起來是一個客戶端單方面錯誤
3)連續查看幾次報錯日志,發現每次報錯都是在發起sql后的第11分鐘才拋出異常,詢問客戶是否有進行timeout相關測試,客戶反饋連接串中未設置任何參數
4)對該場景進行重現測試,發現客戶端報出Socket read timed out,數據庫會話依然在執行直到sql執行結束
5)關于socket read timed out初步了解到是客戶端在向數據庫發起查詢時等待數據返回時超過了某個時間限制導致超時
6)了解到jdbc driver版本是11.2.0.1.0
二:
1)jdbc driver 版本11.2.0.1是不兼容19c,建議客戶先進行升級測試
2)需要進一步排查網絡是否有超時設置
3)通過以上步驟來縮小排查范圍
2.討論進展如下:
1)客戶否認網絡存在問題,但我認為是否可以繼續進行抓包排查
2)客戶表示驅動包問題可以進行升級驅動測試,確認是否驅動包問題
3)提出每次報錯都是在第11分鐘開始報錯,客戶提出可能應用平臺有配置過10分鐘的超時設置,開發排查代碼發現有10分鐘超時設置,后面增加超時時間再進行測試,發現不再報錯
4)客戶存在疑問,為何同樣的配置在12c不生效,而在19c能夠生效
5)現場同時排查了數據庫端sqlnet參數,12c和19c并無差別
三:
1)詢問中間件同事,表示針對不同數據庫版本可能會有不同的超時時間設置,這一點找不到相關資料,詢問sr,gcs表示沒有不同的設置說法
2)中間件同事和sr同時也建議排查操作系統層,目前只能看到數據庫端os,目前看到的網絡相關參數不確認。
3)客戶在測試環境使用11.2.0.4版本jdbc 進行測試,發現同樣在12c不會超時,而在19c會出現超時
4)為了排除數據版本不同造成socket超時不生效原因,我使用一段java代碼指定不同版本的jdbc driver 分別連接12c和19c 進行查詢操作一段,設置socket timeout 時間為10s,發現11.2.0.1和11.2.0.4 的jdbc driver 連接12c和19c 查詢超過10s后 都能出現超時情況,進一步可以說明超時是否生效與數據庫版本無關,同時也和jdbc版本無關,所以問題還是出現在應用端配置上,將此情況向客戶反饋。
四:
1)將java測試代碼 readtimeout 從10秒鐘調整為10分鐘,看是否能復現客戶的問題。
2)調整為10分鐘進行測試,結果是19c 正常10分鐘超時,12c 10分鐘超時。
3)與gcs jdbc 工程師討論,懷疑12c超時不生效是因為客戶端socket api在監測時不斷接收到數據包,導致超時時間被不斷延長。
4)協調系統工程師進行連接12c和19c的網絡抓包測試,發現連接12c時,db端每2分鐘會發送一個10 bytes的tns包到client端,隨后client端會返回ack包。而連接19c時,db端每2分鐘發送一個keep-alive包到client端。從db端來看,目前配置了sqlnet.expire_time=2,可能與此有關。
5)與gcs工程師討論,12c為何timeout不生效就應該是定時tns包影響,而19c timeout生效是因為keep-alive 包是相對比較底層的數據包,client端操作系統直接過濾掉。
五:
1)查詢文檔 Oracle Net 12c: Changes to the Functionality of Dead Connection Detection (DCD) (Doc ID 1591874.1) 發現 在12c后 ,開啟dcd后db端檢測死連接的方式是從每n分鐘發送10 bytes tns包改成了 tcp keep-alive包,這里可以解釋19c網絡抓包中看到的每2分鐘一個的keep-alive包。
2)但目前來看,連接12c是使用了傳統的tns包,而19c是使用了新的keep-alive包, 從文檔1591874.1中看是12.1之后就默認使用了新的模式,但如果操作系統不支持或者認為設定,可以改為傳統發送tns包的模式,目前12c是solaris 11.3操作系統,是支持keep -alive的,理論是應該支持新模式的,目前找不到更多資料說明,這仍是是個謎團。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。