資料庫的故障

❶ 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的補丁。

;

❷ 資料庫事務本身發生了不可預期的故障

你這應該是發生了系統范圍的故障。

資料庫類型：mysql；資料庫版本：mysql5.6；系統：linux。

資料庫系統故障可分為：事務內部故障、系統范圍內故障、介質故障和計算機病毒四類。

1．事務內部故障

事務內部故障是指事務運行沒有達到預期的終點，未能成功地提交事務，使資料庫處於不正確狀態。

事務內部故障有的可以通過事務程序本身發現，是可預期的故障，但更多的是不可預期的故障，如數據溢出等。當發生事務內部故障時，可強行回滾（ROLLBACK）該事務，這類恢復操作稱為撤消（UNDO）。

2．系統范圍的故障

造成系統停止運行的任何事件都稱為系統故障，如停電、操作系統故障。這類故障造成正在運行的事務非正常終止，資料庫緩沖區中數據的丟失。

若發生系統范圍的故障，恢復子系統必須在系統重新啟動時讓所有非正常終止的事務回滾，若事務只作一半便發生故障，必須先撤消該事務，然後重做。

3．存儲介質故障

系統故障又稱軟故障，存儲介質故障稱為硬故障。硬故障發生的可能性小，但破壞性極大。如硬碟損壞等。

4．計算機病毒

計算機病毒主要破壞計算機軟體系統，由計算機病毒引起的故障屬於系統范圍的故障。

❸ 資料庫系統中故障可以分為哪幾類

資料庫系統中故障可以分為：事務故障、系統故障、介質故障。
一、事務故障
某個事務在運行過程中由於種種原因未運行至正常終止點，事務故障的常見原因，輸入數據有誤
運算溢出，違反了某些完整性限制發生鎖死。

二、系統故障

由於某種原因造成整個系統的正常運行突然停止，致使所有正在運行的事務都以非正常方式終止。
發生系統故障時，內存中資料庫緩沖區的信息全部丟失，但存儲在外部存儲設備上的數據未受影響 。

三、介質故障

硬體故障使存儲在外存中的數據部分丟失或全部丟失 ，介質故障比前兩類故障的可能性小得多，但破壞性最大。

❹ 資料庫故障可分為哪幾類

資料庫系統中故障可以分為：事務故障、系統故障、介質故障。

一、事務故障

某個事務在運行過程中由於種種原因未運行至正常終止點，事務故障的常見原因，輸入數據有誤
運算溢出，違反了某些完整性限制發生鎖死。

二、系統故障

由於某種原因造成整個系統的正常運行突然停止，致使所有正在運行的事務都以非正常方式終止。
發生系統故障時，內存中資料庫緩沖區的信息全部丟失，但存儲在外部存儲設備上的數據未受影響 。

三、介質故障

硬體故障使存儲在外存中的數據部分丟失或全部丟失 ，介質故障比前兩類故障的可能性小得多，但破壞性最大。

❺ 資料庫運行過程中常見的故障有哪幾類試述對各類故障的恢復策略。

資料庫運行過程中常見的故障有3類：事物故障、系統故障、介質故障。

恢復策略：

1、事物故障：

發生事務故障時，被迫中斷的事務可能已對資料庫進行丁修改，為了消除該事務對資料庫的影響，要利用日誌文件中所記載的信息，強行回滾該事務，將資料庫恢復到修改前的初始狀態。

為此，要檢查日誌文件中由這些事務所引起的發生變化的記錄，取消這些沒有完成的事務所做的一切改變，這類恢復操作稱為事務撤銷。

2、系統故障：

系統故障的恢復要完成兩方面的工作，既要撤銷所有末完成的事務，還要重做所有已提交的事務，這樣才能將資料庫真正恢復到一致的狀態。

3、介質故障：

介質故障比事務故障和系統故障發生的可能性要小，但這是最嚴重的一種故障，破壞性很大，磁碟上的物理數據和日誌文件可能被破壞，這需要裝入發生介質故障前最新的後備資料庫副本，然後利用日誌文件重做該副本後所運行的所有事務。

(5)資料庫的故障擴展閱讀：

「數據故障恢復」和「完整性約束」、「並發控制」一樣，都是資料庫數據保護機制中的一種完整性控制。所有的系統都免不了會發生故障，有可能是硬體失靈，有可能是軟體系統崩潰，也有可能是其他外界的原因，比如斷電等等。

資料庫運行的突然中斷會使資料庫處在一個錯誤的狀態，而且故障排除後沒有辦法讓系統精確地從斷點繼續執行下去。這就要求DBMS要有一套故障後的數據恢復機構，保證資料庫能夠回復到一致的、正確地狀態去。

參考資料來源：網路-事務故障

參考資料來源：網路-系統故障

參考資料來源：網路-介質故障

❻ 資料庫系統中故障可以分為哪幾類

可以分為三類：

1.事務故障

2.系統故障

3.介質故障

❼ crossref資料庫故障

資料庫的故障主要分為四類：
（1）事務故障。事務在運行過程中由於種種原因，如輸入數據的錯誤、運算溢出、違反了某些完整性限制、某些應用程序的錯誤，以及並發事務發生死鎖等，使事務未運行至正常終止點就被撤銷，這種情況稱為「事務故障」。
（2）系統故障。系統故障是指系統在運行過程中，由於某種原因（如操作系統或資料庫管理系統代碼錯誤、操作員操作失誤、特定類型的硬體錯誤（如 CPU 故障）、突然停電等造成系統停止運行），致使事務在執行過程中以非正常方式終止，這時內存中的信息丟失，但存儲在外存儲設備上的數據不會受影響。
（3）介質故障。系統在運行過程中，由於某種硬體故障，如磁碟損壞、磁頭碰撞或由於操作系統的某種潛在的錯誤、瞬時強磁場干擾，使存儲在外存上的數據部分損失或全部損失，稱為「介質故障」。這類故障比前兩類故障的可能性雖然小得多，但破壞性卻最大。
（4）計算機病毒。計算機病毒是一種人為破壞計算機正常工作的特殊程序。

❽ openGauss資料庫故障定位思路

肯定是從報錯提示入手，具體可以看看報錯日誌；openGauss也提供了一些視圖來存其運行狀態；還有就是收集core文件進行分析。具體參考官方的建議思路：

1、日誌。資料庫日誌記錄了資料庫服務端啟動、運行或停止時出現的問題，當資料庫在啟動、運行或停止的過程中出現問題時，資料庫用戶可以通過運行日誌快速分析問題的產生原因，並根據不同的原因採取相應的處理方法，盡可能地解決問題。

2、視圖。資料庫提供了許多視圖，用於展示資料庫的內部狀態，在定位故障時，經常使用的視圖如下：

• pg_stat_activity，用於查詢當前實例上各個session的狀態。

• pg_thread_wait_status，用於查詢該實例上各個線程的等待事件。

• pg_locks，用於查詢當前實例上的鎖狀態。

3、CORE文件。資料庫相關進程在運行過程中可能會因為各種意外情況導致資料庫崩潰 （Coremp），而崩潰時產生的core文件對於迅速定位程序崩潰的原因及位置非常重要。如果進程運行時出現Coremp現象，建議立即收集core文件便於分析、定位故障。

• 對性能有一定的影響，尤其是進程頻繁異常時對性能的影響更大。

• core文件會佔用磁碟空間。因此，當檢查到core文件產生後，應及時解決以避免對操作系統帶來更嚴重的影響。操作系統自帶core mp機制。開啟後，系統中所有出現Coremp問題時都會生成core文件，對操作系統帶來性能和磁碟佔用的影響

• 設置core文件生成路徑。修改/proc/sys/kernel/core_pattern內容。

  [root@openeuler123 mnt]# cat /proc/sys/kernel/core_pattern
  /data/jenkins/workspace/openGaussInstall/dbinstall/cluster/corefile/core-%e-%p-%t

❾ 資料庫運行中可能產生的故障有哪幾類

資料庫系統中的故障可以分以下幾類：（1）事務內部的故障；（2）系統故障；（3）介質故障；（4）計算機病毒。事務故障、系統故障和介質故障影響事務的正常執行；介質故障和計算機病毒破壞資料庫數據