web-dev-qa-db-ja.com

インデックススプールが遅い（Eagerスプール）新しいサーバーと古いサーバーがインデックスを使用

昨日、SQL Server 2008からSQL Server 2017にアップグレードし、パフォーマンスの問題が発生しているという質問を投稿しました。

1つのデータベースでは機能するが、他のデータベースでは機能しない統計を更新しようとする答えを得ました。 2008年から2017年に互換性レベルを設定する必要がありますか？現時点では、互換性レベルは100のままです（SQL Server 2008）。

古いサーバーは物理サーバーでしたが、新しいサーバーはVM（Hyper-V）です。

アップグレード後、実行プランは古いプランとは異なって見え、インデックスを使用する代わりにインデックススプール（Eager Spool）を使用しているようです。つまり、実行時間は、古いサーバーの3秒から新しいサーバーの1分50秒になりました。

同じクエリでEager Spoolがないデータベースとの唯一の違いは、テーブルの行が少ないことです。これは、非稼働時の13.000.000行と稼働時の70.000行です。正しい実行計画。

以下の計画は匿名化されていますが、十分な情報があることを願っています。

これはEager Spoolを使用した計画です vs Indexを使用した他のデータベース

私が試してみました

  • 統計の更新
  • それに応じてcost threshold for parallelismおよびmax degree of parallelismを変更します。
  • インデックスが以前と同じであるかどうかを再確認します。
  • READ_COMMITTED_SNAPSHOTを見てきました。
  • NUMAの設定を確認しました。

別の問題は、待機タイプが高いことです

LCK_M_IS, 
CXPACKET, 
LCK_M_X, 
ASYNC_IO_COMPLETION, 
LCK_M_IX, 
PAGELATCH_EX, 
BACKBUFFER, 
TRACEWRITE.

アイデアが足りなくなってきています。

最大メモリはOS用に4GBを残すように設定されています。昨日、ホストマシンの電源プランがバランスするように設定されているが、高パフォーマンスに変更しましたが、同じ問題が発生しました。

統計を更新するために受け取ったアドバイスについて：
いずれかのデータベースで作業したようですが、他のすべてのデータベースでまだ問題があります。

古いサーバーは、8コアと32GB RAMを備えた物理サーバーでした。新しいサーバーは、VM 4コアおよび64GB RAMのHyper-Vで実行されています。

sql-serversql-server-2008sql-server-2017
3
Enigma

新しいサーバーでRAM）の量が2倍になると、クエリオプティマイザーが予想よりもパフォーマンスの悪いプランを選択する可能性があります。

_DBCC OPTIMIZER_WHATIF_を使用してみてください1 古いシステムのように、コアが20個でRAMが32 GBしかない場合にどうなるかを確認します。 sqlserverscience.com でどのように機能するかを示すブログ投稿を書きました。

32GBのRAMでのプラン選択への影響を確認するには、次のコマンドを使用できます。

_dbcc optimizer_whatif ('MemoryMBs', 32768);
_

クエリのプランをプランキャッシュから削除するか、 _WITH RECOMPILE_ または OPTION (RECOMPILE) これにより、SQL Serverが「より適切な」プランを選択できるかどうかを確認します。

_dbcc optimizer_whatif_を使用した後でより良いプランが見つかった場合は、クエリをリファクタリングしてオプティマイザがより適切な選択を行えるようにするか、 プランガイドを作成することができます 。

あなたは この質問と、異なるリソースを持つ2つのサーバーでの実行計画の違いについての回答 に興味があるかもしれません。

将来の訪問者のための参考情報：ほとんどのデータベースは互換性レベル100に保たれているという質問です。これにより、SQL Server 2014以降でのカーディナリティエスティメーターの変更に関連する一連の潜在的な問題が排除されます。

1-これはサポートされていないDBCCコマンドであり、テスト目的でのみ使用する必要があることに注意してください。

3
Max Vernon

SQL Serverをアップグレードする場合、「スムーズな」移行を確実にするために、完了する必要のあるタスクがいくつかあります。

私が使用するリストは here にあります。このリストには、CHECKDBの実行、互換性レベルの確認、ビューの更新、統計の更新などのタスクが含まれています。

あなたの場合、古くなった統計が問題のようです。この結果、 カーディナリティエスティメータ は、データの分布と返される行を予測するための正確な推定を行うことができず、異なる最適ではない可能性のある実行計画が生成されます。

更新された質問に基づいて編集

また、互換性レベルの更新についても触れています。上記のリンクは、互換性レベルを調整する方法と理由に関する情報を提供します。これを変更する主な理由の1つは、v12（SQL Server 2014）がCardinality Estimatorの主要なアップグレードを提供したことです。これが違いを生むかどうかを判断する最良の方法は、できればアップグレードが実行される前にテストすることです。これは、アップグレード後に同様の実行プランを生成するのに役立ちます。

2
DimUser