트랜잭션
- 정의: 하나의 논리적 작업 단위를 구성하는 일련의 연산들의 집합.
- 집합 내의 연산들이 모두 성공해야 트랜잭션이 성공한 것으로 본다.
- 만약 트랜잭션이 도중에 실패하거나 정상적으로 실행될 수 없다면, 아무것도 실행되지 않은 처음 상태로 되돌려져야 한다(ROLLBACK).
- 트랜잭션 관리는 데이터베이스 완전성(integrity) 측면에서 중요하다.
트랜잭션의 ACID 성질
Atomicity(원자성)
- 계좌이체 과정 중에 트랜잭션이 실패하게 되어 예금이 사라지는 경우가 발생해서는 안 되기 때문에 DBMS는 완료되지 않은 트랜잭션의 중간 상태를 데이터베이스에 반영해서는 안 된다. 즉, 트랜잭션의 모든 연산들이 정상적으로 수행 완료되거나 아니면 전혀 어떠한 연산도 수행되지 않은 상태를 보장해야 한다. 원자성은 쉽게
'all or nothing'특성으로 설명된다.
Consistency(일관성)
- 고립된 트랜잭션의 수행이 데이터베이스의 일관성을 보존해야 한다. 즉, 성공적으로 수행된 트랜잭션은 정당한 데이터들만을 데이터베이스에 반영해야 한다. 트랜잭션의 수행을 데이터베이스 상태 간의 전이(transition)로 봤을 때, 트랜잭션 수행 전후의 데이터베이스 상태는 각각 일관성이 보장되는 서로 다른 상태가 된다. 트랜잭션 수행이 보존해야 할 일관성은 기본 키, 외래 키 제약과 같은 명시적인 무결성 제약 조건들뿐만 아니라, 자금 이체 예에서 두 계좌 잔고의 합은 이체 전후가 같아야 한다는 사항과 같은 비명시적인 일관성 조건들도 있다
Isolation(독립성)
- 여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션의 수행에 영향을 받지 않고 독립적으로 수행되어야 한다. 즉, 트랜잭션이 서로 간섭하지 않아야 한다는 것으로, 한 트랜잭션의 중간 결과가 다른 트랜잭션에게는 숨겨져야 한다는 의미인데, 이러한 isolation 성질이 보장되지 않으면 트랜잭션이 원래 상태로 되돌아갈 수 없게 된다.
- Isolation 성질을 보장할 수 있는 가장 쉬운 방법은 모든 트랜잭션을 순차적으로 수행하는 것이다. 하지만 병렬적 수행의 장점을 얻기 위해서 DBMS는 병렬적으로 수행하면서도 일렬(serial) 수행과 같은 결과를 보장할 수 있는 방식을 제공하고 있다.
Durability(지속성)
트랜잭션이 성공적으로 완료되어 커밋되고 나면, 해당 트랜잭션에 의한 모든 변경은 향후에 어떤 소프트웨어나 하드웨어 장애가 발생되더라도 보존되어야 한다.
트랜잭션의 종료 형태
- 문제 없이 정상적으로 수행된 경우: 커밋을 통해 종료됨.
- 사용자의 요청에 의하여 철회되거나, 잘못된 입력이 주어졌거나 일관성 제약 조건을 위배하는 상황이 발생한 경우
- 시스템이 감지하는 문제로 인하여 DBMS가 철회하는 경우(타임아웃, 교착 상태 등)
트랜잭션 관리 전략
DBMS의 전략
DBMS의 개략적인 구조
- DBMS는 주로 비휘발성 저장 장치인 디스크에 데이터를 저장하고, 전체 DB의 일부를 메인 메모리에 유지함.
- 데이터는 고정 길이의 page로 저장하며, 페이지 단위로 데이터 입/출력이 이루어짐.
- 메인 메모리에 유지하는 페이지들은 버퍼 관리자 또는 페이지 버퍼 관리자라고 함.
- DBMS는 명확하게 구분되는 계층(layered) 구조로 되어 있음
- 질의 처리기(Query Processor): 상부
- 저장 시스템(Storage System): 하부
- MySQL은 InnoDB, MyISAM 등의 여러 하부 저장 시스템을 선택할 수 있음
- 버퍼 관리 정책은 트랜잭션 관리 방식 결정에 영향을 미친다.
- UNDO 복구 방식
- REDO 복구 방식
UNDO
- 해당 트랜잭션이 정상적으로 종료될 수 없게 되면 트랜잭션이 변경한 페이지들을 원상 복구시키는 방식.
- 아직 완료되지 않은 트랜잭션이 수정한 페이지들이, 버퍼 관리자의 버퍼 교체 알고리즘에 의해 디스크에 출력되는 것을 막기 위함.
- 버퍼 관리자가 트랜잭션 종료 전에는 어떤 경우에도 수정된 페이지들을 디스크에 쓰지 않는다면, UNDO 오퍼레이션은 메모리 버퍼에 대해서만 이루어지면 되는 식으로 매우 간단해질 수 있다.
- 단, 매우 큰 크기의 메모리 버퍼가 필요하다는 단점이 있음.
- UNDO 방식에서의 버퍼 관리 정책(수정된 페이지를 디스크에 쓰는 시점 기준)
- STEAL: 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
- 거의 모든 DBMS가 채택하는 버퍼 관리 정책으로서, 수정된 페이지가 어떠한 시점에도 디스크에 써질 수 있으므로 UNDO 로깅과 복구를 수반함.
- ¬STEAL: 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT, End of Transaction)까지는 버퍼에 유지하는 정책
- STEAL: 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
REDO
- UNDO와 반대 개념으로서, 이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업을 의미함.
- 트랜잭션 실패가 발생하면, 이전 상태로 되돌아가 실패가 발생하기 전까지의 과정을 그대로 따라하는 것.
- 트랜잭션의 지속성(Durability)을 보장하기 위한 관리 방식.
- REDO 방식에서의 버퍼 관리 정책
- FORCE: 트랜잭션이 종료되는 시점에, 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
- 트랜잭션이 커밋되면, 수정된 페이지들이 이미 디스크 상의 DB에 반영되었으므로 REDO 복구가 필요 없어짐.
- ¬FORCE: 트랜잭션이 종료되는 시점에, 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책
- 단, 수정했던 페이지(데이터)를 디스크에 반영하지 않는다는 것이지, 커밋 시점에 어떠한 것도 쓰지 않는다는 것을 의미하지 않음에 유의한다.
- 커밋한 트랜잭션 내용이 DB상에 반영되어있지 않을 수 있기 때문에, 반드시 REDO 복구가 필요하게 된다.
- 거의 모든 DBMS가 채택하는 정책.
- FORCE: 트랜잭션이 종료되는 시점에, 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
트랜잭션 관리: 로그 기법
UNDO, REDO 복구를 위해 쓰이는 트랜잭션 관리 구조이다.
(추후 보완 예정)
출처
부족한 경험을 채우기 위한 나만의 기록 공간