プロセスが正常なキャッシュ操作の主体(principal)に違反したことを検出するか、またはキャッシュ操作が予期せず長い時間を要していることを検出すると、そのプロセスはキャッシュの検証と再構築をトリガーします。このようなイベントは、異常なプロセスの終了、不適切に構成または管理されたデータベース・ストレージ・サブシステムによって引き起こされる可能性があります。

このようなイベントが発生すると、GT.Mは、キャッシュ検証の結果を記述する一連のメッセージをオペレータ・ファシリティに送信します。キャッシュの再構築が成功した場合、それ以上の即時のアクションは必要ありません。キャッシュの再構築が失敗した場合、データベース管理者はデータベースへのアクセスを終了し、DSE（CRITおよびWCINIT）およびMUPIP（INTEG）を使用してキャッシュを手動でリセットし、データベースが損傷していないことを確認する必要があります。

このようなイベントが オペレータ・ファシリティに届いた場合は、異常終了の防止、ディスク・サブシステムの再構成、ディスク操作の性質やスケジュールの変更など、主要な操作期間中にデータベース・アクセスが中断されないように手順を変更するのが適切かどうかを調べる必要があります。

「ハング」という用語は、処理しないことを意味します。プロセスは、GT.Mとは何の関係もない様々な理由でハング・アップする可能性があります。しかし、GT.Mプロセスのハングは、データベースがアクセス不能になっている可能性があります。ハングが疑われる場合は、最初に問題の程度を判断します。

あなたのツールには以下が含まれます：

システムが処理しているプロセスが多いハングの場合、ハングが特定のアプリケーションに限定されているかどうかを判断します。すべてのアプリケーションが影響を受けている場合、またはGT.Mデータベースを使用していないプロセスが影響を受ける場合、この問題はデータベース固有の問題ではなく、 a UNIX の問題などの一般的な 問題です。セクションH6を参照してください。

一つのプロセスだけがハングである場合、そのプロセスは、特定のGT.Mのアプリケーションを使用して唯一のものであるかどうかを調べます。唯一のプロセスであれば、適切な第2のプロセスを開始し、第2のプロセスにも影響があるかどうかを判断します。

他のプロセスが同じデータベースに引き続きアクセスしている間にプロセスがハングする場合、 問題はデータベースの問題ではありません。セクションH2を参照し、次にセクションH8を参照してください。

GT.Mプロセスが特定のアプリケーションを実行しているだけのハングでは、この問題はデータベースの問題である可能性があります。セクションH2を参照してください。

システムは「ハングしていますか？ 」その場合は、次の追加の質問を検討してください：

キャッシュをテストする別の方法は次のとおりです： CRIT がクリアされ、DSE BUFFER がハングした場合、キャッシュは機能していません。MUPIP STOP あるいま/または CRIT -INIT -RESET を使用して、セグメントからすべてを取り除き、DSE WCINITを使用します。WCINITの後、DSEから正常に終了できることを確認します。MUPIP INTEG (-FAST) を使用して、WCINITによって引き起こされる可能性のある損傷をチェックします。

以下の診断手順と参照を使用して、データベース・アクセスの問題に対する適切な処置を決定します。

データが読み書きの両方とも可能な場合 、 問題はデータベースの問題ではありません。セクションH8を参照してください。

データを読み書きすることができない場合、一部のプロセスはデータベース・クリティカル・セクションの完全所有権を解放できません。DSEコマンドCRITICALを使用して、プロセスのプロセス識別番号（PID）を決定します。プロセスが存在する場合は、セクションH4を参照してください。プロセスが存在しない場合は、DSE CRITICAL -REMOVE を使用してリリースをエミュレートし、状況全体を再調査します。

例：

S reg=$V("GVNEXT",""),com="dbcheck.com" o     m-*  com:newv u com
W "$ DEFINE/USER SYS$OUTPUT dbcheck.lis",!,"$ DSE",!
F  Q:reg=""  D
. W "FIND /REGION=",reg,!,"DUMP /FILEHEADER",!
 S reg(reg)="",reg=$V("GVNEXT",reg)
W "$ SEARCH dbcheck.lis ""Cache freeze""",!
; CAUTION: in the above line, "Cache freeze" 
; MUST be mixed-case as shown
W "$ DELETE dbcheck.lis.",!,"$ EXIT",!
C com ZSY "@dbcheck" 
O com C com:delete
W !,"Attempting first access"
S g="^%" D:$D(^%)  F  S g=$O(@g) Q:g=""  D
. S reg=$V("REGION",g) Q:$l(reg(reg))
. I $D(@g)'[0 S reg(reg)=g
. E  S reg(reg)=$Q(@g) 
. W !,"Successful Read in region: ",reg," of ",g
S reg="" F  S reg=$O(reg(reg)) Q:reg=""  D
W !,"Write to region: ",reg 
S @(reg(reg)_"="_reg(reg)) W "–OK"
Q
S reg=$V("GVFIRST"),com="dbcheck" o com:newv u com
W "dse <<yz > dbcheck.lis",!
F  Q:reg=""  D
. W "find -region=",reg,!,"dump -fileheader",!
 S reg(reg)="",reg=$V("GVNEXT",reg)
W "yz",!,"cat dbcheck.lis | grep 'Cache freeze'"
; CAUTION: in the above line, "Cache freeze" 
; MUST be mixed-case as shown
W "|awk '{print $1, $2, $3}'"
C com ZSY "/bin/csh -c ""source dbcheck""" 
O com,dbcheck.lis C com:delete,dbcheck.lis:delete
W !,"Attempting first access"
S g="^%" D:$D(^%)  F  S g=$O(@g) Q:g=""  D
. S reg=$V("REGION",g) Q:$l(reg(reg))
. I $D(@g)'[0 S reg(reg)=g
. E  S reg(reg)=$Q(@g) 
. W !,"Successful Read in region: ",reg," of ",g
S reg="" F  S reg=$O(reg(reg)) Q:reg=""  D
. W !,"Write to region: ",reg 
. S @(reg(reg)_"="_reg(reg)) W "–OK"
Q

