[DB] Transaction processing

Transaction Concepts

Concurrent Executions

Transaction Schedule

Serializability

Recoverability

 

Single-User vs Multiuser Systems

교대 수행 : interleaved concurrency

 

Transaction : an executing program that forms a logical unit of db processing

Begin transaction - end transaction;

includes DB access operations

read-only / read-write transaction

 

read-item(X) : 디스크블록 주소찾기-버퍼에 복사-프로그램 변수로 복사

write-item(X) : 디스크 주소찾기-버퍼에 복사-수정한 프로그램 변수를 다시 버퍼에 복사-디스크에 저장

read-set : 읽은거 집합 {X, Y, …}

write-set : 쓴거 집합

 

💡 Why concurrency control is needed (문제들)

1. Lost update : 같은 변수에 대해 여러번 write해서 덮어쓰기됨
2. Dirty Read(Temporary update) : cascading rollback : 커밋하지않은 수정사항을 읽음
3. Incorrect summary(Inconsistency) : 합계를 구하는 도중에 내부값이 변경됨
4. Unrepeatable read : 두개의 read 사이에 다른 T’가 값을 변경시켜서 두번의 read 값이 다름

 

💡 Why Recovery is needed

• committed : DB에 영구기록시킴
• aborted : 해당 트랜젝션이 다른 T나 DB에 영향을 끼치지 않게 함

if) 트랜젝션 실패 시 모두 실행취소 → all or nothing

 

 

Transaction states and additional operations

The system log

log(DBMS journal) : 모든 트랜젝션 연산을 추적하기 위해

log records

1. [start_transaction, T]
2. [write_item, T, X, old_value, new_value]
3. [read_item, T, X]
4. [commit, T]
5. [abort, T]

< Desirable Properties of Transactions : 트랜젝션이 데이터 무결성을 보장하기 위해 가져야할 특징 >

ACID : 원자성, 일관성, 고립성, 지속성

1. Atomicity : all or nothing
2. Consistency preservation : transformations preserve DB consistency
3. Isolation : 다른거의 영향을 받으면 안됨, 동시성 제어
4. Durability / permanency : 한번 커밋되면 영구저장

Schedules (Histories) of Transactions

• 스케줄 S는 트랜젝션의 순서이다

Conflicting Operations in Schedule : 충돌

1. belong to different transactions
2. access the same DB item
3. one of the 2 operations is a write operation : 쓰기 연산이 있을때만 충돌 발생

Characterizing schedules based on recoverability : 복구가능성 기반 스케줄 특성화

• Recoverable : durability (내구성)
• Nonrecoverable : commt된 트랜젝션이 복구 시 취소되어야할때

(T’가 쓴 데이터를 읽은 T가 먼저 커밋되면 안됨!)

Characterizing schedules based on Serializability : 직렬화가능성

• 직렬화가능한 스케줄 : 동시 실행시 항상 올바른 것으로 간주됨
  • Serial schedules : if no interleaving is permitted → correct
  • Nonserial : if interleavign is allowed → correct or wrong

인터리빙 시에도 결과가 같을 때

(병렬시행 결과가 따로 T1→T2 혹은 T2→T1 직렬시행했을떄의 결과와 같을때)

이 스케줄이 직렬화가능하다 = 이 스케줄이 correct 하다

Equivalence of schedules

result equivalence : 어떤 값이 들어와도 그 결과가 같을때 두 스케줄은 결과 동등

동등성 : 트랜젝션 작업유형에 따른 가정 없음. 같은 순서로 적용되어야함

• Conflict Equivalence : 충돌 동등성
• View Equivalence : 뷰 동등성

Conflict Equivalence : 충돌 동등성

충돌하는 두 작업의 순서가 두 스케줄에서 동일함

 

Conflict Serializability : 충돌 직렬화가능성

: 어떤 스케줄 S가 serial 스케줄 S’와 conflict equivalent하면 S는 conflict serializable하다

Testing for conflict serializability : Precedence graph (우선순위 그래프)

Testing for Conflict Serializability

• no cycles
• finding a cycle from a graph is harder : 사이클 찾기 어려움
• many possible linear orders : 선형순서가 너무 많음
• 그래서 대부분의 상용 DBMS는 모든 일정의 직렬화를 보장하는 프로토콜을 지키도록 설계

→ Concurrency Control protocol

1. Locking
2. TimeStamps
3. Multiversion CC protocols
4. Optimistic protocols

View Equivalence : 뷰 동등성 → 충돌 동등성보다 더 general

• read 연산만 고려함
• 같은 값을 read하면 동등하다고 한다

1. S와 S’에 동일한 거래집합이 참여
2. 어떤 읽기연산도 서로 동일한 값을 읽음
3. 한 값에 대한 마지막 쓰기연산이 동일해야함

View Equivalance and View Serializability

the read operations can see the same ciew in both schedules

DB state should be the same at the end of both schedules

뷰 동등성이 충돌 동등성보다 덜 제한적임.

→ 한 스케줄 S가 시리얼 스케줄 S’와 뷰 동등하다면 View serializable 스케줄이다.

충돌없는 작업은 재정렬 가능

Constrained Write Assumption : 제한된 쓰기

View 직렬가능성 vs 충돌 직렬가능성

제한된 쓰기 → view = conflict

제한되지 않은 쓰기(blind write 존재) → view ≥ conflict

Testing for View serializability → NP-complete problem

Transaction Support in sql

• a transaction begins implicitly : no Begin_Transaction statement (암묵적 실행)
• ends by Commit / Rollback
• 모든 트랜젝션은
  • SET TRANSACTION
  • access mode, diagnostic area size, the isolation level

SET TRRANSACTION statemetn in sql

• access mode : READ ONLY or READ WRITE
• diagnostic area size : diagnostic size n
• Isolation level

level of consistency

1. Read uncommitted
2. Read committed
3. Repeatable read
4. Serializable