literal sql에 의한 hard parsing으로 인한 성능 저하_maxgauge case study

MaxGauge Case Study

Copyrights 2006. EXEM CO., LTD. All Rights Reserved 1

Literal SQL에 의한 Hard Parsing으로 인한 성능 저하 현상 분석

EXEM CO., LTD www.ex-em.com

2006.06

동시사용자가 많은OLTP（On-Line Transaction Process） 및 WEB환경에서, Literal SQL의 과다 사용은 성능

상의 심각한 문제를 야기하는 경우가 많다. 이번 Case Study에서는, Oracle DBMS의 성능진단/분석 툴인

MaxGauge(맥스게이지)를 활용하여, Literal SQL의 과다한 사용에 의해 발생한 성능저하 문제의 원인을

규명해 보고자 한다.

본 사례에서 사용한 문제원인분석의 Flow(Performance Analyzer / MaxGauge)

Drill-Down Flow Menu & Data

1. 성능저하구간의 확인 [Trend Analysis] 메뉴에서, CPU사용률의 급변, Active Session의 증가, Wait Events의 급증 등 성능저하구간을 확인 함.

2. Wait Event의 검출 및 분석 [Trend Analysis] 메뉴에서, 문제원인이 되는 Wait Events를 특정하고, 그 내용을 분석 함.

3. Wait Event 발생원인의 조사 [Trend Analysis] 메뉴에서, Hard parsing과 관련된 parse time cpu, parse time elapsed, parse count (hard)등 STAT지

표의 추이를 분석 함.

4. 세션 및 SQL의 분석을 통한 문제원인의 규명

[Session List] 메뉴에서, Hard Parsing의 과다수행구간을 특정하고, 이와 관련된 세션 및 SQL을 분석하여 문제

원인을 규명함.

MaxGauge Case Study

1. 성능저하구간의 확인

성능문제가 발생한 ｢DBODS1｣ 인스턴스에서 수집된 가동이력로그로부터 일간 추이그래프를 확인해 보면, 「CPU사용률」에는 뚜렷한 변화가 없어 보이지만, 10시17분을 Peak로 「Active Session」 및 ｢Wait Events｣ 가 급증하는 것을 쉽게 확인할 수 있다. ■CPU사용률의 추이그래프

■Active Session수의 추이그래프

■Wait Events의 추이그래프（Wait Time）

2. Wait Events의 검출 및 분석

Active Session의 급증으로 인한 성능저하（Performance Slow-Down）의 원인을 규명하기 위해, 문제시점(10시17분)의 Wait Events의 발생내용을 확인해 본다.

｢Stat/Wait｣에서 동 시점의 Top Wait Event를 확인한 결과, Idle Event(= SQL*Net message from client)를 제외


MaxGauge Case Study

한 Top Wait Event는 latch free임이 확인 된다.

Active Session의 급증에 대한 latch free 대기이벤트의 연관성을 규정하기 위해, 대기이벤트와의 발생패턴을 비교해 본 결과, 「Active Session」의 발생 추이와 상당히 유사하고, 문제시점에 발생한 Wait Events(Wait Time)의 약 74%（전체 392.53초 중에서, 291.91초를 점유 함）를 차지하고 있는 점에서, Active Session의 급

증은 latch free 대기이벤트의 급격한 발생과 연관이 있음을 추측할 수 있다.

실제로, 같은 시점의 상세데이터를 표시하는 Grid화면에서도, latch free 대기이벤트가 Top Wait Event이며, 그 중에서도 latch free(shared pool) 및 latch free(library cache) 대기 이벤트가 많이 발생해 있음을 확인할 수 있

다.


MaxGauge Case Study

3. Wait Event(Latch Free)발생원인의 조사

(출처：Oracle Database성능 튜닝 가이드、Oracle)

latch free 대기이벤트의 발생원인에는 여러 가지가 있으나, 상기 ｢Oracle Database성능 튜닝 가이드｣ 에서도 참

조할 수 있듯이, 일반적으로 latch free (shared pool) 과 latch free (library cache) 대기이벤트가 동시에 발생한 경

우에는 하드 파싱이 그 원인일 경우가 많다. 그 내용을 확인하기 위해 파싱 관련지표인 parse count (hard), parse time cpu, parse time elapsed 의 추이를 확인해 본다.

추이그래프의 분석결과, Active Session이 급증한 시점에서 parse time elapsed의 값이 20,000 centi-sec / sec(= 200sec / sec)로 높아져 있고, 성능저하 현상이 발생하기 전 (09시26분)의 parse count (hard)의 값이 200회 /초 발생했던 사실을 확인할 수 있다. 이를 통해 전 시점의 과다한 하드 파싱으로 인한 일회성 SQL들에 의해 Shared Pool에 memory fragmentation이 발생하였고, 이로 인해 Library Cache에서의 SQL검색이나 신규 SQL의 등록 등을 수행할 시에 지연현상이 발생하고 있는 것으로 분석된다.


MaxGauge Case Study

4. 세션 및 SQL의 분석을 통한 문제원인의 규명

Hard parsing의 수행이 많았던 09시00분 ~ 09시30분간에서, parse count (hard)의 값이 ｢ 1초에 10회 이상｣ 인 세

션을 검색해 본 결과, ｢ 1초에 100회 이상 ｣ 하드 파싱을 수행한 세션은 대부분이 「JDBC Thin Client」 프로

그램임을 확인할 수가 있다.

과다하게 하드 파싱을 수행하고 있는 위의 세션을 조사해 본 결과, 대부분이 유사한 SQL을 사용하고 있고, 바

인드 변수를 사용하지 않은 ｢ Literal SQL｣ 임이 판명 된다.


MaxGauge Case Study

5. 결론 및 해결방안 Performance Slow-Down현상

(Latch free대기이벤트의 급증에 의한 Active session의 급증)

바인드 변수를 사용하지 않은 Literal SQL에 의한 Hard parsing의 과다한 수행

Prepared Statement의 사용을 통해 JDBC P/G내의 Literal SQL을 제거 손쉬운 문제원인 SQL의 추적을 위해 ｢DBMS_APPLICATION_INFO｣

패키지의 사용


literal sql에 의한 hard parsing으로 인한 성능 저하_maxgauge case study

Education