11. Transaction - 트랜잭션

  트랜잭션(Transaction)

• 트랜잭션 : 일관성을 유지하는 단위
• 항공기 예약, 은행, 신용 카드 처리, 대형 할인점 등에서는 대규모 데이터베이스를 수백, 수천 명 이상의 사용자들이 동시에 접근한다.
• 많은 사용자들이 동시에 데이터베이스의 서로 다른 부분 또는 동일한 부분을 접근하면서 데이터베이스를 사용한다.
• 동시성 제어(Concurrency control)
• 동시에 수행되는 트랜잭션들이 데이터베이스에 미치는 영향은 이들을 순차적을 수행하였을 때 데이터베이스에 미치는 영향과 같도록 보장하는 것
• 다수 사용자가 데이터베이스를 동시에 접근하도록 허용하면서 데이터베이스의 일관성을 유지한다.
• 회복(Recovery) : 데이터베이스를 갱신하는 도중에 시스템이 고장 나도 데이터베이스의 일관성을 유지한다.
• 반드시 회복과 동시성 제어가 함께 제공되어야 한다.

데이터베이스 시스템 환경에서 흔히 볼 수 있는 몇 가지 응용의 예 1

사원이 500명 재직하고 있는 회사에서 모든 사원의 급여를 6% 인상하는 연산을 데이터베이스의 EMPLOYEE 릴레이션에서 수행한다. 이때 500명 전원의 급여가 수정되거나 한 명의 급여도 갱신되지 않도록 DBMS가 보장해야 한다.

320번째 사원까지 수정한 상태에서 컴퓨터 시스템이 다운된 후에 재기동되었을 때 DBMS는 어떻게 대응해야 하는가?

-> 예전 상태로 돌려보낸다. 이후 다시 질의한다.

DBMS가 추가로 정보를 유지하지 않는다면 DBMS가 재기동된 후에 어느 직원의 투플까지 수정되었는가를 알 수 없다. 

-> 로그(log) 유지 필요

데이터베이스 시스템 환경에서 흔히 볼 수 있는 몇 가지 응용의 예 2

은행 고객은 자신의 계좌에서 다른 계좌로 송금할 수 있다. 정미림은 자신의 계좌에서 100,000원을 인출하여 안명석의 계좌로 이체하려고 한다. 고객들의 계좌 정보가 CUSTOMER 릴레이션에 들어 있다.

두 개의 UPDATE 문을 사용하여, 하나의 UPDATE문에서는 정미림의 잔액을 100,000원 감소시키고, 또 다른 UPDATE문에서는 안명석의 잔액을 100,000원 증가시킨다.

첫 번째 UPDATE문을 수행한 후에 두 번째 UPDATE문을 수행하기 전에 컴퓨터 시스템이 다운되면 재기동한 후에 정미림은 보냈으나 안명석은 받지 못한 상태가 될 수 있다.

대응책으로, 두 개의 UPDATE문을 둘 다 완전하게 수행되거나 한 UPDATE문도 수행되어서는 안되도록, 즉 하나의 단위(트랜잭션)처럼 동작하도록 DBMS가 보장해야 한다.

기본적으로 각각의 SQL문이 하나의 트랜잭션으로 취급된다.

BEGIN TRANSACTION

[sql1]

[sql2]

...

END TRANSACTION

두 개 이상의 SQL문들을 하나의 트랜잭션으로 취급하려면 사용자가 이를 명시적으로 표시해야 한다.

데이터베이스 시스템 환경에서 흔히 볼 수 있는 몇 가지 응용의 예 3

여행사에서 고객의 요청에 따라 항공기를 예약하려고 한다. 아래의 응용 프로그램은 고급 프로그래밍 언어로 작성한 프로그램 내에서 세 개의 SQL문을 내포시킨 것이다. 이 응용 프로그램에서는 두 개의 릴레이션을 사용한다.

FLIGHT 릴레이션은 각 항공기편마다 FNO(항공기편 번호), DATE(출발일), SOURCE(출발지), DESTINATION(목적지), SEAT_SOLD(팔린 좌석 수), CAPACITY(총 좌석수) 등의 애트리뷰트를 갖는다.

FLIGHT(FNO, DATE, SOURCE, DESTINATION, SEAT_SOLD, CAPACITY)

RESERVED 릴레이션은 각 예약 고객마다 FNO(항공기 번호), DATE(출발일), CUST_NAME(고객 이름), SPECIAL(비고) 등의 애트리뷰트를 갖는다.

RESERVED(FNO, DATE, CUST_NAME, SPECIAL)

FLIGHT 릴레이션에서 고객이 원하는 날짜의 항공기편에 빈 좌석이 남아 있으면 팔린 좌석수를 1만큼 증가시키고, RESERVED 릴레이션에 예약 고객에 관한 투플을 삽입한다.

   

