오라클 백업에 관한 내용

 

 

●Offline Backup (Consistency Backup) vs. Online Backup Inconsistency Backup)

 

■ Offline Backup (Consistency Backup)

- 데이터베이스를 정상적으로 종료(Abort 제외)한 후에 백업을 수행하는 방식이다. 데이터베이스가 닫힌 상태에서 백업이 이루어지므로, 데이터 파일에 대한 추가적인 쓰기 작업이 없다.

  

백업 구성요소
  - Data File
  - Control File(system change number 포함)
  - Redo Log File(정상 종료 후에는 불필요하지만 복구를 위해 모든 변경 사항을 반영하는 데 사용된다)

  - 모든 데이터 파일이 일관성이 있으므로(Consistency), 추가적인 Redo Log를 적용할 필요 없이 데이터베이스를 바로 열 수 있다.
  - 데이터베이스가 닫힌 상태에서 백업이 이루어지기 때문에 파일 간 불일치가 발생하지 않는다.
  

 

 

 

■  Online Backup (Inconsistency Backup)

- 데이터베이스가 실행 중(열려 있는 상태)일 때 백업을 수행하는 방식이다. 백업 작업 중에도 데이터 파일에 계속 쓰기가 발생한다.

백업 구성요소
  - Data File
  - Control File
  - Archive Log File

  - 데이터 파일의 일관성이 맞지 않기 때문에(Consistency 불일치), 백업 이후 Redo Log를 적용하여 복구(Recovery)해야 데이터베이스를 열 수 있다.
  - 백업 중 데이터 블록의 SCN(시스템 변경 번호)이 체크포인트 SCN보다 높을 수 있다. 이를 Header Inconsistency(헤더 불일치)라고 한다.
  - 백업 중 데이터 블록의 크기 차이로 인해 블록의 헤더와 테일 부분의 일관성이 달라질 수 있다. 이를 Block Inconsistency(블록 불일치)라고 한다.

 

 

■ Consistency:
  - Offline Backup: 모든 파일의 일관성이 맞음. 복구가 필요 없음.
  - Online Backup: 데이터 파일의 일관성이 맞지 않음. 복구 과정에서 Redo Log를 적용해야 함.
  
■  백업 시기:
  - Offline Backup: 데이터베이스를 정상적으로 종료 후 백업.
  - Online Backup: 데이터베이스가 열려 있는 동안 백업.

■ 데이터 손상 가능성:
  - Offline Backup: 일관성이 보장되므로 데이터 손상 위험이 적음.
  - Online Backup: 백업 중 쓰기 작업으로 인해 데이터 손상 가능성이 있으며, 이를 복구하려면 추가적인 로그 파일이 필요함.


■ SCN 관리:
  - SCN은 컨트롤 파일과 데이터 파일 헤더에 저장되어 있으며, SCN을 기준으로 데이터 일관성을 맞춘다.
  - 백업 시 I/O 단위와 데이터 블록 크기가 달라질 수 있으므로 데이터 블록의 헤더와 끝부분이 일치하지 않는 문제가 발생할 수 있다. 이를 Block Inconsistency라고 한다.

■ Begin/End Backup:
  - 핫백업을 시작할 때, BEGIN BACKUP 명령을 사용하여 데이터 파일의 백업을 시작한다.
  - 이때부터 리두 로그 엔트리가 데이터베이스 블록 단위로 커진다.
  - 백업이 완료되면 END BACKUP 명령을 통해 백업 상태를 종료하고, 아카이브 로그 파일을 적용할 수 있다.
  - V$BACKUP 뷰에서 현재 백업 상태를 확인할 수 있다.
  
■ Redo 로그:
  - 리두 로그 엔트리는 최소 단위로 발생하지만, 백업 시에는 블록 단위로 커진다.
  - 이를 위해 BEGIN BACKUP과 END BACKUP이 반드시 필요한다. 그렇지 않으면 아카이브 로그 파일을 제대로 적용할 수 없다.

■ 체크포인트 관리:
  - 백업을 시작할 때 데이터베이스가 체크포인트를 발생시킨다.
  - 이때 I/O가 발생하며, 백업 시점의 일관성을 맞추기 위해 체크포인트가 발생한다.
  - 백업 시 모든 데이터 파일을 맞추는 체크포인트를 발생시키므로, 밤에 백업 권장

 

 

 - 체크포인트 3가지 종류

데이터베이스에서 체크포인트는 데이터의 일관성을 유지하고 복구 시간을 단축하기 위해 사용되며 데이터베이스의 상태를 기록하는 방식에 따라 3가지로 나뉜다.

 

 

 

 

