[DB] 로그 이용 회복 (데이터베이스 로그, 지연 갱신의 회복)

2023.06.02 - [DB] - [DB] 트랜잭션

[DB] 트랜잭션

 

 

로그 이용 회복

.

 

 

앞에서 설명한 트랜잭션에서 부분 완료 상태에 들어간 트랜잭션은

다시 실패되지 않는다는 것을 보장받을 때 완료 단계로 들어간다.

 

이러한 보장을 해주는 기법을 알아보자.

 

 

데이터베이스 로그

.

 

로그 레코드는 다음과 같은 유형으로 구분될 수 있다.

 

<Ti, Start>	트랜잭션 Ti가 실행 시작
<Ti, Xj, V1, V2>	트랜잭션 Ti가 데이터 아이템 Xj의 값을 V1에서 V2로 변경
<Ti, Commit>	트랜잭션 Ti가 실행 완료

 

 

로그는 데이터베이스가 갱신될 때마다 만들어지므로 대규모가 된다.

따라서 일정 시간마다 누적되는 로그를 보존시키기 위해 별도로 로그를 만들며,

이를 '보존 로그'라 하고 보통 테이프에 저장한다.

 

 

 

 

데이터베이스가 변경될 때 생성되는 로그는 트랜잭션이 철회되면

로그 레코드도 같이 삭제되어야 하는 경우도 있다.

 

이런 경우를 대비해 실행 중인 트랜잭션에 대한 로그를 디스크에 저장하고

이를 '온라인 로그'라 한다.

 

데이터베이스 자체도 디스크 붕괴나 시스템 장애로 인한 손실에 대비해

주기적으로 사본을 만들어 보존하는데

이를 '보존 데이터베이스'라 한다.

 

 

온라인 데이터베이스와 온라인 로그를 이용한 회복은

주로 트랜잭션 회복이나 시스템 회복을 위해 사용하고

 

장치 회복을 위해서는 보존 데이터베이스와 보존 로그가 사용된다.

 

 

지연 갱신의 회복

.

 

지연 갱신 회복 기법은 트랜잭션이 부분 완료될 때까지 모든 Output 연산을 지연시키고

데이터베이스의 변경을 로그에 전부 기록해 두었다가

한꺼번에 실행시킴으로써 트랜잭션의 원자성을 보장하려는 것이다.

 

만약 트랜잭션 실행 도중 시스템이 붕괴되거나 철회되면

로그에 있는 정보는 그냥 버리고 무시하면 된다.

따라서 Undo 연산은 필요가 없게 된다.

 

즉, 로그 레코드는 <트랜잭션 id, 데이터 아이템, 변경된 값>의 형식을 갖는다.

 

 

예로 트랜잭션들을 <T1, T2> 순으로 실행시킨다 가정하고,

A = 1000, B=2000, C=3000이라고 한다면 두 트랜잭션에 관한 로그는 아래와 같다.

 

 

 

 

그러나 데이터베이스와 로그에 출력하는 순서는 시간적으로 여러 가지가 있을 수 있는데

그 중 하나는 아래와 같이 A의 값은 로그 레코드 <T1, A, 900>이 일단 기록된 뒤어야 출력될 수 있다.

 

 

 

 

이러한 로그를 이용하면 정보의 손실을 가져온 장애를 처리할 수 있는데

그 회복 방법은 다음 Redo 프로시저를 이용한다.

 

 

 

 

이 Redo 연산은 여러번 실행한 것이나 한 번 실행한 것이나 결과는 동등하여야 한다.

 

 

 

이 성질은 Redo 작업 중 다시 장애가 일어나 Redo 연산을 또다시 실행하더라도

처음 한 번 시행한 결과와 동일하다는 것을 보장한다.

 

 

장애가 일어나면 회복 관리자는 어떤 트랜잭션이 재실행(Redo)되어야 하는가를 로그를 이용해 결정한다.

즉, 로그에 <Ti, Start> 레코드와 <Ti, Commit> 레코드가 모두 있는 트랜잭션에 대해서만 재실행한다.

그 이외의 트랜잭션은 새로운 트랜잭션으로 취급한다.

 

 

예로, 트랜잭션 T1과 T2는 <T1, T2> 순으로 실행되고 로그는 아래와 같다.

 

 

 

CASE1. 시스템이 T1의 Write(B)에 대한 로그 레코드를 기록한 직후 붕괴 (a)

 

이 상황(a)에서 시스템이 다시 작동되면 아무런 회복 조치가 필요 없다.

왜냐하면 로그에 <Ti, Commit> 레코드가 없기 때문이다.

 

 

CASE2. 시스템이 트랜잭션 T2의 Write(C)에 대한 로그 레코드를 기록한 직후 붕괴 (b)

 

시스템이 다시 작동되어 회복 작업을 시작하면 Redo(T1)만 실행하여야 한다.

트랜잭션 T1에 대한 <T1, Commit> 레코드만 있기 때문이다.

T2는 다시 처음부터 실행을 시작하여야 한다.

 

 

CASE3. 시스템이 <T2, Commit> 로그 레코드를 출력시킨 뒤에 붕괴 (c)

 

시스템이 회복 작업을 시작하면 T1과 T2의 Commit 레코드가 있다는 것을 확인하고

Redo(T1)과 Redo(T2)를 실행하게 된다.

이 두 회복 연산을 실행한 뒤에는 A, B, C는 각각 900, 2100, 2800이 된다.

 

 

CASE4. 시스템 장애에 대한 회복 작업 도중에 다시 시스템이 붕괴

 

어떤 트랜잭션은 Redo로 회복되었고 어떤 것은 회복되다 중지되었을 것이다.

이때 시스템이 다시 작동하면 회복 작업은 처음부터 다시 시작한다.

즉, 로그에 Commit 레코드가 있는 트랜잭션에 대해서 Redo를 다시 실행한다.

 

 

 

 

 

 

 

 

* 해당 글은 '데이터베이스 시스템' 책을 참고하여 작성하였습니다. 출처: 데이터베이스 시스템 (이석호)