225. Undo 세그먼트 (롤백 세그먼트) - MVCC 구버전 데이터 저장 영역 롤백 동시성 제어 과거 스냅샷 ORA-01555 블로킹 방지 트랜잭션 회복

핵심 인사이트: (224번 MVCC의 핏빛 희생양) "야! 224번에서 MVCC 쓰면 누군가 데이터를 뜯어고치고(Write) 있어도 딴 놈들이 무한대로 조회(Read)할 수 있어서 대기 시간 제로라고 찬양했지? 근데 엑셀 원본은 피 튀기며 수술 중인데, 밖의 10만 명한테는 대체 뭘 보여주는 거냐?! 비밀은 지하 창고에 쑤셔 박아둔 '과거 사진(스냅샷)'이야!! 관리자가 엑셀 값을 '25만 원'으로 덮어쓰기 1초 직전!! DB 엔진이 잽싸게 원본인 '20만 원' 데이터를 복사해서 깊고 어두운 지하 창고(Undo 세그먼트)에 휙 던져놓고 문을 잠가버려!! 그리고 밖에서 조회하러 온 10만 명한테는 그 지하 창고의 과거 사진 쪼가리들을 빛의 속도로 쫙쫙 복사해서 뿌려주며 원본을 읽은 것처럼 감쪽같이 속이는 거지!! 근데 쓰기(Update)를 너무 미친 듯이 많이 하면 이 지하 과거 사진 창고가 터져서 DB가 뻗어버리는 저주받은 쓰레기장이 바로 Undo 세그먼트다!!" MVCC의 찬란한 빛을 위해 묵묵히 똥(과거 데이터)을 치워 담는 지하 하수도, 언두 세그먼트다.

Ⅰ. 동시성과 롤백의 공통 분모 (과거의 기억)

• 트랜잭션이 에러가 나서 **ROLLBACK(취소)**을 치려면, 자기가 고치기 전의 **'과거 원본 상태'**로 엑셀을 되돌려놔야 합니다. 과거를 기억 못 하면 타임머신을 탈 수 없습니다.
• 또한 224번에서 배운 **MVCC(다중 버전 동시성 제어)**를 위해, 내가 고치는 동안 남들에게 보여줄 **'과거 원본 사진'**이 무조건 필요합니다.
• 이 **"과거의 낡은 데이터들"**을 영구 보존하는 DB의 특수 공간이 바로 **Undo 세그먼트(옛날 이름: 롤백 세그먼트 Rollback Segment)**입니다.

Ⅱ. Undo 세그먼트의 개념 🌟

• Undo (되돌리다, 무효화하다)
• 개념: 오라클이나 MySQL 같은 RDBMS에서, 사용자가 데이터를 변경(UPDATE, DELETE)할 때 변경되기 이전의 낡은 구버전 데이터(Before Image)를 안전하게 보관해 두는 **물리적인 디스크/메모리 저장 공간(지하 창고)**입니다.

Ⅲ. Undo 세그먼트의 3대 절대 임무 🌟 핵심 기출 🌟

지하 창고에 모아둔 쓰레기(과거 데이터)가 세상을 구원합니다.

1. 트랜잭션 롤백 (Transaction Rollback) - "타임머신"

• 내가 홍길동 이름을 '이순신'으로 바꿨다가 실수한 걸 깨닫고 "아 ㅆㅂ 취소(ROLLBACK)!"을 때립니다.
• DB 엔진은 뒤도 안 돌아보고 바로 Undo 세그먼트 창고 문을 열고, 아까 쑤셔 박아둔 '홍길동' 사진을 꺼내어 현재 엑셀 칸에 다시 쾅 덮어버림으로써 0.1초 만에 완벽하게 과거로 시간을 되돌려 버립니다.

2. 읽기 일관성 보장 (Read Consistency) & MVCC의 심장 🌟

• (가장 중요한 역할) 누군가 UPDATE를 치고 아직 COMMIT을 안 했습니다(미완성 피투성이 상태).
• 이때 다른 10만 명이 조회를 하러 오면, 피투성이 데이터를 보여주지 않고(오손 읽기 방지), Undo 세그먼트에 고스란히 박제되어 있는 '가장 깨끗했던 과거 사진(Before Image)'을 10만 명의 모니터에 뿌려줍니다.
• 락(Lock) 없이 완벽하게 투명한 100% 동시 조회를 달성하는 MVCC의 실질적인 뼈대(탄약고)가 바로 이 놈입니다.

