1. 트랜잭션 이론 및 회복가능(Recoverable)

1.1 트랜잭션 개념

트랜잭션(Transaction): 하나의 논리적 작업을 수행하는 DB 연산의 순서로, 여러개의 작업을 하나로 묶은 실행 유닛.

 

트랜잭션 관리

1) HW, SW, Transaction 등 다양한 시스템의 장애를 극복하는 회복 기능(Recoverability)

2) 다수개의 트랜잭션을 동시에 수행 시 발생하는 문제점을 해결하는 동시성 제어 기능(Concurrent Execution)

-> 이 두가지 이슈의 관점에서 접근한다.

 

트랜잭션의 ACID 성질

Atomicity(원자성)

: all-or-nothing으로, 트랜잭션을 구성하는 연산은 모두 수행되거나 어느 연산도 수행되지 않아야 한다.(연산의 일부만 수행되는 것은 불가능)

예시)

계좌이체를 할 때

1. A 계좌에서 10만원을 출금을 한다. 2. B계좌에 10만원을 입금을 한다.

이 두 단계를 거쳐야 함.

이때, A계좌에서만 출금이 되고 B계좌에는 입금이 안되는 경우는 없도록 해야함.

Consistency(일치성)

: 단일 트랜잭션의 수행은 데이터 무결성을 유지한다.

예시)

'모든 상품은 가격이 있어야 한다'는 DB제약이 있을 때

1. 가격이 없는 상품을 등록하는 쿼리

2. 기존 상품들에서 이름을 삭제하는 쿼리

위와 같은 쿼리들은 일관성을 위반하기에 사용이 불가함.

Isolation(고립성)

: 다수 트랜잭션이 동시 수행 중이더라도 사용자에게는 본인 트랜잭션만이 홀로 수행되고 있는 느낌을 준다.

예시)

T1이 중간에 값을 2번 변경하는 작업이 있음. 이때 중간에 한번만 변경된 상태에서 T2가 그 값을 읽어 올 수 없음. 즉, 각 트랜잭션 작업은  순서대로 이뤄짐으로서 서로의 트랙잭션 수행이 독립적이도록 함.

Durability(지속성)

: 완료된 트랜잭션의 결과는 후에 시스템 장애가 발생하여도 DB 상태에 반영되어야 한다.

예시)

고객이 은행에 입금했는데 다음날 디스크 장애로 인해 은행에서 입금 사실을 고객에게 확인해주지 못하는 문제는 발생할 수가 없음.

 

-> 이런 ACID성질은 사용자가 트랜잭션을 선언하면 DBS에서 제공해야 함.

 

트랜잭션 상태

Active

: 초기 상태로, 트랜잭션이 수행 중인 상태

 

Partially committed

: 트랜잭션의 모든 문장이 실행된 상태

Aborted

: 트랜잭션이 완료(Committed)되기 전에 시스템 고장, 트랜잭션 연산 오류 등으로 연산 수행을 하지 못하는 상황이 발생한 경우

Committed

: 관련로그를 안전 장소에 기록하는 등 트랜잭션 완료를 위한 조치가 성공적으로 수행된 경우. 이때 트랜잭션 초기 시작 상태로 DB를 원상 복귀해야 함. 

트랜잭션 상태의 과정

Concurrent Executions(동시 실행)

: 시스템이 다수의 트랜잭션을 동시에 수행하는 것.

-> 장점: 1. 자원 활용성 증가, 2. 트랜잭션의 평균 응답 시간 감소

(OS에서의 개별 Process 동시성 수행과 비슷한 장점)

 

*Concurrency Control(동시성 제어): 다수의 트랜잭션을 동시적으로 수행 시 DBS에서 이를 제어하는 기술, isolation(고립성)을 달성할 수 있음.

---

1.2 직렬가능(serializability)

: 트랜잭션을 순차적으로 수행하는 방법으로, 트랜잭션의 일치성(Consistency) 성질에 따라 DB가 항상 일치하는 상태로 유지되므로 항상 올바르다.

But!! 현실적으로는 운영이 불가능하기에 올바른 트랜잭션의 실행인지 판단의 기준으로 사용함.

 

종류는 2가지!

1. Conflict serializable

2. View serializable

 

그렇다면 Nonserializable Execution하면 무엇이 문제일까??

