[database] 트랜잭션 (Transaction)

트랜잭션이란?

트랜잭션(Transaction)이란 하나의 논리적 작업 단위를 구성하는 일련의 연산들의 집합이다. 다시말해, 데이터베이스의 상태를 변화시키기 위해 수행하는 작업 단위이다.

• 상태변화는 SQL 질의어 (SELECT, INSERT, UPDATE, DELETE)를 통해 데이터베이스에 접근하는 것을 뜻한다.
• 작업단위는 일련의 SQL 명령문의 집합으로, 하나의 논리적인 기능을 수행하기 위하여 사람이 정하는 기준에 따라 정의한 것이다.

사용자 A가 사용자 B에게 만원을 송금한다.

1. 사용자 A의 계좌에서 만원을 차감한다: UPDATE 문을 이용해 사용자 A의 계좌 잔고를 변경
2. 사용자 B의 계좌에 만원을 입금한다: UPDATE 문을 이용해 사용자 B의 계좌 잔고를 변경

현재 작업 단위는 1, 2 두개의 UPDATE 문이며, 이를 통틀어 하나의 트랜잭션이라 한다. 두 쿼리문이 모두 성공적으로 완료되어야만 하나의 트랜잭션이 완료되는 것이다. 만약 작업 단위에 속하는 쿼리 중 하나라도 실패할 경우, 모든 쿼리문을 취소하고 이전 상태로 되돌려 놓아야 한다.

트랜잭션의 특징

트랜잭션은 ACID 성질이라고 부르는 네 가지 성질로 설명된다.

Atomicity(원자성)
위의 예시에서 이체 과정중에 트랜잭션이 실패하게 되어 예금이 사라지는 경우가 발생해서는 안 되기 때문에 DBMS는 완료되지 않은 트랜잭션의 중간 상태를 데이터베이스에 반영해서는 안 된다. 즉, 트랜잭션의 모든 연산들이 정상적으로 수행 완료되거나 어떠한 연산도 수행되지 않은 상태를 보장해야 한다. “all or nothing”

Consistency(일관성)
트랜잭션의 수행은 데이터베이스의 일관성을 보존해야 한다. 트랜잭션 수행이 보존해야 하는 일관성은 기본 키, 외래 키 제약과 같은 명시적인 무결성 제약 조건들 뿐만 아니라, 자금 이체의 예시에서 두 계좌 잔고의 합은 이체 전후가 같아야 한다는 비명시적인 일관성 조건들도 포함한다.

Isolation(독립성)
여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션의 수행에 영향을 받지 않고 독립적으로 수행되어야 한다. 즉, 한 트랜잭션의 중간 결과가 다른 트랜잭션에게는 숨겨져야 한다는 의미이다.

Durability(지속성)
트랜잭션이 성공적으로 완료되어 커밋(Commit)되고 나면, 해당 트랜잭션에 의한 모든 변경은 영구적으로 반영되어야 한다.

• commit: 트랜잭션이 성공적으로 완료되고 데이터베이스가 일관성 있는 상태일 때 트랜잭션이 행한 연산이 완료된 것을 트랜잭션 관리자에게 알려주기 위해 사용하는 연산
• rollback: 트랜잭션이 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 트랜잭션의 일부가 정상적으로 처리되었더라도 원자성을 구현하기 위해 트랜잭션이 행한 모든 연산을 취소(Undo)하는 연산

트랜잭션 상태

1. active: 트랜잭션이 실행중인 상태
2. failed: 트랜잭션 실행 도중 오류가 발생하여 중단된 상태
3. aborted: 트랜잭션이 비정상적으로 종료되어 rollback 연산을 수행한 상태
4. partially committed: 트랜잭션의 마지막 연산까지 실행했지만, commit 연산은 실행되지 않은 상태
5. committed: 트랜잭션이 성공적으로 종료되어 commit 연산을 실행한 후의 상태

트랜잭션 관리를 위한 DBMS 전략

데이터베이스 시스템은 보통 디스크에 데이터를 저장하며, 일부분을 메인 메모리에 유지한다. DBMS는 데이터를 고정 길이의 페이지(page)단위로 저장하는데, 디스크에서 읽거나 쓸 때 페이지 단위로 입출력이 이루어진다.

DBMS는 크게 질의 처리기(Query Processor)와 저장 시스템(Storage System) 두 가지로 나뉜다. 페이지 버퍼(page buffer) 혹은 버퍼 관리자는 메인 메모리에 유지하는 페이지들을 관리한다. 버퍼 관리 정책에 따라 UNDO 복구와 REDO 복구가 요구되거나 그렇지 않게 되므로 트랜잭션 관리 측면에서 매우 중요한 결정을 가져온다.

UNDO: 원상태로 되돌림

정상적으로 commit되지 않은 트랜잭션이 변경한 페이지들을 원래대로 되돌려 놓는 작업

UNDO는 사용자가 했던 작업을 반대로 진행해 원래의 상태로 되돌려 놓는 작업니다. 버퍼 교체는 트랜잭션과 무관하게 버퍼의 상태에 따라 결정되기 때문에 수정된 페이지가 버퍼 교체 알고리즘에 따라 디스크에 저장될 수 있다. 이러한 경우 UNDO 작업을 통해 원래대로 복구한다.

• STEAL: 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책으로 대부분의 DBMS가 채택하는 버퍼 관리 정책으로 UNDO logging과 복구를 필요로 한다.
• ¬STEAL: 수정된 페이지들을 트랜잭션이 끝날 때까지 버퍼에 유지하는 정책으로 UNDO 작업이 필요하지 않지만, 매우 큰 메모리 버퍼가 필요하다.

REDO: 원상태로 되돌림

이미 commit한 트랜잭션의 수정을 재반영하는 복구 작업

이전 상태로 되돌아간 후, 실패가 발생하기 전까지의 과정을 그대로 따라가는 작업이다. REDO를 하기 위해서는 정상적으로 실행 되기까지의 과정을 기록해야 하는데, 이를 log라고 한다. 트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 페이지를 디스크에 쓸 것인지 아닌지로 분류한다.

• FORCE: 수정했던 모든 페이지를 트랜잭션 commit 시점에 디스크에 반영한다. 따라서 REDO 작업이 필요 없다.
• ¬FORCE: commit 시점에 디스크에 반영하지 않는 정책으로 대부분의 DBMS가 채택하고 있다. 트랜잭션이 디스크상의 데이터베이스에 반영되지 않을 수 있기 때문에 REDO 복구가 필요하다.