[ OZ Report ] Literal SQL 때려잡기

[ 1 ] 문제

공공 차세대 프로젝트에 DB 튜너로 투입되었습니다.

OZ Report에서 질의하는 SQL이 Literal Sql로써, Hard Parsing 처리 되는 문제점을 확인 하였습니다.

즉, SQL 질의하면 매번 많은 "실행계획 생성 > Cost 평가 > 그 중 가장 낮은 실행계획 선택 > 소스 생성 " > SQL 실행 됩니다.

DB CPU 사용률, SQL Parsing Time 증가 되는 현상이 발생되며, Report 사용이 많을 수록 그 현상은 뚜렷해집니다.

​

​​

[ 2 ] 해결 방법

- ODI 파일 > 데이터 셋(마다) 속성 > "컴파일된 질의문 사용" > True 변경

​

​

[ 3 ] 검증

1. "컴파일된 질의문 사용" > FALSE > 2번 질의 > DB SQL 조회

: SQL Cursor가 2개 생성됨 ( 즉, 값이 다르게 SQL질의할때 마다 신규 SQL Cursor가 생성됨 )

Literal SQL 발생 중인 오즈레포트 SQL

2. "컴파일된 질의문 사용" > TRUE > 2번 질의 > DB SQL 조회

: SQL Cursor 1개로 공유되어 사용됨.

바인딩 변수 처리된 오즈 레포트 SQL

​

​

[ 4 ] 상세 이해하기

일반적인 웹어플리케이션 개발시 SQL 처리를 위해 Mybatis를 자주 이용합니다.

그리고 SQL 바인딩 처리방법은 매우 공유가 잘 되어 있습니다.

​

Mybatis에서 SQL 작성시 파라메터값을 주입하려면, SQL에 #{EMPNO} or ${EMPNO} 2가지 사용가능합니다.

대부분 아시겠지만, #{EMPNO}를 권장합니다.

​

1) ${EMPNO}

- JDBC의 Statement 객체 이용과 동일한 효과

- SQL Injection 노출

- 하드파싱되므로 바인딩처리한 SQL 보다 Parsing Time 길어짐

- DB Shared Pool > Library Cache 영역에 불필요한 자원이 등록됨

​

2) #{EMPNO}

- JDBC의 PreparedStatement 객체 이용과 동일한 효과

- SQL Injection 예방

​

이제 오즈로 돌아오겠습니다.

​

즉, 오즈는 아래 데이터 셋 속성을 Default로 하여 사용하게 되면, 위 Mybatis의 ${EMPNO} 사용과 동일한 효과를 겪게

됩니다. 그러므로 "컴파일된 질의문 사용" TRUE로 변경하여 테스트 후 이상 없다면 점진적으로 적용해보시길 권장드립니다. ( 책임 소재 >,.< 따지지 말기~ )

​

​

​

[ 기대 효과 ]

: 2018년도에 개발자로 근무할 당시 오즈레포트 데이터 셋 속성을 기본으로 사용하다가, "컴파일된 질의문 사용"을 true로

변경한 후 DB "Hard Parse Count"와 "PARSE TIME CPU" 추이 분석한 자료 입니다.

REPORT를 매우 많이 사용하는 곳일 수록 효과가 더 큽니다.

​

HARD PARSE COUNT 추이분석

PARSE TIME CPU 추이 분석

​

​

​

[ 아쉬운 점 ]

- 오즈 레포트 회사에서 "컴파일된 질의문 사용"에 대해 직관적인 설명 추가 or 다른 표현 변경 되었으면 합니다.

차라리 "Bind Variable" or "Prepared Statement" 사용 이라던지요.

컴파일 된 질의문 사용은 저도 이제서야 보니 왜 저 명칭을 썼는지 이해가 되지만,

실은 자주 사용하는 분들이 직관적으로 파악하기는 어렵습니다.

다른 속성을 보면 더 햇갈립니다. 바인딩 전, 후 데이터 보내기... 오즈를 알면 저것도 왜 저렇게 했는지..이해가 됩니다.

하지만...오해의 소지가 있습니다.