31 データ破損の予防、検出および修復
データ破損(ハードウェア、ソフトウェアまたはヒューマン・エラーによって生じるデータの意図しない変更として定義されます)は、Oracle Database環境の整合性に対する重大な脅威となります。この広範囲にわたる懸念に対処するために、Oracleは、予防、検出および修復という3つの基本的な柱の上に構築された堅牢なメカニズムを提供します。
データ破損タイプ
データ破損タイプのサマリー
| タイプ | 発生場所/原因 | 検出機能 | 現象 |
|---|---|---|---|
| 物理的破損 | ハードウェア/ストレージ | ブロックI/O/チェックサム | 読取りエラー、破損した構造 |
| 論理的な破損 | ソフトウェア/メモリー | 整合性チェック | データは存在するが、一貫性がないか、論理的に無効 |
| 書込み消失破損 | ストレージ、I/Oパス | SCNチェック/Data Guard | REDOの期待値よりブロック・バージョンが古い |
物理ブロック破損
これらのエラーは、データベース・ブロックの構造が物理的に破損したり、読取り不能になった場合に発生します。通常、このような破損は、ハードウェア障害(ディスク・エラー、コントローラの障害、ケーブルの障害など)の結果です。
例:
-
ブロック・ヘッダー/フッターが正しくないか欠落している
-
データ・チェックサムまたは内部の「マジック・ナンバー」が一致しない
-
完全にゼロまたはランダムな、認識できないデータ・パターンを含むブロック
特徴:
-
ディスクから破損ブロックを読み取ろうとしたときにOracleによってり検出されます
ORA-01578: ORACLE data block corruptedなどの重大なエラーとして表示されます。-
ブロック・メディア・リカバリまたは有効なバックアップからのデータ・リストアを使用して修復できます
論理ブロック破損
物理破損とは対照的に、ブロックの物理構造が無傷で読取り可能であっても、その内部コンテンツがOracleで想定される論理ルールまたはメタデータと矛盾すると、論理破損が発生します。通常、これらはソフトウェアのバグまたはメモリー関連の問題を示しています。論理ブロック破損には、論理破損が1つのデータ・ブロック内で自己完結するブロック内の論理破損と、2つ以上の独立したデータ・ブロック間でデータが不整合になるブロック間の論理破損があります。
例:
-
存在しない行を参照する索引エントリは、ブロック間の論理破損の例です。
-
同じデータ・ブロック内の関連するメタデータとの不整合を示す表の行は、ブロック内論理破損の例です
-
不正な内部ポインタ(行ピース・チェーン内のポインタなど)は、関連するデータ・ブロックの数に応じてブロック内またはブロック間の論理破損になる可能性があります
特徴:
-
ブロックは物理的に読取り可能で、そのチェックサムと構造は通常有効です
-
検出には、論理的な整合性チェックが必要です。多くの場合、これはRMANの
VALIDATE CHECK LOGICAL、SQLコマンドANALYZE ... VALIDATE STRUCTUREで実行されます。または、アプリケーションでの問合せ中に検出されます。 -
場合によっては、ブロック・メディア・リカバリを使用して修復したり、バックアップから完全リストアすることなく修復できます。たとえば、影響を受ける索引を再構築したり、
DBMS_REPAIRを使用して破損を回避し、残りのデータにアクセスできます
書込み消失破損
書込み消失破損は、データベース・ブロックの変更がストレージ・サブシステムによって正常に書き込まれたと認識されたが、実際のデータはディスクまたはI/Oに永続的に格納されずに失われたときに発生します。これにより、ディスク上のブロック・イメージがデータベースの想定より古くなり、重大な一貫性の不一致が発生します。
例:
- I/Oサブシステムまたはシステム・ファームウェアの不具合が原因で、I/Oが誤って認識される
-
システム・クラッシュまたはハードウェア障害の後、ディスク上のデータ・ブロックに、永続性があると思われる最近コミットされた変更が反映されない
-
ディスクに物理的に存在するバージョンよりも新しいブロック・バージョンを予期するエントリがREDOログに含まれている
特徴:
-
これはデータの一貫性の問題であり、ブロック自体の構造的または論理的な破損ではありません
-
主に、Oracle Data Guard (ブロックSCN比較を使用)などの高度な機能またはなんらかのタイプのメディア・リカバリによって検出されます。
-
プライマリ・データベースとスタンバイ・データベースが同期しなくなった場合、またはREDOストリームがデータ・ファイルの実際の状態と一致しない場合、データの相違が発生します
Oracleのデータ破損回復機能のサマリー
Oracleデータベースにおけるデータ破損に対する包括的な防御は、予防的な防止、警戒的な検知、およびOracleの組込み修復機能の適切な使用で構成されています。
| 柱 | 機能、ツールおよびベスト・プラクティス | 用途 |
|---|---|---|
| 予防 |
ソフトウェア更新の実施、テスト、推奨データベース・パラメータの使用 Oracle Active Data Guard、Exadata、リカバリ・アプライアンス 詳細は、「データ破損の防止」を参照してください |
破損の発生を回避したり、破損がアプリケーションに影響しないようにします |
| 検出 |
推奨データベース・パラメータ、データベースおよびシステム・アラート、RMAN Oracle Active Data Guard、リカバリ・アプライアンス、Exadata 詳細は、「データ破損の検出」を参照してください |
破損の早期発見、通知および処置の実行 |
| 修復 |
Oracle Active Data Guard、またはGoldenGate、ASMおよびExadata、RMAN 詳細は、「データ破損の修復」を参照してください |
影響を最小限に抑え、データをリストアして自動的に修復(つまり、自動ブロック修復)し、最小限のダウンタイムとデータ損失で解決されるようにします。 |
データ破損の防止
予防は、破損が起こる前に予防的に防止することを目的としています。
ベスト・プラクティスとOracleの機能
-
ソフトウェアを最新状態に維持する:
-
専用テスト・システムの使用:
-
本番環境にデプロイする前に、テスト環境のすべてのソフトウェア、ハードウェア、データベースまたはアプリケーションの変更を十分に評価します。これは、潜在的な新しいデータ破損を検出し、既存の破損修正の有効性を検証するのに役立ちます。
-
本番環境を正確に再現した代表的なワークロードを使用することが重要です。一部の破損は、特定のアプリケーション条件または極端なアプリケーション条件でのみ発生からです。
-
-
信頼性の高いハードウェアを採用:
-
高度なエラー修正機能を備えたエンタープライズグレードのストレージソリューションを実装します。
-
ExadataおよびOracle ASMは、データ破損がアプリケーションおよびデータベースに影響を与えないように特別に設計された、多数の統合されたハードウェアおよびソフトウェア機能を提供します。
-
-
ストレージ冗長性の実装:
-
RAID構成および冗長SAN/NASソリューションを使用して、物理ストレージに回復性を持たせます。
- Oracle ASMおよび標準冗長性または高冗長性を採用すると、データの破損から保護されます。
1つのASMディスク上のブロックが物理的に破損している場合(ハードウェア障害などにより)、ASMでは次のことが可能です:
- 破損していないミラー化されたコピーを別のディスクから提供し、破損したデータをデータベースが使用しないようにします。
- 有効なミラー化されたコピーを読み取り、破損したコピーを置き換えるように書き換えることで、破損したコピーを自動的に回復します(可能な場合)。
-
Exadataには、組込みの冗長性と、高度な破損防止および自動修復機能が備わっています。Exadataは、ミラー化されたコピーを使用して破損ブロックを検出および修復するために、定期的なデータ検証(スクラビング)を行います。
-
-
定期的なバックアップの実行:
-
自動化されたRMANバックアップを頻繁にスケジュールし、REDOログが継続的にアーカイブされるようにします。
-
Zero Data Loss Recovery Appliance (ZDLRA)とリカバリ・アプライアンスは、自動バックアップ検証を提供し、Exadataの破損防止と修復のメリットを活用することで、これを強化します。
-
主要なデータベース構成パラメータ
-
DB_BLOCK_CHECKSUM:-
目的: ディスクに書き込まれるすべてのデータベースおよびREDOブロックのチェックサムを有効にして、物理ブロックの破損を検出します。
-
推奨事項: プライマリ・データベースとスタンバイ・データベースの両方に
TYPICAL以上。 -
デフォルト:
TYPICAL
-
-
DB_BLOCK_CHECKING:-
目的: 論理的な破損を検出し、ディスクに書き込まれないようにします。
-
推奨事項: プライマリ・データベースまたはスタンバイ・データベースに
MEDIUM以上。 -
デフォルト:
FALSE -
ノート: パフォーマンスのオーバーヘッドは異なる場合があります。一般的な妥協点は、論理的な破損が伝播されないようにスタンバイ・データベースで有効にすることです。
-
-
DB_LOST_WRITE_PROTECT:-
目的: スタンバイ・データベースで書込み消失を検出し、プライマリ・データベースで書込み消失をアクティブに防止/検出します。
-
推奨事項: プライマリ・データベースとスタンバイ・データベースの両方に
TYPICAL以上。 -
デフォルト: データベース・リリースに応じて
TYPICALまたはNONE。Oracle 19c (19.26)以降、Data Guard構成のデフォルトはTYPICALに変更されました -
ノート: これにより、スタンバイに追加のI/Oが発生し、REDO適用のパフォーマンスを維持するために十分なI/O容量が必要になる場合があります。Oracle Database 19c以降では、プライマリまたはスタンバイのいずれかから現在のブロックを使用して、失われた書込みの自動ブロック修復が行われることがあります。
-
Oracle整合性ツールと機能
-
RMANバックアップ: バックアップの整合性を確保し、リカバリを容易にします。
-
信頼性の低いストレージの回避: Oracleデータベース・ファイルを、不適切に構成されたNFSマウントまたはその他の信頼性の低いストレージ・デバイスに配置しないでください。
-
Active Data Guardの使用: フィジカル・スタンバイ・データベースを使用して構成し、リアルタイム適用すると、Active Data Guardはすべてのタイプのデータ破損を自動的に検出します。また、物理データ・ブロック破損、およびプライマリ・データベースとスタンバイ・データベースの両方での書込み消失破損の自動ブロック修復により、アプリケーションへの影響が回避されます。検出された破損の根本原因を調査するには、Oracleサポートに連絡してください。
-
フラッシュバック・データベースの有効化: フラッシュバック・データベース・ログは、データ破損の自動ブロック修復およびRMANブロック修復に使用できます。
- ASM冗長性およびExadataの使用: さらなる破損の防止、検出および修復
データ破損の検出
破損の検出では、破損の発生後できるだけ早く破損を特定すること、または破損が広範囲に及ぶ前に破損を特定することに重点を置いています。
データ破損を検出するためのベスト・プラクティスとOracleの機能を次に示します。
-
データベース・パラメータの構成:
-
DB_BLOCK_CHECKSUM、DB_BLOCK_CHECKINGおよびDB_LOST_WRITE_PROTECTが予防的なブロックおよび書込みの検証用に構成されていることを確認します。(詳細は予防の項の説明を参照してください)。
-
-
データベース・アラートおよびシステム・アラートの監視:
-
破損関連のエラーまたは警告がないか、Oracleデータベース、OracleクラスタウェアまたはExadataのアラート・ログおよびシステム・ログを定期的に監視します。Exadataは、ストレージ・レイヤー内で破損が検出された場合の追加の特殊なアラートを提供しています。
-
-
データベース・ビューの問合せ:
-
データベース内の既知の破損ブロックの包括的なリストについては、
V$DATABASE_BLOCK_CORRUPTIONを参照してください。
-
-
RMAN検証の活用:
-
RMANバックアップを実行します。これには、デフォルトで物理的破損のチェックが備わっています。
-
BACKUP VALIDATEまたはVALIDATE DATABASEコマンドを使用して、完全バックアップを作成せずに破損を定期的にチェックします。 -
BACKUP VALIDATE CHECK LOGICAL DATABASEを使用して、バックアップ内の論理的な破損を定期的に検出します。
-
-
Oracle Active Data Guardの使用:
-
リアルタイム適用で動作するActive Data Guardおよびフィジカル・スタンバイ・データベースを使用すると、Data Guardは、物理、論理および書込み消失のデータ破損からのすべてのタイプのデータ破損を自動的に検出します。さらに、プライマリ・データベースまたはスタンバイ・データベースの物理データ・ブロック破損および書込み消失破損の自動ブロック修復を容易にし、破損によるアプリケーションへの影響を効果的に防止します。必ずOracleサポートに連絡して、データ破損の根本原因を理解してください。
-
-
Zero Data Loss Recovery Appliance (ZDLRA)またはリカバリ・アプライアンスの使用:
-
リカバリ・アプライアンスは、自動的かつ継続的なバックアップ検証、バックアップの整合性の問題の検出とアラートを提供し、さらなる破損防止と修復の利点を提供します。
-
-
LOBセグメントの破損:
-
一部のLOBセグメントの破損は、標準のデータベース構成パラメータでは検出されない場合があります。この目的のために、新しいPL/SQL検出スクリプトを使用できます。詳細は、My Oracle Supportのノート3084047.1を参照してください。
-
-
ANALYZE ... VALIDATE STRUCTURE CASCADE- Oracleの
ANALYZEコマンドを使用して、表または索引の構造と参照の不整合をチェックできます。不整合をチェックするための句は、VALIDATE STRUCTURE CASCADEです。これらのタイプの論理ブロック間の破損は、推奨されるデータベース・パラメータでは検出されない場合があります。
- Oracleの
- ASM冗長性およびExadataの使用: さらなる破損の防止、検出および修復。検出された破損は関連するログ・ファイルであり、ASMとExadataの両方が、有効なミラー化されたコピーを読み取り、破損したコピーを置き換えるように書き換えることで、破損したコピーを自動的にリカバリします(可能な場合)。これが論理的な破損であるか、ミラー化されたすべてのコピーが破損または損傷している場合、これは機能しない可能性があります。
-
Oracle Enterprise Manager(OEM):
-
破損イベントおよび全体的なバックアップの健全性の自動監視機能を提供します。
-
データ破損の修復
修復戦略は、破損したデータが特定された後の復元または修正、破損したデータの影響の最小化または回避、およびデータ整合性の再確立の試みに重点を置いています。
データ破損を修復するためのベスト・プラクティスとOracleの機能を次に示します。
-
RMANブロック・メディア・リカバリ
-
この非常に効率的な方法では、破損したブロックのみをバックアップからリストアし、リカバリ時間とアプリケーションの停止時間が大幅に削減されます。
-
主に物理データの破損に効果的ですが、推奨される方法に従うと、一部の論理データ・ブロックおよびブロック消失の破損に役立ちます。記事およびドキュメントのトピックへのリンクについては、後述の「参照情報」を参照してください。
-
-
RMANの完全/増分リストアおよびリカバリ:
-
データ・ファイル全体、表領域またはデータベース全体を一貫性のある破損していない状態にリストアするための包括的なリカバリ・オプションが提供されます。
-
-
自動修復およびフェイルオーバーにActive Data Guardを活用:
-
自動ブロック修復: Active Data Guardは、同期されたスタンバイ・データベースから良好なブロックをフェッチすること(またはその逆)で、物理データの破損を自動的に修復できます。Oracle Database 19c R27およびOracle Database 23ai以降、検出されたスタンバイの書込み消失の破損では、透過的修復のために自動ブロック修復機能が使用されます。
- 物理ブロック破損の場合、プライマリ・データベースの自動ブロック修復(つまり、プライマリで破損ブロックが確認され、Oracleがスタンバイから正常なブロックをフェッチして内部的に修正します)では、スタンバイPDBの状態に関係なく、最小適用ラグのスタンバイ・コンテナ・データベースが読取り専用でオープンされている必要があります。スタンバイ自動BMRの場合(つまり、スタンバイで破損ブロックが検出され、Oracleがプライマリから正常なブロックをフェッチして内部で修正します)、少なくともマウントまたはオープンされた最小適用ラグのスタンバイが必要です。
-
書込み消失保護を設定したファスト・スタート・フェイルオーバー(FSFO):スタンバイで書込み消失破損が検出されたときの自動フェイルオーバーを有効にするには、Data Guard Brokerを構成して、ファスト・スタート・フェイルオーバー(FSFO)を有効にし、
DB_LOST_WRITE_PROTECTをTYPICAL以上に設定します。-
自動フェイルオーバーは、FSFOに
CONDITION'LostWrite'を設定することでトリガーできます。 -
または、Data Guardブローカ・プロパティ
PrimaryLostWriteActionを構成できます:-
FAILOVER: FSFOが「最大可用性」モードまたは「最大パフォーマンス」モードで有効になっており、ラグが「最大可用性」でゼロ、または「最大パフォーマンス」でFastStartFailoverLagLimit内にある場合、オブザーバはフェイルオーバーを開始します。 -
FORCEFAILOVER: FSFO (「最大パフォーマンス」モードまた「最大可用性」モードのいずれか)が有効化されている場合、オブザーバによりフェイルオーバーが開始され、データ損失が発生する可能性があります。
-
-
-
-
フラッシュバック・データベースの使用:
-
破損前の時点までデータベースを迅速にリストアできるため、リカバリ時間目標(RTO)が大幅に短縮されます。
-
フラッシュバック・ログは、RMANブロック・メディア・リカバリにも役立ちます。
-
-
ターゲット表/パーティションのリカバリ:
-
特定のオブジェクト・レベルの破損については、RMAN表または表領域のPoint-in-Timeリカバリ、またはData Pumpのエクスポート/インポート(正常なデータの抽出およびロード)を使用できます。
-
-
索引の再作成:
-
索引ブロックが破損している場合、影響を受ける索引を再構築すると、多くの場合、データベースまたは表領域の完全リカバリを必要とせずに問題を解決できます。
-
-
LOBセグメントの破損の修復:
-
新しい修復メカニズムは、特にLOB破損のために開発されています。詳細な手順は、My Oracle Supportのノート3084047.1を参照してください。
-
-
スタンバイ・データベースまたはGoldenGateレプリカへのフェイルオーバー(最も低いRTO/RPO):
-
プライマリ・データベースで破損が発生している場合に、可能なかぎり短いリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)を達成するには、正常なスタンバイ・データベース(Data Guardを介して)またはGoldenGateレプリカへのフェイルオーバーを開始します。これにより、データが破損することなく移行することで、ビジネスの継続性が保証されます。
-
DBMS_REPAIR- Oracleの
DBMS_REPAIRパッケージは、特に物理的または論理的な破損によって通常の問合せまたは操作の完了が妨げられる場合に、データベースの表および索引の破損を特定して対処するように設計されています。破損ブロックを物理的に修正するのではなく、破損ブロックを分離して回避できるため、残りのデータにアクセスおよび管理できます。
- Oracleの
参照情報
- Data Guard構成における破損の検出、防止および自動修復のベスト・プラクティス(ドキュメントID 1302539.1)
- データベース・ディクショナリの不整合: DBMS_DICTIONARY_CHECK PL/SQLパッケージ
- ブロック・メディア修復のガイダンス: ブロック・メディア・リカバリの実行
- 物理ブロックおよび論理ブロックの破損。それに関するすべての情報。(ドキュメントID 840978.1)
- Oracle Databaseの破損の問題に対処するための主要なノート(ドキュメントID 1088018.1)
- フィジカル・スタンバイ・データベースでの論理ブロック破損エラーの解決(ドキュメントID 2821699.1)
- スタンバイ・リカバリ中のORA-00752またはORA-600 [3020]の解決(ドキュメントID 1265884.1)
- ブロック破損、表/索引の不整合、データ・ディクショナリ、および書込み消失の破損拡大の特定(ドキュメントID 836658.1)
- LOBセグメント破損への対処(ドキュメントID 3084047.1)
- OERR: ORA-1578 "ORACLEデータ・ブロックに障害が発生しました(ファイル番号%s、ブロック番号%s)"に関するマスター・ノート(ドキュメントID 1578.1)
- OERR: ORA-8102 "索引キーが見つかりません。オブジェクト番号%s、ファイル%s、ブロック%s (%s)" (ドキュメントID 8102.1)
- ORA-600 [kddummy_blkchk] (ドキュメントID 300581.1)
- ORA-600 [kdblkcheckerror] (ドキュメントID 882875.1)
- 一時セグメントのブロック破損をクリアする方法(ドキュメントID 1332088.1)
- LOBセグメント破損への対処(ドキュメントID 3084047.1)