일부 저장 프로 시저를 최적화하는 동안 DBA와 함께 앉아서 높은 차단 및 / 또는 읽기 / 쓰기 작업을 수행하는 일부 저장 프로 시저를 살펴 보았습니다.
DBA가 언급 한 한 가지는 TABLE재 컴파일을 피하기 위해 저장 프로 시저의 맨 위에 모든 변수 (특히 변수)를 선언해야한다는 것입니다.
이것은 내가 처음들은 것이며 우리가 가진 모든 다른 저장 프로 시저를 다시 방문하기 전에 확인을 찾고있었습니다. 그는 이것을 "코드의 최신보기"라고 부르고 있으며, 재 컴파일은 차단을 설명하는 스키마를 잠그고 있었다.
모든 변수 선언을 저장 프로 시저의 맨 위로 이동하면 재 컴파일이 줄어 듭니까?
답변:
아니.
이것은 예전에는 사실이었고 (더 이상 SQL Server 2000 이후로는 아니 었습니다), 사실이 아니었고 DBA는 그의 제안을 다음 과 혼동했습니다 .
스토어드 프로 시저 시작시 임시 테이블에 대한 모든 DDL 문 (인덱스 작성과 같은)을 그룹화하는 것이 중요합니다. 이러한 DDL 문을 함께 배치하면 스키마 변경으로 인한 불필요한 컴파일을 피할 수 있습니다.
이 페이지 에서이 권장 사항 에 대한 추론에 대한 다른 설명을 찾을 수 있습니다 .
이 Microsoft KB를 살펴보면 저장 프로 시저 재 컴파일의 원인이 다음 중 하나 일 수 있습니다 (SQL Server 2005+).
- 스키마가 변경되었습니다.
- 통계가 변경되었습니다.
- DNR을 다시 컴파일하십시오.
- 설정 옵션이 변경되었습니다.
- 임시 테이블이 변경되었습니다.
- 원격 행 집합이 변경되었습니다.
- 찾아보기 파마에 대한 변경되었습니다.
- 쿼리 알림 환경이 변경되었습니다.
- MPI보기가 변경되었습니다.
- 커서 옵션이 변경되었습니다.
- 재 컴파일 옵션
변수를 선언하는 것은 DDL로 계산되지 않으므로 변수를 선언하면 (예 : 테이블 변수 @table_variable) 이러한 이벤트를 트리거 할 수 없습니다 . 변수 (테이블 변수조차도)는 T-SQL 프로그래밍 전용으로 사용되는 임시 개체입니다. 그렇기 때문에 테이블 변수에 통계 가 없고 트랜잭션에 의해 구속되지 않습니다 . 변수를 선언하면 (테이블 여부에 관계없이) proc recompile을 트리거 할 수 없습니다.
임시 테이블 (즉, 작성 #temp_table) 또는 인덱스를, 그러나, 인 데이터베이스의 물리적 정의에 영향을 DDL. 임시 테이블 및 인덱스는 통계 및 트랜잭션 제어가있는 "실제"개체이므로이를 만들면 위 목록에서 이벤트 1, 2 또는 5가 발생하여 proc 재 컴파일이 트리거 될 수 있습니다.
스택을 반 아래 또는 맨 위에 변수를 선언하기 위해 차이를 만들거나 컴파일 잠금을 줄이거 나 재 컴파일이 덜 발생하도록해서는 안됩니다. 가독성을 높이기 위해 맨 위에서이 작업을 수행합니다.
질문의 "내 DBA 사고는 무엇인가"부분에 도달하기 위해, 내가 생각해 낼 수있는 유일한 것은 (어떻게 되었는가에 대해 생각하고있는 Nick의 관점을 제외하고) 아마도 매개 변수 스니핑에 관한 이야기 일 것입니다. 간단한 대화 에서이 링크의 옵션 2 )
차단 정보-> 실제 차단이 표시되는 경우 DBA가 가장 많이 말하는 컴파일 잠금 경합 유형이 아닙니다. 저장 프로 시저 호출을 스키마 화하는 스키마가 아닌 스키마 한정 테이블이 아닌 이것에 영향을 미치는 특정 사항이 있다는 것은 사실이지만, 높은 읽기의 원인이 아니며 차단의 원인이 아닐 수도 있습니다. 이러한 컴파일 잠금을 피하기 위해 최선을 다해야합니다. 그러나 변수가 어디에 있는지 걱정하는 것보다 나머지 저장 프로 시저 코드를 더 중요한 작업으로 조정하고 최적화하는 방법을 살펴 보겠습니다. 여기에서 문제가 발생하지 않는지 확인하려면 컴파일 잠금을 식별하고 해결하는 방법을 읽을 수도 있습니다.
이전 / 이후 예제를 게시하면 DBA가 무엇을 주도하고 있는지 확인할 수 있습니다.