İki sunucu arasındaki önemli performans farkını gösteren sorgu sorunlarını giderme

Şunlar için geçerlidir: SQL Server

Bu makalede, bir sorgu bir sunucuda başka bir sunucuya göre daha yavaş çalıştığı bir performans sorunu için sorun giderme adımları sağlanır.

Belirtiler

SQL Server yüklü iki sunucu olduğunu varsayalım. SQL Server örneklerden biri, diğer SQL Server örnekteki bir veritabanının kopyasını içerir. Her iki sunucudaki veritabanlarında bir sorgu çalıştırdığınızda, sorgu bir sunucuda diğerinden daha yavaş çalışır.

Aşağıdaki adımlar bu sorunu gidermeye yardımcı olabilir.

1. Adım: Birden çok sorguda sık karşılaşılan bir sorun olup olmadığını belirleme

İki sunucudaki iki veya daha fazla sorgunun performansını karşılaştırmak için aşağıdaki iki yöntemden birini kullanın:

• Sorguları her iki sunucuda da el ile test edin:

  1. Aşağıdaki sorgulara öncelik veren test için çeşitli sorgular seçin:
     • Bir sunucuda diğer sunucuya göre önemli ölçüde daha hızlı.
     • Kullanıcı/uygulama için önemlidir.
     • Sık sık yürütülür veya isteğe bağlı olarak sorunu yeniden oluşturmak için tasarlanmıştır.
     • Üzerinde veri yakalamak için yeterince uzun (örneğin, 5 milisaniyelik sorgu yerine 10 saniyelik bir sorgu seçin).
  2. sorguları iki sunucuda çalıştırın.
  3. Her sorgu için iki sunucuda geçen süreyi (süre) karşılaştırın.

• SQL Nexus ile performans verilerini analiz edin.

  1. İki sunucudaki sorgular için PSSDiag/SQLdiag veya SQL LogScout verilerini toplayın.
  2. Toplanan veri dosyalarını SQL Nexus ile içeri aktarın ve iki sunucudan gelen sorguları karşılaştırın. Daha fazla bilgi için bkz. İki günlük koleksiyonu arasında Performans Karşılaştırması (örneğin Yavaş ve Hızlı)..

Senaryo 1: İki sunucuda tek bir sorgu farklı performans gösterir

Yalnızca bir sorgu farklı bir performans sergiliyorsa, sorun büyük olasılıkla ortama değil tek tek sorguya özgüdür. Bu durumda 2. Adım: Veri toplama'ya gidin ve performans sorununun türünü belirleyin.

Senaryo 2: İki sunucuda birden çok sorgu farklı performans gösterir

Bir sunucuda birden çok sorgu diğerinden daha yavaş çalışıyorsa, bunun en olası nedeni sunucu veya veri ortamındaki farklılıklardır. Ortam farklarını tanılama bölümüne gidin ve iki sunucu arasındaki karşılaştırmanın geçerli olup olmadığını denetleyin.

2. Adım: Veri toplama ve performans sorununun türünü belirleme

Geçen süreyi, CPU süresini ve Mantıksal Okumaları toplama

Her iki sunucuda da sorgunun geçen süresini ve CPU süresini toplamak için, durumunuzla en uygun aşağıdaki yöntemlerden birini kullanın:

• Şu anda yürütülen deyimler için sys.dm_exec_requests total_elapsed_time ve cpu_time sütunlarını denetleyin. Verileri almak için aşağıdaki sorguyu çalıştırın:

  SELECT 
      req.session_id
      , req.total_elapsed_time AS duration_ms
      , req.cpu_time AS cpu_time_ms
      , req.total_elapsed_time - req.cpu_time AS wait_time
      , req.logical_reads
      , SUBSTRING (REPLACE (REPLACE (SUBSTRING (ST.text, (req.statement_start_offset/2) + 1, 
         ((CASE statement_end_offset
             WHEN -1
             THEN DATALENGTH(ST.text)  
             ELSE req.statement_end_offset
           END - req.statement_start_offset)/2) + 1) , CHAR(10), ' '), CHAR(13), ' '), 
        1, 512)  AS statement_text  
  FROM sys.dm_exec_requests AS req
      CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) AS ST
  ORDER BY total_elapsed_time DESC;
  

