Oracle Lock의 기본 구조: Row Lock·TX Enqueue·TM Enqueue·Lock Mode

핵심 요약

Oracle Lock은 여러 Transaction이 같은 데이터나 객체를 동시에 변경할 때 서로의 작업을 파괴하지 않도록 접근 순서를 조정하는 장치입니다. Oracle은 무조건 큰 범위를 잠그는 대신, 필요한 범위에 가장 제한이 적은 Lock을 자동으로 사용해 동시성과 무결성을 함께 확보합니다.

일반 SELECT
→ 일반적으로 Row Lock과 TM Table Lock을 획득하지 않음
→ Undo를 이용해 Statement 시점의 Commit 버전을 읽음

DML·SELECT FOR UPDATE
→ 변경하거나 선점한 Row에 Row Lock 정보 기록
→ Transaction을 식별하는 TX Enqueue 사용
→ 대상 Table에 TM DML Enqueue 획득

한 Transaction이 Row를 변경하는 동안 다른 Transaction은 같은 Row를 동시에 변경할 수 없습니다. 반면 서로 다른 Row를 변경하는 DML은 같은 Table에서도 함께 실행될 수 있습니다. 일반 SELECT는 Writer의 미완료 값을 기다려 읽지 않고 Undo로 Consistent Read Block을 재구성합니다.

Lock 진단에서는 다음을 구분해야 합니다.

Row Header·ITL
→ 어떤 Transaction이 특정 Row를 변경했는지 표현

V$LOCK의 TX
→ Transaction Resource의 보유·요청 상태

V$LOCK의 TM·V$LOCKED_OBJECT
→ Object 수준 DML Lock과 Mode

V$SESSION의 BLOCKING_*·ROW_WAIT_*
→ 현재 Blocker Chain과 대기 중인 Row 위치

학습 목표

1. 일반 SELECT와 DML의 Lock 동작 차이를 설명한다.
2. Row Header, ITL, Undo Transaction Table, TX Enqueue의 연결을 설명한다.
3. TM Enqueue의 목적과 Table 전체 Row 배타 잠금의 차이를 설명한다.
4. Table Lock Mode 0~6과 공식 호환 관계를 해석한다.
5. V$LOCK의 TYPE, ID1, ID2, LMODE, REQUEST, CTIME, BLOCK을 해석한다.
6. 단순 Holder·Waiter와 Lock Conversion을 구분한다.
7. V$LOCKED_OBJECT, V$SESSION, V$LOCK_TYPE, GV$LOCK의 역할을 구분한다.
8. 같은 Row 충돌, Unique Key 충돌, Bitmap Fragment, ITL 부족을 분리한다.
9. 미인덱스 Foreign Key가 Parent Key 변경 시 동시성을 낮추는 이유를 설명한다.
10. Lock Conversion과 Row-to-Table Lock Escalation을 구분한다.

1. Lock이 필요한 이유

여러 Session이 동시에 같은 데이터를 변경하면 마지막 실행이 앞선 변경을 무조건 덮어쓰거나, Object 구조 변경과 DML이 충돌할 수 있습니다. Oracle의 Lock은 다음 충돌을 조정합니다.

Writer ↔ Writer
→ 같은 Row나 같은 Unique Key를 동시에 변경하지 못하도록 순서를 정함

DML ↔ DDL
→ 진행 중인 데이터 변경과 Table 구조 변경이 충돌하지 않도록 조정

Transaction ↔ 내부 공유 구조
→ Enqueue·Latch·Mutex 등 서로 다른 동기화 수단으로 보호

예외적으로 SELECT ... FOR UPDATE는 조회 Row를 이후 변경하기 위해 잠그므로 Row Lock과 TM Lock을 획득합니다. 일반 SELECT와 동일하게 취급하면 안 됩니다.

2. Row Lock·ITL·Undo Transaction Table·TX의 연결

