메뉴 건너뛰기

bysql.net

1._Call_통계

2012.05.07 09:32

정찬호 조회 수:4297


그림1

꾸미기_P20120507_004956672_D4AD1F80-FFA3-4AED-AC96-9C9865B4B597.JPG

SQL 트레이스 레포트에서 Call통계(Statistics) 부분만을 발췌한 화면입니다.

커서의 활동상태를 Parse, Execute, Fetch 세 단계로 나누어 각각에 대한 수행통계를 보여줍니다.


1. Parse Call

 커서를 파싱하는 과정에 대한 통계로서, 실행계획을 생성하거나 찾는 과정에 관한 정보를 포함합니다.

2. Execute Call

 말 그대로 커서를 실행하는 단계에 대한 통계를 보여줍니다.

3. Fetch Call

 SELECT문에서 실제 레코드를 읽어 사용자가 요구한 결과집합을 반환하는 과정에 대한 통계를 보여줍니다.




구문 별 Call 통계


1. INSERT, UPDATE, DELETE, MERGE 등 DML문

  가. Execute Call 시점에 모든 처리과정을 서버 내에서 완료하고 처리결과만 리턴하므로 Fetch Call이 전혀 발생하지 않습니다.

  나. INSERT INTO 문의 경우 클라이언트로부터 명시적인 Fetch Call을 받지 않으며 서버 내에서 묵시적으로 Fetch가 이루어집니다.


그림2

 꾸미기_P20120507_003926336_3E62BD6B-CA5E-4B33-9CDF-CE7F0D3A6B06.JPG



2. SELECT 문

  가. Execute Call 단계에서는 커서만 오픈하고, 실제 데이터를 처리하는 과정은 모두 Fetch 단계에서 일어납니다.

  나. 100만건 짜리 CUST 테이블을 GROUP BY 하는 쿼리

     SORT GROUP BY 는 Execute 단계에서 처리할 것으로 예상되나 실제로는 Fetch 시점에 모든 처리가 일어납니다.

     실제 데이터를 엑세스하면서 일을 시작하는 시점은 첫 번째 Fetch Call 인 것을 짐작할 수 있습니다.


그림3

 꾸미기_P20120507_003943818_D32B3CB4-1B1A-4702-9A94-8740390B267F.JPG



3. FOR UPDATE 문

 가. Execute Call 단계에서 모든 레코드를 읽어 Lock을 설정합니다.

 나. 10,000개 레코드를 갖는 테이블을 FOR UPDATE 구문을 사용해 쿼리한 결과

   사용자는 11번의 Fetch Call을 통해 101개 레코드만 Fetch하고 멈췄지만

   Execute 단계에서 이미 Current 모드로 읽어 10,000개 레코드 전체에 대해 Lock을 설정했습니다.


그림4

꾸미기_P20120507_003958371_11E61974-AD67-4241-AFFB-1BBF3E099B83.JPG