このルーチンは、このセクションで説明するタスクの一部を自動化する一般的な方法を提供します。主に組版上の理由から、引数なしのDOコマンドが含まれています。ルーチンは、いずれかの領域がフリーズされている場合にレポートを発行しますが、どの領域がその状態にあるかは報告しません。データベースの読み書きがハングすることがあります。しかし、^% を保持する領域と ^% の後のグローバル領域に問題がある場合を除いて、試行しようとしている領域の名前が表示されます。このルーチンが完了するまで実行されると、現在のグローバル・ディレクトリ内のデータベースに完全にアクセスできます。このルーチンの制限は、1つ以上のグローバル・ディレクトリに関する埋め込み情報を含むカスタム・シェル・スクリプトやM言語プログラムを記述することで解決でき ます。

	注意
	グローバル・ディレクトリを複数のファイルにマッピングする場合、同じファイルへの異なるマッピングを使用して代替グローバル・ディレクトリを作成することができます。そのようなマッピングは、テストプログラムが「実際の」データに触れることを防止します。

例：

Mapping      Production region   Test region
-----------------------------------------------
A   to   M   
$DEFAULT            SCRATCH
N   to   Z   SCRATCH            
$DEFAULT

アクセス速度を上げるために、GT.Mはプロセスとデータベース・ファイルの間で交換されるデータを共有メモリ・キャッシュにバッファリングします。メモリ・キャッシュ内の情報が破損していると、ディスクへのデータ転送がブロックされる可能性があります。

プロセスがデータベースのクリティカル・セクションの完全な所有権を放棄しないように（セクションH3から）決定 された場合、 データベース・キャッシュに問題がある可能性があります。問題の発生場所を特定するには、プロセスを終了します。これによりハングが解消された場合、問題はデータベースにではなくプロセス中にあり、何らかの形で破損しています。セクションP1を参照してください。それ以外の場合、同じ現象を示す別のプロセスが終了プロセスの代わりになります。この場合、キャッシュが破損しています。

キャッシュが破損している場合は、 再初期化する必要があります。キャッシュの初期化中は、他のすべてのデータベース・アクティビティーを停止することが重要です。このセクションに進む前に、セクションQ1を参照してください。

キャッシュの再初期化によるデータベースの損傷を最小限に抑え、問題がキャッシュの破損によるものであることを確認するには、BUFFER_FLUSH に続けて DSEコマンドの CRITICAL SEIZE を使用します。DSEコマンドのBUFFER_FLUSHは、良質な操作であるデータベース・キャッシュをフラッシュしようとします。この操作が完了するまで、少なくとも1分間待ちます。

BUFFER_FLUSH がハングしていない場合、キャッシュは破損していないので、セクションH1から始まる以前のすべてのステップを再調査してください。

BUFFER_FLUSH がハングする場合は、DSEコマンド WCINIT を使用してキャッシュを再初期化します。このコマンドには確認が必要です。正常に動作しているデータベースでは、WCINIT をけっして使用しないでください。WCINITの後には、少なくとも MUPIP INTEG FAST を常に実行して、拡散の危険性がある誘発された損傷を検出します。WCINITコマンドがハングした場合は、セクションH5で説明したようにクリティカルセクションをクリアし、WCINITを再発行します。

並行性制御のメカニズムでは、一度に1つのプロセスだけが「クリティカル・セクション」内のコードを実行できます。データベースにアクセスするには、最初にクリティカル・セクションの所有権を取得するプロセスが必要です。このセクションで説明するエラーは、クリティカル・セクションの所有権の制御に問題が発生した場合に発生します。

クリティカル・セクションを保持しているプロセスを決定した場合（セクションH2からシステムユーティリティを使用している）は、そのプロセスを終了してみてください。これで問題が解決された場合は、クリティカル・セクションではなく、プロセスが損傷していました。セクションP1を参照してください。

プロセスを特定できない場合、またはそのようなプロセスを終了すると他のプロセスに同じ問題が発生する場合、クリティカル・セクションは破損しており、再初期化する必要があります。再初期化中にデータベースの活動を制限してください。このセクションに進む前に、セクションQ1を参照してください。

データベースのクリティカル・セクションを再初期化する： アクティブなデータベース・ファイル上のクリティカル・セクションを再初期化すると、データベースが破損を引き起こす危険をもたらします。再初期化中にデータベースのアクティビティを制限することにより、このリスクを最小限に抑えることができます。このセクションに進む前に、セクションQ1を参照してください。

DSEコマンド CRITICAL INITIALIZE RESET は、データベース・クリティカル・セクションを再確立し、問題のデータベースに現在アクセスしているすべてのプロセスのエラーを誘発します。RESET 修飾子を削除することで、他のプロセスで引き起こされるエラーを回避できます。しかし、この手法では、他のプロセスが部分的に作成されたクリティカル・セクション構造を使用しようとし、おそらくそれらを破損させたり、データベースの内容を破壊したりする可能性があります。

CRITICAL INITIALIZE の後、DSEコマンド CRITICAL SEIZEおよびCRITICAL RELEASEを使用して、クリティカル・セクションの動作を確認します。セクションH3で説明したようなアクションは、適切な操作のためにより完全にテストします。

UNIX 環境で多くのプロセスが正常に実行されていないと判断した場合は、 システムを「ハイジャック」する優先順位を使用しているプロセスがあります。この場合、優先順位が調整されている理由を再確認し、適切な処置を講じてください。そうしないと、UNIX関連の問題が発生する可能性があります。

ディスクのボリュームがOpenVMS (Open Virtual Memory System)へ読み書きができないと判断した場合は、DCLコマンドの SHOW DEVICE /FULLを使用して、正しいボリュームが正しくマウントされていることをチェックしてください。ボリュームを書き込めない場合は、物理デバイスを調べて、書き込みロック・スイッチまたはプラグが妨害されていないかどうかを確認します。

ディスクボリュームが読み込みおよび/または書き込みのためにUNIXにアクセスできないと判断した場合は、dfコマンドを使用して、正しいボリュームが正しくマウントされていることを確認してください。ボリュームを書き込めない場合は、物理デバイスを調べて、書き込みロック・スイッチまたはプラグが妨害されていないかどうかを確認します。

問題を特定できない場合は、ディスク診断を実行してください。多くのディスク診断は破壊的（つまり、ファイルを破壊する）であることに注意してください。他のすべての手段を使い果たすまで、これらの診断は避けてください。破壊的なディスク診断を実行する必要がある場合、またはディスク・スピンドルを交換する必要があると判断した場合は、すぐに回復計画を立ててください。

アプリケーションの問題は、複数のプロセスでM言語の LOCKまたはOPENコマンドが競合したり、M言語の READまたはJOBコマンドの完了を待っているプロセス（非同期イベントに依存しているプロセス）によって引き起こされる可能性があります。