만일 SQL2 를 수행하고 SQL3를 수행하기 전에 컴퓨터 시스템이 다운되고 재기동한 한다면? 

-> 위의 세 개의 SQL문이 모두 완전하게 수행되거나 하나도 수행되어서는 안되도록, 즉 하나의 단위(트랜잭션)처럼 DBMS가 취급해야 한다.

DBMS는 각 SQL문의 의미를 알 수 없으므로 하나의 트랜잭션으로 취급해야 하는 SQL문들의 범위를 사용자가 명시적으로 표시해야 한다.

 

  트랜잭션의 특성(ACID 특성)

• 원자성(Atomicity)

- 한 트랜잭션 내의 모든 연산들이 완전히 수행되거나 전혀 수행되지 않음(all or nothing)을 의미한다.

- DBMS의 회복 모듈은 시스템이 다운되는 경우에, 부분적으로 데이터베이스를 갱신한 트랜잭션의 영향을 취소함(nothing 보장)으로써 트랜잭션의 원자성을 보장한다.

- 완료된 트랜잭션이 갱신한 사항은 트랜잭션의 영향을 재수행함(all 보장)으로써 트랜잭션의 원자성을 보장한다.

• 일관성(Consistency)

- 어떤 트랜잭션이 수행되기 전에 데이터베이스가 일관된 상태를 가졌다면 트랜잭션이 수행된 후에 데이터베이스는 또 다른 일관된 상태를 가진다.

- 트랜잭션이 수행되는 도중에는 데이터베이스가 일시적으로 일관된 상태를 갖지 않을 수 있다. (일시적 불일치 상태)

• 고립성(Isolation)

- 한 트랜잭션이 데이터를 갱신하는 동안 이 트랜잭션이 완료되기 전에는 갱신 중인 데이터를 다른 트랜잭션들이 접근하지 못하도록 해야 한다.

- 다수의 트랜잭션들이 동시에 수행되더라도 그 결과는 어떤 순서에 따라 트랜잭션들을 하나씩 차례대로 수행한 결과와 같아야 한다.

- DBMS의 동시성 제어 모듈이 트랜잭션의 고립성을 보장한다.

- DBMS는 응용들의 요구사항에 따라 다양한 고립 수준(isolation level)을 제공한다.

• 지속성(Durability)

- 일단 한 트랜잭션이 완료되면 이 트랜잭션이 갱신한 것은 그 후에 시스템에 고장이 발생하더라도 손실되지 않는다.

- 완료된 트랜잭션의 효과는 시스템이 고장난 경우에도 데이터베이스에 반영된다.

- DBMS의 회복 모듈은 시스템이 다운되는 경우에도 트랜잭션의 지속성을 보장한다

  트랜잭션의 완료(Commit)와 철회(Abort)

• Commit : 트랜잭션에서 변경하려는 내용이 데이터베이스에 완전하게 반영되는 것
• SQL 구문 : COMMIT WORK
• Abort : 트랜잭션에서 변경하려는 내용이 데이터베이스에 일부만 반영된 경우에는 원자성을 보장하기 위해서, 트랜잭션이 갱신한 사항을 트랜잭션이 수행되기 전의 상태로 되돌리는 것
• SQL 구문 : ROLLBACK WORK

  트랜잭션이 성공하지 못하는 경우

• 시스템(사이트) 고장 : 중앙 처리 장치, 주기억 장치, 전원 공급 장치 등이 고장난 경우
• 트랜잭션 고장 : 트랜잭션이 수행되는 도중에 철회되는 경우
• 매체 고장 : 디스크 헤드, 디스크 컨트롤러 등이 고장 나서 보조 기억 장치의 전부 또는 일부 내용이 지워진 경우
• 통신 고장
• 자연적 재해
• 부주의 또는 고의적인 고장

  동시성 제어(Concurrency Control)

• 대부분의 DBMS들은 다수 사용자용이며, 여러 사용자들이 동시에 동일한 테이블을 접근하기도 한다.
• DBMS의 성능을 높이기 위해 여러 사용자의 질의나 프로그램들을 동시에 수행하는 것이 필수적이다.
• 동시성 제어 기법 : 여러 사용자들이 다수의 트랜잭션들을 동시에 수행하는 환경에서 부정확한 결과를 생성(트랜잭션들 간의 간섭)하지 않도록 한다.
• 직렬 스케줄(Serial Schedule) : 여러 트랜잭션들의 집합을 한 번에 한 트랜잭션씩 차례대로 수행한다.
• 비직렬 스케줄(Non-serial Schedule) : 여러 트랜잭션들을 동시에 수행한다. (실제로는 매우 빠른 속도로 번갈아가며 수행하여 동시에 수행하는 것처럼 보임)
• 직렬가능(Serializable) : 비직렬 스케줄의 결과가 어떤 직렬 스케줄의 수행 결과와 동등함을 의미한다.
• 데이터베이스 연산

