3. 라이브러리 캐시 구조
2010.06.28 00:15
- 라이브러리 캐시 : Shared Pool에 위치하며 SQL 공유 커서 및 데이터베이스 오브젝트에 대한 정보를 관리한다. PL/SQL Area(프로시저, 함수, 패키지, 트리거)도 포함한다.
- (정의) 실행가능 LCO : 실행가능한 SQL 커서나 PL/SQL 오브젝트
- (정의) 오브젝트 LCO : 테이블, 인덱스, 클러스터 같은 데이터베이스 오브젝트(데이터 딕셔너리 캐시에도 저장되어 있지만 LCO 간의 의존성을 관리하기 위하여 저장)
▣ 라이브러리 캐시의 내용
(실험) 라이브러리 캐시에 저장된 오브젝트 보기
select namespace, gets, pins, reloads, invalidations
from v$librarycache;
NAMESPACE | GETS | PINS | RELOADS | INVALIDATIONS |
SQL AREA | 6321 | 93511 | 905 | 99 |
TABLE/PROCEDURE | 8444 | 19849 | 1168 | 0 |
BODY | 370 | 535 | 48 | 0 |
TRIGGER | 232 | 382 | 18 | 0 |
INDEX | 288 | 1767 | 24 | 0 |
CLUSTER | 266 | 708 | 8 | 0 |
OBJECT | 0 | 0 | 0 | 0 |
PIPE | 0 | 0 | 0 | 0 |
JAVA SOURCE | 0 | 0 | 0 | 0 |
JAVA RESOURCE | 0 | 0 | 0 | 0 |
JAVA DATA | 0 | 0 | 0 | 0 |
(설명) v$librarycache에 저장되는 내용
- Stored Object : 영구적으로 저장되는 테이블, 인덱스, 클러스터, 뷰, 트리거, 패키지 등
- Transient Object : 일시적으로 저장되는 커서, 이름없는 pl/sql 등
▣ 라이브러리 캐시 내의 shares pool latch 의 내용
(실험) 라이브러리 캐시 7개까지 latch 사용
select child#, gets, misses, sleeps, immediate_gets, immediate_misses
from v$latch_children
where name='shared pool'
order by child#;
CHILD# | GETS | MISSES | SLEEPS | IMMEDIATE_GETS | IMMEDIATE_MISSES |
1 | 278105 | 333 | 37 | 0 | 0 |
2 | 11 | 0 | 0 | 0 | 0 |
3 | 11 | 0 | 0 | 0 | 0 |
4 | 11 | 0 | 0 | 0 | 0 |
5 | 11 | 0 | 0 | 0 | 0 |
6 | 11 | 0 | 0 | 0 | 0 |
7 | 11 | 0 | 0 | 0 | 0 |
▣ 라이브러리 캐시 관리 구조
- 라이브러리 캐시는 해시 구조로 관리된다.
- LCO 핸들이 체인으로 연결되어 있고 핸들을 통해 LCO를 찾아간다.
- LCO emp, sql 문 등이 라이브러리 캐시에 적재되어 있음,
- sql 문이 같은데 공유하지 못하는 경우 child 커서를 만든다.
- library cache latch를 먼저 획득하여 접근한다.
select child#, gets, misses, sleeps, immediate_gets, immediate_misses
from v$latch_children
where name='library cache'
order by child#;
- LCO에 대한 라이브러리 캐시 LOCK과 라이브러리 캐시 pin을 사용한다.
LOC 접근시 : 핸들에 대한 Lock 획득 -> 힙에 대한 pin 획득 및 pin 걸기
- shared pool 래치와 library cache 래치 경합은 soft/hard 파싱이 심하게 일어날 EO 발생하고, library cache lock과 librar y cache pin 대기 이벤트는 SQL 수행 중 DDL을 날릴때 사용한다. 트랜잭션이 활발할 때 DDL 문을 수행하면 라이브러리 캐시에 부하가 유발된다.
▣ 라이브러리 캐시 최적화를 위한 튜닝 기법
(1) 커서를 공유할 수 있도록 SQL을 작성한다. - 바인드 변수에 주의한다.
(2) 세션 커서 해싱 기능을 이용하여 라이브러리 캐시에서 SQL을 찾는 비용을 줄인다.
(3) 애플리케이션 커서 캐싱을 이용해 Parse Call 발생량을 줄인다.
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
27 | 8. 애플리케이션 커서 캐싱 | 토시리 | 2010.06.29 | 6610 |
26 | 9. Static vs. Dynamic SQL [1] | balto | 2010.07.04 | 18343 |
25 | 10. Dynamic SQL 사용 기준 | balto | 2010.07.04 | 8643 |
24 | 11. Static SQL 구현을 위한 기법들 | 실천하자 | 2010.07.05 | 12084 |
23 | 4. Array Processing 활용 | 휘휘 | 2010.07.05 | 18239 |
22 | 1. Call 통계 | 실천하자 | 2010.07.05 | 10442 |
21 | 5. Fetch Call 최소화 | 휘휘 | 2010.07.05 | 16839 |
20 | 5장. 데이터베이스 Call 최소화 원리 | 휘휘 | 2010.07.05 | 6102 |
19 | 2. User Call vs. Recursive Call | 토시리 | 2010.07.07 | 9050 |
18 | 3. 데이터베이스 Call이 성능에 미치는 영향 | 토시리 | 2010.07.07 | 11664 |
17 | 6장. I/O 효율화 원리 | 휘휘 | 2010.07.08 | 6404 |
16 | 4. Prefetch | balto | 2010.07.10 | 28434 |
15 | 5. Direct Path I/O | balto | 2010.07.10 | 12190 |
14 | 8. PL/SQL 함수 호출 부하 해소 방안 | 토시리 | 2010.07.11 | 14023 |
13 | 6. 페이지 처리의 중요성 | 실천하자 | 2010.07.11 | 6820 |
12 | 2. Memory vs. Disk I/O | 휘휘 | 2010.07.12 | 7439 |
11 | 3. Single Block vs. Multiblock I/O | 휘휘 | 2010.07.12 | 9167 |
10 | 7. PL/SQL 함수의 특징과 성능 부하 | 실천하자 | 2010.07.12 | 12601 |
9 | 1. 블록 단위 I/O | 토시리 | 2010.07.12 | 9380 |
8 | 1. Library Cache Lock | balto | 2010.07.17 | 12801 |