Наскільки погано впливають компіляції SQL на продуктивність SQL Server?


20

Я профілюю екземпляр SQL Server 2005, і я через PerfMon SQLServer:SQL Statistics - SQL Compilations/sec метрики бачу, що в середньому близько 170 або близько того.

Я витягнув SQL Profiler і шукав SP: Compile або SQL: Compile події. Мабуть, їх не існує. Я знайшов Stored Procedure/SP:Recompileі TSQL/SQL:StmtRecompileподії. Кількість даних, які я бачу в Profiler, говорить про те, що це неправильні події, на які слід дивитися, хоча я не впевнений.

Тож мої запитання. Відповіді на будь-яке з них були б чудовими.

  1. Як я можу побачити, що саме компілюється в SQL Server?
  2. Я вибрав неправильні показники, щоб їх переглянути? У Perfmon чи SQL Profiler?
  3. Що стосується Stored Procedure/SP:Recompileта TSQL/SQL:StmtRecompileподій у SQL Profiler ... вони не включають показник Тривалість. Як я можу оцінити вплив цих подій на систему, якщо вони не дозволяють побачити вплив часу на систему.

Відповіді:


33

Компіляції SQL / сек - це хороший показник, але лише в поєднанні з пакетними запитами / сек . Самі по собі компіляції за секунду насправді мало що розповідають вам.

Ви бачите 170. Якщо пакетна кількість запитів на секунду становить лише 200 (трохи перебільшено за ефектом), то так, вам потрібно зійти донизу причини (швидше за все, надмірне використання спеціальних запитів та планів одноразового використання). Але якщо ваш пакетний запит на секунду вимірює близько 5000, то 170 компіляцій за секунду зовсім не погано. Загальним правилом є те, що компіляції / сек повинні становити 10% або менше загальних пакетних запитів / сек .

Якщо ви дійсно хочете переглянути деталі кешованого запиту, запустіть наступний запит, який використовує відповідні DMV:

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

Щоб отримати всі плани одноразового використання (кількість):

;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

Щоб отримати співвідношення кількості планів для одноразового використання у порівнянні з усіма кешованими планами:

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

Що стосується тривалості, захопленої через трасування SQL Server, вона не доступна для подій перекомпіляції. Це не так важливо, щоб побачити тривалість або біль, що викликає складання плану, так як для ситуації в кожному конкретному випадку ви не можете багато чого зробити. Рішення полягає в спробі обмежити компіляції та рекомпіляції шляхом повторного використання плану (параметризовані запити, збережені процедури тощо).


9

Є три відповідних лічильника, які слід записати за допомогою PerfMon (або іншого рішення сторонніх розробників). Ключовий момент - якось записати ці статистичні дані.

  • Статистика SQL \ Пакетні запити / сек
  • Статистика SQL \ Компіляції SQL / сек
  • Статистика SQL \ повторна компіляція SQL / сек

Як згадував Томас Стрінгер , добре стежити за співвідношенням компіляції / пакетного запиту. Очевидно, що нижче - краще, але існують лише вказівки щодо того, що "добре", і тільки ви можете вирішити, що є прийнятним. Абсолютна кількість приросту за парфу ви побачите, зменшивши кількість компіляцій, залежить від багатьох факторів.

Мені також подобається переглянути співвідношення перекомпіляцій / складання , щоб отримати розуміння кількості повторного використання плану запитів. Знову нижче, краще. У цьому випадку, однак, ви хочете, щоб перекомпіляції в системі відбувалися під час зміни статистики (якщо БД є лише для читання і у вас є перекомпіляції ... щось може бути не так). Як я вже говорив раніше, є лише вказівки щодо того, що "добре".

Те, що ви насправді хочете зробити, - це тенденція з часом змінювати ці цифри, тому, якщо ви бачите величезний шип у будь-якому з співвідношень, щось розгортається, що неправильно використовує плани запитів (в ідеалі це потрапляє під час тестування) - використовуйте Shark's аналіз запитів, щоб знайти винуватців. Окрім того, тут можна знайти запити, які часто перекомпонуються:

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

Якщо ви також записуєте статистику для використання процесора, всі статистичні дані можна співвіднести, щоб дізнатись, наскільки це боляче, і наскільки допоможуть ваші виправлення. На практиці я виявив, що навіть лише одна стратегія плану поганих запитів на основному відростку може поставити сервер на коліна; очевидно YMMV.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.