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
| 번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
|---|---|---|---|---|
| 67 |
Front Page
 | 운영자 | 2010.05.17 | 154865 |
| 66 |
4. Prefetch
| balto | 2010.07.10 | 28434 |
| 65 |
5. 오라클 Lock
| 휘휘 | 2010.06.07 | 26368 |
| 64 |
2. DB 버퍼 캐시
| 휘휘 | 2010.05.24 | 21916 |
| 63 |
3. SQL 트레이스
| balto | 2010.06.06 | 21175 |
| 62 |
1. 기본 아키텍처
[1] | 휘휘 | 2010.05.23 | 19899 |
| 61 |
2. 트랜잭션 수준 읽기 일관성
| 휘휘 | 2010.06.07 | 19568 |
| 60 |
5. Undo
| 토시리 | 2010.05.31 | 18650 |
| 59 |
11. Shared Pool
| 실천하자 | 2010.05.31 | 18511 |
| 58 | 9. Static vs. Dynamic SQL [1] | balto | 2010.07.04 | 18343 |
| 57 |
4. Array Processing 활용
| 휘휘 | 2010.07.05 | 18239 |
| 56 | 1 장. 오라클 아키텍처 | 운영자 | 2010.05.20 | 17842 |
| 55 |
5. Fetch Call 최소화
| 휘휘 | 2010.07.05 | 16839 |
| 54 | 9. ASH(Active Session History) | 실천하자 | 2010.06.14 | 15607 |
| 53 |
2. SQL 처리과정
| 휘휘 | 2010.06.28 | 15340 |
| 52 | 3. 버퍼 Lock [1] | 휘휘 | 2010.05.24 | 15225 |
| 51 |
6. 바인드 변수의 부작용과 해법
| 실천하자 | 2010.06.28 | 14665 |
| 50 | 1. Explain Plan | 실천하자 | 2010.06.06 | 14663 |
| 49 | 8. PL/SQL 함수 호출 부하 해소 방안 | 토시리 | 2010.07.11 | 14023 |
| 48 | 7. Result 캐시 | 휘휘 | 2010.07.19 | 12969 |