データベースには、フロントエンドアプリケーションをサポートするためのSQL Server 2008R2 Enterpriseエディションがありました。以前はタイムアウトの問題はありませんでした。最近、会社はデータベースをSQL Server 2014 Enterpriseエディションにアップグレードすることを決定しました。クラスター設定は常に2ノードです。新しいサーバーは、古いサーバーよりもCPU、メモリが優れています。
アップグレード後、必要なすべての変更、データベースの整合性の確認、DBCC UPDATEUSAGEの実行、統計の更新、インデックスの再構築、ストアドプロシージャの再コンパイルなどを行いました。データベースの切り替えと移行はすべてうまくいきました。ただし、ユーザーはタイムアウトの問題について不平を言い始めます。
私はさまざまな記事、ブログ投稿を確認し、接続文字列の変更やMultiSubnetFailover = 'True'の追加などのいくつかの変更を加えました。この問題の原因と解決方法を知っている人はいますか?この問題を解決するためのあなたの提案と勧告を強く感謝します。
ようやく問題がわかりました。何日にもわたってしまった後、SQL Serverレポートを確認したところ、temp dbデータベースで自動拡張が非常に多く発生していることに気付きました。この問題の原因は、データベースを新しいサーバーに移行した後、システムデータベースのファイルサイズが構成されず、tempdbが想定よりもファイルサイズを小さくすることができたためです。
Tempdbで自動拡張操作が発生すると、クエリが強制的にロールバックされ、問題が発生するようです。ファイルサイズとファイル拡張サイズを変更するだけです。今ではそれは魅力のように機能しており、それ以来問題はありません。
カーディナリティ推定ロジックはSQL Server 2014向けに更新されたため、原因である可能性があります。古いカーディナリティエスティメータで同じクエリをテストし、パフォーマンスメトリックを比較する必要があります。 互換性レベル を<120に下げることでこれを行うことができます。
このテストはすべてテストサーバーで実行し、運用環境では実行しません。
https://msdn.Microsoft.com/en-us/library/dn600374(v = sql.120).aspxhttps://www.brentozar.com/archive/2014/04/sql-2014-cardinality-estimator-eats-bad-tsql-breakfast /