Database Performance Analyzer (DPA) 2024.2のリリース

投稿日: 2024年5月2日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

最新バージョンのDatabase Performance Analyzer (DPA) 2024.2の一般提供が開始されました。このリリースでは、SQL ServerおよびOracle向けのDPAの既存機能である実行プラン収集、インデックスアドバイザ、Table Tuning Advisor(テーブルチューニングアドバイザ)をPostgreSQLにも適用し、PostgreSQLのワークロードを分析します。

Table Tuning Advisor（テーブルチューニングアドバイザ）

どのデータベースにも非効率な問い合わせがあります。言い換えれば、少ないリターンに対して非常に多くの労力を費やしているということです。このような非効率的なクエリは、I/Oの増加、待ち時間の増加、ブロッキングの増加、リソースの競合の増加を招きます。

非効率的なクエリをチューニングするのは難しく、その過程で多くの疑問が浮かびがちです。以下のような疑問です：

●クエリをチューニングすべきか？新しいインデックスを追加すべきか？それとも既存のインデックスに列を追加するのか？
●プランは複雑で分析が難しい。どのステップに注意を払うべきか？
プランのどの述語が非効率的なデータアクセスと大量のリードを引き起こしているのか？
●出発点として使える推奨事項はありますか？
●同じテーブルにアクセスする他の非効率なクエリがあり、インデックスの決定によって影響を受ける可能性はありますか？
●テーブルには現在いくつのインデックスが存在し、それらはどのような構造になっていますか？
●データチャーン（挿入、削除、場合によっては更新）という形で、テーブル内のデータはどの程度トランザクションがあるのか？

Table Tuning Advisorはこれらの疑問を解決するのに役立ちます。

Table Tuning Advisorは、高価なクエリやプランを分析し、非効率なワークロードが実行されているテーブルを特定するために設計されています。各テーブルについて、アドバイザー・ページにはテーブルと非効率なクエリに関する集約された情報が表示されます。この情報を使用して、データベース・パフォーマンス最適化の機会について情報に基づいた決定を下したり、インデックスを追加する潜在的なコストと利点を検討したりすることができます。

ナビゲーション

アドバイザーのページに進むには2つの方法があります：

●インスタンスをクリックすると、ページ上部に “Tuning “スーパータブが表示されます。これにより、クエリ、インデックス、テーブルのチューニングアドバイザーをまとめたページに移動します。

●特定のクエリ・パフォーマンス分析 (QPA) ページに移動したら、テーブル・チューニング・アドバイザーのセクションにスクロールダウンします。このセクションには、テーブル・レベルに集約されたアドバイスが要約され、アドバイザーの詳細ページへのリンクが含まれています。

アドバイザーページのレイアウト

テーブル・チューニング・アドバイザーのページには、選択したオブジェクトに関連する主要なインテリジェンスがぎっしりと詰まっており、3つのメイン・エリアがあります：

●非効率なSQL – テーブルにアクセスするクエリのリストを相対的な作業負荷でランク付け
●SQLとプランの詳細 – 選択したクエリのSQLとプランの詳細
●テーブルおよびインデックス情報 – 現在のテーブル情報、テーブル上の既存のインデックス、およびテーブルのカラム。

テーブル・チューニング・アドバイザーの例

積極的に何かをチューニングし、大きな影響を与えたいとします。概要レベルでは、チューニングタブは非効率なクエリを持つテーブルを表示し、非効率なワークロードに基づいてランク付けします。このリストには、各テーブルの待ち時間の集計と、そのテーブルの非効率なプランステップを持つクエリの数が含まれています。これらはチューニングの絶好の機会です。

出発点として使用する推奨事項はありますか？「orders 」テーブルをクリックすると、テーブル・チューニング・アドバイザーのページが表示されます。このページには、非効率な使用パターン、統計情報、現在のインデックスの設計など、テーブルについて知っておくべきことがまとめられています。

プランのどのステップが非効率ですか? DPA は独自のアルゴ リ ズ ム を使用 し て非効率な計画ス テ ッ プ を発見 し 、 問題の原因 と な っ てい ます。非効率な「プロデューサ」ステップ（例えば、テーブル/インデックスのフル スキャン）は、後続のコンシューマ プラン ステップが後で処理するデータを読み込みます。コンシューマステップ（
例えば、ソート）は高コストになる可能性がありますが、通常は先行するプロデューサステップのデータ読み込み量が多すぎることが影響しています。DPA は非効率なプ ロ デ ュ ーサープ ラ ン ス テ ッ プ を指摘 し 、 チューニングの焦点 と し ます。

上記の例では、 DPA は使用 さ れてい る 2 つのプ ラ ン と 、 各プ ラ ン内の非効率な ス テ ッ プ を特定しました：

１．SEQ SCAN – ステップ7 – 「customer」テーブルのシーケンシャルスキャン 述語値が、非常に非効率的な類似比較が使用されていることを示していることに注意してください。シーケンシャルスキャンは、一致する電話番号のために150K行の検査を引き起こしました。

手作業によるプラン分析でこの情報を得るには、おそらく何時間もかかるでしょう。プラン分析は難しいので、Table Tuning Advisorに任せます。

このテーブルにアクセスする他の非効率なクエリはありますか？ Table Tuning Advisorページの左ペインには、”customer “テーブルにアクセスする他の非効率的なクエリが相対的な作業負荷でランク付けされて表示されます。このリストの最上位にあるクエリは、テーブルに対する作業負荷が高いので注意してください。逆に、相対的な作業負荷が小さい最下部付近のクエリにはそれほど時間をかけるべきではありません。インデックスの追加や修正のような小さな調整で、多くの非効率なクエリが大きく変わることがあります。

テーブルには現在いくつのインデックスが存在し、それらはどのように設計されていますか？Table Tuning Advisorページの下部には、現在のインデックスとそのカラムが統計情報と使用状況と共に表示されます。その他のテーブルとインデックスのメタデータは、リアルタイムのクエリの後に表示され、最新の情報を反映します。これはいくつかの理由で重要です：

●テーブルのデータ・チャーンが高いか？もしそうであれば、挿入/更新/削除のアクティビティが高いことを意味し、新しいインデックスを作成するとかえって害になる可能性があります。
●述語で呼び出されたカラムを含む既存のインデックスが役に立ちそうか？新しいインデックスを作成するのではなく、このクエリに役立つようにインデックスを変更することができますか？
●オプティマイザの統計は最近作成されましたか？もしそうでなく、解約が多いのであれば、テーブルの統計情報を更新することが良い第一歩かもしれません。
●インデックスが肥大化していないか？インデックスが肥大化しており、それに対してスキャンが実行されている場合、バキューム処理の健全性をチェックしてください。

何が見つかったのか？

開発チームは、DPAを使用してコードのパフォーマンスを確認しています。Table Tuning Advisorを使用したところ、問題のあるテーブルが見つかりました。数時間以内に、簡単な書き換えでクエリをチューニングし、毎晩のクリーニング処理にかかるデータベース時間を数時間節約することができるでしょう。

 

関連したトピックス

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。