Concurrency anolmalies(트랜잭션을 올바르게 수행하지 못하는 경우 발생하는 현상)

1. dirty read(오손 읽기)

: 완료되지 않은 값(uncommitted value, dirty value)을 읽는 연산

T2의 경우 dirty data이다.

2. lost update(갱신 손실)

: T2가 쓴 값을 T1이 덮어쓰는 현상으로, T2의 효과는 DB에서 사라짐.

T2의 업데이트 기능이 사라진다.

3. unrepeatable read(반복불가 읽기)

: T1이 처음에 읽는 A 값과 후에 읽은 A값이 차이가 생겨 T1 관점에서 A값을 읽을 때마다 다른 값이 나오는 현상.

고립성 보장을 위해 데이터 값을 읽고 시간이 지난 후 다시 읽어도 그 값이 그대로 똑같이 나와야 함.-> 이럴 경우를 repeatable read라고 함.

Schedules

: 동시적으로 수행되는 다수의 트랜잭션에 속하는 연산들이 수행된 시간적 순서.

1. 동시적으로 수행된 트랜잭션의 모든 연산이 스케줄에 나와 있어야 함.

2. 스케줄에 있는 특정 트랜잭션에 속하는 연산 순서는 해당 트랜잭션 내의 연산 순서와 동일해야 함.

3. 트랜잭션의 마지막 문장은 commit 혹은 abort이고 이를 시스템에서 명시적/암시적으로 수행이 가능함.

 

직렬 스케쥴 VS 비직렬 스케쥴

- 직렬 스케쥴: 트랜잭션의 연산을 모두 순차적으로 실행하는 유형으로 하나의 트랜잭션이 실행되면 해당 트랜잭션이 완료되어야 다른 트랜잭션이 실행될 수 있다.

- 비직렬 스케쥴: 트랜잭션의 직렬 수행 순서와 상관없이 병행 수행하는 스케쥴로 하나의 트랜잭션이 진행 중인 상황에서 다른 트랜잭션이 실행될 수 있다.

 

'Serial Schedule'(직렬 스케쥴)

'Nonserial Schedule'(비직렬 스케쥴)

그렇다면 직렬가능 스케쥴(Serializable Schedule)은 뭘까...?

- 직렬가능 스케쥴: 직렬수행 스케쥴의 결과와 동일한 스케쥴

-> 만약 n가지의 트랜잭션이 있다면 총 n!가지의 직렬 스케쥴이 가능하고 이때 직렬 가능 스케쥴은 n!가지 중 적어도 하나의 직렬 스케쥴과 동일한 결과를 가져야 함.

 

스케쥴 결과의 동일함을 정의하는 방식엔 2가지가 있다.

1. 충돌 직렬가능 스케쥴(Conflict serializability) 2. 뷰 직렬가능 스케쥴(View serializability)

 

충돌 직렬가능 스케쥴

충돌 연산: 동일한 데이터에 대한 두개의 연산 중에서 최소한 한개의 연산이 write 연산이면 두 연산은 충돌한다. 하지만 서로 다른 데이터를 가지고 read, write하는 경우엔 충돌하지 않는다. 

충돌 직렬가능 스케쥴: 스케쥴 중 비충돌 연산을 서로 바꾸어 직렬 스케쥴이 되는 것

만약 스케쥴 S의 비충돌 연산의 순서를 바꾸어 스케쥴 S'이 된다면, S와 S'은 conflict equivalent하다고 함.

이때 스케쥴 S를 '충돌 직렬가능 스케쥴'이라고 한다.

충돌 직렬가능 스케쥴5 예시

뷰 직렬가능 스케쥴

뷰 직렬가능 스케쥴: 스케쥴 S에 속한 각 트랜잭션의 읽기 연산에 대하여 S' 스케쥴에서 동일한 값을 읽고, 스케쥴 S의 마지막 쓰기 연산이 S' 스케쥴의 마지막 쓰기 연산과 동일할 때, 스케쥴 S'은 뷰 직렬가능 스케쥴이라고 한다.

스케쥴 8은 <T5, T6, T7>과 view eqivalent하다.

충돌 직렬가능하지 않은 모든 뷰 직렬가능 스케쥴들은 blind writes(트랜잭션 내에서 해당 데이터를 선 read 없이 write하는 것. ex) 위 그림의 T6, T7)를 가지고 있다.

