CLASS

SPM(SQL PLAN MANAGEMENT) 사용 방법 #1

일반태그: Technical Architecture.DB태그: SQL. 1 Comment 2015년 1월 8일 731 (3)

이번 칼럼은 11g에서 새롭게 소개된 SPM(SQL PLAN MANAGEMENT) 사용 방법 사용 방법에 대해 알아보고자 합니다.

 

SPM(SQL PLAN MANAGEMENT) 이란?

 SPM은 baseline(Plan과 Hint)를 DB내에 저장 해 놓고 검증된 실행계획만 사용할 수 있도록 하는 기능이며, 통계정보 변경이나 application의 수정, DB version upgrade 등으로부터의 영향을 최소화 하는데 그 목적이 있습니다. SQL_PROFILE은 한 Category의 특정 SQL에 대해 오직 하나의 Plan만 저장할 수 있기 때문에, 다른 Plan을 적용시키기 위해서는 Category를 변경하여 저장하거나 새로운 Plan을 Stored Outline으로 저장해야 합니다. 하지만 SPM은 특정 SQL에 여러개의 Plan을 관리할 수 있으며, 그 중 필요한 Plan을 사용할 수 있기 때문에 보다 공격적인 Plan Fix 방법론이라 할 수 있습니다.

 

 
SPM과 SQL_PROFILE 차이점은?
 
SPM과 SQL Profile 모두 검증된 실행계획을 사용하는데는 비슷하나, 아래와 같은 차이점이 있습니다.
SQL PLAN MANAGEMENT  SQL PROFLIE
*. Execution Plan의 변경으로 발생될지 모르는 성능저하를 예방하기 위한 사전 예방적인 방식이다.(Preventative Mechanism)  

*. Plan Hit가 저장되고 Plan History가 관리된다.

*. 저장된 Plan Hit대로 수행되므로 외부적인 환경변화가 있더라도 Plan은 변경되지 않는다.

*. SQL Plan의 이력 관리가 됨.

*. SQL Baseline에 검증된 Plan이 여러 개 존재할 수 있고 실행계획은 그 중에서 선택되어진다.

*. Plan을 검증하는 기능이 있어 기존의 Plan대비 어느 정도의 Cost와 성능 향상이 기대되는지를 분석할 수 있다. 따라서 분석 결과에 따라 특정 Plan을 버릴 수도 있고 Plan으로 채택되지 않게 설정을 변경할 수도 있다.

*. High-Loaded SQL의 Plan을 Tuning 한 결과로 생성되므로 사후 조치적인 방식이다.(Reactive Mechanism).  

*. SQL이 잘 수행될 수 있도록 일반적인 통계정보 이외의 부가 정보를 Dictionary에 저장한다. Plan Hit가 저장되지 않음.

*. SQL Profile이 생성되어 있더라도 외부적인 환경변화로 인해 SQL Plan이 변경될 수 있다.

*. SQL Plan의 이력관리가 안 됨.

*. 한 Category의 특정 SQL에 대해 오직 하나의 Plan만 저장할 수 있기 때문에 다른 Plan을 적응시키기 위해서는 Category를 변경하여 저장하거나 새로운 Plan을 Stored Outline으로 저장해야 한다

 

SPM 사용 예제

 1. 테스트 DB 버전 확인
테스트는 Oracle 11g이며, 버전은 11.2.0.3 입니다.

2. 테스트 테이블, 인덱스, 통계정보 생성

테스트로 많이 사용되는 EMP, DEPT 테이블을 생성하고, 통계정보를 만들었습니다.

3. Format 세팅

SQL-PLUS에서 테스트를 진행하기 때문에 출력 포멧을 지정합니다.

4. 테스트 DB에서 SQL_PLAN_BASELINES 파라미터 확인

SPM에서 사용되는 2개 hidden parameters는 위와 같이 2개이며, 그 기능은 아래와 같습니다.

- optimizer_capture_sql_plan_baselines : SPB를 통해 실행계획을 자동으로 캡쳐하도록 활성화하는 파라미터
- optimizer_use_sql_plan_baselines : SPB를 사용토록 활성화하는 파라미터

5. 세션 레벨에서 SPB 관련 파라미터 값 변경

