6장. Undo와 읽기 일관성

Oracle에서 SELECT는 절대 남의 미커밋 데이터를 보지 않고, 그렇다고 기다리지도 않습니다. 비밀은 "과거를 복원하는 데이터", undo입니다. PostgreSQL과 정반대 방향의 MVCC를 만나봅니다.

6.1 Undo란 — "되돌리기 위한 데이터"

Undo는 이름 그대로 변경을 되돌리기(undo) 위한 정보입니다. UPDATE로 값을 100에서 200으로 바꾸면, Oracle은 "원래 값은 100이었다"라는 변경 전 이미지(before image)를 따로 보관합니다. 이 정보가 하는 일은 세 가지입니다.

• ROLLBACK — 트랜잭션을 취소할 때 undo를 적용해 원래대로 되돌립니다.
• 읽기 일관성(read consistency) — 다른 세션의 SELECT가 미커밋 변경을 "지우고" 과거 시점의 데이터를 볼 수 있게 합니다. 이 장의 주인공입니다.
• Flashback — "10분 전의 이 테이블"을 조회하는 시간여행 기능의 재료가 됩니다.

undo는 어디에 저장될까요? 전용 undo tablespace 안의 undo segment들입니다. 현대 Oracle(9i 이후)은 Automatic Undo Management가 기본이라, DBA는 undo tablespace 크기만 관리하면 세그먼트 할당은 Oracle이 알아서 합니다.

-- undo 관리 방식과 undo tablespace 확인
SHOW PARAMETER undo;

NAME             TYPE     VALUE
---------------- -------- ---------
undo_management  string   AUTO       ← 자동 undo 관리 (기본)
undo_retention   integer  900        ← undo를 최소 900초(15분) 보존 시도
undo_tablespace  string   UNDOTBS1

-- 트랜잭션이 지금 어느 undo segment를 쓰는지
SELECT s.sid, s.username, t.xidusn AS undo_seg_num, t.used_ublk
FROM   v$transaction t JOIN v$session s ON t.ses_addr = s.saddr;

6.2 DML의 순간 — 블록은 제자리에서 고치고, 과거는 undo로

여기가 Oracle을 이해하는 갈림길입니다. Oracle의 UPDATE는 데이터 블록을 제자리에서(in-place) 고칩니다. 새 버전 행을 만들지 않습니다. 대신 덮어쓰기 직전의 값을 undo segment에 복사해 둡니다.

6.3 읽기 일관성 — CR 블록을 만드는 마법

세션 A가 아직 커밋하지 않은 상태에서, 세션 B가 같은 행을 SELECT하면 어떻게 될까요? 블록에는 이미 bal=200이 적혀 있는데요. Oracle의 답은 "블록을 복제한 뒤 undo를 거꾸로 적용해서 과거 시점의 블록을 재조립한다"입니다. 이렇게 만든 사본을 CR(Consistent Read) 블록이라고 부릅니다.

기준점은 SCN(System Change Number) — Oracle 내부의 논리적 시계입니다. 쿼리가 시작되는 순간의 SCN이 "내가 봐야 할 세상의 시각"으로 고정되고, 그보다 미래의 변경(그리고 모든 미커밋 변경)은 undo로 지워냅니다.

6.4 🏆 PostgreSQL과 정반대 방향 — 같은 MVCC, 다른 설계

PostgreSQL도 Oracle도 MVCC(다중 버전 동시성 제어)를 씁니다. 그런데 버전을 어디에 두는가가 정반대입니다. 이 차이 하나에서 두 DB의 운영 특성 대부분이 갈라져 나옵니다.

재미있는 대칭이죠. PostgreSQL은 ROLLBACK이 싸고 청소가 비싸며, Oracle은 청소가 없는 대신 ROLLBACK이 비쌉니다. "대량 배치가 실패해서 ROLLBACK했더니 실행 시간만큼 또 걸렸다"는 Oracle 단골 사연이 여기서 나옵니다.

6.5 ORA-01555: snapshot too old — 유통기한 지난 과거

undo tablespace는 무한하지 않습니다. 공간이 차면 Oracle은 커밋된 지 오래된 undo부터 순환식으로 덮어씁니다. 문제는 아직 그 과거를 필요로 하는 장기 실행 쿼리가 있을 때입니다.

대책은 "과거를 더 오래 보관하거나, 과거를 덜 오래 필요로 하거나" 둘 중 하나입니다.

6.6 Flashback Query — undo가 주는 보너스, 시간여행

undo에 과거가 남아 있다면, 그걸 사용자에게도 열어주면 어떨까요? 그것이 Flashback Query입니다. 실수로 지우고 커밋해버린 데이터를 백업 없이 되살리는 실전 필살기입니다.

-- 10분 전의 테이블 모습 조회 (undo가 남아있는 한)
SELECT * FROM emp
AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '10' MINUTE
WHERE  empno = 7369;

-- 실수로 DELETE + COMMIT한 행 복구
INSERT INTO emp
SELECT * FROM emp AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '10' MINUTE
WHERE  empno NOT IN (SELECT empno FROM emp);

-- 행의 변경 이력을 버전별로 추적
SELECT versions_starttime, versions_operation, sal
FROM   emp VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE
WHERE  empno = 7369;

✍️ 이해도 체크