8장. 트랜잭션과 락

Oracle의 행 락은 별도의 락 매니저 메모리가 아니라 데이터 블록 안(ITL)에 삽니다. 그래서 락이 아무리 많아져도 에스컬레이션이 없습니다 — 이 설계 하나가 Oracle 동시성의 성격을 결정합니다.

8.1 Oracle 락의 철학 — 락은 블록 안에 산다

많은 DBMS는 "어느 세션이 어느 행을 잠갔나"를 메모리의 락 테이블에서 중앙 관리합니다. 이 방식의 약점은 락이 많아지면 락 테이블이 메모리를 잠식한다는 것 — 그래서 일부 DBMS는 행 락 수천 개를 페이지 락·테이블 락 하나로 뭉치는 락 에스컬레이션(lock escalation)을 합니다. 동시성이 갑자기 나빠지는 원인이죠.

Oracle의 설계는 다릅니다. 행 락은 그 행이 사는 데이터 블록 안에 기록됩니다. 5장에서 본 블록 헤더의 ITL(Interested Transaction List)에 트랜잭션이 이름을 올리고, 각 행은 자신을 잠근 트랜잭션의 ITL 슬롯 번호를 가리킬 뿐입니다. 그 결과:

• 락 개수에 비례하는 중앙 메모리가 없습니다. 1행을 잠그든 1억 행을 잠그든 별도 락 메모리 비용은 사실상 같습니다.
• 그래서 락 에스컬레이션이 존재하지 않습니다. 행 락이 테이블 락으로 승격되는 일은 Oracle에 없습니다.
• 락 정보가 블록과 함께 디스크에 쓰이고 캐시됩니다 — 커밋 후 뒷정리(block cleanout)도 블록 단위로 이뤄집니다.

8.2 TX 락과 TM 락 — DML 한 번에 락 두 종류

UPDATE 한 문장을 실행하면 Oracle은 두 종류의 락을 잡습니다.

"행 락 대기"의 실체는 이렇습니다: 세션 B가 세션 A가 잠근 행을 고치려 하면, B는 그 행이 아니라 A의 TX 락에 줄을 섭니다. A가 COMMIT/ROLLBACK으로 TX 락을 풀면 B가 깨어납니다. 대기 이벤트 이름도 enq: TX - row lock contention입니다.

8.3 같은 행 vs 다른 행 — 대기는 언제 생기나

8.4 ITL 슬롯 — 행 락의 실제 저장소

블록 헤더의 ITL은 "이 블록에서 지금 작업 중인 트랜잭션 명단"입니다. 슬롯 초기 개수는 INITRANS(테이블 기본 1)로 정해지고, 필요하면 블록의 free space를 먹으며 늘어납니다(최대 255). 이 슬롯이 모자라면 어떻게 될까요?

8.5 SELECT FOR UPDATE — 읽으면서 미리 잠그기

"읽고 → 판단하고 → 고치는" 로직에서는 읽기와 쓰기 사이에 다른 세션이 끼어들 수 있습니다. 읽는 시점에 행을 잠그고 싶다면 SELECT ... FOR UPDATE를 씁니다. 대기 방식도 고를 수 있습니다.

-- 기본: 행 락을 얻을 때까지 무한 대기
SELECT bal FROM accounts WHERE id = 1 FOR UPDATE;

-- 잠겨 있으면 즉시 에러 (ORA-00054)
SELECT bal FROM accounts WHERE id = 1 FOR UPDATE NOWAIT;

-- 5초만 기다려보고 포기 (ORA-30006)
SELECT bal FROM accounts WHERE id = 1 FOR UPDATE WAIT 5;

-- 잠긴 행은 건너뛰고 잠글 수 있는 행만 — 작업 큐 패턴의 단골
SELECT * FROM job_queue WHERE status = 'READY'
FOR UPDATE SKIP LOCKED;

8.6 Deadlock — ORA-00060과 Oracle의 자동 심판

두 세션이 서로가 잡은 행을 서로 기다리면 아무도 영원히 진행할 수 없습니다 — deadlock입니다. Oracle은 이를 자동 감지해 한쪽의 문장을 강제로 실패시킵니다.

8.7 락 대기 진단 — 범인은 v$session에 있다

"화면이 멈췄어요"라는 신고가 오면, 누가 누구를 막고 있는지부터 찾습니다. v$session의 blocking_session 컬럼이 정답을 바로 알려줍니다.

-- 지금 락에 막혀 있는 세션과, 그를 막고 있는 범인
SELECT sid, serial#, username, event,
       blocking_session,                    -- 나를 막는 세션의 SID
       final_blocking_session,              -- 대기 사슬 맨 끝의 최종 범인
       seconds_in_wait
FROM   v$session
WHERE  blocking_session IS NOT NULL;

 SID  USERNAME  EVENT                              BLOCKING_SESSION
----  --------  ---------------------------------  ----------------
 152  APP_USER  enq: TX - row lock contention                   34   ← 34번이 범인

-- 범인(34번)이 뭘 하는 중인지 확인 후, 응답 없으면 강제 종료
SELECT sid, serial#, status, sql_id, last_call_et FROM v$session WHERE sid = 34;
ALTER SYSTEM KILL SESSION '34,56789';   -- 'sid,serial#' — 최후의 수단!

8.8 격리 수준 — Oracle의 선택지

Oracle의 기본 격리 수준은 READ COMMITTED입니다. 문장 하나하나가 자기 시작 시점의 SCN으로 읽기 일관성을 보장받습니다(문장 수준 일관성). 더 강한 보장이 필요하면 SERIALIZABLE로 올려 트랜잭션 시작 시점의 스냅샷을 트랜잭션 끝까지 고정할 수 있습니다.

눈치채셨나요? READ UNCOMMITTED가 없습니다. 읽기 일관성이 공짜(락 없음)로 제공되는 Oracle에서는 dirty read를 허용할 이유가 아예 없기 때문입니다. 또 REPEATABLE READ도 별도로 제공하지 않습니다 — 필요하면 SERIALIZABLE 또는 SELECT FOR UPDATE로 해결합니다.

-- 트랜잭션 단위 스냅샷 고정
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
UPDATE accounts SET bal = bal - 100 WHERE id = 1;
-- 이 사이 다른 TX가 id=1을 고치고 커밋했다면 → ORA-08177 발생, 재시도 필요
COMMIT;

✍️ 이해도 체크