제 6장 트랜잭션 트랙잭션 동시성 제어 복구

트랜잭션의 정의 하나의 논리적인 작업 단위 하나의 작업을 수행하기 위해 필요한 세부적인 연산들의 집합 하나의 트랜잭션 정의 예 Copyright  2002 by S.-g. Lee and J.-y. Chang

트랙잭션의 예 은행 학교 항공사 회사 A계좌에서 만원을 인출하라. A계좌에서 B계좌로 2만원을 이체하라. 97300-375 학번이 데이타베이스의 개념 과목을 수강 신청한다. 항공사 서울-LA간 #453편의 좌석이 남아 있는지 확인하라 #453편의 두 좌석을 예약하라. 회사 전 직원의 임금을 6% 인상하라. Copyright  2002 by S.-g. Lee and J.-y. Chang

트랜잭션의 필요성 다음과 같은 상황이 발생하지 못하도록 방지 잔액: 100원 - 100원 - 100원 = 0원 잔액 100원으로 200원을 인출했다 !!! Copyright  2002 by S.-g. Lee and J.-y. Chang

트랜잭션의 필요성 트랜잭션의 정의 정의된 트랜잭션의 실행 및 잘못된 상황 방지 전적으로 프로그래머의 권한이자 의무 DBMS의 책임 Copyright  2002 by S.-g. Lee and J.-y. Chang

트랜잭션의 특성 ACID 성질 원자성(atomicity) 일관성(consistency) 고립성(isolation) 트랜잭션에서 정의된 연산들은 모두 성공적으로 실행되던지 아니면 전혀 실행되지 않은 상태로 남아있어야 한다 (all-or-nothing). 일관성(consistency) 트랜잭션은 바른 데이타에서 잘못된 데이타를 만들어 내지 않는다. 고립성(isolation) 트랜잭션이 실행하는 도중에 다른 트랜잭션의 영향을 받아 잘못된 결과를 만들어서는 안된다. 지속성(durability) 트랜잭션이 성공적으로 수행되면 그 트랜잭션이 갱신한 데이타베이스의 내용은 영구적으로 저장된다. Copyright  2002 by S.-g. Lee and J.-y. Chang

원자성 예) A에서 B로 50을 계좌 이체 Begin transaction read(A,a) a = a-50 장애가 일어나면 복귀하던지 실행완료 상태가 되어야 함 Begin transaction read(A,a) a = a-50 write(A,a) read(B,b) b = b+50 write(B,b) End Transaction 장애 복귀 완료 Copyright  2002 by S.-g. Lee and J.-y. Chang

일관성 예) A에서 B로 50을 계좌 이체 Begin transaction read(A,a) a = a-50 write(A,a) End Transaction read(B,b) b = b+50 write(B,b) 이 상태는 첫째 트랜잭션 이 성공적으로 수행되었 으나 A와 B계좌의 합이 처음과 다름(일관성위배) Copyright  2002 by S.-g. Lee and J.-y. Chang

고립성 계좌 이체 도중 두 계좌의 합을 구하는 트랜잭션이 실행된다면? 이 상태에서 A와 B의 합을 구하는 다른 트랜잭션이 실행 Begin transaction read(A,a) a = a-50 write(A,a) read(B,b) b = b+50 write(B,b) End Transaction 이 상태에서 A와 B의 합을 구하는 다른 트랜잭션이 실행 실제와 다른 결과가 도출됨 완료가 안된 다른 트랜잭션에 의해 결과에 영향을 받음 Copyright  2002 by S.-g. Lee and J.-y. Chang

지속성 예) A계좌에서 100원을 인출. Begin transaction read (A,a) a = a-100 write(A,a) End Transaction *buffer flush* 트랜잭션은 완료되었지만 디스크에 반영되지 않았다. 트랜잭션이 완료가 되었으면 디스크에 곧바로 반영되거나 그렇지 않다 하더라도 추후에 그 결과를 복구할 수 있어야 함 장애 Copyright  2002 by S.-g. Lee and J.-y. Chang

