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

온라인 백업

기여자 jfsinmsp
PDF

백업 모드에서 Oracle 데이터베이스를 보호하고 복구하려면 두 세트의 데이터가 필요합니다. 이것이 유일한 Oracle 백업 옵션은 아니지만 가장 일반적입니다.

  • 백업 모드의 데이터 파일 스냅샷

  • 데이터 파일이 백업 모드일 때 생성된 아카이브 로그입니다

커밋된 모든 트랜잭션을 포함하여 완전한 복구가 필요한 경우 세 번째 항목이 필요합니다.

  • 현재 redo 로그 집합입니다

온라인 백업의 복구를 유도하는 방법에는 여러 가지가 있습니다. 많은 고객은 ONTAP CLI를 사용한 다음 Oracle RMAN 또는 sqlplus를 사용하여 복구를 완료함으로써 스냅샷을 복구합니다. 이러한 현상은 데이터베이스 복구 가능성과 빈도가 매우 낮고 숙련된 DBA가 복구 절차를 처리하는 대규모 운영 환경에서 특히 흔합니다. NetApp SnapCenter와 같은 솔루션에는 완벽한 자동화를 위해 명령줄 및 그래픽 인터페이스 모두를 지원하는 Oracle 플러그인이 포함되어 있습니다.

일부 대규모 고객은 예약된 스냅샷을 준비하는 과정에서 특정 시간에 데이터베이스를 백업 모드로 전환하도록 호스트에 기본 스크립트를 구성하여 보다 간단한 접근 방식을 취했습니다. 예를 들어, 명령을 예약합니다 alter database begin backup 23:58에 alter database end backup 00:02에 스냅샷을 예약한 다음 자정에 스토리지 시스템에서 직접 스냅샷을 예약합니다. 그 결과 외부 소프트웨어 또는 라이센스가 필요 없는 간단하고 확장성이 뛰어난 백업 전략을 구축할 수 있습니다.

데이터 레이아웃

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

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

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

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

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

로컬 복구 절차 - NFS

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

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

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

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

  4. 전체 복구가 필요한 경우 현재 redo 로그를 재생합니다.

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

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

로컬 복구 절차 - SAN

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

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

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

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

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

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

  6. 전체 복구가 필요한 경우 모든 재실행 로그를 재생합니다.

이 절차는 원하는 아카이브 로그가 액티브 파일 시스템에 여전히 존재한다고 가정합니다. 만약 그렇지 않다면, 아카이브 로그 LUN/네임스페이스를 완전히 오프라인 상태로 전환한 후 복원을 수행하거나(또는 이전 스냅샷의 클론을 생성하는 방법도 있지만, 동일 호스트에 중복된 UUID 또는 LVM 이름이 생성될 수 있어 어려울 수 있습니다) 아카이브 로그를 복원해야 합니다. 이는 아카이브 로그를 전용 스토리지 리소스로 분리하는 것이 유용한 예시이기도 합니다. 아카이브 로그가 리두 로그와 동일한 볼륨 그룹을 공유하는 경우, 전체 LUN 세트를 복원하기 전에 리두 로그를 다른 위치로 복사해야 합니다. 이 단계를 통해 마지막으로 기록된 트랜잭션의 손실을 방지할 수 있습니다.