5. Transactions

Transaction

• transaction: a unit of progam execution that accesses and possibly updates various data items.
  • 예를 들어 A 계좌에서 B 계좌로 돈을 송금하기 위한 트랜잭션
• Two main issues
  • hardware failures and system crashes
  • concurrent execution of multiple transactions

 

ACID Properties

데이터베이스의 데이터 무결성(integrity)을 보존하기 위해 데이터베이스 시스템이 보장해야 하는 속성들

• Atomicity (원자성): 모든 트랜잭션은 데이터베이스에 적절히 반영되거나 아무것도 반영되지 않아야 한다.
• Consistency (일관성): 독립된 트랜잭션의 수행은 데이터베이스의 일관성을 보존해야 한다.
• Isolation (독립성): 다수의 트랜잭션이 동시에 실행되더라도 각 트랜잭션은 동시에 실행되는 다른 트랜잭션의 실행을 알지 못해야 한다.
  • 중간의 트랜잭션 결과는 실행 중인 다른 트랜잭션에게서 숨겨져야 한다.
• Durability (지속성): 트랜잭션이 성공적으로 종료된 후 그 변화는 시스템 오류가 있더라도 데이터베이스에 지속되어야 한다.

 

Example of Fund Transfer

A 계좌에서 B 계좌로 $50 송금하는 트랜잭션

• Atomicity requirement
  • 3번 스텝에서 트랜잭션이 실패하면 일관되지 않은 데이터베이스 상태로 인한 돈의 손실이 발생
• Durability requirement
  • 사용자가 트랜잭션이 완료되었다는 것을 알게된 후에는 소프트웨어나 하드웨어의 오류가 있더라도 데이터베이스의 업데이트가 지속되어야 한다.
  • Failure Types: transaction / system / media failures

• Consistency requirement
  • 계좌 A와 B의 합은 트랜잭션 수행 이후에도 변화하지 않아야 한다.
  • 다음을 포함
    • 명시적 무결성 제약 조건: 기본 키 및 외래 키
    • 암묵적 무결성 제약 조건 - ex. 계좌의 잔액 합과 대출 금액 합을 뺀 값이 현금 보유량과 같아야 한다.
  • 트랜잭션 수행 동안에는 일시적으로 일관적이지 않을 수 있으나 끝난 후에 데이터베이는 일관되야 함.
  • 잘못된 트랜잭션 로직이 비일관성을 초래 가능

 

• Isolation requirement
  • step 3과 6 사이에 다른 트랜잭션 T2가 부분적으로 수정되니 데이터베이스에 접근하면 비일관성을 볼 수 있다.
  • Isolation은 트랜잭션을 순차적으로 실행함으로써 보장가능하지만 동시 트랜잭션의 이익이 크다.

 

 

---

Concurrent Executions

• Multiple transactions의 장점
  • 프로세서와 디스크 활용도 증가는 트랜잭션 처리량 증가로 이어진다.
  • 트랜잭션 평균 응답 시간을 줄인다. -> 짧은 트랜잭션이 긴 트랜잭션을 기다리지 않아도 된다.
• Concurrency control schemes
  • isolatiion을 달성하기 위한 메커니즘

 

Schedules

• Schedule: 동시 실행되는 트랜잭션들의 명령어들의 실행되는 순서를 지정하는 시퀀스
• 성공적으로 실행 종료하는 트랜잭션은 commit instruction을 마지막에 갖는다.
• 실패하면 마지막에 abort instruction을 갖는다.

Schedule 1

• T1: A -> B로 $50 송금
• T2: A -> B로 A잔액의 10% 송금
• serial schedule : T1 -> T2

Schedule 2

• serial schedule: T2 -> T1

 

Schedule 3

• serial schedule은 아니지만 Schedule 1과 동일함

Schedules 1, 2, 3에서 A + B은 보존됨

 

Schedule 4

• A + B이 보존되지 않음

---

Serializability

• Basic Assumption: 각 트랜잭션은 데이터베이싀 일관성을 보존한다.
• A schedule is serializable if it is equivalent to a serial schedule.

Simplified view of transactions

• read and write instructions를 제외한 operations를 무시

Conflicting Instructions

• instruction I_i와 I_j이 적어도 한 번 write하는 동일한 item Q가 존재한다면 transaction T_j와 T_i는 conflict
• I_i와 I_j 사이 충돌이 발생하면 둘 사이에는 시간적 실행 순서가 강제된다.
• 만약 두 instruction의 순서가 연속적이고 충돌하지 않는다면 순서를 뒤바꿔도 결과는 유지된다.

 

Conflict Serializability

• schedule S의 non-conflicting instructions을 바꿔서 schedule S'을 만들 수 있다면 S와 S'은 conflict equivalent하다. 
• schedule S is conflict serializable if it is conflict equivalent to a serial schedule.

 

 

---

Recoverable Schedules

• Recoverable schedule: 트랜잭션 T_j가 T_i에 의해 쓰여진 데이터 아이템을 읽었다면 T_i의 commit은 T_j의 commit 이전에 나타나야 한다.

 

Cascading Rollbacks

• Cascading rollback: 하나의 트랜잭션 실패가 다른 트랜잭션들의 롤백을 초래

T10이 실패하면 T11과 T12가 롤백되어야 한다.

Cascadeless Schedules

• Cascadeless schedule: cascading rollback이 발생하지 않음
  • 트랜잭션 T_j가 T_i에 의해 쓰여진 데이터 아이템을 읽으려면 T_i의 commit이 T_j의 read operation보다 선행되어야 함.
• 모든 cascadeless schedule은 recoverable하다.

 

Concurrency Control

• 데이터베이스는 모든 가능한 schedule이 다음과 같은 메커니즘을 제공해야 한다.
  • conflict or view serializable
  • recoverable and preferably cascadeless
• Concurrency control 스키마는 동시성의 양과 그것들이 초래하는 오버헤드의 양의 tradeoff
• 스키마에 따라 오직 conflic-serializable schedule만 허용하거나 view-serializable 하지만 conflict serializable하지 않은 schedule만 허용한다.

Transaction Isolation

• Dirty Read: 커밋되지 않은 다른 세션의 트랜잭션이 변경한 열을 읽을 수 있음
  • 변경한 트랜잭션이 롤백하면 읽은 데이터가 사라짐
• Non-repeatable Read: 한 트랜잭션에서 읽은 열을 다른 세션의 트랜잭션에서 변경하고 커밋할 수 있음
  • 첫 세션의 트랜잭션에서 다시 읽는다면 값이 변경됨
• Phantoms: 한 세션에서 특정 조건에 해당하는 열의 집합을 읽을 수 있고 다른 세션은 조건에 맞는 열을 추가한 후 커밋할 수 있음
  • 첫 세션의 트랜잭션에서 다시 조회하면 새로운 열을 발견함

Weak Levels of Consistency

• 성능과 정확성의 tradeoff를 고려하여 적절한 일관성 수준을 선택

Levels of Consistency in SQL-92

• Serializable - default
• Repeatable read - 커밋된 레코드만 읽으며 동일한 read는 동일한 값을 읽음
• Read committed - 커밋된 레코드만 읽을 수 있으나 동일한 read가 다른 값을 읽을 수 있음
• Read uncommitted - 커밋되지 않은 레코드도 읽음