Oracle의 DML Lock을 이해하려면 개별 Row와 Transaction Resource를 한 계층으로 연결해야 합니다.

Table Row
→ Row Header의 Lock 정보
→ 같은 Data Block Header의 ITL Slot
→ Undo Segment의 Transaction Table Entry와 Undo Record
→ Transaction을 나타내는 TX Enqueue

동시에

DML 대상 Object
→ TM Enqueue

2.1 Row Lock 정보는 Data Block에 저장

Oracle은 수정된 모든 Row의 목록을 중앙 Memory Lock Manager에 별도 Row 목록으로 보관하지 않습니다. Row Lock 정보는 해당 Row가 들어 있는 Data Block에 저장됩니다.

Row Header는 자신을 변경한 Transaction이 사용하는 ITL Slot을 참조합니다. 따라서 한 Transaction이 100만 Row를 변경해도 V$LOCK의 TX 행이 100만 개가 되는 것은 아닙니다. 잠긴 Row 수와 Transaction Enqueue 행 수는 서로 다른 단위입니다.

2.2 ITL: Interested Transaction List

각 Data Block Header에는 해당 Block을 변경한 Transaction을 추적하는 ITL이 있습니다.

ITL Entry
→ Transaction ID
→ Transaction 상태·Commit 확인에 필요한 정보
→ Undo Transaction Table과 Undo Record로 이어지는 연결

Row를 읽거나 변경하는 Session은 Row Header와 ITL을 통해 선행 Transaction을 식별합니다. Consistent Read가 필요하면 Undo Chain을 따라 Query SCN에 맞는 과거 Block 버전을 재구성합니다.

INITRANS는 Segment 생성 시 Block에 미리 확보할 초기 Transaction Entry 수와 관련됩니다. 그러나 ASSM과 Block 여유 공간이 있으면 ITL Entry가 동적으로 늘어날 수 있으므로, INITRANS 값만으로 실제 동시 Transaction 수를 단정하지 않습니다.

2.3 ITL 부족은 같은 Row Lock 대기와 다름

여러 Transaction이 서로 다른 Row를 변경하더라도 같은 Block에서 사용할 ITL Slot을 확보하지 못하면 enq: TX - allocate ITL entry 대기가 발생할 수 있습니다.

같은 Row를 두 Transaction이 변경
→ 대표적으로 enq: TX - row lock contention

서로 다른 Row지만 Block의 ITL Slot 부족
→ enq: TX - allocate ITL entry

따라서 Wait Event 이름과 Block 집중도, Segment 속성, 동시 Transaction 수를 함께 확인해야 합니다.

2.4 TX Enqueue

TX는 Transaction Enqueue입니다. Transaction이 변경을 시작하면 자신의 Transaction Resource를 사용하고, 다른 Session이 그 Transaction의 결과를 알아야 할 때 TX를 기다릴 수 있습니다.

Session A가 Row 100 변경
→ A의 Transaction이 TX Resource를 보유

Session B가 같은 Row 100 변경 시도
→ Row Header·ITL을 통해 A의 Transaction 식별
→ A의 COMMIT 또는 ROLLBACK을 기다림

Oracle 문서는 Row Lock을 TX Lock이라고도 표현합니다. 진단에서는 다음 두 수준을 구분하면 이해하기 쉽습니다.

enq: TX - row lock contention은 같은 Row 충돌 외에도 Unique Index 중복 후보, 같은 Bitmap Index Fragment 때문에 발생할 수 있습니다. TX 대기라는 이유만으로 항상 같은 Table Row 충돌이라고 단정하지 않습니다.

3. TM Enqueue와 Object 수준 보호

TM은 DML Enqueue입니다. INSERT, UPDATE, DELETE, MERGE, SELECT ... FOR UPDATE, LOCK TABLE은 대상 Table 또는 관련 Object에 TM Lock을 획득합니다.

