지난 4 시간 동안 대부분의 쿼리 계획이 다시 작성되었습니다.


9

SQL Server 데이터베이스 성능에 문제가 있습니다. 이 도구를 sp_BlitzCache 찾았 습니다 . 명령이 실행 된 후이 문장을 얻었습니다.

지난 24 시간 동안 92.00 %의 계획이 작성되었고 지난 4 시간 동안 92.00 %의 계획이 작성되었습니다.

SQL Server 프로파일 러를 사용하여 문제를 식별하는 동안 StmtRecompile 이벤트 발생을 확인했지만 자주 재구성되는 전체 텍스트 검색 쿼리를 몇 개만 찾을 수있었습니다. 그러나 전체 텍스트 검색 쿼리는 모든 쿼리의 약 5 %를 나타냅니다.

나머지 87 % 계획을 재생산 할 수있는 제안 사항이 있습니까?

SQL Server 2012 (버전 11.0.6567.0)가 있습니다.

편집 : 성능 카운터를 추가했습니다

+---------------------------+--------------------------------+--------------+
|        object_name        |          counter_name          |  cntr_value  |
+---------------------------+--------------------------------+--------------+
| SQLServer:Buffer Manager  | Background writer pages/sec    |            0 |
| SQLServer:Buffer Manager  | Buffer cache hit ratio         |        28436 |
| SQLServer:Buffer Manager  | Buffer cache hit ratio base    |        28436 |
| SQLServer:Buffer Manager  | Checkpoint pages/sec           |      8259452 |
| SQLServer:Buffer Manager  | Database pages                 |      4434337 |
| SQLServer:Buffer Manager  | Free list stalls/sec           |            9 |
| SQLServer:Buffer Manager  | Integral Controller Slope      |            0 |
| SQLServer:Buffer Manager  | Lazy writes/sec                |         5608 |
| SQLServer:Buffer Manager  | Page life expectancy           |       438901 |
| SQLServer:Buffer Manager  | Page lookups/sec               | 122694703703 |
| SQLServer:Buffer Manager  | Page reads/sec                 |     60994608 |
| SQLServer:Buffer Manager  | Page writes/sec                |    126076564 |
| SQLServer:Buffer Manager  | Readahead pages/sec            |     45305420 |
| SQLServer:Buffer Manager  | Target pages                   |    130990080 |
| SQLServer:Buffer Node     | Database pages                 |      4434337 |
| SQLServer:Buffer Node     | Page life expectancy           |       438901 |
| SQLServer:Buffer Node     | Local node page lookups/sec    |            0 |
| SQLServer:Buffer Node     | Remote node page lookups/sec   |            0 |
| SQLServer:Memory Manager  | External benefit of memory     |            0 |
| SQLServer:Memory Manager  | Connection Memory (KB)         |         3304 |
| SQLServer:Memory Manager  | Database Cache Memory (KB)     |     35474784 |
| SQLServer:Memory Manager  | Free Memory (KB)               |     13229808 |
| SQLServer:Memory Manager  | Granted Workspace Memory (KB)  |            0 |
| SQLServer:Memory Manager  | Lock Memory (KB)               |       455928 |
| SQLServer:Memory Manager  | Lock Blocks Allocated          |      1798154 |
| SQLServer:Memory Manager  | Lock Owner Blocks Allocated    |      3568588 |
| SQLServer:Memory Manager  | Lock Blocks                    |        10562 |
| SQLServer:Memory Manager  | Lock Owner Blocks              |        10617 |
| SQLServer:Memory Manager  | Maximum Workspace Memory (KB)  |     43368000 |
| SQLServer:Memory Manager  | Memory Grants Outstanding      |            0 |
| SQLServer:Memory Manager  | Memory Grants Pending          |            0 |
| SQLServer:Memory Manager  | Optimizer Memory (KB)          |         1400 |
| SQLServer:Memory Manager  | Reserved Server Memory (KB)    |            0 |
| SQLServer:Memory Manager  | SQL Cache Memory (KB)          |       229112 |
| SQLServer:Memory Manager  | Stolen Server Memory (KB)      |      8063232 |
| SQLServer:Memory Manager  | Log Pool Memory (KB)           |         4192 |
| SQLServer:Memory Manager  | Target Server Memory (KB)      |     56934400 |
| SQLServer:Memory Manager  | Total Server Memory (KB)       |     56767824 |
| SQLServer:Memory Node     | Database Node Memory (KB)      |     35474784 |
| SQLServer:Memory Node     | Free Node Memory (KB)          |     13229808 |
| SQLServer:Memory Node     | Foreign Node Memory (KB)       |            0 |
| SQLServer:Memory Node     | Stolen Node Memory (KB)        |      8063208 |
| SQLServer:Memory Node     | Target Node Memory (KB)        |     56934376 |
| SQLServer:Memory Node     | Total Node Memory (KB)         |     56767800 |
+---------------------------+--------------------------------+--------------+

누군가 누군가 DBCC FREEPROCCACHE를 실행 했습니까? : P
Daniel Björk 2016 년

@ DanielBjörk 나는 이와 같은 일을 할 권한이있는 유일한 사람이므로 그 이유가 아니라고 생각합니다. 그러나 확인하겠습니다.
Marcin Topolewski

