ve UAT sunucularındaki yürütme planlarındaki fark

Neden aynı sorgunun UAT (3 sn'de çalışır) vs PROD (23 sn'de çalışır) çalıştırılmasında bu kadar büyük bir fark olacağını bilmek istiyorum.

Hem UAT hem de PROD, tam olarak veri ve dizinlere sahiptir.

SORGU:

set statistics io on;
set statistics time on;

SELECT CONF_NO,
       'DE',
       'Duplicate Email Address ''' + RTRIM(EMAIL_ADDRESS) + ''' in Maintenance',
       CONF_TARGET_NO
FROM   CONF_TARGET ct
WHERE  CONF_NO = 161
       AND LEFT(INTERNET_USER_ID, 6) != 'ICONF-'
       AND ( ( REGISTRATION_TYPE = 'I'
               AND (SELECT COUNT(1)
                    FROM   PORTFOLIO
                    WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS
                           AND DEACTIVATED_YN = 'N') > 1 )
              OR ( REGISTRATION_TYPE = 'K'
                   AND (SELECT COUNT(1)
                        FROM   CAPITAL_MARKET
                        WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS
                               AND DEACTIVATED_YN = 'N') > 1 ) ) 

UAT'TA:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 11 ms, elapsed time = 11 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(3 row(s) affected)
Table 'Worktable'. Scan count 256, logical reads 1304616, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'PORTFOLIO'. Scan count 1, logical reads 84761, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CAPITAL_MARKET'. Scan count 256, logical reads 9472, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CONF_TARGET'. Scan count 1, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 2418 ms,  elapsed time = 2442 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

PROD üzerinde:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(3 row(s) affected)
Table 'PORTFOLIO'. Scan count 256, logical reads 21698816, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CAPITAL_MARKET'. Scan count 256, logical reads 9472, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CONF_TARGET'. Scan count 1, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 23937 ms,  elapsed time = 23935 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

PROD'de, sorgunun eksik bir dizin önerdiğini ve test ettiğimde faydalı olduğunu, ancak tartışma konusu olmadığını unutmayın.

Sadece şunu anlamak istiyorum: UAT ÜZERİNE - neden sql sunucusu bir işçi tablosu yaratıyor ve PROD'da bunu yapmıyor? PROD üzerinde değil, UAT üzerinde bir masa biriktirme oluşturur. Ayrıca, yürütme zamanları UAT'e karşı PROD'ta neden bu kadar farklı?

Not :

Her iki sunucuda da sql server 2008 R2 RTM kullanıyorum (çok yakında en yeni SP ile çalışacağım).

UAT: Maksimum bellek 8GB. MaxDop, işlemci benzeşimi ve maksimum işçi iş parçacığı 0'dır.

Logical to Physical Processor Map:
*-------  Physical Processor 0
-*------  Physical Processor 1
--*-----  Physical Processor 2
---*----  Physical Processor 3
----*---  Physical Processor 4
-----*--  Physical Processor 5
------*-  Physical Processor 6
-------*  Physical Processor 7

Logical Processor to Socket Map:
****----  Socket 0
----****  Socket 1

Logical Processor to NUMA Node Map:
********  NUMA Node 0

PROD: maksimum bellek 60GB. MaxDop, işlemci benzeşimi ve maksimum işçi iş parçacığı 0'dır.

Logical to Physical Processor Map:
**--------------  Physical Processor 0 (Hyperthreaded)
--**------------  Physical Processor 1 (Hyperthreaded)
----**----------  Physical Processor 2 (Hyperthreaded)
------**--------  Physical Processor 3 (Hyperthreaded)
--------**------  Physical Processor 4 (Hyperthreaded)
----------**----  Physical Processor 5 (Hyperthreaded)
------------**--  Physical Processor 6 (Hyperthreaded)
--------------**  Physical Processor 7 (Hyperthreaded)

Logical Processor to Socket Map:
********--------  Socket 0
--------********  Socket 1

Logical Processor to NUMA Node Map:
********--------  NUMA Node 0
--------********  NUMA Node 1

GÜNCELLEME :

UAT Yürütme Planı XML:

http://pastebin.com/z0PWvw8m

PROD Yürütme Planı XML:

http://pastebin.com/GWTY16YY

UAT Yürütme Planı XML - PROD için oluşturulan Plan ile:

http://pastebin.com/74u3Ntr0

Sunucu Yapılandırması:

PROD: PowerEdge R720xd - Intel (R) Xeon (R) İşlemci E5-2637 v2 @ 3.50GHz.

UAT: PowerEdge 2950 - Intel (R) Xeon (R) İşlemci X5460 @ 3.16GHz

Answers.sqlperformance.com de gönderdim

GÜNCELLEME :

@Swasheck öneri için teşekkürler

PROD'deki maksimum belleği 60 GB'den 7680 MB'a değiştirerek, PROD'de aynı planı oluşturabiliyorum. Sorgu, UAT ile aynı anda tamamlanır.

Şimdi anlamam gerekiyor - NEDEN? Ayrıca, bu sayede eski sunucunun yerine bu canavar sunucuyu haklı çıkaramayacağım!

Tampon havuzunun potansiyel büyüklüğü, sorgu iyileştirici tarafından plan seçimini çeşitli şekillerde etkiler. Gibi bildiğim kadarıyla, hiper iş parçacığı yok değil planı seçimini etkileyen (kesinlikle potansiyel mevcut programlayıcıları sayısı can rağmen).

Çalışma alanı belleği

Türler ve karmalar gibi bellek tüketen yineleyiciler içeren planlar için, arabellek havuzunun boyutu (diğer şeylerin yanı sıra) çalışma zamanında sorgu için kullanılabilecek maksimum bellek izni miktarını belirler.

SQL Server 2012'de (tüm sürümler) bu numara Optimizer Hardware Dependencies, gösterilen şekilde bir sorgu planının kök düğümünde rapor edilir Estimated Available Memory Grant. 2012'den önceki sürümler bu numarayı gösteri planında bildirmemektedir.

Tahmini mevcut bellek tahsisi, sorgu iyileştirici tarafından kullanılan maliyet modeline bir girdidir. Sonuç olarak, büyük bir sıralama veya karma işlemi gerektiren bir plan alternatifinin, büyük bir tampon havuzu ayarına sahip bir makinede düşük ayarlı bir makineye göre seçilmesi daha olasıdır. Çok büyük miktarda belleğe sahip kurulumlarda , maliyet modeli bu tür bir düşünce ile çok ileri gidebilir - alternatif bir stratejinin tercih edilebileceği çok büyük türlerde veya karma değerlerde planlar seçmek ( KB2413549 - Büyük miktarda bellek kullanmak, SQL Server'daki verimsiz plan - TF2335 ).

Çalışma alanı belleği desteği, sizin durumunuzda bir faktör değil, ancak bilinmeye değer bir şey.

Veri erişimi

Tampon havuzunun potansiyel büyüklüğü ayrıca veri erişimi için optimizer maliyet modelini de etkiler. Modelde yapılan varsayımlardan biri, her sorgunun soğuk bir önbellekle başladığıdır - bu nedenle, bir sayfaya ilk erişimin fiziksel bir G / Ç'ye yol açtığı varsayılır. Model, tekrarlanan erişimin, diğer şeylerin yanı sıra tampon havuzunun potansiyel büyüklüğüne bağlı bir faktör olan önbellekten gelme ihtimalini hesaba katmaya çalışır.

Kümelenmiş Endeks Soruda gösterilen sorgu planlarındaki taramalar tekrarlanan erişimin bir örneğidir; taramalar, iç içe geçmiş döngülerin yarı birleşiminin her bir yinelemesi için geri sarılır (tekrarlanan, ilişkili bir parametre değişikliği olmadan). Yarı birleştirmeye dış girdi 28.7874 satır tahmin eder ve bu taramalar için sorgu planı özellikleri, sonuç olarak 27.7874'te tahmini geri dönüşleri gösterir.

Yine, SQL Server 2012'de sadece, planın kök yineleyici sayısını gösteren Estimated Pages Cachediçinde Optimizer Hardware Dependenciesbölüm. Bu sayı, önbellekten gelen tekrarlanan sayfa erişim şansını hesaba katan maliyet algoritmasına girdilerden birini bildirir.

Bunun etkisi, daha yüksek yapılandırılmış maksimum tampon havuzu boyutuna sahip bir kurulumun, aynı sayfaları daha küçük bir maksimum tampon havuzu boyutuna sahip bir kurulumdan bir kereden fazla okuyan taramaların (veya aramaların) maliyetini azaltma eğiliminde olmasıdır.

Basit planlarda, geri dönüş taramasındaki maliyet azalması (estimated number of executions) * (estimated CPU + estimated I/O), tahmini operatör maliyetiyle karşılaştırıldığında daha düşük olacaktır. Hesaplama, yarı birleşme ve birliğin etkisinden dolayı örnek planlarda daha karmaşıktır.

Bununla birlikte, söz konusu planlar taramaları tekrarlamak ve geçici bir indeks oluşturmak arasındaki seçimin oldukça iyi dengelendiği bir durumu göstermektedir. Daha büyük tampon havuzuna sahip makinelerde, taramaların tekrarlanması, dizinin oluşturulmasından biraz daha düşük maliyetlidir. Tampon havuzu daha küçük olan makinede, tarama maliyeti daha az miktarda azalır, bu da dizin biriktirme planının optimize ediciye biraz daha ucuz görünmesini sağlar.

Seçimleri Planla

Optimize Edici'nin maliyet modeli çok sayıda varsayımda bulunur ve çok sayıda ayrıntılı hesaplama içerir. Tüm detayları takip etmek her zaman (hatta genellikle) mümkün değildir, çünkü ihtiyacımız olan sayıların tümü ortaya çıkmaz ve algoritmalar sürümler arasında değişebilir. Özellikle, önbelleğe alınmış bir sayfa ile karşılaşılma şansını hesaba katmak için uygulanan ölçeklendirme formülü iyi bilinmemektedir.

Bu özel durumdaki noktaya göre, optimizer'ın plan seçenekleri yine de yanlış rakamlara dayanmaktadır. Kümelenmiş Endeks Aramaya ait tahmini satır sayısı 28.7874'tür, çalışma zamanında ise 256 satıra rastlanır - neredeyse bir büyüklük sırası. İyileştiricinin bu 28.7874 satırlardaki beklenen değer dağılımı hakkında doğrudan bilgileri göremiyoruz, ancak aynı zamanda çok da yanlış olması çok muhtemel.

Tahminler bu kadar yanlış olduğunda, plan seçimi ve çalışma zamanı performansı aslında şanstan daha iyi değildir. Endeks makara ile Plan olur tarama tekrarlayarak daha yüksek bir performans, ancak tampon havuzu boyutunu artırarak anomali nedeni olduğunu düşünmek oldukça yanlıştır.

İyileştiricinin doğru bilgiye sahip olduğu yerlerde, makul bir uygulama planı üretme olasılığı daha yüksektir. Daha fazla belleğe sahip bir örnek genellikle iş yükünde daha az belleğe sahip başka bir örneğe göre daha iyi performans gösterir, ancak özellikle plan seçimi yanlış verilere dayandığında hiçbir garanti yoktur.

Her iki durumda da kendi yollarında eksik bir dizin önerildi. Biri açık bir eksik indeks bildirdi, diğeri ise aynı özelliklere sahip bir indeks makarası kullandı. Endeks iyi performans sağlar ve plan istikrarı sağlarsa, bu yeterli olabilir. Benim eğilimim, sorguyu da yeniden yazmak olacak, ama bu muhtemelen başka bir hikaye.

Paul White , daha fazla belleğe sahip sunucularda çalışırken sql server davranışının nedenini çok net bir şekilde açıkladı.

Ayrıca, ilk konuyu belirlediğiniz için @swasheck'e teşekkür ederiz .

Microsoft ve aşağıda bir dava açıldı önerildi.

Sorun T2335 izleme bayrağını başlangıç ​​parametresi olarak kullanarak çözülür.

KB2413549 - SQL Server içinde büyük miktarda bellek kullanarak verimsiz planı neden olabilir daha detaylı olarak nitelendiriyor.

Bu izleme bayrağı, SQL Server'ın sorguyu yürütürken bellek tüketimi açısından daha tutucu bir plan oluşturmasına neden olur. SQL Server'ın kullanabileceği bellek miktarını sınırlamaz. SQL Server için yapılandırılan bellek hala veri önbelleği, sorgu yürütme ve diğer tüketiciler tarafından kullanılacaktır. Lütfen bu seçeneği üretim ortamına almadan önce iyice test ettiğinizden emin olun.

Maksimum bellek ayarları ve hyperthreading, plan seçimini etkileyebilir.

Ayrıca, "ortam" seçenekleriniz her ortamda farklı:

UAT ile ilgili StatementSetOptions:

ANSI_NULLS="true" 
ANSI_PADDING="true" 
ANSI_WARNINGS="true" 
ARITHABORT="true" 
CONCAT_NULL_YIELDS_NULL="true" 
NUMERIC_ROUNDABORT="false" 
QUOTED_IDENTIFIER="true" 

Prod'daki StatementSetOptions:

ANSI_NULLS="true" 
ANSI_PADDING="true" 
ANSI_WARNINGS="true" 
ARITHABORT="false" 
CONCAT_NULL_YIELDS_NULL="true"
NUMERIC_ROUNDABORT="false"
QUOTED_IDENTIFIER="true" 

SQL, SET seçeneklerine göre farklı planlar oluşturabilir. Bu, planı farklı SSMS oturumlarından veya uygulamadan farklı uygulamalardan alıyorsanız ortaya çıkar.

Geliştiricilerin tutarlı bağlantı dizeleri kullandıklarından emin olun.