最初に、LKEコマンドの SHOW ALL WAITING を使用しているM言語の ロックについて、プロセスが救援なしで待機しているかどうかを判断します。M言語ルーチンは、LOCKコマンドを使用して相互排他セマフォを作成します。

SHOW COMMAND がHANGする場合、キャッシュ・セクションまたはクリティカル・セクションに問題があります。セクションH5で評価をリスタートしてください。

SHOWコマンドがNO LOCKS WAITING と表示される場合、問題はLOCKの問題ではありません。SHOWを繰り返し使用して毎回存続する1つ以上のLOCKが表示されない場合、問題はLOCKの問題ではありません。ただし、問題がロックの問題ではない場合でも、ハングする可能性がある、MコマンドのJOB、OPEN、およびREADについて説明しているので、このセクションを続行してください。

存在しないプロセスに属すると識別されたLOCKは、異常なプロセス終了の結果です。他のプロセスが競合するLOCKを要求すると、GT.MはそのようなLOCKを自動的にクリアします。

Process 1       Process 2
---------       --------- 
LOCK ^A         LOCK ^B
LOCK +^B        LOCK +^A

Process 1       Process 2        Process 3
---------       ---------        --------- 
LOCK ^A         LOCK ^B          LOCK ^C
LOCK +^B        LOCK +^C         LOCK +^A

 for  quit:$$NEW
 quit
NEW()  lock ^X(0)
 set ^X(0)=^X(0)+1
 quit $$STORE(^X(0))
STORE(x)
 lock +^X(x):10 if  set ^X(x)=name_"^"_bal
 lock
 quit $TEST

Process 1         Process 2
---------         --------- 
LOCK ^A
                  OPEN "MSA0:"
                  OPEN "/dev/nrst0"
OPEN "MSA0:"
OPEN "/dev/nrst0"
                  LOCK +^A

Process 1         Process 2
---------         --------- 
LOCK ^A
READ x
                  LOCK ^A

 for  quit:$$UPD
 quit
UPD()  set x=^ACCT(acct)
 do EDITACCT
 lock ^ACCT(acct) 
 if x=^ACCT(acct) set ^ACCT(acct)=y
 else  write !,"Update conflict–Please Reenter"
 lock
 QUIT $TEST

MUPIP INTEG によって報告されたデータベース・エラーは、影響と重大度が異なります。損害の拡大を防ぐためには、即刻のアクションが必要なものもあります。重大度の低いその他のエラーに対するアクションが遅れることがあります。

次のセクションでは、次のアクション・コースを決定するための一般的なガイドラインと、遭遇する可能性があるエラー・メッセージに関連する情報を含む表を示します。

GT.Mデータベースとグローバル・ディレクトリは、プロダクトの新しいリリースで変更される可能性があります。

バージョンミスマッチを示すエラーが発生した場合は、最初に、ダイレクト・モードからMコマンド WRITE $ZVERSION を使用してGT.Mのバージョンを確認します。

次に、新しいリリースのインストール手順を参照してください。GT.Mの複数のリリースを実行している場合、 環境を定義する 環境変数 を調べ、適切な処置を講じます。

これらのエラーは、ファイル・ヘッダー内のコントロールまたは参照情報の損傷を示します。

「VBNをできるだけ小さく開始する("Start VBN smaller than possible")」は、INTEGがデータベース構造を特定できないことを示します。「ヘッダーはファイル作成が完了しなかったことを示します("Header indicates that file creation did not complete" )」はMUPIP CREATEの問題を示します。このような場合、データベースは事実上失われてしまいます。DSEはこれらの問題を修正することはできません。期待してジャーナル・ファイルを使用する、バックアップから復旧するコストが非常に高いと判断した場合は、FISにコンサルトすることを検討してください。

このタイプの他のエラーを訂正するには、BLK_SIZE=, BLOCKS_FREE=, TOTAL_BLKS修飾子を指定して DSE CHANGE FILEHEADERコマンドを使用します。

「フリー・ブロック・カウンタ..... ("Free blocks counter ...")」は、ファイル・ヘッダー内の空きブロックの数が正しくないことを示します。このエラーは、情報を返す $VIEW("FREECNT",region) と DUMP FILEHEADERにのみ影響します。

ファイル・サイズのエラーはMUPIPを間違って方向づける可能性がありますが、GT.Mランタイム・システムにエラーが発生することはありません。自動拡張は例外で、ファイル・サイズのエラーがあると正しく機能しない可能性があります。自動拡張の問題の1つの可能な症状は、以前に誤って初期化されたデータベースの「古い」末端の部分ビットマップからビジーエラーと間違ってマークされます。

これらのエラーは、合計ブロック数がファイル・サイズと一致しないことを示します。DSN DUMP FILEHEADERを使用して、ファイルの開始VBNとブロックサイズを取得します。次の式を使用して、正しい合計ブロック値を計算します。

((file size - starting VBN + 1) / (block size / 512))      
((ファイルサイズ - 開始VBN + 1) / (ブロックサイズ / 512))

この数式から10進数が求められます。この10進数を16進数に変換し、次に、DSE CHANGE FILEHEADER TOTAL_BLKS=を使用して、合計ブロック数をこの16進数値に変更します。空きブロック数を BLOCKS_FREE= で調整する必要があるかもしれません。これが必要かどうかをMUPIP INTEGが通知し、正しい値を与えます。

これらのエラーメッセージは、データベース・ファイルの検索、オープン、またはアクセスの失敗を反映しています。二次エラー・メッセージを調べて、問題に関する追加情報を入手してください。

printenv を使用して gtmgbldir をチェックするか、またはMコマンド WRITE $ZGBLDIR を使用して、 "ポインタ" が適切なグローバル・ディレクトリを識別していることを確認します。ポインタが適切でない場合は、 gtmgbldir をリセットするか、Mコマンド SET $ZGBLDIR=を使用して適切なファイル名を指定します。

GDEを使用してグローバル・ディレクトリを調べます。グローバル・ディレクトリが適切でない場合は、GDEで修正または再作成してください。GDEの使用の詳細については、「グローバル・ディレクトリ・エディタ」の章を参照してください。

グローバル・ディレクトリが損傷しているがGDEにアクセスできない場合は、変更を実行するためにGDEを使用した可能性のある人物を調べてください。 グローバル・ディレクトリが壊れていて、GDEでアクセスできない場合は、GT.Mとそのユーティリティ以外のプログラムがファイルに書き込んでいる可能性があるかどうか調べてください。GDEを除く、すべてのGT.Mコンポーネントは、グローバル・ディレクトリを静的および読み取り専用として扱います。

