12. Transaction Processing

Transaction

- 데이터베이스 처리(process)의 논리적 연산 

- Transaction은 하나 이상의 DB접근 연산자를 포함함

- read-only, read-write transaction으로 나뉜다.

Transaction의 성질

Atomicity(원자성) : 실패 아니면, 성공만 있고, 반만 성공하는 경우는 없다.

은행을 예로 들면, Transaction에 실패해 예금 됐단 기록은 남았는데, 돈이 보내지는 경우가 생기면 안 되므로,

돈이 보내지지 않았다면, 예금 됐단 기록도 없던 걸로 한다.

 

Consistency(일관성) : 성공적으로 수행된 Transaction들만 DB에 저장되어야 한다.

 

Isolation(고립성) : 여러 Transaction이 동시에 수행되더라도, 다른 Transaction에 영향을 주어선 안 된다.

 

Durability(지속성) : Transaction이 완료돼, commit이 됐다면,

해당 Transaction에 대한 변경은 어떠한 일이 생기더라도 보존돼야 한다.

 

이를 줄여서 ACID라고 한다.

 

 

 

 

Concurrency Control(동시성 제어)

동시성으로 인한 문제들

1. Lost update (write 연산 무시됨)

2. Temporary update : Cascading rollback (Dirty read)

-> 데이터 틀림

3. Incorrect Summary (Inconsistency)

4. Unrepeatable read

 

Lost update

X = 80, Y = 80, N = 5, M = 4라고 하자.

lost update

원래라면 X는 79가 나와야 하지만,

T1에서 X를 저장하기 전에, T2에서 X를 불러왔고,

T1에서 X 저장이 끝난 뒤, 또 T2에서 X를 저장했기 때문에,

T1의 write_item(X) 는 lost update가 되버린다.

 

temporary update problem

X = 80, Y = 80, N = 5, M = 4

temporary update problem

이 Transaction은 큰 문제가 없지만,

T2에서 연산을 마친 뒤, T1에서 취소가 일어났다.

이렇게 되면, T1의 X는 75가 되고, T2의 X는 79가 되버린다.

만약 이렇게 한 쪽에서, 취소가 발생하면,

관련된 item을 사용한 다른 transaction도 취소를 해줘야 한다.

 

Inconsistency 문제

한 Transaction실행 중에, 다른 Transaction이 개입해, 값을 바꿔버리는 문제이다.

 

T2를 처리하는 도중에, T1이 X의 값을 바꿔버렸고,

T2은 그 바뀐 값을 가지고 계속 연산을 수행해, 일관성이 깨지는 문제다.

 

Inconsistency problem

Unrepeatable read

Transaction T가 어떤 데이터를 2번 읽어야 하는 일이 있을 때,

2번째로 읽을 때 값이 틀리는 현상.

 

실생활의 예를 들면, 빈 좌석을 예약하려 했는데,

결제 준비가 끝나니 누군가가 그 자리를 먼저 예약해버린 상황

요즘엔 이런 문제를 locking 형식으로 해결하는 거 같다.

 

 

Recovery

사용자의 철회 요청이나, Transaction 수행 중 오류 등으로 인해, 복구 작업

 

committed : Transaction 이 정상적으로 수행되, 디스크에 영구 저장

-> 커밋된 데이터를 바꿔야 하는 건(redo)

aborted : Transaction 처리 중 오류가 발생해, 수행하기 전 상태로 돌림(undo)

 

Recoverable Schedule

이론적으로 durability를 충족시키는 transaction들

commit 순서만 바꿔주면 된다.

 

Nonrecoverable Schedule

복구 중에 커밋된 Transaction을 롤백해야 하는 작업

 

예시

다음 Transaction에선 T1에서 write한 걸 commit 하기 전에,

T2에서 다시 write를 하고, commit 을 하면서, lost update 가 발생한 상황이다.

T1의 w1(X)가 lost update

 

이 땐 단순히, 커밋 위치만 바꿔주면 해결되기에, 이 스케줄은 recoverable 하다.

 

 

다음 스케줄을 보자.

T1이 쓴 걸, T2가 가져다 쓰기 때문에 문제가 없는 Transaction이다.

하지만

 

T2가 커밋 된 뒤, T1에서 abort가 일어났기 때문에, T2의 커밋 내용을 롤백해야 한다.

롤백을 해야하는 상황이기 때문에 이 스케줄은 nonrecoverable하다.

 

 

다음 스케줄을 보자.

이전 스케줄하고 비슷한 구조이고, 커밋도 제때 제때 됐기에 이 스케줄은 recoverable하다.

 

 

Cascading Rollback

Transaction끼리 커밋되지 않은 데이터를 받아 쓰다가,

한쪽에서 abort가 발생하면, 다른 Transactioin들도 abort를 해줘야 하는 상황

 

T1에서 쓴 값을, T2가 받아 쓰고, 이걸 T3이 받아 쓰는 단계별 Transaction에서,

T1에서 abort가 일어나면, 이 transaction들을 다 롤백 해야 한다.

 

그렇기에 Cascade Schedule은 다른 Transaction이 read하기 전에, commit을 해줘야 한다.

즉, cascade schedule은 커밋만 봐주면 되니, recorable하다.

 

https://www.geeksforgeeks.org/cascadeless-in-dbms/

 

 

 

recoverable과 nonrecoverable 다이어그램으로 표현한 것이다.