SQL 처리과정

SQL 처리과정

SQL은 세 단계로 나눠서 처리됨

1. Parse Call

   파싱과 최적화를 수행하는 단계 SQL과 실행계획을 라이브러리 캐시에서 찾으면, 최적화 단계는 생략할 수 있음 하드 파싱이 발생하면 최적화 단계가 필요하니 Recursive Call(데이터 딕셔너리 조회)이 발생

2. Execute Call

   SQL을 실행하는 단계 DML은 이 단계에서 모든 과정이 끝나지만, SELECT 문은 Fetch 단계를 거침 (DML은 I/O가 Execute Call에서 발생하고, SELECT는 Fetch 단계에서 발생) DML 문에 DB 내장된 함수가 포함되면 Recursive Call(함수 호출) 발생

3. Fetch Call

   데이터를 읽어서 사용자에게 결과집합을 전송하는 과정 전송할 데이터가 많으면 Fetch Call이 여러 번 발생 SELECT 문제 DB 내장된 함수가 포함되면 Recursive Call 발생

Call이 어디서 발생하느냐에 따라 User Call, Recursive Call로 나뉨 (User Call 이든, Recursive Call이든 SQL을 실행할 때마다 Parse, Execute, Fetch 단계는 발생)

• User Call

  WAS 서버에서 DB Server로 발생하는 Call 외부 네트워크를 경유하기 때문에 성능에 미치는 영향이 큼

• Recursive Call

  DBMS 내부에서 발생하는 Call SQL 파싱/최적화 과정에서 데이터 딕셔너리 조회할 때, 함수/프로시저에 내장된 PL/SQL을 실행할 때 발생하는 Call

<SQL 트레이스 리포트 Call 부분 예시>

• ‘Misses in library cache during parse’ → 하드 파싱 1회 발생
• 어플리케이션 커서를 캐싱한 상태로 SQL 실행 → 5,000번 실행하면서 파싱은 1번만 발생함 해당 트레이스에서는 바인드 변수와 세션 커서를 사용했는지는 알 수 없음
• 소프트 파싱은 0회 → Parse Call 횟수 - 하드 파싱 횟수 ⇒ 1-1=0
• SELECT 문의 대한 트레이스 결과 → I/O 처리가 Fetch 단계에서 발생