Fundamentals of Database Systems R. A. Elmasri and S. B. Navathe

Presentation on theme: "Fundamentals of Database Systems R. A. Elmasri and S. B. Navathe"— Presentation transcript:

1 Fundamentals of Database Systems R. A. Elmasri and S. B. Navathe
제 18장 데이터베이스 트랜잭션 처리의 기반 Fundamentals of Database Systems R. A. Elmasri and S. B. Navathe © 2005 황규영 홍의경 음두헌 박영철 김진호 조완섭

2 Fundamentals of Database Systems
18장. 트랜잭션 처리를 위한 개념 18.1 트랜잭션 처리의 개요 18.2 트랜잭션과 시스템 개념 18.3 트랜잭션의 성질 18.4 회복가능성을 근거로 한 스케줄의 특성화 18.5 직렬가능성을 근거로 한 스케줄의 특성화 18.6 SQL의 트랜잭션 지원 18.7 요약 Ch18 Fundamentals of Database Systems

3 Fundamentals of Database Systems
18.1 트랜잭션 처리의 개요 단일 사용자 시스템과 다수 사용자 시스템 트랜잭션, 읽기와 쓰기 연산, DBMS 버퍼 동시성 제어가 필요한 이유 회복이 필요한 이유 Ch18 Fundamentals of Database Systems

4 Fundamentals of Database Systems
단일 사용자 시스템과 다수 사용자 시스템 단일 사용자 시스템 한번에 한 사람만이 사용할 수 있는 시스템 다수 사용자 시스템 동시에 많은 사용자가 사용할 수 있는 시스템 예: 은행, 보험회사, 증권 거래소 등에서 사용되는 시스템 다중 프로그래밍 개념 인터리빙 병렬처리 Ch18 Fundamentals of Database Systems

5 [그림 18.1] 동시에 수행되는 트랜잭션들을 인터리빙 형태로 처리하는 것과 병렬처리하는 것.
A A B B C CPU1 D CPU2 시간 t2 t3 t4 t1 [그림 18.1] 동시에 수행되는 트랜잭션들을 인터리빙 형태로 처리하는 것과 병렬처리하는 것. Ch18 Fundamentals of Database Systems

6 18.1.2 트랜잭션, 읽기와 쓰기 연산, 그리고 DBMS 버퍼
읽기 전용 트랜잭션: 데이타를 검색만 하는 트랜잭션 트랜잭션의 데이타베이스 접근 연산 read_item(X) : 검색 연산 write_item(X) : 삽입, 삭제, 변경 연산 (a) read_item(X); (b) read_item(X); X:=X-N; X:=X+M; write_item(X); write_item(X); read_item(Y); Y:=Y+N; write_item(Y); [그림 18.2] 두 개의 샘플 트랜잭션 (a) 트랜잭션 T1, (b) 트랜잭션 T2 트랜잭션의 읽기 집합: 그 트랜잭션이 읽는 모든 항목들의 집합 트랜잭션의 쓰기 집합: 그 트랜잭션이 기록하는 모든 항목들의 집합 Ch18 Fundamentals of Database Systems

7 18.1.2 트랜잭션, 읽기와 쓰기 연산, 그리고 DBMS 버퍼(cont.)
read_item(X)의 수행과정 1. 항목 X를 포함하는 디스크 블록의 주소를 찾는다. 2. 그 디스크 블록을 주기억장치의 버퍼로 복사한다. (디스크 블록이 주기억장치의 버퍼에 이미 존재하는 것이 아닐 때) 3.항목 X를 버퍼로부터 프로그램 변수 X에 복사한다. write_item(X)의 수행과정 2. 그 디스크 블록을 주기억장치의 버퍼로 복사한다. (디스크 블록이 주기억장치의 버퍼에 이미 존재하는 것이 아닐 때) 3.항목 X를 프로그램 변수 X에서 그 버퍼의 정확한 위치로 복사한다. 4. 갱신된 블록을 디스크에 저장한다. (즉시 또는 나중의 어느 시점에) Ch18 Fundamentals of Database Systems