- Input(X) : 데이터베이스 항목 X를 포함하고 있는 블록을 주기억 장치의 버퍼로 읽어들인다.

- Output(X) : 데이터베이스 항목 X를 포함하고 있는 블록을 디스크에 기록한다.

- read_item(X) : 주기억 장치 버퍼에서 데이터베이스 항목 X의 값을 프로그램 변수 X로 복사한다.

- write_item(X) : 프로그램 변수 X의 값을 주기억 장치 내의 데이터베이스 항목 X에 기록한다.

• 동시성 제어 없이 다수의 트랜잭션을 동시에 수행할 때 생길 수 있는 문제

- 갱신 손실(lost update) : 수행 중인 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어 씀(overwrite)으로써 갱신이 무효가 되는 것

- 오손 데이터 읽기(dirty read) : 완료되지 않은 트랜잭션이 갱신한 데이터를 읽는 것

- 반복할 수 없는 읽기(unrepeatable read) : 한 트랜잭션이 동일한 데이터를 두 번 읽을 때 서로 다른 값을 읽는 것

갱신 손실의 예

하나의 SQL문은 DBMS 내에서 여러 개의 명령들로 나뉘어 수행된다. 다수 사용자 환경에서는 여러 사용자들이 동시에 요청한 트랜잭션의 명령들이 섞여서 수행될 수 있다. 트랜잭션 T1은 X에서 Y로 100,000을 이체하고, 트랜잭션 T2는 X의 값에 50,000을 더하려고 한다. 두 트랜잭션이 수행되기 전의 X와 Y의 초기값이 각각 300,000과 600,000이라고 가정하면 T1의 수행을 먼저 완료하고 T2의 수행을 완료하던지, T2의 수행을 먼저 완료하고 T1의 수행을 완료하던지 관계 없이 X의 최종값은 250,000, Y의 최종값은 700,000이 되어야 한다.

오손 데이터 읽기의 예

트랜잭션 T1이 정미림의 잔액을 100,000원 감소시킨 후에 트랜잭션 T2는 모든 계좌의 잔액의 평균값을 검색하였다. 그 이후에 T1이 어떤 이유로 철회되면 T1이 갱신한 정미림 계좌의 잔액은 원래 상태로 되돌아간다. 따라서 T2는 완료되지 않은 트랜잭션이 갱신한 데이터, 즉 틀린 데이터를 읽었다.

반복할 수 없는 읽기의 예

먼저 트랜잭션 T2는 모든 계좌의 잔액의 평균값을 검색하였다. 트랜잭션 T2가 완료되기 전에 트랜잭션 T1이 정미림의 잔액을 100,000원 감소시키고 완료되었다. 트랜잭션 T2가 다시 모든 계좌의 잔액의 평균값을 검색하면 첫 번째 평균값과 다른 값을 보게 된다. 동일한 읽기 연산을 여러 번 수행할 때 매번 서로 다른 값을 보게 될 수 있다. 즉, 한 트랜잭션이 동일한 데이터에 접근할 때 다른 트랜잭션에 의해 바뀐 값을 읽게 되는 것이다.

항공기 예약 트랜잭션의 예

여러 여행사에서 동시에 고객들의 요청에 따라 동일한 날짜에 출발하는 항공기의 빈 좌석 유무를 검사할 수 있다.

만일 두 여행사에서 각각 트랜잭션을 수행하는 과정에 SQL문의 수행 결과로 특정 항공기에 빈 좌석이 1개 남아 있다는 사실을 확인하고 동시에 두 여행사에서 SQL문을 수행하여 팔린 좌석수를 1만큼씩 증가시키고 자신의 고객의 정보를 항공사 데이터베이스에 입력하려 할 때 DBMS가 아무런 조치를 취하지 않으면, 1개 남은 좌석에 두 명의 고객이 배정되는 결과를 초래하게 된다.

  로킹(locking)

• 데이터 항목을 로킹하는 개념은 동시에 수행되는 트랜잭션들의 동시성을 제어하기 위해서 가장 널리 사용되는 기법
• 로크(lock) : 데이터베이스 내의 각 데이터 항목과 연관된 하나의 변수
• 각 트랜잭션이 수행을 시작하여 데이터 항목을 접근할 때마다 요청한 로크에 관한 정보는 로크 테이블(lock table) 등에 유지된다.
• 트랜잭션에서 갱신 목적으로 데이터 항목을 접근할 때는 독점 로크(X-lock, eXclusive lock)를 요청한다. (독점 로크는 다른 트랜잭션이 접근하는 것을 막는다.)
• 트랜잭션에서 검색 목적으로 데이터 항목을 접근할 때는 공유 로크(S-lock, Shared lock)를 요청한다.
• 트랜잭션이 데이터 항목에 대한 접근을 끝낸 후에 로크를 해제(unlock)한다.
• 로크를 해제할 때 로크 테이블에서 해당 로크의 레코드(로크 정보)가 삭제된다.

  2단계 로킹 프로토콜(2-phase locking protocol)

