Oracle故障後續處理經驗一則

不經一事不長一智,以下經驗價值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 中的有毒連線。 

歡迎推文分享:
Published 05 October 2016 12:18 AM 由 Jeffrey
Filed under: ,
Views: 2,905



意見

沒有意見

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<October 2016>
SunMonTueWedThuFriSat
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
 
RSS
創用 CC 授權條款
【廣告】
twMVC

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication