了解在使用 IBM DB2 時如何識別最常見的損壞問題，并對這些問題進行分類。在本文中，將了解一些糾正和預防技術，您可以用它們來解決討厭的損壞問題。

被視為是最麻煩的業務問題之一，損壞常常在不知不覺中逐漸形成，給企業帶來不利影響。簡言之，可以將損壞 定義為中的任何意外項。損壞問題可能會對系統造成嚴重的性能沖擊。在某些情況下，它可能會導致頻繁的系統崩潰，引發關鍵業務系統宕機。數據庫損壞可發生在任何層面，從 DB2 到操作系統以及硬件層。因此，了解和排除故障很重要，即分析所有可能受影響的層，并收集可能盡快需要的任何可用的診斷數據。

在本文中，您將了解為何數據庫會在遇到損壞問題時離線。您還將學習分析損壞癥狀，區分易于修復的故障和災難性故障。本文將闡明使用 IBM DB2 時的損壞問題，并幫助 DB2 用戶理解和選擇處理這種關鍵的高影響問題的最佳方法。

本文首先討論可能的損壞來源，然后解釋以下任務：

1. 識別和排除損壞故障，在使用 DB2 時識別數據庫中的損壞問題并對其進行分類，輔以 db2diag.log 中出現的樣例癥狀消息。損壞問題可以大體分為五個類別：數據頁面損壞（或表損壞）、索引損壞、CBIT 損壞、日志損壞和壓縮描述符損壞。
2. 使用 db2dart 和 INSPECT 識別損壞問題，洞悉有用的 DB2 命令，db2dart 和 INSPECT，來檢查數據庫損壞。
3. 從損壞中恢復的方法，一旦識別到一個損壞問題，如何著手處理這些情況、要收集什么數據、如何從該狀況中恢復過來，這些至關重要。學習可能的恢復方法以及如何選擇可用方案。
4. 避免可能的損壞的預防性戰略，討論最佳實踐。

來源

數據庫損壞可能在寫入、讀取、存儲、傳輸或處理過程中發生，這會向原始數據引入非計劃中的更改。損壞問題的一些常見原因：

1. 損壞的文件系統是數據庫中出現損壞的最常見原因之一。突然的系統關閉、電涌、文件系統雙機掛載、遷移磁盤、文件系統級活動，比如數據庫上線運行時檢查和修復文件系統（使用的實用程序包括 Linux® 上的 fsck），在文件打開時使用 Ctrl+Alt+Delete 以及病毒，都可能在數據庫中引入意外的變更。
2. 硬件故障。
3. 內存損壞。
4. DB2 缺陷。
5. I/O 和網絡問題（如光纖適配器和交換機中的問題）。
6. 不正確的應用程序編碼。
7. 緩沖池 (sqldPage) 和文件系統中存儲的頁面的值不一致。
8. 重寫磁盤數據會導致損壞問題。
9. 用戶對數據庫的重要配置文件、日志文件、日志控制文件等的干擾都會使數據庫處于不一致的狀態。

雖說損壞問題由各種原因而致，確切地查明是什么導致了數據損壞是極具挑戰的。在大部分情況下，該問題是由文件系統問題和硬件問題引起的。

識別和排除故障

對于一個 DBMS，頁面 是由操作系統為一個程序執行的內存分配的數據的最小單元，在主內存與任何其他輔助存儲（比如硬盤驅動器）之間傳輸。因此所謂數據庫損壞也就是說數據庫中的某些頁面被損壞了。

如果 DB2 有無法得體處理的錯誤情況，panic 是它會用來招致崩潰的一種方法。當 DB2 檢測到一個頁面損壞時，它通過一個受控崩潰 (panic) 停止所有處理，因為它無法確定數據庫完整性。這也是為了阻止進一步的數據損害或丟失。

當 DB2 遇到數據庫損壞時，db2diag.log 中轉儲很多錯誤消息。當出現意外中斷且啟用了自動的首次出現數據捕獲 (FODC) 時，會基于癥狀來收集數據。當滿足以下條件之一時，DB2 9.5 上會自動收集 FODC 數據：

1. FOCD_Trap，當發生一個實例范圍內的陷阱時。
2. FODC_Panic，當一個 DB2 引擎檢測到不連貫且決定不繼續時。
3. FODC_BadPage，當檢測到壞頁面時。
4. FODC_DBMarkedBad，當數據庫因一個錯誤而被標記為 “壞” 時。

要搜集必要的信息，比如 OS 診斷（例如，AIX® 上的 errpt –a、snap 和 fileplace 輸出）以及任何硬件診斷（狀態保存和錯誤日志等），關鍵是要包含 OS 和硬件支持。重要的是要確保關鍵的文件系統有足夠的磁盤空間，比如轉儲空間和日志目錄，從而確保完全捕獲關鍵事件。

您可以查看 db2diag.log，確認 panic 是因為損壞還是另外的原因引起的。下面您會看到如何識別 DB2 中的損壞并對其進行分類。以下是識別損壞的最常見的一些 db2diag.log 錯誤消息。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com