238. 지연 갱신 (Deferred Update) - 로그 기반 회복 트랜잭션 완료 시점 DB 기록 연기 Undo 불필요 Redo 전용 무결성

핵심 인사이트: (237번 로그 기반 회복의 쫄보 버전) "야! 237번에서 엑셀 칸 고칠 때마다 로그(블랙박스) 쓰라고 했지? 근데 로그 썼다고 해서 진짜 쇳덩어리 엑셀 원본(Data File)에다가 바로 덮어써도 될까? 만약 덮어썼는데 내가 에러 나서 죽으면, 그 쓰레기 지우느라 Undo(취소) 때리고 생고생하잖아! 아예 이렇게 하자! '내가 요리하는 동안에는 절대로!! 하늘이 두 쪽 나도 진짜 원본 엑셀(디스크)에는 단 1글자도 쓰지 마(지연)!! 오직 내 개인 임시 메모리랑 블랙박스(로그)에만 끄적여!! 그러다가 내가 요리를 완벽하게 끝내고 COMMIT(성공) 도장을 쾅! 찍는 그 순간에만!! 지금까지 로그에 적어둔 걸 모아서 진짜 엑셀에 한 방에 덮어써라!!' 이렇게 하면 내가 중간에 뻗어 죽더라도 원본 엑셀은 1도 안 더러워졌으니 Undo(취소) 흑마법을 쓸 필요조차 없잖아!!" 똥을 안 싸서 치울 일도 없게 만든 궁극의 청결 회복 기법, 지연 갱신이다.

Ⅰ. 원본(Disk)을 더럽히는 것의 공포

  • 235번에서 배운 Undo(취소/롤백)는 왜 일어날까요? 내가 아직 COMMIT을 안 했는데, DB가 메모리 꽉 찼다고 내 피투성이 미완성 데이터를 쇳덩어리 디스크에 묻혀버렸기(Flush) 때문입니다.
  • 디스크에 쓰레기가 묻었으니, 롤백할 때 그걸 다시 닦아내는 쌩고생(Undo)을 해야 합니다.

Ⅱ. 지연 갱신 (Deferred Update)의 개념 🌟

  • Deferred (미뤄진, 지연된)
  • 개념: 트랜잭션이 성공적으로 완전히 종료(COMMIT)될 때까지, 데이터베이스 원본 디스크(Data File)에 대한 모든 쓰기(Write) 작업을 꾹 참고 미루어 두었다가(지연), 트랜잭션이 100% 성공했을 때에만 로그 파일을 쫙 읽어서 원본 디스크에 한 번에 반영하는 회복 기법입니다.

Ⅲ. 지연 갱신의 3대 작동 룰 🌟 핵심 기출 🌟

시험에서 "Undo가 필요 없다"는 문장이 나오면 1초 만에 이놈을 찍어야 합니다.

1. Undo(취소)가 우주에서 소멸한다 🌟

  • T1이 10만 원을 5만 원으로 고치고 있었습니다.
  • 이 기법의 룰에 따라 진짜 디스크에는 1도 안 적었고(지연), 메모리와 로그에만 적고 있었습니다.
  • 중간에 벼락 맞고 뻗었습니다!
  • 복구 로직: 디스크를 까봅니다. 어라? 원본은 여전히 깨끗한 '10만 원'입니다! 쓰레기가 안 묻었으니 과거로 되돌리는 Undo(취소) 작업을 할 필요가 아예 물리적으로 0%로 사라집니다. 그냥 메모리 찌끄러기만 날려버리고 무시(Ignore)하면 끝납니다.

2. 오직 Redo(재실행)만 존재한다

  • T1이 작업을 다 끝내고 COMMIT 도장을 쾅 찍었습니다. (로그에는 기록됨)
  • 이제 디스크에 덮어쓰려고(지연 갱신 시작) 하는데, 그 찰나에 벼락을 맞아 뻗었습니다.
  • 복구 로직: 재부팅 후 로그를 봅니다. "어? 이놈 COMMIT 찍었네? 근데 디스크엔 안 들어갔네!" ➜ "당장 로그를 보고 똑같이 다시 디스크에 덮어써라(Redo)!!"
  • 성공한 놈을 살려내는 Redo 연산은 무조건 필요합니다.

3. 로그 파일의 구조 축소

  • 237번에서 로그 1줄은 <T1, 계좌, 10만(과거값 Undo용), 5만(새값 Redo용)> 4단 콤보라고 했습니다.
  • 지연 갱신에서는 Undo 자체를 안 하니까, 로그 파일에 '과거 값(10만 원)'을 아예 적을 필요가 없습니다. 오직 <T1, 계좌, 5만(새값)>만 적으면 되므로 로그 파일이 날씬해집니다.

Ⅳ. 왜 현대 DB는 이 쫄보 룰을 버렸을까? (한계점)

  • "오! Undo 안 하니까 대박 좋은 거 아니에요?"
  • 치명적 단점 (메모리 폭발): 디스크에 똥을 안 싸려면, 내가 요리하는 10시간 동안 그 방대한 데이터를 전부 메모리(RAM) 버퍼에 이빠이 짊어지고 버텨야 합니다.
  • 트랜잭션 1만 명이 들어오면 메모리가 펑 터져서 시스템이 뻗습니다. 그래서 오라클이나 MySQL 같은 대형 상용 DB는 이 '지연 갱신'을 절대 안 쓰고, 239번 상남자 방식인 **'즉시 갱신(Immediate Update)'**을 표준으로 씁니다.

📢 섹션 요약 비유: 지연 갱신(Deferred Update) 기법은 화가가 벽화(원본 DB)를 그릴 때 **'본벽에 붓질 절대 금지 룰'**입니다. 바보 화가(즉시 갱신)는 마음에 안 들면 다시 닦아낼 생각(Undo)을 하고 본벽에 바로 피 튀기며 그림을 그립니다. 근데 지연 갱신 룰의 화가는 절대 본벽 근처에 가지 않습니다. 자기 책상 위의 투명한 OHP 필름(임시 메모리)에다가만 미친 듯이 그림을 그리고 연습합니다. 만약 화가가 심장마비로 쓰러지면? 본벽은 어차피 손도 안 댔으니 물걸레로 닦아낼(Undo 취소) 필요가 전혀 없습니다! 그냥 투명 필름만 쓰레기통에 툭 버리면 복구가 1초 만에 끝납니다. 화가가 그림을 100% 완벽하게 다 그리고 "완성!(COMMIT)" 사인을 냈을 때만, 그 투명 필름을 본벽에 그대로 가져다 딱 붙입니다(Redo 전용). 복구(Undo)의 귀찮음을 완벽하게 멸종시켰지만, 수백 명의 화가가 동시에 투명 필름(메모리)을 이빠이 들고 버텨야 해서 RAM이 터져버리는 쫄보들의 한계점 명확한 회복 방식입니다.