Transaction

Transaction
더 이상 나눌 수 없는 작업, correctness와 consistency를 보장하기 위해 데이터베이스 처리 전체를 완료해야 하는 작업의 논리적인 단위

Scenario: A가 B에게 돈을 송금하는 case
1. A의 계좌를 load
2. B의 계좌를 load
3. 잔고 확인
4. A로부터 예금을 인출
5. B에게 예금 입금
6. COMMIT (부분 완료)
7. A의 계좌 기록
8. B의 계좌 기록
(log buffer에 쓰고 이를 DB에 한 번에 update (WAL: Write Ahead Logging))

Terminology

transaction의 종류

• Read-only: database를 update하지 않는 transaction으로 lock이 필요 없다.
• Read-write: database를 update하는 transaction

transaction 처리 개념의 주 용어

• Data item: 저장하는 매체 단위를 의미, record(tuple), block, field value, file 또는 database 전체가 될 수도 있다.
• Granularity: data item의 size
  • 이 값에 따라 lock의 범위가 달라짐
  • transaction 처리의 concurrency를 결정

TRANSACTION AND SYSTEM CONCEPTS, AND DESIRABLE PROPERTIES OF TRANSACTIONS

Transaction States

트랜잭션 상태

• BEGIN_TRANSACTION: transaction execution의 beginning
• READ or WRITE: database items에 read or write operation 수행
• END_TRANSACTION: transaction execution이 끝났음을 의미
  • transaction의 상태를 체크하기 위해서 commited or aborted가 필요
• COMMIT_TRANSACTION: transaction의 성공적인 종료 신호, 변경이 영구적으로 기록
• ROLL_BACK(or ABORT): transaction이 정상적으로 종료되지 않음 의미, 실행을 취소해야 함 (rollback)

• Partially commited: 사용자에게 더 빠른 response를 주기 위해서
  • DBMS는 각 트랜잭션 단위가 아닌 disk의 변경 사항을 한 번에 반영
  • concurrency control protocols의 일부는 추가적으로 가능한 commit을 확인
  • recovery protocols 일부는 실패사항과 database에 끼치는 영향을 확인
• Failed: checks 중 하나가 실패하거나, transaction이 abort된 경우
  • Partially commited $\rarr$ Abort $\rarr$ Failed 의 대표적인 예: Deadlock

Why Recovery Is Needed? To Handle Failure

Committed:
transaction의 모든 operations이 성공적으로 완료되었고, 해당 영향이 database에 영구적으로 기록된 상태
Aborted:
transaction이 database 또는 다른 어떤 transactions에도 영향을 주지 않은 상태

Failures의 종류

1) computer failure
2) transaction or system error
3) Local error or exception conditions detected by the transaction
4) Concurrency control enforcement
5) Disk failure
6) Physical problems and catastrophe

이들을 복구하기 위해 recovery system 존재

The System Log

시스템 로그
database items의 value에 영향을 끼치는 transaction operations을 추적

• disk에 저장되는 sequential, append-only file
• Log buffer: logs를 기록하기 위해 사용하는 하나 또는 이상의 main memory buffer
  • log entries로 가득차는 경우, disk의 log file 끝에 append

"Log Records"의 종류:
1. [$start\_transaction, T$]
2. [$read\_item, T, X$]: $X$를 read
3. [$write\_item, T, X, old\_value, new\_value$]
4. [$commit, T$]
5. [$abort, T$]
($T$: 자동으로 생성된 고유 트랜잭션 식별자)
system crashes가 발생(inconsistent한 상태)하면, log를 확인하고 ARIES와 같은 recovery technique을 이용하여 consistent한 database로 복구

• UNDO operation: $X$에 $old\_value$를 재저장
  • $WRITE$ operation의 영향을 backward로 되돌림
• REDO operation: $X$에 $new\_value$로 update
  • log에는 update 기록이 남아있지만 failure로 인해 database에는 $new\_value$가 update되지 않은 경우에 수행
  • forward action

Commit Point of Transaction $T$

해당 transaction의 database에 접근하는 모든 operations이 성공적으로 완료되고, log에 모두 기록되었다면, $T$는 commited되었다고 한다.
$\rarr$ [$commit, T$]로 commit record를 log에 write

failure가 발생했을때,

• $T$의 commit record는 있지만, database(disk)에는 반영되지 않은 경우 $\rarr$ REDO their effect
• $start\_transaction$ record는 있지만, commit record가 없는 경우, 즉 commit point까지 도달하지 않은 경우 $\rarr$ UNDO their effect: rollback

"Force-writing": transaction을 commit하기 전에 log buffer를 disk에 flush

ACID Properties of Transaction

transaction이라면 무조건적으로 충족해야 하는 특성
Atomicity: recovery subsystem이 책임

• transaction은 processing의 atomic unit: all or nothing

Consistency: programmer가 책임

• transaction은 consistency을 보존해야 함

Isolation: concurrency control subsystem에 의한 시행

• transaction은 다른 transaction이 없는 것처럼, 방해받지 않고 독립적으로 실행되는 것처럼 보여야 한다.

Durability: recovery subsystem이 책임

• committed transaction에 의해 적용된 변경 사항들은 database에 무조건 저장되어야 한다.

CHARACTERIZING SCHEDULES BASED ON SERIALIZABILITY

Schedules of Transactions

