( 이 MSDN 기사에서 ) 아래 쿼리를 실행하여 CPU 시간별로 가장 나쁜 쿼리를 결정 하지만 설정된 날짜에만 해당합니까?
-- Find top 5 queries
SELECT TOP 5 query_stats.query_hash AS "Query Hash",
SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS "Avg CPU Time",
MIN(query_stats.statement_text) AS "Statement Text"
FROM
(SELECT QS.*,
SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE QS.statement_end_offset END
- QS.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS QS
CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
ORDER BY 2 DESC;
GO
우리의 데이터베이스는 지난 날 심각한 부담을 받았고 문제의 원인을 파악할 수 없습니다.
우리는 Azure SQL Database를 사용하고 있습니다.
DMV에서 일일 통계를 얻을 수 없습니다. dm_exec_query_stats에는 creation_time 및 last_execution_time 열이 있으며, 이는 물론 무슨 일이 일어 났는지 알 수있는 열을 제공합니다. 그러나 이는 해당 계획이 사용 된 처음이자 마지막에 불과합니다. 계획이 계획 캐시에서 삭제되는 경우에도 통계가 손실되므로 상황이 더 나아지고 "나쁜"계획이 더 나은 계획으로 대체 된 경우 해당 계획과 통계가 더 이상 없을 수 있습니다.
이 쿼리는 쿼리에서 사용하는 평균 CPU를 보여 주므로 성능 문제를 해결하는 데 완벽한 쿼리는 아닙니다. 실제로 평균이기 때문에 실행 횟수가 적은 항목은 실제로 문제가되지 않더라도 목록에서 정말 높을 수 있습니다. 일반적으로 성능 문제를 해결하기 위해 총 CPU 및 총 논리적 읽기를 사용하지만 이는 생성 시간 이후의 총량이며 오래 전일 수 있습니다. 이 경우 생성 시간 이후의 시간으로 숫자를 나누는 것도 고려할 수 있으므로 시간당 평균 CPU / I / O를 얻을 수 있습니다. 또한 max * 열을 보면 잘못된 쿼리 / 계획에 대한 힌트를 얻을 수 있습니다.
이러한 종류의 문제가있는 경우 해당 SQL을 작업으로 예약하고 결과를 어딘가에 수집하는 것이 좋습니다. 그런 다음 상황이 나쁠 때 변경된 사항을 비교하기위한 기준으로 사용할 수도 있습니다. 물론이 경우 (아마도 그렇지 않은 경우도 있음) 상위 5 개 이상을 살펴보아야합니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다