Recompile 옵션과 함께 사용할시기에 대한 경험 규칙

Question

With Recompile 옵션은 최적화가 저장된 Procs에 대한 쿼리 계획을 재건하도록 강요하지만 언제 이런 일이 발생 하시겠습니까?

with Recompile 옵션을 사용하는시기와 언제 아닌시기에 대한 경험 규칙은 무엇입니까?

모든 Sproc에 넣는 것과 관련된 효과적인 오버 헤드는 무엇입니까?

Answer 1

다른 사람들이 말했듯이, 당신은 단순히 포함하고 싶지 않습니다. WITH RECOMPILE 습관의 문제로 저장된 모든 Proc에서. 그렇게함으로써 저장된 절차의 주요 이점 중 하나 인 쿼리 계획을 저장한다는 사실을 제거하게됩니다.

왜 그게 잠재적으로 큰 문제입니까? 쿼리 계획을 계산하는 것은 정기적 인 절차 코드를 컴파일하는 것보다 훨씬 집중적입니다. SQL 문의 구문은 만 지정하기 때문입니다 무엇 당신은 원하고 (일반적으로) 어떻게 이를 얻으려면 물리적 계획을 작성할 때 데이터베이스가 광범위한 유연성을 제공 할 수 있습니다 (즉, 실제로 데이터를 수집하고 수정하기위한 단계별 지침). 데이터베이스 쿼리 프리 프로세서가 할 수있는 "트릭"이 많이 있습니다. WHERE 조인 전후에 조항 등

간단한 선택 문의 경우 차이가 없지만 사소한 쿼리의 경우 데이터베이스는 최적의 계획을 세우기 위해 심각한 시간 (일반적인 마이크로 초과 달리 밀리 초로 측정)을 소비 할 것입니다. 정말 복잡한 쿼리의 경우 최적 계획, 그것은 단지 휴리스틱을 사용하여 꽤 좋아 계획. 따라서 매번 다시 컴파일하도록 강요함으로써, 이전 계획이 완벽하게 좋았더라도 그 과정을 계속해서 반복해야한다고 말합니다.

공급 업체에 따라 쿼리 계획을 다시 컴파일하기위한 자동 트리거가 있어야합니다. 예를 들어, 테이블의 통계가 크게 변경되면 (예를 들어, 특정 열의 값의 히스토그램이 시간이 지남에 따라 균등하게 분포되어 시작됩니다). DB는이를 알아 차리고 계획을 다시 컴파일해야합니다. 그러나 일반적으로, 데이터베이스의 구현자는 당신보다 그것에 대해 전체적으로 그것에 대해 더 똑똑 할 것입니다.

공연과 관련된 것과 마찬가지로 어둠 속에서 사진을 찍지 마십시오. 병목 현상이 90%의 성능 비용을 지불하는 위치를 파악하고 먼저 해결하십시오.

Answer 2

쿼리 계획을 컴파일하는 것은 비교적 비용이 많이 드는 작업이며 쿼리 계획이 캐시 및 재사용되는 혜택을 보지 못하기 때문에 모든 저장된 절차에 적용하는 것은 좋은 생각이 아닙니다.

저장된 절차 내부에 구축 된 절을 사용하여 처리 할 수있는 역동적 인 경우 sp_executesql 추가하지 않고 TSQL을 실행합니다 WITH RECOMPILE 저장된 절차에.

또 다른 솔루션 (SQL Server 2005 이후)은 OPTIMIZE FOR 힌트. 행의 값이 정적 인 경우 잘 작동합니다.

SQL Server 2008은 a 알려진 기능이 거의 없습니다 라고 불리는 "OPTIMIZE FOR UNKNOWN":

이 힌트는 쿼리 최적화기가 매개 변수 값이 쿼리에 전혀 전달되지 않은 경우 항상 사용한 표준 알고리즘을 사용하도록 지시합니다. 이 경우 Optimizer는 사용 가능한 모든 통계 데이터를 살펴보고 응용 프로그램에 의해 쿼리에 전달 된 특정 매개 변수 값을 보는 대신 쿼리 플랜을 생성하는 데 사용되는 로컬 변수의 값이 무엇인지 결정에 도달합니다.

Answer 3

가장 일반적인 용도는 절차에서 동적 인 위치가있을 때입니다. 특정 쿼리 계획이 다음에 똑같은 조항이 아닐 수도 있기 때문에 해당 특정 쿼리 계획이 컴파일되고 후속 실행을 위해 저장되기를 원하지 않을 것입니다. 절차가 호출됩니다.

Answer 4

일반적으로 훨씬 더 나은 대안입니다 WITH RECOMPILE ~이다 OPTION(RECOMPILE)아래의 설명에서 볼 수 있듯이 이 질문의 답변은 여기에 있습니다

매개 변수-민감도 문제가 발생하면 포럼 및 Q & A 사이트에 대한 일반적인 조언은 "Recompile 사용"(앞에서 제시된 다른 튜닝 옵션이 부적합하다고 가정)입니다. 불행히도, 그 조언은 종종 저장된 절차에 재 컴파일 옵션을 추가하는 것을 의미하는 것으로 잘못 해석됩니다.

다시 컴파일을 사용하면 효과적으로 우리를 SQL Server 2000 동작으로 반환합니다. 여기서 저장된 프로 시저는 모든 실행에 따라 재 컴파일됩니다. SQL Server 2005 이상에서 더 나은 대안은 매개 변수-스니핑 문제로 어려움을 겪는 명령문에 옵션 (Recompile) 쿼리 힌트를 사용하는 것입니다. 이 쿼리 힌트는 문제가있는 진술 만 재 컴파일됩니다. 저장된 절차 내의 다른 진술에 대한 실행 계획은 정상적으로 캐시되고 재사용됩니다.

Recompile과 함께 사용하면 저장된 절차에 대한 컴파일 된 계획이 캐시되지 않습니다. 결과적으로 sys.dm_exec_query_stats와 같은 DMV에서는 성능 정보가 유지되지 않습니다. 대신 쿼리 힌트를 사용한다는 것은 컴파일 된 계획을 캐시 할 수 있고 DMV에서 성능 정보를 사용할 수 있음을 의미합니다 (영향을받는 명령문에 대해서만 최신 실행으로 제한됨).

최소한 SQL Server 2008 Build 2746 (누적 업데이트 5가 포함 된 서비스 팩 1)을 실행하는 인스턴스의 경우 옵션 (Recompile)을 사용하여 Recompile과 함께 또 다른 중요한 이점이 있습니다.

Answer 5

구제 적 데이터로 테스트 할 때만 사용해야하며 컨텍스트는 잘못된 쿼리 계획 (가능한 이유가 무엇이든)를 생성한다는 것을 보여줍니다. SP가 올바르게 최적화되지 않는다고 미리 (테스트없이) 미리 가정하지 마십시오.

수동 호출에 대한 단독 예외 만 (즉, SP로 코딩하지 마십시오) : 대상 테이블의 문자를 실질적으로 변경했다는 것을 알고있을 때. 예를 들어 자르기, 벌크 하중 등

조기 최적화를위한 또 다른 기회입니다.

참고 : 포인트가 많습니다. Newby가 아래에 동일한 답변을 제출하고 동의하면 동의하는 경우, 그들의 동의하십시오.