[데이터베이스] 오라클의 타임머신과 블랙박스 Undo와 Redo

Oracle Undo와 Redo

 

오라클을 공부하는 학생이나 실무자 입장에서는 비슷한 용어 사용으로 인해 헷갈릴 수 있는 여지가 충분합니다. Redo와 Undo 모두 "변경 사항"을 기록한다는 공통점이 있지만 그 목적은 완전히 다릅니다.

Redo 로그는 장애나 시스템 오류 발생 시 데이터를 복구하기 위한 기록으로, 자동차의 블랙박스처럼 사고 이후 원인을 추적하고 상태를 복원하는 데 사용됩니다. 반면 Undo는 트랜잭션을 취소하거나 이전 상태로 되돌리기 위한 기록으로, 문서 작업에서 Ctrl+Z를 눌러 방금 작업을 되돌리는 기능에 비유할 수 있습니다.

 

Redo (다시 하기): "데이터를 지킨다"

👉 목적
장애 발생 시 데이터 손실을 방지하고 복구(Recovery)하는 것입니다.

👉 작동 방식
모든 변경 사항은 데이터 파일에 쓰이기 전 'Redo Log Buffer'에 기록되고, LGWR 프로세스에 의해 'Redo Log File'로 저장됩니다.

👉 특징: 장애 직전 상태로 돌아갑니다.


Undo (취소 하기): "일관성을 지킨다"

👉 목적
트랜잭션 취소(Rollback) 및 읽기 일관성(Read Consistency) 보장합니다.

👉 작동 방식
변경 전 데이터를 'Undo Segment'에 보관하여, 다른 사용자가 수정 중인 데이터를 조회할 때 이전 상태를 보여줍니다.

👉 특징: MVCC(Multi-Version Concurrency Control) 구현의 핵심입니다.

 

Undo Data

 

언두 데이터는 데이터가 수정되기 전의 원본 값을 복사한 정보입니다. 데이터 변경이 발생하는 모든 트랜잭션에 대해 자동으로 캡처되며, 최소한 해당 트랜잭션이 종료될 때까지는 보존됩니다.

또한 언두 데이터는 다양한 기능을 지원합니다. 대표적으로 트랜잭션을 이전 상태로 되돌리는 롤백(Rollback) 작업을 수행할 수 있으며, 조회 시점의 데이터 정합성을 보장하는 읽기 일관성(Read Consistency) 쿼리를 가능하게 합니다. 이와 함께 Oracle Flashback Query, Flashback Transaction, Flashback Table과 같은 플래시백 기능을 지원하고, 실패한 트랜잭션에 대한 복구(Recovery) 작업에도 활용됩니다.

👉 자동 할당 및 역할
트랜잭션 시작과 동시에 자동으로 할당되며, 데이터 변경 전의 원본 값을 저장하여 장애 발생 시 복구나 롤백을 가능하게 합니다.

👉 실시간 모니터링
현재 어떤 트랜잭션이 어떤 언두 세그먼트를 점유하고 있는지는 V$TRANSACTION 뷰를 통해 명확히 확인할 수 있습니다.

👉 유연한 구조
일반 세그먼트처럼 Extent와 데이터 블록으로 구성되지만, 시스템 상황에 따라 스스로 확장하거나 축소하며 관리됩니다.

👉 순환 구조
 할당된 공간을 순차적으로 사용한 뒤, 끝에 도달하면 다시 처음으로 돌아와 재사용하는 효율적인 구조를 가집니다. 공간이 정말 모자랄 때만 새 Extent를 요청합니다.

👉 예외 케이스
기본적으로 1:1 대응이지만, 병렬 DML/DDL 같은 대규모 작업 시에는 하나의 트랜잭션이 여러 개의 언두 세그먼트를 동시에 사용할 수도 있습니다.

언두 세그먼트는 오직 언두 테이블스페이스에만 생성될 수 있으며, 해당 테이블스페이스에는 테이블과 같은 다른 세그먼트를 만들 수 없습니다. DBCA는 기본적으로 Small File 언두 테이블스페이스를 생성하지만, 필요에 따라 Big File 방식으로도 구성할 수 있습니다. 특히 동시 트랜잭션이 많은 대규모 OLTP 환경에서는 파일 헤더 경합이 발생할 수 있으며, 여러 데이터 파일로 구성된 언두 테이블스페이스를 통해 이를 완화할 수 있습니다.

데이터베이스에는 여러 개의 언두 테이블스페이스가 존재할 수 있으나, 특정 시점에는 하나만 Instance의 활성 언두 테이블스페이스로 사용됩니다. 언두 세그먼트는 자동으로 생성되며 항상 SYS가 소유하고, 순환 버퍼처럼 동작하기 때문에 최소 두 개 이상의 Extent를 가지며, 최대 Extent 수는 블록 크기에 따라 달라집니다(8KB 기준 약 32,765개).

또한 언두 테이블스페이스는 자동 Extent 할당을 사용하는 영구적인 로컬 관리 방식으로 데이터베이스에 의해 자동 관리됩니다. Instance Crash 등으로 실패한 트랜잭션을 복구하기 위해서는 언두 데이터가 필요하므로, 언두 테이블스페이스 복구는 Instance가 MOUNT 상태일 때 수행됩니다.

 

전체 언두 공간 중 얼마나 사용 중인지, 그리고 상태별 점유 현황을 확인하는 쿼리입니다.
ACTIVE: 현재 트랜잭션이 사용 중인 공간 (롤백/읽기 일관성 필요)
UNEXPIRED: 트랜잭션은 종료되었으나 undo_retention 시간이 지나지 않아 보관 중인 공간입니다.
EXPIRED: 보관 기간이 지나 재사용 가능한 공간입니다.

 

