[ MS SQL.PLSQL - 실행계획 ]
± 실행계획의 재사용 : 실행계획들은 잠시동안 프로시저 캐시에 남는다. 같거나 다른 몇몇 사용자가 비슷한 배치(batch) 를 사용하면 관련된 엔진은 프로시저
캐시에서 실행계획과 일치하는 것을 우선 찾는다. 만약 존재하면 재사용되고, 없을 경우에는 SQL Server 는 batch 를 해서(Parse)하고
컴파일 할 것이다. ( 이 재사용으로 Parsing 등을 하지 않으므로 속도가 빠르게 된다. )
재사용 가능 쿼리 : 첫번째로, 두 번째 쿼리의 쿼리 텍스트는 캐시 내 실행계획에 의해 기술된 쿼리의 텍스트와 모든 것들이 완벽하게 동일해야 한다.
(공백, 줄바꿈, 들여쓰기)
두번째는 쿼리가 실행계획을 재 사용하기 위해 fully qualified database object 를 포함할 때이다.
Select *
From db_name.dbo.tbl_name
매개변수화된 쿼리들 : SQL Server 디자이너들은 저장 프로시저들로 쿼리를 재 사용하지 않도록 디자인된 저장 프로시저에 대해서 쿼들의 재 사용을
향상시키기 위해서 두 가지 방법이 존재
1. Autoparameterization : T-SQL 문장이 SQL Server 에 보내질 때 그것은 모든 상수가 매개변수로 대치될 수 있는지 여부를 결정하는 시도를 할 것이다.
같은 템플릿을 사용하는 연속되는 퀴리들은 동일한 실행계획을 다시 사용할 것이다.
Autoparameterization 을 하기 위해 네개의 템플릿 세트와 일치해야 한다.
SELECT { @ ¦ column-list ]
FROM tbl_name
WHERE column-expression
[ORDER BY column-list ]
INSERT tbl_name
VALUES ( { constant ¦ Null ¦ Default } [ , …. ] )
UPDATE tbl_name
SET column-name = constant
WHERE column-expression
DELETE tbl_name
WHERE column-expression
; Autoparameterization 이 사용될 때 쿼리를 포맷팅하는 것을 문제 삼지 않지만, 여전히 개체가 capitalization 에 있어서의 변경이나 qualified 되는
방법에 있어서 변경을 허용하지 않는다.
속도가 빠른이유 : 현재 버전의 SQL Server 쿼리 엔진은 쿼리나 SP를 프로세스하는 가장 최고를 선택하기 위한 수많은 새로운 프로세싱 기술들과
비교작업을 한다. 그러므로 SP를 재 컴파일하는데 필요한 시간은 이전보다 더욱 길어졌다.
± Lazywriter 프로세스가 하는 일 : 실행계획을 SP 캐시로부터 제거 한다. 다음과 같은 경우에…
1. 많은 데이터 수량의 변경시
2. 인덱스 생성 또는 삭제시
3. Constrainsts 가 추가 또는 변경시
4. 인덱스의 분산 통계들의 변화시
5. SP 또는 trigger 에서 재 컴파일하기 위해 명시적으로 SP_recompile 을 호출 하였을 때
* SP 의 소스코드 : syscomments system table 의 text 라는 필드에 저장 됨
type : varchar(8000) 이지만 smallint 로 선언될 때 저장 프로시저는 32k * 8,000 bytes = 약 250MB 이다.
* SP 캐시에서 내리기 : DBCC FREEPROCCACHE
SQL Server 를 재 작동
