[DB] 데이터베이스 복구, ACID

Transaction 이란?

---

Transaction 은 하나의 논리적 작업 단위를 구성하는 연산들의 집합을 뜻한다.

the unit of work

the unit of recovery

the unit of concurrency

 라고도 불려진다.

Transaction 의 4가지 특징(ACID)

---

Atomicity(원자성) : 이체 과정 중에 트랜잭션이 실패하게 되어 예금이 사라지는 경우가 발생해서는 안 되기 때문에 DBMS는 완료되지 않은 트랜잭션의 중간 상태를 데이터베이스에 반영해서는 안 된다. 즉, 트랜잭션의 모든 연산들이 정상적으로 수행 완료되거나 아니면 전혀 어떠한 연산도 수행되지 않은 상태를 보장해야 한다. atomicity는 쉽게 'all or nothing' 특성으로 설명된다. COMMIT , ROLLBACK 은 원자성을 제공해주는 기능이다.

Consistency(일관성) : 고립된 트랜잭션의 수행이 데이터베이스의 일관성을 보존해야 한다. 즉, 성공적으로 수행된 트랜잭션은 정당한 데이터들만을 데이터베이스에 반영해야 한다. 트랜잭션의 수행을 데이터베이스 상태 간의 전이(transition)로 봤을 때, 트랜잭션 수행 전후의 데이터베이스 상태는 각각 일관성이 보장되는 서로 다른 상태가 된다. 트랜잭션 수행이 보존해야 할 일관성은 기본 키, 외래 키 제약과 같은 명시적인 무결성 제약 조건들뿐만 아니라, 자금 이체 예에서 두 계좌 잔고의 합은 이체 전후가 같아야 한다는 사항과 같은 비명시적인 일관성 조건들도 있다.

Isolation(독립성) : 여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션의 수행에 영향을 받지 않고 독립적으로 수행되어야 한다. 즉, 한 트랜잭션의 중간 결과가 다른 트랜잭션에게는 숨겨져야 한다는 의미인데, 이러한 isolation 성질이 보장되지 않으면 트랜잭션이 원래 상태로 되돌아갈 수 없게 된다. Isolation 성질을 보장할 수 있는 가장 쉬운 방법은 모든 트랜잭션을 순차적으로 수행하는 것이다. 하지만 병렬적 수행의 장점을 얻기 위해서 DBMS는 병렬적으로 수행하면서도 일렬(serial) 수행과 같은 결과를 보장할 수 있는 방식을 제공하고 있다.

Durability(지속성) : 트랜잭션이 성공적으로 완료되어 커밋되고 나면, 해당 트랜잭션에 의한 모든 변경은 향후에 어떤 소프트웨어나 하드웨어 장애가 발생되더라도 보존되어야 한다. 

데이터베이스 복구 기법

---

Commit 과 Rollback 기능이 있다.

Commit : Transaction 의 성공적인 종료 시점 , Commit 이 되면 DB 에 변경사항을 저장한다.

Rollback : 가장 최근의 Checkpoint 지점으로 되돌아감.(undone 이라고도 부른다.)

Transaction 이 성공적인 종료인지 system failure 에 의해 비정상적으로 중단되는 경우인지를 구분하기 위해 redo, undo 라는 복구 기법이 있다.

redo 는 시스템이 충돌하기 전 정상적으로 transaction 이 종료 된 transaction 들의 집합이고

undo 는 시스템이 충돌함으로 인해 비정상적으로 종료된 transaction 들의 집합이다.

만약 Commit 을 하고 그 내용들을 DB 에 쓰기(update) 전에 전원이 나간다거나 DB 가 강제종료 되는 경우에는 

어떻게 문제를 해결할 것인가? 이런 의문이 생길 수가 있다. 

이런 시스템의 오류가 발생했을 때 의 대처를 위해서 Write-Ahead Protocol 을 사용한다. Write-Ahead Protocol 은

해당 update가 DB에 써지기 전에 먼저 관련된 UNDO 정보가 로그에 써져야 한다. 어떤 경우에도 UNDO 복구가 되기 위해서는 반드시 준수되어야 한다. 이렇게 함으로서 DB와의 연결이 강제적으로 끊긴 경우라도 로그를 통해서 다시 DB에 update 시킬 수 있다.

보통의 순서가 1.insert, 2.update, 3.commit, 4.물리적으로 DB에 쓰여짐 순서라 하면 Write-Ahead Protocol 은 3번 과정이 완료되기

 전에 발생한다고 볼 수 있다.(3.5 라고 생각하면 될 듯)

redo, undo 를 확인하기 위해서 DBMS 에서는 checkpoint 를 사용한다.

특정 시간을 checkpoint 시점으로 잡으면 그 시간에 진행중인 transaction 들을 log 에 쓰는 방식이다. system failure 가 발생하면 가장

최근에 check point 지점으로 이동하게 된다.

tc 라는 time 을 checkpoint 시점으로 사용된 예제이다. T1의 경우 tc 이전에 정상적으로 종료가 되서 아무 상관이 없다.

tc 에서 진행중인 transaction 은 T2, T3 이므로  이 2개를 log에 기록한다.

계속 진행되다보면 T2, T4는 종료가 되고(commit)  tf 에 system failure 가 발생하는데 이 때 종료되지 못한 T3, T5 는 정상적인 commit이 이루어지지 않은 상태이다. system failure 가 발생했기 때문에 가장 최근 checkpoint 인 tc 로 이동하게 된다.

tc에서부터 log 를 다시 읽어보면 T2, T4 는 commit 이 되었기 때문에 redo 이고

T3, T5 는 undo 가 된다.