회복과 병행제어 - 회복

병행제어 : 수많은 사람들이 동시에 데이터베이스를 이용하는데 문제가 발생하지 않게 제어해주어야한다.

 

트랜젝션

- 하나의 작업을 수행하는데 필요한 데이터베이스 연산을 모은것.

- 작업 수행에 필요한 SQL문 집합

- 논리적 작업단위

- 장애발생시, 복구나 병행제어 작업을 위한 중요한 단위로 사용

- DB의 무결성과 일관성을 보장하기 위해서 작업 수행에 필요한 연산들을 하나의 트랜잭션으로 제대로 정의하고 관리해야함.

ex 1)

1번 작업과 2번 작업이 하나의 트랜잭션이다.

처리 순서는 중요하지 않지만, 두개의 update 명령이 정상적으로 실행되어야한다.

 

ex 2)

insert와 update 모두 정상적으로 실행되어야 상품주문 트랜잭션이 성공적으로 수행된다.

 

 

트랜잭션 특성

1. 원자성 => 회복기능

- all or nothing

- 트랜잭션의 연산들이 모두 정상적으로 실행 or 하나도 실행 X

- 트랜잭션 수행중 장애가 발생되면? => 실행한 연산을 모두 취소하고 DB를 트랜잭션 작업 전으로 복구

- 따라서 원자성 보장을 위해 회복 기능이 필요하다.

ex)

DB = A: 10000, B : 0

-계좌이체 트랜잭션-

(1) A계좌에서 5000원 인출

(2) B계좌에 5000원 입금

DB = A: 5000, B: 5000

 

1,2번 작업 중 장애가 발생하면 실행한 작업을 취소하고

DB = A: 10000, B : 0

상태로 되돌린다.

 

2. 일관성 => 병행 제어

- 트랜잭션이 성공적으로 수행된 후에도 DB가 일관된 상태를 유지해야한다.

ex)

DB = A: 10000, B : 0  ==> 합계 10000

-계좌이체 트랜잭션-

(1) A계좌에서 5000원 인출

(2) B계좌에 5000원 입금

DB = A: 5000, B: 5000  ==> 합계 10000

 

 

 

3. 격리성 => 병행 제어

- 수행 중인 트랜잭션이 완료될때까지, 다른 트랜잭션이 중간 연산 결과에 접근 불가

- 다른 트랜잭션과 연결 X, 독립됨

- 여러 트랜잭션이 동시에 수행되더라도, 순서대로 하나씩 수행되는 것처럼 정확하고 일관된 결과를 얻게 제어해야함

- 트랜잭션 서로 간섭 X

 

DB = A: 10000, B : 0

-계좌이체 트랜잭션-

(1) A계좌에서 5000원 인출 (2) B계좌에 5000원 입금

DB = A: 5000, B: 5000

 

여기서 B계좌에 1000원을 입금하는 다른 트랜잭션이 동시에 수행되어 (1)작업 후 수행되면

계좌입금 트랜잭션은 

-계좌입금 트랜잭션-

DB = A: 5000, B : 0

(1) B 계좌에 1000원 입금

DB = A: 5000, B : 1000

이 되어 두 트랜잭션이 완료되면

DB = A: 5000, B: 5000

DB = A: 5000, B : 1000

B의 계좌 잔액이 일치하지 않게 된다.

 

이러한 문제가 발생한 원인은 두 트랜잭션이 간섭을 일으키기 때문이다. 

따라서 계좌이체 트랜잭션이 끝날때 까지 기다린후, 계좌 입금 트랜잭션을 수행하면 같은 정보를 update하는 충돌이 발생하지 않는다.

즉, 간섭(충돌)이 되는 작업은 기다리고 아니면 동시수행한다.

 

 

 

4. 지속성 => 회복기능

- 트랜잭션이 성공적으로 완료된 후, 데이터베이스에 반영한 수행결과는 영구적이여야 함.