• 로크를 요청하는 것과 로크를 해제하는 것이 2단계로 이루어진다.
• 로크 확장 단계가 지난 후에 로크 수축 단계에 들어간다.
• 일단 로크를 한 개라도 해제하면 로크 수축 단계에 들어간다.
• 로크 확장 단계(1단계) : 트랜잭션이 데이터 항목에 대하여 새로운 로크를 요청할 수 있지만 보유하고 있던 로크를 하나라도 해제할 수 없다.
• 로크 수축 단계(2단계) : 보유하고 있던 로크를 해제할 수 있지만 새로운 로크를 요청할 수 없다. 로크를 조금씩 해제(다른 트랜잭션이 로크를 걸 수 있음)할 수도 있고, 트랜잭션이 완료 시점에 이르렀을 때 한꺼번에 모든 로크를 해제(일반적인 방식)할 수도 있다.
• 로크 포인트(lock point) : 한 트랜잭션에서 필요로 하는 모든 로크를 걸어놓은 시점

A=100, B=200일 때,

T1 실행 후, T2 실행 : A=202, B=402

T2 실행 후, T1 실행 : A=201, B=401

직렬 스케줄의 경우 : A=202, B=401

 

* 로크를 일찍 해제하는 방식은, 직렬 가능한 스케줄을 생성하지 못한다.

비직렬 스케줄과 직렬 스케줄의 결과가 일치하지 않는다. *

  데드록(Deadlock)

• 2단계 로킹 프로토콜에서는 데드록이 발생할 수 있다.
• 데드록은 두 개 이상의 트랜잭션들이 서로 상대방이 보유하고 있는 로크를 요청하면서 기다리고 있는 상태(자원을 기다리는 상태)를 말한다.

1) T1이 X에 대해 독점 로크를 요청하여 허가받음

2) T2가 Y에 대해 독점 로크를 요청하여 허가받음

3) T1이 Y에 대해 공유 로크나 독점 로크를 요청하면, 로크가 해제될 때까지 기다림

4) T2가 X에 대해 공유 로크나 독점 로크를 요청하면 로크가 해제될 때까지 기다림

• 데드록을 해결하기 위해서는 데드록을 방지하는 기법이나, 데드록을 탐지하고 희생자(우선순위가 낮은 트랜잭션 또는 최근에 시작된 트랜잭션)를 선정하여 데드록을 푸는 기법 등을 사용한다.
• 데드록이 발생할 필요 충분 조건

- Mutual exclusion : 공유자원이 아닌 경우

- Hold and wait

- No preemption : 자원을 양보하지 않고, 상대방도 강제로 뺏지 못하는 경우

- Circular wait : waiting 상태를 유지하는 경우

 

  다중 로크 단위(Multiple Granularity)

• 대부분의 트랜잭션들이 소수의 투플들을 접근하는 데이터베이스 응용에서는 투플 단위로 로크를 해도 로크 테이블을 다루는 시간이 오래 걸리지 않는다.
• 트랜잭션들이 많은 투플을 접근하는 데이터베이스 응용에서 투플 단위로만 로크를 한다면 로크 테이블에서 로크 충돌을 검사하고, 로크 정보를 기록하는 시간이 오래 걸린다.
• 트랜잭션이 접근하는 투플의 수에 따라 로크를 하는 데이터 항목의 단위를 구분할 필요가 있다.
• 한 트랜잭션에서 로크할 수 있는 데이터 항목이 두 가지 이상 있으면 다중 로크 단위라고 말한다.
• 데이터베이스에서 로크할 수 있는 단위로는 데이터베이스, 릴레이션, 디스크 블록, 투플 등이 있다. 데이터베이스 단위는 주로 백업 시 사용된다.
• 일반적으로 DBMS는 각 트랜잭션에서 접근하는 투플 수에 따라 자동적으로 로크 단위를 조정한다.
• 로크 단위가 작을수록 로킹에 따른 오버헤드가 증가한다.
• 로크 단위가 작을수록 동시성의 정도는 증가한다.

투플 단위의 로크

릴레이션 R에 속하는 디스크 블록 b1에 다섯 개의 투플 t1, t2, t3, t4, t5가 있다고 가정하자. 또한 트랜잭션 T1은 이 중에서 투플 t1과 t4를 갱신하고, 트랜잭션 T2는 투플 t2를 검색한다고 가정하자. 만일 로크 단위가 투플이라면 두 트랜잭션이 접근하는 투플들이 서로 상이하므로 해당 투플에 로크를 걸고 두 트랜잭션이 동시에 수행될 수 있다.

