[SQLP] 1장. 아키텍처 기반 튜닝 원리 - SQL 파싱 부하

SQL 파싱 부하

1. SQL 처리과정

• 사용자는 구조화된 질의언어 SQL 을 통해 사용자가 원하는 결과집합을 정의

• DBMS는 사용자의 SQL을 SQL옵티마이저를 통해 실행계획으로 작성해줌

가. SQL 파싱

• SQL을 실행하면 제일먼저 SQL 파서가 SQL 문장에 오류가 없는지 검사

• 문법적 오류가 없다면 의미상 오류가 없는지 검사

• 검사후, 사용자가 발생한 SQL과 실행계획이 라이브러리 캐시에 캐싱되어 있는지 확인

• 캐싱되어 있다면 소프트파싱(SQL과 실행계획을 캐시에서 찾아 곧바로 실행단계로 넘어가는 경우), 캐싱되어 있지 않다면 하드파싱(SQL과 실행계획을 캐시에서 찾지 못해 최적화 과정을 거치고 나서 실행단계로 넘어가는 경우)

• 라이브러리는 해시 구조로 관리됨 (SQL문장을 해시값 만드는 키로 사용)

2. 캐싱된 SQL 공유

가. 실행계획 공유 조건

SQL 문장 중간에 작은 공백문자 하나만 추가되더라도 DBMS는 서로 다른 SQL 문장으로 인식하기 때문에 캐싱된 버전을 사용하지 못하게 된다.

나. 실행계획을 공유하지 못하는 경우

1. 공백 또는 줄바꿈

2. 대소문자 구분

3. 주석

4. 테이블 Owner 명시여부

5. 옵티마이저 힌트사용 여부

6. 조건절 값

3. 바인드변수 사용하기

가. 바인드 변수의 중요성

SELECT * FROM CUSTOMER WHERE LOGIN_ID = :LOGIN_ID; 

• 위와 같이 바인드 변수를 사용하면 처음 수행한 세션이 하드파싱을 통해 실행 계획을 작성

• 다른 세션들은 캐시에서 실행계획을 얻어 재사용! -> 소프트파싱

나. 바인드변수 사용시 주의사항

• 칼럼의 분포가 균일할 때 사용 권장

• 칼럼의 분포가 균일하지 않을 때에는 바인딩 값에 따라 쿼리 성능 다르게 나타남

다. 바인드 변수 부작용을 극복하기 위한 노력

바인드변수 Peeking

첫번째 바인드 변수값을 살짝 훔쳐보고 그 값에 대한 분포를 이용하여 실행계획 결정

4. Static SQL과 Dynamic SQL

가. Static SQL

String형 변수에 담지 않고, 코드 사이에 직접 기술한 SQL문 ( PL/SQL, PowerBuilder…)

나. Dynamic SQL

char select_stmt[50] = "SELECT ENAME FROM EMP WHERE EMPNO = :empno"; 

String 형 변수에 담아서 기술하는 SQL문

5. 애플리케이션 커서 캐싱

• 옵션을 별도로 적용하지 않더라도 자동적으로 커서를 캐싱함(단, Stastic SQL 사용시에만)

• Dynamic SQL을 사용하거나 Cursor Variable(=Ref Cursor)를 사용할 때는 커서를 자동으로 캐싱하는 효과가 사라짐