커서_SHARING, Bind Variable Peeeking 및 히스토그램 간의 관계

커서_SHARING, Bind Variable Peeeking 및 히스토그램 간의 관계

대부분의 소스에서 다루는 항목이 다르기 때문에 커서_SHARING, 바인딩 변수, 바인딩 변수 피킹 및 히스토그램의 관계에 대해 잘 이해하고 있는지 확인하려고 합니다.

좋아요, 지금까지 제가 수집한 내용입니다. 제가 틀린 부분이 있으면 언제든지 수정해주세요.

커서_공유

1. = EXCT(기본값)

1.1. SQL 문에서 리터럴을 사용하는 경우: 옵티마이저는 리터럴의 모든 조합에 대해 새로운 실행 계획을 생성합니다. 옵티마이저는 리터럴을 바인딩으로 대체하지 않습니다.모든 리터럴 조합에 대해 새 상위 커서가 생성됩니다.

문에서 바인딩 하는 경우:될 때 는 바인딩 실행 값을 사용합니다. 이후 변수가 있는 1.2. SQL에서 바인딩 변수를 사용하는 경우: 문이 처음 실행될 때 최적화자는 바인딩 변수의 값을 엿보고 특정 값을 사용하여 실행 계획을 생성합니다. 이 바인딩 변수가 있는 모든 향후 문에서는 동일한 계획을 사용합니다(계획이 바인딩 변수의 다른 값에 대해 최적이 아닐 경우에도).

2. = 포스

.1. optimizer 는 1.2 합니다와

3. = 유사

3.1. 히스토그램 없음: optimizer가 모든 리터럴을 바인딩으로 대체함 -> 최종 효과는 1.2 및 2.1과 동일함

리터럴을 이 실행될 번째 하는 것이 아니라)더 계획이 ).3.2 히스토그램으로: optmizer는 모든 리터럴을 바인딩으로 대체하지만 문장이 실행될 때마다(첫 번째 실행 때만 사용하는 것이 아니라) 바인딩 변수를 엿보고 해당 바인딩 변수의 특정 값에 대한 보다 최적 실행 계획이 있는지 확인합니다(히스토그램 통계를 기반으로 함).따라서 옵티마이저에서 발견하는 바인딩 변수의 모든 고유 값에 대해 새 하위 커서가 효과적으로 생성됩니다.

질문:

1. 제가 알기로는 CUSOR_SHARING = EXCT + bind-variables (1.2)로 SQL 문을 작성하면 CUSER_SHARING = FORCE (2.1)을 설정하는 것과 정확히 같은 결과가 나오지 않나요?두 경우 모두 옵티마이저는 실행 계획을 생성하기 위해 첫 번째 실행 시에는 바인딩 변수만 엿보고 이후 실행 시에는 바인딩 변수의 값에 상관없이 해당 계획을 다시 사용합니다.그렇다면 대부분의 출처에서 바인딩 변수를 사용할 것을 권장하는 이유는 무엇입니까?이는 성능에 상당한 영향을 미칠 수 있을 것으로 보입니다.

2. 초기 바인딩 변수 peek에서 히스토그램이 1.2와 2.1에 사용됩니까?와 같이 SQL 문이 실행되고 최적화 도구가 바인딩 변수를 처음 볼 때 히스토그램(있는 경우)을 사용하여 전체 테이블 스캔 또는 인덱스 스캔이 사용되는지 여부를 확인합니까?"Oracle Database 11g, Performance Tuning Recipes"(오라클 데이터베이스 11g, 성능 튜닝 레시피)는 히스토그램이 CURRS_SHARING = SIMILARE(커서_SHARING)일 때만 관련된 것으로 보이지만, 일부 다른 소스에서는 히스토그램이 다른 모든 CURRS_SHARING 설정에서도 사용되는 것으로 나타납니다.