• Sorgunun geçmiş yürütmeleri için sys.dm_exec_query_stats last_elapsed_time ve last_worker_time sütunlarını denetleyin. Verileri almak için aşağıdaki sorguyu çalıştırın:

  SELECT t.text,
       (qs.total_elapsed_time/1000) / qs.execution_count AS avg_elapsed_time,
       (qs.total_worker_time/1000) / qs.execution_count AS avg_cpu_time,
       ((qs.total_elapsed_time/1000) / qs.execution_count ) - ((qs.total_worker_time/1000) / qs.execution_count) AS avg_wait_time,
       qs.total_logical_reads / qs.execution_count AS avg_logical_reads,
       qs.total_logical_writes / qs.execution_count AS avg_writes,
       (qs.total_elapsed_time/1000) AS cumulative_elapsed_time_all_executions
  FROM sys.dm_exec_query_stats qs
       CROSS apply sys.Dm_exec_sql_text (sql_handle) t
  WHERE t.text like '<Your Query>%'
  -- Replace <Your Query> with your query or the beginning part of your query. The special chars like '[','_','%','^' in the query should be escaped.
  ORDER BY (qs.total_elapsed_time / qs.execution_count) DESC
  

  Not

  Negatif bir değer gösteriyorsa avg_wait_time , paralel bir sorgu olur.

• sorguyu SQL Server Management Studio (SSMS) veya Azure Data Studio'da isteğe bağlı olarak yürütebiliyorsanız, BU sorguyu SET STATISTICS TIMEON ve SET STATISTICS GÇON ile çalıştırın.

  SET STATISTICS TIME ON
  SET STATISTICS IO ON
  <YourQuery>
  SET STATISTICS IO OFF
  SET STATISTICS TIME OFF
  

  Ardından İletiler'den CPU süresini, geçen süreyi ve aşağıdaki gibi mantıksal okumaları görürsünüz:

    Table 'tblTest'. Scan count 1, logical reads 3, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
  
    SQL Server Execution Times:
      CPU time = 460 ms,  elapsed time = 470 ms.
  

• Sorgu planı toplayabilirseniz Yürütme planı özelliklerindeki verileri denetleyin.

  1. Sorguyu Fiili Yürütme Planını Ekle açık olarak çalıştırın.

  2. Yürütme planı'ndan en soldaki işleci seçin.

  3. Özellikler'denQueryTimeStats özelliğini genişletin.

  4. ElapsedTime ve CpuTime değerlerini denetleyin.

     

Her iki sunucu için de sorun türünü belirlemek için sorgunun geçen süresini ve CPU saatini karşılaştırın.

Tür 1: CPU'ya bağlı (çalıştırıcı)

CPU süresi geçen süreye yakın, buna eşit veya daha yüksekse, CPU'ya bağlı bir sorgu olarak kabul edebilirsiniz. Örneğin, geçen süre 3000 milisaniye (ms) ise ve CPU süresi 2900 ms ise, geçen sürenin çoğu CPU üzerinde harcanmış demektir. Ardından bunun CPU'ya bağlı bir sorgu olduğunu söyleyebiliriz.

