제 19장 트랜잭션 처리를 위한 개념 경북대학교 컴퓨터과학과 박 영철.

Presentation on theme: "제 19장 트랜잭션 처리를 위한 개념 경북대학교 컴퓨터과학과 박 영철."— Presentation transcript:

1 제 19장 트랜잭션 처리를 위한 개념 경북대학교 컴퓨터과학과 박 영철

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

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

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

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

6 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); T1이 갱신한 결과를 잃어버리게 되어(덮어씀), 항목 X는 잘못된 값을 가진다. [그림 19.3] 동시 수행을 제어하지 않았을 때 발생할 수 있는 문제점들 (a) 갱신 손실 문제 Fundamentals of Database Systems

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

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

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

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

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

12 Fundamentals of Database Systems
트랜잭션의 상태와 부가적인 연산들 하나의 트랜잭션은 완전히 수행을 완료하거나 전혀 수행되지 않아야 한다. 회복 관리자(recovery manager)는 트랜잭션에 대해 다음과 같은 연산들이 적용된 시점을 유지해야 한다. 트랜잭션의 시작(BEGIN_TRANSACTION) 읽기 또는 쓰기(READ or WRITE) 트랜잭션의 종료(END_TRANSACTION) 트랜잭션의 완료(COMMIT_TRANSACTION) 복귀(ROLLBACK) 또는 철회(ABORT) Fundamentals of Database Systems

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

14 Fundamentals of Database Systems
시스템 로그 로그 (log) 데이타베이스 항목에 영향을 미치는 트랜잭션의 모든 연산들을 기록한다. 트랜잭션 실패를 회복하는데 필요하다. 디스크에 유지된다. 주기적으로 테이프 등에 백업(backup)한다. 로그에 기록되는 레코드들의 유형은 다음과 같다. 이 레코드들에서 T는 트랜잭션 식별자이다. [start_transaction, T] [write_item, T, X, old_value, new_value] [read_item, T, X] [commit, T] [rollback, T] [end, T] 연산 Do : 트랜잭션의 정상 수행 Undo (취소): log를 바탕으로 취소 연산의 수행  트랜잭션의 rollback Redo (재수행): log를 바탕으로 재수행 연산의 수행  recovery 시의 재수행 Fundamentals of Database Systems

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

16 Fundamentals of Database Systems
트랜잭션의 성질 트랜잭션은 다음의 ACID 성질을 가져야 하며 DBMS의 동시성 제어와 회복 기법을 통하여 유지된다. 원자성(Atomicity) 일관성 유지 (Consistency preservation) 고립성(Isolation) 지속성(Durability) 또는 영속성(permanency) Fundamentals of Database Systems

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

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

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

20 회복가능성을 근거로 한 스케줄의 특성화 (cont.)
연쇄복귀방지 (cascadeless or avoid cascading rollback) 완료된 트랜잭션이 쓴 항목만을 읽는다. 엄격한 스케줄(strict schedule) 마지막으로 X에 쓰기연산을 한 트랜잭션이 완료되거나 철회되기 전까지 다른 트랜잭션이 X를 읽지도 쓰지도 못한다. 회복과정 : 철회된 쓰기연산이 적용되기 전에 X가 가지고 있던 이전값(before image, BFIM)으로 복귀. Fundamentals of Database Systems

21 스케줄의 직렬가능성(Serializability)
직렬, 비직렬, 충돌 직렬가능 스케줄 스케줄의 충돌 직렬가능성 테스트 직렬가능성의 용도 뷰 동등성과 뷰 직렬가능성 스케줄 동치의 기타 유형 Fundamentals of Database Systems

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

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

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

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

26 Fundamentals of Database Systems
스케줄의 충돌 직렬가능성 테스트 스케줄 S의 충돌 직렬가능성 테스트 알고리듬. 스케줄 S에 참여하는 각 트랜잭션 Ti에 대해 선행 그래프(precedence graph)에 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가 직렬가능한 것은 선행 그래프에 사이클(cycle)이 없다는 것의 필요충분조건. 스케줄 S와 동치인 직렬스케줄 S’의 생성 선행 그래프에 존재하는 모든 간선에 대해 위상정렬함으로써. Fundamentals of Database Systems

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

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

29 스케줄의 충돌 직렬가능성 테스트(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); [그림 19.8] 직렬 가능성을 테스트하는 예 (c)트랜잭션 T1, T2, T3에 대한 스케줄 F Fundamentals of Database Systems 3

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

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

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

33 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는 뷰 직렬가능 Fundamentals of Database Systems

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

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

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

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

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

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