8 Fundamentals of Database Systems
동시성 제어가 필요한 이유 갱신 손실 문제(the lost update problem) T1 T2 (a) read_item(X); X:=X-N; write_item(X); read_item(Y); Y:=Y+N; write_item(Y); 시간 read_item(X); X:=X+M; write_item(X); commit; rollback; T2이 갱신한 결과를 잃어버리게 됨 [그림 18.3] 동시 수행을 제어하지 않았을 때 발생할 수 있는 문제점들 (a) 갱신 손실 문제 Ch18 Fundamentals of Database Systems

9 Fundamentals of Database Systems
동시성 제어가 필요한 이유(cont.) 임시 갱신 (또는 오손 읽기) 문제 : temporary update(or dirty read) problem T1 T2 read_item(X); X:=X-N; write_item(X); read_item(Y); Y:=Y+N; Write_item(Y); Print X; commit; 트랜잭션 T1이 실패하면 X의 값은 원래의 값으로 바뀌어야 한다. 그런데 바꾸기 전에 T2가 X의 잘못된 임시 값을 읽었다. 시간 (b) rollback; [그림 18.3] 동시 수행을 제어하지 않았을 때 발생할 수 있는 문제점들 (b) 임시 갱신 문제 Ch18 Fundamentals of Database Systems

10 동시성 제어가 필요한 이유 (cont.) 부정확한 요약 문제(the incorrect summary problem) T1 T3 sum := 0; read_item(A); sum := sum+A; . read_item(X); sum := sum+X; read_item(Y); sum := sum+Y; commit; 시간 T1이 N을 뺀 후에 T3이 X를 읽고 T1이 N을 더하기 전에 T3이 Y를 읽으므로 요약(합)의 결과가 N만큼 적게된다. [그림 18.3] 동시 수행을 제어하지 않았을 때 발생할 수 있는 문제점들 (c) 부정확한 요약 문제 read_item(X); X := X- N; write_item(X); read_item(Y); Y := Y+N; write_item(Y); commit;

11 Fundamentals of Database Systems
동시성 제어가 필요한 이유 (cont.) 반복할 수 없는 읽기 문제 (unrepeatable read problem) 트랜잭션 T가 수행 도중 하나의 항목을 두 번  읽을 때 각각의 읽기 연산 사이에 다른 트랜잭션 T＇가 그 항목의 값을 바꾸게 되면 T는 동일한 항목을 서로 다른 값으로 읽게 된다. Ch18 Fundamentals of Database Systems

12 18.1.3 동시성 제어가 필요한 이유 (cont.) T1 T3 시간 read_item(X); print X;
…. commit 시간 read_item(X); X := X- N; write_item(X); commit

13 Fundamentals of Database Systems
회복이 필요한 이유 DBMS는 트랜잭션의 실행 결과 다음의 두가지 성질 중 한가지를 만족하도록 보장해야 한다. 트랜잭션의 모든 연산이 성공적으로 완료되고, 그 결과가 데이타베이스에 영구적으로 기록된다. 트랜잭션이 데이타베이스나 어떤 다른 트랜잭션에도 영향을 미치지 않는다. DBMS는 트랜잭션 T의 일부 연산만이 반영되고 나머지 연산은 반영되지 않는 그러한 상황을 허용하면 안된다. 이러한 상황은 트랜잭션이 연산의 일부만 수행하고 연산 전체를 수행하기 전에 실패하는 경우 발생할 수 있다. Ch18 Fundamentals of Database Systems

14 Fundamentals of Database Systems
회복이 필요한 이유(cont.) 실패의 분류 트랜잭션 고장 (transaction failure) 시스템 고장(system failure) 매체 고장(media failure) 실패의 원인 컴퓨터 고장 또는 시스템 붕괴(system crash) 트랜잭션 또는 시스템 오류 트랜잭션이 탐지한 지역적 오류 또는 예외 조건 동시성 제어 시행 디스크 고장 물리적 문제와 재해 Ch18 Fundamentals of Database Systems

