표준방식이 아니라서 ALTER SESSION...을 사용하면 안된다는데 이유가 궁금해서 정리함
me.sap.com/servicessupport 관련 노츠를 검색해도 잘 안나오는듯
cursor_sharing 파라메터 재정리
- 목발같은 파라메터인듯 다리가 나을때까지 임시적으로 사용하기 좋은 도구
- SAP PO에서는 채널에 BindMode로 하는게 좋을것 같음?
- 일시적인 바인드변수에 대한 하드파싱 문제 해결할수 있지만.. 완전한 해결책은 아님
- 하드파싱은 SQL 처음 실행 시 Shared Pool,Library Cache에 없어 완전히 전부 새로 파싱을 한다는 의미라고 함
- 리터널 sql문을 많이 사용하면 하드파싱 빈도를 높이게 된다고 함
- 파스과정 완료 후 sql문자과 실행계획이 공유풀 한 영역의 라이브러리 캐시에 저장 → 성능개선
- 파스(Parse)과정: sql실행 → 하드파싱 → sql오류확인 → sql테이블,컬럼,권한 확인 → 효율적인sql문장변환 → 어떤방식으로 실행할지 선택
- 라이브러리 캐시 경합을 일시적으로 해결하기 위한 파라메터 → 고려할수있는부분
- 오라클 9i의 성능향상 내용에서의 Optimizer개선 내용
- 옵티마이저는 최적화 Optimization은 손실함수 Loss Function의 결과값을 최소화하는 모델 파라미터(강중치)를 찾는 것을 의미한다고 함
- 오라클 8.1.6에서 새로 추가된 기능 → EXACT,FORCE값 사용
- ALTER SYSTEM SET cursor_sharing = FORCE로도 사용가능
- 오라클 9I에서는 CURSOR_SHARING=SIMLAR로 지정 가능
- FORCE사용 시 바람직하지 않은 실해 계획을 선택하는 단점 개선
- 바인딩 사용안하는 SQL을 많이 사용하는 경우 컴파일 과정의 오버헤드를 줄일수 있다고 함
- 실행계획공유,재활용 수준 개선 → 효과는 제한적
- SQL Injection 공격방지 효과를 기대할수 없다고 함
- ALTER SESSION은 현 세션에만 영향 → 영구적인 부분은 DBA에 요청필요
- auto binder라고 하며 올바른 방향이지만 최종 해결책이나 장기적으로 사용하는건 주의필요 → 커서공유로 인해 발생하는 부작용도 있는듯
- 쿼리에서 모든 문자열,숫자 상수 제거 → 옵티마이저가 작업정보 줄어듬 → 쿼리 계획이 달라짐
- 쿼리 아웃풋 관련 문제 쿼리에서 열의 길이가 예기치 않게 변경? → 애플리케이션의 영향받을수 있음 → VARCHAR열에서 반환된 패딩으로 인한 애플리케이션 중단된적도 있다고 함(올바른 동작?)
- 쿼리튜닝이 어려워진다고 함 → SQL플러스의 자동 추적기능에서 커서공유 사용 시 안정적이지 않을수 있다고 함
CURSOR_SHARING=FORCE,EXACT,SIMLAR 차이
- FORCE,SIMLAR 등 파라메터 비교 사이트 → CURSOR_SHARING initialization parameter tips and tricks
- 파라메터 기본값은 EXACT이고 SQL이 100% 같을때만 커서공유 된다고 함
- FORCE인 경우 리터럴값만 다를경우 시스템이 자동생성한 바인드 변수로 대체
- 어떤값으로 실행하든 항상 동일한 실행계획을 사용한다고 함
- EXACT보다 라이브러리 캐시 부하 줄지만 컬럼 히스토그램 사용하지 못하는 문제 발생 → 성능저하
- histogram이란 컬럼값 출현빈도,분포,분산정도를 그래피컬하게 나타낸것
- EXACT보다 개별 쿼리 성능은 더 나빠질 수 있음 → 이 단점을 회피할 목적으로 SIMLAR로 설정
- 리터널 값에 따라 별도 커서 생성 → 다른 실행계획을 사용할수 있게된다고 함
댓글 없음:
댓글 쓰기