트랜잭션의 상태 동작 : 트랜잭션이 시작되고 연산들이 정상적으로 실행중인 상태 부분완료 : 트랜잭션에 정의된 모든 연산의 실행이 끝난 상태 완료 : 트랜잭션이 성공적으로 종료된 상태 실패 : 트랜잭션이 완료되지 못하고 더 이상 실행되지 못하는 상태 중단 : 트랜잭션이 실패 한 후 실행되기 이전으로 복귀된 상태 부분완료 동작 실패 중단 완료 종료 복귀 (Rollback) Copyright  2002 by S.-g. Lee and J.-y. Chang

동시성 제어 다중 프로그래밍 여러 명의 사용자(트랜잭션)이 동시에 CPU를 공유 은행 업무 시스템 항공기 예약 시스템 하나의 트랜잭션이 끝나기 전에 다른 트랜잭션이 실행 가능 동시에 실행되는 트랜잭션들 간에 간섭 발생 가능성 실행 순서의 제어가 필요  동시성 제어가 필요함 Copyright  2002 by S.-g. Lee and J.-y. Chang

트랜잭션을 실행할 때 데이타베이스에 요구하는 대표적 연산 정의 read(x) 이름이 x인 데이타베이스 항목을 트랜잭션의 지역변수 x로 읽어 들인다 write(x) 지역변수 x에 저장된 값을 데이타베이스 항목 x에 저장한다. 디스크에 즉시 반영되지 않을 수 있음  버퍼(buffer)의 사용 Copyright  2002 by S.-g. Lee and J.-y. Chang

동시에 실행되는 두 트랜잭션의 예 Copyright  2002 by S.-g. Lee and J.-y. Chang

동시성 제어가 필요한 이유 갱신 분실 T1에 의해서 변경된 x값이 사라졌다 Copyright  2002 by S.-g. Lee and J.-y. Chang

동시성 제어가 필요한 이유 임시 갱신 T1의 복귀로 인해 T2가 읽은 x값은 효력을 잃었다. Copyright  2002 by S.-g. Lee and J.-y. Chang

동시성 제어가 필요한 이유 불일치 분석 x와 y는 같은 값을 가져야 한다는 데이타베이스의 일관성을 잃어버렸다. Copyright  2002 by S.-g. Lee and J.-y. Chang

동시성 제어가 필요한 이유 위의 문제들이 발생한 이유 다중 프로그래밍 환경에서 트랜잭션들 간에 끼어들기 방식으로 실행되기 때문 끼어들기 방식은 전적으로 운영체제의 권한 사용자는 어떠한 순서로 실행되는지 사전에 알 수 없음 가장 간단한 해결책 트랜잭션들을 순차적으로 실행  직렬 스케줄 Copyright  2002 by S.-g. Lee and J.-y. Chang

스케쥴(schedule) 스케쥴 직렬 스케쥴(serial schedule) 트랜잭션의 각 연산들이 실행되는 순서 직렬 스케쥴(serial schedule) 각 트랜잭션들의 명령들이 끼어들기 방식으로 실행되지 않고 연속적으로 실행되는 스케쥴 다중 프로그래밍의 장점을 포기 병행 수행을 보장하면서 직렬 스케줄과 동일한 결과를 얻는 방법이 필요 직렬 가능한 스케쥴(serializable schedule) 직렬 스케줄이 아니지만 직렬 스케줄과 실행 결과가 동일한 스케줄 Copyright  2002 by S.-g. Lee and J.-y. Chang

스케쥴(schedule) 직렬 스케줄의 예 Copyright  2002 by S.-g. Lee and J.-y. Chang

