TempDBの競合

SQL Server 2014 SP1にアクティブなOLTP 40GBデータベースがあります。IO_Completionの待機、ディスクキューの長さが900に上昇し、SQL Serverが応答を停止すると、クエリが遅くなることがわかりました。私たちが試したもの：

1. インスタンスを再起動すると、すぐに同じように動作し始めます。

2. 2回目の再起動後、各tempdbデータファイルの初期サイズを変更し（16個のデータファイルが作成されます）、正常に動作し始めました。

注：中間結果セットにはテーブル変数を使用しています。これらの結果セットは非常に小さいです。

それは月に2回起こりました。データファイルに手動で少しのスペースを追加するたびに、正常に動作し始めます。さらに興味深いのは、SQL Server 2008 R2とSQL Server 2012で同じセットアップ（同じハードウェア、同じフォルダーとファイルのセットアップ、同じワークロード）が正常に機能していることです。

恒久的な解決策を見つける手助けをしてください。

すべてのデータファイルの初期サイズは同じ1000MB、現在はそれぞれ1500MBです。すべて同じです。自動拡張はそれぞれ100MBです。これまでは、PFSおよびGAMページの競合に直面していましたが、16まで増加し、問題は解決しました。トレースフラグ1117と1118の両方が有効になっています。2つのNUMAノード上の24コア。すべてのデータファイルは同じボリューム上にあります。シンプルディスク、SANなし。

インスタンスは物理マシン上にあります。テーブル変数を使用したクエリとハッシュ結合を使用したクエリは、最も一般的にIO_Completion待機を生成します。

wBobによる詳細な回答により、さらに詳細に検索するようになりました。以前どのようにそれを見逃しましたか：

データベース「tempdb」のファイル「templog」の自動拡張がユーザーによってキャンセルされたか、7704ミリ秒後にタイムアウトしました。ALTER DATABASEを使用して、このファイルのFILEGROWTH値を小さく設定するか、新しいファイルサイズを明示的に設定します。

これは、この種の問題が発生したときにログに記録されたものです。TempDBを別の高速ドライブに移動しています。

tempdbを過剰に断片化し、サーバーのCPUとディスクのセットアップが一致していないと思いますが、さらに情報を収集しましょう。

質問/詳細情報が必要

• プロセッサの名前とタイプを確認してください（基本的に、HT付きの2 x hex-coreかどうかを確立しようとしています）。システム情報（例：Windows Server 2012 R2の[コントロールパネル]> [システムとセキュリティ]> [システム]）および/またはsysinternalsツールCoreInfoを使用して確認します。
• サーバーのmaxdop（例EXEC sp_configure 'max degree of parallelism'）を確認してください。CPUが16進コアの場合、サーバーのmaxdopは最大6（ここで説明）であるか、OLTPシステムではおそらくそれよりも低くなければなりません。通常、サーバーのDOPに合わせてtempdbファイルを最大8つまで保持しますが、それについては説明します。
• ボックスのサーバー合計メモリとSQL Serverのメモリキャップ（例EXEC sp_configure 'max server memory (MB)'）を確認してください。
• ボックスで他のサービスが実行されているかどうかを確認してください（SSIS、SSAS、SSRS、アプリケーション、iTunesなど）
• SQL Serverサービスアカウントでインスタントファイルの初期化が有効になっていることを確認してください。（ここでテストする方法）。
• CPU（2ノードのNUMAセットアップ）と1つのディスク（ホームPC）の間に大きな違いがあるのはなぜですか？ディスクの追加、ストライピング、tempdb用のSSDを検討してください（ただし、過剰な反応は避けてください）。
• 問題のあるクエリの1つに実際の実行計画を追加してください。必要に応じて、SQL Sentry Plan Explorerによる匿名化。

• ハッシュはOLTPシステムのテーブル変数と結合しますか？これは、テーブル変数、メインテーブル、またはその両方のインデックス付けの欠如を示唆しています。このようなテーブル変数を宣言していますか（インデックスなし）？

  DECLARE @t TABLE ( x INT )

• 小さな結果セットを保持している場合でも、テーブル変数の定義を軽視しないでください。可能な限り多くの情報をオプティマイザに提供することが常に最善であるため、インデックスがクラスタ化/非クラスタ化されているかどうかにかかわらず、null可能性、一意性を明示してください。

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• 実行計画を投稿すると、これを診断するのに役立ちます。

• コードがあたりとしてテーブル変数のキャッシングを防ぐためのチェックここでは、ここに。テーブル変数に影響を与えるのは、WITH RECOMPILEで実行される動的SQLとprocだけだと思います。

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• IO警告などのメッセージについて、SQL Serverログ（[オブジェクトエクスプローラー]> [管理]> [SQL Serverログ]）を確認します。

• Windowsイベントビューアーを確認する
• SP1以降、多くのビルドがリリースされています。SP1以降に追加されたCU修正を確認します。SP1の後続のCUで修正されたバグがある可能性があります。たとえば、FIX：推定行数と行サイズが正しい場合、SQL Server 2012またはSQL Server 2014でソート演算子がtempdbに流出する https://support.microsoft.com/en- us / kb / 3088480
• 修正プログラムを適用する前に、これが原因であることを確認してください。ただし、新機能（インメモリOLTP、クラスター化列ストア）の数が多いため、SQL Server 2014のCUを最新の状態に保つことがより重要です。
• 最後に、コアごとに1つのtempdbファイルが必要なのは神話であり、ディスクのセットアップを見ると、tempdbが過度に断片化されていると推測されます。ディスクヘッドが1つ、tempdbに1つのファイルグループ、多くのファイルがあります。

しかし、私たちが知っていると思うことを忘れてください。問題を再現するテストリグを作成し、一時ファイルの数を減らして実験します。1、2、4、6などで情報を収集し、証拠に基づいた意思決定を行います。問題は断続的に見え、tempdbの設定を台無しにできないかもしれないので、これはより難しいビットですが、それが私がこれにアプローチする方法です。

幸運を。乗車方法をお知らせください。