개요
두 대기 이벤트는 오라클의 라이브러리 캐시(Library Cache) 내에 있는 객체(SQL, 프로시저, 테이블 정의 등)를 보호하기 위한 직렬화 메커니즘에서 발생한다.
- LOCK은 ‘정의(Definition)‘를 보호
- PIN은 ‘실행(Execution)‘을 보호
| 구분 | Library Cache Lock | Library Cache Pin |
|---|---|---|
| 보호 대상 | 오브젝트의 핸들(정의, 구조) | 오브젝트의 힙(실체, 실행 코드) |
| 주요 작업 | 파싱(Parsing), DDL | 실행(Execution), 컴파일(Compilation) |
| 발생 시점 | 오브젝트를 찾고 정의를 확정할 때 | 오브젝트를 실제 사용할 때 |
| 해결 핵심 | 과도한 하드 파싱 억제, DDL 시간 조절 | 실행 중인 오브젝트 수정 금지 |
1. Library Cache Lock
오브젝트의 **정의(구조)**를 변경하거나 참조할 때, 다른 세션이 동시에 변경하지 못하도록 제어하는 단계에서 발생한다.
-
용도: 오브젝트의 핸들(Handle)에 대해 획득하며, 해당 오브젝트의 정의를 보장받기 위함이다.
-
주요 발생 상황:
-
ALTER TABLE,DROP TABLE등 DDL 수행 시. -
SQL 문장을 파싱(Hard Parse)하는 동안 해당 오브젝트의 정의가 바뀌면 안 되므로 Lock을 획득한다.
-
-
경합 원인: * 특정 테이블에 대해 DDL을 수행 중인데 다른 세션이 해당 테이블을 참조하는 SQL을 파싱하려고 할 때.
- 빈번한 하드 파싱으로 인해 Shared Pool 내의 부하가 높을 때.
2. Library Cache Pin
이미 Lock을 획득한 오브젝트를 **실행(Execute)**하거나 컴파일하기 위해 실제 메모리 상의 데이터(Heap)를 고정하는 단계에서 발생한다.
-
용도: 실행 중인 코드가 메모리에서 밀려나거나(Age-out) 변경되는 것을 방지하기 위함이다.
-
주요 발생 상황:
-
프로시저, 패키지, 함수 등을 실행할 때.
-
패키지나 프로시저를 재컴파일(
ALTER ... COMPILE)할 때.
-
-
경합 원인:
- 가장 전형적인 케이스: 세션 A가 긴 프로시저를 실행 중(Pin 획득)인데, 세션 B가 해당 프로시저를 수정/컴파일(Lock 획득 후 Pin 요구)하려고 할 때 발생한다.
3. Lock과 Pin의 관계 (동작 순서)
오라클이 라이브러리 캐시 오브젝트에 접근할 때는 반드시 다음 단계를 거친다.
-
Lock 획득: 오브젝트 핸들을 찾아 Lock을 건다. (정의 보호)
-
Pin 획득: 오브젝트의 실제 내용(Executable Code)이 들어있는 메모리 블록을 고정한다. (실행 보호)
-
작업 수행: SQL 실행 또는 컴파일.
-
해제: Pin 해제 후 Lock 해제.
5. 조치사항
이 대기 이벤트들이 상위에 나타난다면 시스템에 ‘블로킹(Blocking)’ 현상이 발생하고 있다는 신호다.
-
DBA 조치:
v$session_wait또는v$libcache_locks(11g 이상) 뷰를 조회하여 **Holder(점유자)**와 **Waiter(대기자)**를 식별해야 한다. -
어플리케이션 측면: 서비스 운영 중에 대량의 DDL을 수행하거나 패키지를 컴파일하는 행위를 피해야 한다.