- 트랜잭션을 성공했으면 결과는 어떤일이 일어나더라도 유지되야한다.

(만약 트랜잭션을 성공했는데 시스템 다운으로 데이터가 날라가 결과에 데이터가 없으면 안된다.)

- 지속성의 보장을 위해선 장애 발생시 회복기능이 필요하다. (다시 복구)

 

 

 

트랜 잭션의 주요연산

1. commit - 트랜잭션이 성공적으로 수행되었음을 선언 (작업 완료)

=> 트랜잭션의 수행 결과가 데이터베이스에 반영되고 일관된 상태를 지속적으로 유지

2. rollback - 트랜잭션을 수행하는데 실패했음 선언 (작업 취소)

=> 지금까지 실행한 연산 결과를 취소하고 트랜잭션 수행 전의 데이터베이스로 상태 되돌림

 

 

트랜 잭션 상태

활동(수행중) -> 실패 -> rollback -> 철회

                 -> 부분완료 -> commit -> 완료

                 -> 부분완료 -> 실패 -> rollback -> 철회

 

활동

- 트랜잭션 수행중

 

부분 완료

- 트랜잭션의 마지막 연산이 실행을 끝낸 직후

 

완료

- 트랜잭션이 성공적으로 완료되어 commit 연산 실행한 상태, 결과를 DB에 반영, DB가 새로운 일관된 상태가 되고 트랜잭션 종료

 

실패

- 장애가 발생하여 트랜잭션 수행 중단된 상태

 

철회

- 트랜잭션 수행실패로 rollback 연산 실행한 상태,

- 지금까지 실행한 트랜잭션 연산을 모두 취소 후 트랜잭션 수행 전으로 DB되돌리고 트랜잭션 종료

- 철회 상태로 종료된 트랜잭션은 다시 수행되거나 폐기됨(상황에 따라)

 

장애 

휘발성 저장장치(소멸성 ) : 장애가 발생하면 저장된 데이터 손실

비휘발성 저장장치(비소멸성) : 장애가 발생해도 저장된 데이터 손실X, 저장장치 자체에 이상이 발생하면 데이터 손실

안정 저장장치 : 비휘발성 저장장치 이용, 데이터 복사본 여러개, 어떤 장애가 발생되도 데이터 손실X, 데이터 영구적 저장

 

트랜잭션 수행을 위해 필요한 데이터 이동 연산

응용프로그램 <-(read) - 메인메모리 <-(input) - 디스크

응용프로그램 ->(write) - 메인메모리 - (output)-> 디스크

read/write에 비해 input, output은 느리다.

트랜잭션에 read/write, input/output 연산이 포함된다.

 * 메인 메모리 데이터 베이스 = 디스크에 있다가 실행 시점에 전부 메인메모리로 가져와 사용한다. (규모가 작고 빠른 R/W시 사용한다.) (주로 read인 경우 - select)

 

디스크와 메인메모리 간의 데이터 이동연산은 block단위로 수행된다.(한번 읽는 시간이 느리므로 block 단위로 읽어옴)

 

 

회복(복구)를 위해 데이터베이스 복사본을 만드는 방법 => 데이터 중복!

덤프(dump) = 데이터베이스 전체를 다른 저장장치에 주기적으로 복사

로그(log) = 데이터베이스에서 변경 연산이 실행될 때마다, 데이터를 변경하기 이전값과 이후값을 별도의 파일에 기록

ex)

5일마다 backup을 한다면, 원본과 복사본 간에 시간차가 생긴다.

DB -(5일 시간차)-> 백업DB 

따라서, log를 사용 =>  5일전 복사본에 log로 변한 것을 적용하면 현재 DB상태가 된다.

 

 

회복(복구)를 위한 기본 연산

redo(재실행) = 가장 최근에 저장한 DB복사본을 가져온 뒤, log를 이용해서 복사본이 생성된 후의 모든 변경 연산을 재실행하여 장애 발생전의 DB상태로 복구

