320x100
교착 상태란?
서로 다른 둘 이상의 프로세서들이 상대 프로세서가 차지하고 있는 자원을 기다리는 무한 대기 상태
예1) 선착순 이벤트
원인: 변경 쿼리의 조건 구문 차이로 인해 페이지 접근 순서가 문제
단계:
Session1 | Session2 | |
1단계 | BEGIN TRAN UPDATE 이벤트 SET 수량 = 수량 - 1 WHERE 이벤트번호 = 1 |
|
2단계 | BEGIN TRAN UPDATE 이벤트 SET 사용수량 = 사용수량 + 1 WHERE 계약번호 = 1 |
|
3단계 | 교착상태 |
개선: 접근 방향을 맞추기 위해 데이터 변경시 조건절을 동일한 기준으로 사용
지급과 사용에 대한 테이블 분리
예2) 조회 구문 변경
원인: 조회 구문에 컬럼을 추가하면서 데이터 페이지 접근이 필요하게 됨
Session1 | Session2 | |
1단계 | BEGIN TRAN UPDATE tabl01 SET name = '1' WHERE idx = 1 |
|
2단계 | SELECT name, registerdate FROM tabl01 WHERE idx = 1 | |
3단계 | 교착상태 |
개선: 격리 수준 조정(Session2에 with(readuncommitted) 추가)
인덱스 조정 (인덱스에 신규로 초가된 컬럼 반영)
예3) 배치 작업
원인: 대량 데이터 조회시 해당 테이블에 변경이 발생하면서 발생
Session1 | Session2 | |
1단계 | INSERT INTO temp SELECT * FROM tabl01 |
|
2단계 | INSERT INTO tabl01 values (....) | |
3단계 | 교착상태 |
개선: 격리 수준 조정(Session1 구문에 with(readuncommitted) 추가)
대량 조회시 with(readuncommitted) 필수
대량 변경시 100 ~ 500건씩 처리
예4) 친구 추가
원인: 양방향 관계를 구성하기 위해 (A,B), (B, A)를 입력함
Session1 | Session2 | |
1단계 | BEGIN TRAN INSERT INTO 친구 VALUES(A,B) |
|
2단계 | BEGIN TRAN INSERT INTO 친구 VALUES(B,A) |
|
3단계 | INSERT INTO 친구 VALUES(B,A) | |
4단계 | INSERT INTO 친구 VALUES(A,B) | |
5단계 | 교착상태 |
개선: Deadlock 발생시 Application 재처리 로직 추가
Application 로직 변경 (1,2단계는 실시간, 3,4단계는 Queue 처리)
정리
교착 상태 예방을 위한 방법
- 같은 순서로 개체 접근
- 트랜잭션 내에 사용자 상호 작용 제거
- 낮은 격리 수준을 사용
- 행 버전 지정 기반의 격리 수준 사용
출처: http://ndcreplay.nexon.com/NDC2014/sessions/NDC2014_0071.html
320x100
'NDC > DB' 카테고리의 다른 글
[NDC 2015] 마비노기 듀얼: 분산 데이터베이스 트랜잭션 설계와 구현 (0) | 2023.01.09 |
---|---|
[NDC 2015] 이 쿼리를 어떻게 짜야 잘 짰다고 소문이 날까? (0) | 2023.01.06 |
[NDC 2014] 라이브 상황에서 윈도우 서버 개발자가 겪은 좌충우돌 Redis 적용 경험담 (0) | 2021.12.25 |
[NDC 2013] 게임속에서의 NoSQL 활용하기 (0) | 2021.12.01 |
[NDC2013] 너무너무 훌륭한 MySQL (0) | 2021.11.12 |