通常、ジャーナリングは完全性の問題からの回復にとって最も魅力的なアプローチです。これにより、時間および/またはソースに基づく更新の抑止やアプリケーション・レベルの論理トランザクションの保存など、物理的な構成ではなく論理的な構成を使用したリカバリの管理が可能になります。バックワード(backward)ジャーナル・リカバリは一般的に最速の修復手段です。ジャーナリングのコストは、ジャーナル・ファイルを作成して保管するための通常の操作で課される負荷です。ジャーナリングについての詳細は、"GT.Mジャーナリング" の章を参照してください。

バックアップからデータベースを復元することは、整合性の問題を処理するための技術的な洗練が最も小さい方法です。この戦略は、データベース内のデータが静的であるか、または再計算できる場合に最も有益です。それ以外の場合は、バックアップと障害の間に実行された作業を識別し、再入力するための操作上の制御が必要です。MUPIP BACKUP、RESTORE、EXTRACT、LOADの詳細については、「MUPIP」の章を参照してください。また、tar、dump、restoreなどのUNIXユーティリティを使用することもできます。

一部のデータベース領域は、一時的なデータ（通常はGT.Mプロセスの有効期間にのみ有効）を保持するように設定されている場合もあれば、プロセスによって実行される一部の操作中であっても有効です。このような領域を復元するのではなく、MUPIP CREATEを使用して領域を削除してから再作成する方が一般に適切です。

DSEを使用したデータベース修復には、多くのスキルが必要であり、他のアプローチよりも時間がかかる可能性があります。DSEを使用するには、GDSへの油断のない注意と、GDSの明確な理解が必要です。DSEは、通常、データベース・ファイル内のほぼすべてのデータにアクセスして変更できます。DSEを使用する場合は、GT.Mが通常データベース構造の完全性を保証する責任を負うものとします。DSEは他のプロセスと同時に使用される可能性があるため、並行プロセスによる更新は修復処理を妨げる可能性があります。可能な場合は、修復中に他のユーザーが領域にアクセスするのを防いでください。

データベースの修復を選択した場合は、FISやGT.M VAR（Value Added Reseller）など、利用可能な専門知識のソースからアシストを求めてください。あなたの組織が、ファイル・ヘッダーへの直接の修正を超えて修復を実行する計画がある場合、FISは、担当者がMUPIPとGDSとDSEとこの章のINTEGセクションの内容に精通していることを強く推奨します。FISは、プロダクション・ファイルの作業に先立って、テスト・ファイルでDSEを使用することを推奨します。

データベースの整合性の問題の原因を理解したら、将来の損害を防止または最小限に抑えるために環境を修正または改善することができます。これらの変更には、電力系の品質の向上などのハードウェアの再構成が含まれる場合があります； ジャーナリングの実装などの運用手順の変更、 および/または、より管理しやすいサイズのファイルへのデータ割り当てのバランスをとるなど、グローバル・ディレクトリへの変更が含まれます。

次のツールを使用して、データベースの整合性の問題の原因を特定します。