Oracle資料庫無響應故障，簡單地講就是資料庫例項不能響應客戶端發起的請求，客戶端提交一個SQL後，就一直處於等待資料庫例項返回結果的狀態。更嚴重的現象是客戶端根本不能連線到資料庫，發起一個連線請求後，一直處於等待狀態。Oracle資料庫無響應故障怎麼處理呢?下面跟yjbys小編一起來學習Oracle資料庫無響應故障的處理方法吧!
無響應的故障現象一般有以下幾種：
le的程序在等待某個資源或事件
這種現象一般可以從V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等動態檢視中檢查程序正在等待的資源或事件，而被等待的資源或事件，一直都不能被獲取，甚至是很長時間都不可獲得。如果這個正在等待的程序持有了其他的資源，則會引起其他的程序等待，這樣就很可能引起例項中大範圍的會話發生等待。由於程序在等待資源或事件時，通常都處於SLEEP狀態，消耗的CPU資源非常少(在等待latch時要稍微多消耗一些CPU資源)，所以從OS來看，CPU的消耗並不高，甚至是非常低。
這種因為等待而引起的個別程序Hang，相對比較容易處理。
2. OracleProcess Spins
所謂Spin，就是指Oracle程序中的程式碼在執行某個過程時，陷入了迴圈。在V$SESSION檢視中，往往可以看到Hang住的會話，一直處於“ACTIVE”狀態。對於這樣的會話，用“alter system kill session ‘sid,serial#’”命令也不能完全斷開會話，會話只能被標記為“killed”，會話會繼續消耗大量的CPU。程序Spins由於是在做迴圈，CPU的消耗非常大，從OS上明顯可以看到這樣的程序，通常會消耗整個CPU的資源。
而對於這樣的Hang住的會話，處理起來相對比較複雜，並且為了從根本上解決問題，需要超過DBA日常維護所需要的技能。
從故障範圍來看，無響應故障可以分為以下幾種情況：
1. 單個或部分會話(程序)Hang住
這種情況屬於小範圍的故障，業務影響相對較小，一般來說只會影響業務系統的個別模組。在一個多應用系統的資料庫上面，如果Hang住的會話比較多，則影響的可能是其中的一個應用系統。這裡有一個例外，如果Hang住的程序是系統後臺程序，如pmon、smon等，則影響的範圍就非常大了，最終甚至會影響整個資料庫及所有應用系統。還有值得注意的是，即使是少部分會話Hang住，也要及時處理，否則極有可能會擴散到整個系統。
2. 單個數據庫例項Hang住
這種情況造成的影響非常大。在這個例項上的所有應用系統均受到嚴重影響，並且在找到根源並最終解決問題之前，資料庫例項往往須要重啟。
3. OPS或RAC中的多個例項或所有例項都Hang住
在這種情況下，即使是OPS或RAC，都已經沒辦法提供高可用特性了。使用這個資料庫的所有應用系統將不能繼續提供服務，這種情況往往須要重啟。
無響應故障成因分析
Oracle資料庫無響應，一般主要由以下幾種原因引起：
1. 資料庫主機負載過高，嚴重超過主機承受能力
比如應用設計不當，資料庫效能低下，活動會話數的大量增加，導致資料庫主機的負載迅速增加，資料庫不能正常操作，並最終Hang住;主機實體記憶體嚴重不足，引起大量的換頁，特別是在SGA中的記憶體被大量換出到虛擬記憶體時，資料庫例項往往就會Hang住。
2. 日常維護不當、不正確的操作引起資料庫Hang住
比如歸檔日誌的儲存空間滿，導致資料庫不能歸檔，引起資料庫Hang住;在一個大併發的繁忙的系
統上，對DML操作比較多的大表進行move、增加外來鍵約束等操作也可能使系統在短時間內負載大幅升高，並引起資料庫系統Hang住;不正確的資源計劃(Resource Plan)配置，使程序得不到足夠的CPU等。
3. Oracle資料庫的Bug
幾乎每個版本都存在著會導致資料庫系統Hang住的Bug，這些Bug會在一些特定的條件下觸發，特別是在RAC資料庫中，引起資料庫Hang住的Bug比較多。
4. 其他方面的一些原因
比如在RAC資料庫中，如果一個節點退出或加入到RAC的過程中，當進行Resource Reconfiguration時，會使系統凍結一段時間，也有可能使系統Hang住。
以上所描述的幾種常見的會導致Oracle資料庫例項Hang住的原因中，大部分的情況是可以避免的，只要維護得當，一般不會出現這種故障。對於Oracle資料庫Bug所導致的資料庫無響應故障，由於是在特定的情況下才會觸發，所以如果能夠儘量對資料庫打上最新版本的補丁，並且熟悉當前版本中會導致系統Hang住的Bug以及觸發條件，就能夠最大限度地避免這種故障的發生，提高系統的可用性。
那麼，在資料庫Hang住的情況下，如何去分析並發現導致問題的根源?一方面，由於系統Hang住會導致業務系統不可用，為了能夠儘快地恢復業務，須快速地判斷問題所在，然後Kill掉引起故障的會話和程序，或者資料庫例項不得不重啟以迅速恢復業務;但另一方面，如果只是重啟資料庫或Kill會話和程序來解決問題，在很多情況下是治標不治本的辦法，在以後故障隨時可能會出現。如何在二者之間進行抉擇呢?對於資料庫Hang故障的處理，首先是儘可能地收集到系統Hang住時的狀態資料，然後儘快地恢復業務，恢復業務後分析收集到的資料，找到資料庫系統Hang住的真正原因，然後再進行相應的處理。下一節將詳細描述資料庫系統Hang住後的處理流程。
無響應故障處理流程
對於Oracle無響應故障的處理，我們可以按下圖所示的流程進行。
值得注意的是，上圖並不是一個完整的Oracle資料庫故障處理流程圖，只是處理Oralce資料庫無響應這一類特定的故障的流程，只列出了針對這一特定型別故障處理時的關鍵處理點。不過既然是故障，所以這類故障的處理流程與其他故障的處理流程，有著非常相似的地方。
下面是整個流程的詳細說明：
1. 在出現資料庫無響應故障後，首先確認系統的影響範圍，如上節所描述的，是部分業務系統或模組還是所有的業務系統都受影響，是不是整個例項或多個例項都無響應。同時應詢問系統維護和開發人員，受影響的系統在出現故障前是否有過變動，包括主機硬體、作業系統、網路、資料庫以及應用等。有時一個細小的變動就可能導致出現數據庫Hang住這樣嚴重的'故障。曾經遇到一個庫，應用只是修改了一個SELECT語句就導致了資料庫Hang住。
2. 為了避免由於網路、資料庫監聽或客戶端因素影響分析，建議都登入到主機上進行操作。
3. 如果主機不能登入(為了避免干擾流程主線，這裡不討論如網路問題這樣也會導致不能連線的故障)，嘗試關閉出現問題的業務系統，甚至是所有的業務系統。如果關閉了所有的業務系統之後，仍然不能連線，則只有考慮重新啟動資料庫主機。在資料庫主機重新啟動後，使用作業系統工具或OSW等長期監控作業系統的資源使用，同時監控Oracle資料庫的效能和等待等。
4. 登入上主機後，先用top、topas等命令簡單觀察一下系統。看看系統的CPU使用、實體記憶體和虛擬記憶體的使用、IO使用等情況。
5. 使用SQLPLUS連線資料庫，如果不能連線，則只能從作業系統上觀察系統中是否有異常的現象，比如佔用CPU過高的程序。使用gdb、dbx等debugger工具對資料庫進行system state dump;使用strace、truss等工具檢查異常程序的系統呼叫;使用pstack、procstack等工具察看異常程序的call stack等。
6. 使用SQLPLUS連線上資料庫後，進行hanganalyze、system state dump等操作;或檢查等待事件、異常會話等正在執行的SQL等待。
7. 找到故障產生的原因，如果暫時找不到原因，儘量收集資料。
8.確良如果應用急須恢復，可通過Kill會話、重啟資料庫例項等方式，先恢復應用。
9. 根據最終診斷結果，對資料庫升級打補丁，或者修改應用等方式從根本上解決問題。
怎樣避免資料庫出現無響應故障
作為Oracle資料庫DBA，除了處理故障之外，更重要的是如何預防故障的發生。根據前面對資料庫無響應故障的成因分析，在日常的維護工作中，須做到以下幾點：
1. 進行正確的維護操作
很多的資料庫無響應故障都是由於不正確的維護操作引起的。應避免在業務高峰期做大的維護操作，比如像move、加主外來鍵約束等會長時間鎖表的操作。如果的確需要，儘量使用正確的操作方法。比如用ONLINE方式重建索引;建主鍵、唯一鍵約束時先建索引，然後在建約束時指定新建的索引，等等。也就是保證系統的併發性、可伸縮性，避免系統序列操作的出現。
2. 優化應用設計，優化資料庫效能
為避免效能問題導致在業務高峰期資料庫不能及時有效處理來自業務的請求，甚至於完全Hang住。對於資料庫中存在序列訪問的部分進行優化，比如latch、enqueue，還包括不合理的sequence設計等。特別是在RAC資料庫中，嚴重序列訪問等待往往更容易引起嚴重的效能問題。優化應用設計，使資料庫具有更好的可伸縮性和並行處理能力，能夠有效地避免效能問題引起的資料庫Hang住。
3. 利用監控系統隨時監控系統負載
遇到系統負載過高，記憶體不足，OS中虛擬記憶體換頁很頻繁等情況時，及時採取措施;監控Oracle資料庫的核心程序，如pmon、smon等，看是否有異常，如過高的CPU消耗。出現異常應立即處理;監控歸檔空間和日誌切換;監控資料庫中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。
4. 為資料庫打上補丁
很多的無響應故障是由於Oracle的Bug引起的，資料庫DBA應關注當前版本中有哪些Bug會導致資料庫Hang住，儘量為資料庫打上解決這些Bug的補丁。
