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

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_ONLYthis および 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