여기서 자동 캡쳐 기능을 테스트하기 위해 OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES 값을 TRUE로 변경하겠습니다.

6. SQL을 직접 수행하여 SPB 등록

DEPT 테이블에 DEPTNO 컬럼으로 구성된 인덱스가 있어서 INDEX RANGE SCAN 실행계획이 나오겠지만, FULL SCAN을 유도하기 위해 세션레벨로 OPTIMIZER_INDEX_COST_ADJ 파라미터값을 변경해 보겠습니다. 이 파라미터는 값이 높을수록 FULL SCAN을 선호하고, 낮을수록 인덱스 사용을 선호합니다.

참고로 SPM은 1회 수행된 SQL은 SPB에 캡쳐가 안되고, 2회 이상부터 캡쳐가 됩니다.

7. 동일 SQL 재수행

한번 더 수행하고 DBA_SQL_PLAN_BASELINES 뷰에서 SPM을 확인한 결과 해당 SQL이 등록된 걸 확인할 수 있으며, 그 의미는 아래와 같습니다.

- SQL_HANDLE : SQL_ID에 대한 SPB 대표이름
- PLAN_NAME : SQL_HANDLE에 종속된 Plan 이름
- ORIGIN : SPB 등록 방식(AUTO-CAPTURE 또는 MANUAL)
- ACCEPT : PLAN_NAME 중 ACCEPT가 YES인 경우에만 SPB로 사용됨
- FIXED : SQL_HANDLE 내에 여러 PLAN_NAME이 있을 경우 FIXED가 YES인 PLAN_NAME만 사용됨

8. 동일 SQL에 대해 새로운 PLAN_NAME 등록

TABLE FULL SCAN 실행계획이 등록되어 있으므로, 이제는 INDEX RANGE SCAN 실행계획을 등록해 보겠습니다. 동일한 방법으로 OPTIMIZER_INDEX_COST_ADJ 파라미터 값을 300에서 1로 다시 설정해서 인덱스를 사용하도록 유도합니다. 참고로 OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES, OPTIMIZER_USE_SQL_PLAN_BASELINES 2개 파라미터 중 하나라도 TURE일 경우 새로운 PLAN_NAME 등록됩니다.

9. SPB 확인

SQL_TEXT로 확인한 결과, SQL_5009a0e70c6d5325 SQL_HANDLE 값이 동일한것이 2개 있고, SQL_PLAN_502d0ww66unt59995a0e9 값이 서로 다른 PLAN_NAME이 등록되었습니다.

10. XPLAN으로 SPB 확인

XPLAN에서도 확인해보면, 더욱 확실히 알 수 있는데, SQL_PLAN_502d0ww66unt59995a0e9 값은 INDEX SCAN 플랜이고,  SQL_PLAN_502d0ww66unt5c392520a  값은 FULL SCAN 플랜입니다.

11. 새로운 PLAN_NAME은 등록되나, 기존에 등록된 PLAN_NAME과 실행계획 동일할 경우 재 등록되지 않음

12. ACCEPT PLAN_NAME 사용 확인

이제 SPM이 잘 작동하는지 확인해 보기 위해, OPTIMIZER_INDEX_COST_ADJ 값을 1로 주어 인덱스를 사용하는지 살펴본 결과 SQL_PLAN_502d0ww66unt5c392520a PLAN_NAME의 ACCEPT 값이 YES이기 때문에 FULL SCAN을 하는 것을 알 수 있으며, 잘 작동하는지 알 수 있습니다.

 13. DBMS_SPM 패키지를 통해 등록된 PLAN_NAME 성능 비교
SPM에는 등록된 SQL_HANDLE 간의 실행계획 성능을 비교할 수 있는 패키지가 있으며, 이를 통해 어느 PLAN_NAME이 더 우수한지 평가할 수 있습니다. DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE 펑션을 통해, SQL_HANDLE에 있는 PLAN_NAME을 비교할 수 있으며, 위의 결과에서는 인덱스를 사용하는 SQL_5009a0e70c6d5325 PLAN_NAME이 FULL SCAN하는 SQL_PLAN_502d0ww66unt5c392520a 보다 더 좋은것으로 평가되었습니다. 재미있는 것은 이 평가로 인해 인덱스를 사용하는 SQL_PLAN_502d0ww66unt59995a0e9 PLAN_NAME의 ACCEPT 값이 NO에서 YES로 변경되는 것을 알 수 있습니다.

 14. 2개 PLAN_NAME의 ACCEPT 값이 모두 YES일 경우