グローバル・ディレクトリが正しく表示されている場合は、DCL コマンドの SHOW LOGICALを使用して、使用している論理名が問題が発生したプロセスに対して適切に定義されていることを確認します。プロセスにアクセス権のない環境がある場合は、その環境を確立するために使用したコマンド・プロシージャを慎重に読み取る必要があります。

グローバル・ディレクトリが正しく表示されている場合は、printenv を使用して、使用している環境変数が問題が発生したプロセスに対して適切に定義されていることを確認します。プロセスにアクセス権のない環境がある場合は、その環境を確立するために使用したシェル・スクリプトを慎重に読んでください。

環境変数が正しく現れる場合は、 ls -l を使用し てファイル保護を調べます。ファイルだけでなく、ファイルを見つける際にアクセスするすべてのディレクトリも調べてください。

ファイルがグローバル・ディレクトリによって正しくマップされ、すべての論理名が正しく指定され、適切なアクセスが許可されるよう適切に保護されている場合は、DCLコマンドTYPEまたはDUMPのいずれかを使用してGT.Mとは独立したファイルへのアクセスを確認します。

ファイルがグローバルディレクトリによって適切に配置され、すべての環境変数が適切に配置され、適切なアクセスが許可されるよう適切に保護されている場合は、od または cat ユーティリティを使用してGT.Mとは独立してファイルへのアクセスを確認します。

バージョン・ミスマッチの問題が疑われる場合は、セクションI2を参照してください。

ディスクハードウェアの問題が疑われる場合は、セクションH7を参照してください。

GT.Mは特定のエラーを自動的に修正します。これらのエラーが続く場合は、GT.Mサポートチャネルに連絡してください。

「ブロック・トランザクション番号が大きすぎる」は、ファイル・ヘッダーがデータベース・ブロックより小さいトランザクション番号を持つことを示します。

TP または増分バックアップを実行していない場合、これは問題のないエラーです（データベースの観点からは、アプリケーション・データの一貫性を検証する必要があります）。GT.Mは、データベースの現在のトランザクション番号をどのブロックのトランザクション番号よりも高くするために十分な更新を実行するとすぐに、これらのエラーを自動的に自己訂正します。このエラーが解決しない場合は、次の手順を実行します：

「現在の tn と早い tn が等しくない("Current tn and early tn are not equal")」は、クリティカル・セクションが破損していることを示します。 indicates an improper file close.「参照カウントがゼロでない("Reference count is not zero")」は、ファイル・クローズが不適切であることを示します。疑わしいデータベースを参照する最初のアクセスでは、これらのエラーを修正する必要があります。一般に、これらのエラーはファイルが正常に閉じられなかったことを示します。この問題は、通常、システムの予期しないシャットダウンによって発生します。あなたの施設のシャットダウン手順を見直し、制御されたシャットダウンを確実にしてください。

「アクセス方法を決定できません...("Cannot determine access method...")」は、ファイルヘッダが破損していることを示します。INTEGはこのエラーを検出すると、強制的にBGのアクセス方法を引き続き実行します。ファイルヘッダーに他にダメージがない場合、他のアクションは必要ありません。

ただし、アクセス方法がMMの場合は、MUPIP SET ACCESS_METHOD= を使用してデータベースを修正してください。

MUPIP INTEG は、ファイルへの書き込みアクセスなしで実行できます。ただし、ファイルが不適切にクローズされた場合は、INTEG する前にRUNDOWNでなければなりません。これを行うには、MUPIP はファイルへの書き込みアクセス権を必要とするため、プロセスの特権を増やすか、ファイルの保護を変更するか、より特権のあるプロセスを使用してMUPIP INTEGを繰り返します。

これらのエラー・メッセージは、DSEで実行されたオペレータ・アクションによって作成されます。

DSEコマンドの CRITICAL INITIALIZE RESET、ALL RESET および ALL RENEWは、ターゲット・データベースにアクセスしようとしているすべてのプロセスでCRITRESETエラーを引き起こします。

「破損」フラグがTRUEに設定されているデータベースにアクセスしようとするプロセスは、DBCRPTエラーを受け取ります。

	注意
	DSEコマンドの CHANGE FILEHEADER CORRUPT=TRUEの使用は、非常に危険です。CHANGE FILEHEADER CORRUPT=FALSEを発行する前にDSEセッションがEXITすると、データベースはまったく役に立たなくなります。

このセクションでは、エラー・メッセージが破損したキーを示す場合、適切な処置について説明します。GDSは、添字または添字のないグローバル変数名を、対応するグローバル変数データ値をインデックス付けするために使用されるデータベース・レコードの一部であるキーに変換します。キーは、ブロック内の以前のキーと共通に保持されている接頭辞の部分を省略した圧縮形式で格納されます。圧縮カウントは、共通文字の数です。ディレクトリ・ツリーを除いて、最初のレコードの後のすべてのレコードはゼロ以外のカウントを持ちます。ブロック内の最初のレコードの圧縮カウントは常にゼロ（0）です。

ブロックがデータブロック、つまり、レベル0の場合、セクション O3 を参照してください。

ブロックにゼロ(0) より大きいレベルの値がある場合、DSEコマンドの DUMP BLOCK=OFFSET を使用してレコードを調べます。ここで、ブロックおよびオフセット値はINTEGエラーレポートによって提供されます。レコードに有効なブロック・ポインタがあるように見える場合は、ポインタをメモします。それ以外の場合は、セクションO2を参照してください。

ポインタに注目した後、SPAWNを行い、MUPIP INTEG BLOCK=pointerを使用して（時間の制約がある場合は、FAST修飾子を使用して）構造をチェックすることができます）。

サブ・ツリーが無効である場合、MUPIP INTEGに従って、DSEは、報告されたバッド・キー、INTEGを含むレコードをREMOVEし、そして、セクションO4を参照してください。

それ以外の場合は、DUMPコマンド BLOCK= RECORD=9999を使用してブロック内の最後のレコードを検索し、DUMP RECORD= コマンドを使用して調べます。DSEを使用して、レベル0 までポインタをたどることを続けて、常に右側のブランチを選択します。データレベルで最大のキーに注意してください。報告された不良キーを含むレコードをREMOVEします。FIND KEY= と ADD KEY=POINTER を使用して、指定されたキーの適切な配置を決定します。ここで、キーとポインターは、以前のアクションで指摘されたものです。

エラーがキーの付け間違いである場合、キーは適切な照合順番になっていません。

