http://blogs.msdn.com/b/jpsql/archive/2013/01/17/do-s-amp-dont-s-17-tempdb-cpu.aspx
--------
KB 2154845 で述べられていますが、一般的には、tempdb データファイルの数は、SQL Server が使用可能な CPU の数に一致させた方が高負荷時のパフォーマンス劣化を防ぐことができるとされています。
--------
基本ですね。
--------
ただし、2011 年の PASS Conference (PASS : Professional Assosiation for SQL Server) におけるセッション Inside Tempdb で発表されたテスト結果を受けて、8 を超える CPU が使用可能な SQL Server では、tempdb データファイル数は 8 を基準とし、状況を見ながら必要に応じて 4 の整数倍の数のファイルを追加するという方法が推奨されています。
--------
ほぉ、これはしらなかった。けど、うちの業務システムで8CPUを超えるようなサーバを使うことないしなぁ。今後クラウドで展開する場合にはありそうですが....
--------
ただ、これを必ずやらなければならないかと言えば、tempdb 負荷の低い環境では必ずしもやる必要はなく、そのような環境では、やったとしても害はありませんが、これといった効果もありません。tempdb 負荷が高いのか低いのか分からないのであれば、やっておいた方が無難でしょう。
--------
上記の通りだと思います。確かに、SNAPSHOT分離レベルとか使わなくていいぐらいの小規模システムとかは意味ないかもですね。(あと、結構知らない人も結構いたりしますよね。)
--------
SQL Server が 2 CPU を使用して動いているとします。SQLOS Scheduler 0 上の Worker 0 が 2:1:1 (tempdb ファイル 1 の PFS) ページに Latch を獲得している状態である場合、Scheduler 0 上の他の Worker は休眠状態であるため、それらが同じページに Latch を獲得しようとすることはありません。ここで、Scheduler 1 上の Worker 1 が新しい一時オブジェクトを作成しようとしたとします。tempdb が 1 データファイルで構成されている場合、Worker 1 は 2:1:1 へのアクセスが必要になります。ここで Worker 0 との競合が発生します。一方、tempdb が 2 データファイルで構成されている場合には、Worker 1 の割り当て要求は、次のファイルであるファイル 2 で処理されることになります。つまり、Scheduler 1 上の Worker 1 は 2:2:1 へのアクセスは必要としますが、Worker 0 が Lacth を獲得している 2:1:1 へのアクセスは必要としません。つまり、競合は発生しないことになります。
--------
ここまではよく理解してませんでした。まだまだ勉強が必要ですね。
--------
select session_id,wait_duration_ms,wait_type,resource_description
from sys.dm_os_waiting_tasks
where wait_type like 'PAGE%LATCH%' -- PAGELATCH_ または PAGEIOLATCH_
and resource_description like '2:%' -- 2 は tempdb の DBID
--------
このSQLもよく使いますね。
Microsoft SQL Server Japan Support Team Blog は勉強になりますね。
