트랜잭션
트랜잭션은 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미한다.
예시) 사용자 A가 사용자 B에게 만원을 송금한다
1. 사용자 A의 계좌에서 만원을 차감한다: UPDATE를 통해 사용자 A의 잔고 변경
2. 사용자 B의 계좌에 만원을 추가한다: UPDATE를 통해 사용자 B의 잔고 변경
작업 단위: 출금 UPDATE + 입금 UPDATE
=> 통틀어 하나의 트랜잭션이라고 한다.
- 위 두 쿼리문이 모두 성공적으로 완료되어야만 하나의 작업 완료트랜잭션 특징
- 트랜잭션은 데이터베이스 시스템에서 병행 제어 및 회복 작업 시 처리되는 작업의 논리적 단위이다.
- 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업 단위이다.
- 하나의 트랜잭션은 Commit 되거나 Rollback된다.
트랜잭션 성질 (ACID 성질)
Atomicity(원자성)
- all or nothing
- 트랜잭션의 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.
- 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.
savePoint
savePoint는 트랜잭션 내부에서 사용자가 지정할 수 있는 세부 작업 단위라고 생각할 수 있다. 특정 지점에 savePoint를 설정한 후 Rollback to savePoint1을 통해 해당 지점으로 롤백을 할 수 있다. 기억해야할 점은 아래 그림에서 SP1으로 롤백을 한 뒤에는 미래 시점인 SP2의 savePoint는 삭제된다는 것이다.
Consistency(일관성)
- 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다.
- 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.
(기본 키, 외래 키 제약과 같은 명시적인 무결성 제약 조건뿐만 아니라, 위의 예시에서 두 계좌의 잔고의 합은 이체 전후가 같아야한다는 사항 같은 비명시적인 일관성 조건도 있다.)
Isolation(독립성)
- 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행 중에 다른 트랜잭션의 연산이 끼어들 수 없다.
- 수행 중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.
- isolation 성질을 보장할 수 있는 가장 쉬운 방법은 모든 트랜잭션을 순차적으로 수행하는 것이지만, 병렬적 수행의 장점을 얻기 위해 DBMS는 병렬적으로 수행하면서도 일렬 수행과 같은 결과를 보장할 수 있는 방식을 제공한다.
Durablility(영속성)
- 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.
트랜잭션 연산 및 상태
Commit 연산
- Commit 연산은 한 개의 논리적 단위(트랜잭션)에 대한 작업이 성공적으로 끝났고 데이터베이스가 다시 일관된 상태에 있을 때, 이 트랜잭션이 행한 갱신 연산이 완료된 것을 트랜잭션 관리자에게 알려주는 연산이다.
Rollback 연산
- Rollback 연산은 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되었더라도 트랜잭션의 원자성을 구현하기 위해 이 트랜잭션이 행한 모든 연산을 취소(Undo)하는 연산이다.
- Rollback 시에는 해당 트랜잭션을 재시작하거나 폐기한다.
트랜잭션의 상태
활동(Active)
트랜잭션이 실행 중인 상태
실패(Failed)
트랜잭션 실행에 오류가 발생하여 중단된 상태
철회(Aborted)
트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태
부분 완료(Partially Committed)
트랜잭션의 마지막 연산까지 실행하고 Commit 연산이 실행되기 직전의 상태
완료(Committed)
트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태
부분완료 vs 완료
commit 요청이 들어오면 상태는 부분 완료 상태가 된다. 이후 commit을 문제 없이 수행할 수 있다면 완료 상태로 전이되고, 만약 오류가 발생하면 실패 상태가 된다. 즉 부분완료는 commit 요청이 들어왔을 때를 의미하고, 완료 상태는 commit을 정상적으로 완료한 상태를 의미한다.
트랜잭션을 사용할 때 주의할 점
트랜잭션은 꼭 필요한 최소의 코드에만 적용하는 것이 좋다.
여러 개의 트랜잭션으로 쪼개서 트랜잭션의 범위를 최소화하라는 의미다.
일반적으로 데이터베이스 커넥션의 개수가 제한적이다. 그런데 각 단위 프로그램이 커넥션을 소유하는 시간이 길어지면 사용 가능한 여유 커넥션의 개수는 줄어들게 된다. 이러면 각 단위 프로그램에서 커넥션을 가져가기 위해 기다려야 하는 상황이 발생할 수도 있기 때문이다.
데이터베이스 커넥션이란 애플리케이션과 데이터베이스를 연결을 뜻하는 것으로, 애플리케이션에서 데이터베이스에 접속하고 접속을 종료하는 일련의 과정을 의미한다.
트랜잭션 관리를 위한 DBMS의 전략
이를 이해하기 위해서는 DBMS의 구조와 Buffer 관리 정책에 대한 이해가 필요하다.
하지만 저는 이해를 못했습니다..
DBMS 구조
데이터베이스 시스템은 보통 비휘발성 저장 장치인 디스크에 데이터를 저장하며 전체 데이터베이스의 일부분을 메인 메모리에 유지한다. DBMS는 데이터를 고정 길이의 페이지로 저장하며, 디스크에서 읽거나 쓸 때에 페이지 단위로 입출력이 이루어진다.
DBMS는 각 제품마다 구조가 다르기는 하지만, 크게 질의 처리기(Query Processor)와 저장 시스템(Storage System)으로 나눌 수 있다.
MYSQL의 경우에는 InnoDB, MyISAM 등과 같이 여러 하부 저장 시스템을 선택할 수 있는데, 이와 같은 모델은 상부의 질의 처리기와 하부의 저장 시스템 간의 명확하게 구분되는 계층 구조에 해당한다.
CUBRID 역시 질의 처리기와 저장 시스템 두 개의 구성 요소로 이루어져 있으며, 질의 처리기와 저장 시스템이 좀 더 밀접하게 연결되어 있다.
페이지 버퍼 관리자 or 버퍼 관리자
메인 메모리에 유지하는 페이지들을 관리하는 모듈
버퍼 관리 정책이 트랜잭션 관리에 매우 중요한 결정을 가져온다. 버퍼 관리 정책에 따라서 트랜잭션의 UNDO 복구와 REDO 복구가 요구되거나 그렇지 않게 된다.
UNDO는 왜 필요한가
오퍼레이션 수행 중에 수정된 페이지들이 버퍼 관리자의 버퍼 교체 알고리즘에 따라서 디스크에 출력될 수 있다. 버퍼 교체는 전적으로 버퍼의 상태에 따라서 결정되며, 일관성 관점으로 봤을 때는 임의의 방식으로 일어나게 된다. 즉 아직 완료되지 않은 트랜잭션이 수행한 페이지들도 디스크에 출력이 될 수 있으므로, 만약 해당 트랜잭션이 어떤 이유든 정상적으로 종료될 수 없게 되면 트랜잭션이 변경한 페이지들은 원상 복구 되어야 한다. 이러한 복구를 UNDO라고 한다.
만약 버퍼 관리자가 트랜잭션 종료 전에는 어떤 경우에도 수정된 페이지들을 디스크에 쓰지 않는다면, UNDO 오퍼레이션은 메모리 버퍼에 대해서만 이루어지면 되는 식으로 매우 간단해질 수 있다. 이 정책은 매우 큰 크리의 메모리 버퍼가 필요하다는 문제점을 가지고 있다.
REDO는 왜 필요한가
커밋한 트랜잭션의 수정은 어떤 경우에도 유지되어야 한다. 이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업을 REDO 복구라고 하는데, REDO 복구 역시 UNDO 복구와 마찬가지로 버퍼 관리 정책에 영향을 받는다.
참고
[DB기초] 트랜잭션이란 무엇인가?
DB 트랜잭션(Transaction)
[DB] 트랜잭션(Transaction)이란? | ACID
[Database] 트랜잭션이란?
