web-dev-qa-db-ja.com

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競合の原因を絞り込むにはどうすればよいですか？

sql-serverperformancesql-server-2005ddltempdb
9
David George

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

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

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

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

すべてのカーソルがLOCAL STATIC READ_ONLY FORWARD_ONLY（ this および this を参照）を使用していることを確認し、＃を多用する既知の高コストのクエリがないか確認します。一時テーブル/ @table変数、CTE、または不要なソートが含まれるか、ハッシュ結合につながる可能性があります...これらすべてが問題の原因となる可能性があります（1つの根本的な原因が見つかるとは思えません）。 「大金」の出発点としての最も簡単な抜本的な修正は、デフォルトの代わりに適切で安価なカーソルオプションを使用することです。

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

14
Aaron Bertrand

TempDBデータファイルをすでに分割して、競合を軽減しようとしていると思います（最初に本稼働前に明らかに）。勇気があるなら、Paul Randalが正式に参照しているトレースフラグを検討してください。 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

5
Peter Schofield

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

tempdbに関するポールランダルの神話 を最初に参照し、彼の TF 1118の記事も を参照

TFはここ KB 328551 で説明されています

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

5
gbn

これを追跡するためにまだ探している場合、私は最近、同期テーブルのドロップで同様に奇妙なパフォーマンスの問題がありました。 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では遅い一時テーブルが削除されます

4
JorgeSandoval