1. Full CheckPoint

 데이터베이스 버퍼 캐시 내의 모든 변경된 블록이 데이터 파일에 기록되며 데이터베이스의 모든 데이터 블록을 디스크에 동기화하여 일관성을 보장한다.

• 정상 종료 시: 데이터베이스가 정상적으로 종료되면 체크포인트가 발생하여 모든 변경사항이 데이터 파일에 기록된다.
• 명령어: ALTER SYSTEM CHECKPOINT; 명령어를 사용하여 수동 체크포인트를 일으킬 수 있다. 이 명령어는 현재 변경된 모든 블록을 데이터 파일에 기록하도록 한다.

2. Incremental CheckPoint

 체크포인트 큐의 변경사항을 데이터 파일에 기록하며, 오래된 변경 사항부터 순서대로 적용한다. 이 체크포인트는 데이터베이스의 성능과 복구를 위해 주기적으로 발생한다.

• 정상적인 체크포인트: 일반적으로 주기적으로 발생하여 데이터베이스가 안정된 상태를 유지하도록 한다.
• DBWn 프로세스: DBWn (Database Writer) 백그라운드 프로세스가 활성화될 때 발생한다. DBWn 프로세스는 데이터베이스 버퍼 캐시에서 변경된 데이터를 데이터 파일에 기록한다.

3. Partial CheckPoint

특정 테이블스페이스의 변경된 블록만을 데이터 파일에 기록한다. 이 체크포인트는 전체 데이터베이스가 아닌 특정 테이블스페이스에 대해서만 적용된다.

• ALTER TABLESPACE BEGIN BACKUP;: 이 명령어를 사용하면 테이블스페이스의 백업을 시작하고, 해당 테이블스페이스의 변경된 블록을 데이터 파일에 기록한다.
• ALTER TABLESPACE 이름 OFFLINE NORMAL;: 테이블스페이스를 오프라인으로 전환하여 변경된 블록을 기록하고, 데이터 파일의 일관성을 유지한다.

 

 

 

 

 

 

 

● 백업 및 복구 과정에서 RAW 디바이스와 ASM(Automatic Storage Management)

 

- 컨트롤 파일은 BCV를 사용해서 복제하면 안된다. 컨트롤 파일에는 데이터베이스 상태, 데이터 파일, 리두 로그 파일 등의 메타데이터가 포함되어 있어, 백업된 데이터 파일과 시점이 달라질 수 있기 때문에 데이터 파일만 BCV로 복제해야 하며, 컨트롤 파일은 운영 시스템에서 수동으로 복사하여 백업한다.

- ASM을 사용할 때는 반드시 RMAN을 이용하여 백업해야 한다. ASM은 데이터를 물리적으로 여러 디스크 그룹에 분산 저장하므로, RMAN은 ASM 구조를 잘 알고 분산된 데이터를 일관성 있게 백업할 수 있는 유일한 도구이다.

 

 

 

 

▶ 컨트롤 파일 복제 및 백업 과정

1. 컨트롤 파일 복사 절차:
   - 운영 데이터베이스에서 컨트롤 파일 복사:
     - 운영 DB에서 현재 사용 중인 컨트롤 파일을 복사하여 백업 DB로 전송한다. 
   - 백업 데이터베이스에서 컨트롤 파일 사용:
     - 백업 DB에서 복사한 컨트롤 파일을 사용하여 데이터베이스를 마운트 상태로 올린다. 이 단계에서 데이터베이스는 데이터를 읽을 수 있지만, 수정할 수는 없다.
   - 마운트 상태에서 RMAN 백업 수행:
     - 데이터베이스가 마운트 상태일 때 RMAN을 사용하여 백업을 수행한다. 이 상태에서는 데이터베이스의 데이터 파일과 아카이브 로그 파일의 백업을 안전하게 수행할 수 있다.
   - 아카이브 로그 파일 복구:
     - 운영 DB에서 생성된 아카이브 로그 파일을 가져와 백업 시점에 맞춰 복구한다. 이 파일들은 데이터베이스 복구 시 필수적이다.

 

 

▶ 노마운트 단계에서 RMAN 백업 수행 이유

- 데이터베이스 상태 인식:
  - 노마운트 상태: 데이터베이스가 노마운트 상태에서는 데이터베이스의 구조에 대한 정보가 컨트롤 파일을 통해 제공된다. 이 상태에서 RMAN이 백업을 수행하면, 데이터베이스는 동일한 DB라고 인식되며, 컨트롤 파일에 기반하여 백업을 일관되게 수행할 수 있다.
  - 오픈 상태: 데이터베이스가 오픈 상태로 들어가면, 데이터베이스가 수정 가능한 상태가 되며, 운영 DB와 백업 DB는 서로 다른 상태로 간주된다. 이 경우, 백업 DB의 상태와 운영 DB의 상태가 달라질 수 있어, 일관성을 유지하기 어렵다.

