14. 트랜잭션처리 -...

14. 트랜잭션 처리

인터넷과 Java 중심으로데이타베이스시스템이론과응용

이 장의 주요 내용

트랜잭션 개요

트랜잭션의 특성 (ACID) 원자성(Atomicity)

일관성(Consistency)

격리성(Isolation)

영속성(Durability)

트랜잭션 스케쥴 회복 가능 트랜잭션 스케쥴

직렬 가능 트랜잭션 스케쥴

직렬 가능 스케쥴을 보장하는 2PL


트랜잭션(transaction)이란?

한번에 모두 수행되거나 수행되지 않아야 하는 작업 수행의 논리적인 단위 예) 은행 데이타베이스를 기반으로 A계좌에서 B계좌로 10만원

이체하는 경우

원자 트랜잭션(atomic transaction)이라고도 함

선언의 단위 응용 설계자가 데이타베이스 연산들을 한데 모아 한 트랜잭션으

로 선언할 수 있음

명시 방법

Begin transaction과 end transaction 문으로 선언

하나의 응용 프로그램은 여러 개의 트랜잭션을 포함할 수 있음


트랜잭션이 가져야 할 특성

1. 원자성 (Atomicity) 트랜잭션 변경 연산은 모두 성공적으로 수행되거나 전혀 수행되

지 않아야 함

2. 일관성 (Consistency) 각 트랜잭션은 트랜잭션 실행 후에 데이타베이스를 하나의 일관

된 상태로 남겨 두어야 함

3. 격리성 (Isolation) 각각의 트랜잭션은 단독으로 실행된 것 같은 효과를 가짐

4. 영속성 (Durability) 트랜잭션이 성공적으로 완료되면 데이타베이스에 대한 변경은

영구적이어야 함 (15장에서 설명)

트랜잭션의 ACID 특성이라고 함


트랜잭션의 동작

한 트랜잭션의 수행은 데이타베이스 내의 객체를 접근하기 위한 일련이 요청들을 필요 읽기(read) 연산

쓰기(write) 연산

완료(commit) 연산

트랜잭션에 의해 수행된 갱신들을 데이타베이스에 영구적으로 반영

복귀(rollback) 연산

트랜잭션에서 SQL문들에 의해 수행된 모든 갱신을 취소함

따라서 데이타베이스 상태는 트랜잭션의 첫 구문이 실행되기 전의상태로 돌아가게 됨

트랜잭션 관리자 트랜잭션의 행동을 감시하고 각 동작의 실행이 가능한지를 결정

하는 소프트웨어

다양한 트랜잭션 프로토콜을 수행할 책임을 가짐


트랜잭션 동작 예제

SQL 문장

SQL 문의 동작

select balance from Customer where accountId=101

update Customer set balance = 0 where accountId = 101

동작식별자 동작의결과

AaccountId = 101를만족하는 Customer 객체의 balance

애트리뷰트읽어오기(read)

BaccountId = 101를만족하는 Customer 객체의 balance

애트리뷰트에쓰기(write)


단일 트랜잭션 시스템에서 트랜잭션의 원자성

단일 트랜잭션 시스템이란? 한번에 오직 하나의 트랜잭션만이 실행

이전 트랜잭션이 종료될 때까지 새로운 트랜잭션을 시작할 수없음

원자성을 지원하기 위한 연산 완료 (commit)

복귀 (rollback)


SQL 데이타베이스에 대한 트랜잭션 모드

자동 완료 모드(autocommit mode) 하나의 SQL 문장은 하나의 트랜잭션으로 수행

트랜잭션을 오픈하기 위한 묵시적인 요청으로 시작

자동적으로 완료 요청

SQL 문장의 실행이 실패 했을 경우 복귀

명시적 완료 모드(explicit commit mode) 여러 SQL 문장들을 단일 트랜잭션으로 실행

새로운 트랜잭션을 생성할 수 있도록 오픈 트랜잭션 문 실행

