TempDBでのDDL競合

過去数か月間、TempDB DDL競合の問題が発生しているSQL Server 2005 Standard x64があります。サーバーは待機リソース2：1：103（待機タイプはPAGELATCH_EX）で競合が発生します。

この問題は、サーバーに適切な負荷がかかっているときに散発的に発生するようです。私は「破壊用の一時テーブル」のレートを監視しており、2：1：103でPAGELATCH_EXの問題が発生しているときに5,000以上にジャンプする可能性があります。私が読んだことから、このカウンターはほとんどの場合0であるはずですが、私たちのカウンターはほとんどの場合300〜1100のどこかにとどまっているようです。システム上のユーザーが非常に少ない場合にのみ、カウンターは0になります。

干し草のスタックで針を探す必要なしに、tempdbのDDL競合の原因を絞り込むにはどうすればよいですか？

私はこの問題を見てきましたが、それを修正するために最終的にリリースされた修正プログラムは、実際にはMicrosoft CSSでの私のケースの直接の結果でした。修正に関する公開KB記事はありません。Service Pack 4と最新の累積的な更新をSQL Serverに適用したことを確認してください（執筆時点では、累積的な更新＃3（9.00.5259）です）。

修正プログラムがリリースされるまで、Microsoftの提案は#tempテーブルの作成を単に停止することでした（KB＃916086のように）。これは、数十および数十のレポート手順を大幅に書き換えることになるため、私の場合の回避策（トレースフラグや一時ファイルのレイアウトに関係なく）は、隔週でクラスターを再起動することでした。ああ。

tempdbの使用状況を追跡するために役立つスクリプトがいくつかあります。たとえば、Adam Machanicのsp_whoIsActiveを参照してください。

• sp_whoisactive：Tempdb競合の分析
• tempdbトランザクションログがいっぱいになっているクエリを特定するにはどうすればよいですか？

また、@ SQLSoldierからのこのスクリプト（およびコメント内のスクリプト）：

• TempDBの競合の分析

すべてのカーソルが使用されていることを確認しLOCAL STATIC READ_ONLY FORWARD_ONLY（これとこれを参照）、＃tempテーブル/ @table変数、CTEを頻繁に使用するか、不要な並べ替えが含まれていたり、ハッシュ結合につながる可能性がある既知の高価なクエリがあるかどうかを確認します...これらすべてが問題の原因になっている可能性があります（私があなたに1つの黄金の原因が見つかるとは思えません）。「手ごろな価格」の開始点としての最も簡単な抜本的な修正は、デフォルトの代わりに適切で安価なカーソルオプションを使用することです。

それまでの間、（a）CU＃3をインストールし、（b）PSSを呼び出します。バグとして既に確認されており、プライベートホットフィックスとして他のユーザーにリリースされている非常に具体的な修正の後にいることを伝えます。最初にケース料金を支払う必要があるかもしれませんが、それはバグであるため、料金は返金されます。

おそらくトレースフラグ1118が必要です

まずtempdbに関するPaul Randalの神話と、彼のTF 1118の記事もご覧ください。

TFについては、KB 328551を参照してください。

私はこれを直接経験していませんが、読んだように聞こえます

TempDBデータファイルをすでに分割して、競合を軽減しようとしていると思います（本稼働前に最初に明らかに）。勇気があるなら、ポールランダルが正式に参照しているトレースフラグを検討してください：http ://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230 ） -tempdb-should-always-have-one-data-file-per-processor-core.aspx

何が痛みを引き起こしているのかという観点から、調査作業を行う必要があります。

• これが発生し始めたばかりですか？変化したこと？
• サーバーはメモリ不足になっているので、TempDBで並べ替えを行う必要がありますか？
• CheckDBのようなDBAプロセス、またはオンラインでの再インデックス、実行中はありますか？
• よりエキゾチックな分離レベル、またはサービスブローカーが使用されていますか？sys.databasesを見てください

このMicrosoft TempDBドキュメントの最後に、tempdbを使用しているものを解決するための素晴らしいクエリがあります。http： //technet.microsoft.com/en-gb/library/cc966545.aspx

これを追跡するためにまだ探している場合、私は最近、同期テーブルのドロップで同様に奇妙なパフォーマンスの問題がありました。SQL 2005を実行しているsqlインスタンスに多数のデータベース（> 100など）があり、多くの一時テーブルの作成および削除ステートメントがある場合、一時テーブルの削除が遅くなる可能性があります。sys.dm_db_index_usage_statsから返された行数を確認すると、これを犯人としてすぐに除外できます。

KB記事に問題が説明されています。http://support.microsoft.com/kb/2003031

sys.dm_db_index_usage_statsに多数の行がある場合、クエリのパフォーマンスが低下する

次のシナリオを検討してください。

Microsoft SQL Server 2005では、多くのテーブル（特にtempdbデータベースの一時テーブル）の削除と再作成を伴うDDL操作を頻繁に実行します。sys.dm_db_index_usage_stats動的管理ビュー（DMV）に多数（100,000以上）のエントリがある。

この質問への私の受け入れられた答えから取った。そこにもいくつかの詳細があります。 SQL 2005の一時テーブルが遅い