SQL 컴파일은 SQL Server의 성능에 어떤 영향을 줍니까?


20

SQL Server 2005 인스턴스를 프로파일 링하고 PerfMon의 SQLServer:SQL Statistics - SQL Compilations/sec메트릭을 통해 평균이 약 170 정도임을 알 수 있습니다.

SQL Profiler를 꺼내서 SP : Compile 또는 SQL : Compile 이벤트를 찾았습니다. 분명히 존재하지 않습니다. 내가 찾았 어 Stored Procedure/SP:RecompileTSQL/SQL:StmtRecompile이벤트. 프로파일 러에서 볼 수있는 데이터 양은 확실하지는 않지만 잘못된 이벤트임을 보여줍니다.

그래서 내 질문들. 이것들에 대한 답은 훌륭 할 것입니다.

  1. SQL Server에서 정확히 무엇이 컴파일되고 있는지 어떻게 알 수 있습니까?
  2. 확인할 잘못된 측정 항목을 선택 했습니까? Perfmon 또는 SQL 프로파일 러에서?
  3. 에 관해서 Stored Procedure/SP:RecompileTSQL/SQL:StmtRecompileSQL 프로파일 러의 이벤트 ... 그들은 시간 메트릭에 포함되지 않습니다. 시스템에 대한 타이밍 영향을 볼 수있는 방법이없는 경우 이러한 이벤트가 시스템에 미치는 영향을 어떻게 측정 할 수 있습니까?

답변:


33

SQL Compilations / sec 는 좋은 지표이지만 Batch Requests / sec 와 결합 된 경우에만 가능 합니다. 자체적으로 초당 컴파일은 실제로 많은 것을 말하지는 않습니다.

초 당 배치 요청이 200에 불과한 경우 (효과적으로 약간 과장된 경우), 원인의 맨 아래로 내려 가야합니다 (대부분의 임시 쿼리 및 단일 사용 계획의 초과 사용). 그러나 초당 배치 요구가 약 5000을 측정하면 초당 170 컴파일이 나쁘지 않습니다. 일반적으로 Compilations / sec 가 총 Batch Requests / sec 보다 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 재 컴파일 / 초

토마스 스트링거 언급 , 그것의 좋은 컴파일 / 배치 요청의 비율에 눈을 유지합니다. 분명히 낮을수록 좋습니다. 그러나 "좋은"항목에 대한 지침 만 있으며 허용 가능한 항목 만 결정할 수 있습니다. 컴파일 수를 줄이면 퍼포먼스의 절대적인 양은 많은 요소에 따라 달라집니다.

또한 쿼리 계획 재 사용량을 파악하기 위해 다시 컴파일 / 컴파일 비율 을보고 싶습니다 . 다시, 낮을수록 좋습니다. 그러나이 경우 통계가 변경 될 때 시스템에서 재 컴파일을 수행하려고합니다 (DB가 읽기 전용이고 재 컴파일 한 경우 무언가 잘못되었을 수 있음). 앞에서 말했듯이 "좋은"것에 대한 지침 만 있습니다.

당신이 정말로하고 싶은 것은 시간이 지남에 따라이 숫자의 추세입니다. 따라서 비율 중 하나가 급격히 증가하면 쿼리 계획을 올바르게 사용하지 않는 배포 된 것이 이상적입니다 (이상적으로는 테스트 중에 포착됩니다). 상어를 사용하십시오 범인을 찾기위한 분석 쿼리 또한 다음은 자주 재 컴파일 된 쿼리를 찾는 방법입니다.

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 사용량에 대한 통계도 기록하는 경우 모든 통계를 서로 연관시켜 얼마나 많은 상처를 입히고 수정 사항이 얼마나 도움이되는지 알아낼 수 있습니다. 실제로 핵심 sproc에 대한 하나의 잘못된 쿼리 계획 전략만으로도 서버가 무릎을 꿇을 수 있습니다. 분명히 YMMV.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.