블록 단위의 로크

위의 상황에서, 트랜잭션 T1은 블록 단위, T2는 투플 단위로 로크를 하는 경우에, 먼저 T1이 블록 b1에 대해 독점 로크를 요청하여 허가를 받으면 이 블록에 들어 있는 투플 다섯 개에도 모두 독점 로크가 걸린다. 그 다음에 트랜잭션 T2가 투플 t2에 대해 공유 로크를 요청하면 트랜잭션 T1이 로크를 풀 때까지 기다려야 한다.

  팬텀 문제(Phantom Problem)

• 두 개의 트랜잭션 T1과 T2가 EMPLOYEE 릴레이션에 대해서 아래와 같은 순서대로 수행된다고 가정해보자.
• 트랜잭션 T1은 EMPLOYEE 릴레이션에서 1번 부서에 근무하는 사원들의 이름을 검색하는 동일한 SELECT문을 두 개 포함하고, 트랜잭션 T2는 1번 부서에 근무하는 사원 투플을 한 개 삽입하는 INSERT문을 포함한다.
  

• 시간 1에 트랜잭션 T1의 SELECT문이 수행되면 1번 부서에 근무하는 사원들의 이름이 검색된다.
• 시간 2에 트랜잭션 T2의 INSERT문이 수행되면 EMPLOYEE 릴레이션에 1번 부서에 근무하는 홍길동 사원에 대한 레코드가 삽입된다.
• 시간 3에 트랜잭션 T1의 두 번째 SELECT문이 수행되면 추가된 투플까지 포함되어 기존의 정보 + 1명의 정보가 출력된다. 즉, “반복할 수 없는 읽기”가 발생하였다.
• 한 트랜잭션 T1에 속한 첫 번째 SELECT문과 두 번째 SELECT문의 수행 결과가 다르게 나타나는 현상을 팬텀 문제라 한다.
• 로킹에도 불구하고 나타난 반복할 수 없는 읽기는 투플 단위의 로크로는 해결할 수 없다.
• 인덱스 단위의 로크의 경우, T1이 인덱스 로크를 풀 때까지 T2는 독점 로크를 걸지 못하게 된다.
• 팬텀 문제의 해결책 : 인덱스 수준에서 로킹하는 것이 필요하다.

  회복의 개요

• 회복의 필요성

- 어떤 트랜잭션 T를 수행하는 도중에 시스템이 다운되었을 때 T의 수행 효과가 디스크의 데이터베이스에 일부 반영되었을 수 있다. (원자성 X)

- 어떻게 T의 수행을 취소하여 원자성을 보장할 것인가?

- 트랜잭션 T가 완료된 직후에 시스템이 다운되면 T의 모든 갱신 효과가 주기억 장치로부터 디스크에 기록되지 않았을 수 있다. (지속성 X)

- 어떻게 T의 수행 결과가 데이터베이스에 완전하게 반영되도록 할 것인가?

- 디스크의 헤드 등이 고장 나서 디스크의 데이터베이스를 접근할 수 없다면 어떻게 할 것인가?

• 여러 응용이 주기억 장치 버퍼 내의 동일한 데이터베이스 항목을 갱신한 후에 디스크에 기록함으로써 성능을 향상시키는 것이 중요하다.
• 버퍼의 내용이 디스크에 기록하는 횟수를 가능하면 최대한 줄이는 것이 일반적이다.
• 버퍼가 꽉 찼을 때 또는 트랜잭션이 완료될 때(강제기록) 버퍼의 내용이 디스크에 기록될 수 있다.
• 트랜잭션이 버퍼에는 갱신 사항을 반영했지만 버퍼의 내용이 디스크에 기록되기 전에 고장이 발생할 수 있다.
• 고장이 발생하기 전에 트랜잭션이 완료 명령(COMMIT)을 수행했다면 회복 모듈은 이 트랜잭션의 갱신 사항을 재수행(REDO)하여 트랜잭션의 갱신이 지속성을 갖도록 해야 한다.
• 고장이 발생하기 전에 트랜잭션이 완료 명령(COMMIT)을 수행하지 못했다면 원자성을 보장하기 위해서 이 트랜잭션이 데이터베이스에 반영했을 가능성이 있는 갱신 사항을 취소(UNDO)해야 한다.
• 단, 갱신한 값이 아닌 현재 값이 블록에 있는 상태라면 취소나 재수행을 할 수 없다.

  저장 장치의 유형

