틈틈히 OWI 책을 보면서 공부하는데..
가장 기본이 되는 Latch 와 Lock 관련하여 정리하여 올려본다.
아는 내용도 있지만 그래도 다시 한번 익히는 좋은기회겸..
또 몰랐던 내용도 알 수 있는 거라 공부하면서 Word 로 정리 해봤다.
흠....이쁘게 정리할 수도 있지만...그냥 편하게...ㅎㅎ
복사해서 필요한것만 find 하도록...
래치와 락 (latch & lock) - OWI
By. Louis Kim
래치와 락의 존재 이유는 동시 작업으로 오라클의 자원을 보호하는 것
|
분류 |
래치(Latch) |
락(Lock) |
|
목적 |
하나의 목적을 수행함 : 메모리 구조에 대한 배타적인 접근을 위함 ( 오라클 9i 부터cache buffers chains latch 들은 읽기 전용시에 공유가 가능함 |
두 가지 목적을 수행함: 락 모드가 호환가능하면 다수의 프로세스가 동일한 리소스를 공유하는 것을 허용하며, 락 모드가 호환 가능하지 않으면 리소스에 대한 배타적인 접근만 허용함 |
|
사용범위 |
SGA 내부의 데이터 구조에만 적용. 메모리 오브젝트를 임시적으로 보호함. 단일 오퍼레이션으로 메모리 구조에 대한 접근 제어. 트랜잭션 단위가 아님 |
테이블, 데이터 블록 및 state object와 같은 오브젝트를 보호함. 데이터베이스의 데이터 또는 베타데이터 접근 제어. 트랜잭션 단위 |
|
획득방식 |
두 가지 모드로 요청이 가능 : willing-to-wait 또는 no-wait |
6가지 모드로 요청이 가능 : null, row share, row exclusive, share, share row exclusive 또는 exclusive |
|
범위 |
SGA내부에 정보가 존재하며, 로컬 인스턴스에서만 볼 수 있음 – 래치는 인스턴스 레벨로 작동 |
데이터베이스 내부에 정보가 존재하며, 모든 인스턴스에서 볼 수 있음 – 락은 데이터베이스 레벨에서 작동 |
|
복잡도 |
단순한 명령어를 사용하여 구현됨. 일반적으로 test-and-set, compare-and-swap 또는 단순한 CPU명령어. 구현이 쉬움 |
문맥 교환(context switch)를 포함한 일련의 명령어들을 사용하여 구현됨, 구현이 복잡함 |
|
지속기간 |
아주 짧은 순간만 지속됨 (microsecond 단위) |
일정 시간 동안 지속됨 (트랜잭션 동안) |
|
큐 |
프로세스가 래치 획득을 실패한 후 슬립(sleep) 상태로 들어갈 때, 해당 요청은 큐(queueu)로 관리되지 않으며, 요청한 순서대로 서비스되지 않음(latch wait list를 이용하여 큐 방식으로 사용되는 래치들은 예외임) |
프로세스가 락 획득을 실패한 후, 해당 요청은 큐(queue)로 관리되며, 요청한 순서대로 서비스됨(no-wait 모드는 예외임) |
|
데드락 |
래치는 데드락(deadlock)이 발생되지 않도록 구현됨 |
락은 큐(queue)방식을 사용하며, 데드락이 발생될 가능성이 높다. 데드락이 발생 될 때마다 트레이스 파일이 생김 |
Latch (래치)
- 가벼운 락(lightweight lock) 으로 분류 (아주 빠른 속도로 작동하게끔 구현된 경량화된 락)
- Shared pool 영역에 존재하는 일종의 메모리 구조체
- 매우 간단하고 작은 메모리영역을 사용하며, 래치를 획득(get)하고 해제(release)하는 작업들 또한 하드웨어 맞게 극도로 최적화 되어 있음
- 래치를 획득하고 해제하는 과정은 원자성(atomicity)이 보장
- 래치 획득의 순서를 보장하지 않음. 순서가 보장되어야 하는 작업은 락에서 진행
- 래치는 SGA 리소스를 보호하기 위함
|
- SQL문을 실행하고자 하는 프로세스는 SQL를 shared pool 의 library cache 영역에 올려야하는데, 이 때 heap 메모리 영역을 할당받기 위해 반드시 shared pool 래치를 획득 필요 - 하나의 프로세스만이 힙으로부터 청크(chunk)를 할당받을 수 있음 - select문의 경우 특정 데이터블록을 읽기 위해 데이터블록의 DBA와 Class에 해당하는 Hash chain에 접근하고자 하는 모든 프로세스는 반드시 Hash chain을 관장하는 cache buffers chains Latch를 획득해야 함 - DML를 실행하기 위해서는 PGA영역에 Redo 데이터를 생성 / Redo data를 Redo buffer로 복하기 위해 redo copy latch 가 필요 |
- Latch 획득하기 위해서 특정 대기 이벤트가 필요 (latch free 대기 이벤트 / p1=address , p2=latch# 래치 이름 획득)
- Child latch를 사용하는 메모리 영역들도 있음
- Buffer cache 의 경우 각각의 hash chain을 독립적으로 관리할 수 있는 구조로 되어 있기에 복수개의 cache buffer chains latch 를 사용
Parent Latch(부모래치) : 여러 개의 자식 latch를 거느릴 수 있음
Solitary Latch (독립래치) : 전체 인스턴스에 단 하나만 존재하는 래치
Child Latch (자식 래치) : 부모 래치에 속한 래치
부모 래치와 독립 래치는 V$LATCH_PARENT 뷰를 이용하여 관찰 가능
자식 래치는 V$LATCH_CHILDREN 부를 통해 관찰 가능
- In Memory Undo 의 경우 10g 이후부터 생긴 것이며 KTI-UNDO 영역을 보호하기 위한 in memory undo latch 가 있음
래치 동작 메커니즘
- 여러 프로세스가 동시에 래치를 획득하는 과정에서 데드락 현상 발생(서로 가지고 있는 래치를 요구하는 경우)
- 데드락 발생을 피하기 위해서 자신 보다 낮은 래치의 경우 no-wait 또는 자신이 획득한 래치 레벨보다 높은 레벨을 요청
래치 모드
- 래치는 기본적으로 Exclusive 모드 사용(한 순간에 하나의 프로세스만이 래치를 보유)
- 특정 래치에 대해서는 Shared mode 를 사용( Cache buffers chains Latch)
래치 획득
- Willing-to wait 모드 래치 획득
n 래치 획득하기 위해서 기본적으로 willing-to-wait 모드를 사용(래치를 획득할 때까지 대기를 의미) – 실패 시 적절한 회수만큼 루프를 돌며 획득 시도 (_SPIN_COUNT 기본 2000) – 이후에도 실패 시 래치가 풀릴때가지 sleep
n Sleep 을 바로 하지 않고 spin 하는 이유
1. 아주 빠른 시간안에 다른 프로세스가 래치를 해지할 것이라고 기대
2.
슬립 상태로 빠지게 되면 OS차원에서 Context switching이 발생(이것이 약간의 CPU를 소모하기 때문에 비용적인 측면에서 sleep 보다는 spin이 나음)
cf) spin 과정에서 Active 상태로 CPU를
계속 점유하기 위해서 일정 시간 소량의CPU를 소모(Active
wait) -> 래치 경합에 의해서 많은 수의 프로세스가 동시에 스핀을 수행할 경우 높은 CPU
사용율을 보일 수 있음(래치 경합을 줄이기 위해 CPU를
늘이는 것은 더욱더 상황을 악화 위험)
n Sleep 에서 깨어나는 방법
1. 약속된 시간(타임아웃)
2. Latch wait list에서 자신의 순서가 되어 다른 프로세스가 깨워주는 방법 (latch wait posting)
u 주로 sleep 상태에서 프로세스는 latch:xxx / latch free 이벤트를 대기
u 매번 슬립 시간이 두배로 증가함으로써 빠른 시간내에 래치 획득을 재시도하는 과정에서 지나친 스핀으로 인해 CPU를 과다하게 사용하는 것을 방지
No-wait 모드의 래치 획득
- 대부분의 latch 획득은 willing-to-wait 모드를 사용하지만 특수한 경우 no-wait 모드 사용
- 가장 최근에 획득한 래치보다 더 낮거나 같은 레벨의 래치를 획득하고자 할 때
- 데드락을 피하기 위함
- No-wait 모드의 래치 획득에 실패할 경우 획득하고자 하는 래치보다 높은 레벨의 래치는 모두 해제하고 올바른 순서로 다시 획득 시도
Ex) 1,2,4 레벨의 레치를 획득 후 3레벨 래치 획득 시도 시 no-wait 시도 / 실패 시 1,2 레벨을 남기고 4 레벨 래치 포기 후 3레벨 순서로 획득
래치 cleanup
-
래치를 획득한 후 공유 메모리 영역을 변경하고자 하는 프로세스는 변경 전에 래치복구 영역에(latch recovery area) 자신의 목적에 대한 정보를 기록
이 후, 갑작스럽게 프로세스가 래치를 보유한 채로 종료되면 PMON에서 cleanup function을 호출하여 래치 복구영역에
기록된 정보를 이용하여 복구
래치 관련 Dynamic Views (V$LATCH)
- v$latch_parent : 독립 래치에 대한 통계값을 제공
- v$latch_children : 모든 개별 자식 래치들에 대한 통계값을 제공
|
컬럼 |
설명 |
|
GETS |
Willing-to-wait 모드에서 슬립하기 전의 래치 “요청” 회수 |
|
MISSES |
Willing-to-wait 모드에서의 슬립하기 전의 래치 획득 실패 회수 |
|
SPIN_GETS |
Willing-to-wait 모드에서 슬립하기 전의 스핀단계에서의 래치 획득 성공 회수 |
|
SLEEPS |
Willing-to-wait 모드에서의 슬립 회수 |
|
IMMEDIATE_GETS |
No-wait 모드에서 래치 획득 성공 회수 |
|
IMMEDIATE_MISSES |
No-wait 모드에서 래치 획득 실패 회수 |
|
SLEEP1 ~ SLEEP4 |
1~3 회의 슬립회수와 4회 이상의 슬립 회수. 오라클 10gR2부터는 사용되지 않으며 V$EVENT_HISTOGRAM 뷰로 대체 |
|
WAITERS_WOKEN |
Latch wait posting 을 사용할 경우 세션이 깨어난 회수. 오라클 10gR2 부터는 사용되지 않는다. Latch wait list 래치가 없어진 것과 같은 맥락으로 latch wait posting 알고리즘이 완전히 바뀌었음을 의미 |
|
WAIT_TIME |
래치를 획득하기 위해 대기한 시간(microsecond) 단위 |
- GETS 와 MISSES 비율을 이용하여 경합이 있는지를 판단
- Willing-to-wait 모드일 경우 MISSES / GETS 값, No-wait 모드일 경우에는 IMMEDIATE_MISSES / (IMMEDIATE_GETS + IMMEDIATE_MISSES) 값이 1% 이상이면 래치 경합이 발생한 것으로 판단
- Wait_time 을 이용해 대기시간이 CPU 시간에 비해 어느 정도 높은 값을 보일 경우 래치 경합이 발생한 것으로 판단
일반적인 래치 관련 대기이벤트들
- Latch: cache buffers chains : Buffer cache에서 특정 블록을 탐색하고자 하는 프로세스는 cache buffers chain Latch 를 반드시 필요 – 이 과정에서 경합이 발생 시 발생 이벤트
- Latch: cache buffers lru chain : Buffer cache에서 free buffer 와 dirty buffer를 탐색하고자 할 때 경합 발생시 발생되는 이벤트
- Latch: shared pool : Shared pool Heep 영역에 chunk를 할당 받고자 할 때 경합 발생 시
- Latch: library cache : Library cache 영역을 탐색하고 할 때 경합 발생 시 이벤트
- Latch: redo copy : DML에 의한 변동사항을 Redo Buffer에 기록하고자 할 때 작업의 전 과정 동안 redo copy latch 획득 필요 이 때 경합 시 발생
Latch Free 대기 이벤트의 경우 P2의 값이 latch# 이므로 이 값을 V$LATCHNAME.LATCH# 과 조인하면 래치이름을 얻을 수 있음
락(Lock)
락의 분류
1. 락에 대한 정확한 분류가 존재하지 않음
2. Enqueue Lock과 일반 Lock과 정확한 구분이 존재하지 않음
- DML Lock
n Row Locks (TX)
n Table Lock (TM)
- DDL Lock
- Latches and Internal Locks
n Latches
n Intercal locks
u Dictionary Cache locks
u File and Log Management Locks
u Tablespace and Rollback Segment locks
Steve Adams 의 Lock 분류
- Row cache Enqueues
- Library cache locks and Pins
- DML Locks
- Buffer Locks
- Sort Locks
Enqueue Lock : Enqueue 구조로 관리되는 Lock (10g 부터는 Wait Event로 등록 (v$event_name)
Row cache lock : shared pool 의 Row Cache 영역을 보호하기 위해 사용 ( Row cache 메모리 영역 자체에 보유 프로세스 목록 (Owner List) 와 대기프로세스 목록(Waiter List) 를 관리) -> Row cache Lock, Library cache Lock, Library cache pin, Buffer Lock 등이 있음
- Enqueue Lock
n User Type lock : TX, TM, UL
n System Type Lock : CF, US, CI, TC, JS, …
- 일반 Lock
n Row cache Lock
n Library cache Lock, Library cache pin
n Buffer lock
Lock 이 보호하는 Resource
- Latch 가 SGA 보호 / Lock은 Database 전체를 보호 (Table, Transaction, undo segment, tablespace, Job 등
- TM Lock 은 Table resource 보호 (ID1=object id)
- TX Lock 은 Transaction Resource 보호 (ID1=USN << 16|SLOT, ID2=Sequence)
- US Lock 은 Undo Segment Resource 보호 (ID1=USN)
- HW Lock (ID1=Tablespace#, iD2=DBA of Undo Segment Header)
- Enqueue Lock은 V$LOCK의 TYPE, ID1, ID2 값이 resource 구분자 역할
V$SESSION_WAIT
- 대기현상이 잘생하는지 관찰 가능
- Buffer lock 경합의 경우 Buffer busy waits 나 Read by other session 이벤트에 대한 대기현상 발생
- Row cache lock 경합은 row cache lock Event로 확인 가능
- Library cache lock 과 library cache pin 에서의 경합은 library cache lock Evnet, library cache pin Event 로 관찰 가능
Lock 동작 매커니즘
1. Lock 모드
|
Mode |
설명 |
|
0 |
None |
|
1 |
Null(N) |
|
2 |
Sub-Shared(SS) 또는 Row-Shared(RS) |
|
3 |
Sub-Exclusive(SX) 또는 Row-Exclusive(RX) |
|
4 |
Shared(S) |
|
5 |
Shared-Sub-Exclusive(SSX) 또는 Shared-ROW-Exclusive(SRX) |
|
6 |
Exclusive(X) |
- Table 변경의 경우 Exclusive Mode로 획득 해야 함
- DML 의 경우 TM Lock을 Sub Exclusive 모드로 획득
- Sub-Exclusive의 경우 상호 호환성이 있기 때문에, 동시에 여러프로세스가 하나의 테이블에 대해 DML 작업을 수행하는 것이 허용
- Lock Mode 호환성
|
|
N |
SS |
SX |
S |
SSX |
X |
|
N |
O |
O |
O |
O |
O |
O |
|
SS |
O |
O |
O |
O |
O |
X |
|
SX |
O |
O |
O |
X |
X |
X |
|
S |
O |
O |
X |
O |
X |
X |
|
SSX |
O |
O |
X |
X |
X |
X |
|
X |
O |
|
X |
X |
X |
X |
Ex1) Procedure 실행하는 process 는 Library cache pin을 Shared mode 로 획득 해야 함.
Ex2) Procedure compile 의 경우, library cache pin을 Exclusive mode로 획득해야 함(호환성이 없기에 library cache pin에 의한 경합이 발생)
2. Lock 획득
- Enqueue Lock 획득에 실패한 프로세스는 Enqueue resource의 대기목록(Waiter list)에 등록
(3초 마다(timeout) 스스로 깨어나서 데드락 발생 여부 확인 후 sleep 또는 락을 보유한 프로세스가 락의 사용이 끝난 후 대기 모드 프로세스를 깨워 줌)
- enq: XX – YYYYY 이벤트를 대기
TX Lock 경합
n enq: TX – row lock contention
n enq: TX – allocate ITL entry
n enq: TX – index contention
n enq: TX – contention
이벤트가 별도로 정의
- Row cache lock과 같은 일반 lock 도 Enqueue Lock 과 기본적으로 같은 방식으로 동작
- Buffer lock은 타임아웃이 1초
- 역속적으로 buffer lock 획득하기 위해 대기하는 경우 3초 타임아웃
- Row cache lock 은 60초까지 대기
- Library cache lock 과 library cache pin 은 3초를 대기
- PMON 프로세스는 타임아웃이 1초
-
데드락의 경우 원천적으로 Latch는 level 매커니즘에 의해 방지하지만 lock 의 경우 데드락의 가능성이
항상 존재하며,
데드락 판정이 나면 데드락을 발견한 프로세스의 락 요청은 취소되며, 전체 Transaction 이 아닌 현재 SQL만 rollback 된다
Lock 관련 Dynamic Views
- V$LOCK 에서 Enqueue Lock 관련 정보를 확인 가능
|
SID |
Lock 을 보유중이거나 요청 중인 Session ID LMODE > 0 이면 Lock을 보유중인 Session 이며, Request > 0 이면 Lock 요청중인 session |
|
Type |
Enqueue Lock Resoure Type (ex – TX, TM, UL, US, CI, TC, …etc) |
|
ID1 |
Resource ID 1 |
|
ID2 |
Resource ID 2 <TYPE-ID1-ID2>가 Lock이 보호하는 Resource 구분자 |
|
LMODE |
Lock 을 보유하고 있는 경우의 Mode (1~6 -> Lock 모드 참조) |
|
REQUEST |
Lock 을 요청중인 경우의 Mode (1~6 -> Lock 모드 참조) |
|
CTIME |
현재의 lock mode가 허용된 시간(second) Lock을 보유하거나 요청한 이후부터의 시간 |
|
Block |
현재의
Lock이 다른 Lock을 블로킹하고 있는지의 여부. |
V$LOCK_OBJECT
- 현재 시스템의 모든 Transaction에 의해 획득 중인 TM Lock에 대한 정보를 제공
- OBJECT_ID를 이용하여 object를 직접 조회할 수 있음
- Lock 이 걸린 테이블을 조회할 때 유용
V$ENQUEUE_LOCK
- V$LOCK과 동일하지만, 실제 Enqueue 현상-Blocking 이 발생한 경우 Waiting session 에 대한 정보만 조회
- 어떠한 session 이 lock을 대기하고 있는지 정보만 확인 가능
Library cache lock
- DBA_DDL_LOCKS, DBA_KGLLOCK, X$KGLLK를 통해 관찰이 가능
Library cache pin
- DBA_KGLLOCK, X$KGLPN 통해서 관찰이 가능
- 122793.1 메타링크 참조
|
1. System Trace 를 이용한 분석 $sqlplus '/ as sysdba' oradebug setmypid oradebug unlimit oradebug dump systemstate 266
행 걸린 SID 를 이용하여 PID 검색 select pid from v$process where addr= (select paddr from v$session where sid= sid번호;
TRACE 파일에서 아래 PID로 검색하여 wait event 확인('waiting for' 를 검색) PROCESS 위에서 확인한 PID
2. X$KGLLK 테이블을 조사 select sid,saddr from v$session where event= 'library cache lock';
select kgllkhdl Handle,kgllkreq Request, kglnaobj Object from x$kgllk where kgllkses = '위에서 찾은 saddr정보' and kgllkreq > 0 --직접 만든 join 문 select a.kgllkhdl Handle,a.kgllkreq Request, a.kglnaobj Object from x$kgllk a, v$session b where b.event='library cache lock' and b.saddr=a.kgllkses and a.kgllkreq > 0;
또는 select sid,saddr from v$session where event= 'library cache lock';
select kgllkses saddr,kgllkhdl handle,kgllkmod mod,kglnaobj object from x$kgllk lock_a where kgllkmod > 0 and exists (select lock_b.kgllkhdl from x$kgllk lock_b where kgllkses = '위에서 찾은 saddr' /* blocked session */ and lock_a.kgllkhdl = lock_b.kgllkhdl and kgllkreq > 0); |
메타링크 원문
|
공통 상황들
Systemstate 이벤트는 모든 오라클 프로세스들의 상세한 정보를 담고 있는 트레이스 파일을 생성해 줍니다. 이 정보에는 특정 프로세스에 의해 사용중이거나 요청중인 모든 자원들을 포함하고 있습니다.
$sqlplus '/ as sysdba'
alter session set max_dump_file_size=unlimited;
select pid from v$process where addr= 이 Systemstate 덤프는
각각의 프로세스별로 구분되는 정보를 담고 있습니다.
SO: 0x79f88a68, type: 53, owner: 0x7d3d62d0, flag:
INIT/-/-/0x00
라이브러리 오브젝트 락이 공유 모드(request=S)에서 요청되었으며 그 이름이 SCOTT.EMPLOYEE임을 알 수 있습니다.
PROCESS 18:
위 결과에서 우리는 Process 18(pid)가 우리가 사용하고자 하는 오브젝트에 배타 락(mode=X)을 걸고 있는 것을 볼 수 있습니다. V$PROCESS 와 V$SESSION을 이용하여 이 프로세스의 sid, 사용자, 터미널, 프로그램, 등을 조회해 볼 수 있습니다. 이 세션이 실행했던 실제 문장도 이 트레이스 화일에서 확인 할 수 있습니다(문장들과 다른 라이브러리 오브젝트들은 "name=" 다음에 위치합니다). X$KGLLK 테이블(SYS/INTERNAL로 조회 가능)은 모든 세션들이 잡고 있거나 요청중인 모든 라이브러리 케시 오브젝트들 담고 있으며 비록 의미를 알기 어려운 열이름들이 사용되지만 V$LOCK 뷰보다 더욱 완벽한 정보를 제공합니다. 여러분은 V$SESSION에 있는 세션 주소(SADDR) 을 찾아 보고 아래의 조회를 해 봄으로써 대기중인 세션에 의해 요청된 락들을 조사할 수 있습니다: select sid,saddr from v$session where
event= 'library cache lock';
이 결과는 라이브러리 캐시 락을 요청하고 있는 세션(KGLLKREQ > 0) 과 함께 락을 잡고자 하는 오브젝트의 이름중 첫 80자리를 KGLNAOBJ로 보여주고 있습니다. KGLLKHDL 의 값은 앞에서 봤던 방법 1의 Systemstate 분석절차에서의 오브젝트에 대한 '핸들 주소' 에 해당됩니다. 만일 이 KGLLKHDL 이 X$KGLLK 의 다른 세션의 핸들과 일치한다면 블로킹 세션의 주소를 알수가 있게 됩니다. 이 락을 작고 있는 세션은 락을 잡고 있기 때문에 KGLLKMOD > 0 상태를 가지고 있을 것입니다.
select kgllkses saddr,kgllkhdl
handle,kgllkmod mod,kglnaobj object
select sid,username,terminal,program
from v$session where saddr = '572eac94'
select sid,username,terminal,program
from v$session
|
일반적인 Lock 관련 대기 이벤트
TX Lock 에 의한 대기 현상
|
Row cache lock |
Row cache lock에 의한 경합 |
|
Buffer busy waits, read by other session |
Buffer lock에 의하 경합 |
|
Library cache lock |
Library cache lock에 의한 경합 |
|
Library cache pin |
Library cache pin 에 의한 경합 |
|
DFS Lock handle |
Global lock인 경우에 관찰 |
V$session_wait 나, v$session 을 이용하여 lock 에 대한 경합을 확인 가능
'Oracle > DBA' 카테고리의 다른 글
| [Oracle] Partition Local Index 테스트 (0) | 2015.12.02 |
|---|---|
| [ORACLE] ASM 에 Datafile 추가 (1) | 2015.11.25 |
| [펌][Oracle] 대용량 자료전환 시 튜닝 포인트 - Hash join (0) | 2015.11.19 |
| [Oracle] Merge 구문 1 (0) | 2015.11.12 |
| [펌] [ORACLE] SYS_CONTEXT 및 USERENV 정리 (0) | 2015.09.03 |