TempDB'de DDL çekişmesi

Geçtiğimiz birkaç aydır TempDB DDL çekişmesi ile ilgili sorunlar yaşayan bir SQL Server 2005 Standard x64 var. Sunucu bekleme kaynağı 2: 1: 103 (bekleme türü PAGELATCH_EX) üzerinde çekişme yaşayacak.

Sunucu düzgün bir şekilde yüklendiğinde sorun ara sıra ortaya çıkıyor gibi görünüyor. "İmha için Geçici Tablolar" oranını izliyorum ve 2: 1: 103'te PAGELATCH_EX sorunları yaşadığımız zamanlarda 5.000+ seviyesine atlayabilir. Bu sayacı okuduğum zamanın çoğu zaman 0 olmalı, ama bizimki çoğu zaman 300-1100 arasında bir yerde kalıyor gibi görünüyor. Sayaç yalnızca sistemde çok az kullanıcı olduğunda 0'a gider.

Bir saman yığınında iğne aramak zorunda kalmadan tempdb'de DDL çekişmesine neden olan şeyi nasıl daraltabilirim?

Ben bu sorunu gördüm ve sonuçta düzeltmek için yayımlanan düzeltme aslında Microsoft CSS ile benim durumumun doğrudan bir sonucuydu. Düzeltme için genel bir KB makalesi yoktur. Lütfen SQL Server'a Service Pack 4'ü ve en son toplu güncelleştirmeyi uyguladığınızdan emin olun (yazma sırasında bu Toplu Güncelleştirme # 3 (9.00.5259) ).

Düzeltme yayımlanıncaya kadar, Microsoft'un önerisi #temp tablolarını ( KB # 916086 gibi ) oluşturmayı durdurmaktı . Bu düzinelerce ve düzinelerce raporlama prosedürünün önemli ölçüde yeniden yazılması anlamına geleceğinden, benim durumumdaki geçici çözüm (izleme bayrakları veya geçici dosya düzeninden bağımsız olarak) kümemizi her iki hafta sonu yeniden başlatmaktı. Yuck.

Tempdb kullanımını izlemek için etrafında yardımcı olabilecek birkaç komut dosyası vardır, örneğin Adam Machanic'in sp_whoIsActive özelliğine bakın :

• sp_whoisactive: Tempdb İçeriğini Analiz Etme
• Hangi sorgunun tempdb işlem günlüğünü doldurduğunu nasıl belirleyebilirim?

Ve ayrıca @SQLSoldier'dan bu komut dosyası (ve yorumlardakiler):

• TempDB İçeriğinin Dağılımı

Tüm imleçlerinizin kullanıldığından emin olurum LOCAL STATIC READ_ONLY FORWARD_ONLY( buna ve buna bakın ) ve #temp tablolarını / @table değişkenlerini, CTE'leri kapsamlı şekilde kullanan veya gereksiz türler içerebilecek veya karma birleşimlere yol açabilecek bilinen herhangi bir pahalı sorgu olup olmadığını görün ... hepsi soruna katkıda bulunabilir (altın bir neden bulacağınızdan şüpheliyim). "Paranızın karşılığını verme" başlangıç ​​noktası olarak en kolay süpürme düzeltmesi, varsayılanlar yerine uygun ve ucuz imleç seçeneklerini kullanmak olacaktır.

Bu arada (a) CU # 3'ü yükler ve (b) PSS'yi çağırırdım. Onlara zaten bir hata olarak onaylanmış ve özel bir düzeltme olarak diğer kullanıcılara yayımlanmış çok özel bir düzeltmenin ardından olduğunuzu söyleyin: "VSTS # 109112 - Geçici tablo ertelenmiş düşüş belirli iş yükleri için ölçeklenmiyor." Başlangıçta dava ücretini ödemek zorunda kalabilirsiniz, ancak bir hata olduğu için ücretin geri ödenmesi gerekir.

Muhtemelen izleme bayrağı 1118'e ihtiyacınız var

Bkz tempdb hakkında Paul Randal'ın mitleri ilk ve onun çok TF 1118 makalesine

TF burada KB 328551'de açıklanmaktadır.

Bununla ilgili doğrudan bir deneyimim yok ama okuduğum gibi görünüyor

Çekişmeyi hafifletmeye çalışmak için TempDB veri dosyalarınızı zaten böldüğünüzü varsayalım (açıkça üretim öncesi yoluyla). Eğer cesursanız, Paul Randal'ın yetkili olarak başvurduğu izleme bayrağını düşünün: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb-zaman-olmalı-on-veri dosyası başına işlemci core.aspx

Acıya neden olan şey açısından, bazı araştırma çalışmaları yapmanız gerekir:

• bu daha yeni başladı mı? Ne değişti?
• bellek baskı altında mı, bu yüzden TempDB içinde yapılması gerekir?
• CheckDB veya çevrimiçi yeniden dizin oluşturma gibi DBA işlemleri çalışıyor mu?
• daha egzotik izolasyon seviyeleri mi yoksa servis komisyoncusu mu? sys.databases'a bir göz atın

Bu Microsoft TempDB belgesinin altında tempdb kullanan şeyi bulmaya çalışmak için güzel bir sorgu var: http://technet.microsoft.com/en-gb/library/cc966545.aspx

Bunu hala takip etmek istiyorsanız, yakın zamanda senkronize tablo düşüşleriyle benzer şekilde garip bir performans sorunum vardı. SQL 2005 çalıştıran bir sql örneği üzerinde çok sayıda veritabanınız (> 100 kadar) varsa ve geçici tablo oluşturma ve bırakma deyimleriniz varsa, yavaş geçici tablo damlaları alabilirsiniz. Sys.dm_db_index_usage_stats tarafından döndürülen satır sayısını kontrol etmek, suçlu olarak bunu hemen dışlayabilir.

KB makalesi sorunu açıklar. http://support.microsoft.com/kb/2003031

Sys.dm_db_index_usage_stats çok sayıda satıra sahip olduğunda sorgu performansı düşer

Aşağıdaki senaryoyu düşünün:

Microsoft SQL Server 2005'te, genellikle çok sayıda tablonun (özellikle tempdb veritabanındaki geçici tabloların) bırakılmasını ve yeniden oluşturulmasını içeren DDL işlemi gerçekleştirirsiniz. Sys.dm_db_index_usage_stats dinamik yönetim görünümünde (DMV) çok sayıda girişiniz (100.000 veya daha fazla) var.

Bu soruya kabul edilen yanıtımdan alındı. Orada daha fazla ayrıntı var. SQL 2005'te yavaş temp tablosu düşer