15 Fundamentals of Database Systems
18.2 트랜잭션과 시스템 개념 트랜잭션의 상태와 추가적인 연산들 시스템 로그 트랜잭션의 완료점 Ch18 Fundamentals of Database Systems

16 Fundamentals of Database Systems
트랜잭션의 상태와 추가적인 연산들 하나의 트랜잭션은 완전히 수행을 완료하거나 전혀 수행되지 않아야 함 회복을 위한 목적으로 회복 관리자는 트랜잭션에 대해 다음과 같은 연산들이 적용된 시점을 유지해야 함 트랜잭션의 시작(BEGIN_TRANSACTION) 읽기 또는 쓰기(READ or WRITE) 트랜잭션의 종료(END_TRANSACTION) 트랜잭션의 완료(COMMIT_TRANSACTION) 복귀(ROLLBACK) 또는 철회(ABORT) 위의 연산 외에 취소(undo)와 재수행(redo)과 같은 추가적인 연산들을 필요로 하는 회복 기법들도 있음 Ch18 Fundamentals of Database Systems

17 18.2.1 트랜잭션의 상태와 추가적인 연산들(cont.)
수행중인 상태 완료 PARTIALLY COMMITTED 부분 완료 상태 철회 완료 상태 읽기, 쓰기 트랜잭션 시작 종료 상태 실패 상태 트랜잭션 종료 [그림 18.4] 트랜잭션 실행의 상태를 나타내는 상태 전이도 Ch18 Fundamentals of Database Systems

18 Fundamentals of Database Systems
시스템 로그 트랜잭션 실패를 회복하기 위해서 시스템은 로그(log)를 유지함 로그에는 데이타베이스 항목에 영향을 미치는 트랜잭션의 모든 연산들을 기록하며, 이 정보는 트랜잭션 실패를 회복하는데 사용됨 로그는 디스크 오류를 제외한 어떠한 오류에도 영향을 받지 않도록 하기 위하여 디스크에 유지됨 로그를 주기적으로 테이프 등에 백업하여 디스크 오류 등의 재해로부터 대비함 로그에 기록되는 레코드들의 유형은 다음과 같음. T는 트랜잭션 식별자임 [start_transaction, T] [write_item, T, X, old_value, new_value] [read_item, T, X] [commit, T] [abort, T] 로그를 이용하여 트랜잭션에 의해 변화된 내용을 취소하거나 재수행할 수 있음 연쇄 복귀(cascading rollback)를 방지하는 회복 프로토콜에서는, 거의 모든 실제 프로토콜이 이에 해당하는데, 읽기 연산을 시스템 로그에 기록할 필요가 없다. 그러나 모든 데이타베이스 연산을 추적해야 하는 감사(auditing) 시스템 같이 로그를 다른 목적으로 사용하는 경우에는 읽기 연산을 시스템 로그에 기록해야 한다. Ch18 Fundamentals of Database Systems

19 Fundamentals of Database Systems
트랜잭션의 완료점 트랜잭션의 완료(commit) 데이타베이스를 접근하는 모든 연산들이 성공적으로 수행되고, 트랜잭션의 모든 연산들이 데이타베이스에 끼친 효과들이 로그에 저장되었을 때, 트랜잭션 T는 완료점에 도달한다. 완료점을 지나면 트랜잭션을 ‘완료’ 되었다고 한다. 시스템 고장이 일어나면 로그에 [start_transaction, T]를 기록했지만 [commit, T] 레코드는 기록하지 않은 모든 트랜잭션 T를 찾아서 복귀시킨다. 로그에 commit 레코드를 기록한 트랜잭션은 commit 레코드 이전에 먼저 자신의 모든 쓰기 연산들을 로그에 기록해야 한다. 로그 레코드가 추가될 때마다 디스크에 직접 기록하는 대신에 로그 화일의 한 블록을 주기억장치에 유지하고 그것이 로그 레코드들로 채워질 때마다 디스크에 한 번만 기록하는 방법이 보편적으로 사용된다. 트랜잭션을 완료하기 전에 로그화일에 강제 쓰기(force-writing)한다. Ch18 Fundamentals of Database Systems

