Kaynak süresine sorun giderme

udf sınıflandırma için kullanılabilir hiçbir Sınıflandırıcısı vardır sonra tüm oturumlar için varsayılan otomatik olarak gidecek iş yükü grubu.Bir udf Sınıflandırıcısı oluşturduktan sonra kaynak süresine ile kayıtlı olduğunu ve bellek içi yapılandırma güncelleştirilmiş olduğunu doğrulamak gerekir.

Oluşturma, kaydetme ve etkinleştirme bir Sınıflandırıcısı udf üç adım işlemdir:

• İlk olarak, işlev oluşturmak gerekir.

  CREATE FUNCTION function_name() RETURNS <something> 
  WITH SCHEMABINDING
  

• İkinci olarak, işlev ile kaynak süresine kaydetmek gerekir.

  ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION=schema_name.function_name)
  

• Üçüncü olarak, kaynak süresine bellek içi yapılandırma güncelleştirmeniz gerekmez.

  ALTER RESOURCE GOVERNOR RECONFIGURE
  

Sınıflandırma sorun giderme olduğunu doğruladığınızda, oluşturduğunuz işlev kaynak süresine ve yapılandırma ile kayıtlı olduğunu yapmanız ilk şey güncelleştirildi.Şema adı edinmek için aşağıdaki sorgu kullanın (schema_name) ve Sınıflandırıcısı işlev adı (function_name) için kaynak süresine kullanmakta udf Sınıflandırıcısı.

USE master
SELECT 
      object_schema_name(classifier_function_id) AS [schema_name],
      object_name(classifier_function_id) AS [function_name]
FROM sys.dm_resource_governor_configuration

Burada udf Sınıflandırıcısı değişti ancak kaynak süresine hala önceki işlev mantığı oturumları sınıflandırmak için kullandığı bir senaryo ilgili sorunları gidermek için yukarıdaki yaklaşım kullanabilirsiniz.Bu davranış, yaptığınız değişiklikler bellek içi yapılandırma uygulandı gösterir.

Beklenen sonuçlar üretmek ya da kaynak yoğun olan bir çok karmaşık Sınıflandırıcısı işlev oluşturabilirsiniz.Temel sorun giderme yaptıysanız, sonra işlev mantığı ses olduğunu doğrulamanız gerekir.En kötü durum senaryosunda, bir kodlama kusur biridir sonuçlar sonsuz bir döngüye veya kaçan bir sorgu.

Adanmış yönetici bağlantısı (dac), çünkü dac bir sınıflandırmaya tabi değildir ve kaynak süresine çalışan ve gelen oturumları sınıflandırma kullanılabilir Sınıflandırıcısı işlev yazılan kötü sorun gidermek için kullanabilirsiniz.Daha fazla bilgi için bkz: Adanmış yönetici bağlantısı kullanma.

Aşağıdaki sorgulayarak Sınıflandırıcısı işlev hakkında bilgi edinebilirsiniz:

• sys.dm_exec_query_stats.(contains statement information but not the actual function)

• sys.dm_exec_sql_text(birlikte kullanın sql_handle alınan sys.dm_exec_query_stats)

• PreConnect:Starting Event Class (kimliği ve adı Sınıflandırıcısı işlev sağlar)

Bu senaryoda, istek sayısı azaltılır şüphe ve kullanıcı performans düşüşü raporlar.

Yapmanız gereken ilk şey, istek sayısını azaltmayı açıkça, kullanıcı grubu için yapılandırılmış olup olmadığını doğrulamak olur.group_max_requests ayarı etkin olup olmadığını görmek için kullanıcının grup üyeliğini kontrol ederek bunu.group_max_requests etkin olması hiçbir açık istek sayısı azaltma.Araştırmanız gerekir aşağıdaki adımları göre daha fazla.

• Sorgu sys.dm_os_waiting_tasks görmek istekler bekliyor, resmgr_throttled bekleme türü.İstek sayısını azaltmayı bu bekleme türü varlığını gösterir.