트랜잭션을 완료할 수 있도록 완료 트랜잭션 문 실행

응용이 트랜잭션의 취소를 요청하면 복귀 문장 실행


의사코드로 표현된 트랜잭션 예open transaction

/* “Star Wars” 영화의복사본을찾음 */

int video1 = select id of an available copy of "Star Wars“/* 찾은복사본을예약하기위해예약테이블에삽입, 만약복사본이없다면전체예약취소 */

if (video1 == null) rollback transaction

insert row into Reservation for video1

/* “Return of the Jedi” 영화의복사본을찾음 */

int video2 = select id of an available copy of "Return of the Jedi“/* 찾은복사본을예약하기위해예약테이블에삽입, 만약복사본이없다면전체예약취소 */



/* “The Empire Strikes Back” 영화의복사본을찾음 */

int video3 = select id of an available copy of "The Empire Strikes Back“/* 찾은복사본을예약하기위해예약테이블에삽입, 만약복사본이없다면전체예약취소 */



commit transaction


트랜잭션의 원자성 지원 트랜잭션 복귀

시스템이 트랜잭션에 의해 변경된 내역을 유지

변경 내역이나 이전의 상태를 임시 영역에 저장

Orcle8에서의 복귀 : immediate update 오픈된 각각의 트랜잭션에 대하여 롤백 세그먼트(RBS : rollback

segment) 엔트리를 포함하는 데이타 영역 포함

RBS 엔트리

트랜잭션으로 변경된 행들에 대한 이미지 집합

이미지 : 트랜잭션이 실행되기 이전의 값

트랜잭션 연산

오픈 : 새로운 RBS 엔트리 생성하고 트랜잭션과 연관시킴

완료 : RBS 엔트리를 삭제하고 변경 내용을 데이타베이스에 영구적으로 반영

복귀 : 변경된 모든 행들을 RBS엔트리로부터 가져와 복구


트랜잭션의 원자성 지원 [계속]

Oracle 8에서 트랜잭션 처리시 데이타베이스 상태

트랜잭션 T

T.A 쓰기 r

T.B 쓰기 s

T.C 읽기 s

T.D 읽기 u

Oracle8 데이타베이스서버

롤백세그먼트이전이미지

rs

데이타베이스테이블갱신된값

rstu


단일 트랜잭션 시스템에서 트랜잭션의 원자성

트랜잭션 복귀를 위해서는 시스템이 트랜잭션에 의해 변경된 내역을 유지 변경 내역이나 이전의 상태를 임시 영역에 저장

savepoint 연산 SQL 에서 지원

트랜잭션 내에 중간 복귀 시점 만듦

savepoint가 실행 되었을 당시의 상태로 복구하기 위해 사용

savepoint가 실행된 이후에 발생된 모든 갱신들만이 취소

SQL 문 예

savepoint A;

…

rollback to A;


일관성 보장

데이터 모델의 모든 제약 조건을 만족한다면 데이타베이스는 일관성 상태로 됨 제약조건 : 기본 키와 외래 키 제약 조건, 도메인 제약 조건, 비즈

니스 규칙 등

트랜잭션 모델 하에서 각 트랜잭션은 데이타베이스가 트랜잭션 실행 전에 일관된 상태였다면 적절한 완료 작업이후에도 일관된 상태로 유지할 수 있도록 설계되어야 함


일관성 보장의 예

예) 영화의 movieId를 변경 가정

Movie 테이블에 한 영화가 이미 추가되어 있고 Videotape 테이블에 복사본이 있음

movieId를 변경하기 위해 Movie 테이블과 Videotape 테이블을 모두 변경할 경우

Update Movie set movieId = 101045 where movieId = 101023

Update Videotape set movieId = 101045 where movieId = 101023→무결성 제약조건 위배


movieId 변경을 위한 해결 방법들 – 1/3

해결 방법 1

insert into Movie (movieId, title, genre, length, rating)

select 101045, title, genre, length, rating from Movie

where movieId=101023

