VACUUM & AUTOVACUUM — 테이블 부풀음(Bloat) 원인 · 자동청소 튜닝
📋 실습 안내
✏️ CODE EDITOR (JSX)
▶ 실행 버튼을 눌러 코드를 테스트하세요.
👁️ 내 미리보기
내 코드 실행 결과
🎯 완성 미리보기
목표
위 에디터 코드를 수정해서 이 결과물과 똑같이 만들어보세요!
💡 TODO 주석을 채워서 위 결과물처럼 동작하게 만들어보세요
🤖 AI 선생님에게 질문하기
이번 강의 전용
▼
선생님이 답변 중이에요...
⚠️ 학습 관련 질문만 답변합니다. 관련 없는 질문은 자동으로 학습으로 유도됩니다.
Q1. PostgreSQL에서 UPDATE 실행 후 기존 행이 즉시 삭제되지 않고 남아 있는 것을 무엇이라고 하는가?
💡 MVCC 구조에서 UPDATE/DELETE된 행은 Dead Tuple로 남아 VACUUM이 회수할 때까지 테이블 파일에 존재합니다.
Q2. VACUUM FULL과 일반 VACUUM의 가장 큰 차이점은?
💡 VACUUM FULL은 테이블을 완전히 재작성하여 OS로 공간을 반환하지만, 실행 중 테이블 잠금(AccessExclusiveLock)이 발생하여 운영 서비스에 영향을 줍니다.
Q3. Transaction ID Wraparound 문제를 예방하기 위해 VACUUM이 수행하는 작업은?
💡 VACUUM FREEZE는 행의 XID를 특수한 Frozen XID(2번)로 변환하여 Wraparound 위험에서 영구적으로 보호합니다.
Q4. 대형 테이블(수억 건)에서 AUTOVACUUM이 너무 늦게 실행되는 문제를 해결하는 가장 올바른 방법은?
💡 scale_factor 기본값 0.2는 대형 테이블에서 수천만 건의 Dead Tuple이 쌓여야 청소가 시작됩니다. 테이블별 ALTER TABLE SET으로 0.01로 낮추면 조기 청소가 가능합니다.
Q5. 다음 중 VACUUM이 Dead Tuple을 회수하지 못하도록 방해하는 요인은?
💡 오래된 스냅샷을 가진 장기 트랜잭션이 존재하면, 해당 스냅샷 이후에 생성된 Dead Tuple을 VACUUM이 제거할 수 없습니다. idle_in_transaction_session_timeout 설정으로 방지합니다.
😅
아쉽네요!
점수: 0점 — 70점 이상이 되어야 통과합니다.