推奨の生成¶

Administration Tool を開き、[Tools] -> [Query optimizations] -> [Summary Recommendations] に移動します。このオプションを使用できるのはグローバル管理者ユーザーだけであり、サーバーライセンスによって許可されている必要があります。

[Generate recommendations] をクリックする前に、複数のオプションを以下のように調整できます。

• Recommendations time limit (minutes): 推奨プロセスの最大実行時間 (分単位) を指定できます。

• Minimum query duration (ms): 実行時間がこの最小継続時間よりも長いクエリのみをログから探して検討対象とします。このオプションによって、すでにパフォーマンスの高いクエリを除外し、本当に最適化すべきクエリのみに注力することが可能となります。

• Initial date to consider: この日付以降に開始したワークロードのみを検討対象とします。日付を指定するには、「2021-05-01」のようなリテラルを使用することも、addweek(current_date(), -1) のように、より複雑な表現を使用することも可能です。

• Last date to consider: この日付以前に開始したワークロードのみを検討対象とします。

• Maximum size for summary candidates (number of rows): 推定サイズがこの制限未満のサマリを検討対象とします。

• Maximum number of summary candidates: プロセスが推奨するサマリの最大数を指定します。

• Database for recommended summaries: プロセスが推奨サマリを配置する、Virtual DataPort 上のデータベースを指定します。ユーザーが明示的にマテリアライズを指示するまで、サマリは Virtual DataPort サーバー上だけに存在します。

• Folder recommended summaries: プロセスが推奨サマリを配置する、選択したデータベース上のフォルダを指定します。

• Analyze queries from these databases: 指定したデータベースから実行されたクエリのみを検討対象とします (指定しない場合、全データベース)。このオプションは、常に同じデータベースを使用して接続する特定のクライアントからのクエリを最適化する場合に便利です。

• Views to consider: ビューを選択した場合、推奨されるサマリ候補には選択したビューが少なくとも 1 つ含まれます。このオプションはファクトテーブルなどの重要なビューに的を絞らせる手段として役立ちます。

• Preferred target data sources: 推奨サマリの保存先として希望するデータソースを選択できます。選択しない場合、プロセスはサーバーのキャッシュ構成で構成されたデータソースと、各クエリで最大のビューを含むデータソースであると見なします。

• Excluded target data source: サマリの保存先として検討しないデータソースを選択します。

次の点を考慮してください。

日付範囲を非常に広くとると、検討するクエリが増加します。その結果、優れた推奨クエリが生成される可能性がありますが、実行時間も増加します。通常はまず他のパラメータを調整して有用なクエリだけを検討してから、用途に最適な日付範囲を選択します。推奨される手順としては、サーバー上のすべてのクエリを対象としたプロセスを 1 度に実行するのではなく、毎回特定の用途に着目し、それに合わせてパラメータを調整します。

例: データベース「bi_tool」によってアクセスを行う BI ツールを使用するユーザーからのクエリを最適化する場合、次の構成が考えられます。

• [Analyze queries from these databases] にデータベース bi_tool を指定する

• [Views to consider] にファクトテーブルを指定する

• 希望するデータソースを選択する

• 用途に応じて、[minimum query duration] を設定する。たとえば 10000 など、100 ミリ秒を超える値を選択するのが妥当でしょう。

最後に、[Tools] の下の [Query Monitor] ユーティリティから、推奨プロセスの実行中に、進捗をより詳細に確認できます。「CREATE SUMMARY RECOMMENDATION」から始まるリクエストを選択して、実行プランを確認してください。

「Read log information time」プロパティの値が大きすぎる場合は、ログ実装インターフェイス i_queryblock_notification と i_request_notification にアクセスするビューのキャッシュを検討しても構いません。

結果の処理¶

プロセスの結果、ワークロードに対する特に優れたサマリが選出されます。また、各サマリについて以下の情報が表示されます。

• [Database for recommended summaries] と [Folder recommended summaries] で指定したデータベースとフォルダにサマリのメタデータが作成されます。この時点ではリモートデータソースにテーブルが存在せず、データは読み込まれていないことに注意してください。

• 結果にはサマリに関する有用な情報が含まれます。

  • Name: サマリの名前です。名前の先頭には「sum」とランキング上のサマリの順位を示す数値と、含まれる最大のビューが記載されます。名前をクリックしてサマリを開き情報を確認することが可能です。この時点ではまだリモートデータソース上にサマリは存在せず、読み込まれるまでクエリオプティマイザーはサマリを考慮しないことに注意してください。「Valid for query acceleration」プロパティに「Needs refresh」値が存在するのはこのためで、サマリを直接実行するとエラーになります。

  • Data source: データを読み込む場合に、サマリのデータを保存するように構成されたデータソースです。

  • Views: サマリのクエリ定義で使用されるビューです。

  • Estimated size: サマリの推定サイズです。Medium は十万単位、Large は百万単位を表します。

  • Usage (Num.queries): サマリのメリットを受ける、選択したワークロードからのクエリの数です。

  • Absolute gain factor: サマリを使用しない元のワークロードと比較して、このサマリを単独で使用することによってワークロードの推定コストが何倍削減されるかを表します。

  • Relative gain factor: 順位が 1 つ下のサマリだけを使用した場合の推定コストと比較して、このサマリと順位が 1 つ下のサマリを使用することでワークロードの推定コストが何倍削減されるかを表します。

結果ではコスト優位性とサイズから判断した順番にサマリが表示されるため、先頭のサマリが最良の選択肢だと判断されたものです。結果を基に推奨サマリを確認し、どのサマリを保持するかを判断することが可能です。保持を希望するサマリがある場合は、まずそれぞれのサマリを編集して選択されたデータソース、カタログ、スキーマが最適なものかを確認し、必要に応じて変更を行ってください。また、「 サマリを使用する場合の推奨事項 」の推奨事項を確認することを強くお勧めします。確認が完了したら、[Load] をクリックして同じデータベースにサマリを作成するか、[Export] をクリックしてサマリの VQL を保存します。サマリの読み込みが完了すると、クエリオプティマイザーがサーバーのクエリの高速化に利用できるようになります。別の環境でサマリを作成する場合は、選択したサマリを次の昇格のリビジョンに含めることが可能です。詳細については、Solution Manager ガイドの「 昇格 」を参照してください。