참고링크
1.트랜잭션이란?
하나의 논리적 작업 단위를 구성하는 연산들의 집합을 트랜잭션이라고 합니다.
대표적인 예로,
- 한 계좌에서 10만원을 인출
- 다른 계좌로 10만원을 이체
이런 일련의 작업은 전체 작업이 정상적으로 완료되거나, 정상적으로 처리되지 않는경우 아무것도 실행되지 않은 처음 상태로 되돌려져야 합니다.
2. ACID
흔히 트랜잭션은 ACID 성질이라고 하는 네 가지 정의로 설명됩니다.
2.1. Atociticy(원자성)
DBMS는 완료되지 않은 트랜잭션(작업 단위)의 중간 상태를 DB에 번영해서는 안됩니다.
쉽게 ‘all or nothing‘특성으로 설명됩니다.
2.2. Consistency(일관성)
고립된 트랜잭션 수행이 DB의 일관성을 보존해야 합니다.
성공적으로 수행된 트랜잭션은 정당한 데이터들만을 DB에 반영해야 한다는 말입니다.
트랜잭션 수행으로 보존해야 할 일관성은 PK, FK 제약 같은 명시적인 무결성 제약조건 뿐만 아니라, 자금 이체 예에서 두 계좌의 잔고 합이 이체 전후 둘다 같아야 한다는
비명시적인 일관성 조건들도 있습니다.
2.3. Isolation(독립성)
여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션에 영향을 받지않고 독립적으로 수행되어야 합니다.
이러한 isolation성질이 보장되지 않으면 트랜잭션이 원래 상태로 되돌아 갈 수 없게 됩니다.
DBMS는 병렬적으로 트랜잭션을 수행하면서도 일렬수행과 같은 결과를 보장할 수 있는 방식을 제공합니다.
2.4. Durability(지속성)
트랜잭션이 성공적으로 커밋되고 나면, 해당 트랜잭션에 의한 모든 변경은 어떤 장애가 발생되더라도 보존되어야 합니다.
3. 트랜잭션 관리를 위한 DBMS의 전략
데이터베이스 시스템은 보통 디스크에 데이터를 저장하며, 전체 데이터베이스의 일부분을 메인 메모리에 유지합니다.
DBMS는 데이터를 고정 길이의 page로 저장하며, 디스크에서 page단위로 입출력이 이루어집니다.
메인 메모리에 유지하는 page들을 page buffer(버퍼 관리자)라고 부르는대, DBMS에서 매우 중요한 모듈 중 하나입니다.
버퍼 관리 정책이 트래잭션 관리에 매우 중요한 결정을 가져옵니다. 버퍼 관리 정책에 따라서 UNDO복구와 REDO복구가 요구되거나 그렇지 않게 됩니다.
3.1. UNDO
오퍼레이션(명령어) 수행 중에 수정된 page들이 page buffer에 의해 디스크에 쓰여질 수 있습니다. 이는 임의의 방식으로 일어나게 됩니다.
즉, 아직 완료되지 않은 트랜잭션이 수정한 page들도 디스크에 출력될 수 있으므로, 만약 트랜잭션이 정상적으로 종료될 수 없게되면 트랜잭션이 변경한 page(데이터)들은 원상 복구되어야 합니다.
page buffer가 트랜잭션 종료 전에 절대로 수정된 page들을 디스크에 쓰지 않는다면(출력하지 않는다면), UNDO는 메모리 버퍼에 대해서만 이루어지면 되는식으로 간단해 질 수 있습니다.
이는 매력적이지만 매우 큰 크기의 메모리 버퍼가 필요하다는 문제가 있습니다.
수정된 page를 디스크에 쓰는 시점을 기준으로 두개의 정책으로 나눌 수 있습니다.
- STEAL : 수정된 page를 언제든지 디스크에 쓸 수 있는 정책. 필연적으로 UNDO 로깅(후술)과 복구를 수반합니다. 거의 모든 DMBS가 채택하는 버퍼 관리 정책입니다.
- ¬STEAL : 수정된 page들을 최소한 트랜잭션 종료 시점(EOT)까지는 버퍼에 유지하는 정책.
3.2. REDO
이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업을 REDO복구라고 합니다.(UNDO와 반대되는 개념)
REDO복구역시 버퍼 관리 정책에 영향을 받습니다. 트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 page들을 디스크에도 쓸 것인가 여부로 두가지 정책이 나뉩니다.
- FORCE : 수정했던 모든 page를 트랜잭션 커밋 시점에 디스크에 반영하는 정책.
- ¬FORCE : 수정했던 page를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책(로그 레코드로 기록). 디스크의 DB에 반영되지 않을 수 있기 때문에 반드시 REDO 복구가 필요하게됩니다. 거의 모든 DBMS가 채택하는 정책입니다.
4. log
로그는 DB의 모든 갱신 작업을 기록합니다. 대부분의 DBMS는 성능 상의 이유로 하나의 로그를 유지합니다.
로그는 덧붙이는(append)방식으로 기록되며, 각 로그 레코드는 고유의 식별자(Log Sequence Number/Addtress)를 가집니다.
로그 데이터는 물리적/논리적 로깅으로 분류할 수 있습니다.
DBMS제품들은 적절하게 로깅 방법을 섞어서 사용하고 있습니다.
로그를 통한 복구는 idempotent(멱등성)을 지녀야 합니다. 여러 번 수행하더라도 한 번 수행한 결과와 같아야한다는 것을 의미합니다.
4.1. 물리적인 상태 로깅
DBMS에서 가장 널리 쓰이는 기본적인 로깅 방법입니다. 로그 레코드는 갱신 이전, 이후 이미지를 모두 가지고 있으며,
UNDO복구 때는 이전 이미지로 현재 이미지를 대체하며, REDO복구 때는 이후 이미지를 반영하는 방식으로 복구가 이루어집니다.
예를 들어, UPDATE문장에 대한 로깅은 수정 전 레코드 이미지와 수정 후 레코드 이미지를 모두 기록하고 필요시에 이미지를 대체합니다.
물리적 상태 로깅은 page수준(index나 데이터 파일의 헤더 page변경 로깅)에서 이루어지기도하고, 레코드 수준에서 이루어지기도 합니다.
4.2. 물리적인 전이 로깅
이 방법은 XOR 차이점을 기록하는 방식으로 이루어집니다. 복구 시점에서 로그 레코드에 기록된 xor 이미지와 레코드 이미지를 이용하여 복구를 수행합니다.
4.3. 논리적인 전이 로깅
이 방법은 로그 레코드의 크기를 크게 줄여주고 물리적으로 복구하기 쉽지 않은 자료 구조에 대한 로깅을 쉽게 해주는 장점이 있습니다.
REDO를 할 때는 로그 레코드에 기록된 오퍼레이션(DML,DDL)을 재수행하고, UNDO를 할 때는 역 오퍼레이션을 수행합니다.
4.4. 로그는 어떻게 쓸까?
- 해당 update가 DB에 써지기 전에 먼저 관련된 UDNO정보가 로그에 써져야 합니다.(Write Ahead Logging)
- 트랜잭션이 정상적으로 종료 처리되기 위해서는 먼저 REDO정보가 로그에 써져야합니다.
DBMS는 로그 레코드를 위한 로그 버퍼를 유지합니다. 성능을 위해서 로그 버퍼에 로그 레코드를 모았다가 블록 단위로 로그 파일에 출력합니다.
댓글남기기