1. Library Cache Lock
2010.07.17 14: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 | 8. 애플리케이션 커서 캐싱 | 토시리 | 2010.06.29 | 6743 |
26 | 9. Static vs. Dynamic SQL [1] | balto | 2010.07.03 | 18610 |
25 | 10. Dynamic SQL 사용 기준 | balto | 2010.07.03 | 8762 |
24 |
11. Static SQL 구현을 위한 기법들
![]() | 실천하자 | 2010.07.04 | 12274 |
23 |
4. Array Processing 활용
![]() | 휘휘 | 2010.07.04 | 21043 |
22 | 1. Call 통계 | 실천하자 | 2010.07.04 | 10605 |
21 |
5. Fetch Call 최소화
![]() | 휘휘 | 2010.07.05 | 17113 |
20 | 5장. 데이터베이스 Call 최소화 원리 | 휘휘 | 2010.07.05 | 6243 |
19 |
2. User Call vs. Recursive Call
![]() | 토시리 | 2010.07.07 | 9193 |
18 |
3. 데이터베이스 Call이 성능에 미치는 영향
![]() | 토시리 | 2010.07.07 | 11806 |
17 | 6장. I/O 효율화 원리 | 휘휘 | 2010.07.07 | 6556 |
16 |
4. Prefetch
![]() | balto | 2010.07.10 | 28601 |
15 |
5. Direct Path I/O
![]() | balto | 2010.07.10 | 12355 |
14 | 8. PL/SQL 함수 호출 부하 해소 방안 | 토시리 | 2010.07.11 | 14225 |
13 | 6. 페이지 처리의 중요성 | 실천하자 | 2010.07.11 | 6973 |
12 | 2. Memory vs. Disk I/O | 휘휘 | 2010.07.11 | 7571 |
11 | 3. Single Block vs. Multiblock I/O | 휘휘 | 2010.07.11 | 9331 |
10 | 7. PL/SQL 함수의 특징과 성능 부하 | 실천하자 | 2010.07.12 | 12768 |
9 |
1. 블록 단위 I/O
![]() | 토시리 | 2010.07.12 | 9531 |
» |
1. Library Cache Lock
![]() | balto | 2010.07.17 | 12948 |