05.데이터베이스 Call 최소화 원리 - 01.Call 통계

이번 챕터에서는 Parse Call을 제외하고 SQL수행 중에 발생하는 Execute Call,Fetch Call을 줄이는 방법에 대해서 설명하고, 데이터베이스 Call을 User Call과 Recursive Call로 나누어 각각을 최소화하는 원리와 방안에 대해서도 집중적으로 설명합니다.
DBA의 관리적명령어이든 사용자로부터의 데이터 조작 명령어든 모두 데이터베이스 Call을 통해 서버 프로세스에 전달되며, 불필요하고 반복적인 Call 수행횟수를 최소화하는 것은 데이터베이스 수행속도를 향상시키고 확장성을 높이는 중요하고 핵심적인 튜닝요소입니다.

아래는 sql trace 레포트에서 call 통계 부분만을 발췌한 것입니다.

Parse Call은 커서를 파싱하는 과정에 대한 통계로써, 실행계획을 생성하거나 찾는 과정에 관한 정보를 포함합니다.
Execute Call은 말 그대로 커서를 실행하는 단계에 대한 통계를 보여줍니다.

Fetch Call은 select문에서 실제 레코드를 읽어 사용자가 요구한 결과집합을 반환하는 과정에 대한 통계를 보여줍니다.
위 결과에서는 앞 챕터에서 사용했던 Parse Call 최적화(바인드변수)를 하여 parse call이 1이 되는것을 확인할 수 있습니다.
insert ,update, delete merge 등 DML문은 execute call 시점에 모든 처리과정을 서버 내에서 완료하고 처리결과만 리턴하므로 Fetch Call이 전혀 발생하지 않습니다. (insert....select 문도 마찬가지입니다) 클라이언트로부터 명시적인 Fetch Call을 받지 않고 묵시적으로 Fetch가 이루어집니다.
(아래의 표를 보시면 fetch 가 0임을 확인할 수 있습니다)

select문일때 execute call단계에서는 커서만 오픈하고, 실제 데이터를 처리하는 과정은 모두 Fetch단계에서 일어납니다. 예를 들어, 100만건 짜리 테이블을 group by 하는 쿼리인데, sort group by는 executee 단계에서 처리할 것으로 예상되지만 실제로는 Fetch시점에서 모든 처리가 일어났습니다.
실제 데이터를 액세스하면서 일을 시작하는 시점은 첫번째 Fetch Call인 것을 알 수 있습니다.
(fetch 시점의 rows가 26개의 row를 반환했는데 아래를 보면 sort group by에서 26개의 row가 나온것을 확인할 수 있습니다)

for update 구문을 사용하면 execute Call 단계에서 모든 레코드를 읽어 lock을 설정합니다.
10,000개의 레코드를 갖는 테이블을 for update문을 사용해 쿼리한 결과인데 사용자는 11번의 fetch call을 통해 101개 레코드만 fetch하고 멈췄지만 execute call에서 이미 Current 모드로 읽어 레코드 전체에 Lock을 설정했음을 알 수 있습니다.