Skip to main content
Enterprise applications
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

백업 모드 없이 Oracle 자동 복구

PDF

Oracle 12c가 출시되면서 스냅샷 기반 백업 및 복구가 훨씬 간편해졌습니다. 데이터베이스를 무중단 제거 모드로 설정할 필요가 없어졌기 때문입니다. 그 결과, 스토리지 시스템에서 직접 스냅샷 기반 백업을 예약할 수 있게 되었습니다.

핫 백업 복구 절차는 DBA에게 더 익숙하지만 데이터베이스가 핫 백업 모드인 동안 생성되지 않은 스냅샷을 사용할 수 있는 것은 오래되었습니다. Oracle 10g 및 11g를 복구하는 동안 데이터베이스의 일관성을 유지하기 위해 추가 수동 단계가 필요했습니다. Oracle 12c를 사용하면 sqlplus 및 rman 핫 백업 모드에 있지 않은 데이터 파일 백업에서 아카이브 로그를 재생하는 추가 로직을 포함합니다.

앞에서 설명한 것처럼 스냅샷 기반 핫 백업을 복구하려면 두 가지 데이터 세트가 필요합니다.

  • 백업 모드에서 생성된 데이터 파일의 스냅샷입니다

  • 데이터 파일이 핫 백업 모드일 때 생성되는 아카이브 로그

복구 중에 데이터베이스는 데이터 파일에서 메타데이터를 읽어 복구에 필요한 아카이브 로그를 선택합니다.

백업 모드 없이 자동 복구를 수행하려면 동일한 결과를 얻기 위해 약간 다른 데이터 세트가 필요합니다.

  • 데이터 파일의 스냅샷입니다.

  • 동기화된 아카이브 로그, 제어 파일 및 리두 로그 세트입니다. 아카이브 로그에는 데이터 파일 스냅샷이 생성된 시점부터의 모든 레코드가 포함되어야 하므로, 과도한 로그 삭제에 주의해야 합니다.

복구 과정에서 데이터베이스는 데이터 파일에서 메타데이터를 읽어 필요한 로그 레코드를 식별하고 기록된 모든 트랜잭션을 재생합니다.

참고:

이 접근 방식은 특정 시점으로의 복구를 근사적으로 수행할 수 있지만, 세부적인 복구 수준은 제한적입니다. 예를 들어, 백업 모드의 데이터 파일로 시작하면 임의의 트랜잭션 시점으로 데이터베이스를 롤포워드할 수 있습니다.

백업 모드를 사용하지 않고 자동 복구 방식을 사용하는 경우, 데이터베이스를 로그 스냅샷 시점으로 복구해야 합니다. 정상적인 상황에서는 원본 아카이브 로그, 리두 로그 및 제어 파일이 활성 파일 시스템에 남아 있으므로 RPO는 0이 됩니다. 하지만 활성 파일 시스템의 모든 데이터가 손실되어 스냅샷에서만 복구를 수행해야 하는 경우에는 RPO가 1시간이 됩니다.

데이터 레이아웃 가장 간단한 레이아웃은 데이터 파일을 전용 볼륨, LUN 또는 NVMe 네임스페이스에 격리하는 것입니다. 스토리지 리소스는 다른 파일 유형과 섞이지 않도록 해야 합니다. 이렇게 하면 SnapRestore 작업을 통해 중요한 리두 로그, 제어 파일 또는 아카이브 로그를 손상시키지 않고 데이터 파일을 신속하게 복원할 수 있습니다.

SAN은 전용 리소스 내에서 데이터 파일 격리에 대해 유사한 요구 사항을 가지고 있습니다. AFF 스토리지를 사용하는 Microsoft Windows와 같은 운영 체제에서는 단일 볼륨에 여러 개의 데이터 파일 LUN이 포함될 수 있으며, 각 LUN은 NTFS 파일 시스템을 사용합니다. 다른 운영 체제에서는 일반적으로 논리 볼륨 관리자가 있습니다. 예를 들어 Oracle ASM의 경우, 가장 간단한 옵션은 ASM 디스크 그룹의 LUN을 단일 볼륨으로 제한하여 하나의 단위로 백업 및 복원하는 것입니다. 성능 또는 용량 관리 이유로 추가 볼륨이 필요한 경우, 새 볼륨에 추가 디스크 그룹을 생성하면 관리가 더 간편해집니다.

