Quantcast
Channel: 黑暗執行緒
Viewing all articles
Browse latest Browse all 2311

Oracle故障後續處理經驗一則

$
0
0

不經一事不長一智,以下經驗價值1.5小時。

接獲回報,部分 ASP.NET 網頁出現資料庫錯誤,錯誤指向某 Oracle 資料庫,使用 Telnet oracel_server_ip 1521 測試無反應,通報系統人員,查出為資料庫主機網路異常,並在隨後修復。

真正的茶包在 Oracle 資料庫主機恢復後才現身,部分使用者通報他們還是無法使用網頁,但我測試是成功的,而有問題的使用者「多試幾次」也會成功。網站為 Web Farm 架構,參雜使用者連上主機可能不同的因素,歷經一番追查彙整,才理頭緒:

  • 網頁連線 Oracle 資料的動作時好時壞,失敗時出現連線錯誤或 Timeout
  • 問題集中在 Web Farm 其中兩台主機
  • 事件檢視器有 EntityFramework 連線錯誤 The underlying provider failed on Open

由於該網頁使用者不多,推測 Oracle 出錯時兩台問題主機剛好有使用者在線上,當時用的 OracleConnection 無法連線出錯,而出錯連線殘留在 Connection Pool。之後 Oracle 資料庫恢復正常,但若是網頁從 Connection Pool 中取出的是曾出錯的連線,便會產生 The underlying provider failed on Open 錯誤。由於 Connection Pool 部分連線是好的,部分是壞的,造成時好時壞,多試幾次就會成功的現象。而重啟 Application Pool 後,問題宣告排除。

事後才想起七年前 ODP.NET 9207 時代我也遇過 Oracle Connection Pool 殘留錯誤連線問題,當時還研究過 ClearPool() ClearAllPool() 指令,可惜未及時想起白走了冤枉路,扼腕!

教重訂 SOP 如下:

遇 Oracle Server 出錯恢復後,應重啟 AppPool 或程序,以清除 Connection Pool 中的有毒連線。 


Viewing all articles
Browse latest Browse all 2311

Trending Articles