undo(취소) = log를 이용하여 실행된 모든 변경 연산을 취소하여 DB를 원래 상태로 복구(변경중이었거나, 변경된 내용만 신뢰성을 잃은 경우)

* log : 데이터를 변경하기 이전값과 변경한 후의 값을 기록한 파일, 레코드 단위로 트랜잭션 수행과 함께 기록

 

 

 

DB 회복(복구) 기법

- 로그 회복기법(즉시 갱신, 지연갱신 회복기법)

- 검사 시점 회복기법

- 미디어 회복기법

 

1. 로그 회복 - 즉시갱신 회복기법

- 트랜잭션 수행 중 데이터 변경 연산 결과를 DB에 즉시 반영

- 장애 발생에 대비하기 위해, 데이터 변경에 관한 내용을 log에 기록

- 데이터 변경 연산이 실행되면, log파일에 log 레코드를 기록하고 DB에 변경 연산 반영

- 장애 발생 시점에 따라 redo, undo 연산을 하여 DB 복구

바로 바로 반영한다.

 

1) 트랜 잭션이 완료되기 전에 장애가 발생

=> <T1, start>레코드는 있지만 commit레코드는 없다, 따라서 undo 연산

2) 트랜 잭션 완료 후 장애 발생

=> start, commit 로그 레코드 둘다 존재(정상적으로 실행되었다 판단), 따라서 redo 연산

1 => 일부이므로 undo 연산

2 => T2는 일부만 시행했으므로 undo, T1은 commit했으므로 redo

 

2. 로그 회복기법 - 지연갱신 회복

- 트랜 잭션 수행중 데이터 변경 연산 결과를 로그에만 기록

- 트랜 잭션이 부분완료된 후 로그에 기록된 내용을 DB에 한번에 반영 (commit을 만나면 DB에 반영)

- 트랜 잭션 수행중, 장애 발생하면 로그기록을 버리면 DB가 원래 상태 유지하게 됨 (DB에 반영은 나중에 하므로)

- log만 삭제하면 되므로 undo 연산은 필요없고, redo 연산만 사용한다.

- 로그 레코드에는 변경 이후 값만 기록하면 됨.

 

1) 트랜 잭션이 완료되기 전에 장애가 발생

=> <T1, start>레코드는 있지만 commit레코드는 없다, 따라서 기록된 log 버림

2) 트랜 잭션 완료 후 장애 발생

=> start, commit 로그 레코드 둘다 존재(정상적으로 실행되었다 판단) => 데이터베이스에 반영, 따라서 redo 연산

 

 

3. 검사시점 회복 기법

- 로그 기록 이용

- 일정 시간 간격으로 checkpoint생성

- checkpoint 시점이 되면 모든 log 레코드를 log에 기록 => 데이터 변경 내용을 안정저장창지에 기록 => 검사시점을 표시하는 <checkpoint L> 로그 레코드를 로그 파일에 기록

- 백업본 + log로 복구

- 백업후 시행한 것 모두 redo or undo 하여야한다 => 양이 많을 수 있음

- 따라서 일정 시간 마다 안정저장장치에 변경 내용 저장

- 마지막 check point 이후 작업만 처리한다. => 가장 최근 검사 시점 이후의 트랜잭션에만 회복 작업 수행(즉시 갱신 or 지연 갱신 복구)

- 백업후 시행한 것 모두 redo or undo 하여야한다 => log 전체를 회복기법 적용하는 것 보다 효율성이 좋음

- 검사 시점으로 작업 범위가 정해지므로 불필요한 회복 작업이 없어서 시간 단축

 

 

4. 미디어 회복 기법

- 디스크에 발생할 수 있는 장애에 대비

- 덤프(복사본) 이용 => 전체 DB내용을 일정 주기마다 다른 안전한 저장장치에 복사

- 디스크 장애 발생시 => 가장 최근에 복사해둔 덤프를 이용하여 장애 발생 이전의 DB 상태로 복구, 필요에따라 redo연산 수행