운영에서 먼저 볼 것

긴 트랜잭션은 오래된 버전 정리를 멈추게 만든다

MVCC는 읽기와 쓰기를 서로 덜 막게 해 주지만, 끝나지 않은 트랜잭션이 오래 남아 있으면 과거 스냅샷을 유지하느라 저장 공간과 정리 작업에 부담이 쌓입니다.

탐지
시작 시각이 오래된 세션을 먼저 찾고, 얼마나 오래 열려 있는지 본다.
판단
긴 조회인지, idle in transaction인지, 정리 지연을 만드는 세션인지 구분한다.
조치
트랜잭션 경계를 짧게 유지해 undo 보관, purge, vacuum 대기를 줄인다.

긴 트랜잭션이 만드는 공통 흐름

1. 스냅샷 고정

읽기 시작 시점의 가시성 기준을 오래 유지한다.

과거 버전 필요
2. 정리 지연

이미 끝난 변경도 바로 치우지 못하고 남겨 둔다.

undo / dead tuple
3. 운영 부담

공간 사용 증가, purge·vacuum 지연, 스냅샷 오류 위험이 커진다.

성능 저하
DBMS
오래 열리면 무엇이 묶이나
어디서 찾나
Oracle
Undo 블록 보관이 길어짐

오래된 읽기가 계속 남아 있으면 과거 버전을 더 오래 유지해야 하므로 ORA-01555 위험도 함께 올라간다.

세션 + 트랜잭션 시작 시각

오래 열린 세션과 사용 중인 undo 양을 같이 본다.

v$session + v$transaction
MySQL
Purge가 치울 수 있는 시점이 늦어짐

오래된 ReadView가 남아 있으면 제거 가능한 undo 버전의 경계가 뒤로 밀린다.

활성 트랜잭션 지속 시간

얼마나 오래 열린 trx인지 먼저 정렬해 확인한다.

information_schema.innodb_trx
PostgreSQL
VACUUM이 지울 수 없는 행 버전이 늘어남

특히 idle in transaction 세션은 dead tuple 정리와 xid 소모 관리에 직접 부담을 준다.

대기 중인 트랜잭션 세션

쿼리는 끝났지만 트랜잭션이 닫히지 않은 세션을 본다.

pg_stat_activity
실무 takeaway: MVCC는 비차단 읽기를 주지만, 긴 트랜잭션을 방치하면 그 대가가 저장 공간과 정리 지연으로 돌아온다. 그래서 운영에서는 먼저 장기 트랜잭션을 찾고, 트랜잭션 경계를 짧게 유지해야 한다.