• 주기억 장치와 같은 휘발성 저장 장치에 들어 있는 내용은 시스템이 다운된 후에 모두 사라진다.
• 디스크와 같은 비휘발성 저장 장치에 들어 있는 내용은 디스크 헤드 등이 손상을 입지 않는 한 시스템이 다운된 후에도 유지된다.
• 안전 저장 장치(stable storage) : 모든 유형의 고장을 견딜 수 있는 저장 장치
• 두 개 이상의 비휘발성 저장 장치가 동시에 고장날 가능성이 매우 낮으므로 비휘발성 저장 장치에 두 개 이상의 사본을 중복해서 저장함으로써 안전 저장 장치를 구현한다.

  재해적 고장과 비재해적 고장

• 재해적 고장

- 디스크가 손상을 입어서 데이터베이스를 읽을 수 없는 고장

- 재해적 고장으로부터의 회복은 데이터베이스를 백업해 놓은 자기 테이프를 기반으로 한다.

• 비재해적 고장

- 그 이외의 고장

- 대부분 회복 알고리즘들은 비재해적 고장에 적용된다.

- 로그를 기반으로 한 즉시 갱신, 로그를 기반으로 한 지연 갱신, 그림자 페이징(shadow paging) 등 여러 회복 알고리즘들이 있다.

- 대부분 상용 DBMS에서 로그를 기반으로 한 즉시 갱신 방식을 사용한다.

  로그를 사용한 즉시 갱신

• 즉시 갱신에서는 트랜잭션이 데이터베이스를 갱신한 사항이 주기억 장치의 버퍼에 유지되다가 트랜잭션이 완료되기 전이라도 디스크의 데이터베이스에 기록될 수 있다.
• 데이터베이스에는 완료된 트랜잭션의 수행 결과뿐만 아니라 철회된 트랜잭션의 수행 결과도 반영될 수 있다.
• 트랜잭션의 원자성과 지속성을 보장하기 위해 DBMS는 로그(Log)라고 부르는 특별한 파일을 유지한다.
• 데이터베이스의 항목에 영향을 미치는 모든 트랜잭션의 연산(갱신 연산)들에 대해서 로그 레코드를 기록한다.
• 각 로그 레코드는 로그 순서 번호(Log Sequence Number, LSN)로 식별된다.
• 주기억 장치 내의 로그 버퍼에 로그 레코드들을 기록하고 로그 버퍼가 꽉 찰 때 디스크에 기록한다.
• 메인 메모리에 데이터베이스 버퍼보다 로그 버퍼를 항상 먼저 디스크로 내보낸다.
• 로그는 데이터베이스 회복에 필수적이므로 일반적으로 안전 저장 장치에 저장된다.
• 이중 로그(dual logging) : 로그를 두 개의 디스크에 중복해서 저장하는 것
• 각 로그 레코드가 어떤 트랜잭션에 속한 것인가를 식별하기 위해서 각 로그 레코드마다 트랜잭션 ID를 포함시킨다.
• 동일한 트랜잭션에 속하는 로그 레코드들은 연결 리스트로 유지된다.
  

[ 디스크와 메모리 내 버퍼의 읽기/쓰기 관계 ]

고장이 나서 재기동하면, 고장 전 로그 버퍼에 있는 로그 레코드가 로그 파일에 기록되었을 때

로그 파일에 있는 새 값을 가지고 연산한 결과를 데이터베이스 버퍼에 다시 기록한다.

트랜잭션의 로그 레코드

아래의 두 트랜잭션 T1과 T2를 고려해 보자. T1 다음에 T2가 수행되고, 데이터베이스 항목 A, B, C, D, E의 초기값은 각각 100, 300, 5, 60, 80이라고 가정한다. 

이 두 트랜잭션을 수행하면 아래의 오른쪽 표와 같은 로그 레코드들이 생성된다. 오른쪽 표에서 2번 로그 레코드는 트랜잭션 T1이 데이터베이스 항목 B를 이전값 300에서 새값 400으로 갱신했음을 나타낸다. 일단 이 로그 레코드가 디스크의 로그에 기록된 후에는 B가 새값으로 고쳐진 주기억 장치의 버퍼가 언제든지 디스크의 데이터베이스에 기록될 수 있다.

  트랜잭션의 완료점(Commit Point)

• 한 트랜잭션의 데이터베이스 갱신 연산이 모두 끝나고 데이터베이스 갱신사항이 로그에 기록된 시점
• DBMS의 회복 모듈은 로그를 검사하여 로그에 [Trans-ID, start] 로그 레코드와 [Trans-ID, commit] 로그 레코드가 모두 존재하는 트랜잭션들은 재수행(REDO)한다. (all 보장)
• [Trans-ID, start] 로그 레코드는 로그에 존재하지만 [Trans-ID, commit] 로그 레코드가 존재하지 않는 트랜잭션들은 취소(UNDO)한다. (nothing 보장)
• 재수행 과정