UPDATE orders ...
→ 변경 Row에 Row Lock
→ Transaction TX Resource
→ ORDERS Object에 TM Row Exclusive Lock

TM Lock의 주된 목적은 다음과 같습니다.

• Transaction이 해당 Table에서 DML을 수행 중임을 표시
• 진행 중인 DML과 충돌하는 DDL·명시적 Table Lock을 제어
• Foreign Key 관계에서 Parent Key 변경과 Child Table 검증을 조정

TM Lock이 존재한다고 Table의 모든 Row가 배타적으로 잠긴 것은 아닙니다. 일반 DML이 사용하는 Row Exclusive Mode는 다른 Row Share·Row Exclusive Mode와 호환되므로 서로 다른 Row에 대한 동시 DML이 가능합니다.

3.1 미인덱스 Foreign Key

Child Table의 Foreign Key Column에 Index가 없고 Parent의 Primary·Unique Key를 삭제하거나 변경하면 Oracle이 Child Table을 더 넓게 잠그고 검사할 수 있습니다. 이로 인해 Full Scan, TM Lock 대기, Deadlock 위험과 동시성 저하가 발생할 수 있습니다.

Parent Key 변경·삭제
+ Child Foreign Key 미인덱스
→ Child 참조 행 검사를 위한 넓은 접근과 Table Lock 가능

Foreign Key Index는 모든 경우에 무조건 필요한 것이 아니라, Parent Key가 실제로 갱신·삭제되는지와 Child DML 패턴을 함께 판단합니다. 그러나 OLTP에서 Parent Key 변경·삭제가 가능하면 우선 검토할 중요한 동시성 설계 요소입니다.

4. 한 번의 UPDATE에서 발생하는 Lock 흐름

다음 Table을 가정합니다.

CREATE TABLE orders (
    order_id NUMBER PRIMARY KEY,
    status   VARCHAR2(20)
);

Session A

UPDATE orders
SET    status = 'PAID'
WHERE  order_id = 100;

아직 COMMIT하지 않은 상태에서 개념적으로 다음 흐름이 발생합니다.

1. 대상 Row를 Current Mode로 찾음
2. Data Block의 ITL Slot을 확보
3. Row Header가 해당 ITL을 참조하도록 변경
4. 변경 전 정보를 Undo에 기록
5. Transaction TX Resource를 사용
6. ORDERS에 TM Row Exclusive Lock을 보유

Session B: 일반 SELECT

SELECT status
FROM   orders
WHERE  order_id = 100;

Session B는 Session A의 미완료 값을 읽지 않습니다. 필요한 경우 Undo를 적용해 Statement 시작 시점에 맞는 Commit 버전을 읽으므로 일반적으로 A의 Row Lock 해제를 기다리지 않습니다.

Session C: 다른 Row 변경

UPDATE orders
SET    status = 'CANCELLED'
WHERE  order_id = 200;

Row 200이 다른 Transaction에 잠겨 있지 않고 ITL 등 다른 Resource 경합이 없다면 함께 진행할 수 있습니다. A와 C가 같은 Table에 TM Row Exclusive Lock을 동시에 보유하는 것은 정상입니다.

Session D: 같은 Row 변경

UPDATE orders
SET    status = 'CANCELLED'
WHERE  order_id = 100;

Session D는 A가 COMMIT 또는 ROLLBACK할 때까지 기다릴 수 있습니다. 선행 Transaction이 끝나면 후행 DML은 Row의 최신 상태와 WHERE 조건을 다시 확인합니다. 따라서 대기 전에 조건을 만족했더라도 선행 변경 이후에는 영향 Row가 0건이 될 수 있습니다.

5. Table Lock Mode와 호환성

V$LOCK.LMODE, V$LOCK.REQUEST, V$LOCKED_OBJECT.LOCKED_MODE는 다음 숫자를 사용합니다.

공식 호환 관계

행은 현재 보유 Mode, 열은 새로 요청하는 Mode로 이해합니다.