3. 사례 1.1의 경우, 최적화 도구는 히스토그램을 사용하여 최적 실행 계획을 결정합니까?기본적으로 히스토그램이 언제 사용되는지 알고 싶습니다.CURRS_SHARING = SIMILER_SHARING 다른 CURRS_SHARING 설정이 양호한 경우에만 해당합니까?

4. 적응형 커서 공유 - 이 기능은 바인딩 변수(사용자 쿼리 또는 문자 그대로 대체를 통해 시스템에서 생성됨)가 있는 경우에만 수행됩니다.따라서 1.2, 2.1, 3.1 및 3.2에서만 발생합니다. 그러나 유사성이 감가상각되었기 때문에 이것은 ACS가 1.2 및 2.1에서만 발생한다는 것을 의미합니까?

제가 지금 베이스에서 너무 멀리 떨어져 있지 않기를 바라지만 제가 실수를 했다면 수정해주세요.

감사합니다!

편집자 : BYS2 2011년 12월 20일 오후 12:11

1. (a) FORCE를 사용하는 것과 (b) EXCT와 바인딩 변수를 직접 코딩하는 것의 차이점은 후자의 경우 바인딩 변수를 사용할 때 제어한다는 것입니다.따라서 특정한 경우 바인딩 변수가 성능을 저하시키거나 필요하지 않은 경우 해당 쿼리를 변경할 수 있습니다.포스가 있으면, 당신은 꼼짝 못합니다.OLTP 유형 쿼리에 대해 바인딩 변수를 권장하는 이유는 구문 분석이 큰 병목 현상이 될 수 있는 매우 직렬화된 프로세스이기 때문입니다.OLTP 시스템에서는 항상 동일한 실행 계획을 사용해야 하는 많은 쿼리가 다른 값으로 실행되는 경향이 있으므로 항상 이를 다시 구문 분석하는 것은 낭비입니다.또한 바인딩 변수를 사용하지 않는 경우도 고려할 것을 권장합니다. 예를 들어 쿼리의 특정 위치에 나타날 수 있는 가능한 값이 몇 개밖에 없는데, 이러한 값 중 하나 이상이 다른 실행 계획의 이점을 얻을 수 있다면,각 변형을 한 번 구문 분석한 다음 캐시된 계획을 다시 사용할 수 있으므로 리터럴을 사용하는 것이 전반적으로 더 나을 수 있습니다.

바인딩 변수를 사용할 경우 SQL 주입에 대한 개방도가 낮아진다는 점도 장점입니다.

2 & 3. 히스토그램은 쿼리 실행 계획을 작성할 때 일반적으로 사용되며 명백한 것보다 더 많은 방법으로 사용됩니다.예, EXCT 설정이 있는 표준 바인딩 변수 peek의 경우 히스토그램이 실행 계획을 결정할 때 최적화 도구에 의해 사용됩니다.이것은 좋은 것일 수도 있고 나쁜 것일 수도 있는데, 이것은 스큐와 바인딩에 대한 특정 가치에 따라 달라질 수 있습니다.소스에서 히스토그램과 유사한 설정에 대해 설명하고 있는 점은 이 경우 히스토그램이 있으면 새 실행 계획이 생성되는 트리거 중 하나라는 것입니다.

(Hostogram의 사용 시기와 사용 방법에 대해 원하는 모든 정보를 보려면 Jonathan Lewis의 "비용 기반 Oracle Fundamentals"를 적극 권장합니다.)

4.. Adaptive Cursor Sharing은 기본적으로 이전에 CURRS_SHARING=MILARE을 위해 구현된 로직의 향상된 버전이라고 생각합니다.최적화자는 모든 상황에서 바인딩 변수 훔쳐보기를 기반으로 새 계획을 작성하는 것을 고려합니다.SIMIL은 여전히 옵션으로 존재하는 것으로 보입니다.이 게시물은 유용한 정보를 제공할 수 있습니다.

언급URL : https://stackoverflow.com/questions/8581413/relationship-between-cursor-sharing-bind-variable-peeking-and-histograms