SQL Derlemeleri SQL Server'ın performansını ne kadar kötü etkiler?


20

SQL Server 2005'in bir örneğini profilliyorum ve PerfMon'un metriğiyle SQLServer:SQL Statistics - SQL Compilations/sec, ortalamanın yaklaşık 170 kadar olduğunu görüyorum.

SQL Profiler'ı çırptım ve SP: Compile veya SQL: Compile olaylarını aradım. Görünüşe göre onlar yok. Ben buldunuz Stored Procedure/SP:Recompileve TSQL/SQL:StmtRecompileolaylar. Profiler'de gördüğüm veri miktarı, emin olmamakla birlikte, bunların bakmak için yanlış olaylar olduğunu gösteriyor.

Sorularım. Bunlardan herhangi birinin cevapları harika olurdu.

  1. SQL Server'da tam olarak neyin derlendiğini nasıl görebilirim?
  2. Bakmak için yanlış metrikleri seçtim mi? Perfmon veya SQL Profiler'de?
  3. SQL Profiler ile ilgili Stored Procedure/SP:Recompileve TSQL/SQL:StmtRecompileolaylarla ilgili olarak ... Süre metriğini içermezler. Sistemin zamanlama etkisini görmenin bir yolunu sağlamazlarsa, bu olayların sistem üzerindeki etkisini nasıl ölçebilirim.

Yanıtlar:


33

SQL Derlemeleri / sn iyi bir metriktir, ancak yalnızca Toplu İstekler / sn ile birleştiğinde . Kendi başına, saniye başına derlemeler size çok fazla şey anlatmaz.

170 görüyorsunuz. Saniyede toplu iş gereksinimi sadece 200 ise (etki için biraz abartılıysa), evet, nedenin sonuna inmeniz gerekir (büyük olasılıkla geçici sorgulamanın ve tek kullanımlık planların aşırı kullanımı). Ancak saniyede toplu iş gereksinimi yaklaşık 5000 ise, saniyede 170 derleme hiç de fena değil. Derlemeler / sn'nin toplam Toplu İstek / sn'den % 10 veya daha az olması genel bir kuraldır .

Önbelleğe alınan öğeyi ayrıntılı olarak incelemek istiyorsanız, uygun DMV'leri kullanan aşağıdaki sorguyu çalıştırın:

select
    db_name(st.dbid) as database_name,
    cp.bucketid,
    cp.usecounts,
    cp.size_in_bytes,
    cp.objtype,
    st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st

Tüm tek kullanımlık planları (bir sayı) almak için:

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
)
select count(*)
from PlanCacheCte
where usecounts = 1

Önbelleğe alınan tüm planlarla karşılaştırıldığında kaç tane tek kullanımlık sayım planınızın oranına sahip olmak için:

declare @single_use_counts int, @multi_use_counts int

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @single_use_counts = count(*)
from PlanCacheCte
where usecounts = 1

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @multi_use_counts = count(*)
from PlanCacheCte
where usecounts > 1

select
    @single_use_counts as single_use_counts,
    @multi_use_counts as multi_use_counts,
    @single_use_counts * 1.0 / (@single_use_counts + @multi_use_counts) * 100
        as percent_single_use_counts

Bir SQL Server izleme yoluyla yakalanan sürelere gelince, Recompile olayları için kullanılamaz. Durumun derlenmesinin neden olduğu süreyi veya ağrıyı görmek o kadar önemli değildir, çünkü tek tek durum için yapabileceğiniz çok şey yoktur. Çözüm, plan yeniden kullanımı (parametreleştirilmiş sorgular, saklı yordamlar, vb.) Yoluyla derlemeleri ve yeniden derlemeleri sınırlamaya çalışmaktır.


9

PerfMon (veya başka bir 3. taraf çözümü) kullanılarak kaydedilmesi gereken üç ilgili sayaç vardır. Kilit nokta bu istatistikleri bir şekilde kaydetmek .

  • SQL İstatistikleri \ Toplu İstekler / sn
  • SQL İstatistikleri \ SQL Derlemeleri / sn
  • SQL İstatistikleri \ SQL Yeniden Derlemeleri / sn

As Thomas Stringer sözü , 's iyi derlemeler / toplu istek oranına göz kulak. Açıkçası, daha düşük daha iyidir, ancak sadece "iyi" olana ilişkin yönergeler vardır ve neyin kabul edilebilir olduğuna yalnızca siz karar verebilirsiniz. Derleme sayısını azaltarak göreceğiniz mutlak kazanç miktarı birçok faktöre bağlıdır.

Ayrıca sorgu planı yeniden kullanım miktarını anlamak için , yeniden derleme / derleme oranına bakmak istiyorum . Yine, daha düşük daha iyidir. Bununla birlikte, bu durumda, istatistikler değiştikçe sistemde yeniden derlemeler olmasını istersiniz (DB salt okunursa ve yeniden derlediyseniz ... bir şeyler yanlış olabilir). Daha önce söylediğim gibi, sadece "iyi" ne olduğuna dair yönergeler vardır.

Gerçekten yapmak istediğiniz şey, bu sayıları zaman içinde trend etmek, bu nedenle oranlardan herhangi birinde büyük bir artış görüyorsanız, sorgu planlarını doğru kullanmayan bir şey konuşlandırıldı (ideal olarak, test sırasında yakalanır) - Shark's kullanın suçluları bulmak için analiz sorguları. Ayrıca, sık sık derlenen sorguları bulmak için:

SELECT TOP 50
    qs.plan_generation_num,
    qs.execution_count,
    qs.statement_start_offset,
    qs.statement_end_offset,
    st.text
    FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    WHERE qs.plan_generation_num > 1
    ORDER BY qs.plan_generation_num DESC

CPU kullanımı için istatistikleri de kaydediyorsanız, ne kadar acıttığını ve düzeltmelerinizin ne kadar yardımcı olduğunu bulmak için tüm istatistikler birlikte ilişkilendirilebilir. Uygulamada, çekirdek bir sproc üzerindeki tek bir kötü sorgu planı stratejisinin bile bir sunucuyu dizlerine getirebileceğini buldum; belli ki YMMV.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.