TempDB yayınları

SQL Server 2014 SP1'de etkin bir OLTP 40GB veritabanımız var. IO_Completion beklemeleri, Disk Kuyruk Uzunluğu 900'e yükseldiğinde ve SQL Server yanıt vermeyi durdurduğunda sorgular yavaş bulunur. Ne denedik:

1. Örneği yeniden başlatın ve bir dakika içinde aynı şekilde davranmaya başlar.

2. İkinci yeniden başlatmadan sonra, her tempdb veri dosyasının başlangıç ​​boyutunu değiştirdik (16 veri dosyası oluşturuldu) ve düzgün çalışmaya başlıyor.

Not: Ara sonuç kümeleri için tablo değişkenleri kullanıyoruz. Bu sonuç kümeleri çok küçüktür.

Ayda iki kez oldu. Veri dosyalarına manuel olarak biraz yer eklediğimde normal çalışmaya başlıyor. Daha ilginç olan şey, SQL Server 2008 R2 ve SQL Server 2012'de sahip olduğumuz aynı kurulumun (aynı donanım, aynı klasör ve dosya kurulumu, aynı iş yükü) iyi çalışmasıdır.

Kalıcı bir çözüm bulmamıza yardımcı olun.

Tüm veri dosyalarının başlangıç ​​boyutu aynı 1000MB, Geçerli her biri 1500MB'dir. Hepsi aynı. Otomatik büyüme her biri için 100 MB'dir. Bundan önce PFS ve GAM sayfalarının çekişmesiyle karşı karşıya kaldık ve 16'ya çıktık ve sorun çözüldü. Her iki izleme bayrağı (1117 ve 1118) etkinleştirilir. 2 NUMA düğümünde 24 çekirdek. Tüm veri dosyaları aynı birimdedir. Basit disk, SAN yok.

Eşgörünüm fiziksel bir makinede. Tablo Değişkenleri ile sorgular ve Karma Birleşimler ile sorgular en yaygın olarak IO_Completion beklemeleri oluşturur.

WBob'un ayrıntılı cevabı bizi daha ayrıntılı arama yapmaya itti. Daha önce nasıl kaçırdık:

'Tempdb' veritabanındaki 'templog' dosyasının otomatik büyümesi kullanıcı tarafından iptal edildi veya 7704 milisaniyeden sonra zaman aşımına uğradı. Bu dosya için daha küçük bir FILEGROWTH değeri ayarlamak veya açıkça yeni bir dosya boyutu ayarlamak için ALTER DATABASE kullanın.

Bu, bu tür bir sorun ortaya çıktığında günlükte bulduk. Hızlı sürücüyü ayırmak için TempDB'yi hareket ettiriyoruz.

Sanırım tempdb'nizi aşırı parçaladınız ve sunucu CPU ile disk kurulumu arasında bir uyumsuzluk var, ancak biraz daha bilgi toplayalım:

Sorular / Ek bilgi gerekli

• Lütfen işlemci adını ve türünü onaylayın (Temel olarak HT ile 2 x altı çekirdekli olup olmadığını belirlemeye çalışıyorum). Onaylamak için Sistem bilgilerini (örn. Denetim Masası> Sistem ve Güvenlik> Windows Server 2012 R2'deki Sistem) ve / veya sistem içi aracı CoreInfo kullanın.
• Lütfen sunucu maxdop'unu onaylayın (örn. EXEC sp_configure 'max degree of parallelism'). CPU'lar altı çekirdekli ise, sunucu maxdop'u en fazla 6 ( burada olduğu gibi ) veya bir OLTP sisteminde muhtemelen daha düşük olmalıdır. Normalde tempdb dosyalarımı sunucumun DOP'u ile maksimum 8'e kadar tutarım, ancak buna geleceğiz.
• Lütfen kutudaki sunucu toplam belleğini ve SQL Server bellek kapağını (örn. EXEC sp_configure 'max server memory (MB)') Onaylayın .
• Lütfen kutuda başka hizmetlerin çalışıp çalışmadığını onaylayın (örn. SSIS, SSAS, SSRS, uygulama, iTunes vb.)
• Lütfen SQL Server hizmet hesabı için Anında Dosya Başlatma'nın etkin olduğunu doğrulayın. ( Burada test etmenin yolları ).
• Neden bir disk (ev bilgisayarı) ile CPU arasında (büyük 2 düğüm NUMA kurulumu) büyük bir tutarsızlık var? Tempdb için disk, şeritleme, SSD eklemeyi düşünün ( aşırı tepki vermekten kaçının:) .
• Lütfen sorun sorgularından biri için gerçek bir yürütme planı ekleyin. İsterseniz SQL Sentry Plan Explorer ile anonim olun.

• Bir OLTP sisteminde tablo değişkenleri ile karma birleşir mi? Bu, tablo değişkeni, ana tablo veya her ikisinde dizin oluşturma eksikliğini gösterir. Tablo değişkenlerinizi böyle (dizinsiz) bildiriyor musunuz?

  DECLARE @t TABLE ( x INT )

• Küçük sonuç kümeleri tutmasına rağmen tablo değişkeni tanımını gözden kaçırmayın. Optimize ediciye olabildiğince fazla bilgi vermek her zaman en iyisidir; bu nedenle, dizinin kümelenmiş / kümelenmemiş olsun, örn.

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• Yürütme planını yayınlamak, bunu teşhis etmeye yardımcı olacaktır.

• Tablo değişkeninin önbelleğe alınmasını engelleyen kodu burada , burada belirtin . Dinamik SQL ve RECOMPILE İLE yürütülen proc tablo değişkenlerini etkileyen sadece bence.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• IO uyarıları gibi SQL Server Günlüğü'nü (Nesne Gezgini> Yönetim> SQL Server Günlükleri) kontrol edin.

• Windows Olay Görüntüleyicisi'ni denetleme
• SP1'den bu yana bir dizi derleme yayınlandı. SP1'den beri eklenen CU düzeltmelerini gözden geçirin . SP1'de sonraki CU'larda düzeltilen hatalar olabilir, örn. FIX: Tahmini satır sayısı ve satır boyutu doğru olduğunda operatör döküntülerini SQL Server 2012 veya SQL Server 2014'te tempdb'ye göre sıralayın https://support.microsoft.com/en- tr / kb / 3088480
• Herhangi bir düzeltmeyi uygulamadan önce bunun nedenini belirleyin, ancak yeni özelliklerin (bellek içi OLTP, kümelenmiş sütun deposu) nedeniyle SQL Server 2014 ile CU'larla güncel kalmak daha önemlidir.
• Son olarak, çekirdek başına bir tempdb dosyasına ihtiyaç bir efsanedir ve disk kurulumunuza baktığımda tahminim tempdb aşırı parçalanmıştır. Bir disk kafasına sahip bir nagging hissi var, tempdb bir dosya grubu, birçok dosya var.

Ancak bildiğimizi düşündüğümüzü unutun; sorununuzu yeniden üreten bir test platformu oluşturun ve geçici dosya sayısını azaltmayı deneyin ... kanıta dayalı bir karar vermek için 1, 2, 4, 6 vb. Sorununuz aralıklı göründüğü için şimdi bu biraz daha zor ve tempdb kurulumunuzla uğraşamayabilirsiniz, ama ben bu şekilde yaklaşacağım.

İyi şanslar. Nasıl geçtiğinizi bize bildirin.