20 Fundamentals of Database Systems
18.3 트랜잭션의 성질 트랜잭션은 다음의 ACID 성질을 가져야 하며, 이 성질은 DBMS의 동시성 제어와 회복 기법을 통하여 유지됨 원자성(Atomicity). 한 트랜잭션은 하나의 원자적 수행 단위이다. 트랜잭션은 완전히 수행되거나 전혀 수행되지 않아야 한다. 일관성 유지 (Consistency preservation). 트랜잭션을 완전히 실행하면 데이타베이스를 하나의 일관된 상태에서 또 다른 일관된 상태로 바꿔야 한다. 고립성(Isolation). 하나의 트랜잭션은 다른 트랜잭션들과는 독립적으로 실행되는 것처럼 보여야 한다. 즉 하나의 트랜잭션의 실행은 동시에 실행 중인 다른 트랜잭션의 간섭을 받아서는 안된다. 지속성(Durability) 또는 영속성(permanency). 일단 한 트랜잭션이 데이타베이스를 변경시키고 그 변경이 완료되면 그 변경은 이후의 어떠한 고장에도 손실되지 않아야 한다. 고립성 등급. 0 등급 : 상위등급의 트랜잭션이 오손읽기(dirty-read)한 것을 덮어쓰지 않는다. 1 등급 : 갱신 손실(lost update)이 없다. 2 등급 : 갱신 손실과 오손 읽기가 없다. 3 등급 : 등급 2의 성질을 모두 가지며, 이외에도 반복 읽기(repeatable read) 성질을 가진다. Ch18 Fundamentals of Database Systems

21 Fundamentals of Database Systems
18.4 회복가능성을 근거로 한 스케줄의 특성화 트랜잭션들이 인터리빙 방식으로 동시에 수행될 때 여러 트랜잭션들이 가진 연산들의 실행 순서를 스케줄(또는 히스토리)이라 한다. 트랜잭션들의 스케줄(히스토리) 회복가능성을 근거로 한 스케줄의 특성화 Ch18 Fundamentals of Database Systems

22 Fundamentals of Database Systems
트랜잭션의 스케줄(히스토리) 트랜잭션의 스케줄 n개의 트랜잭션 T1, T2, ..., Tn의 스케줄(히스토리) S는 이들 트랜잭션들의 연산들을 순서화한 것임 여기서 스케줄 S에 참여하는 각 트랜잭션 Ti에 대해서 Ti의 연산들이 Ti내에서와 동일한 순서로 스케줄 S에 나타나야 함 [예: 그림 14.3 (a) ] Sa : r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y); 충돌(conflict) 하나의 스케줄에 포함된 두 개의 연산이 아래의 세 가지 조건들을 모두 만족하면 충돌(conflict)이라고 함 : (1) 그 연산들은 서로 다른 트랜잭션에 속한다. (2) 그 연산들은 동일한 항목 X에 접근한다. (3) 그 연산들 중 최소한 하나는 write_item(X)이다. Ch18 Fundamentals of Database Systems

23 18.4.1 트랜잭션의 스케줄(히스토리)(cont.)
완전한 스케줄(complete schedule) : n개의 트랜잭션 T1, T2, ..., Tn에 대한 스케줄 S가 다음과 같은 조건을 만족하면 완전한 스케줄이라고 함 1. S 내의 연산들은 T1, T2, ..., Tn내의 연산들이며, 각 트랜잭션의 마지막 연산으로서 완료나 철회 연산을 포함한다. 2. 트랜잭션 Ti의 연산들의 어떠한 쌍에 대해서도 S내에서 그 연산들이 나타나는 순서는 Ti내에서 그 연산들이 나타나는 순서와 동일하다. 3. 충돌하는 어떠한 두 개의 연산에 대해서도 그들 중 하나는 반드시 나머지 하나보다 스케줄에서 먼저 나타나야 한다. Ch18 Fundamentals of Database Systems