일반 INSERT, UPDATE, DELETE, MERGE, SELECT ... FOR UPDATE는 대상 Table에 주로 RX·SX Mode를 사용합니다. 여러 Session이 RX를 동시에 보유할 수 있으므로 실제 Row 충돌은 Row Header·ITL·TX 상태에서 결정됩니다.

Constraint 부수 효과나 특정 작업에서는 일반적인 SX보다 더 강한 Mode가 잠깐 필요할 수 있으므로, SQL 종류만으로 항상 Mode를 고정하지 않고 실제 LMODE와 REQUEST를 확인합니다.

6. Lock Conversion과 Lock Escalation

Lock Conversion
→ 같은 Resource에서 이미 보유한 Mode를 더 제한적인 Mode로 변경

Lock Escalation
→ 많은 Row Lock을 Block·Table 같은 더 큰 단위 Lock으로 자동 승격

한 Session이 RS를 보유한 상태에서 실제 DML로 RX가 필요해지면 Conversion이 발생할 수 있습니다. 이때 V$LOCK 한 행에서 LMODE > 0이면서 REQUEST > 0으로 나타날 수 있습니다.

따라서 다음 단순 규칙에는 예외가 있습니다.

일반 Holder: LMODE > 0, REQUEST = 0
일반 Waiter: LMODE = 0, REQUEST > 0
Conversion Waiter: LMODE > 0, REQUEST > 0

Oracle은 많은 Row를 변경했다는 이유만으로 Row Lock을 자동 Table Lock으로 Escalation하지 않습니다. 대량 UPDATE에서도 각 Row의 Lock 정보와 Transaction 구조를 유지하며, TM Lock은 Row Lock 개수를 줄이는 Escalation이 아니라 DML·DDL 관계를 조정하기 위한 별도 Object Lock입니다.

7. Enqueue와 Latch·Mutex의 차이

library cache lock처럼 이름에 Lock이 들어가도 TX·TM Enqueue와 같은 범주가 아닐 수 있습니다. Wait Event와 Resource 종류를 먼저 분류합니다.

8. V$LOCK 해석

SELECT sid,
       type,
       id1,
       id2,
       lmode,
       request,
       ctime,
       block
FROM   v$lock
WHERE  type IN ('TX', 'TM')
ORDER BY type, id1, id2, sid;

동일한 Resource를 찾으려면 TYPE, ID1, ID2를 함께 비교합니다. ID1과 ID2의 의미는 Lock Type마다 다르므로 V$LOCK_TYPE.ID1_TAG, ID2_TAG를 같이 확인하는 것이 안전합니다.

SELECT type, name, id1_tag, id2_tag, description
FROM   v$lock_type
WHERE  type IN ('TX', 'TM');

실무에서 TM의 ID1은 관련 Object 식별에, TX의 ID 값은 Transaction 식별에 활용되지만, Hard-coded 공식처럼 모든 Lock Type에 같은 의미를 적용하면 안 됩니다.

8.1 Holder·Waiter 매칭

SELECT w.sid AS waiter_sid,
       h.sid AS holder_sid,
       w.type,
       w.id1,
       w.id2,
       h.lmode AS holder_mode,
       w.request AS waiter_request
FROM   v$lock w
JOIN   v$lock h
  ON   h.type = w.type
 AND   h.id1  = w.id1
 AND   h.id2  = w.id2
WHERE  w.request > 0
AND    h.lmode   > 0
AND    h.sid    <> w.sid;

이 Query는 현재 Snapshot의 Enqueue 관계를 보여 주는 출발점입니다. Lock Conversion, RAC Remote Holder, 매우 짧은 대기, 여러 Holder가 있는 호환 Mode에서는 추가 확인이 필요합니다.

8.2 RAC 환경

