옵티마이저가 수행하는 최적화 작업이란 일종의 시뮬레이션 이며 시뮬레이션은 모형화에 들어가는 요소값들을 얼마나 정확하게 부여했는가에 대한 부분과
어떤 목표에 대한 시뮬레이션을 했느냐에 따라 그 결과가 크게 달라진다.
옵티마이저 모드의 종류
마라톤처럼 일부라도 먼저 통과하는 것을 목표로 하는 방법을 '초기결과 최적화(First_rows)' 라 부른다.
반대로 구보와 같이 전체가 모두 수행되는 것을 목표로 하는 방법을 '전체결과 최적화(All_rows)' 라 부른다.
육상 예선 경기에서 5위까지 결선에 진출한다면 해당 경기의 목표는 1위가 아닌 5위 안쪽이 될 것이다. 이와 매우 유사한 개념이 적용된 것이
FIRST_ROWS_n 으로 지정하는 방법이다. (커트라인에 따라 최적화의 목표가 달라지는 것)
비용기준 옵티마이저의 기본 모드는 ALL_ROWS로 지정된다. 그러나 현실적으로 FIRST_ROWS를 기본 모드로 하는 것이 옳다고 본다.
우리가 FIRST_ROWS로 지정했다고 해서 전체범위를 처리하지 않는 것은 아니며 모드에 따라서 항상 다른 실행계획이 나타나는 것은 더욱 아니다.
그러나 부분범위로 처리되길 원하는 SQL 이 만약 ALL_ROWS 모드로 최적화를 하게 되면 전체 결과를 최적화하는 방식의 실행계획이 나타나는 경우가
많다. 실전에서는 별 문제 없이 운영하던 시스템의 모드를 ALL_ROWS로 바꾸어 주었다가 심각한 수행속도의 저하가 나타나 낭패를 당하는 경우가 있다.
옵티마이저 모드의 결정 기준
OLTP형 시스템 중에서 'CHOOSE'모드가 있던 버전에 개발된 시스템으로 기존의 실행계획을 가능한 유지를 원한다면 : FIRST_ROWS
그렇지 않은 경우나 새로운 버전에서 개발된 시스템이라면 : FIRST_ROWS_n
OLAP형 업무처럼 배치처리 위주의 시스템 이라면 : ALL_ROWS
실행계획의 고정화
우리가 애써 이룩해 놓은 최적의 실행계획이 완벽하지도 않은 옵티마이저에 의해 나쁜 쪽으로 변경된다면 참으로 억울한 알이다.
여러 가지 힌트를 사용하고 강제적인 수단을 동원하여 겨우 우리가 원하는 최적의 실행계획으로 유도해 두었지만 이마저 통계정보의 변화에 따라 수시로
흔들린다면 난감한 노릇이 아닐 수 없다.
옵티마이저는 이러한 목적을 위하여 과거에 수립되었던 실행계획의 요약본을 저장하고 있다가 이것을 참조하여 실행계획을 수립하는 기능을 가지고 있다.
이것을 'Outline' 이라고 한다.
가장 바람직한 방법은 잘 정비된 옵티마이징 팩터와 적절한 SQL을 기반으로 대부분의 경우는 옵티마이저에게 맡기고, 특별히 문제가 있는 경우에
대해서만 Outline으로 통제하는 것이다. 이것이 가장 이상적인 최적화 전략이다.
'IT > DBMS 공통' 카테고리의 다른 글
Oracle DBLink 와 비슷한 MySQL FEDERATED ENGINE (0) | 2014.04.07 |
---|---|
Select 후 바로 Update Function (0) | 2014.03.18 |
옵티마이저 (0) | 2014.02.25 |
대용량 데이터베이스 솔루션 - 함수 기반 인덱스 (0) | 2014.02.18 |
대용량 데이터베이스 솔루션 - 인덱스의 유형과 특징 (0) | 2014.02.10 |