[팁] TKPROF로 TRACE 분석

● execute, fetch의 횟수가 동일하다는 것은 SQL 수행시마다 기본키에 의해 한건씩만 처리되고 있다는 것을 의미한다.
   만약 pares가 1인데 execurte와 fetch가 100이라면 루프가 100번 수행되면서(어프리케인션은
   한번만 수행되고 SQL은 루프 내에서 반복수행되었다. 왜냐하면, 어플리케이션이 여러번 실행되었다면
   비록 SQL이 실제 파싱하지 않고 Shared SQL Area에서 찾아 왔다고 해도 parse의 횟수는 증가되기 때문이다)
   보관커서 상태의 SQL이 한 건씩을 추출한 상태이다.
   이 경우의 SQL문은 'SELECT ... INTO ...'형식으로 사용되었을 것이다.
  
●  parse가 1이고 execute가 1이며, fetch가 100이라면 SQL은 단 한번 수행되었고(루프 내에서 수행되지 않았음)
   페치만 연속해서 100번을 수행한 것이다. 이 경우의 SQL문은 대개 'DECLARE CURSOR'로 선언한
   SQL이 'FETCH ... INTO ...'에 의해 SQLCODE가 '1403'(Date Not Found)일 때까지 수행되었거나 부분범위 처리에 의해
   일정 양만큼만 수행하고 멈추었을 때이다.
  
  
●  parse : execute : fetch의 비율은 공통 작업이 여러번 수행되면 그 배수로 나타난다.
   예를 들면 parse : execute : fetch가 10 : 10 : 1000인 경우는 1 : 1 : 100인 작업이 10번 수행되었다는 것을 의미한다.
  
● fetch가 10인데 rows가 100이라면 운반단위가 10인 다중처리(Array Processing)를 사용하여 한번 페치마다
   10건의 로우가 추출되었음을 의미한다.
  
●  트레이스의 중간부분에 'Misses im library cache during parse : 1'이라는 문장이 있다.
   이것은 공유 SQL 영역에서 파상된 결과를 찾지 못하여 실제 파싱작업을 하게 되었다는 것을 의미한다.
  
● 최종적으로 추출된 로우의 수는 적으나 많은 CPU 시간이 소요되었다면 이것은 분명히
   적절한 액세스 경로로 수해되지 않았음을 의미한다.
  
● CPU 시간과 ELAPSED 시간의 차이는 적을수록 좋다.
   만약 CPU시간에 비해 ELAPSED 시간이 훨씬 많다면, 그 원인은 다음 중 하나일 가능성이 높다.
   ▶ 주변의 다른 세션에서 많은 부하를 발생시켜 시스템 전체에 부하가 많이 걸려있는 경우
   ▶ 어플리케이션의 문제이거나 다량의 데이타 처리에 따른 I/O 병목현상이 발생한 경우
  
●  disk, query, current의 숫자는 적을수록 좋다.
   이 숫자들이 크다는 것은 메모리 공유영역의 적중률(Hit Ratio)이 낮다는 것을 의미한다.
  
● Overall totals For All Statements에서 적중률 계산은 다음과 같다.
   ▶ (Execute 'disk' + Fetch 'Disk')/(Execute 'query' + Execute 'current' + Fetch 'query' + Fetch 'Current') * 100
   ▶ 이 값이 10%이상이라면 메모리 캐쉬에서 데이타를 찾는 비율(적중률)이 너무 낮은 것이다.
  
● 다음은 아주 빠른 응답이 요구되는 온라인 프로세싱 시스템의 경우에서만 적용되는 규칙들이다.
   ▶ 모든 Execute 'CPU'가 1초보다 적어야 한다.
   ▶ Parse 'CPU' 시간이 Parse당 0.01초보다 적어야 한다.
   ▶ 작은 테이블(200로우 이하)에서만 전체 테이블 스캔이 일어나게 한다.
   ▶ sysdate만 찾아오거나, 오직 연산만 하거나, 'SELECT ... INTO ...'로 값을 복사하는 경우를 위해서
      DUAL 테이블들을 불필요하게 사용하는 것은 모두 없앤다.
   ▶ 동시에 작업되는 SQL들은 가능한 PL/SQL을 사용한다.
   ▶ 조인시에 옵티마이져가 적절한 드라이빙 테이블을 선택하는지를 확인하거나,
      여러개의 조건들 중에서 주(드라이빙)가 되는 조건들과 부(체크)가 되는 조건들을 확인한다.
      또한 적적한 인덱스가 사용될 수 있는지를 확인하여 주조건의 처리범위가 넓지 않도록 항상 유의한다.