1. Library Cache Lock
2010.07.17 23:42
▣ 라이브러리 캐시 구조
▣ 라이브러리 캐시 Lock
- 라이브러리 캐시 Lock은 라이브러리 캐시 오브젝트(LCO)에 대한 핸들을 보호한다.
- Lock의 모드
Shared : 읽기작업
Exclusive : 생성 또는 변경작업
Null : Lock을 장시간 유지할 때, 대기는 발생시키지 않고 오브젝트간 의존성 관리
- Lock 모드간 호환성
Lock 모드 | Null | Shared | Exclusive |
Null | O | O | O |
Shared | O | O | X |
Exclusive | O | X | X |
- (실험) 1번 때문에 2번이 대기하는 것을 3번으로 관찰하였다.
(프로그램) | |
1 | create table t( id number, name char(10)); insert into t select rownum, lpad( rownum, 10, '0' ) from dual connect by level <= 1000000; commit; alter table t modify name char(20); /* 시간이 걸리는 작업 */ |
2 | select sid from v$mystat where rownum = 1; select count(*) from t; /* 대기 상태 - library cache lock */ |
3 | select event, wait_time, seconds_in_wait, state, p1text || '->' || p1 || ' , ' || p2text || '->' || p2 ||' , '||p3text||'->' ||p3 param from v$session_wait where sid = '141'; (결과) EVENT WAIT_TIME SECOMDS IN_WAIT STATE PARAM -------------------------------------------------- library cache lock 0 11 WAITING ... |
- NULL 모드는 Lock을 장시간 유지할 때 사용, 커서는 항상 널 모드 사용, 언제든지 요청이 있으면 break 된다.
- 스키마 오브젝트는 변경되거나 Drop 되면 커서를 참조하는 LOC는 무효화되어야 한다. 커서는 자기가 참조하는 객체에 대하여 Parse Lock을 보유한다. 객체가 변경되면 Parse Lock 해제되고 커서는 무효화된다.
▣ 라이브러리 캐시 Pin
- 라이브러리 캐시 Pin은 LCO 내용이 담긴 힙영역을 보호한다.
- 프로세스는 LCO에 대한 Pin을 얻어서 읽고, 변경, 실행한다.
Null Lock이 해제된 상태이면 Pin 연산은 실패하게 된다.
Lock을 얻고 Pin하려는 순간 힙의 내용이 캐시에서 밀려나면 다시 적재해야한다.
- 하드파싱을 하게 되면 SQL 트레이스에서 다음 항목을 발견할 수 있다
Misses in library cache during parse: 1
- library cache miss가 Execute 단계에서 나타날 수도 있다. 이유는 실행단계에서 LCO 힙에서 밀려나 있을 수 있기 때문이다.
Misses in library cache during parse: 1
Misses in library cache during execute: 1
- Pin의 모드
Share (읽기 작업)
Exclusive (Shared 모드에서 에러와 보안 체크한 후 변경작업시 Exclusive 모드)
▣ 라이브러리 캐시 Lock과 Pin, 두 개의 직렬화 장치를 따로 두는 이유
- LCO 타입에 따른 Lock과 Pin
LCO 타입 | LOCK | Pin |
테이블, 인덱스, 클러스터 | 생성, 변경시 Exclusive 읽을때 Share | 변경할떄 Exclusive 읽을때 Share |
함수, 프로시저, 패키지 | 컴파일때 Exclusive 읽을때 Share 실행할 때 Null | 컴파일할 때 Share 실행할 때 Share |
SQL 커서 | 항상 Null | 커서찾을때 Share 하드파싱할 때 Exclusive |
- 라이브러리 캐시 Lock과 Pin 메커니즘 예 1
DEPT 테이블 변경 -> get_dname() 함수에 대한 Parse Lock 해제 -> select 문 해제
-> get_dname() 함수 컴파일 작업은 진행 가능...
- 라이브러리 캐시 Lock과 Pin 메커니즘 예 2
select 문 실행 중 -> Shared 모드로 pin 설정 -> get_dname() 함수도 Shared 모드로 pin 유지 -> DEPT 테이블 변경
-> Parse Lock 모두 해제 -> select 문 실행 중이므로 pin은 유지 -> get_dname() 컴파일하려면 library cache pin 대기 이벤트 발생
- 하나의 LCO에 대해서 Lock과 Pin 2개의 직렬화 장치를 둔다.
LCO 핸들은 영구적인 Fixed Array 영역에 할당되고 LCO는 힙영역에 할당된다.
LCO의 정합성은 Pin으로 보장되고, 별도로 Lock을 두어 동시성을 높인다.
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
27 | 5. V$SYSSTAT [1] | 토시리 | 2010.06.14 | 9849 |
26 | 1. 블록 단위 I/O | 토시리 | 2010.07.12 | 9381 |
25 | 4. 커서 공유 | balto | 2010.06.28 | 9200 |
24 | 3. Single Block vs. Multiblock I/O | 휘휘 | 2010.07.12 | 9172 |
23 | 2. User Call vs. Recursive Call | 토시리 | 2010.07.07 | 9050 |
22 | 10. Dynamic SQL 사용 기준 | balto | 2010.07.04 | 8643 |
21 | 1. 트랜잭션 동시성 제어 | 실천하자 | 2010.05.31 | 8632 |
20 | 2. AutoTrace | 실천하자 | 2010.06.06 | 8599 |
19 | 3. 비관적 vs. 낙관적 동시성 제어 | 휘휘 | 2010.06.07 | 8210 |
18 | 9. Snapshot too old | balto | 2010.05.30 | 8102 |
17 | 11. End-To-End 성능관리 | 휘휘 | 2010.06.14 | 8095 |
16 | 7. Response Time Analysis 방법론과 OWI | balto | 2010.06.13 | 8067 |
15 | 10. 대기 이벤트 | balto | 2010.05.30 | 8012 |
14 | 8. I/O 효율화 원리 | 휘휘 | 2010.07.19 | 7742 |
13 | 2. Memory vs. Disk I/O | 휘휘 | 2010.07.12 | 7439 |
12 | 부록 | 휘휘 | 2010.07.19 | 7238 |
11 | 1. SQL과 옵티마이저 | 휘휘 | 2010.06.28 | 7218 |
10 | 12. 데이터베이스 성능 고도화 정석 해법 | 휘휘 | 2010.06.14 | 7153 |
9 | 4장. 라이브러리 캐시 최적화 원리 | 휘휘 | 2010.06.28 | 6915 |
8 | 2장. 트랜잭션과 Lock | 운영자 | 2010.06.01 | 6896 |