들어가기 :
| Part 3 | - Search Type과 Iteration 개념,
- 많은 종류의 Cost Based Query Transformation에 대해 논의
| Part 4 | - CBQT 발생할 때 내부적으로 어떤일이 일어나는지
- Logical Optimizer의 최적화 전략은 무엇인지
- 어떤 메모리 공간을 사용하는지
- Library Cache에 변환된 쿼리들이 어떤 모습으로 저장 되는지
- Cost Based Query Transformation Unit간의 상호작용은 어떻게 발생하는지
- 내부적인 메모리 관리 방법은 무엇인지
|
4.1 Search Type의 개념과 종류
- serch type이란 변환 가능한 경우의 수를 어디까지 고려할 것인지의 정도를 나타낸다. Serch Type 개념과 2가지 종류(Exhaustive, Linear)(3.B,p226)
- 모든 종류의 CBQT에서 Search Type이 적용되므로 중요하다
ex)서브쿼리가 3개(SUBQ3,SUBQ2,SUBQ1)인 SQL이 변환이 가능한 모든 경우의 수
| (1,1,1) | 모든 서브쿼리가 Unnesting됨. |
| (1,1,0) | SUBQ1은 Unnesting 되지않고 SUBQ2, SUBQ3은 Unnesting됨. |
| (1,0,1) | SUBQ2는 Unnesting 되지 않고 SUBQ1,SUBQ3은 Unnesting됨. |
| (1,0,0) | SUBQ3만 Unnesting 되고 SUBQ1,SUBQ2은 Unnesting되지않음. |
| (0,1,1) | SUBQ3은 Unnesting 되지 않고 SUBQ1,SUBQ2는 Unnesting됨. |
| (0,1,0) | SUBQ2만 Unnesting 되고 SUBQ1,SUBQ3은 Unnesting되지않음. |
| (0,0,1) | SUBQ1만 Unnesting 되고 SUBQ2,SUBQ3은 Unnesting되지않음. |
| (0,0,0) | 모든 서브쿼리가 Unnesting 되지 않음. |
- 1은 Subquery Unnesting이 수행
- 0은 Subquery Unnesting이 미수행
※ 가장 위의 서브쿼리가 SUBQ1이며 가장 아래쪽의 서브쿼리가 SUBQ3일 경우 숫자표기법은 반대로 표시된다. 10053도 동일|
Serch Type의 네 가지 종류와 두가지 옵션
종류 : Exhaustive, Iterative, Linear, Two_pass
옵션 : on, off
※N : 서브쿼리 개수
| 1 | Exhaustive | 모든 경우의 수를 다 고려하여 가장 Cost가 저렴한 Plan을 선택한다.
이 Type의 Iteration 횟수는 2의 N승개이다. |
|---|
| 2 | Iterative | 2*n개 를 고려하게된다.
하지만 Iteration횟수는 N + 1이다. |
|---|
| 3 | Linear | N + 1가지의 경우를 고려한다.
실제로는 Iterative Type과 똑같이 2 * N 가지의 경우를 고려한다.자세한 설명은 4.5장서.. |
|---|
| 4 | Two_pass | 2가지의 경우만 고려한다. (All or Nothing) 다시말하면 (1,1,1)과 (0,0,0)의 Cost만을 비교하여 저렴한 것을 택하게 된다.
하지만 4.6장에서 보게 될 실제 예제에서는 (1,1,1)만 고려하게 된다.
이 Type은 Best Plan을 차지 못할 확률이 매우 높으며 Logical Optimizer의 운신?의 폭을 제한하기 때문에 권장되지 않는다. | 5 | On | 상황에 따라 가장 적당한 것을 골라서 사용하게 된다.
위험하다 |
|---|
| 6 | Off | CBQT를 제거한다는 의미이다.
6가지의 유효한 값 중에 가장 권장되지 않는 값이다. |
|---|
Default Search Type은 Linear이다.
- _Optimizer_cost_based_transformation 파라미터의 Default 값은 Linear이다.
Search Type은 변한다.
- _optimizer_cost_based_transformation 파라미터에 특정한 값을 저정한다고 해도 효율성 때문에 상황에 따라 Search Type은 동적으로 변한다.(Off제외)
ex. 서브쿼리가 2개뿐이라면 모든 경우의 수는 네가지 밖에 안된다. 이경우는 Exhaustive Type을 선택한다고 해도 Hard Parsing시의 부하가 크지 않을 것이다. 하지만 서브쿼리가 7개나 되는 경우라면
128(2의7승)가지의 경우를 고려해야 한다. 이때 Logical Optimizer가 Exhaustive Type을 계속 고집한다면 Hard Parsing시의 부하는 상당 할 것이다. - 동적 Search Type에 대한 예제는 4.4장과 4.5장과 4.8장에..