update Videotape set movieId=101045 where movieId=101023

delete from Movie where movieId=101023



해결 방법 2 : Trigger 기능 이용 Trigger : 어떤 이벤트와 조건이 발생하였을 때, 데이타베이스 시

스템이 수행할 자동적인 동작을 명시하는데 사용

create trigger movieId_check

after update of movieId on (Movie)

referencing old row as orow

referencing new row as nrow

for each row

when

select V.movieId

from Videotape V

where V.movieId= orow.movieId

begin

update videotape

set movieId=nrow.movieId

where videotape.movieId=orow.movieId;

end;

• 이벤트 : - insert, delete, update 연산- before나 after 키워드다음에명시

• 조건 :- 조건이참이될때동작을실행- when 절로명시

• 실행동작 :- 조건을만족할때



해결 방법3 : 스키마의 on delete, on update 이용

create table videotape {

videoId int;

movieId int;

….

foreign key movieId references Movie

on delete cascade on update cascade }


병행 트랜잭션 처리

대부분 DBMS는 다수 사용자 시스템

데이타베이스에서 동시성 제어에 관한 대부분의 이론은병행 처리 형태(A) 의 동시성 관점에서 개발 예) 동시에 수행되는 트랜잭션을 처리하는 방법들

병렬처리(B)병행처리(A)


병행 트랜잭션 처리

별개의 응용들이 병행적으로 데이타베이스 서버에 서비스를 요청함으로 트랜잭션 연산의 중첩이 발생

트랜잭션의 격리성 원리1. 아직 완료되지 않은 응용에 의해 가해진 변경은 다른 트랜잭션

에게 보이지 않아야 한다.

2. 다른 트랜잭션에 의해 가해진 변경들을 (완료된 트랜잭션 조차도) 응용에서 알아 볼 수 있도록 해서는 안 된다.

실행중인 트랜잭션은 다른 트랜잭션의 간섭 없이 그 실행을 완료 할 수 있어야 함


간섭의 예

간섭 1

트랜잭션 T2에 의한 쓰기 연산이 트랜잭션 T1을 간섭함

예) 시간 1과 시간 3에서 같은 객체 r에 대해 서로 다른 값을 읽음

간섭 2

트랜잭션 T1에 의해 가해진 변경이 그 이후에 취소되었음에도트랜잭션 T2에 의해 부적절하게 읽혀짐

예) 시간 4에서 T1은 객체 u를 쓰고, 시간 5에서 T2는 그 값을 읽음

실행 스케쥴 : T1.A, T2.A, T1.B, T1.c, T2.B, T1.D

데이타베이스 서버

데이타베이스테이블

r

s

t

u

T2가

T1을

간섭

T1이

T2를

간섭

트랜잭션 T2

쓰기 rT2.A

동작

읽기 uT2.B

3

2

1

시간

4

5

6

트랜잭션 T1

읽기 rT1.B

읽기 rT1.A

동작

쓰기 uT1.C

복귀T1.D

3

2

1

시간

4

5

6


격리되지 않은 트랜잭션의 문제점 - 1/6

갱신 분실(lost update) 문제를 나타내는 스케줄 S1

S1: T3.A, T4.A, T3.B, T4.B, T3.commit, T4.commit

트랜잭션 T4의동작트랜잭션 T3의동작

T4.A balance2 = (select balance from

Customer where accountId = 101);

balance2 += 10.00;

T4.B update Customer set balance =

?balance2 where accountId = 101;



balance1 += 5.00;



시간 트랜잭션 T3 연산 트랜잭션 T4

1 T3.A 계정 101의잔액읽어오기 : $15

2 계정 101의잔액읽어오기 : $15 T4.A

3 T3.B 계정 101의잔액에쓰기 : $20

4 계정 101의잔액에쓰기 : $25 T4.B

5 T3.commit

6 T4.commit



오손 판독(dirty read) 문제를 나타내는 스케줄 S2

S2: T3.A, T3.B, T4.A, T3.rollback, T4.B, T4.commit

