web-dev-qa-db-ja.com

クエリが環境Aでは高速に実行され、環境Bでは低速になるのはなぜですか?

環境Aで非常に高速に実行されるように見えるSQLがありますが、環境Bではまったく同じクエリの実行が非常に遅くなります。

環境は同じであると想定されているので、クエリが同じように実行されない理由を確認するために何をすべきか、および/またはどこを調べればよいですか?

7
LowlyDBA

SQL Serverの内部と外部の両方に多くの要因があり、それらがまったく同じように構成されている場合でも、同じクエリが異なる環境間で異なる動作をする原因となる可能性があります。

サーバー

  • 環境全体のハードウェアは同じですか(ディスク、メモリ、CPUなど)?
    • VMが使用されている場合、 騒々しい隣人 が全体に影響を与える可能性があるVMパフォーマンス?
    • クラウド内にある場合、自動スケーリングやその他の構成にパリティはありますか?
  • 物理/仮想/クラウド間で環境が混在していますか?
  • OSのバージョンは一致していますか?
  • 環境は異なるデータセンターにありますか?

インスタンス

  • SQL Serverのバージョンは同じですか?
    • CUまたはSPは、メジャーバージョンが同じであっても、違いをもたらすことができます。
  • クエリ実行中のアクティブなワークロードは同等ですか?
    • すべての環境で同じ量のクエリが存在していますか?
    • ワークロードの性質はすべての環境で同じですか?
  • すべての環境が同じHA/DRセットアップに参加していますか?
    • 運用環境/ DRがこれらのテクノロジーを使用している可能性がある間、何倍も低い環境では可用性グループ、ログ配布、またはレプリケーションのセットアップがありません。
  • すべての環境で同じメンテナンスジョブが同じスケジュールで実行されますか?
  • トレースフラグはすべての環境で同等ですか?
  • すべての環境で同じバックアップジョブが実行されていますか?
    • バックアップによる影響は最小限に抑える必要がありますが、多くの場合、下位の環境ではまったく実行されません。
  • システム構成は同じですか?

データベース

  • スキーマ/インデックス/統計/オブジェクトはすべて環境全体で同じですか?
  • exact同じデータが環境全体に存在しますか?
    • データ量
    • データの配布
    • データのサイズ(他の環境での実際の値のサイズを反映しない可能性がある可変長データ型のダミーデータを考えてください)
  • データベースレベルの構成は同じですか?
  • 互換性レベルは同じですか?

このすべてを念頭に置いて、多くの場合、さまざまな環境間でデータベースのすべての側面を完全にコピーすることは単純に不可能であることは当然のことです。テストを行うと、各環境でのクエリの実行方法についてある程度の確実性が得られますが、環境間に差異がある場合でも、当然のことです。新しいクエリを開発する場合、本番環境に移行するため、追加のチューニングが必要になることがよくあります。

通常、1つの環境で低速なクエリを調整しても、生成された実行プランに回帰が発生することはないので、全体的な改善のためにインデックス、統計、またはクエリ自体を調整する機会です。

最後の注記:下位の環境はサイズが小さく、多くの場合、実稼働環境または実稼働前環境と同じパフォーマンスを期待できません。

その他のリソース:

13
LowlyDBA

他の答えは良いですが、環境Bのデータ量と他のクエリとの競合を考慮する必要があることを付け加えます。

一部のSQLクエリは分離してパフォーマンスの問題を示しません(たとえば、テーブル内の1000行、他のクエリは実行されていません)が、テーブル内の10,000,000行でホラーショー(たとえば、パラメータースニッフィングの問題)、および/または他のクエリが書き込み、更新する可能性がありますまたは関連するテーブルをロックします。

最初にハードウェア/環境/構成が一致することを確認することに関する他の回答にも同意しますが、明らかなことが何もない場合は、クエリ実行プランの確認、SQLプロファイラーの実行などを開始します。

9
Phil S

つまり、データベース自体が他と比較して遅いのか、その環境が遅いのかを特定する必要があります。最も簡単なことを最初に除外します。

これは何度か私に起こりました。それが環境であることが判明するたびに、別の誰かが1つのサーバー上のIOPSのdbを打ちのめして飢えさせていました。

遅いサーバーでtop(1)を実行し、CPUで大量の待機状態が発生しているかどうか、または仮想環境にいる場合はCPUがスチールしているかどうかを確認します。

これにより、実行計画でインデックススキャンの代わりに全テーブルスキャンが実行される原因となる欠落したインデックスを指摘することもできます(ただし、クエリロギングが遅い場合は簡単に見つけることができます)。これは、D状態のprocとしてpsにも表示されます。

それを除外したら、ハードウェアをより深く掘り下げる時が来ました。すべてのCPUに分散されている作業であり、ネットワークポートが100Mbに再ネゴシエートされています。両方のマシンでvmstatまたはiostatを実行し、違いを比較します。

データセットが同一の場合、同じクエリが両方で同じ実行プランを生成しますか?テーブルには同じ数の行が含まれていますか?インデックス定義は同じですか?テーブルに同様のレベルの断片化がありますか?アクティブな接続の数は同じですか?

3
dland