もしブロックがデータ・ブロックの場合、つまり、レベルゼロ（0）、それにGLOをDUMP、それを指し示すレコードをREMOVEし、それをFREEにMAPし、DUMP GLOの出力を MUPIP LOAD します。

ブロックがレベルが0より大きい場合は、その適切な場所にレコードの位置変更か、セクションO4で説明したサルベージ戦略を使用するかを選択することができます。一般的に、サルベージ戦略はそれほど厳しいものではなく、危険性も低いです。ただし、レコードを保持するインデックス・ブロックのレベルが1よりもはるかに大きい場合は、時間がかかることがあります。サルベージ戦略に反対する決心をする場合は、破損したレコードの内容を書き留めます。いずれの場合も、レコードをREMOVEしてください。サルベージを使用する場合は、セクションO4を参照してください。そうでない場合は、FIND KEY= を使用してレコードの適切な場所を特定し、最も近い既存のパスを表示してから、K1の最後の段落に記載されている手順に従います。

二重に割り当てられたブロックは、データが不適切に混在を引き起こすので、危険です。KILL が発生しない限り、二重割り当てによって追加のデータが永久に失われることはありません。ただし、アプリケーション・プログラムがエラーや不適切な結果を生成する可能性があります。ブロックが二重に割り当てられると、KILLは適切な範囲外のデータを削除する可能性があります。

二重に割り当てられたインデックス・ブロックは、またブロックの数が増加する原因となる可能性があります。問題を解決するには、次の手順を使用します。

最初に、FIND EXHAUSTIVE および/または MUPIP INTEGによって報告された情報を使用して、ブロックへのすべてのポインタを識別します。エラー報告により、ブロックに不適切なキーまたは不良レベルが含まれていると特定された場合、INTEG は、ブロックを含むすべてのパスを識別しました。その場合、INTEGは、二重に割り当てられたエラーを持つ最初のパスの後のすべてのパスと、「キーの順序が間違っている("Keys out of order")」エラーなどの最初のパスを報告します。

INTEGレポートが「二重に割り当てられたエラー」の前にブロックを認識していない場合は、FIND EXHAUSTIVEを使用してそのブロックへのすべてのポインタを識別します。

もしブロックがデータ・ブロックの場合、つまり、レベルゼロ（0）、それにGLOをDUMP、それを指し示すレコードをREMOVEし、それをFREEにMAPし、DUMP GLOの出力を MUPIP LOAD します。

ブロックのレベルがゼロ（0）より大きい場合、ブロックとその子孫をソートして、混在したデータを区切ります。ブロックのレベルが1より大きい場合は、試してみる価値があります。サルベージ戦略（セクションO4で議論されている）は時間がかかり、誤った配置のノードが1つしかないかもしれません。しかし、一般的に、サルベージ戦略はそれほど厳しくなく、危険性は低いです。

サルベージ戦略を選択した場合は、ブロックを指し示すレコードをREMOVEし、それをFREEでMAPし、セクションO4を参照してください。

BLOCKで作業することを決定した場合は、保持するパスを選択し、他のポインタレコードをREMOVEし、DSE ADDとREMOVEを使用して間違った子孫を再配置します。

各インデックス・ブロックは、キーと対応するポインタを含むレコードで構成されています。データベースの損傷が、有効なポインタと対になった不正なキーの症状である場合、いくつかの策略で実装できる、修復の戦略は、ポインタを使用してデータを探し出しキーを再構築することです。

それらは非常にまれにしか発生しませんが、無効なポインタは同じ戦略を可能にしません。無効なポインタがある場合は、DSE REMOVEコマンドを使用して、不良ポインタを含むレコードを削除してください。無効なポインタの下にデータを格納することはできないため、最初の使用時にポインタ・エラーが検出され、データが失われていないか、使用中にポインタが破損しています。使用中にポインタが破損した場合、失われたデータは、「間違ってマークされたビジー状態のブロック」エラーを調べて見つけ出し、一般にセクションO4で説明したように回復する必要があります。

多くのデータが失われた場合は、次のように不良レコードを再構築を試みることをお勧めします。不良ポインタを含むレコードを削除する前に、DUMPコマンドを使用してレコード内のキーに注意してください。エラー・レポートまたはDSE RANGEコマンドを使用して、キーが指すブロックを見つけます。その後、DSE ADDを使用して、以前に削除したレコードを、正しいキーとポインターを含む新しいレコードで置き換えます。

すべてのインデックス・ブロックの最後のレコードは、ブロック内の先行レコードによってカバーされていないすべてのデータへのパスを継続するブロックを指すスター・キー・レコード(star-key record)でなければなりません。スター・キー・レコードは、プラットフォームに応じてサイズが 7、8、そして圧縮カウントがゼロ（0）のユニークな形式です。このセクションで説明するエラーは、スター・キーが無いか破損していることを示しており、2つの戦略で攻撃される可能性があります。

一般に、最後の既存のレコードをスター・キーにする必要があります。ブロックが少なくとも1つの有効なレコードを保持している限り、これはうまく動作します。この戦略を選択した場合は、DUMP RECORD=9999 を使用して最後のレコードを探します。最後のレコードをDUMPし、そのポインタを書き留めます。次に、最後のレコードをREMOVEします。最後に、書きとめたキーにADD STAR POINTER=をします。

スター・キーがルート・ブロック内の唯一のレコードである場合は、新しい空のレベル 0 の子孫を追加する必要があります。この戦略を選択する場合は、FIND FREEBLOCK HINT=this-block を使用して新しいスター・キーを追加して、近くのブロックを探します。次に、新しいブロック BUSY と CHANGE LEVEL=0 と BSIZ=7（またはプラットフォームに応じて 8 ）をマップします。新しいブロックのレベルがゼロ（0）であれば、損傷したブロックに戻り、そして ADD STAR POINTER=the-first-new-block を行います。

「圧縮カウントが最大ではない("Compression count not maximal")」 は、キーの記憶域のスペースを節約するために使用される圧縮カウントが正しくないことを示します。

もしブロックがデータ・ブロックの場合、つまり、レベルゼロ（0）、それにGLOをDUMP、それを指し示すレコードをREMOVEし、それをFREEにMAPし、DUMP GLOの出力を MUPIP LOAD します。

ブロックが 0 より大きいレベルのブロックを持っている場合は、レコードをREMOVEし、同じ KEY= と POINTER= または STAR を使用して同じ場所にADDして戻します。

