SQLパフォーマンスの調整がデータベース管理にとって非常に重要なのはなぜですか？
それはあなたに大きな時間を節約することができるからです。我慢してください。そうすれば、その方法がわかります。
SQLパフォーマンスの調整とデータベース管理—点をつなぐ
ほとんどのデータベースの専門家は、明かりをつけ続けることに時間を費やしています。彼らは、メモリ、ストレージ、ネットワークスループットなどのリソースを監視することにより、稼働時間を確保することにほとんどの努力を費やしています。これはデータベース管理の重要な部分ですが、データベースをAWSやAzureなどのほぼ無限のクラウドリソースに移行する企業が増えるにつれ、他の側面がより重要になっています。
SQLパフォーマンスの調整はそれらの側面の1つです。ライトが安全に点灯し、データベース管理のニーズの階層を上に移動したら、次に必要なのはパフォーマンスの向上です。これには調整が必要です。
SQLでパフォーマンスを調整するときに最初に尋ねる質問
遅かれ早かれ、多くのデータベースプロフェッショナルは、自分たちが構築していないSQLServerの前にいることに気づきます。そのような状況に対応するハウツーガイドは多くありません。 SQLパフォーマンスの調整は、掘り下げて何が問題なのかを突き止め、それを繰り返し修正するための演習です。
最初の修正では、SQLステートメントにまったく触れない場合があります。一部のデータベースプロは、ユーザー/セッションレベルで開始します。彼らはユーザーが不満を抱いているところに行き、彼らの不満がどのように聞こえるかを聞き、質問を投げかけます。
- レンダリングに時間がかかりすぎる画面またはページはどれですか？
- 新しいチケットを作成したり、既存のチケットを開いたりすると、アプリケーションの速度が低下しますか？
- レコードを保存するのに長い時間がかかりますか？
- 「長い時間」はどのくらいですか？
それらの答えが得られたら、データベースの何が原因であるかを確認します。
これは、初日に座って、ユーザーにまったく影響を与えない可能性のある断片化などの問題に対処することを決定するよりも優れています。重要なのは、ユーザーが気にかけていることから始めることです。
インスタンス/データベースレベルについても考えてください。たとえば、Microsoftの世界では、SQLServerエージェントのジョブを開始するのが適切です。これらは一連のアクションであり、通常、成功または失敗を監視できる管理タスクを定義します。それらは便利であることを意図していますが、データベース管理の多くのものと同様に、人々がそれらがどのように発生し、何をしているのかを忘れると蓄積する傾向があります。
複数のジョブが同じことを実行している場合があります。たとえば、異なるバージョンのインデックススクリプトを実行したり、さらに悪いことに、相互に作用したりします。 「このジョブは何をするのか」という2つの質問に照らして、構成済みのジョブを調べます。そして、もっと重要なのは、「その仕事をやめたら、何か悪いことが起こるだろうか？」
どの要素を探す必要がありますか？
SQLのパフォーマンス調整のレベルに達すると、いくつかの要因から動作の手がかりが得られます。専門家に尋ねる：データベースパフォーマンス円卓会議のウェブキャストで説明したように、次のような要素を見つけて正しく解釈すれば、SQL自体の調整に費やす時間を短縮できます。
- ブロック— サーバーがブロックしている場合、それは時限爆弾のようなものです。スクリプトがトランザクションを開始し、それを閉じないとします。これにより、ログファイルが大きくなり、スペースがなくなるまで大きくなる可能性があります。ブロッキングはパフォーマンスにとって悪いニュースなので、すぐに探してください。
- エージェント— SQL Serverエージェントジョブの適切な方法として、管理者はパフォーマンスを低下させるタスクを誤ってジョブにラップすることが知られています。トランザクションを実行したり、ジョブでインデックスを再構築したり、トランザクションでデータベースを縮小したりする場合があります。そのような場合は、エージェントを一時的に無効にして、関連するすべてのジョブをシャットダウンすることを検討してください。これは積極的な手法ですが、パフォーマンスが向上すれば、その理由がわかります。
- 待機統計— 「現在、サーバーは何を待っていますか？」と自問してください。ページの平均余命やディスクキューの長さなどの指標にはいくつかの答えがありますが、それらは狭い視野しか提供しません。待機統計は、待機タイプと待機カテゴリのレンズを通してすべてを表示し、最も時間を消費する5つほどの待機イベントに焦点を当てることができます。 Brent Ozarのsp_BlitzFirstは、SQLServerクエリが現在待機しているものを検出するための信頼できるストアドプロシージャです。次に、サーバーの待機統計の長期的なパターンを調査する場合は、パフォーマンス監視ツールを検討してください。
- 管理者の活動— これは「パイロットエラー」とも呼ばれます。これは、自分が行っていることからパフォーマンスの問題が発生するためです。 SQLServerアクティビティモニターとSQLServerプロファイラーの両方を同時に実行してクエリストアを学習しようとしているとします。観察者効果を超えることはできません。そのようなすべてを追跡するときは、データベースの速度を低下させるように要求しているだけです。
- インデックス— 有益であると思われるものについては、インデックスは確かに首に痛みを与える可能性があります。実際、それらは1つ以上の弾丸に値します。続きを読む。
SQLパフォーマンスの調整とは、インデックスを厳密に調べることを意味します
大部分は、SQLパフォーマンスの調整はインデックスの調整に要約されます。幸い、オンプレミスのデータベース管理でそれを習得すれば、スキルをクラウドのデータベース管理に簡単に移行できます。
インデックスの調整は、クラスター化、非クラスター化、一意、フィルター処理、列ストア、ハッシュ、メモリ最適化非クラスター化、XML、空間、フルテキストなど、さまざまなインデックスが進化しているため、重要性を増しています。ただし、変更されていないことの1つは、データベースエンジンによって行われるインデックスの決定を駆動するインデックスの最初の列です。
多くのベンダーは、意図されたインデックスが多数含まれているアプリケーションを販売および展開しており、最終的には使用されないか、さらに悪いことに、実際にはパフォーマンスが低下します。一部のソフトウェア製品で未使用のインデックススクリプトまたはインデックス消費スクリプトを調べると、外部キーに大量のインデックスが見つかります。製品がたとえば20個の外部キーを使用する場合、ベンダーは最大20個のインデックス、10個の単一列インデックス、さらに10個の一意のクラスター化インデックスのインデックスなどを出荷できます。
オプションがある場合は常に、データベースアーキテクチャにアプローチするためのより良い方法は、テーブルを最もよく表すと思われる1つのクラスター化インデックスから始めることです。次に、システムをしばらく実行します。より多くのインデックスが必要な場合は、それらを作成します。インデックスを追加することは、ディスクスペースのいっぱいになり、そこでロックするなどの問題で、ここでのパフォーマンスの向上とトレードオフするための演習です。追加の各インデックスがシステム全体にどのように影響するかを確認するのは難しくなります。
さらに言えば、アレルギーのある人が食品群を排除する方法であるインデックスを排除して、パフォーマンスがどのように変化するかを確認することを検討してください。開発インスタンスのすべてのインデックスを削除して、上位5つのクエリに影響を与えるインデックスを確認してください。
SQL Serverのパフォーマンスチューニング—それに付属するツール
この取り組みはあなただけではないことに注意してください。 SQL Serverには、パフォーマンスを向上させるように設計された機能が含まれています。
プランガイドでは、SQL Serverが特定のクエリを実行する方法を変更できます。これは、純粋なSQLパフォーマンスチューニングではありませんが、パフォーマンスに影響します。多くのアプリケーションには外部ベンダーによって作成されたSQLクエリが含まれており、それらのクエリによってパフォーマンスが低下したとしても、データベースの専門家の中には当然のことながらそれらを変更することを躊躇する人もいます。プランガイドを使用すると、クエリヒントまたは固定プランをクエリに添付して、クエリの実行方法に影響を与えることができます。
ただし、プランガイドの欠点は、時間の経過とともに変化しないものの、周囲の環境が変化することです。印刷されたロードマップのように、それらは短期的にはうまく機能し、やがて時代遅れになる可能性があるため、それらに依存する場合は、時々それらを再検討することをお勧めします。
プランガイドに関連するのは、システムで最も多くのリソースを消費するクエリを特定して調整するのに役立つSQLServerの機能であるクエリストアです。新しいSQLServerおよびAzureSynapseAnalytics（SQL DW）データベースでは、クエリストアはデフォルトで有効になっていません。ただし、新しいAzureSQLデータベースではデフォルトで有効になっています。
一般に、クエリストアを有効にすることは難しくありませんが、すべてのSQLServerが最初からクエリストアを必要としているわけではありません。クエリストアについて知らない管理者もいれば、クエリストアについては知っているが、十分に調査するための時間をまだ取っていない管理者もいます。無効のままにしておく方がよいでしょう。後で、クエリストアがどのように機能するかを理解すると、クエリストアを使用して、クエリプランの変更によって引き起こされたパフォーマンスの違いを見つけることができます。
最後に、Database Engine Tuning Advisorはワークロードを分析し、クエリのパフォーマンスを向上させるためにインデックスまたはパーティション化戦略を推奨します。データベースでTuningAdvisorを実行することをお勧めします。すぐに実行しないでください。インデックスの推奨事項が有効になるように、データベースに十分なデータが含まれていることを確認してください。アプリケーションを最初に構築するときは、各テーブルに1,000行しかない場合があります。チューニングアドバイザーの推奨事項は、データベースが大きくなるとさらに役立ちます。
お金を見せて
冒頭で述べたように、SQLパフォーマンスの調整は、コストを節約できるため、データベース管理にとって重要です。どうやって？
特にクレジットカードによるスケーリングが一般的なクラウドでは、ITチームは毎月のストレージが実際にどれほど高価になるかを調べています。さらに、不十分に記述されたクエリを実行し、AWSとAzureにインデックスを管理させると、クラウドコンピューティングのコストが増加することを理解し始めています。遅いクエリと悪いインデックスはあなたにお金がかかります。
SQLパフォーマンスの調整とは、これらすべてを正しく行うことです。そうすれば、オンプレミスのOpExの世界にとどまる場合でも、クラウドのCapExの世界に移行する場合でも、支出を管理できます。