1. Oracle資料庫無響應故障處理方式
Oracle資料庫無響應故障處理方式
Oracle資料庫無響應故障，簡單地講就是資料庫實例不能響應客戶端發起的請求，客戶端提交一個sql後，就一直處於等待資料庫實例返回結果的狀態。更嚴重的現象是客戶端根本不能連接到資料庫，發起一個連接請求後，一直處於等待狀態。Oracle資料庫無響應故障怎麼處理呢?下面跟我一起來學習Oracle資料庫無響應故障的處理方法吧!
無響應的故障現象一般有以下幾種：
1.Oracle的進程在等待某個資源或事件
這種現象一般可以從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 mp;使用strace、truss等工具檢查異常進程的系統調用;使用pstack、procstack等工具察看異常進程的call stack等。
6. 使用SQLPLUS連接上資料庫後，進行hanganalyze、system state mp等操作;或檢查等待事件、異常會話等正在執行的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的補丁。
;2. ORACLE資料庫出現大量LOG FILE SYNCS等待事件，怎麼辦
本文主要討論 RAC 資料庫中的'log file sync' 等待事件。RAC 資料庫中的'log file sync' 等待事件要比單機資料庫中的'log file sync' 等待事件復雜，主要原因是由於RAC 資料庫需要將SCN同步到所有實例。
首先，回顧一下單機資料庫中的'log file sync' 等待事件，當user session 提交（commit）時，user session會通知LGWR進程將redo buffer中的信息寫入到redo log file，當LGWR進程完成寫操作後，LGWR再post（通知）user session 寫操作已經完成，user session 接收到LGWR的通知後提交操作才完成。因此user session 在沒有收到LGWR post（通知）之前一致處於等待狀態，具體的等待事件為'log file sync'。
在RAC資料庫中為了一致性讀，需要將Commit SCN同步/傳播到所有的節點上。SCN同步/傳播的主要方法有兩種：Lamport SCN 和 immediate commit propagation (BOC)。
10gR1 及以下版本默認使用Lamport SCN，Lamport SCN方式即一個節點上的commit SCN 不保證立刻同步/傳播到所有節點，也就是說可能延時同步/傳播，對於一些實時性要求高的RAC資料庫Lamport SCN方式是不可取的。如果希望commit SCN 立刻同步/傳播到所有節點，手動修改參數MAX_COMMIT_PROPAGATION_DELAY=1
從10gR2開始默認使用immediate commit propagation (BOC)，BOC即一個節點上的commit SCN 立刻同步/傳播到所有節點。
介紹 immediate commit propagation (BOC)的工作原理
1. user session 執行提交（commit），user session會通知LGWR進程將redo buffer中的信息寫入到redo log file。
2. LGWR進程收到user session通知後，將redo buffer中的信息寫入redo log file，同時LGWR 將COMMIT SCN 同步/傳播給遠程的資料庫實例的LMS 進程。
3. 遠程資料庫實例的LMS將commit SCN同步到本地SCN，然後通知commit實例的LMS，表示SCN 同步已經完成。
4. 當commit 實例的LMS接收到所有遠程資料庫實例的LMS的通知後，commit 實例的LMS再通知本地的LGWR 所有節點SCN同步已經完成。
5. LGWR 在完成了IO 操作和LMS進程通知後，LGWR通知user session commit 成功。user session在沒有收到LGWR通知前，一直處於等待log file sync。
通過以上原理的說明，我們不難看出來導致'log file sync' 等待事件的主要原因有：
1. 磁碟IO 慢導致LGWR進程將redo buffer中的信息寫入到redo log file速度慢。
2. user session commit過於頻繁。
3. 本地或者遠程伺服器CPU資源不足，導致LMS和/或者LGWR不能及時得到CPU調度，不能正常工作。
4. RAC私有網路性能差，導致LMS同步commit SCN慢。
5. ORACLE BUG.
分析處理'log file sync' 等待事件時的重要log/信息
1. AWR
例如：AWR中log file sync 的等待時間與log file parallel write的時間基本相同，因此是由於IO問題導致的log file sync.
2. LGWR and LMS process trace file
例如：LGWR trace文件中報出下面的信息，很有可能是IO慢導致的。
Warning: log write time 1000ms, size 2KB
3. OSWatcher <--- 可以幫助我們確認伺服器CPU資源使用情況
例如：下面的是OSW中vmstat 的輸出，其中runQ中的進程達到48個，表明當時CPU資源是非常緊張的，會導致LMS/LGWR不能獲得CPU 調度，導致Log file sync等待。
procs memory page faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
48 22 0 23877753 30244459 0 0 0 0 0 0 0 153454 2184632 114234 38 60 2
48 22 0 23877753 30244094 0 0 0 0 0 0 0 153694 2181493 114887 36 61 3
註：關於OSW的安裝配置請參考BLOG中的文章：
https://blogs.oracle.com/Database4CN/entry/%E5%88%A9%E5%99%A8osw_oswatcher_black_box_%E4%B9%8B%E7%AE%80%E4%BB%8B%E7%AF%87
4. Alert log
5. Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) [Document 1064487.1]
解決'log file sync' 等待事件主要方法
1. 提高磁碟IO速度
2. 採用批量提交，減少應用commit次數
3. 安裝OSWatcher 定位CPU使用率高的進程
4. 採用專用網路，正確設置網路UDP buffer參數
5. 安裝最新版本資料庫避免bug，具體bug修復的版本參考文檔：
WAITEVENT: "log file sync" Reference Note (Doc ID 34592.1)
如果自己搞不定可以找ASKMACLEAN專業資料庫修復團隊成員幫您恢復!
3. oracle資料庫運行sql很卡很慢很頓，看等待事件都是cursor:pin s on x,這是啥
詳解cursor: pin S wait on X等待事件 『cursor: pin * events』等待事件 該類等待事件一般是為了pin相關的子游標 『Cursor: pin S on X』 最常見的等待事件， 進程為了共享操作例如執行pin游標而以SHRD S mode申請mutex， 但是未立即獲得。原因是該游標被其他進程以EXCL X mode 持有了。 實際該 cursor: pin S wait on X等待事件往往是由於其他因素誘發的。Mutex爭用僅僅是問題的症狀，但根本原因需要Database Consultant 進一步挖掘。 下面我們列出一些已知的常見案例， 在這些例子中可以看到 我上面提到的 Mutex的爭用僅僅是偽爭用: 過多的子游標 High Version Counts 過多的子游標版本Version Count可能導致Mutex 爭用，一般一個SQL的Version Count不要高於500。 檢查High Version Count很簡單， 在AWR里就有SQL ordered by High Version Count，也可以寫SQL查V$SQL、V$SQLAREA 昂貴的X$、V$視圖查詢 一些對於V$、X$視圖的查詢，需要訪問X$KGL*之類的fixed table，可能觸發Mutex爭用。 Mutex持有者得不到CPU Mutex持有者若得不到足夠的CPU片可能一直阻塞他人，直到它拿到需要的CPU。 這種情況可能由於OS操作系統的實際情況或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。 已經被KILLED的SESSION仍持有Mutex 當session正持有Mutex，而其對應的Process被強制KILL掉， 則直到PMON徹底清理掉該Dead Process並釋放Mutex，其他session才能不再等待。 診斷該類問題，最好能檢查PMON的TRACE。 當然也存在部分BUG會導致PMON清理過程非常慢。 舉例來說，bug 9312879描述了一種場景：PMON 需要獲得某個Mutex以便清理某個dead process，但是該Mutex又被其他進程持有，則PMON甚至無法開始真正清理並釋放Mutex。 如果自己搞不定可以找ASKMACLEAN專業ORACLE優化團隊成員幫您搞定!
4. oracle資料庫里出現很多enq: TX – index contention等待事件是怎麼回事
等待事件
當索引塊分裂發生時， 負責實施分裂 split 的進程會持有 相關的隊列鎖enqueue TX 鎖，
直到該進程完成Split操作才會釋放該enqueue Tx，在這個過程中負責split的進程需要找到合適的新塊並將對應的數據移動到該新塊中。
若在此split過程中，有其他進程INSERT數據到該索引塊中，則將進入 enq: TX – index
contention等待事件，直到split結束enqueue TX被釋放。
負責split的進程需要找到一個合適的新塊， 其會優先尋找本index 已分配的空間中的 free block， 這些free
block應當是100% free的，但是在Oracle 的segment bitmap block 中只區分 0%-25%，25%-50%,
50%-75%, 75%-100% 使用率的數據塊， 即無法直接區分 0%-25%使用率的數據塊中哪些是100% free的數據塊，
Oracle這樣做的目的是 為了重用數據塊，以避免過度分配空間。 當oracle發現沒有可重用的數據塊時才會擴展索引空間並移動分裂數據。
這個在split 過程中 尋找可復用的free block的過程稱之為failed probes on index block
reclamation，在正常的情況下這種找尋可復用塊的過程是很快的 ，但是如果 恰好遇到 物理讀緩慢或者
全局的數據塊爭用時，該過程可能變得很慢，這將直接導致split 變慢， 進而導致大量INSERT進程長時間等待enq: TX – index
contention。
from askmaclean
5. 如何查看oracle的等待事件常見的等待事件以及可能的原因是什麼
有專門介紹等待事件的書啊。一般也只是介紹一些常用的等待事件啊。
答題不易，互相幫助，手機提問的朋友在客戶端右上角評價點滿意即可.
如認可我的回答，請點擊採納為滿意回答按鈕.
6. oracle 有哪些空閑等待事件
Oracle的
等待事件是衡量Oracle運行狀況的重要依據及指標。等待事件的概念是在Oracle7.0.1.2中引入的，大致有100個等待事件。在Oracle
8.0中這個數目增加到了大約150個，在Oracle8i中大約有200個事件,在Oracle9i中大約有360個等待事件。主要有兩種類別的等待事
件，即空閑(idle)等待事件和非空閑(non-idle)等待事件。
空閑事件指Oracle正等待某種工作,在診斷和優化資料庫的時候,我們不用過多注意這部分事件。
常見的空閑事件有:
• dispatcher timer
• lock element cleanup
• Null event
• parallel query dequeue wait
• parallel query idle wait - Slaves
• pipe get
• PL/SQL lock timer
• pmon timer- pmon
• rdbms ipc message
• slave wait
• smon timer
• SQL*Net break/reset to client
• SQL*Net message from client
• SQL*Net message to client
• SQL*Net more data to client
• virtual circuit status
• client message
非空閑等待事件專門針對Oracle的活動,指資料庫任務或應用運行過程中發生的等待，這些等待事件是我們在調整資料庫的時候應該關注與研究的。
一些常見的非空閑等待事件有:
• db file scattered read
• db file sequential read
• buffer busy waits
• free buffer waits
• enqueue
• latch free
• log file parallel write
• log file sync
7. oracle 9i 怎麼查看等待事件的sql
oracle 查詢最近執行過的 SQL語句
select sql_text,last_load_time from v$sql order by last_load_time desc;
SELECT sql_text, last_load_time FROM v$sql WHERE last_load_time IS NOT NULL and sql_text like 'select%' ORDER BY last_load_time DESC;
SELECT sql_text, last_load_time FROM v$sql WHERE last_load_time IS NOT NULL and sql_text like 'update%' ORDER BY last_load_time DESC;
SELECT sql_text, last_load_time FROM v$sql WHERE last_load_time IS NOT NULL and last_load_time like' 14-06-09%' ORDER BY last_load_time DESC;
8. oracle資料庫運行sql很卡很慢很頓，看等待事件都是cursor:pin s on x,這是啥
詳解cursor: pin S wait on X等待事件
『cursor: pin * events』等待事件
該類等待事件一般是為了pin相關的子游標
『Cursor: pin S on X』 最常見的等待事件， 進程為了共享操作例如執行pin游標而以SHRD S mode申請mutex， 但是未立即獲得。原因是該游標被其他進程以EXCL X mode 持有了。
實際該 cursor: pin S wait on X等待事件往往是由於其他因素誘發的。Mutex爭用僅僅是問題的症狀，但根本原因需要Database Consultant 進一步挖掘。
下面我們列出一些已知的常見案例， 在這些例子中可以看到 我上面提到的 Mutex的爭用僅僅是偽爭用:
過多的子游標 High Version Counts
過多的子游標版本Version Count可能導致Mutex 爭用，一般一個SQL的Version Count不要高於500。
檢查High Version Count很簡單， 在AWR里就有SQL ordered by High Version Count，也可以寫SQL查V$SQL、V$SQLAREA
昂貴的X$、V$視圖查詢
一些對於V$、X$視圖的查詢，需要訪問X$KGL*之類的fixed table，可能觸發Mutex爭用。
Mutex持有者得不到CPU
Mutex持有者若得不到足夠的CPU片可能一直阻塞他人，直到它拿到需要的CPU。
這種情況可能由於OS操作系統的實際情況或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。
已經被KILLED的SESSION仍持有Mutex
當session正持有Mutex，而其對應的Process被強制KILL掉， 則直到PMON徹底清理掉該Dead Process並釋放Mutex，其他session才能不再等待。 診斷該類問題，最好能檢查PMON的TRACE。 當然也存在部分BUG會導致PMON清理過程非常慢。
舉例來說，bug 9312879描述了一種場景：PMON 需要獲得某個Mutex以便清理某個dead process，但是該Mutex又被其他進程持有，則PMON甚至無法開始真正清理並釋放Mutex。
如果自己搞不定可以找ASKMACLEAN專業ORACLE優化團隊成員幫您搞定!
9. Oracle的sql語句中wait的含義
nowait：立即執行，如果另有會話正在修改該記錄會立即報告錯誤：ORA-00054: 資源正忙，要求指定 NOWAIT；如果不選擇nowait選項則會一直處理等待狀態。
wait [n]：等待n秒，如果另有會話正在修改該記錄會報告錯誤：ORA-30006: 資源已被佔用; 執行操作時出現 WAIT 超時
＝>另外，還有一個skip locked。
skip locked：跳過已被別的會話鎖定的記錄
10. oracle資料庫等待事件和性能有什麼影響
這是一個很容易引起誤導的等待事件，實際上這個等待事件和並行操作（比如並行查詢，並行DML）沒有關系。 這個事件發生在資料庫恢復的時候，當有一些數據塊需要恢復的時候，Oracle會以並行的方式把他們從數據文件中讀入到內存中進行恢復操作。這個等待事件包含三個參數：
Files： 操作需要讀取的文件個數。
Blocks： 操作需要讀取的數據塊個數。
Requests：操作需要執行的I/O次數。