물리적인 바이너리 파일은 oradata 영역에 undotbs01.dbf 파일로 생성되며, 우리가 오라클을 사용하는 동안에도 주기적으로 블랙박스를 생성하고 있습니다.

 

 

 

Redo log

데이터베이스에서 가장 중요한 요소는 바로 데이터의 무결성(Integrity) 입니다. 만약 갑작스러운 정전이나 서버 장애가 발생하면, 메모리(SGA)에 존재하던 변경 내용은 모두 사라질 수 있습니다. 이때 시스템은 "이전에 이러한 변경이 있었다"는 사실을 근거로 데이터베이스를 정상 상태로 복구해야 합니다.

해당 역할을 수행하는 것이 Redo Log입니다. Redo Log는 데이터에 발생한 변경 사항을 지속적으로 기록하여, 장애 발생 시 해당 변경 내역을 다시 적용함으로써 데이터의 일관성과 무결성을 보장합니다.

Redo Log가 어떻게 기록되는지 그 흐름을 살펴보겠습니다.

👉 Redo Log Buffer
사용자가 데이터를 변경(INSERT, UPDATE, DELETE)하면, 먼저 메모리 공간인 Buffer에 기록됩니다.

👉 LGWR (Log Writer)
특정 시점(3초마다, Buffer의 1/3이 찼을 때, 또는 Commit 했을 때)에 메모리의 내용을 실제 디스크인
Redo Log File로 옮겨 적습니다.

👉 Write-Ahead Logging (WAL)
핵심 원칙입니다. 실제 데이터 파일(DBF)을 수정하기 전에, 반드시 로그부터 기록해야 합니다. 그래야 나중에 사고가 나도 로그를 보고 복구할 수 있으니까요.

로그를 계속 쌓아두면 디스크가 가득 차게 될 수 있는 우려가 있어 Oracle은 Redo Log를 무한히 저장하지 않고 순환 방식으로 운영합니다.

Redo Log는 최소 두 개 이상의 그룹으로 구성되며, 일반적으로 Group 1, Group 2와 같이 여러 개를 번갈아 사용합니다. 특정 로그 파일이 가득 차면 Log Switch가 발생하여 다음 그룹으로 기록이 넘어갑니다. 그리고 마지막 그룹까지 모두 사용하면 다시 처음 그룹으로 돌아가 기존 내용을 덮어씁니다.

다만, 덮어쓰기 전에 반드시 수행해야 할 중요한 작업이 있습니다. 먼저 Checkpoint를 통해 해당 로그에 기록된 변경 사항이 실제 데이터 파일(.dbf)에 모두 반영되었는지 확인합니다. 또한 데이터베이스가 ARCHIVELOG 모드로 운영 중이라면, 덮어쓰기 전에 해당 Redo Log를 별도의 안전한 위치에 복사하여 Archived Redo Log로 보관합니다. 이 아카이브 로그가 있어야 특정 과거 시점으로의 복구가 가능해집니다.

 

Redo 로그를 다중화하여 안정성을 높일 수는 있지만, 데이터베이스의 데이터는 곧 기업의 자산이자 매우 중요한 정보입니다. 따라서 단순한 로그 다중화만으로는 충분하지 않을 수 있습니다.

실무 환경에서는 최악의 데이터 유실 상황에 대비하기 위해 Data Pump를 활용한 정기 백업이나, Oracle GoldenGate(OGG)를 통한 실시간 데이터 복제와 같은 추가적인 보호 전략을 함께 운영합니다. 이를 통해 장애나 재해 상황에서도 데이터 손실을 최소화할 수 있도록 대비합니다.

물리적인 바이너리 파일은 oradata 영역에 redo.log 파일로 생성되며, 우리가 오라클을 사용하는 동안에도 주기적으로  생성하고 있습니다.

 

Redo Log 파일이 아카이브되지 않은 상태에서는 다른 트랜잭션 로그로 덮어쓸 수 없습니다. 데이터베이스는 먼저 해당 Redo Log 파일을 지정된 아카이브 위치로 복사한 뒤, 복사가 정상적으로 완료된 경우에만 그 파일을 다시 사용할 수 있으며, 이러한 절차를 통해 Redo 로그 데이터가 안전하게 보존되고 장애 발생 시에도 특정 시점까지의 복구가 가능하도록 보장합니다.

적제된 Redo 로그를 통해 RMAN(Recovery Manager) 혹은 ARCHIVELOG 복구를 통해 장애 발생 시점이전으로 완벽하게 복구할 수 있습니다. Oracle은 이처럼 데이터 동기화 관리부터 백업 및 복구 체계에 이르기까지 매우 견고한 아키텍처를 제공하며, 이러한 안정성과 신뢰성을 바탕으로 지금까지도 엔터프라이즈 시장에서 독보적인 위치를 유지하고 있습니다.

 

 

Redo 로그의 동작 상태는 쿼리를 통해 확인할 수 있습니다. V$LOG 다이나믹 퍼포먼스 뷰를 이용하면 각 로그 그룹의 상태, 크기, 시퀀스 번호 등의 정보를 조회할 수 있습니다.

CURRENT: 지금 LGWR가 동작중인 그룹 상태입니다.
ACTIVE: 쓰기는 끝났는데, 아직 이 로그 안의 내용이 데이터 파일(DBF)에 다 기록되지 않은 상태입니다. 
INACTIVE: 데이터 파일에 반영 완료하여 덮어써도 되는 안전한 상태입니다.
UNUSED: 아직 한 번도 안 쓴 새 파일입니다.