• Performans İzleyicisi'ni başlatmak ve verileri kullanarak toplama sıraya alınan istekler ve etkin istekleri sayaçları.Sıfır olmayan sıraya alınan istek sayısını azaltma isteği gösterir.

• Olmadığını kontrol etkin istekleri değerle eşleşen group_max_requests ayarı.If the Active requests value is higher than the GROUP_MAX_REQUESTS setting, the group may have requests that cannot be throttled (for example, open transactions).

• If Queued requests is zero, check the Active requests of all the workload groups sharing the same resource pool because the pool may have been overloaded with too many requests.

Kaynak süresine olay üretimi tarafından yönlendirilen bir ilkesi varsa, en yüksek cpu sınırına ulaşıldığında oluşturan olayın kullanabilirsiniz.

Bu senaryoda, çok fazla cpu kullanan bir sorgu algılamak için yapılandırılan en fazla cpu sınırını (REQUEST_MAX_CPU_TIME_SEC) çok düşük olup olmadığını belirlemek istiyorsunuz.

Aşağıdaki eylemleri cpu sınır ayarı doğrulamak yardımcı olur.

• sql izleme oturum başlatmak ve toplama cpu eşiği aşıldı olay.Kullanıcı isteği cpu kullanım sınırına ulaştığında, sunucu sql izleme olay otomatik olarak oluşturur.Ayarınızı çok düşükse, bu olaylar çok sayıda üretilecektir.

• Performans İzleyicisi'ni başlatmak ve verileri kullanarak toplama en fazla cpu saat (ms) istek sayaç.Bu sayacın değeri bir kılavuz olarak uygun sınırı ayarlamak için kullanabileceğiniz iş yükü grubu.

Bu senaryoda, cpu bant genişliği nedeniyle bastırma şüpheleniyorsanız cpu kullanımı % performans sayacı veya kaynak süresine max_cpu_percent ayarı'e yakın olur.cpu kullanımı % değeri için tüm iş yükünü grupları ve kaynak havuzları için aşağıdaki sorgu döndürür bir SQL Server örnek.

select * from sys.dm_os_performance_counters where counter_name = 'cpu usage %'

Daha fazla bilgi için bkz: sys.dm_os_performance_counters (Transact-sql).

Sisteminizde aşağıdaki denetimleri gerçekleştirerek cpu bant genişliği daraltma olup olmadığını belirleyebilirsiniz.

• Toplam sunucu cpu kullanımını denetleyin.sql Server dışında bir yükü etkin değilse, sorun gidermeye çalışıyorsanız sorgu etkileyebilir.

• cpu kullanımı kaynak havuzları arasında dağıtımını denetleyin.cpu kullanımı için yapılandırılmış yüksek bir minimum değer başka bir havuza sahip olduğu kaynak havuzu bastırma.Sayaçlar için beklenen (Hesaplanan cpu kullanımı) gerçek cpu kullanımına karşı karşılaştırın.

• Söz konusu kaynak havuzuna atanan iş yükünü gruplarını denetleyin.Diğer iş yükünü grupları yük aynı havuzunu paylaşan kullanıcıları etkileyebilir.

• cpu kullanımı dağıtımını planlayıcılar kontrol edin.İncelediğiniz sorgunun uzun süre çalışan sorguları içeren bir Zamanlayıcı üzerinde yerleştirilmiş olabilir.Bu durum, sorguyu bastırma gibi görünebilir ancak eşit olmayan yük planlayıcılar arasında dağıtımını gerçek sorundur.

• Burada iş yükünü kaynak süresine ayarları tarafından bastırma yerine diğer oturumları engellendi olası durumlar için denetleyin.

• Sistemde şu anda çalışan sorgu oturumları sayısını denetleyin.Eş zamanlı yürütülen istek sayısı arttıkça, sql Server bunların tümünü en az miktar CPU güvenceye dener saat cpu artırılarak.

