TempDB内の競合であると私たちが信じていることが原因で問題が発生しています。
問題が発生しているときはいつでも、システムは常に1つの特定のリソースを待機しています:2:1:103、それを検索すると(DBCC PAGE(2,1,103)を使用)、システムテーブルsysmultiobjrefsであるobject_id75に戻ります。 。
この問題を解決するために、そのリソースを待機しているぶら下がっているspidを強制終了することで回避できる場合があります...最悪の場合、実際にSQLを停止してバックアップを開始する必要があります。
これを軽減する方法についてのアイデアはありますか?
128GBのRAMを搭載したクワッド/クワッドサーバーでSQL2005 SP3x64を実行しています。ディスクもSANにあり、log/tempdb/dataはそれぞれ独自のRAID1/0ドライブにあります。
TempDBには、16個のデータファイル(コアごとに1個)と1個のログファイルがあります。
前もって感謝します。
SQLコードにSELECTINTOステートメントがたくさんありますか?これにより、SELECT INTOステートメントが完了するまで、いくつかのtempdbシステムオブジェクトがロックされます。
ロブ、
私たちの環境では、彼の2:1:103の問題に約1か月間取り組んできました。この問題を防ぐ方法の1つは、オプションの場合、SQLサービスを定期的に再起動することです。この特定の問題については、多くのフォーラムで明確な回答がありませんでした。 T1118フラグは、Linci Shea(MVP)や他の数人のブログで提唱された議論では有効とは見なされていません。
私が個人的に問題が発生して消えるのを見た1つの本番シナリオは、SQLサーバーがメモリを24Gbから27GBに増やす機会を得たときでした。 24GBでは、無関係のタスクジョブがdbサーバーで実行されている間、2:1:103で約40のプロセスがハングしていました。私はそのタスクを強制終了し、SQLは利用可能な30 GBからより多くのメモリを取得し始め、Tempdbの競合は27GBを取得してから約1分ほどで27GBで徐々に消えました。それはあなたがそれを自分でテストすることを試みることができる1つの領域です。 DBサーバー上の他のサービスのフットプリントを減らし、SQLに使用できる最大メモリを増やします。
同じための他の解決策を見つけたら私に知らせてください。
シン。
私はここでのパーティーに遅れていることに気づきましたが、私のチームは今週2:1:103で駆け込みました。基本的に、このリソースの競合は、tempdbでのDDL操作との競合を示し、一時テーブルまたは一時テーブル変数の作成/破棄が多すぎることが原因です。私はこれについて http://www.mattwrock.com/post/2011/09/10/Latch-waits-on-21103-You-are-probably-creating-too-many-temp-tablesでブログに書いています-in-Sql-Server.aspx ここでの競合は、トレースフラグT1118またはtempDbへのファイルの追加によって軽減されることはありません。重要なのは、一時テーブルと一時テーブル変数の使用を減らすか、それらの使用状況を評価して、それらがキャッシュされているかどうかを確認することです。詳細については、 http://technet.Microsoft.com/en-us/library/cc966545.aspx を参照してください。
トレースフラグT1118を有効にしようとしましたか?
記事からの引用:
注トレースフラグ-T1118は、Microsoft SQL Server2005およびSQLServer 2008でも使用可能であり、サポートされています。ただし、SQL Server2005またはSQLServer 2008を実行している場合は、修正プログラムを適用する必要はありません。
Tempdbデータファイルの数を、少なくともプロセッサの数と等しくなるように増やします。また、同じサイズのファイルを作成します。詳細については、「詳細情報」セクションを参照してください。¨
以前はSP2のtraceflagT1118でパフォーマンスの問題がありましたが、Msは修正プログラムをリリースしました。これは、あなたの場合と同様に、SP3で修正する必要があります。
一時テーブルの作成方法についてmrdennyに同意します。次のようなWHERE句がない限り、SELECT * INTO #x FROMTableAを使用して一時テーブルを作成しないでください。
WHERE 1 = 2
ただし、CREATE TABLE#x構文を使用することをお勧めします。どうして? SQLは、クエリがデータをフェッチして一時テーブルに挿入しようとする限り、システムテーブルに多くのロックを設定します。明らかなwhere句を使用しても行やテーブルの作成構文が返されない場合、ロックは短期間保持されます。
/HåkanWinther
お互いの作業を踏むトランザクションからデッドロックが発生しているだけではないことを確認しましたか?ロックが発生したときに実行中/ロックされたSQLクエリを確認しましたか?