Enqueue는 오라클에서 사용되는 locking 메커니즘이다.
Enqueue는 동시에 여러 프로세스가 기존의 자원에 대해서 다른 정도(degree)로 공유할 수 있는 방법을 제공한다.
* enqueue 종류
column enqueue format a150
select EQ_TYPE,EQ_NAME||'('||REQ_REASON||') : '||REQ_DESCRIPTION enqueue from V$ENQUEUE_STATISTICS;
EQ ENQUEUE
--------------------------------------------------------------------------------------------------------------------------------------------------------
TA Instance Undo(contention) :Serializes operations on undo segments and undo tablespaces
TX Transaction(contention) :Lock held by a transaction to allow other transactions to wait for it
TX Transaction(row lock contention) :Lock held on a particular row by a transaction to prevent other transactions from modifying it
TX Transaction(allocate ITL entry) :Allocating an ITL entry in order to begin a transaction
TX Transaction(index contention) :Lock held on an index during a split to prevent other operations on it
TW Cross-Instance Transaction(contention) :Lock held by one instance to wait for transactions on all instances to finish
US Undo Segment(contention) :Lock held to perform DDL on the undo segment
SU SaveUndo Segment(contention) :Serializes access to SaveUndo Segment
TT Tablespace(contention) :Serializes DDL operations on tablespaces
IM Kti blr lock(contention for blr) :Serializes block recovery for IMU txn
TD KTF map table enqueue(KTF dump entries) :KTF dumping time/scn mappings in SMON_SCN_TIME table
:
위의 내용처럼 TX lock의 경우 발생할 수 있는 경우가 4가지가 있다.
transaction contention, row lock contention, ITL allocation, index contention.
한개의 enqueue가 한개의 원인일 꺼란 생각은 금물 !!
Enqueue의 가장 대표적인 예가 테이블에 대한 Lock(TM)이라 할 수 있겠다.
즉 하나의 테이블에 대해서 두개의 프로세스가 share 모드나 share update 모드로 Lock을 잡을 수 있다.
Enqueue는 O/S의 locking 메커니즘을 이용하여 사용자가 요구한 lock의 모드에 관한 정보를 갖고 있고 O/S lock 관리자는 Lock에 걸린 자원를 계속해서 추적한다. 만약 어떤 프로세스가 요구한 Lock 모드가 현재 허용될 수 없다면 O/S는 Lock을 요구하는 프로세스를 wait queue에 넣게 된다.
* Lock monitoring
SQL> select * from v$lock where type not in ('MR');
ADDR KADDR SID TY ID1 ID2 LMODE REQUEST CTIME BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
0000040B410D1DA0 0000040B410D1DC0 879 TS 3 1 3 0 98069 0
0000040B410D1B20 0000040B410D1B40 880 RS 25 1 2 0 98071 0
0000040B410D19E0 0000040B410D1A00 880 CF 0 0 2 0 98074 0
0000040B410D1940 0000040B410D1960 880 XR 4 0 1 0 98074 0
0000040B410D1C60 0000040B410D1C80 881 RT 1 0 6 0 98071 0
Latches 와 Enqueues의 차이는 latch는 wait하기위한 queue의 순서가 없는 반면 enqueue에는 queue의 순서가 있다는 것이다. Latch waiter는 wake up 하기위한 timer를 이용하거나, retry 또는 spin (multiprocessors 환경)을 이용한다. 모든 waiter가 동시에 retry(scheduller dependent)하기 때문에 누구든지 latch를 얻을 수 있고, 어느 경우에는 처음 시도한 프로세스가 가장 나중에 latch를 획득(get) 할 수도 있다.
ENQUEUE_RESOURCES 는 lock manager 에 의해 lock 되는 자원(resource)의 개수를 의미한다.
이의 초기값은 SESSIONS 파라미터에 의하며, 적절히 부여하기 위해 DML_LOCKS+20 보다 크게 주어야 한다.
예를 들어 3-4 개의 세션(session) 인 경우 default 값은 20 이다.
또 4-10 세션(session) 인 경우 default 값은 ((SESSIONS - 3) * 5) + 20,
10개 이상의 세션(session)에서는 ((SESSIONS - 10) * 2) + 55 이다.
만일 ENQUEUE_RESOURCES 를 DML_LOCKS + 20 보다 크게 한 경우 그 값이 이용된다.
만일 테이블이 많은 경우 이 값은 증가한다.
이는 한 lock 당 부여되는 것이 아니고, 자원을 사용하는 세션(session)의 개수나 cursor 개수에 관계없이 각 자원(resource) 마다 부여되기 때문이다.
* resource 사용현황
SQL> select * from v$resource_limit;
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
processes 180 477 800 800
sessions 173 470 885 885
enqueue_locks 60 81 10750 10750
enqueue_resources 60 90 4112 UNLIMITED
ges_procs 0 0 0 0