오손된 값 : 데이타베이스에 저장되지 않은 값



2 T3.B 계정 101의잔액쓰기 : $20


4 T3.rollback 계정 101의잔액복원: $15

5 계정 101의잔액쓰기 : $30 T4.B

6 T4.commit



T5 : 102 계좌 잔액에서 101고객의 계정으로 $10이체

T6 : 두 101과 102고객의 총 잔액을 계산


T6.A total = select sum(balance) from

Customer where accountId = 101

or accountId = 102;



balance1 += 10.00;



T5.C balance1 = (select balance from


balance1 -= 10.00;

T5.D update Customer set balance =




부정확한 요약(incorrect summary) 문제를 나타내는 스케줄 S3

S3: T5.A, T5.B, T6.A, T6.commit, T5.C, T5.D, T5.commit




3 계정 101의잔액읽어오기 : $25T6.A

계정 102의잔액읽어오기 : $15

4 T6.commit

5 T5.C 계정 102의잔액읽어오기 : $15

6 T5.D 계정 102의잔액에쓰기 : $5

7 T5.commit



반복 불가능(unrepeatable read)한 읽기 문제를 나타내는 스케줄 S4

S4: T7.A, T8.A, T8.commit, T7.B, T7.commit


T8.A update Customer set balance = 0.0

where accountId = 101;



T7.B balance2 = (select balance from




2 계정 101의잔액에쓰기 : $0 T8.A

3 T8.commit

4 T7.B 계정 101의잔액읽어오기 : $0

5 T7.commit



팬텀 문제를 나타내는 스케줄 S5

S5: T9.A, T10.A, T9.B, T10.rollback, T9.commit


1 T9.A 계정의잔액합계읽어오기 : $100

2 잔액이있는새계정 105의삽입 : $10 T10.A

3 T9.B 계정의잔액합계읽어오기 : $110

4 계정 105의제거 T10.rollback

5 T9.commit


T10.A insert into Customer (accountId,

balance, zipcode) values

(105, 10.00, 31101)

T9.A totalA = select sum(balance) from

Customer where zipcode = 31101

T9.B totalB = select sum(balance) from

Customer where zipcode = 31101


회복가능 트랜잭션 스케줄 - 1/2

트랜잭션 스케쥴이란? 트랜잭션들이 인터리브된 방식으로 병행 실행될 때, 여러 트랜잭

션들이 가진 연산들의 실행 순서

스케쥴 S에 참여하는 각 트랜잭션 Ti에 대해서 Ti의 연산들이 Ti

내에서와 동일한 순서로 스케쥴 S에 나타나야 함

동시 실행을 보장하기 위해서는 스케쥴의 형태에 어떤 제한을 둘 필요가 있음

회복 가능한 스케쥴 (recoverable schedule) 스케쥴 S안에 있는 어떤 트랜잭션 T가 읽은 값에 쓰기 연산을 수

행한 또 다른 트랜잭션 T’이 완료되기 전까지 트랜잭션 T가 완료되지 않는 스케줄


회복불가능 트랜잭션 스케줄 예

스케줄 S7은 회복 불가능 스케줄 S7: T3.A, T3.B, T4.A, T4.B, T4.commit, T3.rollback






5 T4.commit

6 T3.rollback 계정 101의잔액복구 : $15




balance2 += 10.00;





balance1 += 5.00;




회복가능 트랜잭션 스케줄 - 2/2

연쇄 복귀 (cascading rollback) 문제 연쇄 : S2에서 트랜잭션 T3의 복귀가 다시 또 다른 트랜잭션의

복귀 원인이 되는 상태

여러 트랜잭션이 복귀될 수 있기 때문에 연쇄 복귀는 많은 시간을 소비

이런 현상이 나타나지 않는 것을 보장하는 스케쥴들을 특성화하는 것이 중요

엄격한 스케줄 (strict schedule) 객체에 쓰기 연산을 수행한 트랜잭션이 완료되기 전까지 어떠한

트랜잭션도 그 객체를 읽거나 쓰지 못하는 것

항상 옳지는 않지만, 효율적 복귀 지원


엄격한 트랜잭션 스케줄 예

스케줄 S7-1은 엄격한 스케줄 S7-1: T3.A, T3.B, T3.commit, T4.A, T4.B, T4.commit

포함 관계




3 T3.commit



6 T4.commit

회복가능한스케쥴

연쇄복귀방지하는스케쥴

엄격한스케쥴


직렬가능 트랜잭션 스케줄 - 1/3

직렬 스케줄 (serial schedule) 서로 다른 트랜잭션 동작들이 인터리브 되지 않고 수행되는 스

케줄

즉, 한 트랜잭션의 모든 동작들은 다음 트랜잭션들의 동작보다 먼저수행

병행성 문제 발생 하지 않으나, 비현실적임

직렬 스케쥴처럼 동작하지만, 병행 실행을 수행하는 스케쥴이 필요



직렬가능 스케줄(serializable schedule) 직렬 스케줄과 동치(equivalent)인 병렬 스케줄

예) 충돌 동치(conflict equivalent)

두 스케줄의 충돌 동작 순서가 같은 것

충돌 (conflict) : 두 트랜잭션이 모두 어떤 데이타 객체를 참조하고 있고그 중 한 트랜잭션이 그 객체를 갱신할 때

스케쥴 1 (직렬가능스케쥴) 스케쥴 2 (직렬스케쥴)


직렬가능 스케쥴이 필요한 예

BigHit 비디오에 대한 PayStatement 생성 트랜잭션

/* TimeCard 테이블로부터 PayStatement 테이블에새로운값을삽입하고 TimeCard 테이블의paid를 true로표시 */

1. begin transaction;

2. insert into PayStatement

3. (ssn, hourlyRate, numHours, amountPaid, dataPaid)

4. select TimeCard.ssn, hourlyRate,

5. sum((endTime-startTime)*24) as hoursWorked,

6. sum((endTime-startTime)*24*hourlyRate) as amountPaid,

7. today

8. from TimeCard, HourlyEmployee

9. where TimeCard.ssn = HourlyEmployee.ssn and paid = false

10. group by TimeCard.ssn, hourlyRate;

11. update TimeCard set paid = true

12. where paid = false;

13. Commit transaction;



트랜잭션 관리의 목표 모든 트랜잭션을 직렬가능 스케줄로 실행

방법 1 : 직렬가능 하지 않은 스케줄 탐지 필요

방법 2 : 직렬가능 스케줄을 보장하는 트랜잭션들을 설계할 프로토콜 요구 (2PL)

방법 1 : 직렬 불가능 스케줄 검사 트랜잭션 관리 시스템이 스케줄에서 발생한 모든 충돌 발견

시스템은 오픈 트랜잭션의 동작에 대해 가능한 모든 직렬 스케줄의 기록을 유지

충돌이 발생할 때

충돌 동치 직렬 스케줄이 존재한다면, 직렬가능 스케줄

그렇지 않은 경우, 트랜잭션 복귀

실행하는데 비용이 많이 듦


직렬가능 스케줄을 보장하는 2단계 로킹 – 1/2

방법 2: 2단계 로킹(2PL:two-phase locking) 데이터 항목들을 로킹하는 기법을 사용

여러 트랜잭션이 그 항목들에 동시에 접근하는 것을 방지하기위함

로크 타입 읽기 로크(read lock)

비배타적이며 많은 판독자들 사이에 공유될 수 있음

객체를 읽을 수는 있으나 변경할 수는 없음

공유 로크 (shared lock) 라고도 함

읽기 로크를 차지하고 있는 한 트랜잭션은 다른 트랜잭션이 읽기 로크를 걸지 않은 경우에만 그 로크를 쓰기 로크로 상승 시킬 수 있음


직렬가능 스케줄을 보장하는 2단계 로킹 - 2/2

쓰기 로크(write lock)

배타적이며 트랜잭션이 객체를 변경할 수 있음

다른 어떠한 트랜잭션도 그 객체로부터 읽어 오거나 그 객체에 쓰기를 할 수 없음

배타 로크(exclusive lock)라고도 함

쓰기 로크는 어느 때라도 읽기 로크로 하강 될 수 있음

로크의 단위(granularity) 개별적으로 로크 될 수 있는 객체의 크기

예) 데이타베이스 레코드, 데이타베이스 레코드의 필드값, 디스크 블록, 파일 전체, 데이타베이스 전체