- read only mode:
  - 리드온리 모드: 데이터베이스를 리드온리 모드로 오픈하면, 데이터베이스의 내용이 변경되지 않으므로 일관성을 유지할 수 있다. 이 상태에서는 데이터베이스가 읽기 전용으로 작동하므로, 백업 작업과 복구 작업이 비교적 안전하게 수행될 수 있다.

 

 

 

 

 

▶ RAW 디바이스에서 ASM으로 전환할 때
   - RAW 디바이스 복구:
     - RAW 디바이스에서는 BEGIN BACKUP을 찍고 복제 후 복제를 종료한다. 복제된 볼륨이 백업본이 된다.
     - , RAW 디바이스에 볼륨이 1, 2, 3, 4가 있다면 각각 데이터 파일 datafile01.dbf, datafile02.dbf 등으로 매칭된다.
     - 일부 데이터 파일만 깨졌을 경우, 해당 파일만 복구하면 된다.
  
   - ASM 복구:
     - ASM은 데이터를 여러 디스크 그룹에 분산 저장하므로, ASM에서 일부 파일이 손상될 경우 전체 복구가 필요하다.
     - RMAN은 이러한 분산 저장된 데이터를 일관성 있게 복구할 수 있다.
     - ASM의 파일 구조는 내부적으로 데이터가 여러 디스크에 분산되어 있어 asmcmd 명령어를 통해 파일 구조를 확인할 수 있다.
  
   - ASM 데이터 파일은 일반적으로 .omf(Oracle Managed File) 형식으로 저장되며, RMAN은 이러한 파일 구조를 알고 백업 및 복구를 수행한다.

 

▶ RAW 디바이스에서 ASM으로 전환 시 절차
   1. SRDF 사용: 원격 스토리지 복제를 통해 데이터 파일을 복제.
   2. BEGIN BACKUP 명령어로 백업을 시작.
   3. SRDF 끊기: 복제가 완료된 후 SRDF 연결을 끊음.
   4. END BACKUP 명령어로 백업 종료.
   5. 컨트롤 파일 복사: 운영 DB에서 수동으로 컨트롤 파일을 백업 DB로 복사.
   6. 마운트 단계에서 컨트롤 파일을 사용하여 DB를 올리고, RMAN으로 백업을 수행.
   7. 아카이브 로그 파일은 운영 DB에서 가져와 백업 DB에 적용하여 일관성을 유지.














◎ BEGIN BACKUP

BEGIN BACKUP은 핫백업(Hot Backup) 중 데이터베이스의 일관성을 유지하기 위해 수행되는 중요한 과정이다. 핫백업 동안 데이터베이스는 여전히 운영 중이기 때문에, 데이터 파일은 계속해서 업데이트된다.그래서 BEGIN BACKUP 명령을 실행하면 데이터 파일 헤더의 체크포인트 SCN(System Change Number)이 고정된다. 체크포인트는 데이터베이스에서 현재 메모리의 내용을 디스크에 기록하는 과정으로, 이로 인해 데이터 파일의 SCN이 고정된다.

 

 BEGIN BACKUP 명령어가 실행되면 데이터 파일의 헤더에 Fuzzy Bit가 설정되는데 Fuzzy Bit는 "이 파일이 지금 백업 중"이라는 표시로, 백업이 끝날 때까지 데이터 파일이 변경되고 있음을 알린다.

 

 백업 과정 중 데이터 파일은 계속 변경되지만, SCN은 고정되어 있다. 따라서 백업이 끝난 후 리두 로그 파일을 적용하여 데이터 파일을 복구할 수 있다. BEGIN BACKUP이 실행되면 리두 로그 엔트리가 데이터베이스 블록 단위로 커지기 때문에, 리두 로그 파일과 아카이브 로그 파일을 모두 백업받는 것이 중요한다.
 

 아카이브 로그 파일은 데이터베이스의 변경 사항을 기록하고, 복구 시 필요한 파일이다. 핫백업 중에는 아카이브 로그 파일도 함께 백업하여, 나중에 복구할 때 데이터 파일과 아카이브 로그 파일을 세트로 사용해 일관성을 유지해야 한다.

 

