ユーザー タイプ1:1秒以下の短い既知の作業(戦術的作業)
- サマリーのみ記録する
- BEGIN QUERY LOGGING LIMIT SUMMARY = 1,3,5 ON ALL ACCOUNT = 'acctname';
1,3,5という数値は、CPU時間ではなくクロック時間の秒数です。
- SQLは記録しない
- オブジェクトは記録しない
このワークロードでは、高速の性能と最小限の応答時間が第一の目標です。一般に、このワークロードの問合わせは単一AMP検索になるよう設計されているため、基本的に予測は非常に簡単な傾向があります。
このワークロードのリクエスト レベルでのロギングは、次の2つの理由により不要です。
- トランザクションは明確に定義されていて、既知であり、何度も繰り返されます。
- 各リクエストのSQLを記録するために必要となるオーバーヘッドが実行される全体の作業に占める割合は、トランザクションを基準とした場合、それなりの量となります。このため、追加で加わるオーバーヘッドがリクエストの応答時間に大きな影響を及ぼす可能性があります。
目標は、それらのSQLリクエストに関するサマリー情報のみを収集することです。このワークロードタイプでは作業が予測可能で繰り返し実行され、あまり変化しないことが期待されるため、サマリー ロギングで十分です。ただし、このIDの許可されていない使用がある場合や非定期的に問合わせの実行が長くなる場合は、しきい値ロギングを使用できます。
ユーザー タイプ2:大部分が実行時間の長い作業
- SQLおよびオブジェクトとともに詳細を記録する
- BEGIN QUERY LOGGING WITH SQL, OBJECTS LIMIT SQLTEXT =0 ON ALL ACCOUNT = 'acctname';
1秒以下の作業が万単位で存在する場合、追加のオーバーヘッドが発生します。
Teradataは、このワークロードカテゴリの分析用に、より詳細なデータを収集することを推奨します。このDBQLロギング オプションで作成されるデータからは、性能の効果的な管理および調整のために必要な、重要な詳細情報が生成されます。
ロギングでは、各リクエストのSQLテキスト全体と、そのリクエストの処理に使用されたオブジェクトとがキャプチャされます。SQLテキストとオブジェクト データは問合わせのアクセス パス分析を実行する上で重要です。DBQLの詳細データは、CPUと入出力のデータを提供するだけでなく、効果的な性能調整の鍵となる計算を行なうためのデータ(すなわち、問合わせにスキューが生じているかどうか、問合わせが大規模スキャンを実行するかどうか、または大規模な積結合の特性を備えるかどうか)も提供します。
ユーザー タイプ3:大部分が1秒以下の短いリクエストで、非定期的に実行時間が長い作業や未知の作業が伴う
- しきい値を記録します
- BEGIN QUERY LOGGING WITH SQL, OBJECTS LIMIT THRESHOLD =100 CPUTIME AND SQLTEXT =10000 ON ALL ACCOUNT = 'acctname';
- しきい値の数値100は、CPU時間の100分の1であることを表し、CPU時間が1秒を超える問合わせをDBQLSQLTbl、DBQLObjTblおよびDBQLogTblに詳細と共に記録します。CPU時間が1秒未満の問合わせはサマリーされます。
しきい値ロギングの場合、DBQLは指定した基準を超えて長くかかる問合わせについても、個々のExplain、およびXMLテーブルに記録できません。SQL、STEPINFOおよびOBJECTSは、しきい値ロギング中に記録できません。指定されたクロック時間の秒数よりも長くかかる問合わせの場合でも同様です。
このロギング シナリオでは、作業の大部分である1秒以下のリクエストはサマリー レベルで記録しながら、未知のリクエストや実行時間が長くなるリクエストは詳細なレベルでキャプチャされます。