クエリー・パトローラー・センターまたは Query Patroller コマンド行を介して次のタスクのいずれかを実行すると、警告メッセージが戻されます。
以下の警告メッセージが出されます。
DQP1024W Creation, change, or removal of a query class will not take effect until the Query Patroller server is restarted.
同様に、「DB2 Query Patroller(TM) Guide: インストール、管理、使用法のガイド」バージョン 8.2 にも、照会クラスを作成、変更または除去した後にその変更を有効にするには Query Patroller サーバーを再始動しなければならない、という説明があります。
そのガイドのメッセージとステートメントの説明に誤りがあります。 前述の 3 つのクラス・タスクは、キューに入れられた照会や実行中の照会がなければ即時に有効になります。 新たにサブミットされた照会を含む、キューに入れられた照会や実行中のキューがあると、照会クラスの変更はそれらの完了時に有効になります。 キューに入れられたキューや実行中のキューすべてが完了するのを待てない場合は、Query Patroller サーバーを再始動する必要があります。
キャンセル済み および実行済み 照会状況の意味は、以下のように更新されました。
Query Patroller 用のヒストリカル・データ生成プログラムの実行時に Explain 表が存在しない場合は、 この生成プログラムが作成します。 ただし、ヒストリカル・データ生成プログラムの実行前に Explain 表を作成することを強くお勧めします。 Explain 表を作成する場合は、いずれも同じパーティションに作成してください。 Explain 表を同一パーティションに作成すれば、Explain 機能のパフォーマンスが向上します。 それによって、ヒストリカル・データ生成プログラムのパフォーマンスも向上します。
一定期間の照会アクティビティー (履歴分析) レポートの照会に関して「Explain Run」列に 「異常実行 (Ran unsuccessfully)」という状況が表示されている場合、 その照会の履歴データは生成されていません。 このため、その照会は履歴分析レポートまたはグラフに表示されません。 バージョン 8 の資料に記載されているように、照会が正常に実行されなかった理由を判別するには、qpuser.log ファイルを確認してください。
qpuser.log ファイルを調べる他に、qpdiag.log ファイルも確認してください。
ヒストリカル・データ生成プログラムを実行し、通常とは異なる方法でシャットダウンした場合、 次回ヒストリカル・データ生成プログラムを実行しようとしたときにエラーを受け取ります。 異常シャットダウンの例には次のものがあります。
ヒストリカル・データ生成プログラムが異常シャットダウンしたときは、 以下のコマンドを発行してから、ヒストリカル・データ生成プログラムの再発行を試みる必要があります。
qp -d database generate historical_data stop
ここで database は、 コマンドの実行対象のデータベースを表します。
一部の照会クラス操作では、 今後は Query Patroller をいったん停止してから再始動して有効化する必要はなくなりました。
下表のアクティブな照会とは、実行中または待機中の状況にある照会を指します。
ネストされた照会をキューに入れることはできません。 つまり、ネストされた照会は、 通常であればキューに入るはずのしきい値を超えた場合に、即時に実行されます。
上記の説明とは逆に、以下のステートメントを使用した照会は、キューに入れることができます。
クエリー・パトローラー・センターを実行しているリモート・デスクトップに接続するために Terminal Services Client を解像度 640x480 で使用する場合は、「サブミット設定 (Submission Preferences)」ウィンドウがブランクで表示される場合があります。「サブミット設定 (Submission Preferences)」ウィンドウを正常に表示させるには、640x480 より高い解像度を使用する必要があります。
バージョン 8.2 以降、DB2 Universal Database (UDB) は、オペレーティング・システムのグループを超えたユーザー・グループをサポートするようになりました。したがって、クエリー・パトローラー・センターの「照会サブミット設定」ウィンドウの「使用するサブミッター・プロファイル」ドロップダウン・リストが多少変更されています。
ログインしても、Query Patroller のユーザー管理用の DBADM 権限または編集特権を持っていない場合は、自分のためにのみサブミット設定を追加または更新できます。この場合は、「使用するサブミッター・プロファイル」ドロップダウン・リストには、自分が属するオペレーティング・システムのグループだけでなく、自分が属する DB2(R) UDB グループの既存のサブミッター・プロファイルが含まれます。
ログインして、Query Patroller のユーザー管理用の DBADM 権限または編集特権を持っている場合は、他のユーザーのためにサブミット設定を追加または更新できます。この場合は、「使用するサブミッター・プロファイル」ドロップダウン・リストには、すべての既存のグループ・サブミッター・プロファイルが含まれています。
クエリー・パトローラー・センターでスケジュールを処理している場合は、「スケジュール」ウィンドウを使用してスケジュールをファイルに保管し、後でそれをインポートできます。フィックスパック 6 以前を使用して保管したスケジュールがある場合は、バージョン 8.2 以降を使用してスケジュールをインポートすることはできません。この制限は、DB2 UDB バージョン 8.2 で導入された JDK レベル間でシリアライゼーションが異なることに起因しています。
RUN IN BACKGROUND QUERY コマンドを実行できるのは、照会を最初にサブミットしたサブミッターのみです。
Query Patroller バージョン 8.1 FixPak 5 の時点から、Query Patroller は照会のサブミッターの許可 ID と一致するスキーマで結果表を作成しなくなりました。 代わりに、Query Patroller は共通の DB2QPRT スキーマで結果表を作成するようになりました。 結果表をサブミッターのスキーマを使用して参照できるようにするために、Query Patroller バージョン 8.2 には、Query Patroller が作成する新しい結果表ごとに別名を自動的に作成するオプションが導入されています。 結果表は DB2QPRT スキーマに作成され、別名はサブミッターの許可 ID と一致するスキーマに作成されます。
このオプションをオン/オフにするには、CREATE_RESULT_TABLE_ALIASES オプションを指定して UPDATE QP_SYSTEM コマンドを発行します。
>>-UPDATE QP_SYSTEM USING---------------------------------------> >--+-DEFAULT------------------------------+-------------------->< '-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-' '-'N'-'
CREATE_RESULT_TABLE_ALIASES オプションを指定して作成された別名は、結果表のドロップ時に自動的にドロップされます。ただし、結果表をドロップしても対応する別名がドロップされない 2 つの状況があります。
対応する結果表のない別名をクリーンアップするために、新しいコマンド REMOVE RESULT_TABLE_ALIASES が作成されました。このコマンドは、Query Patroller のスケジュールされた結果表パージ・プロセスの一部として結果表がパージされると常に自動的に実行されます。REMOVE RESULT_TABLE_ALIASES コマンドは、以下の照会を使用してパージする別名のリストを取得します。
with a as (select tabschema, tabname from syscat.tables where type = 'A' and tabname like 'QUERY%_RESULTS'), t as (select tabname from syscat.tables where type = 'T' and tabname like 'QUERY%_RESULTS') select all tabschema, tabname from a where not exists (select * from t where t.tabname=a.tabname)
DBADM 権限が必要です。
このコマンドは、対応する結果表のドロップ後に存在するすべての別名を除去します。別名は、最初は結果表のために Query Patroller によって作成されたものです。
>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><
Query Patroller は、qpdiag.log ファイルにエントリーを記録する一部の fenced ストアード・プロシージャーを使用します。したがって、fenced ユーザー ID に qpdiag.log ファイルと qpdiag.log ファイルが存在するパスへの書き込みアクセス権限が必要です。
[ ページのトップ |前ページ | 次ページ | 目次 ]