CHANGE CMPC= を使用して圧縮カウントを調整することもできます。これは、ブロック内のすべての後続キーの値を変更するため（スター・キーを除く）、これらのキーも正しく表示されない場合にのみ、この代替方法を試してください。

「データベースの最大値が大きすぎます("Key too large for database maximum" )」とは、データベースがGT.Mに正規であるがデータベースのKEY_MAX_SIZEを超えるキーを保持していることを示します。

ファイル制限を調整するには、DSEコマンドの CHANGE FILEHEADER KEY_MAX_SIZE=を使用します。または代わりに、先祖ノードでMコマンドKILLを使用して、レコードを削除することもできます。キーの長さが長い間にデータベース内のレコードを変更または置換しようとすると、GT.Mはエラーを返してSETを拒否します。

ファイル内のすべてのブロックには、対応するビットがビットマップ内にあります。有効なデータを持つすべてのブロックは、マップ内で使用中(busy)とマークされます； 使用されていない、またはもはやデータを保持していないブロックはすべて空き(free)としてマークされます。GDSはビットマップを使用して空きブロックを効率的に配置します。このセクションで説明するエラーは、ビットマップの問題を示します。

「ブロックが間違ってフリーとマーク("Block incorrectly marked free")」は、 潜在的に危険なビットマップエラーだけです。このエラーは、ブロックが Bツリー構造内にあることを意味しますが、ビットマップが使用可能であることを示しています（つまり、起動を待っている「"二重に割り当てられたブロック("Block doubly allocated")」" です）。このようなブロックをBUSYにMAPするには、すぐにDSEを使用します。

ビットマップ情報は冗長です（つまり、ビットマップはB-ツリーをスキャンして再作成できます）； しかし、ビットマップ・エラーの大半は、B-ツリーの脆弱性に起因する2次的なエラーを反映しています。これは、MUPIP INTEGによってキーまたはデータ・エラーとして報告されることがよくあります。

INTEG はエラーを検出すると、ツリーのその枝葉の処理を停止します。その後、生成されたビットマップをデータベース内のビットマップと比較すると、「ブロックが間違ってビジー状態になった("Block incorrectly marked busy")」と検出されなかったツリーに属するブロックがレポートされます。このエラー・タイプは、インデックスが中断された紛失データのブロックの位置をマークするフラグとして見ることができます。

INTEGは、それが間違ってマークされたと結論づけられた各ブロックと、"bad" ビットを保持するローカル・マップを報告します。さらに、ローカル・マップ「エラー」が、ローカル・マップがマスター・マップ内ででフルになっているかどうかに影響を与える場合、INTEGはマスター・マップに（潜在的な）問題も報告します。したがって、レベル1 のインデックス・ブロック内の1つのエラーは、それ自身に加えて、1つ以上の「間違ってビジー(busy)とマークされたブロック("Block incorrectly marked busy")」、1つ以上の「ローカル・ビットマップの誤り("Local bitmap incorrect")」、および場合によっては1つ以上の「マスター・ビットマップ("Master bitmap shows...")」を生成します。高レベルのインデックス・ブロックでエラーは、非常に多数のビットマップ・エラー・レポートが発生する可能性があります。

通常、ビットマップ・エラーは他のエラーよりも優先順位が高いため、プライマリ・エラーを修正すると通常はビットマップエラーも修正されます。この理由から、さらに重要なのは、ビットマップ・エラーは「失われた」データの位置を特定する傾向があるため、修復セッションのクローズ時または終了時に常に修正する必要があります。

DSEコマンドのMAPは、ローカル・マップ内のビットをFREEおよびBUSYで切り替え、MASTERを使用してローカル・マップのステータスをマスタ・マップに伝播し、RESTOREを使用してB-ツリーからすべてのマップを完全に再構築する方法を提供します。すべての非ビットマップエラーが解決されるまで、MAP MASTERは使用しないでください。

ビットマップは、プラットフォームのユークリッド順に応じて、マイナス1（-1）およびブロック・サイズ 87 または 88 のレベルの一意のヘッダー形式を持つブロックに格納されます。このセクションで説明するエラーは、その形式に違反するビットマップ・ブロック・ヘッダーを示します。

BSIZ=87 または 88（プラットフォームに依存）および LEVEL=-1FF 修飾子を持つDSEコマンドCHANGEを使用して、問題を修正します。ブロックサイズが小さすぎる場合は、MAP RESTOREを使用してビットマップを再構築するか、MAP FREEを使用して INTEGエラーレポートから手動でビットマップを再構築する必要があります。他のエラーがある場合は、修復されるまでMAP RESTOREを延期します。

GDSは、B-ツリーを論理ブロックに構成します。論理ブロックは、それぞれGT.Mが離散的に処理します。ブロックは、ブロック・ヘッダーと字句的に増加するレコードのシーケンスで構成されます。ルート・ブロックから始まりデータ・ブロックまでのブロックはインデックス・ブロックです。完全なパス内の最後のブロックはデータ・ブロックです。このセクションで説明するエラーは、破損したブロックを示しています。

DSEコマンドのINTEGRITを使用して、ブロックに他の問題があるかどうかを判断します。DSEコマンドのDUMPを使用してブロックの内容を調べます。このブロックの前にあるブロック、および/または、このブロックのレコードが指すブロックを調べることもできます。適切なアクションを決定できる場合は、BANZ= および/または LEVEL= 修飾子を付けてCHANGEを使用してください。ブロックをすばやく修復できない場合は、DUMP HEADERでそのレベルを調べます。ブロックがデータブロック、つまり、レベル0の場合、セクション O3 を参照してください。ブロックのレベルが 0 より大きい場合は、ブロックを指すレコードをREMOVEし、セクション O4 を参照してください。

GDSは、ポインターやデータでキーを編成してレコードを形成します。レコードには、レコード・サイズを保持するヘッダーと、このレコードによって先行するキーがどれくらい共通に保持されているかを識別する圧縮カウントがあります。ブロック内のレコードは、キーの値によって順序付けられます。このセクションで説明するエラーは、レコードの破損を示します。レコードエラーは、GT.Mが同じブロック内の後続のレコードを正しく解釈することを潜在的に防止するという点で、追加の課題を提示します。

ブロックがデータブロック、つまり、レベル0の場合、セクション O3 を参照してください。

ブロックがインデックス・ブロックである場合、つまりゼロ（0）より大きいレベルを持つ場合、最良の選択肢は一般にセクションO4で説明したサルベージ戦略を使用することです。破損したレコードをREMOVEし、ブロックをINTEGします。ブロックがまだ壊れている場合は、最後のステップを繰り返し、ポインタをREMOVEしてMAPを解放します。いずれの場合も、セクションO4を参照してください。

