제 15 장 트랜잭션 처리 Chapter 15. Transaction Processing

1. 제15장 트랜잭션 처리Chapter 15. Transaction Processing Byun, Jeonggyong uDB Lab School of Computer & Multimedia Dongguk University

2. 강좌 내용 DB개념과활용 제1장 개념, 기본용어 DB 설계 제2장 관계형 모델 제6장 DB설계와 ERD 제3장 SQL 제7장 관계형 DB 설계 제4장 고급SQL 제8장 응용설계 및개발 DB 관리 제10장 XML 제15장 트랜잭션 제16장 동시성 제어 제17장 회복 시스템

3. contents • Transaction: trans+action = 변동+처리, 프로그램 수행 단위 • Transaction Concept(트랜잭션 개념) • Transaction State(트랜잭션 상태) • Implementation of Atomicity and Durability(원자성과 지속성의 구현) • Concurrent Executions(동시 수행) • Serializability(직렬성) • Recoverability(복구가능성) • Implementation of Isolation(고립성의 구현) • Transaction Definition in SQL(SQL에서 트랜잭션 정의) • Testing for Serializability.(직렬성 실험)

4. Transaction Concept • A transactionis a unit of program execution that accesses and possibly updates various data items. • A transaction must see a consistent database. • During transaction execution, the database may be inconsistent. • When the transaction is committed, the database must be consistent. • Two main issues to deal with: • Failures of various kinds, such as hardware failures and system crashes • Concurrent execution of multiple transactions

5. ACID (원일고지) Properties To preserve integrity of data, the database system must ensure: • Atomicity(원자성). Either all operations of the transaction are properly reflected in the database or none are. • Consistency(일관성). Execution of a transaction in isolation preserves the consistency of the database. • Isolation(고립성). Although multiple transactions may execute concurrently, each transaction must be unaware of other concurrently executing transactions. Intermediate transaction results must be hidden from other concurrently executed transactions. • That is, for every pair of transactions Tiand Tj, it appears to Tithat either Tj, finished execution before Ti started, or Tj started execution after Ti finished. • Durability(지속성). After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures.

6. 적립금 전송의 예 • Transaction to transfer $50 from account A to account B: 1. read(A) 2. A := A –50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B) • Consistency requirement – the sum of A and B is unchanged by the execution of the transaction. • Atomicity requirement — if the transaction fails after step 3 and before step 6, the system should ensure that its updates are not reflected in the database, else an inconsistency will result.

7. 적립금 전송의 예(Cont.) • Durability requirement • once the user has been notified that the transaction has completed (i.e., the transfer of the $50 has taken place), the updates to the database by the transaction must persist despite failures. • Isolation requirement • if between steps 3 and 6, another transaction is allowed to access the partially updated database, it will see an inconsistent database (the sum A + B will be less than it should be). • Can be ensured trivially by running transactions serially, that is one after the other. However, executing multiple transactions concurrently has significant benefits, as we will see.

8. Transaction State • Active(동작), the initial state; the transaction stays in this state while it is executing • Partially committed(부분완료), after the final statement has been executed. • Failed(실패), after the discovery that normal execution can no longer proceed. • Aborted(철회,취소), after the transaction has been rolled back and the database restored to its state prior to the start of the transaction. Two options after it has been aborted: • restart the transaction – only if no internal logical error • kill the transaction • Committed(완료),after successful completion.

9. Transaction State (Cont.) 완료 부분완료 동작 철회 실패

10. 원자성과 지속성의 구현 • The recovery-management component of a database system implements the support for atomicity and durability. • 그림자 데이터베이스전략(shadow-database scheme): • assume that only one transaction is active at a time. • a pointer called db_pointer always points to the current consistent copy of the database. • all updates are made on a shadow copy of the database, and db_pointer is made to point to the updated shadow copy only after the transaction reaches partial commit and all updated pages have been flushed to disk. • in case transaction fails, old consistent copy pointed to by db_pointer can be used, and the shadow copy can be deleted.

11. 원자성과 지속성의 구현 (Cont.) 그림자 데이터베이스 전략: • 디스크는 실패하지 않는 것으로 간주함 • 문서편집기에 유용함. 하지만 큰 DB에서는 극히 비효율적임. 단일 트랜잭션 수행시 전체 DB 복사요구. (Will see better schemes in Chapter 17.)