만약 PLAN_NAME의 ACCEPT 값이모두 YES일 경우, 기존의 옵티마이저 Cost에 따라 Plan 결정됩니다.

 15. PLAN_NAME 중 하나를 FIXED 설정
위에서 본 것처럼 ACCEPT 값이 모두 YES일 경우 임의로 선택당할 수 있기 때문에, 만약 원하는 PLAN_NAME이 있을 경우 보다 강력히 적용시키기 위해 FIXED 값을 변경할 수 있습니다. DBMS_SPM.ALTER_SQL_PLAN_BASELINE 펑션을 통해 FULL SCAN 하는 SQL_PLAN_502d0ww66unt5c392520a PLAN_NAME을 FIXED 하도록 수행하였으며, 이로인해  OPTIMIZER_INDEX_COST_ADJ 값을 1로 주어 인덱스 사용을 유도하여도 FULL SCAN하는 SQL_PLAN_502d0ww66unt5c392520a PLAN_NAME 사용하는 것을 알 수 있습니다.

 16. 양쪽 모두 FIXED 값을 YES로 할 경우
만약 모두 FIXED일 경우 ACCEPT 값이 모두 YES인 경우와 동일하게 옵티마이저 Cost에 의해 Plan 선택됩니다.

 17. 인덱스 사용하는 PLAN_NAME 삭제 후, FIXED 설정된 SQL_HANDLE에 추가로 PLAN_NAME이 등록되는지 확인
인덱스를 사용하는 PLAN_NAME 삭제 후, FIXED 설정된 SQL_HANDLE에 추가로 PLAN_NAME이 등록되는지 확인해 본 결과, 새로운 PLAN_NAME 추가되지 않는 걸 알 수 있습니다.

18. AUTO-CAPTURE가 아닌 MANUAL로 SPB 등록

이번에는  AUTO-CAPTURE가 아닌 MANUAL로 SPB를 등록해 보겠습니다. MANUAL 등록 시, 해당 PLAN의 SQL_ID, PLAN_HASH_VALUE 값을 이용하여 MANUAL하게 SPB 등록할 수 있습니다.

19. FIXED를 NO로 변경할 경우 새로운 PLAN_NAME 등록되는지 테스트
이번에는 FIXED 값을 NO로 변경할 경우 새로운 플랜이 등록되는지 확인하는 내용이며,  SQL_PLAN_502d0ww66unt5c392520a PLAN_NAME의 FIXED를 NO로 하고, OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES 파라미터를 활성화 했기 때문에 새로운 PLAN_NAME 등록됩니다.

20. ACCEPT 값이 NO이고 FIXED만 YES일 경우 Plan이 선택되는지 확인

만약 ACCEPT 값이 NO이고 FIXED만 YES일 경우 어떤 Plan이 선택되는지 확인한 결과,  FULL SCAN을 하는 SQL_PLAN_502d0ww66unt5c392520a 사용하는 것을 알 수 있으며 그 이유는, SQL_PLAN_502d0ww66unt59995a0e9 PLAN_NAME의 FIXED가 YES여도 ACCEPT값이 NO이기 때문에 선택이 되지 않는 걸 알 수 있습니다.

 
 
 
 
이상으로 SPM에 대한 간략한 테스트를 마쳤습니다. 다음 시간에는 SPM을 Export/Import 하는 기능과 Shared Pool에서 SPB를 등록하는 상세 방법에 대해 소개하도록 하겠습니다. 내용을 보고 궁금한 점 있으면 리플을 달아주기 바라며, 아래에는 위에서 소개된 기능에 대해 요약한 내용입니다.
 

 

요약

 

SPM 명령어 모음 

 

Reference List

- Oracle Document

http://wiki.gurubee.net/display/CORE/3.+SQL+PLAN+MANAGEMENT

1개의 댓글이 등록되었습니다
  1. 팀장님 좋은 정보 감사합니다ㅎㅎ

하승환 에 응답 남기기 응답 취소

댓글작성시 Code-Highlighter 삽입방법