第1レベルの情報はDBQLogTbl and DBQLSummaryTblに取り込まれます。短時間で大量の問合わせについては、THRESHOLDオプションをSQL、STEPINFO、またはOBJECTSロギング オプションと組み合わせて要求し、収集のオーバーヘッドを削減できます。さらに経過時間、CPU利用率、I/O数の単位を指定することもできます。
DBQLogTblとDBQLSummaryTb1のデータを利用して、例えば応答時間のサービス レベル基準を満たさないワークロードなどの問題を識別することができます。領域が大きな問題となる場合は、しきい値ロギングを使用することができますが、詳細を取得した方がはるかに深い洞察が得られます。
DBQLロギングのベスト プラクティスは、SQLおよびOBJECTSロギング オプションを使用してシステム レベルで記録する方法です。特定のアカウント文字列がある場合や、多数の戦術的なきわめて短い時間のリクエストを実行するだけのユーザーIDがある場合、Teradataでは、THRESHOLDロギング オプションとSTEPINFOロギング オプションを使用してCPU利用状況を記録することを推奨します。
詳細データは、限定的に使用するかぎり、非常に役立ちます。分析することによって以下が可能になります。
- 例えば以下を比較することによって、問合わせ、または問合わせ管理や優先順位のストラテジーを最適化する。
- 同じ結合インデックスをターゲットとするさまざまな問合わせの結果
- さまざまな日付や時間に実行された同じ問合わせの経過時間
- 問合わせの特徴を示す他の収集データ(QCF、ResUsage、DBC.AMPUsageなど)とDBQLデータを比較することによって、大量消費またはパフォーマンス低下の理由を特定する。
- 問合わせリクエストの指数関数的な増大を因子として考慮することにより、既存の容量を効率的に使用して将来の拡張を計画する