3. 트랜잭션 회복 (Crash Recovery)

• 정전이 나서 서버가 뻗었다 켜졌습니다.
• 켜자마자 DB는 "야! 아까 불 꺼질 때 COMMIT 도장 못 찍고 죽은 미완성 트랜잭션 찌끄러기 누구야?!" 색출해 낸 뒤, Undo 세그먼트에 있는 과거 데이터를 부어서 그 찌끄러기들의 흔적을 싹 다 파내고 깨끗하게 취소(Undo) 시켜버립니다. (235번 Undo 회복 기법)

Ⅳ. Undo 세그먼트의 저주: ORA-01555 에러 (스냅샷이 너무 낡았습니다) 🌟

세상에 무한한 창고는 없습니다.

• 원인: 지하 창고(Undo) 용량은 10GB뿐인데, 미친 관리자가 1시간 동안 데이터를 1,000만 건이나 UPDATE 해버렸습니다.
• 1시간 전 과거 사진, 30분 전 과거 사진이 창고에 꽉 찼습니다! 꽉 차면 어떻게 될까요? DB 엔진은 가장 낡고 오래된 '1시간 전 과거 사진'부터 분쇄기에 갈아서 지워버리고(덮어쓰기) 새 과거 사진을 밀어 넣습니다.
• 대참사: 이때, 영화를 보듯이 엄청나게 긴 엑셀 통계를 1시간째 멍때리며 읽고(Read) 있던 불쌍한 고객 1명이 있었습니다. 이 고객은 1시간 전 데이터를 계속 읽어야 하는데, 방금 Undo 창고에서 그 1시간 전 사진이 용량 부족으로 삭제되어 증발해 버렸습니다!!
• 고객의 모니터에는 치명적인 죽음의 에러 메시지가 뜹니다. "ORA-01555: snapshot too old (스냅샷이 너무 오래되어 볼 수 없습니다)". 데이터가 썩어서 더 이상 과거를 보여줄 수 없게 되어 쿼리가 터져버리는, 데이터베이스 관리자(DBA)가 밤잠을 설치는 가장 끔찍하고 유명한 Undo 에러입니다.

📢 섹션 요약 비유: Undo 세그먼트는 마술 쇼 무대 뒤에 숨겨진 **'비밀 쓰레기통 겸 과거 사진 보관함'**입니다. 마술사(트랜잭션)가 무대 위에서 비둘기를 모자로 바꾸는 마술(UPDATE)을 부립니다. 비둘기를 그냥 날려 보내는 게 아닙니다. 마술사는 잽싸게 비둘기(과거 데이터)를 무대 뒤 지하 창고(Undo 세그먼트)에 쑤셔 박아둡니다. 왜 박아둘까요? 1. 마술이 실패해서 "아 취소(ROLLBACK)!"라고 외치면, 지하 창고 문을 열고 잽싸게 아까 그 비둘기를 꺼내와 아무 일 없었던 척하기 위해서. 2. 무대 뒤쪽 구석 자리에 앉은 관객(Read 조회)들이 "아직 모자로 덜 변했는데, 원래 뭐였지?" 하고 고개를 빼꼼 내밀 때, 피투성이 모자(미확정 데이터)를 보여주지 않고 창고에 쑤셔 박아둔 온전한 '비둘기 사진(과거 스냅샷)'을 쓱 보여줘서 안심시키기 위해서입니다(MVCC 읽기 일관성). 하지만 마술사가 손이 너무 빨라 수만 개의 물건을 미친 듯이 지하 창고에 쑤셔 박다 보면, 창고가 꽉 차서(용량 초과) 맨 밑에 있던 비둘기가 압사당해 사라져 버립니다. 그때 뒤늦게 온 굼벵이 관객이 "아까 1시간 전 비둘기 좀 볼 수 있어?"라고 물으면 마술사는 창고가 비어 멘붕에 빠지며 ORA-01555 에러를 뿜고 쇼를 망쳐버리게 됩니다.