로크 단위가 작아질수록

병행성 증가, 오버헤드 증가

로크 단위가 커질수록

병행성 감소, 유지 로크 수 감소, 로크를 걸고 해제하는데 걸리는 시간 감소


2단계 로킹 프로토콜

2단계 로킹(2PL : two-phase locking) 프로토콜이란? 확장 단계(growing phase)

새로운 로크를 요청할 수 있음

공유 로크 -> 배타적 로크로 상승시킬 수 있음

축소 단계(shrinking phase)

로크를 해제

배타적 로크 -> 공유 로크로 하강시킬 수 있음

트랜잭션은 두 단계를 섞어서 사용할 수 없음

어떤 로크가 해제되면 그 트랜잭션은 새로운 로크를 요청 할 수없음.


2PL을 따르는 트랜잭션과 그렇지 않은 트랜잭션

트랜잭션 T13 : 2단계 로킹을 따르는 트랜잭션

트랜잭션 T14 : 2단계 로킹을 따르지 않는 트랜잭션

데이터 항목 : A, B, C, D, E

시간 트랜잭션 T13의로크동작 단계

T13.A A에대한읽기로크획득 : read_lock(A) 확장단계시작

T13.B B에대한읽기로크획득 : read_lock(B)

T13.C A의로크를쓰기로크로상승 : write_lock(A)