24 Fundamentals of Database Systems
회복가능성을 근거로 한 스케줄의 특성화 회복가능한 스케줄 (recoverable schedule) 트랜잭션 T 가 완료되었다면 절대 복귀(rollback)될 필요가 없다는 기준을 두고, 이 기준을 만족하는 스케줄을 회복가능한 스케줄이라 한다. 회복가능(recoverable) 만약 스케줄 S내의 어떤 트랜잭션 T에 대해서도 T가 읽은 항목에 쓰기연산을 수행한 모든 트랜잭션 T’이 완료되기 전까지 T가 완료되지 않는다면 S가 회복가능하다고 한다. 회복가능한 스케줄내에서는 어떠한 완료된 트랜잭션도 복귀할 필요가 없다. 연쇄복귀(cascading rollback) 또는 연쇄철회(cascading abort) 완료되지 않은 트랜잭션이 실패한 트랜잭션으로부터 항목을 읽어옴으로써 발생하는 것으로 하나의 트랜잭션 철회가 다른 트랜잭션의 철회로 이어지는 현상이 발생함 [예] Se : r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2 Ch18 Fundamentals of Database Systems

25 18.4.2 회복가능성을 근거로 한 스케줄의 특성화(cont.)
연쇄복귀방지 완료된 트랜잭션이 쓴 항목만을 읽는다. 엄격한 스케줄(strict schedule) 마지막으로 X에 쓰기연산을 한 트랜잭션이 완료되거나 철회되기 전까지 다른 트랜잭션이 X를 읽지도 쓰지도 못한다. 회복과정 : 철회된 쓰기연산이 적용되기 전에 X가 가지고 있던 이전값(before image, BFIM)으로 복귀. 지금까지 스케줄들을 (1) 회복가능성, (2) 연쇄 복귀의 방지, (3) 엄격함이라는 관점에 따라 특성화하였다. 스케줄들이 가진 특성들은 번호가 높아짐에 따라 더 엄중한 조건임을 알 수 있다. 그러므로 조건 (2)는 조건 (1)을 암시하고 조건 (3)은 조건 (2)와 (1) 모두를 암시한다. 따라서, 모든 엄격한 스케줄들은 연속적인 철회가 필요 없으며, 모든 연속적인 철회가 필요 없는 스케줄들은 회복가능하다. Ch18 Fundamentals of Database Systems

26 Fundamentals of Database Systems
18.5 직렬가능성을 근거로 한 스케줄의 특성화 스케줄들의 직렬가능성 개념은 트랜잭션들의 연산들이 인터리빙되어 수행될 때 어떤 스케줄들이 정확한지 식별하는데 사용된다. 직렬, 비직렬, 충돌 직렬가능 스케줄 스케줄의 충돌 직렬가능성 테스트 직렬가능성의 용도 뷰 동치와 뷰 직렬가능성 스케줄 동치의 기타 유형 Ch18 Fundamentals of Database Systems

27 Fundamentals of Database Systems
직렬, 비직렬, 충돌 직렬가능 스케줄 직렬스케줄(Serial schedule) T1 T2 read_item(X); X:=X-N; write_item(X); Y:=Y+N; write_item(Y); X:=X+M; 시간 read_item(Y); (a) (b) 그림 18.5 (a)와 (b)의 스케줄은 다른 트랜잭션과 인터리빙 없이 연속적으로 수행되므로 직렬 스케줄이다. Ch18 Fundamentals of Database Systems

28 18.5.1 직렬, 비직렬, 충돌 직렬가능 스케줄(cont.)
비직렬 스케줄(Nonserial schedule) T1 T2 read_item(X); X:=X-N; write_item(X); Y:=Y+N; write_item(Y); X:=X+M; 시간 read_item(Y); (c) (d) 그림 18.5 (c)와 (d)의 스케줄은 두 트랜잭션들의 연산들이 인터리빙되므로 비직렬 스케줄이다. Ch18 Fundamentals of Database Systems