Çalıştırma (CPU'ya bağlı) sorgu örnekleri:

Geçen Süre (ms)	CPU Süresi (ms)	Okumalar (mantıksal)
3200	3000	300000
1080	1000	20

Mantıksal okumalar - önbellekteki veri/dizin sayfalarını okuma - en sık SQL Server CPU kullanımının sürücüleridir. CPU kullanımının diğer kaynaklardan geldiği senaryolar olabilir: bir süre döngüsü (T-SQL'de veya XProcs veya SQL CRL nesneleri gibi diğer kodlarda). Tablodaki ikinci örnek, CPU'nun çoğunluğunun okumalardan olmadığı böyle bir senaryoyu gösterir.

Not

CPU süresi sürenin üzerindeyse, bu paralel sorgunun yürütülür olduğunu gösterir; birden çok iş parçacığı cpu'sunu aynı anda kullanıyor. Daha fazla bilgi için bkz. Paralel sorgular - çalıştırıcı veya garson.

Tür 2: Performans sorunu bekleniyor (garson)

Geçen süre CPU süresinden çok daha uzunsa sorgu bir performans sorununu bekliyor. Geçen süre, sorgunun CPU'da yürütülmesini (CPU süresi) ve kaynağın yayımlanmasını bekleme süresini (bekleme süresi) içerir. Örneğin, geçen süre 2000 ms ve CPU süresi 300 ms ise, bekleme süresi 1700 ms'dir (2000 - 300 = 1700). Daha fazla bilgi için bkz . Bekleme Türleri.

Bekleyen sorgu örnekleri:

Geçen Süre (ms)	CPU Süresi (ms)	Okumalar (mantıksal)
2000	300	28000
10080	700	80000

Paralel sorgular - çalıştırıcı veya garson

Paralel sorgular genel süreye göre daha fazla CPU süresi kullanabilir. Paralelliğin amacı, birden çok iş parçacığının sorgunun bölümlerini aynı anda çalıştırmasına izin vermektir. Saat süresinin bir saniyesinde, bir sorgu sekiz paralel iş parçacığı yürüterek sekiz saniye CPU süresi kullanabilir. Bu nedenle, geçen süre ve CPU süresi farkı temelinde CPU'ya bağlı veya bekleyen bir sorgu belirlemek zorlaşır. Ancak, genel bir kural olarak, yukarıdaki iki bölümde listelenen ilkeleri izleyin. Özet:

• Geçen süre CPU süresinden çok daha uzunsa, bunu bir garson olarak düşünün.
• CPU süresi geçen süreden çok daha uzunsa, bunu bir çalıştırıcı olarak düşünün.

Paralel sorgu örnekleri:

Geçen Süre (ms)	CPU Süresi (ms)	Okumalar (mantıksal)
1200	8100	850000
3080	12300	1500000

3. Adım: Her iki sunucudaki verileri karşılaştırın, senaryoyu öğrenin ve sorunu giderin

Sunucu1 ve Sunucu2 adlı iki makine olduğunu varsayalım. Sorgu Sunucu1'de Sunucu2'den daha yavaş çalışır. Her iki sunucudaki saatleri karşılaştırın ve aşağıdaki bölümlerden sizinkiyle en iyi eşleşen senaryonun eylemlerini izleyin.

Senaryo 1: Sunucu1'de sorgu daha fazla CPU süresi kullanır ve mantıksal okumalar Server1'de Server2'den daha yüksektir

Sunucu1'de CPU süresi Sunucu2'den çok daha uzunsa ve geçen süre her iki sunucuda da CPU süresiyle yakından eşleşiyorsa, önemli beklemeler veya performans sorunları yoktur. Sunucu1'de CPU süresindeki artışa büyük olasılıkla mantıksal okumalardaki artış neden olur. Mantıksal okumalarda yapılan önemli bir değişiklik genellikle sorgu planlarındaki farkı gösterir. Örneğin:

Server	Geçen Süre (ms)	CPU Süresi (ms)	Okumalar (mantıksal)
Sunucu1	3100	3000	300000
Sunucu2	1100	1000	90200

Eylem: Yürütme planlarını ve ortamlarını denetleme

1. Her iki sunucudaki sorgunun yürütme planlarını karşılaştırın. Bunu yapmak için iki yöntemden birini kullanın:
   • Yürütme planlarını görsel olarak karşılaştırın. Daha fazla bilgi için bkz. Gerçek Yürütme Planını Görüntüleme.
   • Yürütme planlarını kaydedin ve SQL Server Management Studio Plan Karşılaştırma özelliğini kullanarak karşılaştırın.
2. Ortamları karşılaştırın. Farklı ortamlar sorgu planı farklılıklarına veya CPU kullanımında doğrudan farklılıklara yol açabilir. Ortamlar arasında sunucu sürümleri, veritabanı veya sunucu yapılandırma ayarları, izleme bayrakları, CPU sayısı veya saat hızı ve Sanal Makine ile Fiziksel Makine karşılaştırması bulunur. Ayrıntılar için bkz. Sorgu planı farklılıklarını tanılama .

Senaryo 2: Sorgu Sunucu1'de bir garsondur ancak Sunucu2'de değildir

Her iki sunucudaki sorgunun CPU süreleri benzerse ancak Server1'de geçen süre Sunucu2'den çok daha uzunsa, Server1'de sorgu bir performans sorunu beklerken çok daha uzun zaman harcar. Örneğin:

Server	Geçen Süre (ms)	CPU Süresi (ms)	Okumalar (mantıksal)
Sunucu1	4500	1000	90200
Sunucu2	1100	1000	90200

• Sunucu1'de bekleme süresi: 4500 - 1000 = 3500 ms
• Sunucu2'de bekleme süresi: 1100 - 1000 = 100 ms

Eylem: Sunucu1'de bekleme türlerini denetleme

Server1'de performans sorununu belirleyin ve ortadan kaldırın. Bekleme örnekleri engelleme (kilit beklemeleri), mandal beklemeleri, disk G/Ç beklemeleri, ağ beklemeleri ve bellek beklemeleridir. Sık karşılaşılan performans sorunlarını gidermek için Beklemeleri veya performans sorunlarını tanılama bölümüne geçin.

Senaryo 3: Her iki sunucudaki sorgular garsondur, ancak bekleme türleri veya süreleri farklıdır

Örneğin:

Server	Geçen Süre (ms)	CPU Süresi (ms)	Okumalar (mantıksal)
Sunucu1	8000	1000	90200
Sunucu2	3000	1000	90200

• Sunucu1'de bekleme süresi: 8000 - 1000 = 7000 ms
• Sunucu2'de bekleme süresi: 3000 - 1000 = 2000 ms

Bu durumda, CPU süreleri her iki sunucuda da benzerdir ve bu da sorgu planlarının büyük olasılıkla aynı olduğunu gösterir. Performans sorunlarını beklemezlerse sorgular her iki sunucuda da eşit performans sergiler. Bu nedenle süre farklılıkları farklı bekleme süresi miktarlarından gelir. Örneğin, sorgu Sunucu2'de G/Ç'de 2000 ms beklerken 7000 ms için Sunucu1'de kilitlerde bekler.

Eylem: Her iki sunucuda da bekleme türlerini denetleyin

Her sunucuda ayrı ayrı bekleyen ve her iki sunucuda da yürütmeleri hızlandıran performans sorunlarını giderin. Her iki sunucudaki performans sorunlarını ortadan kaldırmanız ve performansı karşılaştırılabilir hale getirmeniz gerektiğinden bu sorunun giderilmesi yoğun emek gerektirir. Sık karşılaşılan performans sorunlarını gidermek için Beklemeleri veya performans sorunlarını tanılama bölümüne geçin.

Senaryo 4: Sunucu1'de sorgu, Sunucu2'den daha fazla CPU süresi kullanıyor, ancak mantıksal okumalar yakın

Örneğin:

Server	Geçen Süre (ms)	CPU Süresi (ms)	Okumalar (mantıksal)
Sunucu1	3000	3000	90200
Sunucu2	1000	1000	90200

Veriler aşağıdaki koşullarla eşleşiyorsa:

• Sunucu1'de CPU süresi Sunucu2'den çok daha uzundur.
• Geçen süre, her sunucudaki CPU süresiyle yakından eşleşir ve bu da bekleme olmadığını gösterir.
• Genellikle cpu süresinin en yüksek sürücüsü olan mantıksal okumalar her iki sunucuda da benzerdir.

Ardından ek CPU süresi diğer BAZı CPU'ya bağlı etkinliklerden gelir. Bu senaryo, tüm senaryoların en nadir örneğidir.

Nedenler: İzleme, UDF'ler ve CLR tümleştirmesi

Bu sorunun nedeni şu olabilir:

• XEvents/SQL Server izleme, özellikle metin sütunlarında filtreleme (veritabanı adı, oturum açma adı, sorgu metni vb.) ile. İzleme bir sunucuda etkinse ancak diğer sunucuda etkinleştirilmediyse, farkın nedeni bu olabilir.
• Kullanıcı tanımlı işlevler (UDF'ler) veya CPU'ya bağlı işlemler gerçekleştiren diğer T-SQL kodu. Bu durum genellikle Sunucu1 ve Sunucu2'de veri boyutu, CPU saat hızı veya Güç planı gibi diğer koşulların farklı olması durumunda neden olabilir.
• CPU'ya yol gösterebilen ancak mantıksal okuma gerçekleştirmeyen CLR tümleştirmesini veya Genişletilmiş Saklı yordamları (XP) SQL Server. DLL'lerdeki farklılıklar farklı CPU sürelerine yol açabilir.
• CPU'ya bağlı SQL Server işlevselliğindeki fark (örneğin, dize işleme kodu).

Eylem: İzlemeleri ve sorguları denetleme

1. Aşağıdakiler için her iki sunucudaki izlemeleri denetleyin:

   1. Sunucu1'de etkinleştirilmiş ancak Sunucu2'de etkinleştirilmemiş izleme varsa.
   2. Herhangi bir izleme etkinleştirilirse izlemeyi devre dışı bırakın ve sorguyu Sunucu1'de yeniden çalıştırın.
   3. Sorgu bu kez daha hızlı çalışıyorsa geri izlemeyi etkinleştirin ancak varsa metin filtrelerini kaldırın.

2. Sorgunun dize işlemeleri veya listedeki veri sütunlarında SELECT kapsamlı işlemeler yapmak için UDF kullanıp kullanmadığını denetleyin.

3. Sorgunun döngüler, işlev özyinelemeleri veya iç içe yerleştirmeler içerip içermediğini denetleyin.

Ortam farklarını tanılama

Aşağıdaki soruları denetleyin ve iki sunucu arasındaki karşılaştırmanın geçerli olup olmadığını belirleyin.

• İki SQL Server örneği aynı sürümde mi yoksa derlemede mi?

  Aksi takdirde, farklılıklara neden olan bazı düzeltmeler olabilir. Her iki sunucuda da sürüm bilgilerini almak için aşağıdaki sorguyu çalıştırın:

  SELECT @@VERSION
  

• Fiziksel bellek miktarı her iki sunucuda da benzer mi?

  Bir sunucuda 64 GB bellek, diğerinde ise 256 GB bellek varsa, bu önemli bir fark olabilir. Veri/dizin sayfalarını ve sorgu planlarını önbelleğe almak için daha fazla bellek kullanılabilirken, sorgu donanım kaynağı kullanılabilirliğine göre farklı şekilde iyileştirilebilir.

• CPU ile ilgili donanım yapılandırmaları her iki sunucuda da benzer mi? Örneğin:

  • CPU sayısı makineler arasında farklılık gösterir (bir makinede 24 CPU, diğerinde 96 CPU).

  • Güç planları— dengeli ve yüksek performans.

  • Sanal Makine (VM) ile fiziksel (çıplak) makine karşılaştırması.

  • Hyper-V ile VMware arasındaki fark; yapılandırma farkı.

  • Saat hızı farkı (daha düşük saat hızı ve daha yüksek saat hızı). Örneğin 2 GHz ile 3,5 GHz arasındaki farklar olabilir. Bir sunucuda saat hızını almak için aşağıdaki PowerShell komutunu çalıştırın:

    Get-CimInstance Win32_Processor | Select-Object -Expand MaxClockSpeed
    

  Sunucuların CPU hızını test etmek için aşağıdaki iki yoldan birini kullanın. Bunlar karşılaştırılabilir sonuçlar vermezse sorun SQL Server dışındadır. Bu bir güç planı farkı, daha az CPU, VM yazılımı sorunu veya saat hızı farkı olabilir.

  • Her iki sunucuda da aşağıdaki PowerShell betiğini çalıştırın ve çıkışları karşılaştırın.

    $bf = [System.DateTime]::Now
    for ($i = 0; $i -le 20000000; $i++) {}
    $af = [System.DateTime]::Now
    Write-Host ($af - $bf).Milliseconds " milliseconds"
    Write-Host ($af - $bf).Seconds " Seconds"
    

  • Her iki sunucuda da aşağıdaki Transact-SQL kodunu çalıştırın ve çıkışları karşılaştırın.

    SET NOCOUNT ON 
    DECLARE @spins INT = 0
    DECLARE @start_time DATETIME = GETDATE(), @time_millisecond INT
    
    WHILE (@spins < 20000000)
    BEGIN
       SET @spins = @spins +1
    END
    
    SELECT @time_millisecond = DATEDIFF(millisecond, @start_time, getdate())
    
    SELECT @spins Spins, @time_millisecond Time_ms,  @spins / @time_millisecond Spins_Per_ms
    

Beklemeleri veya performans sorunlarını tanılama

Performans sorunlarını bekleyen bir sorguyu iyileştirmek için, beklemenin ne kadar sürdüğünü ve performans sorununun nerede olduğunu (bekleme türü) belirleyin. Bekleme türü onaylandıktan sonra bekleme süresini azaltın veya beklemeyi tamamen ortadan kaldırın.

Yaklaşık bekleme süresini hesaplamak için, sorgunun geçen zamanından CPU süresini (çalışan saati) çıkarın. Genellikle CPU süresi gerçek yürütme süresidir ve sorgunun ömrünün kalan bölümü bekler.

Yaklaşık bekleme süresini hesaplama örnekleri:

Geçen Süre (ms)	CPU Süresi (ms)	Bekleme süresi (ms)
3200	3000	200
7080	1000	6080

Performans sorununu belirleme veya bekleme

• Geçmiş uzun süre bekleyen sorguları (örneğin, >geçen sürenin %20'sini bekleme süresi) tanımlamak için aşağıdaki sorguyu çalıştırın. Bu sorgu, SQL Server başlangıcından bu yana önbelleğe alınmış sorgu planları için performans istatistiklerini kullanır.

  SELECT t.text,
           qs.total_elapsed_time / qs.execution_count
           AS avg_elapsed_time,
           qs.total_worker_time / qs.execution_count
           AS avg_cpu_time,
           (qs.total_elapsed_time - qs.total_worker_time) / qs.execution_count
           AS avg_wait_time,
           qs.total_logical_reads / qs.execution_count
           AS avg_logical_reads,
           qs.total_logical_writes / qs.execution_count
           AS avg_writes,
           qs.total_elapsed_time
           AS cumulative_elapsed_time
  FROM sys.dm_exec_query_stats qs
           CROSS apply sys.Dm_exec_sql_text (sql_handle) t
  WHERE (qs.total_elapsed_time - qs.total_worker_time) / qs.total_elapsed_time
           > 0.2
  ORDER BY qs.total_elapsed_time / qs.execution_count DESC
  

• Şu anda 500 ms'den uzun bekleme süreleriyle yürütülen sorguları belirlemek için aşağıdaki sorguyu çalıştırın:

  SELECT r.session_id, r.wait_type, r.wait_time AS wait_time_ms
  FROM sys.dm_exec_requests r 
     JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id 
  WHERE wait_time > 500
  AND is_user_process = 1
  

• Sorgu planı toplayabilirseniz SSMS'deki yürütme planı özelliklerindenWaitStats'ı denetleyin:

  1. Sorguyu Fiili Yürütme Planını Ekle açık olarak çalıştırın.
  2. Yürütme planı sekmesinde en soldaki işleci sağ tıklatın
  3. Özellikler'i ve ardından WaitStats özelliğini seçin.
  4. WaitTimeMs ve WaitType değerlerini denetleyin.

• PSSDiag/SQLdiag veya SQL LogScout LightPerf/GeneralPerf senaryolarını biliyorsanız, performans istatistiklerini toplamak ve SQL Server örneğinizde bekleyen sorguları belirlemek için bunlardan birini kullanmayı göz önünde bulundurun. Toplanan veri dosyalarını içeri aktarabilir ve SQL Nexus ile performans verilerini analiz edebilirsiniz.

Beklemeleri ortadan kaldırmaya veya azaltmaya yardımcı olacak başvurular

Her bekleme türünün nedenleri ve çözümleri farklılık gösterir. Tüm bekleme türlerini çözümlemek için tek bir genel yöntem yoktur. Sık karşılaşılan bekleme türü sorunlarını gidermeye ve çözmeye yönelik makaleler şunlardır:

• Engelleme sorunlarını anlama ve çözme (LCK_M_*)
• Azure SQL Veritabanı engelleme sorunlarını anlama ve çözme
• G/Ç sorunlarının (PAGEIOLATCH_*, WRITELOG, IO_COMPLETION, BACKUPIO) neden olduğu yavaş SQL Server performansı sorunlarını giderme
• SQL Server'da son sayfa ekleme PAGELATCH_EX çekişme sorununu çözme
• Bellek açıklamaları ve çözümleri verir (RESOURCE_SEMAPHORE)
• ASYNC_NETWORK_IO bekleme türünden kaynaklanan yavaş sorgularda sorun giderme
• AlwaysOn Kullanılabilirlik Grupları ile Yüksek HADR_SYNC_COMMIT bekleme türü sorunlarını giderme
• Nasıl Çalışır: CMEMTHREAD ve Hata Ayıklama
• Paralellik beklemelerini eyleme dönüştürülebilir hale getirme (CXPACKET ve CXCONSUMER)
• THREADPOOL bekleme

Birçok Bekleme türünün açıklamaları ve bunların ne gösterdiği için Bekleme Türleri'ndeki tabloya bakın.

Sorgu planı farklılıklarını tanılama

Sorgu planlarındaki farklılıkların bazı yaygın nedenleri şunlardır:

• Veri boyutu veya veri değerleri farklılıkları

  Aynı veritabanı her iki sunucuda da mı kullanılıyor, aynı veritabanı yedeklemesi kullanılıyor mu? Veriler bir sunucuda diğer sunucuyla karşılaştırıldığında değiştirildi mi? Veri farklılıkları farklı sorgu planlarına yol açabilir. Örneğin, tablo T1'i (1000 satır) T2 tablosuyla (2.000.000 satır) birleştirmek, T1 tablosunu (100 satır) tablo T2 (2.000.000 satır) ile birleştirmekten farklıdır. İşlemin JOIN türü ve hızı önemli ölçüde farklı olabilir.

• İstatistik farklılıkları

  İstatistikler diğer veritabanında değil de bir veritabanında güncelleştirildi mi? İstatistikler farklı bir örnek oranıyla güncelleştirildi mi (örneğin, %30 ile %100 tam tarama)? her iki taraftaki istatistikleri aynı örnek hızıyla güncelleştirdiğinizden emin olun.

• Veritabanı uyumluluk düzeyi farklılıkları

  Veritabanlarının uyumluluk düzeylerinin iki sunucu arasında farklı olup olmadığını denetleyin. Veritabanı uyumluluk düzeyini almak için aşağıdaki sorguyu çalıştırın:

  SELECT name, compatibility_level
  FROM sys.databases
  WHERE name = '<YourDatabase>'
  

• Sunucu sürümü/derleme farklılıkları

  SQL Server sürümleri veya derlemeleri iki sunucu arasında farklı mı? Örneğin, bir sunucu SQL Server sürüm 2014 ve diğer SQL Server sürüm 2016 mı? Sorgu planının seçilmesinde değişikliklere yol açabilecek ürün değişiklikleri olabilir. aynı SQL Server sürümünü ve derlemesini karşılaştırdığınızdan emin olun.

  SELECT ServerProperty('ProductVersion')
  

• Kardinalite Tahmin Aracı (CE) sürüm farklılıkları

  Eski kardinalite tahmin aracının veritabanı düzeyinde etkinleştirilip etkinleştirilmediğini denetleyin. CE hakkında daha fazla bilgi için bkz. Kardinalite Tahmini (SQL Server).

  SELECT name, value, is_value_default
  FROM sys.database_scoped_configurations
  WHERE name = 'LEGACY_CARDINALITY_ESTIMATION'
  

• İyileştirici düzeltmeleri etkin/devre dışı

  Sorgu iyileştirici düzeltmeleri bir sunucuda etkinleştirildiyse ancak diğer sunucuda devre dışı bırakıldıysa, farklı sorgu planları oluşturulabilir. Daha fazla bilgi için bkz. SQL Server sorgu iyileştirici düzeltme izleme bayrağı 4199 bakım modeli.

  Sorgu iyileştirici düzeltmelerinin durumunu almak için aşağıdaki sorguyu çalıştırın:

  -- Check at server level for TF 4199
  DBCC TRACESTATUS (-1)
  -- Check at database level
  USE <YourDatabase>
  SELECT name, value, is_value_default 
  FROM sys.database_scoped_configurations
  WHERE name = 'QUERY_OPTIMIZER_HOTFIXES'
  

• bayrak farklarını izleme

  Bazı izleme bayrakları sorgu planı seçimini etkiler. Bir sunucuda diğer sunucuda etkinleştirilmemiş izleme bayrakları olup olmadığını denetleyin. Her iki sunucuda da aşağıdaki sorguyu çalıştırın ve sonuçları karşılaştırın:

  -- Check at server level for trace flags
  DBCC TRACESTATUS (-1)
  

• Donanım farklılıkları (CPU sayısı, Bellek boyutu)

  Donanım bilgilerini almak için aşağıdaki sorguyu çalıştırın:

  SELECT cpu_count, physical_memory_kb/1024/1024 PhysicalMemory_GB 
  FROM sys.dm_os_sys_info
  

• Sorgu iyileştiricisine göre donanım farklılıkları

  Sorgu planının durumunu OptimizerHardwareDependentProperties denetleyin ve donanım farklılıklarının farklı planlar için önemli olup olmadığını denetleyin.

  WITH xmlnamespaces(DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
  SELECT
    txt.text,
    t.OptHardw.value('@EstimatedAvailableMemoryGrant', 'INT') AS EstimatedAvailableMemoryGrant , 
    t.OptHardw.value('@EstimatedPagesCached', 'INT') AS EstimatedPagesCached, 
    t.OptHardw.value('@EstimatedAvailableDegreeOfParallelism', 'INT') AS EstimatedAvailDegreeOfParallelism,
    t.OptHardw.value('@MaxCompileMemory', 'INT') AS MaxCompileMemory
  FROM sys.dm_exec_cached_plans AS cp
  CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) AS qp
  CROSS APPLY qp.query_plan.nodes('//OptimizerHardwareDependentProperties') AS t(OptHardw)
  CROSS APPLY sys.dm_exec_sql_text (CP.plan_handle) txt
  WHERE text Like '%<Part of Your Query>%'
  

• İyileştirici zaman aşımı

  İyileştirici zaman aşımı sorunu var mı? Yürütülen sorgu çok karmaşıksa, sorgu iyileştirici plan seçeneklerini değerlendirmeyi durdurabilir. Durduğunda, planı o anda en düşük maliyetle seçer. Bu, bir sunucuda rastgele bir plan seçimi gibi görünmesine ve başka bir sunucuya yol açabilir.

• SET seçenekleri

  SET ARITHABORT gibi bazı SET seçenekleri plan etkiler. Daha fazla bilgi için bkz . SET Seçenekleri.

• Sorgu İpucu farklılıkları

  Sorgulardan biri sorgu ipuçlarını kullanıyor ve diğeri kullanmıyor mu? Sorgu ipuçlarının varlığını oluşturmak için sorgu metnini el ile denetleyin.

• Parametreye duyarlı planlar (parametre algılama sorunu)

  Sorguyu tam olarak aynı parametre değerleriyle mi test ediyorsunuz? Aksi takdirde, oradan başlayabilirsiniz. Plan daha önce farklı bir parametre değerine dayalı olarak bir sunucuda derlenmiş miydi? Yeniden plan yeniden kullanımı olmadığından emin olmak için RECOMPILE sorgu ipucunu kullanarak iki sorguyu test edin. Daha fazla bilgi için bkz . Parametreye duyarlı sorunları araştırma ve çözme.

• Farklı veritabanı seçenekleri/kapsamlı yapılandırma ayarları

  Her iki sunucuda da aynı veritabanı seçenekleri veya kapsamlı yapılandırma ayarları kullanılıyor mu? Bazı veritabanı seçenekleri plan seçimlerini etkileyebilir. Örneğin, veritabanı uyumluluğu, eski CE ile varsayılan CE karşılaştırması ve parametre algılama. İki sunucuda kullanılan veritabanı seçeneklerini karşılaştırmak için bir sunucudan aşağıdaki sorguyu çalıştırın:

  -- On Server1 add a linked server to Server2 
  EXEC master.dbo.sp_addlinkedserver @server = N'Server2', @srvproduct=N'SQL Server'
  
  -- Run a join between the two servers to compare settings side by side
  SELECT 
     s1.name AS srv1_config_name, 
     s2.name AS srv2_config_name,
     s1.value_in_use AS srv1_value_in_use, 
     s2.value_in_use AS srv2_value_in_use, 
     Variance = CASE WHEN ISNULL(s1.value_in_use, '##') != ISNULL(s2.value_in_use,'##') THEN 'Different' ELSE '' END
  FROM sys.configurations s1 
  FULL OUTER JOIN [server2].master.sys.configurations s2 ON s1.name = s2.name
  
  
  SELECT 
     s1.name AS srv1_config_name,
     s2.name AS srv2_config_name,
     s1.value srv1_value_in_use,
     s2.value srv2_value_in_use,
     s1.is_value_default,
     s2.is_value_default,
     Variance = CASE WHEN ISNULL(s1.value, '##') != ISNULL(s2.value, '##') THEN 'Different' ELSE '' END
  FROM sys.database_scoped_configurations s1
  FULL OUTER JOIN [server2].master.sys.database_scoped_configurations s2 ON s1.name = s2.name
  

• Plan kılavuzları

  Bir sunucudaki sorgularınız için plan kılavuzları kullanılıyor ancak diğer sunucuda kullanılmıyor mu? Farklılıkları oluşturmak için aşağıdaki sorguyu çalıştırın:

  SELECT * FROM sys.plan_guides