Single Instance의 V$LOCK은 Local Instance 상태를 중심으로 봅니다. RAC에서는 GV$LOCK.INST_ID, GV$SESSION.BLOCKING_INSTANCE, Global Wait Chain을 함께 확인합니다. BLOCK=2는 Local Node에서 차단 중인 Session이 보이지 않지만 Remote Node를 차단할 가능성이 있음을 뜻합니다.

9. V$LOCKED_OBJECT와 V$SESSION

9.1 Object 수준 DML Lock

V$LOCKED_OBJECT는 Transaction이 어떤 Object에 어떤 TM DML Lock Mode를 보유하는지 보여 줍니다.

SELECT lo.session_id AS sid,
       s.serial#,
       s.username,
       o.owner,
       o.object_name,
       o.subobject_name,
       o.object_type,
       lo.locked_mode,
       lo.xidusn,
       lo.xidslot,
       lo.xidsqn
FROM   v$locked_object lo
JOIN   v$session s
  ON   s.sid = lo.session_id
JOIN   dba_objects o
  ON   o.object_id = lo.object_id
ORDER BY lo.session_id, o.owner, o.object_name;

한 행은 잠긴 개별 Row 한 건이 아니라 Transaction이 Object에 보유한 TM Lock입니다. Row 목록 전체를 제공하지 않습니다.

9.2 현재 Blocking Chain과 Row 위치

SELECT sid,
       serial#,
       event,
       blocking_instance,
       blocking_session,
       final_blocking_instance,
       final_blocking_session,
       row_wait_obj#,
       row_wait_file#,
       row_wait_block#,
       row_wait_row#
FROM   v$session
WHERE  state = 'WAITING'
OR     blocking_session IS NOT NULL;

ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW#는 Session이 다른 Transaction의 Commit을 기다리는 현재 Row Wait에서 ROW_WAIT_OBJ# <> -1일 때 의미가 있습니다. 대기가 끝난 뒤 값을 영구적인 잠금 이력으로 사용하면 안 됩니다.

Object를 찾을 때는 상황에 따라 DBA_OBJECTS.DATA_OBJECT_ID와 비교해야 합니다. Partition·Subpartition의 실제 Segment를 찾으려면 OBJECT_ID만 비교해 누락하지 않도록 주의합니다.

10. TX 대기의 원인 분류

enq: TX - row lock contention은 대표적으로 다음 원인이 있습니다.

다음 대기는 별도로 분리합니다.

Wait Event 이름만 보지 않고 SQL, Object, Index 종류, Block 위치, Transaction Key를 결합합니다.

11. 혼동하기 쉬운 판단

12. 적용 판단 순서

1. 일반 SELECT, SELECT FOR UPDATE, DML, DDL 중 어떤 작업인지 구분합니다.
2. Wait Event를 확인해 TX Row, TX ITL, TX Index, TM, Library Cache 대기를 분류합니다.
3. V$SESSION의 BLOCKING_SESSION, FINAL_BLOCKING_SESSION, ROW_WAIT_*를 확인합니다.
4. V$LOCK 또는 RAC의 GV$LOCK에서 TYPE, ID1, ID2, LMODE, REQUEST, BLOCK을 확인합니다.
5. 같은 Resource의 Holder·Waiter와 Conversion 상태를 구분합니다.
6. V$LOCKED_OBJECT와 DBA_OBJECTS로 TM Object와 Partition을 확인합니다.
7. TX라면 같은 Row, Unique Key, Bitmap Fragment, ITL, Index Split 가능성을 분리합니다.
8. Parent Key 변경이라면 Child Foreign Key Index와 TM Lock을 확인합니다.
9. Blocker의 SQL, Transaction 시작 시각, Undo 사용량, Commit·Rollback 경계를 확인합니다.
10. 단순 Session 종료보다 긴 Transaction·잘못된 업무 순서·Missing Index·Hot Block 설계를 먼저 교정합니다.
11. 같은 동시 실행 조건에서 대기시간, 처리량, Block 집중도와 Deadlock 재발 여부를 다시 측정합니다.