BEGIN BACKUP 명령어
- 핫백업 시 데이터 파일의 체크포인트 SCN을 고정하여 복구 시점을 명확히 함.
- 체크포인트 발생: 데이터 파일이 백업 중임을 표시하는 Fuzzy Bit가 설정되고, 리두 로그 파일에 변경 전 이미지가 저장됨.
- 블록 스플릿 방지: 백업 중 데이터가 변경되어도 리두 로그에 기록된 변경 전 이미지를 통해 복구 가능.



■ 블록 스플릿 현상
- 백업 중 I/O 단위 차이로 인해 데이터 파일의 헤더와 테일이 일치하지 않는 현상.
- 해결 방법: 블록 스플릿 현상에 대비하기 위해 아카이브 로그 파일을 적용해 복구함.
- 주의점: BEGIN BACKUP 명령을 찍지 않으면 리두 로그 파일이 저장되지 않아 복구할 수 없음.

■  END BACKUP 명령어
- 핫백업 종료 시, hotbackup end marker redo record가 생성되어 백업이 종료된 시점이 기록됨.
- 복구 시, RESETLOGS 명령어를 사용해 데이터베이스를 열어야 함.

 

 

 

 

 

 

■ 완전 복구와 불완전 복구

▶ 완전 복구 (Full Recovery):
- 정의: 장애 발생 전 마지막 커밋 시점까지 데이터베이스를 복구하는 방법이다. 이 방식은 장애 발생 전 모든 트랜잭션을 복구하여 데이터베이스를 최종 상태로 되돌린다.
- 사용 시점: 일반적으로 장애가 발생했을 때, 가장 최근 커밋된 상태까지 복구하고자 할 때 사용된다.
- 조건: 모든 아카이브 로그와 데이터 파일이 손상되지 않고 사용 가능해야 한다.

 

 

 

▶불완전 복구 (Incomplete Recovery):
- 복구를 특정 시점이나 중간 상태로 제한하여 데이터를 복구하는 방법이다. 완전 복구가 불가능할 때 사용된다.
  

- 시점 기반 복구 (Point-in-Time Recovery):
   특정 시간이나 날짜로 복구하는 방법이다. 예를 들어, 데이터베이스가 특정 시간에 맞춰 복구되며, 해당 시간 이후의 모든 트랜잭션은 복구되지 않다.
    - 사용 시점: 특정 시점에서의 상태로 복구해야 할 때 사용된다. 예를 들어, 데이터가 실수로 삭제된 후 복구 시점을 특정 시점으로 설정하여 삭제 전 상태로 복구할 수 있다.
  - 취소 기반 복구 (Cancel-Based Recovery):
    - 정의: 아카이브 로그 파일의 특정 시점까지 복구하고, 중간에 로그 기록을 멈추는 방법이다. 이를 통해 과거 시점으로 복구할 수 있다.
    - 사용 시점: 복구 시점이나 상태를 조정하여, 특정 시점의 데이터로 복구할 수 있지만 모든 데이터가 복구되지 않을 수 있다.

 

 

 

 

 

 

 

 

 

 

■ DR 서버에서의 복구

DR 서버에서의 복구:
- 제약 사항: DR(Disaster Recovery) 서버에서는 BEGIN BACKUP 명령어를 사용할 수 없다. 이 명령어는 데이터를 백업 모드로 전환하여 복구를 수행할 때 사용된다.
- 불완전 복구 방법 사용 제한: DR 서버에서는 복구가 필요한 시점에 맞추어 백업을 수행해야 하며, 불완전 복구 방법(시점 기반 또는 취소 기반 복구)은 사용할 수 없다. 대신, 전체 백업이나 특정 시점으로 복구할 수 있는 방법을 사용해야 한다.

 

 

 

■ 클론 DB

클론 DB (Clone Database):
-  기존 데이터베이스의 복사본을 만들어 복구하거나 테스트 환경을 구성하는 방법이다. 클론 DB를 사용하여 특정 시점의 데이터를 복사하여 복구할 수 있다.
  - 복구: 실수로 삭제된 테이블이나 데이터를 복구할 때, 전체 데이터베이스가 아닌 특정 테이블이나 데이터만을 복구할 수 있다.
  - 테스트: 개발 및 테스트 환경에서 실제 데이터를 사용하여 테스트를 수행할 수 있다. 이 경우 클론 DB는 실제 운영 데이터베이스의 스냅샷을 제공한다.
- 작업 방법:
  - 백업 복사: 원본 데이터베이스의 백업을 사용하여 클론 DB를 생성한다.
  - 테이블 복구: 클론 DB에서 특정 테이블을 복원하거나 데이터를 복구한다.