[DB] CH14. 트랜잭션(Transaction)

 

트랜잭션이란?

unit of program execution that accesses and possibly updates various data items

트랜잭션에 관한 중요한 이슈 2가지

• HW나 SW failures에 대한 대응
• multiple transation들의 concurrent execution 문제

DB 시스템이 data integrity를 보장하기 위해 트랜잭션이 갖추어야 할 조건 4가지(ACID)

• Atomicity : 한 트랙잭션 내의 모든 operation들의 결과는 모두 반영되거나 모두 반영되지 않거나 둘 중 하나(system failure 등으로 인한 partial execution은 반영되면 X)
• Consistency : 트랜잭션이 성공적으로 완료되면 DB 데이터의 일관성이 유지되어야 함
• Isolation : multiple 트랜잭션이 concurrent하게 동작 중일 때, 한 트랜잭션의 중간 계산 값(intermediate result)은 다른 트랜잭션이 읽지 못하도록 해야 함(Isolation은 running transations serially로 보장 가능 BUT concurrent execution으로 얻을 수 있는 이점을 얻지 못함)
• Durability : 성공적으로 수행이 완료된 트랜잭션의 결과는 반드시 반영되어야 함(system failure에도 불구하고)

Concurrent execution의 이점

• 프로세서와 디스크 utilization(활용도) 증가
• average response time이 줄어듬

스케쥴(Schedule)이란?

concurrent transation들이 수행되는 instruction의 sequence

cf.) instruction은 transation 안의 operation이다.

스케쥴이 "serializable"하다는 것은?

serial schedule과 equivalent하다는 뜻!

• conflict serializability
• view serializability

Conflicting instruction

instruction I1, I2가 각각 트랜잭션 T1, T2의 instruction이라 할 때, item Q에 대해 다음 중 하나에 해당되면 conflict

1. I1 = read(Q), I2 = write(Q)
2. I1 = write(Q), I2 = read(Q)
3. I1 = write(Q), I2 = write(Q)

참고로, I1 = read(Q), I2 = read(Q)는 conflict하지 않다!

Conflict equivalent & Conflict serializability

스케쥴 S의 non-conflicting instruction을 swap하여 스케쥴 S'으로 만들 수 있으면 S와 S'은 conflict equivalent

특별히, 스케쥴 S가 serial schedule과 conflict equivalent하면 S는 conflict serializable하다고 한다.

스케쥴3은 conflict serializable하다

View equivalent & View serializability

스케쥴 S와 S'이 아래의 세 조건을 모두 만족하면 view equivalent하다.

1. initial read : 만약 S의 트랜잭션 T1이 Q의 initial value를 read했다면, S'에서도 T1은 Q의 initial value를 read해야 함
2. same read : 만약 S의 T1이 T2로부터 생성된 Q를 read했다면, S'에서도 T1은 T2로부터 생성된 Q값을 읽어야 함
3. final write : 만약 S의 T1이 final write(Q)를 했다면 S'에서도 T1이 final write(Q)를 해야 함

특별히, S가 serial schedule과 view equivalent하면 S는 view serializable하다고 한다.

Conlict serializable vs. View serializable

모든 conflict serializable한 스케쥴은 view serializable하다(즉, conflict는 view의 부분집합)

view serializable하지만 conflict serializable하지 않은 스케쥴 예

위처럼 view serializable하지만 conflict serializable하지 않은 스케쥴은 모두 blind write를 갖고 있다.(T28의 write(Q)처럼 T29의 write(Q)에 의해 overwritten되는 경우)

Recoverable schedule

트랜잭션 T1이 T2가 write한 item을 읽는다면 T2에서의 commit operation이 T1에서의 commit operation보다 먼저 실행되어야 함

아래의 스케쥴은 recoverable하지 않다. 왜냐하면 T8의 commit이 T9의 commit보다 먼저 나오지 않았기 때문이다. 이러한 경우 문제가 발생할 수 있다. 만약 T8이 문제가 발생해 abort되어야 한다면 T9은 abort되기 이전의 데이터를 읽고 이미 commit을 해버려서 data inconsistency가 발생한다.

Cascading rollback

하나의 트랜잭션의 failure가 여러 트랜잭션의 rollback을 줄줄이 야기하는 것(series of transaction rollback)

아래 예시에서 T10이 fail하면 T11,T12 모두 rollback되어야 한다. 이는 이미 수행한 많은 작업의 취소로 이어진다.

이처럼 degree of concurrency와 cascadeless는 trade-off 관계에 있다.

cascading rollback

Cascadeless schedule

cascading rollback이 없는 스케쥴을 말한다. 만약 T1이 T2가 write(Q)한 Q를 읽는다면 T2의 commit operation이 T1의 commit operation보다 먼저 나오게 하면 된다.

참고로, 모든 cascadeless schedule은 recoverable하다

Concurrency control의 목적

concurrent한 execution의 serializability를 보장하는 protocol을 만드는 것

스케쥴은 conflict/view serializable 중 하나를 만족하며 recoverable해야 한다. 그리고 될 수 있으면 cascadeless라면 좋다.