1. HOME
  2. [종료]코어 오라클 데이터베이스 스터디
  3. 5차 코어 오라클 데이터베이스 스터디
  4. Shared Pool 관련 Latch

Shared Pool 관련 Latch (by kwlee55) [2010.09.09]

SQL 실행을 보호하는 Latch

1. shared pool latch

  • shared pool의 Heap Area 탐색 및 Free Chunk 할당 작업을 보호
  • shared pool latch의 개수는 shared pool에 하나씩
  • shared pool 은 7개까지 설정 가능

<활성화된 shared pool latch 확인>

2. library cache latch

  • library cache 영역의 탐색 및 변경 작업을 보호
  • library cache latch의 개수는 CPU개수보다 큰 소수 중 가장 작은 수로 설정

<현재 사용중인 library cache latch 확인>

shared pool latch 경합

1. Freelist와 같은 Heap Area를 탐색하기 위해서 shared pool latch 획득 필요
2. Hard Parsing과 같이 메모리에 저장되는 작업이 심해질 경우 경합 발생 가능
3. 경합 해결 방안

  • Bind SQL사용
  • CUSROR_SHARING 파라메터 사용 검토 (session level 적용 권장)
  • Shared Pool 크기 감소
    • freelist의 길이를 줄여 chunk들의 탐색시간을 줄일 수 있다.
    • ORA-4031 에러 발생 확률이 높아진다.
    • Shared Pool에 상주할 수 있는 객체의 수가 줄어들어 부가적인 하드파싱 유발 할 수 있다. 자주 사용하면서 크기가 큰 객체등은 DBMS_SHARED_POOL_KEEP프로시저를 이용하여 영구적으로 상주시킨다.
  • sub pool 사용
    • 최대 7개의 서브 풀로 나누어 관리 가능 (9i)
    • CPU개수가 4개 이상이고 shared pool zmrlrk 250MB이상인 경우 _KGHDSIDX_COUNT 값 만큼 서브 풀을 생성할 수 있다.
    • 각각의 서브 풀이 독립적으로 관리되어, 각 서브 풀마다 freelist, LRU list, shared pool latch를 가지게 되어 경합을 줄일 수 있다.

4. latch:shared pool : Shared Pool의 free chunk를 탐색하기 위해 shared pool latch를 획득할 때까지 대기하는 이벤트

library cache latch 경합

1. Library Cache 체인 검색시 반드시 library cache latch 획득 필요

2. 대기 발생 사유

  • Soft/Hard Parsing 모두에서 빈도가 증가함에 따라 경합 발생 가능
    • 하드파싱이 많이 발생하면 Library Cache 를 탐색하는 회수가 늘어나므로 그 만큼 library cache 래치를 보유하는 시간과 회수가 늘어난다.
    • 하드파싱의 경우 Library Cache 영역에 대한 탐색뿐만 아니라 추가적인 청크 할당이 필요하기 때문에 그만큼 library cache 래치를 보유하는 시간이 늘어난다.
    • 소프트파싱은 하드파싱에 비해 그 비용이 매우 싸긴 하지만 신택스(Syntax) 체크 / 시맨틱(Semantics) 체크 / Library Cache 탐색 등의 과정은 피할 수 없다. 이 과정에서 Library Cache를 탐색하는 동안 library cache 래치를 획득해야만 한다. 따라서 많은 세션이 동시에 소프트파싱을 수행하는 경우 library cache 래치 경합에 의한 성능 저하 현상이 발생한다.
  • 버전 카운트(Version count)가 높은 경우
    • 자식 LCO 탐색으로 인해 library cache를 탐색하는 시간이 증가하며 이로 인해 library cache 래치 경합이 증가한다.
  • SGA영역의 페이지 아웃(Page out)이 발생하는 경우
    • Shared Pool이 디스크로 페이지 아웃된 경우, 해당 영역에 대한 스캔이 발생할 때 다시 디스크의 내용을 메모리로 불러들이는 과정동안 대기해야 하므로 library cache 래치에 대한 대기시간이 증가할 수 있다.

3. 경합 해결 방안

  • 파싱회수를 줄인다.
    • 파싱 회수를 줄이면 그만큼 library cache 래치 경합을 줄일 수 있다. ( Java 환경의 경우 PreparedStatement 객체 이용, 특정 Web Application Server의 경우 Statement Cache 기능 이용)
    • PL/SQL의 Dynamic SQL을 사용할 때는 커서(Cursor) 재사용이 불가하여 library cache 래치 경합이 증가할 수 있다. Statis SQL 사용한다.
  • SESSION_CACHED_CURSORS 파라미터
    • SESSION_CACHED_CURSORS 파라미터 값이 세팅되어 있으면 오라클은 세 번 이상 수행된 SQL 커서에 대한 정보를 PGA내에 보관한다. (기본값은 버전마다 다르다. 기본값이 작다면 되도록이면 50 이상의 값을 설정)

4. latch:library cache : library cache chain을 탐색하기 위해 library cache latch를 획득할 때까지 대기하는 이벤트

5. library cache latch를 획득한 상태에서 Library Cache 영역을 탐색하고 필요에 따라 Heap을 할당해야 할 경우 shared pool latch를 획득한다.

문서에 대하여

  1. HOME
  2. [종료]코어 오라클 데이터베이스 스터디
  3. 5차 코어 오라클 데이터베이스 스터디
  4. Shared Pool 관련 Latch