29 18.5.1 직렬, 비직렬, 충돌 직렬가능 스케줄(cont.)
직렬 스케줄 스케줄에 참가하는 각 트랜잭션 T에 대해서 T에 속한 모든 연산들이 다른 트랜잭션의 연산들과 인터리빙되지 않고 연속적으로 실행될 때 직렬 스케줄이라고 함 스케줄의 직렬가능 n개 트랜잭션들로 구성된 스케줄 S가 동일한 n개의 트랜잭션들로 구성된 어떤 직렬 스케줄과 동치일 경우를 의미함 결과 동치(result equivalence) 두 개의 스케줄이 데이타베이스의 최종 상태를 동일하게 만드는 경우 스케줄의 동치를 정의하는데 사용해서는 안됨 충돌 동치 두 스케줄에서 어떠한 두 개의 충돌 연산들의 순서도 동일할 경우 Ch18 Fundamentals of Database Systems

30 18.5.1 직렬, 비직렬, 충돌 직렬가능 스케줄(cont.)
충돌 직렬 가능(Conflict serializable) 충돌 동치의 개념을 이용해서 스케줄 S가 어떤 직렬 스케줄 S’과 (충돌) 동치일 경우 Ch18 Fundamentals of Database Systems

31 Fundamentals of Database Systems
스케줄의 충돌 직렬가능성 테스트 스케줄 S의 충돌 직렬가능성 테스트 알고리듬 스케쥴 S에 참가하는 각 트랜잭션 Ti에 대해 선행 그래프에서 Ti라는 레이블을 가진 노드 생성 스케줄 S에서 Ti가 write_item(X)를 실행한 후에 Tj가 read_item(X)를 실행하는 경우마다 선행 그래프에 간선 (Ti Tj) 생성 스케줄 S에서 Ti가 read_item(X)를 실행한 후에 Tj가 write_item(X)를 실행하는 경우마다 선행 그래프에 간선 (Ti Tj) 생성 스케줄 S에서 Ti가 write_item(X)를 실행한 후에 Tj가 write_item(X)를 실행하는 경우마다 선행 그래프에 간선 (Ti Tj) 생성 스케줄 S가 직렬가능한 것은 선행 그래프에 사이클이 없다는 것의 필요충분조건 스케줄 S와 동치인 직렬스케줄 S’의 생성 선행 그래프에 존재하는 모든 간선에 대해 위상정렬함으로써 얻어짐 Ch18 Fundamentals of Database Systems

32 18.5.2. 스케줄의 충돌 직렬가능성 테스트(cont.)
스케줄의 충돌 직렬성 테스트와 동치인 직렬스케줄 생성의 예제 transaction T1 read_item(X); write_item(X); read_item(Y); write_item(Y); transaction T2 read_item(Z); transaction T3 write_item(Z); (a) [그림 18.8] 직렬 가능성을 테스트 하는 예. (a) 트랜잭션의 읽기와 쓰기 연산들 Ch18 Fundamentals of Database Systems 2

33 18.5.2. 스케줄의 충돌 직렬가능성 테스트(cont.)
(b) transaction T1 transaction T2 transaction T3 read_item(Z); read_item(Y); write_item(Y); write_item(Z); read_item(X); write_item(X); [그림 18.8] 직렬가능성을 테스트하는 예 (b)트랜잭션 T1, T2, T3에 대한 스케줄 E Ch18 Fundamentals of Database Systems

34 18.5.2. 스케줄의 충돌 직렬가능성 테스트(cont.)
transaction T1 transaction T2 transaction T3 read_item(Y); read_item(Z); read_item(X); write_item(X); write_item(Y); write_item(Z); write_item(Y); read_item(Y); write_item(Y); write_item(X); [그림 18.8] 직렬 가능성을 테스트하는 예 (c)트랜잭션 T1, T2, T3에 대한 스케줄 F Ch18 Fundamentals of Database Systems 3

