본문 바로가기

Oracle/Tuning

V$SQLAREA 자료사전


 V$SQL, V$SQLTEXT
[공유-풀 영역의 구문 분석 결과를 제공]
 - 가장 많은 Disk I/O가 발생한 sql문을 제공
 - 가장 많은 메모리를 사용한 sql 문을 제공
 - 가장 많은 CPU 사용기간이 소요된 SQL문을 제공
 - 사용자가 실행한 SQL 패턴 제공
 - SORT 횟수, INVALIDATION된 SQL문 등

SELECT SQL_TEXT, VERSION_COUNT, LOADS, INVALIDATIONS, PARSE_CALLS, SORTS,DISK_READS, BUFFER_GETS
FROM V$SQLAREA
WHERE SQL_TEXT NOT LIKE '%$%' AND COMMAND_TYPE IN (2,3,6,7);

SQL_TEXT NOT LIKE '%$%'  : 시스템에서 실행한 SQL을 제외한 사용자가 호출한 SQL QUERY만을 검색
COMMAND_TYPE IN (2,3,6,7) : 특정 쿼리만 분석(2 : INSERT, 3 : SELECT, 6 : UPDATE, 7 : DELETE)

SQL_TEXT : 실행한 SQL QUERY
VERSION_COUNT :  같은 쿼리를 서로다른 사용자가 실행햇을때 의 수
LOADS : 로딩된 수?
 INVALIDATIONS :  drop alter analyze 의 이유로 해당 sql 문의 무결성을 보장할 수 없다.는
PARSE_CALLS :  : 재실행 수
SORTS : 사용한 소팅 수


ex)
ALTER SYSTEM FLUSH SHARED_POOL;

SELECT SQL_TEXT, VERSION_COUNT, LOADS, INVALIDATIONS, PARSE_CALLS, SORTS
FROM V$SQLAREA
WHERE SQL_TEXT NOT LIKE '%$%' AND COMMAND_TYPE IN (2,3,6,7);

SELECT * FROM EMP;
SELECT * FROM DEPT;

SELECT SQL_TEXT, VERSION_COUNT, LOADS, INVALIDATIONS, PARSE_CALLS, SORTS
FROM V$SQLAREA
WHERE SQL_TEXT NOT LIKE '%$%' AND COMMAND_TYPE IN (2,3,6,7);

SQL_TEXT        VERSION_COUNT  LOADS INVALIDATIONS PARSE_CALLS SORTS
-----------------------------------------------------------------------------
SELECT * FROM EMP       1               1                    1                  1           0
SELECT * FROM DEPT      1               1                    1                  1           0

동일한 문장이 아닌 경우
 - 띄어쓰기의 갯수가 다를 경우      -> 해결 방법 : 공통으로 사용하는 sql 문법을 만들어 사용
 - 바인드 변수명 또는 변수의 데이터 타입이 다른 경우 -> 해결 방법 : cursor_sharing parameter 사용
 - 대소문자가 다른 경우        -> 해결 방법 : 공통으로 사용하는 sql 문법을 만들어 사용
 - 라인이 다른 경우         -> 해결 방법 : 공통으로 사용하는 sql 문법을 만들어 사용

CURSOR_SHARING :
 9i 이후, 모든 조건은 동일한데 조건절의 상수 값이 다른경우 또는 바인드 변수의 값이 다른경우도 동일한 sql 문으로 재사용하기위해 사용

 * CURSOR_SHARING = EXACT
-- 동일한 조건일 경우 파싱정보 공유

 * CURSOR_SHARING = SIMILAR
-- 기존에 파싱된 sql중 위와 같은 경우가 발생하면 파싱정보를 공유

 * CURSOR_SHARING = FORCE
-- 기존에 파싱된 sql에 위와 같은 경우의 sql이 존재하지 않는 경우에도
-- 이후의 경우를 위해 조건절의 상수를 공유 가능 상태로 해놈

cursor_sharing 파라미터를 사용하지 않는 이유
  1. 자동변환과 overhead
    이 파라미터를 사용하게 되면 바인드변수를 사용한 효과를 볼 수 있지만
    오라클 내부에서 자동변환이 발생하게 된다고 한다.
    그리고 그 자동변환에 의해 overhead가 발생할 수 있다고 한다.
   
    바인드변수를 사용했을 때 보다 30% 정도의 overhead가 발생한다고 한다.

  2. 동작보증
    동작보증을 못 한다는 것이다.
    어디까지나 오라클이 내부적으로 테스트 해 본 결과가 그렇다는 것이지 모든 고객 시스템에서
    그런 효과를 볼 수 있는 지는 보증할 수 없다고 한다.
    이게 무슨 얘기인지 아직도 잘 이해가 안 되지만... 그럼 쓰라는 얘기야 쓰지 말라는 얘기야?!

  3. 바인드변수를 사용하는 게 일반적으로는 최상의 방법
    바인드변수를 사용하는게 최상의 방법이라고 한다.
    하지만 "일반적으로 최상의 방법"이라는 표현은 시스템마다 상황이 다르기에
    cursor_sharing 파라미터로 문제해결이 가능하기도 하다는 뜻이다.