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 | 9. ASH(Active Session History) | 실천하자 | 2010.06.14 | 15607 |
| 26 | 8. Statspack / AWR | balto | 2010.06.13 | 12767 |
| 25 |
7. Response Time Analysis 방법론과 OWI
 | balto | 2010.06.13 | 8066 |
| 24 |
5. 오라클 Lock
| 휘휘 | 2010.06.07 | 26368 |
| 23 | 4. 동시성 구현 사례 | 토시리 | 2010.06.07 | 10939 |
| 22 | 3. 비관적 vs. 낙관적 동시성 제어 | 휘휘 | 2010.06.07 | 8210 |
| 21 |
2. 트랜잭션 수준 읽기 일관성
| 휘휘 | 2010.06.07 | 19568 |
| 20 | 4. DBMS_XPLAN 패키지 | balto | 2010.06.06 | 10461 |
| 19 |
3. SQL 트레이스
| balto | 2010.06.06 | 21175 |
| 18 | 3장. 오라클 성능 관리 | 운영자 | 2010.06.06 | 6697 |
| 17 | 2. AutoTrace | 실천하자 | 2010.06.06 | 8597 |
| 16 | 1. Explain Plan | 실천하자 | 2010.06.06 | 14663 |
| 15 | 2장. 트랜잭션과 Lock | 운영자 | 2010.06.01 | 6895 |
| 14 |
6. 문장수준 읽기 일관성
| 토시리 | 2010.06.01 | 10432 |
| 13 | 1. 트랜잭션 동시성 제어 | 실천하자 | 2010.05.31 | 8631 |
| 12 |
5. Undo
| 토시리 | 2010.05.31 | 18654 |
| 11 |
11. Shared Pool
| 실천하자 | 2010.05.31 | 18511 |
| 10 | 8. 블록 클린아웃 | 휘휘 | 2010.05.31 | 12283 |
| 9 | 7. Consistent vs. Current 모드 읽기 | 휘휘 | 2010.05.31 | 10537 |
| 8 | 10. 대기 이벤트 | balto | 2010.05.30 | 8011 |