Cardinality Feedback 개념
cardinality feedback(이후 CF)도 이와 비슷한 개념이다. 예를 들어 col1 = ‘1’ 이라는 조건으로 filter되면 백만 건이 return된다고 옵티마이져가 예측해서 full table scan을 했다. 하지만 예측과 달리 실행결과가 100건이 나왔다면? 해당 SQL을 다시 실행할 때는 full table scan보다는 index scan이 유리할 것이다. 그런데 같은 SQL을 두 번째 실행할 때 "실제로는 백만 건이 아니라 100건 뿐이야"라는 정보를 옵티마이져에게 알려주는 전달자가 필요하다. 그 전달자가 바로 CF이다. CF가 없으면 결과가 100건 임에도 SQL을 실행 할 때마다 full table scan을 반복할 것이다. 결국 CF는 악성 실행계획을 올바로 수정하는 것이 목적이며 매우 유용한 기능임을 알 수 있다. CF의 단점은 최초에 한번은 full table scan이 필요하다는 것이다. 왜냐하면 실행해서 결과가 나와야만 실제 분포도(건수)를 알 수 있기 때문이다.
CF는 실행순서
CF는 같은 SQL을 두 번 이상 실행했을 때 적용된다. 그 이유는 아래의 CF 적용순서를 보면 알 수 있다.
1. 최초의 실행계획을 작성할 때(Hard Parsing 시에) 예측 분포도가 계산된다.
2. SQL이 실행된다. 한번은 실행 해봐야 예측 분포도와 실제 분포도를 비교할 수 있다.
3. 예측 분포도와 실제 분포도의 값이 차이가 크다면 실제 분포도를 저장한다.
4. 두 번째 실행될 때 CF에 의해 힌트의 형태로 옵티마이져에게 전달되어 실제 분포도가 적용된다. 이때 분포도뿐만 아니라 실행계획이 바뀔 수 있다. 두 번째 이후로 실행될 때는 CF가 계속 적용된다.
CF를 발생 시키는 방법
ALTER SYSTEM FLUSH SHARED_POOL;
ALTER SESSION SET "_OPTIMIZER_USE_FEEDBACK" = TRUE; -- CF를 활성화 한다. default로 true이다.
즉, 결과 집합이 비용 기반 최적화 프로세스 결과에 따른 예측과 다르면 cf는 부모 커서를 마크할 수 있다. 부모 커서가 이런 방식으로 마크되면 다음 번 파싱 때 하드 파싱을 수행 해서 다른 실행계획을 작성하고 새로운 자식 커서가 생성돼서 예전 부모 밑으로 이동한다.
부모 커서는 아래와 같은 2가지 모드로 마크될 수 있다.
1. bind sesitive - 더 나은 실행계획이 있는 지 찾기 위해서 옵티마이저가 커서를 재 파싱(하드 파싱)하기를 원할 때 마크 모드
2. bind aware - 선택도 때문에 한 개 이상의 커서(자식 커서)가 생기면 해당 마커는 바인드 집합 정보와 짝을 이룬다.
부모 커서가 "bind aware"로 마크된 후 해당 sql문의 다음 파싱은 더 이상 전통적인 소프트 파싱이 아니다.
이제 옵티마이저가 존재하는 실행계획/자식 커서 쌍들 중에서 어떤 것이 바인드 선택도에 최선인지 결정해야 한다. 이것은 하드 구문 분석이 아니다. 그렇다고 소프트구무 분석도 아니다. 일종의 하더 소프트 파싱 이다.
각 커서에 대해서 주어진 바인드 정보를 검사하고 존재하는 자식/실행계획 중에서 어던것이 재 사용되어야 하는지 결정한다.
그래서 하더 소프트 파싱으로, 최초 파싱 시에 바인드 변수를 들여댜 볼 뿐만 아니라 알려진 SQL문이 파싱 프로세스에 들어 올때마다 바인드 변수를 들여다 본다.("Bind Peeking") 물론 라이브러리 캐시에 이미 존재하는 커서와비교하는 것과 바인드 변수를 들여다 보는 것 모두 자원을 소비한다.
참고 : https://scidb.tistory.com/entry/Cardinality-Feedback%EC%9D%B4-%EC%9C%84%ED%97%98%ED%95%A0%EB%95%8C
Cardinality Feedback이 위험할 때
부제: Cardinality Feed Back의 개념과 사용예제 이번 글은 난이도가 높으므로 익숙하지 않은 사람은 Cardinality Feedback의 개념 정도만 이해하기 바란다. 물론 이 블로그를 꾸준히 구독한 독자라면 어려
scidb.tistory.com