T13.D B에읽기로크해제 : unlock(B) 축소단계시작

T13.E A의로크를읽기로크로하강 : read_lock(A)

T13.F A에읽기로크해제 unlock(A)

시간 트랜잭션 T14의로크동작 단계

T14.A A에대한읽기로크획득 : read_lock(A) 확장단계시작

T14.B B에대한읽기로크획득 : read_lock(B)

T14.C B의읽기로크해제 : unlock(B) 축소단계시작

T14.D A의로크를쓰기로크로상승 : write_lock(B) 위반

T14.E B에대한읽기로크획득 : read_lock(B) 위반


2PL을 따르는 트랜잭션들 예

시간 T1 T2

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

read_lock(Y);

read_item(Y);

write_lock(X);

unlock(Y);

read_item(X);

X:=X+Y;

write_item(X);

unlock(X);

read_lock(X);

read_item(X);

write_lock(Y);

unlock(X);

read_item(Y);

Y=X+Y;

write_item(Y);

unlock(Y);


보수적 2단계 로킹

보수적 2단계 로킹 (conservative 2PL) 각 트랜잭션이 그 트랜잭션의 시작 초기에서 모든 로크를 얻도

록 하는 것

확장 단계 : 초기에 발생

축소 단계 : 전체 실행 동안

장점

트랜잭션이 충돌이나 교착상태가 전혀 일어나지 않고 실행이 완료될 수 있음

단점

트랜잭션은 사용 가능한 모든 객체에 로크를 걸어야 하므로, 병행성이 제한됨


엄격한 2단계 로킹

엄격한 2단계 로킹 (strict 2PL) 트랜잭션 끝까지 모든 로크를 유지하고 완료나 복귀 시에 해제

확장 단계 : 전체 실행 동안

장점

각 트랜잭션이 필요로 하는 것에만 로크를 설정

단점

교착상태가 일어날 가능성이 있음


엄격한 2PL로 실행되는 예 -1/2

1. begin transaction;

2. insert into PayStatement

3. (ssn, hourlyRate, numHours, amountPaid, dataPaid)