このセクションで説明するエラーには、ヘッダー、レコード、またはキーの損傷が含まれます。

ブロックのレベルが0（ゼロ）の場合は、DSE DUMPを使用してブロックの内容を調べます。問題を解決するための情報や、絶滅のおそれのあるデータを特定して再作成するのに役立つ情報に注意してください。GDSと16進表記に精通している場合は、DSEが不揃いで認識できないデータを認識することができます。

ブロックの開始が有効な場合、DUMP GLOは破損している箇所まで内容を取り込むことができます。最悪の場合は、ブロックをポイントするレコードをREMOVEし、MAPをFREEにし、その内容全体を失います。損傷の程度と重要性は、ブロックのサイズとそれを保持する必要があるかどうかによって異なります。類似しているがかなり劇的ではないケースでは、問題を持つレコードをREMOVEし、そのレコードの内容を失います。

この戦略では、ビットマップ・エラーを使用して、B-ツリーに属する情報を含むデータ・ブロックを特定しますが、エラーおよび/またはインデックスの修復のためにインデック付けされません。

このアルゴリズムは、ほとんどのビットマップ・エラーがインデックス・エラーの2次的なものであるという事実に基づいています。したがって、ビットマップについては楽観的であり、インデックスについては悲観的です、B-ツリーへのデータよりもむしろより多くのデータをレストアする側でエラーになりがちです。この手法を使用した後は、用いられなくなったデータが復元されたかどうかを常に確認する必要があります。データがレストアされ、GDSの整合性がレストアされた場合、「余分な」データを安全にKILLすることができます。

インデックスがある時期に損害を受け、損害により重複キーを作成することを引き起こした場合、この戦略は、どの値が「正しい」値であるかの問題を提起します。ほとんどのアプリケーションは、単にノードをオーバーレイするよりはむしろ、新しいノードを形成するか、既存のノードを更新するかどちらかのため、この問題はほとんど発生しません。通常、アプリケーションは「間違った」ノードを更新しようとすると失敗します。問題が発生した場合、問題は、「正しい」値ではなく、利用可能な最良の値を、決定していない可能性があります。

重複したノードの問題がアプリケーション問題である可能性がある場合、重複したノードを検出して報告するMプログラムを使用して、DSEで作成されたシーケンシャル・ファイルをロードできます。ブロック・トランザクション番号は、ブロックが更新された順序の手がかりとして使用することもできます。ただし、通常、最後の更新でどのレコードが変更されたかを知ることができず、DSE修復アクションによってブロック・トランザクション番号が変更されることを覚えておいてください。

重複ノードの問題が重大な問題を引き起こす場合は、DSEを使用してデータベースを修復するのではないかわりに、ジャーナルを使用してバックアップからリカバリまたはリストアを行うことをお勧めします。

この戦略は、欠落しているインデックスがレベル1（1）である場合に効果的です。しかし、失われたインデックスのレベルが増加するにつれ、必要な時間は劇的に増加します。レベル4（5）またはレベル5（5）のインデックスの問題に悩んでいて、DSEでスキルを発達させている場合は、技術的に要求の厳しい指標を修復することをお勧めします。

ビットマップ・エラー以外のすべてのエラーを修正したら、SPAWN と MUPIP INTEG FAST REGION NOMAPを使用して、残りのビットマップ・エラーのリストを取得します。レポートに「空きブロックが間違ってマークされています("Blocks incorrectly marked free")」というメッセージが含まれている場合は、それらのBUSYをMAPしてください。次に、DUMP HEADER BLOCK= を使用して、それぞれ「間違ってマークされたビジー ("Block marked marked busy")」を調べます。レベルが 1 の場合、ブロックGLOをDUMPします。いずれにしても、それをFREEにMAPします。このように、すべてのブロックがシーケンシャル・ファイルで収集されたら、MUPIP LOADを使用してシーケンシャル・ファイルからデータを再利用します。

例：

salvage;
  read !,"SET REGION to <DEFAULT>: ",r s:r="" r="DEFAULT"
  write !
  set in="db_integ.log",x="mupip integ -fast -nomap -region"
  set teg="/bin/csh -c """_x_" "_r_" > "_in_""""
  zsystem teg
  set out="db_drive",skip=$char(32,10,13)
  set prefix="map -bl=",old="",lenold=0,blk=0
  open in:(read:exc="goto done"),out:newv
  use out
  write "dse <<yz",!,"find -region=",r,!,"open -file=","db.go",!
  use in
  for  read x if x["marked" use out do out use in
  ; CAUTION: in the above line, "marked" MUST be in lower-case
  ;
done
  use out
  write "close",!,"exit",!
  write "yz",!
  write "mupip load db.go",!
; comment out the line above if you wish to examine
; db.go and initiate the load separately
  close in,out
  zsystem "/usr/local/bin/tcsh -c ""source db_drive"""
  quit
out
  for j=1:1:$length(x) quit:skip'[$extract(x,j)
  set blk=$piece($piece($extract(x,j,999)," ",1),":",1)
  set state=$select($extract(x,42)="f":" -busy",1:" -free")
  ; CAUTION: in the above line, "f" MUST be in lower-case
  if state=" -free" write "dump -glo -bl=",blk,!
  ; CAUTION: in the above line " -free" MUST match the
  ; case in the $select above
  ; comment out the above line (starting with "i state")
  ; if you wish to eliminate, rather than save,
  ; the contents of loose busy blocks
  write prefix,blk,state,!
  quit

このルーチンでは、このセクションで説明する手法を自動化するための基本的な例を示します。これは、適切に定義された gtmgbldirを持つ適切なディレクトリから実行する必要がありますが、 より使いやすいように拡張することができます。

次の例は、破損したスパニング・ノードを ^mypoem に保存する方法を示しています。

損傷したプロセスとは、内部的に「混乱("confused")」し、外部環境の状況に起因しない病理的な方法で実行されているプロセスです。

プロセスが壊れていることが判明した場合は、そのプロセスに関連するすべてのイベントを慎重にレビューし、問題の発見につなげてください。プロセスが優先順位が高く、ハングアップしていない可能性がありますが、むしろ、システムリソースを「ホッギング("hogging")」していた可能性があります。問題はアプリケーション・ループの問題であり、セクション H3の手順を十分に厳格に実行しないと失われている可能性もあります。

プロセスに損傷を与える可能性のあるハードウェアの問題の証拠をチェック してください 。

