4

ちょっとした背景: サーバーには 17 の異なる TempDB データベース ファイルと 6 つの TempDB ログ ファイルがあります。これらは異なるドライブに分散されていますが、2 つのドライブ アレイでホストされています。

ディスク IO の応答時間が推奨制限を超えています。通常、ディスクは 5 ～ 10 ミリ秒で応答し、200 ミリ秒を超えることはありません。TempDB ファイルで最大 800 ミリ秒のランダムなスパイクが見られますが、1 つのドライブ アレイでのみ発生します。

提案された解決策: SQL サーバーを再起動します。SQL サーバーがシャットダウンしている間に、TempDB ファイルの大部分をホストしているドライブ アレイを再起動します。さらに、SQL がダウンしている間に、ネットワーク接続をやり直してネットワーク スイッチをバイパスし、ハードウェアの速度低下の原因を排除します。

これは良いアイデアですか、それとも暗闇でのショットですか? 何か案は？前もって感謝します。

4

1 に答える 1

10

17？誰がその番号を思いついたのですか？これとこれを読んでください。特に、基盤となるアレイ/コントローラーが2つしかない場合は、8を超えるファイルが役立つシナリオはほとんどありません。いくつかの提案：

  1. 偶数のファイルを使用します。ほとんどの人は4または8から始めて、まだ競合があることを証明した場合にのみそれを超えて増加します（また、基盤となるI / Oが実際により多くのファイルを処理し、それらに合わせてスケーリングできることも知っています。場合によっては、効果または正反対の効果-異なるドライブ文字は、必ずしもより良いI / Oパスを意味するわけではありません）。
  2. すべてのデータファイルのサイズが同じで、自動拡張設定が同じであることを確認してください。サイズと自動拡張設定が異なる17個のファイルがあると、ラウンドロビンが無効になります。多くの場合、SQL Serverが比例塗りつぶしを実行する方法により、1つのファイルのみが使用されます。そして、奇数を持っていることはちょうど...まあ、私には奇妙に思えます。
  3. 5つの余分なログファイルを削除します。彼らは絶対に役に立たない。
  4. トレースフラグ1117を使用して、すべてのデータファイルが同時に（2.のために）同じ速度で大きくなることを確認します。ただし、このトレースフラグは、tempdbだけでなく、すべてのデータベースに適用されることに注意してください。詳細はこちら。
  5. トレースフラグ1118を使用して割り当てを変更することもできますが、最初にこれをお読みください。
  6. インスタントファイル初期化がオンになっていることを確認してください。これにより、ファイルが展開されたときにファイルをゼロにする必要がなくなります。
  7. tempdbファイルのサイズを事前に設定して、通常の日常のアクティビティ中にファイルが大きくなる必要がないようにします。tempdbファイルは突然大きくなるため、縮小しないでください。これは、すすぎと繰り返しの操作です。一度大きくなると、再び大きくなるためです。その間に回収されたスペースを貸し出すことができるわけではありません。
  8. 可能であれば、他の場所で実行しDBCC CHECKDBます。定期的に走っているならCHECKDB、イェーイ！背中を軽くたたいてください。ただし、これはtempdbに負担をかける可能性があります。この操作を最適化し、可能な場合は本番インスタンスから削除する方法については、この記事を参照してください。
  9. 最後に、表示されている競合のタイプを検証します。tempdbのパフォーマンスがクロールすると言いますが、どのようにですか？これをどのように測定していますか？こことこことこことこことここのtempdbボトルネックの正確な性質を判断するためのいくつかの情報。

明示的にtempdbをあまり使用しないことを検討しましたか（#tempテーブル、@ table変数、静的カーソル、またはカーソル全体の数が少なくなります）。RCSI、MARS、またはLOBタイプのローカル変数を多用していますか？

于 2013-02-04T22:57:36.297 に答える