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