Query Patroller

照会クラスの振る舞いの更新

クエリー・パトローラー・センターまたは 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 と同様、照会クラスの最大照会数の更新は常に即時に有効になります。

管理対象の照会状態定義の更新

キャンセル済み および実行済み 照会状況の意味は、以下のように更新されました。

キャンセル済み
照会は、クエリー・パトローラー・センターまたは Query Patroller コマンド行を使用して、プロファイルに編集権限とモニター特権を持つ、管理者、サブミッター、またはオペレーターによりキャンセルされました。実行中保留リリース済み、およびキュー済み の照会のみキャンセル できます。
実行済み
照会は正常に完了しました。
注:
照会自体はエラーなしで完了した場合でも、完了が DB2 force アプリケーションなどの外部イベントに起因する場合、アプリケーションがエラーを受け取る場合があります。

Query Patroller のヒストリカル・データ生成プログラムの実行以前の Explain 表の作成

Query Patroller 用のヒストリカル・データ生成プログラムの実行時に Explain 表が存在しない場合は、 この生成プログラムが作成します。 ただし、ヒストリカル・データ生成プログラムの実行前に Explain 表を作成することを強くお勧めします。 Explain 表を作成する場合は、いずれも同じパーティションに作成してください。 Explain 表を同一パーティションに作成すれば、Explain 機能のパフォーマンスが向上します。 それによって、ヒストリカル・データ生成プログラムのパフォーマンスも向上します。

履歴分析のための Query Patroller ログ・ファイルの検査

一定期間の照会アクティビティー (履歴分析) レポートの照会に関して「Explain Run」列に 「異常実行 (Ran unsuccessfully)」という状況が表示されている場合、 その照会の履歴データは生成されていません。 このため、その照会は履歴分析レポートまたはグラフに表示されません。 バージョン 8 の資料に記載されているように、照会が正常に実行されなかった理由を判別するには、qpuser.log ファイルを確認してください。

qpuser.log ファイルを調べる他に、qpdiag.log ファイルも確認してください。

ヒストリカル・データ生成プログラムの異常シャットダウン

ヒストリカル・データ生成プログラムを実行し、通常とは異なる方法でシャットダウンした場合、 次回ヒストリカル・データ生成プログラムを実行しようとしたときにエラーを受け取ります。 異常シャットダウンの例には次のものがあります。

ヒストリカル・データ生成プログラムが異常シャットダウンしたときは、 以下のコマンドを発行してから、ヒストリカル・データ生成プログラムの再発行を試みる必要があります。

    qp -d database generate historical_data stop

ここで database は、 コマンドの実行対象のデータベースを表します。

動的照会クラスの更新

一部の照会クラス操作では、 今後は Query Patroller をいったん停止してから再始動して有効化する必要はなくなりました。

下表のアクティブな照会とは、実行中または待機中の状況にある照会を指します。

表 38. 照会クラスの変更の有効化の条件
更新内容 変更の有効化の条件
照会クラスの追加、除去、または更新 アクティブな照会がない場合、変更はただちに有効化されます。
「照会の最大数」の変更のみをともなう照会クラスの更新。 アクティブな照会があっても、即時に有効化されます。
「照会の最大コスト」の変更のみをともなう照会クラスの更新。 アクティブな照会がある場合に更新が有効化されるのは下記の時点です。
  • Query Patroller を停止してから再始動したとき。
  • アクティブな照会がなくなったとき。
注:
「照会の最大コスト」に対するペンディングの変更があると、 その後に続くどのような種類の照会クラスの更新も、上記の 2 つの条件のいずれかが満たされないと有効化されません。
照会クラスの追加または除去。 アクティブな照会がある場合に追加または除去が有効化されるのは下記の時点です。
  • Query Patroller を停止してから再始動したとき。
  • アクティブな照会がなくなったとき。

ネストされた照会の動作

ネストされた照会をキューに入れることはできません。 つまり、ネストされた照会は、 通常であればキューに入るはずのしきい値を超えた場合に、即時に実行されます。

SQL ステートメント・タイプ別の制限事項

上記の説明とは逆に、以下のステートメントを使用した照会は、キューに入れることができます。

Terminal Services Client を使用する場合の解像度の制限

クエリー・パトローラー・センターを実行しているリモート・デスクトップに接続するために Terminal Services Client を解像度 640x480 で使用する場合は、「サブミット設定 (Submission Preferences)」ウィンドウがブランクで表示される場合があります。「サブミット設定 (Submission Preferences)」ウィンドウを正常に表示させるには、640x480 より高い解像度を使用する必要があります。

照会サブミット用の新しいグループのサポート

バージョン 8.2 以降、DB2 Universal Database (UDB) は、オペレーティング・システムのグループを超えたユーザー・グループをサポートするようになりました。したがって、クエリー・パトローラー・センターの「照会サブミット設定」ウィンドウの「使用するサブミッター・プロファイル」ドロップダウン・リストが多少変更されています。

ログインしても、Query Patroller のユーザー管理用の DBADM 権限または編集特権を持っていない場合は、自分のためにのみサブミット設定を追加または更新できます。この場合は、「使用するサブミッター・プロファイル」ドロップダウン・リストには、自分が属するオペレーティング・システムのグループだけでなく、自分が属する DB2(R) UDB グループの既存のサブミッター・プロファイルが含まれます。

ログインして、Query Patroller のユーザー管理用の DBADM 権限または編集特権を持っている場合は、他のユーザーのためにサブミット設定を追加または更新できます。この場合は、「使用するサブミッター・プロファイル」ドロップダウン・リストには、すべての既存のグループ・サブミッター・プロファイルが含まれています。

Query Patroller のスケジュールの制限

クエリー・パトローラー・センターでスケジュールを処理している場合は、「スケジュール」ウィンドウを使用してスケジュールをファイルに保管し、後でそれをインポートできます。フィックスパック 6 以前を使用して保管したスケジュールがある場合は、バージョン 8.2 以降を使用してスケジュールをインポートすることはできません。この制限は、DB2 UDB バージョン 8.2 で導入された JDK レベル間でシリアライゼーションが異なることに起因しています。

RUN IN BACKGROUND QUERY コマンドを使用するために必要な許可

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 権限が必要です。

手順

  1. REMOVE RESULT_TABLE_ALIASES コマンドを発行します。

このコマンドは、対応する結果表のドロップ後に存在するすべての別名を除去します。別名は、最初は結果表のために Query Patroller によって作成されたものです。

コマンド構文

構文図を読む構文図をスキップする>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><
 

注:
コマンド行インターフェースを使用して Query Patroller コマンドを入力する方法、および Query Patroller コマンドの一般的な構文については、Query Patroller コマンド行インターフェースを参照してください。

fenced ユーザー ID に qpdiag.log ファイルおよびパスへの書き込みアクセス権限が必要

Query Patroller は、qpdiag.log ファイルにエントリーを記録する一部の fenced ストアード・プロシージャーを使用します。したがって、fenced ユーザー ID に qpdiag.log ファイルと qpdiag.log ファイルが存在するパスへの書き込みアクセス権限が必要です。

[ ページのトップ |前ページ | 次ページ | 目次 ]