ASA는 볼륨 수준의 추상화를 제공하지 않습니다. 대신 일관성 그룹을 사용합니다. 많은 경우 단일 LUN 또는 NVMe 네임스페이스로 데이터베이스의 관리 및 성능 요구 사항을 충족할 수 있습니다. 여러 LUN 또는 네임스페이스가 필요한 경우 추가 리소스를 추가하여 일관성 그룹으로 바인딩할 수 있으며, 이 그룹이 데이터 파일 컨테이너가 됩니다.

이 지침을 따르면 스냅샷을 스토리지 시스템에서 직접 예약할 수 있습니다.

  • 주의: * ASM을 확인합니다 spfile 및 passwd 파일이 데이터 파일을 호스팅하는 디스크 그룹에 없습니다. 이로 인해 데이터 파일과 데이터 파일만 선택적으로 복원할 수 없습니다.

== 로컬 복구 절차—NFS 기본 절차는 다음과 같습니다:

  1. 데이터베이스를 종료합니다.

  2. 원하는 복원 지점 바로 직전의 스냅샷으로 데이터 파일 볼륨, LUN 또는 네임스페이스를 복구합니다.

  3. 실행 alter database automatic;

이 절차에서는 활성 파일 시스템에 원하는 아카이브 로그가 여전히 존재한다고 가정합니다. 그렇지 않은 경우, 또는 아카이브 로그를 복원해야 합니다 rman 또는 sqlplus 의 데이터로 이동할 수 있습니다 .snapshot 디렉토리.

또한 데이터베이스의 규모가 작은 경우 최종 사용자가 에서 직접 데이터 파일을 복구할 수 있습니다 .snapshot 디렉토리에는 자동화 툴 또는 스토리지 관리자의 도움 없이 SnapRestore 명령을 실행할 수 있습니다.

== 로컬 복구 절차—SAN 기본 절차는 다음과 같습니다:

  1. 데이터베이스를 종료합니다.

  2. 데이터 파일을 호스팅하는 디스크 그룹을 중지합니다. 절차는 선택한 논리적 볼륨 관리자에 따라 다릅니다. ASM을 사용할 경우 이 프로세스에서는 디스크 그룹을 마운트 해제해야 합니다. Linux에서는 파일 시스템을 마운트 해제해야 하며 논리적 볼륨 및 볼륨 그룹이 비활성화됩니다. 목표는 복구할 타겟 볼륨 그룹의 모든 업데이트를 중지하는 것입니다.

  3. 원하는 복원 지점 바로 전에 데이터 파일 디스크 그룹을 스냅샷으로 복원합니다.

  4. 새로 복구된 디스크 그룹을 다시 활성화합니다.

  5. 실행 alter database automatic;

이 절차는 원하는 아카이브 로그가 액티브 파일 시스템에 여전히 존재한다고 가정합니다. 만약 그렇지 않다면, 아카이브 로그 LUN을 오프라인으로 전환한 후 복원을 수행하여 아카이브 로그를 복원해야 합니다. 이는 아카이브 로그를 전용 볼륨, LUN 또는 네임스페이스로 분리하는 것이 유용한 예시이기도 합니다. 아카이브 로그가 리두 로그와 동일한 볼륨 그룹을 공유하는 경우, 최종적으로 기록된 트랜잭션 손실을 방지하기 위해 전체 LUN 세트를 복원하기 전에 리두 로그를 다른 위치로 복사해야 합니다.

== 완전 복구 예시 데이터 파일이 손상되었거나 파괴되어 완전 복구가 필요한 경우를 가정해 보겠습니다. 복구 절차는 다음과 같습니다.

[oracle@host1 ~]$ sqlplus / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1610612736 bytes
Fixed Size                  2924928 bytes
Variable Size            1040191104 bytes
Database Buffers          553648128 bytes
Redo Buffers               13848576 bytes
Database mounted.
SQL> recover automatic;
Media recovery complete.
SQL> alter database open;
Database altered.
SQL>