突然インデックスやクエリを変更する必要がある理由に答える方法

私は3年の経験を持つジュニアDBAです。私たちの仕事は、クエリを微調整するか、特定のコードを書き換えるか、インデックスが必要であることを開発者にアドバイスすることです。

開発チームが頻繁に尋ねる1つの簡単な質問は、「昨日は問題なく動作しましたが、何が突然変化しましたか？」です。インフラストラクチャの側面を確認するよう求められます。問題に対する最初の反応は、常に検証される最初のことであるインフラストラクチャに最大の責任を負わせることです。

開発チームからの「何が変わったのか」という質問にどのように答えればよいでしょうか？皆さんは今まで同じ状況に直面しましたか？もしそうなら、あなたの経験を共有してください。

開発者が変更した質問にどのように答えますか？

これは、DEVだけでなく、ITおよびビジネスのすべてのチームに当てはまる非常に一般的な質問です。

何が変わったの？==>事実と数字で答えることができます。

事実は例えばを参照します

• データベースにアクセスしているユーザーの数を増やしますか？
• サーバー構成パラメーターの変更？
• データベースのメンテナンス-統計の更新、インデックスの再編成/再構築が実行されていませんか？このため、プランは正しく生成されていません。
• データ量が増えた？
• アプリケーションのビジネスサイクルの完全な回帰テストを行わずに、ネットワーク側で変更が行われ、OSにパッチが適用され、SQLサーバー用の新しいサービスパックまたはCUが展開されましたか？
• 基礎となるSANが突然遅くなった？

表示するデータがあれば、数値を導き出すことができます。例えば ​​：

• この状況では、サーバーのベースラインを設定することが重要です。あなたは固体の数字で事実をサポートすることができるので、これは非難ゲームを軽減します。
• DMVまたはsp_whoisactiveを使用してテーブルへのデータ収集を開始し、SQLサーバーの再起動後にデータが保持されるようにします。

（環境とニーズ、データを収集する頻度/収集するデータ、および保持期間はどれくらいになるかについて、ワークアウトする必要があります）または（sqlsentryやideraの診断マネージャーなどのサードパーティソフトウェアに投資できます）上記の作業を行います）。

まあ、あなたは別の計画を得ている可能性があります：

• 次の理由により、計画はキャッシュから削除された可能性があります。
  • サービスの再起動
  • プランキャッシュの手動クリア
  • サービスの再起動またはフェイルオーバー
  • 不注意な変更、たとえば特定のsp_configure変更がキャッシュをフラッシュする可能性がある
  • 基礎となるオブジェクト、インデックス、統計、またはその他の依存関係への変更により、再コンパイルがトリガーされました
• 次の理由により、他のユーザーまたは以前の呼び出しとは異なるプランを取得している可能性があります。
  • クエリテキストが同一でない可能性があります（大文字と小文字の区別と空白が含まれます。別の列、結合条件、フィルターなどを気にしないでください）。
  • （計画内の任意のオブジェクトは、完全修飾名を持っていない場合、または別のデフォルト・スキーマクエリは、異なるセットのオプションで異なるユーザによって実行することができスキーマを含みます）
• クエリとプランは同じである可能性がありますが、次の理由によりパフォーマンスが異なる可能性があります。
  • プランはさまざまなパラメーターを使用してキャッシュされ、そのプランは現在のパラメーターセットには最適ではありません（これは一般に「パラメータースニッフィング」と呼ばれます）
  • パラメータに基づくデータ量、または単にデータの変化によるデータ量が大幅に異なる
  • データはデータにアクセスするための最も効率的な方法を変更するのに十分に変更されましたが、統計の更新または再コンパイルをトリガーするのに十分ではありません（昇順のキーの問題と自動統計アルゴリズムを検索）
  • データはバッファプールから追い出されており、ディスクから読み取る必要があります
  • クエリを満たすために必要なリソースの同時実行性、ブロッキング、またはその他の負荷が高い

私はこれらの多くをここでより詳細に調べます：

• 「同一の」クエリの複数のプラン

これらが異なる環境で実行されている場合は、ここで一連のことを確認します。

• 「同一」サーバーの異なるプラン

また、インデックスを作成したり、クエリを変更したりしても、クエリのパフォーマンスが突然向上する直接的な理由にはならない場合があることに注意してください。これらの変更によって新しいプランが実際に生成されたり、既存のプランが無効になったりする場合もあります。 。

いつものように、アーロンベルトランとキンは素晴らしい答えを出しました。ただし、両方の回答には共通のスレッドが含まれています。どちらかの回答を分析すると、XYZが昨日と同じように機能していない理由は、Xが行ったことが原因ではないことがわかります。状況が変わった理由は、データベースがXYZの理由により別の方法で行うことにしたためです。

データベースは、生きている呼吸する実体です。データベースは、仮定、統計、およびその他のヒューリスティックツールの組み合わせにより、意思決定を行い、その考えを変えます。これは、ほとんどのアプリケーション層プログラミングとは大きく異なります（機械学習は注目すべき例外です）。

_{今はもっと良いものを考えることができないので、いくつかの軍事関連資料を使用します。より一般的なメタファーが評価されます（しゃれは意図されていません）。}

ほとんどのアプリケーションでは、プログラマーはドリルインストラクターとして機能します。彼らはコンピュータに何を何の順番で、時にはどれだけの時間を正確に伝えるかです。データベースのプログラミングは、指揮官として行動することに似ています。高レベルで何をしたいかを伝え、必要に応じていくつかのガイダンスを提供します。データベースは、下級将校や下士官のような現在の情報に基づいて計画を実行するための最良の方法を理解する仕事を引き受けます。

他のプログラマの心でこの区別を明確にすることにより、彼らはあなたが彼らの環境に対して行うような独裁的な力を持っていないことに気付くようになるでしょう。あなたはデータベースをソリューションに導き、時々データベースは正当な理由または悪い理由で軌道から外れます。最終的には、データベースが正常に機能しなくなった*ことは問題ではないが、それを回復するために何ができるかを彼らに思い出させる。

_{*「なぜ」は将来の予防、学習などに非常に役立つことを認識していますが、OPは問題について学びまたは助けようとしない人々からの抵抗に直面しているようです。}