스케쥴(schedule) 직렬 가능한 스케줄의 판단방법 트랜잭션 T1, T2의 연산 C1과 C2가 연속적으로 수행될때 IF C1과 C2가 서로 다른 데이터 항복에 대한 연산이면 순서를 바꾸어도 연산결과가 불변함 IF C1과 C2가 서로 같은 데이터 항복에 대한 연산이면 C1과 C2가 모두 Read연산일 경우에만 순서를 바꿀 수 있음 둘 중 하나라도 Write연산이 포함되면 write이후의 Read연산에 영향이 미침 주어진 스케줄에 대해서 이러한 연산의 순서 바꾸기로 직렬 스케줄로 변환이 가능하면 직렬 가능한 스케줄이 됨 Copyright  2002 by S.-g. Lee and J.-y. Chang

스케쥴(schedule) … Copyright  2002 by S.-g. Lee and J.-y. Chang

스케쥴(schedule) 직렬 가능한 스케줄이 만들어지도록 실행순서를 제어해야함 잠금(locking) 트랜잭션의 순서를 강제로 제어 대부분의 DBMS에서 사용 타임스탬프(timestamp) 트랜젝션의 병행 실행을 최대한 보장 직렬 가능성에 위배될 가능성이 있으면 트랜잭션 취소 거의 사용 안 함 이책에서는 다루지 않음 Copyright  2002 by S.-g. Lee and J.-y. Chang

잠금 한 트랜잭션이 데이타를 읽는 동안 다른 트랜잭션이 그 데이타를 고치지 못하도록 하는 것 잠금이 설정된 데이터는 잠금을 설정한 트랜잭션 외에는 접금이 불가능하고 이 트랜잭셔만이 잠금을 해제할 수 있음 잠금 방법 트랜잭션 T1이 데이터 항목 X에 접금하려면 lock(X) 연산으로 잠금 설정 트랜잭션 T2가 lock(X)를 실행하면 T1이 잠금을 해제할 때까지 대기 T1이 unlock(x) 연산으로 잠금을 해제해야만 T2가 잠금을 설정하고 실행 계속 Copyright  2002 by S.-g. Lee and J.-y. Chang

잠금의 종류 두 트랜잭션이 동시에 read(x)를 수행한다면 잘못된 결과가 발생할 가능성이 없음 동시에 실행 가능 두 트랜잭션 중 하나라도 write(x)를 수행한다면 잘못된 결과가 발생할 가능성 있음 동시에 실행 불가능 read, write에 따라 잠금의 종류가 달라짐 Copyright  2002 by S.-g. Lee and J.-y. Chang

Read 연산을 할 때에는 Write 연산을 할 때에는 S-lock간에는 동시 잠금이 허용 동시잠금 가능 여부 공유잠금 (shared lock: S-lock) Write 연산을 할 때에는 배타잠금 (exclusive lock: X-lock) S-lock간에는 동시 잠금이 허용 나머지 경우에는 동시 잠금이 허용되지 않음 동시잠금 가능 여부 Copyright  2002 by S.-g. Lee and J.-y. Chang

잠금 규칙 트랜잭션은 데이타 항목 x에 대해서 read(x) 연산을 실행하기 전에 S-lock(x)나 X-lock(x)를 실행해야 한다. 트랜잭션은 데이타 항목 x에 대해서 write(x) 연산을 실행하기 전에 X-lock(x)를 실행해야 한다. 트랜잭션은 데이타 항목 x에 대해서 read(x)나 write(x) 연산의 실행이 끝나면 unlock(x)를 실행해야 한다. 트랜잭션은 데이타 항목 x에 대해서 S-lock(x)나 X-lock(x)를 실행한 경우에만 unlock(x)를 실행할 수 있다. Copyright  2002 by S.-g. Lee and J.-y. Chang

잠금을 설정한 트랜잭션의 예 Copyright  2002 by S.-g. Lee and J.-y. Chang

잠금과 직렬 가능한 스케줄 잠금을 설정한 트랜잭션의 예 Copyright  2002 by S.-g. Lee and J.-y. Chang

가능한 트랜잭션 실행 예1 (직렬 가능하지 않은 스케줄) 잠금 설정만으로 직렬 가능한 스케줄이 보장되지 않음 추가적인 제약이 필요함 Copyright  2002 by S.-g. Lee and J.-y. Chang

