[MSSQL] Error 1205 Deadlock Victim

Error 1205 – Deadlock Victim

유형: 일반오류형 · DBA 개입이 필요한 고급 트랜잭션 장애

1️⃣ 대표 오류 메시지

Transaction (Process ID xx) was deadlocked on resources with another process and has been chosen as the deadlock victim

2️⃣ 장애 개요

Error 1205는 단순히 “락이 충돌했다”는 의미가 아닙니다.
DB 내부의 Lock Manager가 여러 트랜잭션 간 락 대기 관계를 그래프로 구성한 뒤, 데드락 사이클을 감지하고 그중 하나의 트랜잭션을 의도적으로 종료(kill)했음을 의미합니다.

핵심 포인트
- 데드락은 “우연”이 아니라 구조적 문제
- DB가 살아남기 위해 한 트랜잭션을 희생시킨 결과
- 재시도하면 성공하는 경우가 많아 문제를 숨기기 쉬움

3️⃣ 왜 이 오류가 고급 장애인가

• 단순 락 대기가 아니라 순환 대기(cycle) 발생
• Lock Manager가 내부적으로 대기 그래프를 생성
• 각 트랜잭션의 비용(cost)을 계산
• 가장 “저렴한” 트랜잭션을 데드락 희생자로 선택

즉, Error 1205는 DB가 임의로 종료한 것이 아니라
시스템 안정성을 유지하기 위한 합리적 판단 결과입니다.

4️⃣ 사용자 입장에서 보이는 증상

• 특정 요청이 가끔 실패했다가 재시도하면 성공
• 동일 기능인데 사용자마다 성공/실패가 갈림
• 장애 로그에는 에러가 찍히지만 서비스는 계속 동작

위험한 착각
“재시도하면 되니까 괜찮다” → 구조적 문제 방치
트래픽 증가 시 대규모 장애로 확장될 가능성 큼

5️⃣ DBA가 봐야 하는 본질

• 접근 순서 불일치
  Table A → B 와 B → A가 혼재
• 인덱스 부재
  불필요한 범위 락(S / IX / X) 확장
• 격리 수준 문제
  Serializable / Repeatable Read 사용으로 락 강도 증가
• 트랜잭션 범위 과다
  여러 테이블을 길게 묶어 처리
• 숨은 쿼리 경로
  트리거, FK 체크, 내부 조회까지 포함한 전체 흐름

6️⃣ DBA 레벨 대응 전략

① Deadlock Graph 분석
- DB가 제공하는 데드락 그래프(XML/텍스트) 분석
- 실제 충돌한 객체와 순서 파악

② 접근 순서 통일
- 모든 트랜잭션이 동일한 테이블/인덱스 순서로 접근
- 코드 규칙 수준에서 강제

③ 인덱스 재설계
- 조건 컬럼에 적절한 인덱스 추가
- 범위 스캔 → 포인트 접근으로 전환

④ 트랜잭션 구조 개선
- 트랜잭션을 짧게 유지
- retry-safe(재시도 안전) 구조로 설계

7️⃣ 기본 오류 대응 4단계

1) 현상 확인: Error 1205 발생 시점과 빈도
2) 그래프 분석: 어떤 자원이 순환 대기인지 파악
3) 구조 수정: 접근 순서·인덱스·트랜잭션 범위 조정
4) 재발 방지: 개발 규칙화 + 모니터링 추가

8️⃣ 반드시 기억해야 할 결론

👉 “쿼리만 고쳐주세요”로 해결되는 단계가 아님
👉 트랜잭션 설계·인덱스·접근 순서의 문제
👉 DBA 관점에서 전체 흐름을 재설계해야 함

Error 1205는 “DB가 약하다”는 신호가 아니라,
시스템이 이미 한계 상황에서 스스로를 보호하고 있다는 신호입니다.
이 단계에서의 대응 품질이 서비스 안정성을 결정합니다.