- テーブルの保全性の検証には、CheckTableの診断中にテーブルが変更されないことが必要です。したがってCheckTableは、テーブルのチェック時に各テーブルに対してREADロックをかけます。CheckTableが、テーブルの基本行とフォールバック行との整合性を確認している間は、INSERTを実行することはできません。
- CheckTableは、DBC.TVMに対して一時的にREADロックをかけて、検査中のテーブルの有無を検査します。また、実施中に表、ビュー、マクロの作成または変更を行なうとロックによる問題が生じる可能性があります。なぜなら、これらの操作にはDBC.TVMに対するWRITEロックが必要だからです。
- ダウンしているAMPが1つ以上あると、CheckTableはテーブルの整合性の検証を完了できないことがあります。
- PRIORITY
CheckTableを実行すると、システム リソース(CPU使用率、ディスク アクセス、スプール領域など)に負担がかかり、システムにアクセスするときのパフォーマンスが低下することがあります。デフォルトでは、CheckTableは、MEDIUM優先順位で実行します。
予想されるシステム ワークロードに基づいてジョブ スケジューリングを制御し、パフォーマンスを向上させるには、PRIORITYオプションを使用します。
- CONCURRENT MODE
このオプションは、ロック プロトコルを最適化してテーブルを逐次チェックすることにより、ロック競合を少なくします。
CONCURRENT MODEでは、CheckTableを完了まで実行することができ、静止していないシステムでデッドロックを回避できます。並行モード(同時実行モード)で使用されるロック プロトコルを最適化して必要なロックの数を最小化し、できるだけ制限の少ないロック タイプを使用します。ただし、進行中のトランザクションによる誤ったエラー報告を回避するために必要なロックもあります。
ロック競合を最小限にしても、アクティブなシステムではブロックが必要です。例えば、チェック中のテーブルにはREADロックがかけられます。したがって、そのテーブルに対する更新操作は、表チェックが完了するまでブロックされます。
CONCURRENT MODE RETRY LIMITオプションを指定すると、CheckTableはロックされたすべてのテーブルをスキップし、これらのロックされたテーブルに対しては、他のセッションによってロックされていない指定されたすべてのテーブルのチェックを完了した後にチェックを再試行します。
RETRY LIMITの値 CheckTableの動作 … 指定しない場合 すべてのテーブルのチェックが正常に終了するまで、ロックされたテーブルに対して繰り返しチェックを再試行し続けます。 CheckTableはロックされたテーブルにアクセスしようとする際、最大5分間ロックが解放されるのを待機します。ロックがその時間内に解放されない場合、CheckTableは次のテーブルに移動します。CheckTableは、ロックされたテーブルに戻って再試行します。
0より大 RETRY LIMITに達するまでチェックを再試行し続けます。 0 スキップしたテーブルに対してチェックを再試行しません。 負 エラー メッセージを表示します。