공통 원인
장기 조회나 느린 정리가 과거 버전을 오래 붙잡습니다.
읽기 일관성은 유지되지만, 이미 끝난 변경본을 바로 버리지 못합니다.
공통 비용
버전 보관 공간과 백그라운드 정리 작업이 함께 늘어납니다.
문제의 본질은 같은데, 엔진마다 버전이 머무는 위치가 다릅니다.
비교 포인트
그래서 지표 이름보다 "정리 지연이 어디에 쌓이는가"를 먼저 봅니다.
Undo 공간, Purge 대기, Dead Tuple 중 어디가 먼저 부풀어 오르는지 확인합니다.
학습 포인트
같은 MVCC 병목도 DBMS마다 다른 운영 신호로 드러납니다.
숫자가 커졌다는 사실보다, 그 숫자가 어떤 정리 지연을 뜻하는지가 중요합니다.
DBMS
버전 보관 공간
Oracle
과거 버전이 Undo Tablespace에 남아 공간 압박으로 보입니다.
정리 대기 길이
MySQL
InnoDB가 아직 지우지 못한 변경 이력이 Purge backlog로 남습니다.
가비지 누적
PostgreSQL
삭제·갱신된 튜플이 VACUUM 전까지 테이블과 인덱스에 남습니다.
버전이 남는 곳
Undo 세그먼트
읽는 세션이 끝날 때까지 이전 이미지 보관
Undo 로그 + History List
Purge 스레드가 뒤에서 천천히 정리
테이블의 Dead Tuple
Autovacuum이 회수하기 전까지 실제 파일에 잔류
먼저 보는 지표
Undo Tablespace 사용량
버전 보관 때문에 공간이 얼마나 묶였는가
History List Length
Purge가 따라가지 못한 변경 이력이 얼마나 밀렸는가
n_dead_tup
정리되지 않은 죽은 행이 얼마나 누적됐는가
운영 해석
값이 계속 크면 장기 트랜잭션이나 Undo 압박을 의심합니다.
값이 늘면 쓰기 속도 > Purge 속도 상태가 길어졌다는 뜻입니다.
값이 높으면 Autovacuum 지연과 테이블·인덱스 비대화를 점검합니다.
대표 확인
dba_data_files
UNDOTBS1 사용량 확인
SHOW ENGINE INNODB STATUS
History list length 확인
pg_stat_user_tables
n_dead_tup 상위 확인