UNDO & REDO 목적
UNDO 를 사용하는 목적은 다음과 같다.
- TRANSACTION ROLLBACK
- TRANSACTION RECOVERY
- (→ INSTANCE RECOVERY 시 ROLLBACK 단계)
- READ CONSISTENCY
REDO 로그는 아래 3가지 목적을 위해 사용된다.
- DATABASE RECOVERY
- (= MEDIA RECOVERY)
- CACHE RECOVERY
- (→ INSTANCE RECOVERY 시 ROLL FORWARD 단계)
- FAST COMMIT
첫째. REDO 로그는 물리적으로 디스크에 결함이 생기는 등 MEDIA FAIL 발생 시 데이터베이스를 복구하기 위해 사용되며, 이때는 ARCHIVED REDO 로그를 이용하게 된다. MEDIA RECOVERY 라고도 한다.
둘째. REDO 로그는 CACHE RECOVERY 를 위해 사용되며 다른 말로 INSTANCE RECOVERY 라고도 한다. 모든 데이터베이스 시스템이 I/O 성능을 위해 버퍼캐시를 사용하지만, 버퍼캐시는 휘발성이다. 캐시에만 적용한 변경사항을 아직 데이터파일에 기록하지 않은 상태에서 정전 등이 발생해 인스턴스가 비정상적으로 종료되면, 그때까지의 작업내용을 모두 잃게 된다. 이러한 트랜잭션 데이터 유실에 대비하기 위해 REDO 로그를 남긴다.
마지막으로, REDO 로그는 FAST COMMIT 을 위해 사용된다. 변경된 메모리 버퍼 블록을 ㄷ이터 파일에 기록하는 작업은 RANDOM 액세스 방식으로 이루어지기 때문에 느리다. 반면 로그는 APPEND 방식으로 이루어지므로 훨씬 빠르다. 따라서 트랜잭션에 의한 변경사항을 건건이 데이터 파일에 기록하지보다 우선 APPEND 방식으로 빠르게 로그 파일에 기록하고, 버퍼캐시 블록과 데이터파일 블록간 동기화는 적절한 수단 (DBWR, CHECKPOINT) 를 이용해 나중에 일괄 (BATCH) 수행한다.
사용자가 요구한 갱신 사항을 휘발성인 버퍼캐시에만 기록한 채 아직 디스크에 영구 기록하지 않았더라도 REDO 로그를 믿고 빠르게 COMMIT 을 완료한다는 의미로 FAST COMMIT 이라는 용어를 사용한다. 커밋 정보가 로그파일에 기록되어 있기만 하면, 인스턴스 CRASH 가 발생하더라도 REDO 로그를 이용해 언제든지 복구 가능하므로 사용자 프로세스는 안심하고 COMMIT 을 완료할 수 있다.
동시에 많은 트랜잭션이 몰려 로그 스위치가 너무 자주 발생하면, 자칫 백업(ARCHIVE)를 완료하지 못한 ONLINE REDO 로그로 스위칭이 일어나면서 DB HANG 이 발생할 수 있다. 그런 현상이 발생하지 않도록 적절한 크기와 적절한 개수의 REDO 파일을 할당해야 한다.
REDO 메커니즘
- LOG FORCE AT COMMIT
- DML 을 수행하는 사용자 프로세스가 로그 버퍼에 로그를 기록하고 데이터 블록을 변경한다.
- 이후 LGWR (LOG WRITER) 가 주기적으로 로그 버퍼 엔트리를 REDO 로그 파일에 기록하는데, 메모리상의 로그 버퍼는 언제든 유실될 가능성이 있다.
- 따라서 트랜잭션의 영속성을 보장하려면 최소한 커밋 시점에는 로그를 메모리가 아닌 데이터파일에 안전하게 기록해야 한다.
- 이를 LOG FORCE AT COMMIT 이라 한다.
- FAST COMMIT
- 사용자가 요구한 갱신 사항을 휘발성인 버퍼캐시에만 기록한 채 아직 디스크에 영구 기록하지 않았더라도, REDO 로그를 믿고 빠르게 커밋을 완료한다는 의미로 FAST COMMIT 이라는 용어를 사용한다.
- 커밋 정보가 로그파일에 기록되어 있기만 하면, 인스턴스 CREASH 가 발생하더라도 REDO 로그를 이용해 언제든 복구 가능하므로 사용자 프로세스는 안심하고 커밋을 완료할 수 있다.
- WRITE AHEAD LOGGING
- 버퍼캐시 블록을 갱신하기 전에 먼저 REDO 엔트리를 로그 버퍼에 기록해야 하며, DBWR 가 버퍼캐시의 DIRTY 블록들을 데이터 파일에 기록하기 전에 먼저 LGWR 가 해당 REDO 엔트리를 모두 REDO 로그 파일에 기록했음이 보장되어야 한다.
- 이를 WRITE AHEAD LOGGING 이라고 한다.
오라클은 데이터를 읽는 도중에 다른 트랜잭션에 의해 변경되었거나 변경이 진행중인 블록을 만나면 과거 시점으로 되돌린 CR COPY 블록을 만들어서 읽는다. 이때 UNDO 정보를 이용하는데, 필요한 UNDO 블록이 다른 트랜잭션에 의해 재사용 (OVERWRITTING) 된 상태면 CR COPY 를 생성할 수 없다. 그럴 때 SNAPSHOT TOO OLD 에러가 발생하므로 이는 UNDO 와 관련된 메커니즘이다.