「Doc、SQLServerのパフォーマンスが心配です。」
それはほとんどの患者から聞くようなものではありませんでした。しかし、その後、有料の専門家として、データベース管理者であるという困難な時期でさえ、すべてに対処するように訓練されました。
"本当に？それを調べてみましょう。」
「もちろん、ドク。つまり、時々それはとても圧倒されるように感じます。私がそれにコミットした後は、すべてがそれ自体でうまくいくと思いました。しかし、気が付く前に、SQL Server 2012、2014、2017でパフォーマンスの問題が発生し始めました。SQLServer2019についても考えたくありません。」
"そうか。 SQL Serverとの良好な関係は、それ自体で発生するだけではありません。あなたはそれに取り組む必要があります。教えてください、SQL Serverのパフォーマンス調整手法に取り組んだことがありますか？」
「えー、いや、ドク。私はそれらのテクニックのどれも本当に知りません。」
"心配しないで。私たちはそれらに取り組むことができます。 SQLServerはおそらく無視されていると感じています。ゲームの先を行くことを確認するために、それを監視する必要があります。これにはSQLServerの監視が必要です。」
"モニタリング？どうやってそれをしますか？」
「気になるSQLServerを表示する必要があります。特定の指標に注意を払う必要があります。私たちもそれに取り組むことができます。」
「OK、ドク。あなたが言うことは何でも。この時点で何でも試してみます。事態は今よりも悪化することはありませんでした。」
「じゃあね。さぁ、始めよう。"
SQL Serverのパフォーマンスメトリック—多くの可動部分
患者は正しかった：SQLServerのパフォーマンスを監視することは圧倒的に感じるかもしれません。一度起動して実行すると、注意を払うのをやめることはできません。気にかけていることを示し続ける必要があります。
SQL Serverには、常にメトリックを生成する可動部分がたくさんあります。どれを見るかを知り、忙しい一日の時間を実際に取って監視することは、DBAにとって大変な作業になる可能性があります。
そこで、SQLServerのパフォーマンスメトリックの主要な領域のいくつかを患者と一緒に調べました。
インデックス
SQL Serverでパフォーマンスの問題が発生したときに最初に確認する場所の1つは、インデックスです。データは常に増加しているため、インデックスも常に増加しています。ただし、断片化やページ分割などの条件が適用されるため、クエリへの応答が遅くなる可能性があります。
データベースでは毎日何が起こっているのでしょうか。ユーザーはレコードを作成、編集、削除しています。インデックスは、レコードのすべての部分がどこにあるかに追いつきますが、時間の経過とともに、インデックスの断片化がパフォーマンスを妨げます。
次に、インデックスフィルファクターがあります。これは、ページ分割の数を制御し、クエリの効率を高めるためにSQLServerで構成できるパラメーターです。ただし、ページ分割の増減のバランスは、他の点でパフォーマンスに影響します。
フィルファクターで指標を監視する 、I/Oおよびフラグメンテーション これは、SQLServerインデックスの状態を把握するための良い方法です。
バッファキャッシュ
これを簡単にしましょう。ディスク、遅い。バッファキャッシュ、高速。バッファキャッシュは、最近使用されたデータベースページのメモリ内コピーです。 SQL Serverが探しているものを見つけられない場合は、ディスクに移動する必要があり、パフォーマンスが低下します。
SQL Serverでは、バッファキャッシュに割り当てるシステムメモリの量を指定できますが、他のタスク用に残されたメモリとトレードオフします。目標は、他の領域でSQLServerのパフォーマンスを妨げることなくできるだけ多くを割り当てることです。
また、ページの平均余命、つまりデータベースからの情報のページが再度アクセスされることなくバッファ内で費やす時間も重要です。 SQL Serverは、バッファキャッシュからページを継続的に削除して、最近使用されたページ用のスペースを確保しています。ただし、そこで検出される有用なページが少ないほど、ディスクから読み取る必要があり、パフォーマンスが低下します。
ページの平均余命などの指標 およびバッファキャッシュでの成功したヒットの比率 ページの削除頻度を減らしたり、キャッシュのサイズを増やしたりすることについて決定を下すのに役立ちます。
T-SQL
SQL Serverは、T-SQLと呼ばれるクエリ言語を使用します。 SQL Serverは、SQLステートメントをアドホックに実行するのではなく、それらをバッチ処理し、実行プランとしてコンパイルしてキャッシュすることにより、パフォーマンスを向上させようとします。また、コンパイルの頻度を最小限に抑え、実行計画をできるだけ頻繁に再利用しようとします。データベースの変更が多すぎるなどの理由で実行プランを再利用できない場合は、プランを再コンパイルします。プロセスは大量のCPUを消費し、パフォーマンスを低下させる可能性があるため、SQLステートメントの再コンパイルの数をできるだけ少なくすることをお勧めします。
コンパイルと再コンパイルの必要性は、ストアドプロシージャの使用やクエリのパラメータ化など、優れたコーディング手法の機能です。 SQLコンパイルの速度などのメトリックを監視するDBA およびSQLの再コンパイル SQLServerクエリヒントを変更してパフォーマンスを向上させることができます。
プロセスのロック、待機、ブロック
他の誰かがあなたと同時に何かを変更していることに気付くのはイライラします。そのため、データベースは行やテーブルなどを自動的にロックして、複数の料理人がキッチンに入らないようにします。もちろん、その保護のトレードオフは、他のすべてのユーザーがリソースのロックが解除されるまで待機する必要があることです。また、ロックが必要なレベルでのみ行われていることを確認するのは困難です。
ロックが他の操作に影響を与える頻度と範囲を示すメトリックを使用すると、DBAは、トランザクションをより迅速に処理するために、より多くの物理システムリソースの必要性を判断できます。 SQLServerが不必要に低いレベルでロックしている可能性もあります。 ロック待機の頻度 そして、より広義には、ブロックされたプロセスの数 ボトルネックを見つけるのに役立ちます。
SQLパフォーマンスチューニングでボトルネックを解消
「まあ、ドク、あなたはすべての可動部分について正しいです。これで、SQL Serverをインストールして設定し、忘れることができないことがわかりました。私は関係を養う必要があります。しかし、これはまだ圧倒的な感じがします。どうすれば、これほど多くのさまざまなことをまっすぐに保ち、ゲームの先を行くことができるでしょうか？」
「それが最良の部分です。 SQLServerのパフォーマンスに役立つツールがあります。一人で行く必要はありません。」
「ふぅ！それは心強いです。それについては知りませんでした。」
"それは正しい。ツールはSQLサーバーのパフォーマンスを監視し、これらすべてのメトリックを報告するため、チューニング手法を適用してボトルネックを排除できます。」
「本当に？」
"もちろん。そして、私たちはそれらの権利に取り組むことができます—ああ、私、今週は時間切れです。受付係に予約を入れてください。来週迎えに行きます。」
「少年、その4時間はあっという間に過ぎた、ドク！ 断片化、リソース使用量に関するパフォーマンスの問題を解決するときは、時間が経つことは間違いありません。 およびバッファキャッシュヒット率 、そうではありませんか？」
「はい。SQLServerでこれらの問題について率直に話し合うと、パフォーマンスの問題はすべて履歴になります。」
私たちのセッションに勇気づけられて、患者は去りました。次回は、SQLServerのパフォーマンスのボトルネックの監視に取り組みます。ブログで紹介しますので、気を付けてください。
その間、私を信じてください。私は有給の専門家です。データベースとの関係でこれらのことを試してみることをお勧めします。 SQLServerが必要だと感じさせます。パフォーマンス指標に注意してください。
試すのに遅すぎることはありません。