Call이 어디서 발생하느냐에 따라 User Call과 Recursive Call로 나눌 수 있다.
SQL 트레이스 파일을 TKProf 유틸리티로 포맷팅하면 맨 아래쪽에 아래와 같은 Overall Total 통계가 나온다. 이 중 NON-RECURSIVE 통계가 User Call에 해당하며, 그 아래쪽 RECURSIVE 통계가 Recursive Call에 해당한다.
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 4 0.02 0.03 0 121 0 0
Execute 4 0.03 0.03 4 95 2915 0
Fetch 30 0.04 0.02 0 122 0 2859
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 38 0.09 0.09 4 338 2915 2859
Misses in library cache during parse: 2
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 4 0.00 0.00 0 0 0 0
Execute 53 0.00 0.00 0 0 0 0
Fetch 53 0.00 0.00 80 277 0 3
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 110 0.00 0.00 80 277 0 3
DBMS 성능과 확장성(Scalability)를 높이려면 User Call을 최소화 하려는 노력이 무엇보다 중요하며, 이를 위해 아래와 같은 기능과 기술을 적극적으로 활용해야만 한다.
SELECT code,....
FROM ....
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 493 0.01 0.00 0 0 0 0
Fetch 493 0.03 0.02 0 3451 0 493
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 986 0.04 0.02 0 3451 0 493
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 41 (recursive depth: 1)
위의 결과에 나오는 recursive depth는 PL/SQL실행시에 나오는 결과로 옆의 숫자값은 프로시져의 호출 횟수이다.
recursive depth가 2이상이면 특정프로시져에서 또 다른 프로시져를 호출한 경우이며, 트레이스 결과는 마지막 프로시저에서 사용된 SQL에 대한 수행결과이다.
PL/SQL은 가상머신(Virtual Machine)상에서 수행되는 인터프리터(Interpreter)언어이므로 빈번한 호출 시 컨텍스트 스위칭(Context Switching)때문에 성능이 매우 나빠진다. 성능을 위해서라면 PL/SQL에 대한 지나친 모듈화닌 지양해야 한다.
또한, 대용량 데이터 조회시에 함수를 잘못사용하면 건건이 함수 호출이 발생되어 성능이 극도로 제한될수 있는등의 문제가 있다.
될수있으면 조인 또는 스칼라 서브쿼리 형태로 변환하려는 노력이 필요하다.
기타 자세한 함수에 대한 설명은 7절 이하에서 자세히 다룬다고 하니~~ 패쑤다.