it-swarm.com.de

Wie stark wirken sich SQL-Kompilierungen auf die Leistung von SQL Server aus?

Ich profiliere eine Instanz eines SQL Server 2005 und ich über PerfMons SQLServer:SQL Statistics - SQL Compilations/sec Metrik, ich sehe, dass der Durchschnitt etwa 170 oder so ist.

Ich habe SQL Profiler ausgepeitscht und nach SP: Compile- oder SQL: Compile-Ereignissen gesucht. Anscheinend existieren sie nicht. Ich habe Stored Procedure/SP:Recompile und TSQL/SQL:StmtRecompile Veranstaltungen. Die Datenmenge, die ich im Profiler sehe, deutet darauf hin, dass dies die falschen Ereignisse sind, obwohl ich nicht sicher bin.

Also meine Fragen. Die Antworten auf diese Fragen wären großartig.

  1. Wie kann ich sehen, was genau in SQL Server kompiliert wird?
  2. Habe ich die falschen Metriken ausgewählt? In Perfmon oder SQL Profiler?
  3. In Bezug auf Stored Procedure/SP:Recompile und TSQL/SQL:StmtRecompile Ereignisse in SQL Profiler ... enthalten nicht die Duration-Metrik. Wie kann ich die Auswirkungen dieser Ereignisse auf das System messen, wenn sie keine Möglichkeit bieten, die zeitlichen Auswirkungen auf das System zu erkennen?.
22
AngryHacker

SQL Compilations/sec ist eine gute Metrik, aber nur in Verbindung mit Batch Requests/sec. Zusammenstellungen pro Sekunde sagen nicht viel aus.

Sie sehen 170. Wenn die Stapelanforderung pro Sekunde nur 200 beträgt (etwas übertrieben für den Effekt), müssen Sie der Ursache auf den Grund gehen (höchstwahrscheinlich eine Überbeanspruchung von Ad-hoc-Abfragen und Einwegplänen). Wenn Ihre Stapelanforderung pro Sekunde ungefähr 5000 beträgt, sind 170 Kompilierungen pro Sekunde überhaupt nicht schlecht. Es ist eine allgemeine Faustregel, dass Zusammenstellungen/Sek. bei 10% oder weniger als insgesamt Stapelanfragen/Sek. liegen sollte.

Wenn Sie wirklich einen Drilldown zu den zwischengespeicherten Daten durchführen möchten, führen Sie die folgende Abfrage aus, bei der die entsprechenden DMVs verwendet werden:

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

So erhalten Sie alle Einwegpläne (eine Zählung):

;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

So erhalten Sie ein Verhältnis der Anzahl der Einweg-Zählpläne zu allen zwischengespeicherten Plänen:

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

Die über einen SQL Server-Trace erfasste Dauer ist für die Ereignisse zum erneuten Kompilieren nicht verfügbar. Es ist nicht so wichtig, die Dauer oder den Schmerz zu sehen, den die Planerstellung verursacht, da Sie für eine Einzelfall-Situation nicht viel tun können. Die Lösung besteht darin, zu versuchen, Kompilierungen und Neukompilierungen durch Wiederverwendung von Plänen (parametrisierte Abfragen, gespeicherte Prozeduren usw.) einzuschränken.

33
Thomas Stringer

Es gibt drei relevante Zähler, die mit PerfMon (oder einer anderen Lösung von Drittanbietern) aufgezeichnet werden sollten. Der entscheidende Punkt ist, diese Statistiken irgendwie aufzuzeichnen .

  • SQL Statistics\Batch Requests/Sek
  • SQL Statistics\SQL Compilations/Sek
  • SQL Statistics\SQL Re-Compilations/Sek

Wie Thomas Stringer erwähnt , ist es gut, das Verhältnis von Zusammenstellungen/Batch-Anfrage im Auge zu behalten. Niedriger ist natürlich besser, aber es gibt nur Richtlinien für das, was "gut" ist, und nur Sie können entscheiden, was akzeptabel ist. Die absolute Menge an Perf-Gewinn, die Sie durch Reduzieren der Anzahl der Zusammenstellungen sehen, hängt von vielen Faktoren ab.

Ich schaue mir auch gerne das Verhältnis von Neukompilierungen/Kompilierung an, um einen Eindruck von der Menge der Wiederverwendung von Abfrageplänen zu bekommen. Wieder ist niedriger besser. In diesem Fall möchten Sie jedoch, dass Neukompilierungen im System durchgeführt werden, wenn sich die Statistik ändert (wenn die Datenbank schreibgeschützt ist und Sie Neukompilierungen haben ... ist möglicherweise etwas nicht in Ordnung). Wie ich bereits sagte, gibt es nur Richtlinien für das, was "gut" ist.

Was Sie wirklich tun möchten, ist, diese Zahlen im Laufe der Zeit zu bestimmen. Wenn Sie also einen großen Anstieg in einem der Verhältnisse feststellen, wurde etwas bereitgestellt, das Abfragepläne nicht korrekt verwendet (idealerweise wird dies beim Testen abgefangen) - verwenden Sie Sharks Analyse-Abfragen, um die Schuldigen zu finden. Darüber hinaus finden Sie hier häufig neu kompilierte Abfragen:

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

Wenn Sie auch Statistiken für die CPU-Auslastung aufzeichnen, können alle Statistiken miteinander korreliert werden, um herauszufinden, wie weh es tut und wie viel Ihre Korrekturen helfen. In der Praxis habe ich festgestellt, dass bereits eine einzige Strategie für einen schlechten Abfrageplan auf einem Kern-Sproc einen Server in die Knie zwingen kann. offensichtlich YMMV.

10
Jon Seigel