충돌 직렬가능(Conflict Serializable) VS 뷰 직렬가능(View Serializable)

충돌 직렬가능 스케쥴이면 모두 뷰 직렬가능 스케쥴이다.

 하지만...! 충돌 직렬가능 스케쥴과 뷰 직렬가능 스케쥴 외에도 다른 직렬가능 스케쥴이 존재한다.

T1의 Read(B)와 T2의 Write(B)는 swap할 수 없기에&nbsp; 충돌 직렬가능X, T1의 Read(B)는 T2의 Write(B)한 값을 가져와야 하므로 뷰 직렬가능X. 하지만 위 스케쥴은 <T1,T2>와 동일한 결과를 보이므로 직렬가능 스케쥴이다.

=> 트랜잭션 내에서 수행하는 연산을 사전에 DBMS에서 알 수 없기에 위와 같은 스케쥴에 대하여 직렬가능 스케쥴임을 분석하는 건 어렵다.

---

1.3 직렬가능 시험(Testing for Serializability)

충돌 직렬가능 시험

위처럼 선행 그래프를 그렸을 때 사이클이 존재하면 충돌 직렬가능 스케쥴이 아니다.

위와 같이 사이클이 존재하지 않는다면 충돌 직렬가능 스케쥴이다.

 

이렇게 사이클 여부만 확인하면 충돌 직렬가능 여부를 테스트할 수 있기에 매우 간단하고 저렴한 연산이다.(n^2 or n+e 시간이 걸림)

뷰 직렬가능 시험

 NP-complete 문제 때문에 간단한 알고리즘을 구하는 것이 매우 어려움.

∴ 충돌 직렬가능 여부를 확인 후 blind writes의 존재 여부를 확인하여 찾는다.

 

---

1.4 회복가능(Recoverability)

스케쥴을 만들 때 고려해야 하는 사항은 isolation(고립성)을 위한 직렬가능 문제 외에도 시스템 고장 시(Atomicity, Durability) 회복 가능 여부도 있음.

 

회복 가능 스케쥴에서는 데이터를 읽은 트랜잭션은 그 데이터를 쓴 트랜잭션 이후에 완료하여야 한다.

 

연쇄 철회(Cascading Rollbacks)

:트랜잭션 하나의 철회가 다른 트랜잭션 철회를 유도하는 것으로, 이를 방지하기 위해서는 기본적으로 완료된 읽기(Committed read)만을 허용하여야 한다.

 

dirty read: 읽는 값이 committed된 값이 아닌 것.

 

연쇄 철회가 필요없는 스케쥴(Cascadeless Schedules, ACA(avoid cascading aborts) Schedules)

1. 트랜잭션들은 다른 트랜잭션 or 자기 자신의 트랜잭션에서의 committed 된 데이터만을 읽어야 한다.

2. 모든 Cascadeless Schedule은 회복가능하다.

 

스케쥴의 관계

RC: recoverable

ACA: avoids cascading aborts

ST: strict

SR: conflict serializable

 

제한적인 스케쥴(strict schedule)은 쓰기 연산을 한 트랜잭션이 committed/aborted 될 때까지 해당 데이터를 다른 트랜잭션이 읽거나 쓸 수 없다.

- 조건:

wj[x] < oi[x](j가 x를 write하는 연산이 i가 x를 operation(read or write)하는 연산보다 전에 일어나야 한다.)

즉, aj < oi[x] or cj < oi[x] (aj, cj는 각각 abort, commit을 의미)

 

동시성 제어(Concurrency Control)

: 어떤 규약을 준수하면서 트랜잭션을 수행하여 원하는 스케쥴이 나오게 하는 것.

 

보통 우리가 원하는 스케쥴은 직렬가능 스케쥴이면서 동시에 회복가능 or 연쇄철회를 방지하는 스케쥴이다.

트랜잭션을 수행한 후에 스케쥴을 판별하는 것은 트랜잭션이 늦 동시성 제어 규약을 준수하면서 트랜잭션을 수행해야 한다.

 

Concurrency Control Protocol은 serializability하도록 만들어주는 것이다.

 

 

다음 장에서는 동시성 제어에 관해서 자세히 알아본다.