$n$개의 transactions $T_1, T_2, ..., T_n$의 schedule $S$

• transactions의 operations의 순서
• 서로 다른 transactions의 operations는 $S$에서 serial(correctness $\uarr$, 성능 $\darr$)하거나, interleaved(serialize: serial인 것처럼 보임, serial의 단점을 보완)해야 한다.
• Exmaple: "interleaving" two transactions의 Schedule $T_1, T_2$:
  • $S: r_1(X);\,w_2(X);\,w_1(X);\,r_1(Y);\,w_2(X);\,w_1(Y);$
  • non-serial schedule

Serial Schedule

schedule $S$의 모든 transactions $T$의 모든 operations이 다른 operations의 interleaved operations없이 연속적으로 실행되는 경우, 해당 schedule은 serial

• 모든 serial schdule은 CORRECT하지만, non-serial schedule은 CORRECT하지 않기에 생성해서는 안된다.

Serial scheduels의 "Problem"

• operations의 interleaving을 제한함으로써, 동시성을 제한
• 다른 transaction이 수행되기를 기다릴 수 없다. (실사용에서는 적용 불가)

Solution
: serial schedule과 비슷하게 동작하는 schedule을 사용해야 함

Conflicting Operations in a (Nonserial) Schedule

Schedule에 있는 두 transacitons은 아래의 경우, conflict가 발생

• operations이 서로 다른 transactions에 존재 (같은 transaction 내에서는 충돌이라는 개념 X)
• operations가 동일한 item $X$에 접근
• 적어도 하나의 operations은 $write\_item(X)$여야 한다. ($read$ operation끼리는 충돌 X)

또한, 두 operations의 순서 변경이 서로 다른 결과를 초래한다면 이는 conflict

Confilct의 두 가지 종류
i) read-write
ii) write-write
E.g., $S: r_1(X);\,w_2(X); \rarr$ read-write conflict
$S: w_1(X);\,r_1(Y); \rarr$ write-write conflict
이러한 충돌을 방지(Concurrency Control technique으로)해야 correctness를 보장할 수 있다.

Why Concurrency Control Needed in a Schedule - Types of Problems (1 / 6)

Why Concurrency Control Needed in a Schedule - Types of Problems (2 / 6)

• Serial이므로 순서를 변경시켜도 결과가 동일

  

• Nonserial은 순서에 따라 결과가 달라지지만, Serializable은 순서를 변경시켜도 결과가 동일

Why Concurrency Control Needed in a Schedule - Types of Problems (3 / 6)

lost update problem

갱신 손실

• $T_1$이 write한 값 위에 $T_2$의 값이 덮어쓰여짐(Overwrite) ($T_1$ 입장에서는 lost)

Why Concurrency Control Needed in a Schedule - Types of Problems (4 / 6)

dirty read(or temporary update) problem

• $T_2$에서는 $T_1$에서 write하고 abort된 dirty data를 read = dirty read
• $X$의 value가 $old\_value$로 복구되어야 함

Why Concurrency Control Needed in a Schedule - Types of Problems (5 / 6)

incorrect summary problem

= Phantom read

• $T_3$는 $A, ..., X\,and\,Y$의 값들을 누적합하려는 transaction
• $T_1$이 $T_3$의 선택 조건에 매칭되는 새로운 record를 삽입하는 경우 결과값이 달라지게 되는 문제

Why Concurrency Control Needed in a Schedule - Types of Problems (6 / 6)

unrepeatable read problem

• 어떤 transaction이 같은 item을 두 번 read하려는데, 이 두 번의 read 사이에 다른 transaction의 영향으로 item의 값이 달라져있는 문제

위와 같은 모든 problems를 해결하고,
nonserial하지는 않지만 serializable schedule을 생성하기 위해서
Good Concurrency Control이 필요

Serializable Schedule

아래의 한 예시로 serial, serializable, non-serial에 대한 이해가 가능할 것이다.
$X=90;\, Y=90;\,N=3;\,M=2$

How to Ensure Serializablity?

Concurrency Control(CC) protocols 사용

Two-phase locking (2PL): 가장 흔하게 사용, Serialized schedule을 생성

• concurrent transactions가 서로 방해하는 것을 방지하기 위해 data items에 lock을 가하는 것
• locking은 아래 3가지 문제를 드러냄
  • high overhead, Dead lock, Starvation
• Two phases: growing, shrinking
• 하지만 deadlock 예방은 보장하지 못한다.

Transactions Following 2PL

TRANSACTION SUPPORT IN SQL

Transaction Support in SQL

• 일반적으로, 명시적인 $Begin\_Transaction$ 절이 없다.
• 하지만 명시적인 end statement인 $COMMIT | ROLLBACK$은 존재해야 한다.
• 모든 transaction은 isolation level(고립수준)으로 명시되는 특징을 가진다.
  • ISOLATION LEVEL
    • $isolation$ = READ UNCOMMITTED | READ COMMITTED
      (ORACLE에서 기본값)
      REPEATABLE READ | SERIALIZABLE (대부분의 DBMSs에서 기본값)

What Happens if Serializability is Violated?

• Dirty read (오손 읽기)
• Nonrepeatable read (반복 불가능)
• Phantoms (유령 데이터)

READ UNCOMMITTED: 개별 transaction의 성능 향상
SERIALIZABLE: concurrency control 성능 향상