2._Cursor_Sharing
2012.05.28 08:29
바인드 변수 사용 원칙을 잘 지키지 않아 시스템 정상 가동이 어려운 경우가 있음
--> 라이브러리 캐시 경합을 일시적으로 해결하기 위해 cursor_sharing 파라미터를 변경하는것을 고려할수 있음
1. emp 테이블을 새로 만듬
SQL> create index emp_idx01 on emp(empno); 인덱스가 생성되었습니다.
SQL> analyze table emp compute statistics
>> SQL문이 100% 같을 대만 커서를 공유함
SQL> show parameter cursor_sharing NAME TYPE VALUE
>> 다른 문자열은 모두 같고 일부 Literal 값만 다를때 그 값들을 시스템이 자동 생성한 바인드 변수로 대체함으로써 공유가능한 SQL 커서로 만듬
세션이 변경되었습니다. SQL> alter system flush shared_pool;
SQL> select sql_id, sql_text, version_count
SQL_ID SQL_TEXT VERSION_COUNT
PL/SQL 에서 루프를 돌면서 Dynamic SQL을 이용해 Literal 상수를 제공하며 조회했는데 V$SQL을 조회하면 바인드 변수를 사용했을때처럼 공유커서가 반복 사용 됨
SQL_ID CHLD_NO PLAN_HASH LOADS PARSE_CALLS EXECUTIONS FETCHES |
. FORCE로 설정시
- 어떤 값으로 싫행하든 항상 같은 실행계획을 사용
- EXACT 일 때보다 라이브러리 캐시 부하는 상당히 줄겠지만 컬럼 히스토그램을 사용하지 못하는 문제 때문에
성능이 더 나빠질 가능성
-> 어떤 값은 분포가 90% 이고 다른 값들은 대개 1% 정도 분포를 보일때 FORCE를 사용하면 항상
고정된 실행계획을 사용함으로써 EXACT일 때보다 개별 쿼리 성능은 더 나빠질수 있음
>> 위의 단점을 회피할 목적으로 SIMILAR를 설정, 실행되는 Literal 값에 따라 별도의 커서를 생성함으로써
다른 실행계획을 사용할수 있게 함
SQL> alter system flush shared_pool; 시스템이 변경되었습니다. SQL> alter session set cursor_sharing = 'SIMILAR'; 세션이 변경되었습니다.
SQL> select sql_id, sql_text, version_count
SQL_ID SQL_TEXT VERSION_COUNT
SQL> select sql_id, child_number chld_no, plan_hash_value plan_hash, loads, parse_calls, executions, SQL_ID CHLD_NO PLAN_HASH LOADS PARSE_CALLS EXECUTIONS FETCHES >> SIMILAR로 설정했는데도 Literal 값에 따라 CHILD 커서를 생성하지 않았고 FORCE일때와 똑같이 하나의 공유 커서를 사용함, empno 칼럼에 히스토그램이 없기 때문이며 , SIMILAR로 설정해도 FORCE와 같은 방식으로 작동
|
>> 입력되는 Literal값에 따라 다른 실행계획이 생성되는지 확인하기 위해 많이 입력함
SQL> insert into emp(empno, ename, job, mgr, hiredate, sal, comm, deptno) 9999 개의 행이 만들어졌습니다. SQL> commit; 커밋이 완료되었습니다.
SQL> analyze table emp compute statistics 테이블이 분석되었습니다.
SQL> set autotrace traceonly exp
>> TABLE을 FULL SCAN함 Execution Plan --------------------------------------------------------------------------
>> SIMILAR 옵션을 줌
SQL> delete from emp where empno = '7788' and rownum <= 9999; 9999 행이 삭제되었습니다.
SQL> declare PL/SQL 처리가 정상적으로 완료되었습니다. SQL> SQL_ID 7v2nh2sv9hf80 SQL_ID
SQL_ID CHLD_NO PLAN_HASH LOADS PARSE_CALLS EXECUTIONS FETCHES SQL_ID CHLD_NO PLAN_HASH LOADS PARSE_CALLS EXECUTIONS FETCHES
|
>> SIMILAR 일때, 히스토그램을 생성해 둔 컬럼에 값의 종류가 아주 많으면 어떤일이 발생하는지 테스트
SQL> create table t
SQL> create index t_idx on t( no);
SQL> analyze table t compute statistics
SQL> alter system flush shared_pool;
SQL> alter session set cursor_sharing = 'SIMILAR'; 세션이 변경되었습니다. SQL> set timing on PL/SQL 처리가 정상적으로 완료되었습니다. 경 과: 00:00:00.04
--> 아주 빠르게 처리함, V&SQL을 조회해 보지 않더라고 하나의 공유 커서가 사용됐음을 짐작
>> 히스토그램 생성 경 과: 00:00:00.04 테이블이 분석되었습니다. 경 과: 00:00:00.10 PL/SQL 처리가 정상적으로 완료되었습니다. 경 과: 00:00:09.71 --> 수행시간이 급격히 저하, 히스토그램을 생성했으므로 각 입려값별로 child 커서를 만들어야 하고 아래처럼 하드파싱 할 때보다 더 나쁜 결과를 초래함
SQL> declare PL/SQL 처리가 정상적으로 완료되었습니다. 경 과: 00:00:06.92
>> 바인드 변수를 사용함
SQL> declare PL/SQL 처리가 정상적으로 완료되었습니다. 경 과: 00:00:00.18 |
--> 과도한 shared pool과 라이브러리 캐시 래치 경합 을 줄이는데 효과는 있지만, 기존 실행계획이 틀어져
이전보다 더 느리게 수행되는 쿼리들이 속출하게 될 가능성이 높음
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
66 | 부록 | 남송휘 | 2012.06.05 | 2708 |
65 | 8._IO_효율화_원리 | 운영자 | 2012.06.05 | 4426 |
64 |
3._Deterministic_함수_사용_시_주의사항
![]() | 정찬호 | 2012.05.29 | 4351 |
» | 2._Cursor_Sharing | 운영자 | 2012.05.28 | 6276 |
62 | 7._Result_캐시 | 운영자 | 2012.05.27 | 4426 |
61 |
3._Single_Block_vs._Multiblock_IO
![]() | 정찬호 | 2012.05.22 | 4229 |
60 |
2._Memory_vs._Disk_IO
![]() | 정찬호 | 2012.05.22 | 4446 |
59 |
1._블록_단위_IO
![]() | 정찬호 | 2012.05.22 | 4211 |
58 |
6장._IO_효율화_원리
![]() | 정찬호 | 2012.05.22 | 4085 |
57 |
1._Library_Cache_Lock_Pin
![]() | 남송휘 | 2012.05.21 | 4290 |
56 |
6._RAC_캐시_퓨전
![]() | 남송휘 | 2012.05.21 | 17797 |
55 | 5._Direct_Path_IO | 남송휘 | 2012.05.21 | 7932 |
54 |
4._Prefetch
![]() | 남송휘 | 2012.05.21 | 3889 |
53 | 8._PLSQL_함수_호출_부하_해소_방안 | 남송휘 | 2012.05.21 | 3773 |
52 | 5._Fetch_Call_최소화 [1] | 박영창 | 2012.05.15 | 6065 |
51 |
7._PLSQL_함수의_특징과_성능_부하
![]() | 남송휘 | 2012.05.14 | 6935 |
50 | 6._페이지_처리의_중요성 | 남송휘 | 2012.05.14 | 3379 |
49 | 4._Array_Processing_활용 | 시와처 | 2012.05.13 | 4043 |
48 |
3._데이터베이스_Call이_성능에_미치는_영향
![]() | 시와처 | 2012.05.13 | 3645 |
47 |
10._Dynamic_SQL_사용_기준
![]() | 남송휘 | 2012.05.07 | 4556 |