Özdeş (?) SQL Server 2005 makineleri; sorgu biri 2sn, diğeri 15dk alır

Çevre:

SQL Server 2005 çalıştıran iki adet 32-bit Windows Server 2003 R2 makinemiz var. Donanım yapılandırmaları Xeon 5160 CPU, 4GB RAM ve 13GB RAID0 ile aynı sunuculardır. AWE ve / 3GB bayrakları etkin değil.

Sunucular, önceden tanımlanmış bir yükleme denetim listesi kullanılarak yan yana kuruldu ve TÜM yüklü yazılımlar her iki makinede de aynı.

Kontrol etmek için bildiğimiz her SQL sunucusu kurulum ayarı ve yama seviyesi aynıdır. Bir fark, TEMPDB'nin hızlı makinede 400MB ve yavaş makinede 1.2GB olmasıdır. Ancak, her iki durumda da herhangi bir TEMPDB tahsisi gerçekleşmediğini görmüyoruz.

Sorun:

Birinde 2 saniye, diğerinde 15 dakika süren saklı bir prosedür vardır. Ek 15 dakika boyunca, disk etkinliği çok azdır veya hiç yoktur, bellek kullanımı değişmez, ancak bir CPU çekirdeği tüm zaman boyunca% 100 sabitlenir.

Bu davranış, veritabanları birinden yedeklendiğinde ve diğerine geri yüklendiğinde bile devam eder.

Saklı bir yordam olduğundan, etkinlik izleyicisi ve profil oluşturucu , saklı yordamda bu yüksek CPU etkinliğinin nerede gerçekleştiği hakkında bize hiçbir ayrıntı göstermez .

Soru:

Başka nelere bakmalıyız?

Takip et:

Yavaşlık, aşağıdaki imleç tanımı için FETCH NEXT deyimlerinde oluşur:

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE X NOT IN (SELECT X FROM dbo.B)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y
...

FETCH deyimlerinin her biri - yalnızca yaklaşık 1000 satır içeren bir tabloda - yaklaşık 7.25 dakika gerektirir. (Hayır, neden üst üste iki yaptığını bilmiyorum, geliştiricilere sormanız gerekiyor, ancak her iki sunucuda da doğru çalışıyor).

Sanal Okumalar gerçekten yüksek gibi gözüktüğü için, "DEĞİLDE (SEÇ ...)" konusunda biraz şüpheliyim.

Bekler ve Kuyruklar gibi bir performans sorun giderme yöntemi kullanmak , yüksek CPU tüketiminin nedenini belirler, bu nedenle darboğaz tanımlandıktan sonra uygun eylem önerilebilir.

SQL Server, diğer kutuda farklı bir plan seçiyor.

Geri yükleme genellikle istatistikleri temel alan sorunları kaldırır, bu yüzden sunucu farklılıklarına bakarım.

Önce bazı kaba kontroller. Varsaymayın: kontrol edin

• SQL Server ayarlarının sys.configuration'da aynı olup olmadığını kontrol edin, örn. Maks. Derece veya paralellik
• Çalışma zamanında herhangi bir ANSI ayarının farklı olup olmadığını görmek için DBCC USEROPTIONS komutunu çalıştırın (ANS ayarları seçilen planı etkileyebilir)
• Herhangi bir sorun olup olmadığını görmek için Windows ve SQL Server günlüklerini kontrol edin

Sonra Remus'un cevabına göre derin uca atlayın.

Tüm diğer şeyler eşitse, her sunucuda farklı bir yürütme planı oluşturuluyor olabilir (@ gbn'nin cevabına göre). Akademik bir alıştırma olarak, her iki planı da görmek ilginç olacaktır, bu yüzden onları her sunucudaki plan önbelleğinden alın ve mümkünse sorunuza ekleyin. Daha sonra performansta bu kadar büyük bir değişikliğe neden olan planlardaki farklılıkları belirleyebiliriz.

Hızlı bir düzeltme için KULLANIM PLANI ipucuna bir göz atın . Bu, iyi planın hızlı sunucudan yavaş sunucuda saklı yordama eklenmesini mümkün kılar.

Düzenleme: Güncelleme sonrasında yeniden: imleç

Diğer cevaplarda bahsedilen görmüyorum denemek için sorgunuzda bir başka varyasyon:

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE NOT EXISTS (SELECT 1 FROM dbo.B WHERE dbo.B.X = dbo.A.X)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y

Beni mizah edin ve değiştirmeyi deneyin:

DECLARE C CURSOR FOR
SELECT X, Y
FROM dbo.A
WHERE X NOT IN (SELECT X FROM dbo.B)
AND Z <=0

Bununla:

DECLARE C CURSOR FOR
SELECT 
    X, 
    Y
FROM dbo.A

    LEFT OUTER JOIN dbo.B
        ON dbo.A.X = dbo.b.X

WHERE dbo.B.X IS NULL
AND Z <=0

Bu kendini kodunuzun FETCH NEXT FROM bölümünde bir performans sorunu olarak göstermesi gerektiğini düşünmüyorum, ancak henüz kafein enjeksiyonum olmadı. Önerimi bir deneyin ve bana bildirin.

Bu yardımcı olur umarım,

Mat

Dizinlerinizi kontrol edin ve tüm istatistiklerinizi güncelleyin. Çok similerle ilgili bir sorun yaşadım ve bir makinedeki istatistiklerin sakat olduğu ortaya çıktı.

Aynı davranışı iki kez yaşadım ve size her seferinde neyin düzeltildiğini söyleyeceğim:

1.) Önbelleğe alınan plan korkunç olduğundan saklı yordamla RECOMPILE İLE ipucu ekledim.

2.) Saklı yordamı tablo değişkenleri yerine geçici tablolar kullanmak için değiştirdim.

Umarım bu yardımlardan herhangi biri. İyi şanslar.