表に対して更新・挿入・削除を繰り返すことにより、データの保存状況が劣化して、望ましいパフォーマンスが得られなくなる場合がある。このため、定期的に状態の確認を行い、必要に応じて表・索引の再編成を行う必要がある。このために必要とされるコマンドは、REORGCHK・REORG・RUNSTATの３つである。
REORGCHKは、表・索引の物理編成に関する情報を収集するためのプログラムである。その書式は以下の通り。
REORGCHK [CURRENT STATISTICS]
ON TABLE (tablename | ALL
| SYSTEM | USER )
このコマンドでは、以下のような指標を見ることが出来る。
これらの指標について、推奨範囲を超えた場合には、その旨の表示が行われる。
REORGCHKコマンドを実行した結果、再編成を行うべきであることが判明した場合には。REORGコマンドを実行する。REORGコマンドは、全ての未使用スペースを削除し、表および索引データを連続するページに書きこむ。DB2では、削除された行には削除フラグが立てられるのみで、その領域は利用可能にならない。おおむね、表の３割が変更されるごとにREORGが必要と言われている。
REORGコマンドの構文は以下の通り。
REORG TABLE tablename INDEX indexname USE temporarytablespace
INDEXパラメータを使用すると、表のデータは索引の物理順にしたがって並べ替えられる。但し、更新時にはこの順番は保存されない。
REORGコマンドを実行すると表の記憶属性が変化するので、RUNSTATコマンドを引き続いて実行する必要がある。
RUNSTATコマンドは、OracleのANALYZEコマンドに相当するもので、表の記憶属性を調べてシステムカタログに保存するものである。これにより、オプティマイザが最適なアクセスプランを選択できるようになる。
RUNSTATコマンドの構文は以下の通り。
RUNSTAT ON TABLE tablename
[ ( AND [DETAILED] INDEXES ALL
| FOR [DETAILED] INDEXES ALL ) ]
[ WITH DISTRIBUTION ]
[ SHRLEVEL (CHANGE | REFERENCE) )]
このコマンドを実行しない場合、システムカタログの記憶属性を示すカラムには-1が入っている。獲得された記憶属性は、動的SQLのアクセスパス作成にはすぐに利用されるが、静的SQLには適用されないため、REBINDコマンドを実行してパッケージをバインドしなおすことが必要となる(db2rbindユーティリティで全てのパッケージを一括してバインドすることが出来る)。
なお、テスト環境で本番環境のアクセスプランをシミュレートしたい場合などは、システムカタログSYSSTAT内にあるテーブルの統計情報を更新することで行うことが出来る。
ストアドプロシジャやユーザ定義関数は、通常はDB2 UDB本体とは別のアドレス空間で実行する。プロシジャの安全性が確保できている場合、これらを同一のアドレス空間で実行するようにして、パフォーマンスを最適化することが出来る。このためには、CREATE_NOT_FENCED特権が必要である。
インスタンスで実行中のアプリケーションは、以下のコマンドで表示することができる。
LIST APPLICATIONS [FOR DATABASE database-id] [SHOW DETAIL]
特定のアプリケーションを強制的に終了するためには、LIST APPLICATIONSコマンドでアプリケーションIDを取得し、FORCE APPLICATIONコマンドを実行する。
FORCE APPLICATION (application-id | ALL)
DB2 UDBは、開始状態とは別に、活動状態というものがあり、メモリの割り当てなどに関係してくる。通常、最初のアプリケーションが接続することで活動状態になり、最後のアプリケーションが切断することで非活動状態になるが、ACTIVATE DATABASEコマンドを投入することで常に活動状態にすることができる。ACTIVATE DATABASE状態は、DEACTIVATE DATABASEコマンドを投入することで解除できる。インスタンス中の活動データベースの状態は、LIST ACTIVE DATABASEコマンドを投入することで確認できる。
トップページに