가능한 트랜잭션 실행 예2 (직렬 가능하지 않은 스케줄) Copyright  2002 by S.-g. Lee and J.-y. Chang

Unlock을 트랜잭션의 마지막에 실행하면? Copyright  2002 by S.-g. Lee and J.-y. Chang

가능한 트랜잭션 실행 예 Copyright  2002 by S.-g. Lee and J.-y. Chang

2단계 잠금 규약(2-Phase Locking Protocol: 2PL) 직렬 가능한 스케쥴을 보장하는 규약이며 두 단계로 구성된다. 확장 단계(growing phase) 트랜잭션을 잠금을 설정할 수 있다. lock-S를 얻을 수 있다. lock-X를 얻을 수 있다. lock-S 를 lock-X로 바꿀 수 있다. 트랜잭션은 잠금을 해제할 수 없다.. 축소단계(shrinking phase 트랜잭션은 잠금을 해제할 수 있다. lock-S를 해제할 수 있다. lock-X를 해제할 수 있다. lock-X를 lock-S로 바꿀 수 있다. 잠금을 설정하지 못한다. Copyright  2002 by S.-g. Lee and J.-y. Chang

2단계 잠금 규약(2-Phase Locking Protocol: 2PL) Copyright  2002 by S.-g. Lee and J.-y. Chang

2단계 잠금 규약을 준수한 트랜잭션의 실행 예 T1, T2 모두 2PL을 준수 T1 실행 후에 T2을 실행 하는 직렬 스케줄과 동일 한 결과를 도출함 직렬 가능한 스케줄이 됨 Copyright  2002 by S.-g. Lee and J.-y. Chang

2PL의 장단점 2PL은 직렬가능한 스케줄을 보장 필요충분조건은 아님 (역은 성립하지 않음) Copyright  2002 by S.-g. Lee and J.-y. Chang

2PL의 장단점 병행성을 최대한 보장하는 방법은 아님 알고리즘적으로 단순하여 많이 사용됨 교착 상태는 해결하지 못함 최적의 방법은 사실상 불가능 알고리즘적으로 단순하여 많이 사용됨 적은 노력으로 동시성 제어 가장 많이 사용되는 규약 교착 상태는 해결하지 못함 이를 위한 여러 가지 추가적 제약 방법들이 있음 예) 그림 6-16 Copyright  2002 by S.-g. Lee and J.-y. Chang

잠금 단위 Lock(X) 단위가 크면? 단위가 작으면 예) 단위가 튜플이면.. 예) 단위가 릴레이션이면.. 해결책 튜플? 디스크 블록? 릴레이션? 데이타베이스? 단위가 크면? 동시성 수준이 낮아짐 제어가 간단함 단위가 작으면 동시성 수준이 높아짐 관리가 복잡 예) 단위가 튜플이면.. 하나의 릴레이션에 대해 여러 트랜잭션이 실행 가능 Lock을 튜플 별로 관리하므로 복잡함 예) 단위가 릴레이션이면.. 서로 다른 튜플에 대한 연산이라도 두 트랜잭션이 동시에 실행 불가능 릴레이션에 대해 하나의 lock연산만이 필요하므로 단순 해결책 상황에 따라 여러 단계로 lock의 단위 정하고 필요에 따라 수준을 결정 Copyright  2002 by S.-g. Lee and J.-y. Chang

복구(Recovery) 장애(failure)가 발생하였을 때 장애 이전의 일관된 상태로 복원하는 과정 트랜잭션 실행 도중 장애가 발생하면 트랜잭션 이전 상태나 이후 상태로 복구하여야 원자성이 보장됨 장애의 종류 트랜잭션 장애 트랜잭션 내의 논리적 오류나 잘못된 입력 데이타, 또는 시스템내의 자원부족 등으로 인해 트랜잭션이 중단 시스템 장애 정전이나 하드웨어의 결함으로 인해 작동이 중단되는 경우 주기억장치와 같은 휘발성 저장장치의 내용이 분실 또는 손상 로그를 이용해 복구 미디어 장애 디스크와 같은 비휘발성 저장장치의 일부 또는 전체가 손상된 상태 백업, 미러링 , RAID 등을 이용해 복구 Copyright  2002 by S.-g. Lee and J.-y. Chang