35 18.5.2. 스케줄의 충돌 직렬가능성 테스트(cont.)
스케줄 E에 대한 선행 그래프 (d) T2 T3 T1 Y X Y,Z 동치인 직렬 스케줄 없음 이유 사이클 X(T1 → T2), Y(T2 → T1) 사이클 X (T1→ T2), YZ(T2→ T3), Y(T3→ T1) 스케줄 F에 대한 선행 그래프 (e) T1 T2 T3 X,Y Y Y,Z 동치인 직렬 스케줄 T3 → T1 → T2 [그림 18.8] 직렬가능성을 테스트하는 예 (d) 스케줄 E에 대한 선행 그래프 (e) 스케줄 F에 대한 선행 그래프 Ch18 Fundamentals of Database Systems 4

36 18.5.2. 스케쥴의 충돌 직렬가능성을 위한 테스트(cont.)
동치인 직렬 스케줄을 두 개 가지는 스케줄을 나타내는 선행 그래프 T3 (f) T1 T2 동치인 직렬 스케줄 T3 → T2 → T1 T3 → T1 → T2 [그림 18.8] 직렬 가능성을 테스트하는 예(cont.) (f) 동치가 되는 두 개의 직렬 스케줄들을 갖는 선행 그래프 Ch18 Fundamentals of Database Systems

37 Fundamentals of Database Systems
직렬가능성의 용도 직렬가능한 스케줄에서는 어떠한 정확성도 잃지 않으면서 동시 실행의 장점을 얻을 수 있음 직렬 가능성 테스트의 문제점 직렬가능성을 보장하기 위해 스케줄의 연산들이 어떻게 인터리빙 될 것인가를 미리 결정하는 것은 실질적으로 불가능함 비실용적 (직렬가능이 아니라고 판명되면 그 스케줄의 영향을 반드시 취소시켜야 함) 직렬 가능성을 보장해주는 몇가지 동시성 제어 프로토콜 두 단계 로킹 방법 타임스탬프 순서화에 근거한 방법 데이타 항목의 여러 버전을 유지하는 것과 보증 또는 검증에 기반을 둔 방법 Ch18 Fundamentals of Database Systems

38 Fundamentals of Database Systems
뷰 동치와 뷰 직렬가능성 뷰 동치(View equivalence) 다음의 세 가지 조건이 만족되면 두 스케줄 S와 S＇은 뷰 동치이다. 동일한 트랜잭션들의 집합이 S와 S ’에 참여하고, S와 S’은 그 트랜잭션들이 가진 연산들과 동일한 연산들을 포함한다. S에 속한 Ti의 임의의 ri(X)연산에 대해서, 그 연산이 읽는 X의 값이 Tj에 속한 연산 wj(X)가 기록한 값(또는 그 스케줄이 시작되기 전에 X가 가지고 있던 원래 값)이라면 S’에 속한 Ti의 ri(X) 연산이 읽는 X 값에 대해서도 동일한 조건이 만족되어야 한다. 만약 S에서 Tk의 wk(Y) 연산이 항목 Y를 마지막으로 기록하는 연산이라면 S’ 에서도 Tk의 wk(Y) 연산이 항목 Y를 마지막으로 기록하는 연산이어야 한다. 뷰 동치와 뷰 직렬가능(View serializability) 스케줄 S가 어떤 직렬 스케줄과 뷰동치이면 S는 뷰 직렬가능 Ch18 Fundamentals of Database Systems

39 Fundamentals of Database Systems
뷰 동치와 뷰 직렬가능성(cont.) 읽지않고 쓰기(blind write) 충돌 직렬가능과 뷰 직렬가능 뷰 직렬가능의 정의가 충돌 직렬가능의 정의보다 덜 제한적임 : 충돌 직렬가능한 스케줄은 뷰 직렬가능하지만 그 역은 성립하지 않음 Ch18 Fundamentals of Database Systems

