Kimberly Tripp의 SQL Server 계획 캐싱과 관련하여 다음과 같은 훌륭한 기사를 읽었습니다. http://www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/
"임시 작업 부하를 최적화"하는 옵션이있는 이유는 무엇입니까? 항상 켜져 있지 않아야합니까? 개발자가 임시 SQL을 사용하는지 여부에 관계없이이 옵션을 지원하는 모든 인스턴스 (SQL 2008+)에서이 옵션을 활성화하지 않아 캐시 부풀림이 줄어드는 이유는 무엇입니까?
답변:
SQL Server 개발 팀은 가장 놀랍지 않은 원칙에 따라 작업하므로 SQL Server에는 일반적으로 이전 버전과 같은 동작을 유지하기 위해 새로운 기능이 비활성화되어 있습니다.
예, 임시 워크로드에 대한 최적화는 계획 캐시 부풀림을 줄이는 데 탁월하지만 항상 먼저 테스트하십시오!
[편집 : Kalen Delaney는 흥미로운 일화에 따르면 Microsoft 엔지니어 친구에게이 기능을 사용하는 것이 적절하지 않은 상황이 있는지 물었습니다. 그는 며칠 후 다시 돌아와서 많은 쿼리가 있고 각 쿼리가 총 두 번 정확히 실행되는 응용 프로그램을 상상해보십시오. 그러면 부적절 할 수 있습니다. 그런 앱이 많지 않다고해도 충분합니다!]
[편집 : 대부분의 쿼리가 두 번 이상 실행되는 경우 (정확히 두 번이 아님); 적합하지 않을 수 있습니다. 일반적인 규칙은 데이터베이스에 일회용 일회용 쿼리가 많이있는 경우이를 돌리는 것입니다. 그러나 여전히 그런 앱은 많지 않습니다.]
다음은 " Ad Hoc 워크로드 ON / OFF 전환 최적화 "가 유리 한지 여부를 결정하는 데 도움이되는 작은 코드입니다 . 우리는 일반적으로 사내 및 클라이언트 서버에 대한 상태 점검의 일부로이를 점검합니다.
이를 사용하는 것이 가장 안전한 옵션이며 Brad는 여기 , Glenn Berry는 여기 에 잘 설명되어 있습니다 .
--- for 2008 and up .. Optimize ad-hoc for workload
IF EXISTS (
-- this is for 2008 and up
SELECT 1
FROM sys.configurations
WHERE NAME = 'optimize for ad hoc workloads'
)
BEGIN
DECLARE @AdHocSizeInMB DECIMAL(14, 2)
,@TotalSizeInMB DECIMAL(14, 2)
,@ObjType NVARCHAR(34)
SELECT @AdHocSizeInMB = SUM(CAST((
CASE
WHEN usecounts = 1
AND LOWER(objtype) = 'adhoc'
THEN size_in_bytes
ELSE 0
END
) AS DECIMAL(14, 2))) / 1048576
,@TotalSizeInMB = SUM(CAST(size_in_bytes AS DECIMAL(14, 2))) / 1048576
FROM sys.dm_exec_cached_plans
SELECT 'SQL Server Configuration' AS GROUP_TYPE
,' Total cache plan size (MB): ' + cast(@TotalSizeInMB AS VARCHAR(max)) + '. Current memory occupied by adhoc plans only used once (MB):' + cast(@AdHocSizeInMB AS VARCHAR(max)) + '. Percentage of total cache plan occupied by adhoc plans only used once :' + cast(CAST((@AdHocSizeInMB / @TotalSizeInMB) * 100 AS DECIMAL(14, 2)) AS VARCHAR(max)) + '%' + ' ' AS COMMENTS
,' ' + CASE
WHEN @AdHocSizeInMB > 200
OR ((@AdHocSizeInMB / @TotalSizeInMB) * 100) > 25 -- 200MB or > 25%
THEN 'Switch on Optimize for ad hoc workloads as it will make a significant difference. Ref: http://sqlserverperformance.idera.com/memory/optimize-ad-hoc-workloads-option-sql-server-2008/. http://www.sqlskills.com/blogs/kimberly/post/procedure-cache-and-optimizing-for-adhoc-workloads.aspx'
ELSE 'Setting Optimize for ad hoc workloads will make little difference !!'
END + ' ' AS RECOMMENDATIONS
END
" Ad Hoc 워크로드 최적화 "옵션 을 켜면 실행 계획을 컴파일하고 동일한 데이터를 가져 오기 때문에 두 번째로 실행되는 임시 쿼리가 첫 번째 시간만큼 느려집니다 ( 캐시하지 않고) 처음 2 번.
큰 문제는 아니지만 쿼리를 테스트 할 때 알 수 있습니다.
이제이 옵션을 설정 하지 않고 1-Off Ad-Hoc 쿼리로 가득 찬 캐시를 사용 하지 않으면 어떻게됩니까 ?
이 최적화 기능이 도입되면서 캐싱 관리 알고리즘도 업데이트되었습니다.
Kimberly Tripp의 기사는 이 알고리즘 변경에 대한 Kalen Delaney의 게시물 도 참조 합니다.
그녀는 그것을 가장 잘 설명합니다.
변경 내용은 실제로 SQL Server에서 메모리 부족이 있음을 인식하는 계획 캐시 크기를 계산하여 캐시에서 계획을 제거하기 시작합니다. 제거 할 계획은 재사용되지 않은 저렴한 계획이며, 이것은 좋은 일입니다.
즉, 리소스를 확보해야 할 때 성가신 원 타이머 계획이 가장 먼저 진행됩니다.
" 왜 SQL 서버가 필요한 경우 사용되지 않는 계획을 제거 할을 담당 할 때 우리가 '임시 워크로드 최적화'해야합니까? "
정기적으로 비 매개 변수가 광고의 꽃잎을 생성하는 동적 SQL의의 톤이있는 경우 그 내 대답은이다 -질문이 있으면이 기능을 켜는 것이 좋습니다.
최대 캐시 메모리 공간을 사용한 후에는 캐시 된 계획 / 데이터를 강제로 제거하도록 시스템 리소스에 부담을주지 않기를 원합니다.
다음은 현재 캐시 한 Ad-Hoc Plan의 수와 그들이 차지하는 디스크 공간의 양을 보여주기 위해 작성한 쿼리입니다.
--Great query for making the argument to use "Optimize for Ad Hoc Workloads":
SELECT S.CacheType, S.Avg_Use, S.Avg_Multi_Use,
S.Total_Plan_3orMore_Use, S.Total_Plan_2_Use, S.Total_Plan_1_Use, S.Total_Plan,
CAST( (S.Total_Plan_1_Use * 1.0 / S.Total_Plan) as Decimal(18,2) )[Pct_Plan_1_Use],
S.Total_MB_1_Use, S.Total_MB,
CAST( (S.Total_MB_1_Use * 1.0 / S.Total_MB ) as Decimal(18,2) )[Pct_MB_1_Use]
FROM
(
SELECT CP.objtype[CacheType],
COUNT(*)[Total_Plan],
SUM(CASE WHEN CP.usecounts > 2 THEN 1 ELSE 0 END)[Total_Plan_3orMore_Use],
SUM(CASE WHEN CP.usecounts = 2 THEN 1 ELSE 0 END)[Total_Plan_2_Use],
SUM(CASE WHEN CP.usecounts = 1 THEN 1 ELSE 0 END)[Total_Plan_1_Use],
CAST((SUM(CP.size_in_bytes * 1.0) / 1024 / 1024) as Decimal(12,2) )[Total_MB],
CAST((SUM(CASE WHEN CP.usecounts = 1 THEN (CP.size_in_bytes * 1.0) ELSE 0 END)
/ 1024 / 1024) as Decimal(18,2) )[Total_MB_1_Use],
CAST(AVG(CP.usecounts * 1.0) as Decimal(12,2))[Avg_Use],
CAST(AVG(CASE WHEN CP.usecounts > 1 THEN (CP.usecounts * 1.0)
ELSE NULL END) as Decimal(12,2))[Avg_Multi_Use]
FROM sys.dm_exec_cached_plans as CP
GROUP BY CP.objtype
) AS S
ORDER BY S.CacheType
결과 :
" X MB가있는 경우 " 또는 " Ad Hoc의 X %가 일회용 인 경우 " 라고 말하지 않겠 습니다.
Sprocs, Triggers, Views 또는 Parameterized / Prepared SQL에는 영향을 미치지 않으며 Ad-Hoc 쿼리에만 영향을줍니다.
내 개인적인 권장 사항은 Prod Environment에서 켜는 것이지만 Dev Environment에서 끄는 것을 고려하십시오.
나는이 말을 단지 당신이 분 실행 이상 소요 쿼리를 최적화하는 경우, 당신은 당신이 그것을 캐시와 함께 갈 것입니다 얼마나 빨리 볼 수 있습니다 전에 3 번을 실행하지 않기 때문에, 개발을위한 - 모든 한 번만 편집하면 최상의 최적화 디자인을 찾을 수 있습니다.
하루 종일이 작업을 수행하지 않으면 업무에 방해가되지 않도록 DBA에 요청하십시오.
"사용하지 말아야하는 이유는 ..."입니다. 일부 성능 조사 과정에서 계획을 실시간으로 계획 캐시에서 거의 가져 오면서 리소스 사용률을 관찰하는 것이 매우 유용 할 수 있습니다. 캐시 작업시 adhoc 스텁 계획이 계획을 반환하지 않기 때문에 "adhoc 워크로드 최적화"로 인해 중단 될 수 있습니다. 이와 같은 경우 쿼리 및 계획을 식별 할 수없는 경우 조사를 위해 설정을 껐다가 다시 켤 수 있습니다. 설정 변경 사항은 그 시점부터 컴파일 된 쿼리에 영향을줍니다. 또한 'server'특성을 변경할 때마다 동일한 버전에서 비 Prod 인스턴스를 확인하여 변경 사항이 계획 캐시를 플러시하는지 여부를 확인하십시오. 나는 개인적으로 그 사실에 놀라지 않습니다. 예를 들어 서버 수준에서 maxdop를 변경하면 일반적으로 계획 캐시가 플러시됩니다.
"컴파일 된 계획 스텁에는 이와 연관된 실행 계획이 없으며 계획 핸들을 쿼리해도 XML 실행 계획이 반환되지 않습니다." http://technet.microsoft.com/en-us/library/cc645587.aspx