システムをシングル・ユーザー状態にする、または、適切なクラスまたは適切なユーザーのためにGT.Mコンポーネントへの実行アクセスを削除するなど、新しいユーザーがデータベースにアクセスしようと試みることを防ぎます。また、問題のデータベースにアクセスするすべてのプロセスを、UNIXの ps -af ユーティリティを使用して終了または中断して、そのプロセスを検出します。DSEコマンドのCRITICAL -INITIALIZE -RESET は、データベース・ファイルにアクセスするすべてのプロセスでエラーを生成するため、このようなプロセスを迅速に停止することができます。

GT.Mプロセスは、実行時にエラーを検出することがあります。これらのエラーは、GT.Mエラー処理メカニズムをトリガします。これは通常、プロセスをダイレクト・モードにします。または、アプリケーション・プログラムをトリガしてエラー・コンテキストをシーケンシャル・ファイルまたはグローバルに転記します。For more information on error handling, refer to the "Error Processing" chapter of the GT.M Programmer's Guide.

ほとんどの実行時エラーは、アプリケーションとその環境に関連しています。しかし、一部のエラーは、プロセスがデータベースを適切に処理できないことを反映しています。このタイプのいくつかのエラーは、GT.Mユーティリティ・プログラムによっても生成されます。

個々のエラーの説明については、「GT.Mメッセージ＆リカバリ手順リファレンス・マニュアル」を参照してください。

このようなエラーを、同じタスクを実行する別のプロセス、または適切に指導されたMUPIP INTEGを使って再現できない場合は、損傷したプロセスによって報告された可能性が最も高いです。この場合は、セクションP1を参照してください。

次の表は、実行時エラーをニーモニックのアルファベット順に一覧表示しています。

これらの実行時エラーは、プロセスがデータベース本体内で整合性エラーを検出したことを示します。

エラーメッセージに表示されているグローバル変数の直下ノードを指定して、MUPIPコマンド INTEG SUBSCRIPT= を使用してエラーを確認します。または、別のプロセスで同じルーチンを実行するか、ダイレクト・モードを使用してエラーをトリガーしたM行によって実行されたアクションと同じアクションを実行して、アクセスを試みることができます。エラーを再現できない場合は、セクションP1を参照してください。

これらのエラーの大部分は、4文字のエラー・コードで終了します。コード内の各文字は、データベース・アクセスを実行しようとするときの失敗の種類を表します。文字がすべて同じでない場合は、プロセスが最後の再試行を行ったときに何が起きたかを反映するため、最後のコードが最も重要です。以前の試行では、最後のエラーのコンテキストを確立するために重要なエラーコードが表示されます。

次の表は、MUPIP INTEG、コードの意味の簡単な説明、および詳細情報を見つけるためのセクション参照が必要かどうかにかかわらず、失敗コードを示しています。

これらのメッセージは、可能性のあるプロセスの損傷またはデータベース・キャッシュの破損を示します。別のプロセスでアクションを再試行してください。2番目のプロセスも失敗した場合は、セクションH4を参照してください； それ以外の場合は、セクションP1を参照してください。

These errors indicate the process received a message from a kill system これらのエラーは、イメージが終了することを要求する kill システム・サービスからのメッセージを受信したプロセスを示してい ます。

MUPIP STOP コマンドは、区別コードで kill を使用し ます。MUPIP STOPによって提供されるコードでは、エラー・メッセージに stop ディレクティブのソースを含めることができます。

データベースがいっぱいで拡張できない場合、データベースに新しい情報を追加しようとするプロセスは、実行時エラーを経験します。次の条件では、データベースの自動拡張ができません。

最初の2つのケースは、MUPIP EXTENDコマンドを使用して処理できます。MUPIP EXTEND は、ファイル・ヘッダに指定されている拡張子よりも小さい拡張子を許可することで、3番目のケースを処理するのに役立ちます。ファイル・ヘッダーの拡張サイズ、または MUPIP EXTEND へ /BLOCKS= 修飾子はGDSブロック内にあり、ビットマップのオーバーヘッドは含まれていないことに注意してください。

ボリューム上にスペースがなければ、MコマンドのKILLを使用してデータベースからデータを削除することができます。グローバル全体をKILLするには、データベースファイルに1つの空きGDSブロックが含まれている必要があります。一連の添字のあるノードをKILLするか、小さな拡張を行うことで、これらを得ることができます。

また、tar、cp、lprm などの UNIXユーティリティを使用して、ボリュームからファイルを削除し、別のボリュームに配置することもできます。

最後に、DCLコマンドの MOUNTによって呼び出されるMOUNTユーティリティーを使用して、バインドされたボリューム・セットを作成または追加することができます。ファイルのRMS配置を変更する場合は、グローバル・ディレクトリおよび/または論理名を新しい環境に合わせて調整してください。

新しいディスクを追加することもできます。ファイルの配置を変更する場合は、グローバル・ディレクトリおよび/または環境変数を新しい環境に合わせて調整してください。

GTMASSERT と GTMCHECK のエラーは、プロセスがある種の論理的不一致を検出したことを示します。エラーを取り巻く状況に関するすべての情報を収集した後、FISに相談してください。

これらのメッセージは、複数のプロセッサー同期の可能性のある問題を示しています。ハードウェア診断の実行を開始します。診断で問題が見つからない場合は、エラーの状況に関するすべての情報を収集した後、FISと相談することを検討してください。

7つ以上のレベルを含むツリーをデータベースに作成しようとしました。ツリーの正規レベルは0〜7です。グローバルに新しいレベルを追加するには、既存のサブスクリプトの一部を削除するか、グローバルを抽出してより大きなブロックサイズのデータベースにリロードして、大きなツリーを必要としないようにします。

通常の操作ではそうではありませんが、データベース・ファイルへの読み取り専用アクセスを持つプロセスは、処理に十分なキャッシュ領域を取得できないため、失敗する可能性があります。データベースに書き込む権限がないため、そのようなプロセスは変更されたキャッシュ・レコードをディスクにフラッシュすることができません： データベースへの読み取り専用アクセスを許可するポイントまで、変更されたレコードの数を維持するために、成功します。ただし、更新プロセスが変更されたレコードをフラッシュすることを許可しない方法で終了すると、キャッシュが十分なブロックを供給できないため、読み取り専用プロセス（特に大きなトランザクションを実行するプロセス）が失敗する可能性があります。この状態は、影響を受ける領域内のDSE BUFFERコマンドでクリアできます。