Veritabanı uygulaması ile SSMS arasındaki sorgu performansı farkını giderme

Bir veritabanı uygulamasında sorgu yürütürken, SQL Server Management Studio (SSMS), Azure Data Studio veya SQLCMD gibi bir uygulamada aynı sorgudan daha yavaş çalışır.

Bu sorun, aşağıdaki nedenlerden oluşabilir:

• Sorgular farklı parametreler veya değişkenler kullanır.

• Sorgular farklı ağlar üzerinden sunucuya gönderilir veya uygulamaların verileri işleme şekli farklıdır.

• Veritabanı uygulamasındaki ve SSMS'deki SET seçenekleri farklıdır.

Sorunu gidermek için şu adımları izleyin:

1. Adım: Sorguların aynı parametreler veya değişkenlerle gönderildiğini doğrulayın

Bu sorguları karşılaştırmak ve her şekilde aynı olduklarından emin olmak için şu adımları izleyin:

1. SSMS'nizi açın ve kullandığınız Veritabanı Altyapısına bağlayın.

2. Genişletilmiş Olaylar oturumu oluşturmak için aşağıdaki komutları çalıştırın:

   CREATE EVENT SESSION <EventSessionName> ON SERVER
   ADD EVENT sqlserver.existing_connection(SET collect_options_text=(1)),
   ADD EVENT sqlserver.login(SET collect_options_text=(1)
       ACTION(sqlserver.client_app_name)),
   ADD EVENT sqlserver.rpc_completed,
   ADD EVENT sqlserver.sp_statement_completed(
       ACTION(sqlserver.client_app_name)),
   ADD EVENT sqlserver.sql_batch_completed(
       ACTION(sqlserver.client_app_name)),
   ADD EVENT sqlserver.sql_statement_completed(
       ACTION(sqlserver.client_app_name))
   ADD TARGET package0.event_file(SET filename=N'<FilePath>')
   WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 
   SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
   GO
   

   Not

   EventSessionName ve FilePath> yer tutucularını <oluşturmak istediklerinizle değiştirin.<>

3. EventSessionName oturumunu başlatmak için aşağıdaki komutları çalıştırın:

   ALTER EVENT SESSION <EventSessionName> ON SERVER
   STATE = START
   

4. Sorunu yeniden oluşturmak için sorgularınızı çalıştırın.

5. Toplanan verileri analiz etmek için aşağıdaki yöntemlerden birini kullanın:

   • Windows Gezgini'ni açın, hedef .xel dosyasını bulun ve üzerine çift tıklayın. Dosya, görüntülemek ve çözümlemek için kullanabileceğiniz başka bir SSMS penceresinde açılır.

   • Nesne Gezgini'daYönetim>Genişletilmiş Olaylar>Oturumları>EventSessionName'i genişletin, package0.event_file sağ tıklayın ve Hedef Verileri Görüntüle... öğesini seçin.

   • .xel dosyalarının konumunu bulun ve sys.fn_xe_file_target_read_file işlevini kullanarak bu dosyayı okuyun.

6. Aşağıdaki olayları denetleyerek Field deyimini karşılaştırın:

   • sp_statement_completed
   • sql_batch_completed
   • sql_statement_completed
   • rpc_completed

Özdeş sorgular hakkında daha fazla bilgi için aşağıdaki örneklere bakın:

• Saklı yordamların veya işlevlerin farklı parametre değerleri varsa, sorgu süreleri farklı olabilir:

  • SpUserProc @p1 = 100

  • SpUserProc @p1 = 270

• Aşağıdaki sorgular farklıdır. İlk sorgu kardinalite tahmini için histogramdan Ortalama Yoğunluk kullanırken, ikinci sorgu kardinalite tahmini için histogram adımını kullanır:

  • declare @variable1 = 123
    select * from table where c1 = @variable1
    

  • select * from table where c1 = 123
    

Yukarıdakiyle aynı nedenle, saklı yordamın yürütülmesini eşdeğer geçici sorgunun (yerel değişkenleri kullanarak) yürütülmesiyle karşılaştırmak farklı olabilir. Özdeş deyimlerin karşılaştırılması gerekir.

2. Adım: Sunucuda yürütme süresini ölçme

Sorgu sürelerinin doğru karşılaştırması için ağ gecikme süresini veya uygulamaya özgü veri işleme süresini dışlayabilirsiniz. SQL Server yalnızca yürütme süresini ölçmek için aşağıdaki yöntemlerden birini kullanın:

• SET STATISTICS TIME komutunu kullanarak sorgunuzu çalıştırın:

  SET STATISTICS TIME ON
  <YourQuery>
  SET STATISTICS TIME OFF
  

• Sorgunun süresini veya geçen süresini (olay sınıfı SQL:StmtCompleted, SQL:BatchCompletedveya RPC:Completed) incelemek için 1. adımdaki XEvent'i kullanın.

Bazı durumlarda sorgular arasındaki zaman farkının nedeni farklı bir ağda çalışan bir uygulama veya uygulamanın kendisi olabilir. Sunucuda yürütmeyi karşılaştırdığınızda, sorguların sunucuda çalıştırılmasının ne kadar sürdüğünü karşılaştırırsınız.

3. Adım: Her bağlantı için SET seçeneklerini denetleyin

Sorgu planını etkileyen SET seçenekleri vardır, bu da sorgu planı seçimini değiştirebilecekleri anlamına gelir. Bu nedenle, bir veritabanı uygulaması SSMS'den farklı küme seçenekleri kullanıyorsa, her küme seçeneği farklı bir sorgu planı alabilir. Örneğin, ARITHABORT, NUMERIC_ROUNDABORT, ROWCOUNT, FORCEPLAN ve ANSI_NULLS. SSMS ile .NET uygulamaları arasında gözlemlenen en yaygın fark SET ARITHABORT seçeneğidir. Varsayılan olarak, seçenek SSMS'de ON olarak ayarlanır ancak çoğu veritabanı uygulamasında KAPALI olarak ayarlanır. Uygulama gereksinimlerinize göre, ikisi arasında geçerli bir karşılaştırma yapmak için ARITHABORT'ı hem SSMS'de hem de uygulamada aynı ayara ayarlayın.

Uyarı

SQL Server Management Studio için varsayılan ARITHABORT ayarı ON'dır. ARITHABORT ayarını KAPALI olarak ayarlayan istemci uygulamaları farklı sorgu planları alabilir ve kötü performans gösteren sorgularda sorun gidermeyi zorlaştırabilir. Başka bir ifadeyle, aynı sorgu Management Studio'da hızlı ancak uygulamada yavaş yürütülebilir. Management Studio ile sorgu sorunlarını giderirken her zaman istemci ARITHABORT ayarıyla eşleşin.

Plan etkileyen tüm seçeneklerin listesi için bkz. Seçenekleri ayarlama.

Hem SSMS hem de uygulamadaki SET seçeneklerinin geçerli bir karşılaştırma yapabilmek için aynı olduğundan emin olmak için şu adımları izleyin:

1. 1. adımda toplanan verileri kullanın.

2. ve olaylarınılogin, özellikle options_text ve existing_connectionseçenekleri sütunlarını denetleyerek küme seçeneklerini karşılaştırın.