1) 로그 버퍼에서 디스크(로그 파일)로 저장했던 로그 레코드를 회복 모듈이 참조한다.

2) 디스크에서 DB버퍼로 읽어온 기존값을 새 값으로 갱신한다.

3) 이후 디스크에 다시 기록한다.

[ 위의 예시의 트랜잭션의 완료점에 따른 작업과 결과 ]

  로그 먼저 쓰기(Write-Ahead Logging, WAL)

• 트랜잭션이 데이터베이스를 갱신하면 주기억 장치의 데이터베이스 버퍼에 갱신 사항을 기록하고, 로그 버퍼에는 이에 대응되는 로그 레코드를 기록한다.
• 만일 데이터베이스 버퍼가 로그 버퍼보다 먼저 디스크에 기록되는 경우에는 로그 버퍼가 디스크에 기록되기 전에 시스템이 다운되었다가 재기동되었을 때 주기억 장치는 휘발성이므로 데이터베이스 버퍼와 로그 버퍼의 내용은 전혀 남아 있지 않는다.
• 로그 레코드가 없어서 이전값을 알 수 없으므로 트랜잭션의 취소가 불가능하다.
• 따라서 데이터베이스 버퍼보다 로그 버퍼를 먼저 디스크에 기록해야 한다.

  체크포인트(Checkpoint)

• 시스템이 다운된 시점으로부터 오래 전에 완료된 트랜잭션들이 데이터베이스를 갱신한 사항은 이미 디스크에 반영되었을 가능성이 크다.
• DBMS가 로그를 사용하더라도 어떤 트랜잭션의 갱신 사항이 주기억 장치 버퍼로부터 디스크에 기록되었는가를 구분할 수 없다.
• 따라서 DBMS는 회복시 재수행할 트랜잭션의 수를 줄이기 위해서 주기적으로 체크포인트를 수행한다.
• 체크포인트 시점에는 주기억 장치의 버퍼 내용이 디스크에 강제로 기록되므로, 체크포인트를 수행하면 디스크 상에서 로그와 데이터베이스의 내용의 일치하게 된다.
• 체크포인트 작업이 끝나면 로그에 [checkpoint] 로그 레코드가 기록된다.
• 일반적으로 체크포인트를 10~20분마다 한 번씩 수행한다.
•  체크포인트를 할 때 수행되는 작업

- 수행 중인 트랜잭션들을 일시적으로 중지시킨다. 회복 알고리즘에 따라서는 이 작업이 필요하지 않을 수 있다.

- 주기억 장치의 로그 버퍼를 디스크에 강제로 출력한다.

- 주기억 장치의 데이터베이스 버퍼를 디스크에 강제로 출력한다.

- [checkpoint] 로그 레코드를 로그 버퍼에 기록한 후 디스크에 강제로 출력한다.

- 체크포인트 시점에 수행 중이던 트랜잭션 ID도 [checkpoint] 로그 레코드에 함께 기록된다.

- 일시적으로 중지된 트랜잭션의 수행을 재개한다.

• 체크포인트를 하지 않았을 때

위의 이미지는 시스템이 다운된 후(tfail 이후)에 재기동되었을 때 회복 모듈이 디스크에 저장되어 있는 로그 레코드를 조사하여 얻어낸 그림이라 가정하자. 트랜잭션 Ta, Tb, Tc는 재수행, 트랜잭션 Td는 commit 되지 않았으므로 취소한다.

• 체크포인트를 했을 때

트랜잭션 Ta는 무시, 트랜잭션 Tb, Tc는 재수행, Td는 취소

 

  데이터베이스 백업과 재해적 고장으로부터의 회복

• 아주 드물지만, 데이터베이스가 저장되어 있는 디스크의 헤드 등이 고장나서 데이터베이스를 읽을 수 없는 경우가 발생한다.
• 이런 경우에 데이터베이스를 회복하는 한 가지 방법은 주기적으로 자기 테이프에 전체 데이터베이스와 로그를 백업하고, 자기 테이프를 별도의 공간에 안전하게 보관하는 것이다.
• 사용자들에게 데이터베이스 사용을 계속 허용하면서, 지난 번 백업 이후에 갱신된 내용만 백업을 하는 점진적인 백업(incremental backup)이 바람직하다.

  Transact-SQL의 트랜잭션

