1. Library Cache Lock

▣ 라이브러리 캐시 구조

▣ 라이브러리 캐시 Lock

- 라이브러리 캐시 Lock은 라이브러리 캐시 오브젝트(LCO)에 대한 핸들을 보호한다.

- Lock의 모드

Shared : 읽기작업

Exclusive : 생성 또는 변경작업

Null : Lock을 장시간 유지할 때, 대기는 발생시키지 않고 오브젝트간 의존성 관리

- Lock 모드간 호환성

- (실험) 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