12. 동시 실행(Concurrent Executions) • 다중 트랜잭션이 시스템에서 동시적으로 수행되도록 허용될 때의 장점들: (*실행=수행) • 처리기 및 디스크의 이용률 증가, 트랜잭션의 실행결과를 보다 좋게 주도함:한 트랜잭션이 디스크 읽기, 쓰기 동안 다른 트랜잭션은 CPU를 사용할 수 있게 함. • 트랜잭션의 평균 응답시간의 단축: 수행시간이 짧은 트랜잭션이 긴 것들 뒤에서 기다리지 않도록 함. • 동시성제어전략(Concurrency control schemes) • 고립성을 성취할 장치 즉 동시수행 트랜잭션들이 DB의 일관성을 깨어버리지 않도록 하기 위하여 그들간의 상호작용을 제어하는 것 • 동시수행의 정확성 개념을 공부한 후 16장에서 다룸.

13. 스케줄(Schedules) • 일정,스케줄(Schedules) • 동시수행 트랜잭션들의 명령어들이 수행되는 시간적 순서를 지시하는 순서 나열 • 트랜잭션을 구성하는 명령어들의 실행순서. • 트랜잭션 집합에 대한 스케쥴은 그들 트랜잭션의 모든 명령어들로 구성되어야 함 • 한 트랜잭션에 속하는 명령어들은 스케줄 내에 같이 나타난다. • DB에서 여러 트랜잭션이 동시 수행이 될 때 이에 대응하는 스케줄은 더 이상 순차적이지 못하다.

14. DB 자료와 프로그램 자료 • 프로그램의 변수 • Read(A) … Write(A) • Read(B) … Write(B) buffer A: 100 200 B: Read (A) Read (B) Write (A) Write (B) 100 200

15. Fig 15.4 Fig 15.3 스케줄1,2의 예 • 계좌 A에서 B로 $50을 송금하는 트랜잭션을 T1, A에서 10% 차감한 잔액을 B로 송금하는 트랜잭션을 T2. • T1=> T2 가 따라서 수행될 때 직렬 스케줄. • 초기값: A=$1000,B=$2000 • 스케줄 1: <T1, T2> f15.3 • A=$855, B=$2145 • 스케줄 2: <T2, T1> f15.4 • A=$850, B=$2150

16. 스케줄3의 예 (Cont.) • 직렬 스케줄이 아닌 오른쪽 스케줄 3은 스케줄1과 같다. • 두 스케쥴 1과 3에서, 합 A + B는 보장(유지)된다. • 초기값: A=$1000,B=$2000 • A=$855, B=$2145 • 스케줄 1: A+B = 스케줄 3: A+B Fig 15.5

17. 스케줄4의 예 (Cont.) • 동시성 스케쥴 4는 합 A+B를 보장하지 못한다. • T1:A = 1000 • T2의 A는 1000에서 900이 된 후 쓰기함 • T2는 B를 읽음, B는 2000 • T1은 A에 950을 겹쳐 씀. 900 없어짐 • T1은 B=2000읽은 후 2050을 쓰기함 • T2는 2100을 겹쳐 쓰기함. 2050 은 겹쳐 쓰기로 없어짐 • 스케줄 4:

18. 직렬성(Serializability) • 기본가정–각 트랜잭션은 DB 일관성을 보장함. • 따라서 트랜잭션 집합의 직렬수행은 DB 일관성을 보장함. • 어떤 스케줄이 직렬 스케줄과 일치(equivalence)이면 그 스케줄은 직렬가능(serializable)이다. 스케줄 일치의 다른 형태의 두 개념: • 충돌 직렬성(conflict serializability) • 뷰 직렬성(view serializability) • 읽기(read)와쓰기(write)명령어 이외는 무시한다. 읽기와 쓰기 동안에 지역 버퍼 내에 있는 자료에 대한 임의의 계산을 수행한다고 가정한다. 단순화된 스케줄은 단지 읽기, 쓰기 명령어들로 구성되어 있다.

19. 충돌 직렬성(Conflict Serializability) • 두 명령어li와lj (i ≠ j)가 동시에 접근된 항목 Q가 존재하고 적어도 이들 중 하나는 Q에 쓰기를 한다면 트랜잭션 Ti와 Tj 의 각 명령어 li와lj는 충돌한다. 1. li = read(Q), lj = read(Q). li와 lj는 충돌하지 않음.2. li = read(Q), lj = write(Q). 충돌.3. li = write(Q), lj = read(Q). 충돌.4. li = write(Q), lj = write(Q). 충돌. • 직관적으로, li와lj간의 충돌은 그들간의 시간적 순서를 강제한다. li와 lj가 한 스케줄에서 연속적이며, 충돌하지 않는다면, 그들이 스케줄에서 상호 교환되었다 할지라도 그들의 결과는 같은 상태 가 될 것이다.