매개 변수화 된 쿼리 또는 저장 프로 시저를 사용하고 있습니까? 또는 SQL에 문자열 / 숫자 리터럴이있어서 계획을 재사용 할 수 없다는 문제입니까?
James Z

@JamesZ 예, 매개 변수가 많은 쿼리를 사용하고 있습니다. 내 게시물 BlitzCache에서 언급 한 도구는 매개 변수 스니핑에 문제가 있다고 말합니다.
Marcin Topolewski

1
야간에 인덱스를 다시 작성하거나 통계를 업데이트하고 있습니까? 서버에 메모리 부족이 있습니까?
Erik Darling

답변:


6

계획 작성 시간을 테스트하는 데 사용되는 쿼리는 다음과 같습니다.

WITH x AS (
SELECT SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 24 THEN 1 ELSE 0 END) AS [plans_24],
       SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 4 THEN 1 ELSE 0 END) AS [plans_4],
       SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 1 THEN 1 ELSE 0 END) AS [plans_1],
       COUNT(deqs.creation_time) AS [total_plans]
FROM sys.dm_exec_query_stats AS deqs
)
SELECT CONVERT(DECIMAL(3,2), NULLIF(x.plans_24, 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_24],
       CONVERT(DECIMAL(3,2), NULLIF(x.plans_4 , 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_4],
       CONVERT(DECIMAL(3,2), NULLIF(x.plans_1 , 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_1],
       @@SPID AS SPID
INTO #plan_creation
FROM x
OPTION (RECOMPILE) ;

또한 SP는 추가 연구를 시작할 위치와 실마리를 제공합니다.

이 백분율이 높으면 메모리 부족의 징후이거나 계획 캐시 불안정 일 ​​수 있습니다.

위의 단서 외에 서버가 다시 시작되었는지 확인하십시오.

서버가 다시 시작되지 않으면 다음과 같은 접근 방식이 있습니다.

  • 당신의 직면 메모리 압력을 확인

먼저 메모리 설정이 최적으로 구성된 경우 참조하십시오. 그렇다면 아래 카운터를 사용하여 메모리 압력에 직면하고 있는지 확인할 수 있습니다

메모리 : 사용 가능한 MB
SQL 버퍼 : 사용 가능한 페이지
SQL 버퍼 : 페이지 수명
SQL 버퍼 : 지연 쓰기

메모리 부족에 직면하면 더 많은 메모리를 사용하거나 더 많은 메모리를 추가하는 쿼리를보고 조정할 수 있습니다

재 컴파일을 유발하는 쿼리를 실행했을 수 있습니다.

  • 쿼리에서 참조하는 테이블 또는 뷰의 변경 사항 (ALTER TABLE 및 ALTER VIEW).

  • 단일 프로 시저를 변경하면 캐시에서 해당 프로 시저에 대한 모든 계획이 삭제됩니다 (ALTER PROCEDURE).

  • 실행 계획에서 사용하는 인덱스 변경

  • UPDATE STATISTICS와 같은 명령문에서 명시 적으로 생성되거나 자동으로 생성 된 실행 계획에 사용되는 통계에 대한 업데이트입니다.

  • 실행 계획에서 사용하는 인덱스를 삭제합니다.

캐싱 계획에 대한 자세한 내용은이 백서를 참조하십시오.

https://technet.microsoft.com/en-us/library/ee343986(v=sql.100).aspx


성능 카운터를 추가했는데이 값을 해석하는 데 도움이 될 수 있습니까?
Marcin Topolewski

여기에 자세한 메모리 관련 카운터 피려 할 수 있습니다 blogs.msdn.microsoft.com/teekamg/2007/11/06/...
TheGameiswar

@TheGameiswar는 "인덱스 변경, 통계 업데이트와 같은 재 컴파일을 유발하는 쿼리를 실행했을 수 있습니다"라고 말합니다. 매일 밤 조각화 + 업데이트 통계를 기반으로 인덱스 재구성 / 재 구축을 수행하는 경우, 내 계획이 매일 매일 (또는 거의 모두) 다시 작성 될 것입니까? 그게 문제입니까?
Danielle Paquette-Harvey

2

@TheGameiswar가 말한 것을 추가하기 위해이 쿼리를 실행하여 캐시에서 얻지 못한 계획의 세부 정보를 볼 수도 있습니다.

;with
    xmlnamespaces (N'http://schemas.microsoft.com/sqlserver/2004/07/showplan' as DYN)
select
    db_name(st.dbid) as DBName
    , object_schema_name(st.objectid, st.dbid) as SchemaName
    , object_name(st.objectid, st.dbid) as ObjectName
    , ecp.objtype
    , st.text
    , qp.query_plan.value('(/DYN:ShowPlanXML/DYN:BatchSequence/DYN:Batch/DYN:Statements/DYN:StmtSimple/@RetrievedFromCache)[1]', 'varchar(100)') as RetrievedFromCache
    , qp.query_plan
into #temp
from sys.dm_exec_cached_plans ecp
    outer apply sys.dm_exec_query_plan(ecp.plan_handle) qp
    outer apply sys.dm_exec_sql_text(ecp.plan_handle) st

select
    *
from #temp t
where t.RetrievedFromCache is null
    and t.DBName is not null
order by t.DBName, t.SchemaName, t.ObjectName;
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.