CLASS

SQL_PROFILE 사용 방법

일반태그: Technical Architecture.DB태그: Oracle. 1 Comment 2014년 10월 31일 387 (1)

이번 칼럼은 10g부터 소개된 SQL_PROFILE의 기능에 대한 소개를 하고자 합니다.

SQL_PROFILE이란, 특정 SQL_ID의 실행계획이 비효율적으로 생성될 경우, SQL 구문 변경 없이 실행계획만 변경시키거나 고정시키기 위해 사용합니다.일반적으로 SQL 튜닝을 하기 위해서는 아래와 같은 절차를 통해 개선을 합니다. 

* 튜닝 대상 SQL에 대한 구문 변경
* 튜닝 대상 SQL에 대한 힌트 사용
* 튜닝 대상 프로그램에 대한 로직 변경
* 필요할 경우 인덱스 생성

문제는 위와 같은 튜닝을 하기 위해서는 DB Object 변경이 수반되어야 한다는 점입니다. 운영 상태에서 DB Object 변경은 상당한 Risk(Object Invalidation, Re-Parsing 등)를 가지고 있기 때문에, 해당 이슈를 처리하다가 장애까지 이어질 수 있으므로 이와 같은 튜닝을 적용하기에는 무리가 있습니다. 이 경우, SQL 구문 변경 없이(Object 변경 없이) 원하는 실행계획을 유도할 경우, 긴급하게 이슈 대응이 가능하기 때문에 튜너라면 반드시 이 기능을 숙지하고 있어야 합니다.

이제 SQL_PROFILE을 어떻게 사용하는지 살펴보겠습니다.

1. SQL_PROFILE 사용 예제

1-1) 오라클 버전 확인

 1-2) 테이블 생성

 1-3) 데이터 생성

1-4) 인덱스 생성 및 통계정보 생성

 1-5) 데이터 확인

1-6) 실행계획 확인

지금까지 DEPT 테이블을 만든 후 데이터, 인덱스 및 통계정보를 생성한 뒤, 실행계획을 살펴보았습니다. 실행계획은 당연히 DEPTNO 조건이 들어오기 때문에 이 컬럼으로 구성된 DEPT_U1 인덱스를 사용한 것을 볼 수 있습니다. 이제 이 실행계획을 SQL_PROFILE을 통해 FULL SCAN을 하도록 유도하려고 하는데, 그림으로 표현하면 아래와 같습니다.

즉, DEPT_U1 인덱스를 사용하는 SQL을 A라 하고, FULL SCAN 하는 SQL을 B라 할 때, SQL_PROFILE을 통해 B로 변경을 하는 방식입니다.

1-7) B 실행계획 유도

이제 원하는 B 실행계획이 나왔으므로, 이 힌트에 대한 OUTLINE FULL HINT를 통해 값을 가져오도록 하겠습니다.

1-8) B 실행계획 OUTLINE FULL HINT 

위에서 나온 ‘Outline Data’를 SQL_PROFILE에 등록합니다(등록 시 모두 가져올 필요는 없으며, 필요한 힌트만 취득하면 되나 테스트를 위해 전체를 가져옴)

SQL_PROFILE은 SQL_TEXT를 구분자로 인식하기 때문에 반드시 SQL_TEXT가 일치해야 하므로, 가급적 Shared Pool에 있는 SQL_TEXT를 이용하는 것이 좋습니다. 이를 이용하기 위해 해당 SQL을 수행토록 하겠습니다.

1-9) Shared Pool에 등록 및 SQL_ID 확인

SQL 실행 후 V$SQL에서 SQL_ID 및 SQL_FULLTEXT를 확인 하였으므로, 이를 활용하여 SQL_PROFILE을 등록토록 하겠습니다.

1-10) SQL_PROFILE 등록

이제 해당 SQL_PROFILE이 DICTIONARY에 등록 되었으며, 해당 내용을 사용해 보도록 하겠습니다.

1-11) SQL_PROFILE 사용

위의 결과처럼, Session-Level에서 ‘DEPT_PROFILE_1′ SQL_PROFILE을 사용한 결과, 힌트 없이 FULL SCAN하는 것을 알 수 있으며, ‘Note’에서도 ‘DEPT_PROFILE_1′을 사용했다는 것을 확인할 수 있습니다. 이와 같이 SQL_PROFILE은 SQL별로 등록할 수 있으며, 이에 대해 DBA_SQL_PROFILES 뷰에서도 확인이 가능합니다.

1-12) DBA_SQL_PROFILES View

 1-13) CATEGORY 기능

 1-14) DEFAULT로 등록

 

 2. SQL_PROFILE 패키지 정리

2-1) DBMS_SQLTUNE Package

 2-2) SQL_PROFILE 활성화 

 

 3. FORCE_MATCH 기능

SQL_PROFILE의 구분자는 위에서 설명한 것처럼 SQL 구문으로 체크를 합니다. 그런데, 만약 바인드 변수가 아닌 Literal 값으로 들어오는 Dynamic SQL일 경우,  SQL 구문이 모두 틀리기 때문에 SQL_PROFILE을 등록하여도 공유해서 사용을 할 수가 없습니다. 이 때, FORCE_MATCH 기능을 사용할 경우 CURSOR_SHARING 기능처럼 Literal 값을 바인드 변수로 자동변경 해주므로, 하나만 등록하여도 나머지 SQL을 공유해서 사용 할 수 있습니다.

3-1) 기존 SQL_PROFILE 삭제

3-2) Literal SQL을 CATEGORY ‘DEFAULT’로 하고, FORCE_MATCH 기능 없이 등록하여 공유가 되는지 체크

3- 3) 실행계획 확인

위의 결과에서 보듯이, ‘DEPT=10′에 대해서만 SQL_PROFILE을 등록하였기 때문에, 이 경우에만 FULL SCAN을 하고 나머지 20, 30, 40일 경우 INDEX SCAN을 사용했습니다. 즉, 20, 30, 40인 경우에는 SQL_PROFILE을 사용하지 못하는 것을 확인할 수 있습니다.

이제는 FORCE_MATCH를 사용하여 CURSOR_SHARING 기능이 사용되는지 체크해보도록 하겠습니다.

3-4) Literal SQL을 CATEGORY ‘DEFAULT’로 하고, FORCE_MATCH 기능 포함하여 등록한 후 공유가 되는지 체크

이처럼, SQL_PROFILE에서 FORCE_MATCH 기능을 통해 Literal SQL도 극복할 수 있으므로, 아주 유용한 기능이라 할 수 있습니다.

 

4. 주의사항

1) SQL_PROFILE 체크는 SQL 구문으로 체크하기 때문에 Shared Pool에 등록된 SQL을 SQL_PROFILE 시 사용하는 것이 좋습니다.
2) 1)에서 이야기한 것 처럼 SQL 구문으로 인식하기 때문에, 튜닝 SQL이 힌트가 아닌 구문 변경일 경우 사용할 수 없습니다.
3) CATEGORY 등록 시 ‘DEFAULT’ 즉, System-Level로 등록할 경우 시스템에 부하를 줄 수 있기 때문에 가급적 긴급 대응일 경우에만 사용하는 것이 좋습니다.

 

 

이상으로 오라클에서 제공하는 SQL_PROFILE에 대해 살펴보았습니다.

내용을 보시고 궁금하신 점이 있으시면 리플 달아주시기 바랍니다.

감사합니다.

 

reference site : http://docs.oracle.com/cd/B14117_01/appdev.101/b10802/d_sqltun.htm

Related Posts

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

Leave a Reply

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