20. 충돌 직렬성(Cont.) • 스케줄 S가 일련의 비충돌 명령어의 교환에 의하여 스케줄 S´으로 변환될 수 있다면, S 와 S´ 는 충돌동등(conflict equivalent)라 한다. • 스케줄 S가 직렬스케줄과 충돌동등이라면, 그 스케줄은 충돌직렬가능(conflict serializable)이라 한다. • 스케줄 3 => 스케줄 5 • T1 read(B)T2 read(A) • T1 write(B)T2 write(A) • T1 write(B)T2 read(A) • 순서변경을 모두하면 => 스케줄 6 스케줄 5 스케줄 6

21. 충돌직렬성(계속) • 충돌 직렬적이지 못한 예: • 스케줄 7 => • 이 스케줄은 직렬스케줄인 < T3, T4 > 또는 < T4, T3 > 어느 쪽과도 일치하지 않기 때문에 충돌직렬적이지 못하다. • Q=100, T4: Q=200 • <T3,T4> Q=200, <T4,T3> Q=250 • 오른쪽 스케줄 3은 비충돌 명령어의 교환으로 스케줄 1(T2가 T1 을 따름)으로 변환될 수 있다. 그러므로스케줄 3 은 충돌 직렬성을 가진다.

22. 직렬성의 다른 개념 • Schedule 8 은 < T1,T5 >와 같은 결과를 내지만 충돌 동등 또는 뷰 동등하지 않다. • 실행 후 결과 값은 $960, $2,040으로 같지만, • T5의 write(B)와 T1의 read(B)와 충돌한다. • 다음 뷰동등(조건1,2,3)에서 해결 • 그와 같은 일치를 결정하는 것은 읽기, 쓰기와 다른 연산의 분석을 요구한다. 충돌

23. 뷰직렬성 • 같은 트랜잭션 집합을 가진 두 스케줄을 S와S´이라 하자. 다음 3가지 조건이 만족하면 S와S´은 뷰일치(view equivalent)라고 한다: • 스케줄1,스케줄2는 뷰동등하지 않다. 스케줄2는 조건2 위반 • 스케줄3은 조건 1,2,3 만족하므로 뷰동등하다. • 각 자료 항목 Q에 대하여, 만약 스케줄 S에 있는 트랜잭션 Ti가 Q의 초기값을 읽는다면,Ti는 반드시 S´에서도 Q의 초기값을 읽어야 한다. • 각 자료 항목 Q에 대하여, 만약 트랜잭션 Ti가 스케쥴 S에서 read(Q)를 수행하고, 그 값이 트랜잭션 Tj (있을 경우)의 write(Q)에 의하여 만들어진 값이라면, 트랜잭션 Ti의 read(Q) 연산은 반드시 S´ 에서도 Tj 의 write(Q)에 의하여 만들어진 Q의 값을 읽어야 함. • 각 자료 항목 Q에 대해, 만약 스케쥴 S에서 최종 write(Q) 연산을 수행하는 트랜잭션은 S´에서도 마지막 write(Q)를 수행해야 한다.

24. 뷰 직렬성 (Cont.) • 스케줄S가 직렬스케줄과 뷰동등이라면 그 스케줄은 뷰 직렬가능 • 모든 충돌직렬가능 스케줄은 또한 뷰 직렬가능, 역은 성립하지 않음. • 스케줄 9는 뷰직렬가능이지만 충돌직렬가능이 아닌 스케줄이다. • T4와 T6은 read(Q)를 하지 않고 바로 write(Q)만 실행한다. 이런 맹목쓰기는 충돌직렬적이 아니 어떤 뷰 직렬 스케줄에도 나타날 수 있음 • 스케줄 9 => • 스케줄 9는 <T3,T4,T6>와 뷰동등 (조건1,3 만족). • 충돌직렬가능이 아닌 모든 뷰직렬가능 스케줄은 맹목 쓰기(blind writes)이다.

