239. 즉시 갱신 (Immediate Update) - 로그 기반 회복 상용 DBMS 표준 실시간 디스크 반영 Redo Undo 병행 원자성 영속성 오버헤드 완화
핵심 인사이트: (238번 지연 갱신의 반대이자 현대 DB의 진짜 뼈대) "야! 238번처럼 메모리에만 짊어지고 있다간 10만 명 트래픽 쏟아지면 RAM 터져서 서버 뒈진다고 했지?! 그래서 오라클(Oracle)이랑 MySQL은 무식한 상남자 방식을 쓴다!! '야!! COMMIT 도장 안 찍어도 돼!! 그냥 네가 엑셀 칸 고칠 때마다, 메모리에 담아두지 말고 실시간으로 쇳덩어리 디스크(원본)에 피 튀기며 팍팍 덮어써버려(즉시 갱신)!!' '어? 그러다 내가 에러 나서 죽으면 디스크에 똥 묻은 거 어떡해요?' '아 ㅆㅂ 그건 그때 가서 블랙박스(로그) 까보고 뒤로 벅벅 지우면(Undo) 되잖아!! RAM 터져서 다 같이 죽는 것보단, 디스크에 똥 좀 묻혀놓고 나중에 고생해서 지우는 게 100배 낫다!!'" 쫄보의 룰을 버리고, Undo와 Redo의 쌍칼을 모두 휘두르며 극한의 퍼포먼스를 뽑아내는 현대 DB의 절대 헌법, 즉시 갱신이다.
Ⅰ. 메모리 한계와 실시간 쓰기의 필요성
- 대형 은행 시스템에선 한 트랜잭션이 데이터 100만 건을 고치기도 합니다.
- 238번(지연 갱신)처럼 이걸 COMMIT 칠 때까지 RAM에 들고 있으면 서버가 3초 만에 뻗습니다. (Out Of Memory)
- 살길은 **"어차피 저장할 거, 그때그때 디스크에 내려보내서(Flush) 메모리를 비우자"**는 것입니다.
Ⅱ. 즉시 갱신 (Immediate Update)의 개념 🌟
- Immediate (즉각적인, 실시간의)
- 개념: 트랜잭션이 성공적으로 100% 끝나는(
COMMIT) 것을 기다리지 않고, 트랜잭션이 실행되는 도중에 데이터 변경 연산(UPDATE)이 발생할 때마다 곧바로 원본 물리 디스크(Data File)에 그 변경 사항을 실시간으로 덮어써 버리는 회복 기법입니다. - 절대 전제조건: 무조건 원본을 덮어쓰기 전에, 236번 WAL (Write-Ahead Logging) 룰을 지켜서 "나 지금 원본 덮어쓴다!"는 로그 1줄을 먼저 쾅 박아두어야만 허락됩니다.
Ⅲ. 즉시 갱신의 2대 쌍칼 복구법 (Redo + Undo) 🌟 핵심 기출 🌟
지연 갱신(238번)은 Redo 하나만 썼지만, 이 상남자 방식은 두 개의 칼을 다 씁니다. 정보처리기사 서술형 1순위입니다.
1. Undo (취소)의 뼈저린 부활 🌟
T1이 10만 원을 5만 원으로 고치고 있습니다.- 룰에 따라 아직
COMMIT을 안 쳤는데도 쇳덩어리 디스크 원본에 '5만 원'이라고 덮어써버렸습니다! - 중간에 벼락 맞고 뻗었습니다!
- 복구 로직: 디스크를 까보니 5만 원짜리 쓰레기가 묻어있습니다!! 엔진은 로그를 까보고 "아 이 새끼 쓰다 뒈진(미완성) 놈이네!" 판단하고, 로그에 적힌 과거 값(10만 원)을 꺼내서 쇳덩어리에 거꾸로 덮어씌워 벅벅 지워내는 Undo(취소/Roll-backward) 연산을 필연적으로 수행해야만 합니다.
2. Redo (재실행) 역시 필수
T2가 작업을 끝내고COMMIT도장을 쾅 찍었습니다.- 근데, 100건 중 90건은 즉시 갱신으로 디스크에 내려갔는데, 마지막 10건은 아직 디스크로 못 내려가고 메모리에 떠 있다가 벼락을 맞아 날아갔습니다.
- 복구 로직: "야 ㅆㅂ COMMIT 찍힌 놈은 영속성 지켜야지!" 로그를 보고 날아간 10건의 작업을 똑같이 Redo(재실행/Roll-forward) 해서 디스크에 꽉꽉 채워 넣습니다.
Ⅳ. 즉시 갱신 vs 지연 갱신 (1초 비교 요약)
| 구분 | 239. 즉시 갱신 (Immediate) 🌟 | 238. 지연 갱신 (Deferred) |
|---|---|---|
| 디스크 반영 시점 | 트랜잭션 실행 도중 (아무 때나) | 트랜잭션 COMMIT 직후 (한 방에) |
| 필요한 복구 마법 | Redo + Undo 둘 다 필요 | 오직 Redo만 필요 (Undo 안 함) |
| 로그 파일 구조 | 과거값(Undo용) + 새값(Redo용) 둘 다 필요 | 새값(Redo용)만 있으면 됨 |
| 실무 사용 | 오라클, MySQL 등 대세 표준 | 실무에선 램 터져서 안 씀 |
📢 섹션 요약 비유: **즉시 갱신(Immediate Update)**은 화가가 벽화(원본 DB)를 그릴 때 '실시간 본벽 물감 덮어쓰기' 방식입니다. 화가는 연습장(메모리)에 끄적일 시간도 없습니다(램 부족). 그냥 페인트통 들고 벽화 원본에 다이렉트로 피 튀기며 그림(Write)을 그립니다. 그러다 심장마비로 쓰러지면? 벽화에는 반쯤 그리다 만 괴상한 눈깔과 핏자국(미확정 쓰레기 데이터)이 고스란히 묻어있습니다. 박물관장(DB 엔진)은 이 사태를 수습하기 위해 물걸레를 들고 와서 그 핏자국과 쓰레기 그림을 벅벅 닦아내어(Undo 취소) 깨끗한 과거 벽으로 돌려놓는 생고생을 해야 합니다. 반대로 화가가 "그림 완성!(COMMIT)"을 외쳤는데, 코팅제(디스크 완전 저장)를 바르기 직전에 불이 났다면? 박물관장은 화가의 일기장(로그)을 보고 똑같은 색깔을 다시 덧칠(Redo 재실행)해서 그림을 영원히 보존시켜 줍니다. 중간에 지우고 닦아내는 개고생(Undo)을 감수하더라도, 한 번에 무거운 짐을 들고 있지 않고 그때그때 벽에 발라버리는 이 미친 퍼포먼스 덕분에 전 세계 상용 데이터베이스가 수천만 명의 트래픽을 램 폭발 없이 가볍게 버텨내는 것입니다.