4. select TimeCard.ssn, hourlyRate,

5. sum((endTime-startTime)*24) as hoursWorked,

6. sum((endTime-startTime)*24*hourlyRate) as amountPaid,

7. today

8. from TimeCard, HourlyEmployee

9. where TimeCard.ssn = HourlyEmployee.ssn and paid = false

10. group by TimeCard.ssn, hourlyRate;

11. update TimeCard set paid = true

12. where paid = false;

13. Commit transaction;

PayStatement 트랜잭션


연산 설명

read_lock(TimeCard)

read_lock(HourlyEmployee)

TimeCard와 HourlyEmployee의 전체테이블에읽기로크획득

Select 절실행 select from TimeCard, HourlyEmployee 실행

Write_lock(PayStatement) PayStatement의전체테이블에쓰기로크획득

Insert 절실행 insert into PayStatement 실행

Write_lock(TimeCard) Timecard의로크를쓰기로크로상승

Update절실행 update TimeCard 실행

Unlock(TimeCard)

Unlock(PayStatement)

Unlock(HourlyEmployee)

모드로크해제

엄격한 2PL로 실행되는 예 -2/2


트랜잭션 처리에서 교착상태

교착상태(deadlock) 각 트랜잭션이 다른 트랜잭션에 의해 요청되는 있는 로크를 차

지하고 있는 경우

해결방법1. 교착상태에 빠진 트랜잭션 중에 하나를 철회하고 로크를 해제

2. 교착 상태 예방 프로토콜 사용

예) 자원의 우선 순위를 정해 놓고 모든 로크는 정의된 순서 내에서요청되도록 하는 것

SQL에서 시행하기 어려움


트랜잭션과 교착상태 스케줄 예제

교착상태를 나타내는 스케줄 S6

S6: T11.A, T12.A, T11.B, T12.B




T12.B update Customer set balance = 10.0




T11.B update Customer set balance = 0.0



1 T11.A 계정 101에대한배타적로크

2 계정 102에대한배타적로크 T12.A

3 T11.B 계정 102에대한배타적로크요청 : 봉쇄

4 계정 101에대한배타적로크요청 : 봉쇄 T12.B


교착 상태의 예

time T1 T2

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

read_lock(Y);

read_item(Y);

write_lock(X);

unlock(Y);

read_item(X);

X:=X+Y;

write_item(X);

unlock(X);

read_lock(X);

read_item(X);

write_lock(Y);

unlock(X);

read_item(Y);

Y=X+Y;

write_item(Y);

unlock(Y);

wait

wait

T1 T2

X

Y


SQL에서 묵시적 로킹 - 1/2

SQL에서 트랜잭션의 4가지 격리 레벨(isolation level) 미완료된 트랜잭션 읽기(read uncommitted)

오손판독, 반복불가능 읽기, 팬텀 문제가 발생

완료된 트랜잭션 읽기(read committed)

반복불가능 읽기, 팬텀 문제가 발생

반복가능 읽기(repeatable read)

팬텀 문제가 발생

직렬 가능(serializable)

오손판독, 반복불가능 읽기, 팬텀 문제 모두 예방


SQL에서 묵시적 로킹 - 2/2

SQL 표준 DBMS가 어떠한 레벨이든 지원할 수 있도록 허용

직렬가능 레벨이 기본 레벨로 제공

시스템이 트랜잭션을 더 높은 레벨로 상승시키는 것도 허용

직렬가능 레벨만을 지원하는 것도 허용

Oracle 8 완료된 트랜잭션 읽기와 직렬가능 레벨 제공

Set transaction 문

격리 레벨을 명시

트랜잭션이 데이타베이스를 갱신할 수 있는지의 여부를 나타냄

set transaction read only;

set transaction read write; /*기본값 */

set transaction isolation read committed; /* Oracle8에서기본값 */

set transaction isolation level serializable; /* SQL에서기본값 */

14. 트랜잭션처리 -...

Documents