• 쿼리 옵티마이저는 SQL 구문의 성능을 직접적으로 책임지고 있다.
• 쿼리 옵티마이저의 구성은 여러 초기화 파라미터 뿐만 아니라 시스템 통계 및 오브젝트 통계로 이루어져 있다.

쿼리 옵티마이저를 구성할 것인가, 말 것인가?

• 각각의 어플리케이션은 저마다의 요구사항과 워크로드 특성을 갖는다.
• 각각의 시스템은 서로 다른 하드웨어와 소프트웨어로 구성되어 있기 때문에 고유의 특성을 갖는다.
• 쿼리 옵티마이저가 잘 작동한다는 것은 대부분의 SQL 구문에 대해 훌룡한 실행 계획이 생성된다는 것을 의미한다.
• 하지만 이는 쿼리 옵티마이저의 구성이 올바르게 되어있으며 데이터베이스가 옵티마이저의 모든 기능을 활용할 수 있도록 설계되어 있어야 한다는 조건에 부합할 경우에만 그러하다.

구성 로드맵

1. 언제나 두 개의 초기화 파라미터, OPTIMIZER_MODE와 DB_FILE_MULTIBLOCK_READ_COUNT는 조정해야 한다.
2. 이 단계에서 조정할 초기화 파라미터는 기본값으로도 양호하기 때문에 이 단계는 선택사항이다.
3. 시스템 통계와 오브젝트 통계는 쿼리 옵티마이저에게 중요한 정보를 제공하기 때문에 반드시 수집해야 한다.
4. WORKAREA_SIZE_POLICY 초기화 파라미터를 설정하야 메모리에 데이터를 저장하는 오퍼레이션이 사용할 작업 영역의 크기를 수동으로 설정할지 자동으로 설정할지 선택할 수 있다.
5. 작업 영역의 크기가 자동일 경우, PGG_AGGREGATE_TARGERT 초기화 파라미터를 설정한다.
6. 작업 영역의 크기가 수동인 경우, 실제 크기는 메모리를 사용하는 오퍼레이션 유형에 따라 달라진다.
7. 구성의 첫번째 부분이 준비가 되면 애플리케이션을 테스트한다. 테스트가 실시하는 동안 요구된 성능을 제공하지 못하는 컴포넌트에 대해 실행 계획을 수집한다. 이렇게 수집된 실행 계획을 분서하여 문제가 무엇인지 추론할 수 있어야 한다.
8. 대부분의 SQL 구문에 대해 쿼리 옵티마이저가 효과적인 실행 계획을 생성한다면 구성이 훌룡하다고 볼 수 있다.
9. 쿼리 옵티마이저가 인덱스를 너무 많이 혹은 너무 적게 사용하는 경향이 이거나 네스티드 루프 조인을 선호한다면 이 문제를 해경하기 위해 일반적으로 OPTIMIZER_INDEX_CACHING 및 OPTIMIZE_INDEX_COST_ADJ 초기화 파라미터를 조정해 볼 수 있다.