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

Oracle 데이터베이스 온라인 백업

기여자

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

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

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

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

  • 현재 redo 로그 집합입니다

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

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

데이터 레이아웃

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

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

이러한 지침을 따를 경우 정합성 보장 그룹 스냅샷을 수행할 필요 없이 스토리지 시스템에서 스냅샷을 직접 예약할 수 있습니다. Oracle 백업에는 데이터 파일을 동시에 백업할 필요가 없기 때문입니다. 온라인 백업 절차는 몇 시간 내에 테이프로 천천히 스트리밍될 때 데이터 파일을 계속해서 업데이트할 수 있도록 설계되었습니다.

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

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

로컬 복구 절차 - NFS

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

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

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

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

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

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

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

로컬 복구 절차 - SAN

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

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

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

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

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

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

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

이 절차에서는 활성 파일 시스템에 원하는 아카이브 로그가 여전히 존재한다고 가정합니다. 그렇지 않은 경우 아카이브 로그 LUN을 오프라인으로 전환하고 복원을 수행하여 아카이브 로그를 복원해야 합니다. 아카이브 로그를 전용 볼륨으로 분할하는 것이 유용한 예이기도 합니다. 아카이브 로그가 재실행 로그와 볼륨 그룹을 공유하는 경우 전체 LUN 세트를 복원하기 전에 재실행 로그를 다른 위치에 복사해야 합니다. 이 단계는 최종 기록된 트랜잭션의 손실을 방지합니다.