戦術的クエリーと最も関連がある2つのクエリー ロギング テーブルは、デフォルト ロギング テーブルのDBC.DBQLogTblと、サマリー ロギング テーブルのDBC.DBQLSummaryTblです。
クエリー ロギングは、1人のユーザー、ユーザーのグループ、すべてのユーザー、または1つのアプリケーションに対して有効にできますが、ディスクへの書込み後はロギングされたデータの表示しか行なえません。サマリー テーブルのキャッシュは、10分ごとにディスクに書き込まれます。行は、以下のいずれかの条件が発生する場合に、デフォルトのテーブルおよび他のDBQLテーブルに書き込まれます。
- DBQLテーブルのキャッシュが満杯になった場合
- DBQLFlushRateのしきい値に達した場合
- END QUERY LOGGINGリクエストを実行した場合
テスト期間を過ぎてから戦術的クエリーのクエリー ロギングをデフォルトのロギング レベルで有効にすることは避けてください。そのオーバーヘッドが、単一のまたは少数のAMPクエリーの実行に影響を与える可能性があるためです。
DBC.DBQLogTblテーブルにはキャッシュされた計画がクエリーで使用されたかどうかを示すフラグがあるため、計画がキャッシュされているかどうかを検証するために、戦術的クエリーのテスト段階でデフォルトのクエリー ロギングを有効にすることができます。しかし、正しく調整された、予測可能な戦術的クエリー アプリケーション用にデフォルトのロギングを有効にする価値はほとんどありません。しかも、クエリーが単一または少数のAMP操作である場合は、クエリー ロギングによって、クエリーを実行するたびにログに1行を書き込むオーバーヘッドがわずかながら生じます。
戦術的クエリーのクエリー ロギングを使用することのより一般的な目的は、クエリー応答時間の一貫性を評価および記録することです。これは、サマリー ロギングを使用することによって実現できます。サマリー ロギングでは、行はDBC.DBQLSummaryTblにしか書き込まれません。時間変数のサマリー ロギングを実行する場合は、次のようにして3つの秒単位の時間しきい値を定義する必要があります。経過時間、CPU時間または正規化されたCPU時間のいずれかを使用して、サマリー ロギングをリクエストできます。また、I/Oカウント数のサマリー ロギングをリクエストすることもできます。
以下に例を示します。
BEGIN QUERY LOGGING LIMIT SUMMARY = 1, 5, 10 ON cab;
このサマリー ロギングにユーザーが含まれているセッションごとに、4つの定義済みバケットのそれぞれにカウントが保持されます。ある間隔でのカウントがゼロのバケットは、ロギングされません。たとえば、ある間隔でのクエリーが、すべて同じバケットに分類される場合、そのセッションでは1つのバケットのみがロギングされます。これらのバケット(時間範囲内のクエリーのカウントを含む)は、セッションごとに独立して保持され、サマリー行には行が属するセッションを識別するためのセッションIDが含まれます。
このカウンター バケットは、10分間隔でディスクにフラッシュされます。最初の10分の間隔が終了したら、次の例のようなリクエストを使用してDBC.DBQLSummaryTblテーブルを問合わせることによって、その時間間隔(およびその前の時間間隔)のバケットを調べることができます。
SELECT procid, collecttimestamp, userid, acctstring, sessionid, qrycnt, qrysecs, lowhist, highhist FROM dbqlsummarytbl ORDER BY collecttimestamp, sessionid, lowhist;
このクエリーによって、単一セッションで収集されたサマリー データのいくつかを示す次のレポートが生成されます。
分析しやすいように、これらのサマリー行は10分間隔ごとに配列し、収集間隔の間に空白行を挿入してあります。CollectTimeStampの値から、最初のグループは他のグループよりも数日前に収集されたことが分かります。情報は明示的に削除するまで、クエリー ログ テーブルに保持されます。
DBC.DBQLSummaryTblテーブルのプライマリ インデックスは最初の2つの列です。これらの列は、行のディスクへの書き込み速度を上げるために選択されています。10分間隔の各グループは、同じNUPI値を使用してバッチで効率的に書き込まれます。
次のリストに、DBC.DBQLSummaryTblテーブル情報についての説明を示します。
- LowHist列とHighHist列は、特定のバケットの範囲を定義します。間隔の中でクエリー カウントが最低1つあるバケットだけが生成されます。前のレポートに示されている3番目のグループは、レポートを生成するために使用されるBEGIN QUERY LOGGINGリクエストのSUMMARYリストによって定義されている4つのすべての間隔バケットの中で、クエリー カウントがある唯一のグループです。
間隔番号 間隔の時間範囲(秒数) 1 0 - 1 2 1 - 5 3 5 - 10 4 10 - 4,294,967,295 DBC.DBQLSummaryTblのHighHistの有効な上限値は、4,294,967,295 (232)秒(約1,193,046時間)です。
- QueryCount列(レポートではQryCntと略されている)は、間隔の範囲内の応答時間で実行されたクエリーせの数を示しています。たとえば、出力の最初の行では、8つのクエリーが1秒未満で実行され、2つのクエリーが10秒以上で実行されています。
- QuerySeconds列(レポートではQrySecsと略されている)は、バケット内のすべてのクエリーの合計実行時間を厳密に表わしているわけではありません。この合計に含めるには、特定のクエリー応答時間は0.5秒より多くなければならず、0.5秒以上で実行されたクエリーは1秒とカウントされます。集計では秒の小数部は切り上げまたは切り捨てられます。
- UserIDの値は、システムに表示される形式であるBYTEデータ型で表わされています。サマリー テーブルを識別しやすいユーザーIDで表示するには、次のクエリーに示されているとおり、DBC.databases2Vビューに結合するという方法があります。サマリー テーブルには、前述の例のクエリーを実行した場合と同じ詳細が含まれています。
SELECT st.collecttimestamp, db.databasename, st.sessionID, st.querycount, st.queryseconds, st.lowhist, st.highhist FROM DBC.databases2V AS db,DBC.dbqlsummarytbl AS st WHERE db.databaseid = st.userid ORDER BY collecttimestamp, lowhist;
戦術的クエリーにDBQLを使用する場合の追加の考慮事項には、次のような問題も含まれます。
- クエリー ログ テーブルは、クエリーの容易さよりも、ログ テーブルへの挿入の効率を優先した設計になっています。このため、行カウントが大きいログ テーブルへのアクセスは、時間のかかるプロセスとなる可能性があります。テーブルを十分に保守しておくことにより、表示、領域管理、およびログ情報の分析の容易さに効果が現れます。
- クエリーが主に単一または少数のAMP操作であるユーザーについては、テスト時にデフォルト テーブルのDBC.DBQLogTblのログ記録を有効にし、実働環境ではクエリーを必要時にのみログに記録します。
- DBQLサマリー情報は、戦術的アプリケーションの応答時間の偏差の程度を評価するのに役立ちます。
- DBQLサマリー テーブルは、秒の小数部が丸められるため、実行時間が短いクエリーの正確なクエリー率を確証することには向いていません。ロギングの間隔が10分であり、データを表示できるため、サマリーロギングはリアルタイム パフォーマンス アラートのニーズには合いません。
- サマリー ロギングの代わりにしきい値ロギングを使用できます。この方法では、指定されたしきい値時間(経過時間、CPU時間、正規化CPU時間の任意の。すべて秒単位)、または指定された入出力回数よりも長く実行されているクエリーだけがDBC.DBQLogtblにロギングされます。実行時間がしきい値を下回るすべてのクエリーのログは、DBC.DBQLSummaryTblに記録されます。