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

Oracle Database Storage Snapshot Optimized Backups의 약어입니다

기여자

데이터베이스를 핫 백업 모드로 설정할 필요가 없기 때문에 Oracle 12c가 출시되었을 때 스냅샷 기반 백업 및 복구가 더욱 간편해졌습니다. 그 결과 스토리지 시스템에서 직접 스냅샷 기반 백업을 예약하고 전체 또는 시점 복구를 수행하는 기능을 유지할 수 있습니다.

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

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

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

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

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

스토리지 스냅샷으로 최적화된 복구에서는 동일한 결과를 얻기 위해 약간 다른 데이터 세트가 필요합니다.

  • 데이터 파일의 스냅샷과 스냅샷이 생성된 시간을 식별하는 방법입니다

  • 최신 데이터 파일 체크포인트 시점부터 스냅샷의 정확한 시간까지 로그를 아카이빙합니다

복구 중에 데이터베이스는 데이터 파일에서 메타데이터를 읽어 필요한 초기 아카이브 로그를 식별합니다. 전체 또는 특정 시점 복구를 수행할 수 있습니다. 시점 복구를 수행할 때는 데이터 파일의 스냅샷 시간을 알아야 합니다. 지정된 복구 지점은 스냅샷 생성 시간 이후여야 합니다. NetApp에서는 클럭 변동을 고려하여 스냅샷 시간에 최소 몇 분을 추가하는 것이 좋습니다.

자세한 내용은 Oracle 12c 설명서의 다양한 릴리스에서 제공되는 "Recovery using Storage Snapshot Optimization(스토리지 스냅샷 최적화를 사용한 복구)" 항목에 대한 Oracle 설명서를 참조하십시오. 또한 Oracle 타사 스냅샷 지원에 대해서는 Oracle Document ID Doc ID 604683.1을 참조하십시오.

데이터 레이아웃

가장 간단한 레이아웃은 데이터 파일을 하나 이상의 전용 볼륨으로 분리하는 것입니다. 다른 파일 형식으로 오염되지 않아야 합니다. 이는 중요한 redo 로그, 제어 파일 또는 아카이브 로그를 삭제하지 않고 SnapRestore 작업을 통해 데이터 파일 볼륨을 신속하게 복원할 수 있도록 하기 위한 것입니다.

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

이러한 지침을 따를 경우 정합성 보장 그룹 스냅샷을 수행할 필요 없이 ONTAP에서 스냅샷을 직접 예약할 수 있습니다. 이유는 스냅샷 최적화 백업에는 데이터 파일을 동시에 백업할 필요가 없기 때문입니다.

여러 볼륨에 분산된 ASM 디스크 그룹과 같은 상황에서는 문제가 발생합니다. 이 경우 ASM 메타데이터가 모든 구성 볼륨에서 일관되도록 CG-스냅샷을 수행해야 합니다.

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

로컬 복구 절차 - NFS

이 절차는 수동으로 또는 SnapCenter와 같은 응용 프로그램을 통해 실행할 수 있습니다. 기본 절차는 다음과 같습니다.

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

  2. 원하는 복원 지점 바로 전에 데이터 파일 볼륨을 스냅샷으로 복구합니다.

  3. 원하는 지점으로 아카이브 로그를 재생합니다.

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

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

로컬 복구 절차 - SAN

이 절차는 수동으로 또는 SnapCenter와 같은 응용 프로그램을 통해 실행할 수 있습니다. 기본 절차는 다음과 같습니다.

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

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

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

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

  5. 원하는 지점으로 아카이브 로그를 재생합니다.

이 절차에서는 활성 파일 시스템에 원하는 아카이브 로그가 여전히 존재한다고 가정합니다. 그렇지 않은 경우 아카이브 로그 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>

특정 시점 복구 예

전체 복구 절차는 단일 명령입니다. recover automatic.

시점 복구가 필요한 경우 스냅샷의 타임스탬프를 알고 있어야 하며 다음과 같이 식별할 수 있습니다.

Cluster01::> snapshot show -vserver vserver1 -volume NTAP_oradata -fields create-time
vserver   volume        snapshot   create-time
--------  ------------  ---------  ------------------------
vserver1  NTAP_oradata  my-backup  Thu Mar 09 10:10:06 2017

스냅샷 생성 시간은 3월 9일 및 10:10:06으로 표시됩니다. 안전을 위해 스냅샷 시간에 1분이 추가됩니다.

[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 database until time '09-MAR-2017 10:44:15' snapshot time '09-MAR-2017 10:11:00';

이제 복구가 시작됩니다. 또한 스냅샷 시간을 10:11:00, 기록된 시간 1분 후 가능한 클럭 편차를 계산하고 목표 복구 시간을 10:44로 지정했습니다. 그런 다음 sqlplus는 원하는 복구 시간인 10:44에 도달하는 데 필요한 아카이브 로그를 요청합니다.

ORA-00279: change 551760 generated at 03/09/2017 05:06:07 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_31_930813377.dbf
ORA-00280: change 551760 for thread 1 is in sequence #31
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 552566 generated at 03/09/2017 05:08:09 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_32_930813377.dbf
ORA-00280: change 552566 for thread 1 is in sequence #32
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 553045 generated at 03/09/2017 05:10:12 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_33_930813377.dbf
ORA-00280: change 553045 for thread 1 is in sequence #33
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 753229 generated at 03/09/2017 05:15:58 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_34_930813377.dbf
ORA-00280: change 753229 for thread 1 is in sequence #34
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
SQL>
참고 를 사용하여 스냅샷을 사용하여 데이터베이스 복구를 완료합니다 recover automatic 명령에는 특정 라이센스가 필요하지 않지만 를 사용하여 시점 복구가 필요합니다 snapshot time Oracle Advanced Compression 라이센스가 필요합니다.