Bu senaryoda, grant bellek boyutu bir sorgu yavaş çalışmasına neden olduğundan kuşkulanıyorsanız.

Kaynak süresine grant bellek büyük sorgular böylece azaltarak maksimum sorgu bellek sınırını zorlayan uyma sınırı içinde.Bellek grant % 100'den küçük bir sorgu alırsa, geçici veri spill ve dikkat çekici bir performans etkisi olan bir diske yazmak gerekli olabilir.

Sorgular büyük yüzdesini belirlemek gereken küme uygun maksimum sorgu boyutu sınırı.Aşağıdaki eylemleri en iyi ayarları belirlemek yardımcı olacaktır:

• Sorgu sys.dm_exec_query_memory_grants görmek geçerli durumunu bellek verir.The ideal_memory_kb column shows the ideal amount based on the cardinality estimate.The requested_memory_kb column shows the asking amount which could have been reduced after reaching the maximum query limit.If requested_memory_kb is significantly lower than ideal_memory_kb, then the query may end up spilling frequently (assuming that the cardinality estimate is correct).

• Performans İzleyicisi'ni başlatmak ve verileri kullanarak toplama daha az bellek verir/sn sayaç.Bu sayacın değeri en fazla istek boyutu sınırını vurarak sonra ideal tutardan daha az alınan bellek grant Count hızını temsil eder.Büyük sorguları bellek sınırları içinde kalmak için diske spill gerektiğinden ideal bir tutarla olandan çok daha yavaş çalışabilir.

Hafifletmek için bir bellek vermek sorun, havuz boyutu sınırı veya en büyük bellek boyutu sınırı artırmak zorunda kalabilirsiniz.

Bu senaryoda, bir sorgu bellek verme zaman aşımı hatası ile başarısız olur.

Etkin belleğin bölümlerinin toplam sayı vermek istekleri ve belirtilen bellek sınırlarını iş yükü grubu ve kaynak havuzu tanımları içinde bellek verme zaman aşımı rol çalabilir.Bir tek kaynak havuzuna birden çok kaynak grupları tarafından paylaşılıyorsa, diğer gruplarda eşzamanlı sorguları sayısını bellek verme zaman aşımı da etkileyebilir.

Aşağıdaki eylemleri en iyi kaynak havuzu ayarlarını belirlemek yardımcı olacaktır:

• Sorgu sys.dm_exec_query_memory_grants bellek verir ve bu grup ve bekleyen sorguları sayısını görmek içinhavuz.

• Sorgu sys.dm_exec_query_resource_semaphores görmek toplam verilen bellek ve hedefler.

GRANT bellek kullanımı kullanılabilir bellek alanından daha büyük olduğunda, kaynak havuzu boyutu sınırını artırmayı düşünebilirsiniz.

Bir sorgu bir yetersiz bellek hatası ile başarısız olur.

Temel sorun giderme

Gelişmiş sorun giderme

Bu senaryoda, bir sorgu bir hassasiyetli sorgu planı nedeniyle yavaş çalıştığını kuşkulanıyorsanız.Bunu yeterli bellek yetersiz bellek sınırı ayarlamak için bir kaynak havuzu nedeniyle almazsa sorgu iyileştiricisi hassasiyetli sorgu planı oluşturabilir.

Aşağıdaki eylemleri en iyi kaynak havuzu ayarlarını belirlemek yardımcı olacaktır:

• Verilerin alınacağı veri sorgu en iyi duruma getirmeleri/sn görmek için sayaç olup olmadığını iş yükü grubu çok sayıda sorgu derlerken vardır.

• Verilerin alınacağı veri hassasiyetli planları/sn görmek için sayaç sorgu iyileştiricisi sık sık hassasiyetli planlar üretir.

Yukarıdaki koşullardan biri varsa, kaynak havuzu bellek sınırını artırmayı düşünün.