web-dev-qa-db-ja.com

SQL Server 2019のパフォーマンスは2012よりも悪い...何か不足していますか？

同じインフラストラクチャで（私が見る限り）SQL Server 2019データベースよりもはるかに優れたSQL Server 2012サーバーがあります。同じSLAを使用して、両方のデータベースをクラウドプラットフォームでホストしています。どちらも180GB RAMおよび16個のプロセッサーを備えています。

ただし、いくつかの重要な違いがあります。

  1. 2012データベースサーバーはエンタープライズ、2019は標準です。私の知る限り、これは違いを生むべきではない
  2. 2012データベースが2019サーバーに復元され、バージョンが150（2019）に変更されました
  3. 2012サーバーのMAXDOPは0でした、2019サーバーはMicrosoftや他の人が推奨するように8に設定されています
  4. 並列処理のコストしきい値= 2012サーバーでは5、2019サーバーでは20

編集：私が気付いたもう一つの大きな違い-1つはWindows Server 2008、もう1つはWindows Server 2019です。それはおそらくサーバー側の設定かもしれません...

すべてのSQLディスクのアロケーションユニットサイズは64kbに設定されています。SQLには、ファイルサイズ自体を制御するための適切な権限があります。サーバーは高パフォーマンスモードに設定されています。他に何かサーバー側を変更する必要がありますか？

その他のデータベース設定は変更されなかったため、次の設定は2019年のデフォルトです。

  • 従来のカーディナリティの推定=オフ
  • パラメータスニッフィング=オン
  • クエリオプティマイザーの修正=オフ

主に実行するクエリのタイプは、更新と挿入を実行する大規模で複雑なマルチ結合クエリであり、ユーザーからの小さな選択が時々行われます。大きなファイルをデータベースにロードしてから、通常は一度に1つずつ、大きなクエリでデータを処理します。これらの大きな「ロード」の合間に、ユーザーは、将来のロード/プロセスのステップに備えてロード/処理されていない他のデータベーステーブルを選択します。通常、処理のパフォーマンスは30％〜50％低下します。これはMAXDOP設定が原因であると考えましたが、0に変更しても、一連の実行で違いはありませんでした。

主な症状は、処理がビジーなときに2019サーバーに接続しようとすると、ロックタイムアウトが発生するのに対し、2012サーバーはまだ非常にゆっくりと接続にサービスを提供していることです。サーバーの接続タイムアウト設定を高く設定することを考えていましたが、それでもサーバーから応答が得られないのではないかと思います。それは少しでもビジー状態の場合、すべての新しい接続をブロックしているようなものです。

他に試すべきことはありますか？それらのデータベース設定をいじくり回す価値はありますか？

さらに掘り下げてDMVの調査を開始することもできますが、これはパフォーマンスが大幅に低下する「好きなもの」環境のアップグレードに近いようです。より大きな調査を行う前に、他に確認すべきことがないことを確認するだけです。

sql-serverperformanceupgradesql-server-2019
5
blobbles

データベースのアップグレード、クエリストアの有効化、データベースの互換性レベルを上げる前のテストが、推奨されるアップグレードプロセスである理由を発見したと思います。

enter image description hereデータベースの互換性レベルを変更し、クエリストアを使用

計画の回帰が多い場合は、次のように、より高いデータベース互換性レベルで古いカーディナリティエスティメータを使い続けることができます。

ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
10
David Browne - Microsoft

Sql Server 2012からのアップグレードで同様の問題が発生しました。

SQL Server 2014で導入されたCardinality Estimatorの変更が原因でした。

テスト環境でレガシーカーディナリティ設定をオンに変更して、ワークロードのパフォーマンスを比較してみてください

https://blog.sqlauthority.com/2019/02/09/sql-server-enabling-older-legacy-cardinality-estimation/

3
dbakerry987

SQL Server 2008 R2からSQL Server 2019へのアップグレードで同様の問題がありました（互換性レベル150）。

夜間の更新ジョブの一部は、実行に突然6〜7倍の時間がかかりました（4分から39分、1時間から6時間）。

従来のカーディナリティ設定をONに設定すると、通常の更新速度に戻りました。

これが私たちがしたことです（ソース： https://blog.sqlauthority.com/2019/02/09/sql-server-enabling-older-legacy-cardinality-estimation/ ）：

USE [YourDB]
GO
ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO
2
btb

別の可能性は、グローバルトレースフラグ9481を有効にすることであり、インスタンス内のすべてのワークロードはレガシーCEを使用します

0
Javier Villegas