복구(Recovery) 복구의 기본 원리 데이터의 중복(redundancy) Back-up file 복제(mirroring) 로그(log) 복제(mirroring) Copyright  2002 by S.-g. Lee and J.-y. Chang

데이터 저장 방식 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그 데이타베이스 변경에 대한 기록 모든 갱신에 대한 history을 기록 이것을 이용하여 트랜잭션 시작 이전상태로 복구하거나 완료된 트랜잭션의 갱신기록을 알 수 있음 로그에 기록되는 내용 트랜잭션의 시작 : <T start> T는 각 트랜잭션에 부여되는 식별자 트랜잭션의 완료 : <T commit> 트랜잭션의 중단 : <T end> 각 데이터 항목에 대한 갱신 : <T x v1 v2> X는 데이터 항목 V1은 갱신 이전 값 V2는 갱신 이후값 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그 그림 6-18의 트랜잭션이 실행되면 기록되는 로그의 예 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그 로그 우선기록 규약(write-ahead logging protocol) 트랜잭션이 갱신한 데이타 항목을 데이타베이스에 기록하기 전에 로그 레코드에 우선 기록되어야 함 트랜잭션이 실행 도중 실패했을 때 이미 기록된 변경내용을 취소 시키려면 로그 레코드에 그 기록이 남아있어야 함 이미 완료된 트랜잭션에 대해서 데이타베이스의 갱신 내용을 디스크에 반영할 때도 필요 데이타베이스의 갱신 기록이 반영이 되지 않고 주기억장치의 버퍼에만 있을때 장애가 발생한다면 복구 가능 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그를 이용한 복구 기법 복구를 위한 기본적 연산 복구 방법 UNDO REDO 갱신된 값을 그 이전의 값으로 되돌려 REDO 쓰기 연산을 실행하였지만 실제로 디스크로 반영이 안되었을 경우 이를 재실행 복구 방법 지연 갱신(deferred database modification)을 기반으로 한 복구 기법 즉시 갱신(immediate database modification) 을 기반으로 한 복구 기법 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그를 이용한 복구 기법 지연 갱신을 이용한 복구 기법 트랜잭션의 수행이 성공적으로 끝날 때까지 갱신 내용을 디스크에 저장하지 않고 지연 트랜잭션이 실행되는 동안에는 갱신된 내용이 주기억장치의 버퍼와 로그에만 기록 트랜잭션이 완료될 때까지는 버퍼의 내용이 디스크로 저장되지 못한 트랜잭션의 실행 과정 ①   트랜잭션 T가 시작되면 <T start>가 로그에 기록 ②  T가 데이타 항목 x에 대해 쓰기 연산을 수행하면 로그에 그 내용이 기록되고 버퍼에 있는 x에 그 내용이 반영 ③  최종적으로 T가 모든 연산에 대한 실행을 마치면 T는 부분 완료 상태가 되고 로그 레코드 <T commit>가 로그에 기록 ④   <Ti commit>가 로그에 기록되면 T는 완료 상태가 되어 종료 ⑤   버퍼에 저장된 x는 이후 적당한 시기에 디스크에 반영 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그를 이용한 복구 기법 지연 갱신을 이용한 복구 기법 트랜잭션이 완료되었다는 것은 로그에 <T commit>이 기록되었다는 것을 의미 UNDO연산이 불필요 로그 레코드에 저장될 갱신 기록에서 이전 값은 저장할 필요가 없고 갱신 이후 값만을 저장 복구 과정(NO-UNDO/REDO 알고리즘 ) ①  로그 화일의 처음부터 기록을 순차적으로 검색 ② 로그에 저장된 각 트랜잭션의 로그 레코드에 대해서 <T commit>이 저장되었으면 REDO연산을 수행 ③ <T commit>이 없는 나머지 트랜잭션에 대한 로그 레코드들은 무시 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그를 이용한 복구 기법 지연 갱신을 이용한 복구 기법 초기값 X = 100 Y = 200 장애 복구 과정 T1에 대해서 REDO T2는 무시 최종적으로 x=20, y = 200 장애 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그를 이용한 복구 기법 즉시갱신을 이용한 복구 기법 트랜잭션 실행중에 변경된 데이타를 저장하는 것을 허용하나 단, 로그가 디스크에 쓰여지기 전에 데이타를 저장하는 것은 허용하지 않는다. 트랜잭션의 완료되었다는 것은 로그에 <T commit>이 기록되었다는 것으로 판단 Redo와 더불어 완료되지 못한 트랜잭션에 대해서는 원래의 값으로 돌려놓는 UNDO연산이 필요 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그를 이용한 복구 기법 즉시갱신을 이용한 복구 기법 복구 과정(UNDO/REDO알고리즘) ① 로그 화일이 기록된 마지막부터 반대 방향으로 순차적으로 검색 ② 로그에 저장된 각 트랜잭션의 로그 레코드에 대해서 <T start>가 있으나 <T commit>이 없으면 이 트랜잭션의 갱신 기록에 대해서 UNDO연산을 수행 ③  로그 화일의 처음부터 순차적으로 검색 ④ 로그에 저장된 각 트랜잭션의 로그 레코드에 대해서 <T commit>이 저장되었으면 이 트랜잭션의 갱신 기록에 대해서 REDO연산을 수행 Copyright  2002 by S.-g. Lee and J.-y. Chang