40 Fundamentals of Database Systems
스케줄 동치의 기타 유형 가끔 스케줄의 직렬가능성이 동시 실행의 정확성을 보장하기 위한 조건으로 너무 제약적일 때가 있다. 더하는 연산과 빼는 연산은 교환적이기 때문에 이들은 어떠한 순서로도 적용할 수 있으므로, 직렬 스케줄은 아니지만 정확한 스케줄들을 만드는 것이 가능하다. 최근에는 직렬가능성이 스케줄의 정확성을 결정하는 조건으로 너무 엄격하다고 여겨지는 경우들을 다루기 위해서 동시성 제어 이론을 확장하는 연구가 진행되고 있다. Ch18 Fundamentals of Database Systems

41 Fundamentals of Database Systems
18.6 SQL의 트랜잭션 지원 SQL 트랜잭션은 작업의 논리적인 단위이며 원자성이 보장된다. 하나의 SQL 문은 오류없이 실행을 완성하든지 혹은 실패하여 데이타베이스를 수정하지 않은 상태로 두든지 간에 관계없이 항상 원자적 수행단위로 간주된다. SQL에는 명시적인 Begin_Transaction 문이 없다. 트랜잭션은 특정한 SQL 문을 만났을 때 묵시적으로 시작한다. 모든 트랜잭션은 명시적인 종료(end) 문을 가져야 한다. 명시적인 종료 문이란 COMMIT 혹은 ROLLBACK이다. Ch18 Fundamentals of Database Systems

42 Fundamentals of Database Systems
18.6 SQL의 트랜잭션 지원(cont.) 모든 트랜잭션들은 속성들을 가지고 있으며, 이러한 속성들은 SQL2에서 SET TRANSACTION 문으로 명시된다. 이러한 속성들에는 접근 모드(access mode), 진단 영역 크기(diagnostic area size), 고립성 등급(isolation level)이 있다. 예제: EXEC SEQ SET TRANSACTION READ WRITE DIAGNOSTIC SIZE 5 ISOLATION LEVEL SERIALIZABLE; Ch18 Fundamentals of Database Systems

43 Fundamentals of Database Systems
18.6 SQL의 트랜잭션 지원(cont.) 접근 모드 READ ONLY : 데이타 검색만이 가능하다. 고립성 등급을 READ UNCOMMITTED로 명시한다면 접근 모드는 READ ONLY로 된다. READ WRITE : 수정, 삽입, 삭제, 생성 명령을 실행할 수 있다. 고립성 등급을 READ UNCOMMITTED로 명시하지 않는 한 접근 모드의 디폴트는 READ WRITE이다. 진단 영역 크기 : DIAGNOSTIC SIZE n 정수 값 n을 지정하며 이는 진단 영역에서 동시에 유지할 수 있는 조건들의 개수를 나타낸다. 이러한 조건들은 사용자에게 가장 최근에 실행한 SQL 문에 대하여 반환정보(즉, 오류 혹은 예외)를 제공한다. Ch18 Fundamentals of Database Systems

44 Fundamentals of Database Systems
18.6 SQL의 트랜잭션 지원(cont.) 고립성 등급 : ISOLATION LEVEL <isolation> <isolation>의 값 READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE 디폴트 고립성 등급은 SERIALIZABLE이며, 몇몇 시스템에서는 READ COMMITTED를 디폴트 고립성 등급으로 사용하고 있음 고립성 등급에 따르는 문제들 오손 읽기(dirty read) 반복할 수 없는 읽기(nonrepeatable read)    팬텀(phantom) 현상 Ch18 Fundamentals of Database Systems

45 Fundamentals of Database Systems
18.7 요 약 트랜잭션 처리의 개요 다사용자 DBMS 동시성 제어와 회복이 필요한 이유 트랜잭션과 트랜잭션의 성질 ACID 성질 트랜잭션의 스케줄과 직렬 가능성 스캐줄의 직렬 가능성 검사 방법과 연산의 동시 실행 SQL의 트랜잭션 지원 SQL 규격에서 지원되는 트랜잭션 개념들 Ch18 Fundamentals of Database Systems