All
트랜잭션의 이해
데이터 동시 접근 문제
•
동일 데이터에 다수 사용자 접근 허용시 일관성이 훼손
트랜잭션 개념
•
데이터베이스를 조작하기위한 하나의 논리적 단위를 이루는 일련의 데이터베이스 연산의 집합
•
데이터베이스를 사용하여 처리하는 작업을 하나의 묶음으로 인식하여 묶음 단위로 실행된 것과 동일한 결과가 도출되도록 정의한 개념
데이터 읽기과 쓰기
•
Read(X): 데이터베이스에서 데이터X를 읽고 트랜잭션이 실행되는 메모리의 변수 X에 값을 저장하는 연산
•
Write(X): 트랜잭션이 실행되는 메모리에 있는 변수 X의 값을 데이터베이스에 저장하는 연산
트랜잭션의 특징
ACID
•
원자성(Atomicity): 하나의 트랜잭션에 포함된 모든 연산은 완전히 수행되거나 전혀 수행되지 않음
•
일관성(Consistency): 특정 트랜잭션이 수행되기 전과 후에 데이터베이스가 일관된 상태를 유지
•
고립성(Isolation): 특정 트랜잭션이 데이터베이스를 갱신하는 동안 다른 트랜잭션에 의해 방해받지 않음
•
지속성(Durability): 완료된 트랜잭션의 결과는 어떠한 시스템의 장애에도 데이터베이스에 반영되어야 함
트랜잭션 실행 연산자
•
커밋(Commit): 트랜잭션 연산에 의해 갱신된 데이터 항목의 값을 데이터베이스에 반영시키고 지속성을 확보
•
롤백(Rollback): 트랜잭션이 중단되기 이전까지 수행한 연산에 의해 갱신된 모든 데이터 항목의 값을 무효화하여 일관성을 확보
트랜잭션의 상태
•
동작: 트랜잭션이 시작을 준비 또는 실행중인 상태
•
부분 커밋: 모든 연산을 마치고 커밋 직전 대기 상태
•
커밋: 트랜잭션이 성공적으로 종료되어 변경 사항이 영구 저장된 상태
•
실패: 실행 도중 오류가 발생하여 더 이상 진행할 수 없는 상태
•
중단: 트랜잭션이 취소되어 모든 변경이 원상 복구된 상태
트랜잭션의 동시성
동시성이란?
•
DBMS는 다수의 사용자가 데이터베이스를 공용으로 사용하기 위한 목적으로 도입
•
다중 사용자 환경에서 트랜잭션 동시 실행으로 데이터 갱신시, 일관성 훼손 문제 발생
•
트랜잭션 동시 실행 이점
◦
트랜잭션 처리율과 자원 이용률 향상
◦
트랜잭션 대기 시간 감소
•
동시성 제어(Concurrency Control)
◦
다수의 트랜잭션이 성공적으로 동시에 실행되어도 일관성을 유지할 수 있도록 지원하는 기법
스케줄
•
여러 트랜잭션들이 동시에 실행될 때, 각각의 Read/Write 연산들이 실제로 어떤 순서로 실행되었는지를 표현한 것
•
데이터베이스는 트랜잭션들이 동시에 접근하더라도 일관성 유지를 위해 스케줄 제어를 한다
직렬 스케줄
•
하나의 트랜잭션이 모두 끝난 후 다음 트랜잭션이 실행됨
•
가장 안전하지만 동시성 없음 → 비효율적
병렬 스케줄
•
여러 트랜잭션의 연산이 서로 섞여 실행됨
•
성능은 향상되지만 일관성 훼손 위험 존재
트랜잭션의 직렬화
•
병렬 스케줄을 직렬처럼 만들어서 일관성 훼손 문제가 발생하지 않도록 하는것
직렬 가능 스케줄
•
트랜잭션 간 연산 순서를 교환하여 트랜잭션을 직렬 스케줄과 동등하게 변환이 가능한 스케줄
•
사용된 Read와 Write 연산 교환시 상황에 따라 실행결과에 일관성이 훼손되는 현상(충돌발생)
•
이를 판단하기 위해 충돌 직렬성 판단
충돌(Conflict)
•
같은 데이터 접근
•
적어도 하나는 Wirte 연산
충돌 동등
•
두 개의 스케줄에서 연산 순서를 바꿔도 충돌이 없는 경우, 동일한 결과를 낼 수 있으면 충돌 동등
충돌 직렬성
•
충돌 동등한 스케줄을 어떤 직렬 스케줄로 변환 가능하다면, 그 스케줄은 충돌 직렬 가능
T1: R(A)
T2: R(A)
T1: W(A)
T2: W(A)
SQL
복사
•
T1의 W(A)와 T2의 W(A)가 충돌함
•
이 순서를 바꾸면 결과가 달라질 수 있음 → 직렬 불가능 → 충돌 직렬성 X
트랜잭션의 회복
•
트랜잭션 실패시, 원자성을 보장하기 위해 실행된 모든 연산을 실행 이전 상태로 복원하는 기법
회복 불가능한 스케줄
커밋 순서가 잘못된 경우, 원자성 보장이 어려워지는 스케줄
•
어떤 트랜잭션 Tj가 다른 트랜잭션 Ti가 기록한 데이터를 읽은 후, 먼저 커밋하는 경우
•
만약 Ti가 실패(롤백) 된다면, 이미 커밋한 Tj는 잘못된 데이터를 기반으로 커밋한 것이 되므로, 회복이 불가능
T5: Write(A)
T6: Read(A) → Commit
T5: Fail
SQL
복사
•
T6이 T5가 쓴 A를 읽고 먼저 커밋해버렸기 때문에, T5가 실패해도 T6의 커밋은 무효화할 수 없음 → 데이터 무결성 손상
•
T6은 T5가 먼저 커밋한 후에만 커밋해야함
회복 가능한 스케줄
읽은 트랜잭션보다 기록한 트랜잭션이 먼저 커밋하는 스케줄
•
Tj가 Ti가 쓴 데이터를 읽는 경우, 반드시 Ti가 먼저 커밋된 이후에 Tj가 커밋해야 함
•
만약 Ti가 실패하면, Tj도 커밋하지 않고 롤백함 → 데이터 무결성 유지
단점:
•
커밋간 의존성 발생
•
하나의 트랜잭션이 롤백되면 여러 트랜잭션이 연쇄적으로 롤백될 수 있음 → 연쇄적 롤백
-- T2가 T1의 언커밋된 데이터를 읽어도,
-- T2는 T1 커밋 후에만 커밋이 허용됨T1: Write(X)
T2: Read(X)
T1: Commit
T2: Commit
SQL
복사
비연쇄적 스케줄
연쇄적 롤백조차 일어나지 않도록 설계된 안전한 스케줄
•
Tj가 Ti가 쓴 데이터를 읽기 전에, Ti가 이미 커밋된 상태여야 함
•
즉, 커밋된 트랜잭션의 데이터만 읽기 허용
-- T1이 먼저 커밋한 뒤에야 T2가 읽고 커밋
T1: Write(X)
T1: Commit
T2: Read(X)
T2: Commit
SQL
복사
•
T2는 커밋된 데이터만 읽었기 때문에, T1이 롤백되는 일은 애초에 없음
•
→ 회복 시에도 롤백 전파가 발생하지 않음
•
가장 안전하고 효율적인 구조지만, 실행 제약이 있음