사실은 두서없이 봅니다;;
순서가 필요하다고 자각하고 있습니다.
두서없이 보면서도 상통하는 부분은 있기야 있습니다만 체계적이지 않기 때문에
간과하는 부분도 많습니다.
제가 스스로를 알기 위해 쓴다는 느낌의 글이 될 것 같군요.
QUERY 를 볼 때 사용할 수 있는 재료는 다음과 같은게 있겠지요.
1. 원문쿼리
2. TRACE 파일 (TKPROF 된)
3. 통계정보
1번에 대해서는 추가적으로 언급할 것은 없는 것 같습니다.
2번에 대해서는 가장 많은 정보가 들어있습니다. 대표적으로 실행플랜과 웨이트정보 스탯정보가 있겠네요.
3번에 대해서는 테이블 스탯, 인덱스 스탯이 있겠네요. 추가적으로 세그먼트의 크기정보도 필요할 겁니다.
3번에 대해서 세그먼트의 크기를 이야기 한 것은 통계정보가 낡은 경우 현재의 사이즈를 가늠하기 위해서 입니다.
재료는 다 모아졌습니다. (아마도...)
재료를 해석하는 방법은 어떠한 것이 있을까요...?
앞에서 이야기한 3가지 재료에 대해 각기 생각해 보면 다음과 같은게 있지 않을까요?
1. 원문쿼리 - 2번 못지 않게 많은 정보를 가지고 있습니다. SELECT-LIST, 조인조건, 체크조건, 엑세스 테이블 등등
해석초점은 쿼리를 보고 조인조건에 대한 이상(NL JOIN) 이나 COLUMN 가공부분 중복 엑세스 테이블 등등이 있을 겁니다.
또 쿼리를 보고 ERD 아닌 ERD 를 그려볼 수 있겠지요. MS 의 VISIO 같은 느낌으로 그린달까요?
테이블이 있으면 각기 어떤 테이블과 관계를 가지고 있는지. 또 그 관계는 몇 개의 조건으로 이루어져 있는지
추가적으로 스스로의 처리범위를 줄여줄 조건을 몇 게나 가지고 있는지가 있겠네요.
이렇게 그려놓으면 어떤 테이블이 먼저 DRIVING 되어야 하는지 또 조인순서가 잘못 되었는지 제대로 되었는지 등의
많은 정보를 한 눈에 얻을 수 있습니다. 뭐 일부에서는 '시간이 남아도냐?' 라고 이야기 하시는 분도 있지만
시간이 부족하지 않다면 그려보는게 이해도 잘 됩니다. ERD 에 대한 내용은 대용량 아키텍쳐 솔루션 같은 모델링 책을
공부한 상태라면 더 큰 도움이 되지 않을까 싶네요. 물론 추가적으로 필요한 정보들도 있겠지요. (참조 무결성 조건)
2. TRACE 파일 - 많은 정보가 있습니다. 전체를 보는 방법이 있고 부분을 보는 방법이 있을겁니다. (아마도)
통상적으로 이 파일을 들여다 본다는 것은 쿼리를 개선하기 위한 것이기에 부분을 찾아가는 경우가 많습니다.
가장 큰 문제를 해결함으로써 가장 큰 비효율을 해소한다는 걸까요? 뭐 요 부분을 찾아가는 방법으로는 실행플랜의 CR 과
TIME 정보를 이용하는 것입니다. 8i 의 경우에는 앞의 두 정보가 하나도 없습니다 ㅡ..ㅡ;
TIME 정보는 9i 부터 나왔을거라 생각이 되네요. (아마도...;;) 사실 비효율 부분을 핀포인트로 간다 해도 해당
부분이 왜 비효율적인지 해석하기 위해서는 해당 OPERATION 을 감싸고 있는 전체적인 OPERATION 을 해석할
수 있어야 합니다. 추가적으로 CR 과 TIME 이외에도 ROWS 를 이용하는 방법이 있습니다. 이 부분의 경우는
이용 INDEX 의 효율성과 테이블의 규모 그리고 JOIN 시 비효율성 등등의 문제를 찾는데 유용합니다.
위에서 PLAN 부분을 주로 이야기 했습니다. 이 부분이 8할 이상이 아닐까 싶네요. STAT 정보에서는 EXECUTION PLAN
에서 나왔던 각종 STAT 을 보기좋게 표로 만들어진 부분입니다. 제 경우 사용하는 정보는 QUERY 와 ELAPSED, CPU
정도네요... QUERY 는 EXECUTION 의 CR 에 해당하는 값입니다. ELAPSED 는 CPU + I/O WAIT 에 해당하는 값입니다.
마지막으로 WAIT 정보가 있네요. 이 부분은 아직 저도 가늠이 안가는 부분입니다. 뭐 개개의 WAIT EVENT 에 대해서는
이해하고 있을 작정이지만 뭐랄까요 눈으로 확인한 값이 시스템에 어떠한 영향을 미칠지는 실감이 안납니다.
3. 통계정보 - 정...말 많은 정보가 있습니다. 사실 여기서 많다는 이야기는 컬럼이 많다는 이야기 입니다. ;
사실 사용하는 정보만 사용합니다만 ㅡ..ㅡ
제 경우엔 아래와 같은 정보를 사용합니다.
<INDEX 의 경우>
INDEX_NAME, TABLE_NAME, COLUMN_NAME, DISTINCT_KEY, COLUMN_POSITION, LAST_ANALYZED,
INDEX_TYPE
<TABLE 의 경우>
TABLE_NAME, NULLABLE, NUM_ROWS, (음...?)
뭔가 더 있었던 것 같은데 기억이 안나네요. 하여간 INDEX 와 TABLE 에 대한 컬럼은 정말 많아서 필요한 것만
뽑아 쓸 필요가 있습니다. WORD 파일 같은데에 붙여넣으면 한순간에 정크가 됩니다. 알아보는 사람이 대단하다고
밖에 생각할수가 없습니다.
재료와 분석 초점에 대한 이야기가 끝났습니다.
한번에 모아 모아 이야기 하면 아래와 같이 되지 않을까요?
1. 원문쿼리를 바인드 변수를 이용해 TRACE
2. TRACE 를 TKPROF 로 요약
3. 사용되었던 테이블, 인덱스 통계정보 수집
4. CONSTRINTS, COMMENTS 정보 수집
5. 원문 쿼리의 OVER VIEW
6. 원문 쿼리의 도식화 (머릿속에 그릴 수 있으면 생략해도 되겠지요...)
7. 원문 쿼리의 업무 해석 (이를 하기 위해서는 COMMENT 정보가 필요합니다.)
8. 실행플랜의 STAT 정보 확인 ( CR 과 ELAPSED 를 보겠지요...)
9. 실행플랜의 OVER VIEW
10.실행 플랜의 비효율 부분 체크
11.비효율 부분의 딕셔너리 정보 확인
12.쿼리의 개선
4번의 경우 앞에서 따로 이야기를 안한 것 같네요. CONSTRAINT 정보는 참조무결성 조건의 확인을 위해 필요합니다.
원문 쿼리의 도식화(6번) 를 정식으로 하기 위해 필요하겠지요. 그리고 이 정보는 COMMENT 정보를 통해 승화된다고
생각(어디까지나 생각입니다...) 합니다. 여기서 COMMENT 라 함은 개발자가 객체에 대해 남겨놓는 일종의 주석이라고
생각하시면 됩니다. 이런 정보가 있음으로 쿼리를 말로 풀어 이야기 할 수 있을거라 생각합니다. (정작 자신은 아직
해 보지 않았습니다;)
뭐 이것을 하기에 앞서 과연 얼마나 COMMENT 가 달려 있나는 의문입니다.
지금은 빼먹는 부분도 많지만 생각을 글로쓰면 그것이 미래가 된다는 이야기 같이 머리 한켠에 기억해보려 합니다.