25. 복구성(Recoverability) • 동시수행중인 트랜잭션의 실패의 효과 • Ti가 실패하면 원자성 보장을 위하여 Ti의 실행 결과철회(abort) • Ti에 종속적인 Tj의 실행 또한 철회(abort)되어야 함 • 복구 가능한 스케줄(Recoverableschedule) • Tj가 이전에 Ti에 의하여 기록된 데이터를 읽는 트랜잭션 Ti와 Tj 의 각 쌍에 대해 Ti가 Tj에 대하여 Tj 의 연산이 완료되기 전에 Ti 의 연산이 먼저 완료되는 스케줄 • 스케줄 11은 복구 불가능 • T9은 읽기뒤 곧 바로 완료(T8보다 먼저) • T8이 철회되었을 때 복구불가능 • DB는 스케줄의 복구 가능성을 보장해야 함. 스케줄 11

26. 복구성(Cont.) • 연쇄적인 복구(Cascading rollback)–하나의 트랜잭션이 취소됨으로써 쓴 값을 읽어간 일련의 트랜잭션들이 따라서 취소되는 현상 • 연쇄적 취소는 바람직하지 않은 현상이다. • T10이 실패하면 T11은 종속되므로 반드시 취소 및 복귀 • T12 역시 T11에 종속되므로 반드시 취소 및 복귀 • 스케줄 12 : <T10, T11, T12> T11 T10 T12 읽기 4 2 1 3 읽기 실패 data 쓰기

27. 복구성(Cont.) • 비연쇄적 스케줄(Cascadelessschedules): Ti에 의하여 쓰여진 하나의 자료 항목을 Tj가 읽는 한 쌍의 트랜잭션 Ti와 Tj에서 Tj의 읽기 연산에 앞서 Ti의 완료 연산이 실행되는 스케줄 • 모든 비연쇄적 스케줄은 또한 복구가능 • 비연쇄적인 트랜잭션으로 스케줄을 제한하는 것이 바람직하다. Ti Tj 2 완료 1 3 읽기 data 쓰기

28. 고립성의 구현 • DB의 일관성 유지, 실패의 안전한 처리를 위한 스케줄의 필수 속성: 충돌직렬가능, 뷰 직렬가능, 비연쇄적 요구 • 동시성 제어기법에서 DB 전체에 잠금장치 사용 가능 • 단지 한 트랜잭션만이 한 순간에 수행될 수 있다는 정책은 직렬적, 비연쇄적이지만 동시성 수준이 떨어짐, 즉 성능저하 초래 • 동시성 제어 기법 => 16장 • 목적: 생성된 모든 스케줄들이 충돌, 뷰직력적이고 비연쇄적임을 보장하면서 높은 동시성을 보장하는 것 • 특성: 허용하는 동시성의 양과 일으키는 부담의 둘사이에 하나가 좋으면 하나가 나쁜 관계를 갖는다.(Trade-off) • 기법들 가운데 일부는 충돌 직렬가능만을 허용하며, 어떤 것은 뷰 직렬가능한 스케줄만을 허용한다.

29. 직렬성 검사 • T1, T2, ..., Tn트랜잭션 집합의 몇몇 스케줄 고려 • 순위그래프(Precedence graph)—정점은 트랜잭션, 연결선은 아래 세조건 중 하나. G = (V,E) • Tj가 read(Q)를 실행하기 전에 Ti가 write(Q)를 실행 • Tj가 write(Q)를 실행하기 전에 Ti가 read(Q)를 실행 • Tj가 write(Q)를 실행하기 전에 Ti가 write(Q)를 실행 • Ti -> Tj이면 Ti는 반드시 Tj보다 먼저 실행되어야 함 • 스케줄 4처럼, 순위 그래프에 고리(cycle)가있으면 스케줄은 충돌 직렬가능이 아니다. 스케줄4 x y

30. 위상정렬 도식 • 트랜잭션의 직렬순서는 순위그래프의 부분 순서에 대응되는 선형순서를 결정하는 위상정렬(topological sorting)을 통하여 얻을 수 있다. • 순위그래프 작성 =>탐색알고리즘

31. End of Chapter

32. Schedule 5 -- Schedule 3 After Swapping A Pair of Instructions

33. Schedule 6 -- A Serial Schedule That is Equivalent to Schedule 3

34. Schedule 7

35. Precedence Graph for (a) Schedule 1 and (b) Schedule 2

36. Precedence Graph

37. fig. 15.21