트랜잭션(transaction)이란?
- 데이터베이스의 상태를 변화시키기 위해 수행하는 하나의 논리적인 작업 단위
여기서 상태를 변화시킨다는 의미는 SQL DML(조작어)를 통해 DB에 접근하는 것을 의미한다. (SELECT,INSERT,DELETE,UPDATE) - 데이터베이스에 장애가 발생했을 때, 데이터를 복구하는 작업의 단위가 되기도 함
- 일반적으로 데이터베이스 연산은 SQL문으로 표현되므로 트랜잭션을 작업 수행에 필요한 SQL문들의 모임으로 이해해도 된다.
트랜잭션 예시
예시) 유저 A가 유저 B에게 10,000원을 송금하는 상황
- 이때 DB 작업
- 유저 A의 계좌에서 만원을 차감한다 : UPDATE문을 이용해 유저 A의 잔고를 변경
- 유저 B의 계좌에 만원을 추가한다 : UPDATE문을 이용해 유저 B의 잔고를 변경
두 UPDATE문을 처리하는 순서는 중요하지 않지만 둘 다 정상적으로 실행되어야 함.
만약, 첫번 째 UPDATE문이 실행된 후 시스템에 장애가 발생하여 두번 째 UPDATE문이 실행되지 않는다면 유저 A의 돈은 뿅! 하고 사라지게 되므로 모순된 상황이 발생한다.
이를 방지하기 위해, 출금 UPDATE문과 입금 UPDATE문을 묶어 하나의 작업 단위를 만들 수 있는데, 이를 하나의 트랜잭션(transaction)으로 본다.
모든 쿼리 문이 성공적으로 완료되어야만 "하나의 작업(트랜잭션)"이 완료되는 것으로 보고, 작업 단위에 속하는 쿼리 중 하나라도 실패하면 모든 쿼리문을 취소하고 데이터베이스를 이전 상태로 돌려놓아야 한다.
성공하면 commit, 실패하면 rollback을 수행한다.
- Commit
하나의 트랜잭션이 성공적으로 끝났고, DB가 일관성있는 상태일 때 이를 알려주기 위해 사용하는 연산- Rollback
하나의 트랜잭션 처리가 비정상적으로 종료되었을 때, DB의 상태를 트랜잭션 시작 전 상태로 돌려놓는 연산
트랜잭션의 특성
트랜잭션이 성공적으로 처리되어 데이터베이스의 무결성과 일관성이 보장되려면
네 가지 특성을 꼭 만족해야 한다. 앞자를 따서 ACID 라고도 함
- Atomicity(원자성)
트랜젝션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 한다. - Consistency(일관성)
트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다. - Isolation(독립성)
둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다. - Durability(지속성)
트랜잭션이 성공적으로 완료 되었다면, 결과는 영구적으로 반영되어야 한다.
트랜잭션 관리를 위한 DBMS 전략
이해를 위한 2가지 개념 : DBMS의 구조 / Buffer 관리 정책
DBMS의 구조
크게 2가지 : Query Processor (질의 처리기), Storage System (저장 시스템)
입출력 단위 : 고정 길이의 page 단위로 disk에 읽거나 쓴다.
저장 공간 : 비휘발성 저장 장치인 disk에 저장, 일부분을 Main Memory에
저장
Page Buffer Manager or Buffer Manager
DBMS의 Storage System에 속하는 모듈 중 하나로, Main Memory에 유지하는 페이지를 관리하는 모듈
Buffer 관리 정책에 따라, UNDO 복구와 REDO 복구가 요구되거나 그렇지 않게 되므로, transaction 관리에 매우 중요한 결정을 가져온다.
UNDO
오퍼레이션 수행 중에 수정된 Page들이 Buffer 교체 알고리즘에 따라서 디스크에 출력될 수 있음. Buffer 교체는 transaction과는 무관하게 buffer의 상태에 따라 결정됨.
이로 인해, 정상적으로 종료되지 않은 transaction이 변경한 page들은 원상 복구 되어야 하는데, 이 복구를 undo라고 함.
수정된 페이지를 디스크에 쓰는 시점을 기준으로 다음과 같은 두 개의 정책으로 나누어 볼 수 있음.
- STEAL: 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
- ¬STEAL: 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT, End of Transaction)까지는 버퍼에 유지하는 정책
STEAL 정책은 수정된 페이지가 어떠한 시점에도 디스크에 써질 수 있기 때문에, 필연적으로 UNDO 로깅과 복구를 수반하는데, 거의 모든 DBMS가 채택하는 버퍼 관리 정책이다.
REDO
이미 commit한 transaction의 수정을 재반영하는 복구 작업이다.
Buffer 관리 정책에 영향을 받는다는 특징이 있음.
Transaction이 종료되는 시점에 해당 transaction이 수정한 page를 디스크에 쓸 것인가 아닌가에 따라 두 가지 정책이 구분됨.
- FORCE : 수정했던 모든 페이지를 Transaction commit 시점에 disk에 반영.
transaction이 commit 되었을 때 수정된 페이지들이 disk 상에 반영되므로 redo 필요 없음.- ¬FORCE: 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책
transaction이 disk 상의 db에 반영되지 않을 수 있기에 redo 복구가 필요. (대부분의 DBMS 정책)
FORCE 정책을 따르면 트랜잭션이 커밋되면 수정되었던 페이지들이 이미 디스크 상의 데이터베이스에 반영되었으므로 REDO 복구가 필요 없게 된다.
반면에 ¬FORCE 정책을 따른다면 커밋한 트랜잭션의 내용이 디스크 상의 데이터베이스 상에 반영되어 있지 않을 수 있기 때문에 반드시 REDO 복구가 필요하게 된다.
사실 FORCE 정책을 따르더라도 데이터베이스 백업으로부터의 복구, 즉 미디어(media) 복구 시에는 REDO 복구가 요구된다. 거의 모든 DBMS가 채택하는 정책은 ¬FORCE 정책이다.
정리해보면 DBMS는 버퍼 관리 정책으로 STEAL과 ¬FORCE 정책을 채택하고 있어, 이로 인해서 UNDO 복구와 REDO 복구가 모두 필요하게 된다.
출처