• Transact-SQL : MSSQL 상에서의 SQL문으로, SQL2의 트랜잭션 구문을 지원한다.
• 사용자나 응용 프로그램은 트랜잭션 시작과 끝을 명시하여 트랜잭션을 제어한다.
• 즉, 트랜잭션의 범위를 조정할 수 있다.
• 한 트랜잭션은 임의의 SQL문으로 시작되거나, 트랜잭션의 시작을 표시하는 명시적인 키워드를 사용하여 시작된다.
• BEGIN TRANSACTION : 트랜잭션의 시작을 명시적으로 표시하기 위한 SQL문
• 한 트랜잭션의 끝을 표시하기 위해서 사용자는 COMMIT 또는 ROLLBACK문을 입력한다.
• 사용자가 정의한 트랜잭션 이름이 허용되는 것을 제외하면 COMMIT TRANSACTION문은 COMMIT WORK(데이터베이스에 갱신 사항을 완전하게 반영)와 동일한 기능을 가진다.
• Ex. 트랜잭션의 시작을 명시적인 키워드로 나타내지 않고, 두 개의 UPDATE문으로 이루어진 트랜잭션을 명시하였다. COMMIT 키워드를 사용하여 트랜잭션의 끝을 표시(하나의 트랜잭션으로 취급)하였다.

• 트랜잭션의 속성

- 만일 트랜잭션이 데이터베이스를 읽기만 한다면 트랜잭션이 읽기 전용임을 명시하여 DBMS가 동시성의 정도를 높일 수 있다.

- 만일 어떤 트랜잭션이 읽기 전용이라고 명시했으면 그 트랜잭션은 어떠한 갱신 작업도 수행할 수 없다. 아래와 같은 SQL문은 허용되지 않는다.

- 트랜잭션에 대해 SET TRANSACTION READ WRITE를 명시하면, SELECT, INSERT, DELETE, UPDATE문을 모두 수행할 수 있다.

  고립 수준

• SQL2에서 사용자가 동시성의 정도를 몇 가지로 구분하여 명시할 수 있다.
• 고립 수준 : 한 트랜잭션이 다른 트랜잭션과 고립되어야 하는 정도
• 고립 수준이 낮으면 동시성은 높아지지만 데이터의 정확성(일관성)은 떨어진다.
• 고립 수준이 높으면 데이터가 정확해지지만 동시성이 저하(동시에 수행될 수 없음)된다.
• 응용의 성격에 따라 허용 가능한 고립 수준을 선택함으로써 성능을 향상시킬 수 있다.
• 응용에서 명시한 고립 수준에 따라 DBMS가 사용하는 로킹 동작(로크를 얼마나 지속할 것인가)이 달라진다.
• 한 트랜잭션에 대해 명시한 고립 수준에 따라 그 트랜잭션이 읽을 수 있는 데이터에만 차이가 있다.
• 상용 DBMS에서 제공하는 몇 가지 고립 수준

READ UNCOMMITTED

- 가장 낮은 고립 수준

- 트랜잭션 내의 질의들이 공유 로크를 걸지 않고 데이터를 읽는다.

- 오손 데이터 읽기, 반복할 수 없는 읽기, 팬텀 문제 발생

- 갱신하려는 데이터에 대해서는 독점 로크를 걸고, 트랜잭션이 끝날 때까지 보유한다.

- 오손 데이터가 미미한 영향을 주는 경우(Ex. N이 큰 숫자일 때, N개의 정수들의 평균값 구하기)에 사용된다.

READ COMMITTED

- 트랜잭션 내의 질의들이 읽으려는 데이터에 대해서 공유 로크를 걸고, 읽기가 끝나자마자 로크를 해제한다. (2단계 로킹 프로토콜을 지키지 않음)

- 따라서 동일한 데이터를 다시 읽기 위해 공유 로크를 다시 걸고 데이터를 읽으면, 이전에 읽은 값과 다른 값을 읽는 경우가 생길 수 있다. (반복할 수 없는 읽기, 팬텀 문제 발생)

- 갱신하려는 데이터에 대해서는 독점 로크를 걸고, 트랜잭션이 끝날 때까지 보유한다.

- 이 고립수준은 Transact-SQL의 디폴트 고립 수준 (MSSQL 기준)

REPEATABLE READ

- 질의에서 검색되는 데이터에 대해 공유 로크를 걸고, 트랜잭션이 끝날 때까지 보유한다.

- 한 트랜잭션 내에서 동일한 질의를 두 번 이상 수행할 때 매번 같은 값을 포함한 결과를 검색하게 된다.

- 갱신하려는 데이터에 대해서는 독점 로크를 걸고, 트랜잭션이 끝날 때까지 보유한다.

- 레코드 수준의 로킹

- 2단계 로킹 프로토콜은 지키지만, 팬텀 문제를 해결하지 못한다.

SERIALIZABLE

- 가장 높은 고립 수준

- 질의에서 검색되는 투플들 뿐만 아니라 인덱스에 대해서도 공유 로크를 걸고 트랜잭션이 끝날 때까지 보유한다.

- 갱신하려는 데이터에 대해서는 독점 로크를 걸고 트랜잭션이 끝날 때까지 보유한다.

- SQL2의 디폴트 고립 수준

- 데이터베이스의 일관성을 높이지만, 동시성이 저하된다.