Database - 회복

회복의 필요성

• 어떤 트랜잭션 T를 수행하는 도중에 시스템이 다운되었을 때, T의 수행 효과가 데이터 베이스에 일부 반영되었을 수 있다. (원자성 보장 필요)
• 트랜잭션 T가 완료된 직후에 시스템이 다운되면 T의 모든 갱신 효과가 주기억 장치로부터 디스크에 기록되지 않을 수 있다. (수행 결과를 반영하여 지속성을 보장해야 한다)
• 디스크의 헤드 등이 고장 나서 디스크의 데이터베이스를 접근할 수 없다면 어떻게 할 것인가?

회복의 개요

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

저장 장치의 유형

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

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

재해적 고장

• 디스크가 손상을 입어서 데이터베이스를 읽을 수 없는 고장
• 재해적 고장으로부터의 회복은 데이터베이스를 백업해 놓은 자기테이프를 기반으로 한다.

비재해적 고장

• 그 이외의 고장
• 대부분의 회복 알고리즘들은 비재해적 고장에 적용된다.
• 로그를 기반으로 한 즉시 갱신, 로그를 기반으로 한 지연갱신, 그림자 페이징(shadow paging) 등의 여러 알고리즘이 있다.
• 대부분 상용 DBMS에서 로그를 기반으로 한 즉시 갱신 방식을 사용한다.

로그를 사용한 즉시 갱신

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

로그 레코드의 유형

[Trans-id, start]

• 한 트랜잭션이 생성될 때 기록되는 로그 레코드

[Trans-ID, X, old_value, new_value]

• 주어진 Trans-ID를 갖는 트랜잭션이 데이터 항목 X를 이전값(Old_value)에서 새 값(new_value)로 수정했음을 나타내는 로그 레코드
• Physical log record

  Logical log record

  • [trans-id, x, add, 7]과 같은 논리적인 연산 형태를 지니며 수행여부를 pageLSN으로 식별한다.

트랜잭션의 완료점

• 한 트랜잭션의 데이터베이스 갱신 연산이 모두 끝나고 데이터베이스 갱신 사항이 로그에 기록되었을 때
• DBMS의 회복 모듈은 로그를 검사하여 로그에 [Trans-ID, start] 로그 레코드와 [Trans-ID ,commit] 로그 레코드가 모두 존재하는 트랜잭션들을 재수행한다.
• [Trans-ID, start]로그 레코드는 로그에 존재하지만 [Trans-ID ,commit]로그 레코드가 존재하지 않는 트랜잭션들은 취소한다.

로그 버퍼

• append only / 로그 버퍼가 꽉 차면 디스크에 저장(FLUSH)하며, 저장된 버퍼에는 재사용이 가능하다.

로그 먼저 쓰기(WAL : Write – Ahead Logging)

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

PageLSN (wal을 구현하기 위해서)

• 로그 버퍼의 내용을 디스크에 저장할 때, 항상 로그의 끝까지 저장하는 것은 오버헤드가 크다
• PageLSN(데이터 베이스 버퍼의 페이지 내에서 제일 마지막 업데이트 연산에 대응되는 로그LSN)을 포함하는 로그 버퍼의 블록까지 저장함으로써 오버헤드를 줄인다.
• FlushLSN : 디스크로 Flush한 마지막 LSN을 저장한다.

체크 포인트 필요성

• 시스템이 다운된 시점으로부터 오래 전에 완료된 트랜잭션들이 데이터베이스를 갱신한 사항은 이미 디스크에 반영되었을 가능성이 크다.
• DBMS가 로그를 사용하더라도 어떤 트랜잭션의 갱신 사항이 주기억 장치 버퍼로부터 디스크에 기록되었는가를 구분할 수는 없다.
• 따라서 DBMS는 회복시 재수행할 트랜잭션 수를 줄이기 위해서 주기적으로 체크포인트 수행

체크포인트 전략

• 체크포인트 시점에는 주기억 장치의 버퍼 내용이 디스크에 강제로 기록되므로, 체크포인트를 수행하면 디스크 상에서 로그와 데이터베이스 내용이 일치하게 된다.
• 체크포인트 작업이 끝나면 로그에 [checkpoint] 로그 레코드가 기록된다.
• 일반적으로 체크포인트를 1~20분마다 한 번씩 수행된다.

체크포인트를 할 때 수행되는 작업

• 수행 중인 트랜잭션들을 일시적으로 중지시키며, 회복 알고리즘(fuzzy 체크 포인트)에 따라서는 필요하지 않을 수 있다.
• 주기억 장치의 로그 버퍼를 디스크에 강제로 출력한다.
• 주기억 장치의 데이터베이스 버퍼를 디스크에 강제로 출력한다.
• [checkpoint] 로그 레코드를 로그 버퍼에 기록한 후 디스크에 강제로 출력한다.
• 체크포인트 시점에 수행 중이던 트랜잭션들의 ID도 [checkpoint] 로그레코드에 함께 기록한다.
• 일시적으로 중지된 트랜잭션의 수행을 재개한다.

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

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