整合性チェックのオーバーヘッドを最小限に抑えながら、一貫性のある検証の方針は、データベースの破損における迅速な識別と修正のプロセスを促進します。GT.Mでは、この方針で論理的にGDSの整合性を検証するために、MUPIP INTEGとその数多くのオプションを中心に開発されています。MUPIP INTEGの詳細については、"MUPIP"の章を参照してください。以下のセクションでは、MUPIP INTEGを実行することが適切な処置である状況について説明します。
GTMASSERT は、通常のユーザー・メッセージに加えてオペレータ・ログ・メッセージを送信します。これらは潜在的に危険な状態であるため、すべてのGTMASSERTは直ちにFISに報告されるべきです。必要に応じて、できるだけ早く、 -FAST 修飾子を使用してデータベースの整合性をチェックしてください。GT.MのCHECKは、GTMASSERTに似ていますが、あまり洗練されていません。操作ログ・メッセージを送信しません； ただし、プリンシパル・デバイスにメッセージを送信します。
監視されていないイベントや報告されていないイベントがデータベースを壊さないように、INTEGを定期的にスケジュールします。これらの定期的なチェックは、損傷したポインタの発生を最小限に抑えます。これにより、ファイル内の誤った場所が更新され、損傷が拡大する可能性があります。
それらが必要とする時間と、データベース構成全体に対する相対的価値のために、大量の情報をデータベースの内外に移動させる操作にはINTEGを伴うことが必要です。INTEGは、MUPIP EXTRACTなどの出力操作に先行し、MUPIP LOAD、RESTORE、およびJOURNAL RECOVERなどの入力操作に従います。
大量の情報転送が一貫して発生は、データベースのバックアップ中に発生します。多くの場合、致命的なイベントからの正常なリカバリは、データベースの信頼できるバックアップ・コピーの取得に依存します。したがって、バックアップ手順は、データベースの整合性の検証を補完するように設計する必要があります。バックアップがディスクに対して行われているときは、バックアップ・コピーを作成した直後にバックアップコピーをINTEGすることが最速の方法です。バックアップがGDS形式でない場合は、INTEGをバックアップの前に置く必要があります。
ハードウェアまたはオペレーティング・システムの障害などの破滅的なイベントの直後に、INTEGが続く必要があります。障害の原因を判別するには、システム・エラー・メッセージ、オペレーター・メッセージ、システム・ログ・ファイル（使用可能な場合）を調べます。
GT.Mランタイムシステムがデータベースアクセスエラーを報告すると、データベースの整合性をチェックします。セクション R1 の表には、システムの問題を示す実行時エラーがすべてリストされています。これらのエラーの大部分には、INTEG、または、表に示されているセクションで説明した適切な選択肢の1つが必要です。