로그를 이용한 복구 기법 즉시갱신을 이용한 복구 기법 로그 레코드의 예 장애 시점 이전에 이 내용들이 모두 디스크에 반영이 되었다면 시스템의 재가동되었을 때 디스크의 x와 y에는 각각 0과 200이 저장 못한 T2에 대해서 UNDO를 실행하여 x의 값을 20으로 복구 T1에 대해서 REDO를 실행하여 x의 값을 다시 20으로 저장 Copyright  2002 by S.-g. Lee and J.-y. Chang

검사점 주기적으로 검사점을 둔 후 장애가 발생하면 검사점 이후의 로그만 검색한다. 로그와 디스크으 내용을 일치하는 과정 검사점을 두기 위한 작업(즉시 갱신의 경우) 1. 버퍼에 있는 모든 내용을 디스크에 저장한다. 2. 디스크의 로그에 <Checkpoint>를 기록한다. 검사점 이후에 실행과정에서 장애가 발생하면 그 이후에 완료된 트랜잭션이나 장애 시점까지 아직 완료되지 않은 트랜잭션에 대해서만 UNDO와 REDO연산을 실행 Copyright  2002 by S.-g. Lee and J.-y. Chang

검사점 복구 과정 -<Checkpoint> 위치 검색 -<Checkpoint>이전에 완료된 트랜잭션은 무시 -T1 : 무시 -T2 : REDO -T3 : REDO -T4 : UNDO -최종: x = 20 y = 30 z = 30 Copyright  2002 by S.-g. Lee and J.-y. Chang

참고자료 - 잠금의 구현 DBMS 구성요소에서 트랜잭션 관리기내에 잠금 관리기(Lock Manager)가 별도로 존재 다른 프로세스와 독립적으로 운용 잠금 관리기는 잠금 테이블(Lock Table)이란 자료구조를 유지하고 잠금 설정과 요청, 대기에 관련된 정보를 유지함 잠금 테이블은 일반적으로 주기억 장치에 데이터 항목에 대한 해쉬 테이블로 관리됨 Copyright  2002 by S.-g. Lee and J.-y. Chang

참고자료 - 잠금의 구현 해쉬 테이블 데이터 항목 대기 T23을 동시설정 (T1, T8: S-lock T2: X-lock) I912에 대한 잠금 설정 데이터 항목 대기 Copyright  2002 by S.-g. Lee and J.-y. Chang