자율운영 Data Guard를 사용하여 장애 및 재해로부터 중요한 데이터베이스 보호

자율운영 Data Guard 정보

자율운영 Data Guard는 애플리케이션의 연결 및 사용 기본 데이터베이스와 기본 데이터베이스의 동기화된 복사본인 대기 데이터베이스라는 두 개의 완전히 별도 데이터베이스 복사본을 생성하고 유지 관리합니다. 그런 다음 어떤 이유로든 기본 데이터베이스를 사용할 수 없게 되면 자율운영 Data Guard가 대기 데이터베이스를 기본 데이터베이스로 변환할 수 있으므로 애플리케이션 서비스를 시작합니다.

기본 데이터베이스와 대기 데이터베이스는 서로 피어 데이터베이스라고 하는 경우가 많습니다. 자율운영 컨테이너 데이터베이스당 최대 두 개의 대기 데이터베이스를 가질 수 있습니다.

주:

자율운영 Data Guard가 제공하는 데이터베이스 가용성 기능의 이점을 최대한 활용하려면 애플리케이션이 TAC(투명한 애플리케이션 연속성)를 사용하도록 구성되어야 합니다.

다음 다이어그램은 각 대기 데이터베이스가 기본 데이터베이스와 동기화된 상태를 보여줍니다.

autonomous-data-guard.eps에 대한 설명은 다음과 같습니다.

그림 autonomous-data-guard.eps에 대한 설명

primary database의 변경 사항은 primary database의 리두 로그에 기록됩니다. 자율운영 Data Guard는 이러한 리두 레코드를 네트워크를 통해 스트림으로 대기 데이터베이스의 리두 로그로 전송합니다. 그런 다음 대기 데이터베이스가 이러한 레코드를 대기 데이터베이스에 적용합니다. 이러한 방식으로 standby database는 primary database와 동기화된 상태로 유지됩니다.

동기화는 거의 즉각적으로 이루어지지만 방금 설명한 프로세스에서 알 수 있듯이 리두 레코드를 standby database로 전송하고 리두 레코드를 standby database에 적용하는 두 가지 작업이 있습니다. 그 중 첫 번째는 전송 지연이라고 하고, 다른 하나는 적용 지연이라고 합니다. You can view current lag values for an Autonomous Database from the database's Details page from Autonomous Data Guard under Resources. under Resources in the side menu. 컨테이너 데이터베이스의 세부정보 페이지에서 컨테이너 데이터베이스의 모든 Autonomous Database에 대한 현재 지연 값을 유사한 방식으로 볼 수 있습니다.

주:

대기 데이터베이스가 여러 개인 경우 계단식 리두 전송이 지원되지 않습니다.

자율운영 Data Guard 구성

Autonomous Database on Dedicated Exadata Infrastructure에서는 자율운영 컨테이너 데이터베이스(ACD) 레벨에서 자율운영 Data Guard를 구성하고 관리합니다. 이미 프로비전된 ACD에 대해 자율운영 Data Guard를 사용으로 설정하고 Oracle Cloud Infrastructure 콘솔을 사용하여 세부정보 페이지에서 최대 2개의 대기 ACD를 추가할 수 있습니다. 지침은 자율운영 컨테이너 데이터베이스에서 자율운영 Data Guard 사용 및 두 번째 대기 자율운영 컨테이너 데이터베이스 추가를 참조하십시오.

자율운영 Data Guard를 구성하기 전에 다음 사항에 유의하십시오.

Exadata Cloud@Customer에 배포된 Autonomous Database의 경우 자율운영 Data Guard 설정에서 기본 데이터베이스와 대기 데이터베이스 간의 TCP 트래픽을 허용하려면 포트 1522가 열려 있어야 합니다.
다음 3일 이내에 일정이 잡힌 활성 유지보수 실행이 있는 ACD에서 자율운영 Data Guard를 사용으로 설정할 수 없습니다. 먼저 활성 유지보수를 실행한 다음 자율운영 Data Guard를 사용으로 설정하거나, 두번째 대기 데이터베이스가 추가될 때까지 시작되지 않도록 유지보수 실행 일정을 변경할 수 있습니다.
두번째 standby database를 추가하려면 첫번째 standby database에 대해 자동으로 비롤링을 재시작해야 합니다. 기본 데이터베이스는 이 비롤링 재시작의 영향을 받지 않습니다.

고객 관리 키로 자율운영 Data Guard 구성

전용 Exadata 인프라의 Autonomous Database에서는 자율운영 컨테이너 데이터베이스(ACD) 레벨에서 고객 관리 키로 자율운영 Data Guard를 구성하고 관리할 수 있습니다. Oracle Cloud Infrastructure 콘솔을 사용하여 이미 프로비전된 ACD에 대해 자율운영 Data Guard를 사용으로 설정하고 세부정보 페이지에서 최대 2개의 대기 ACD를 추가할 수 있습니다. 지침은 자율운영 컨테이너 데이터베이스에서 자율운영 Data Guard 사용 및 두 번째 대기 자율운영 컨테이너 데이터베이스 추가를 참조하십시오.

고객 관리 키로 자율운영 Data Guard를 구성하기 전에 다음 사항에 유의하십시오.

OCI KMS(Oracle Cloud Infrastructure Key Management System)를 사용 중이고 영역 간 자율운영 Data Guard를 사용으로 설정하려면 먼저 OCI 저장소를 대기 데이터베이스를 추가할 영역에 복제해야 합니다. 자세한 내용은 저장소 및 키 복제를 참조하십시오.

주:
영역 간 저장소 복제 기능이 도입되기 전에 생성된 가상 저장소는 영역 간에 복제할 수 없습니다. 다른 영역에서 복제해야 하는 저장소가 있고 해당 저장소에 대해 복제가 지원되지 않는 경우 새 저장소와 새 키를 생성합니다. 그러나 모든 프라이빗 저장소는 영역 간 복제를 지원합니다. 자세한 내용은 가상 저장소 영역 간 복제를 참조하십시오.
OKV(Oracle Key Vault)를 사용 중이고 영역 간 자율운영 Data Guard를 사용으로 설정하려면 키 저장소에서 OKV 클러스터에 대한 접속 IP 주소를 추가했는지 확인하십시오.

자율운영 Data Guard 모델

2025년 3월부터 자율운영 컨테이너 데이터베이스(ACD)는 세부정보 페이지에서 자율운영 Data Guard를 사용으로 설정하고 최대 두 개의 대기 ACD를 생성할 수 있습니다. 이 릴리스에서는 이전 Autonomous Data Guard Associations 모델 및 관련 API가 더 이상 사용되지 않으며 새 Autonomous Data Guard Groups 모델 및 API로 대체됩니다. 2025년 3월 이후에 Oracle Cloud Infrastructure(OCI) 콘솔에서 프로비저닝된 모든 새로운 ACD는 자동으로 새로운 Autonomous Data Guard Groups 모델을 사용합니다.

기존 ACD를 전환하기 위해 고객은 OCI 콘솔의 ACD 세부정보 페이지에서 자율운영 Data Guard 그룹으로 업그레이드를 누르거나 MigrateAutonomousContainerDatabaseDataguardAssociation API를 사용하여 새 모델로 마이그레이션할 수 있습니다.

업그레이드 시:

자율운영 Data Guard 작업이 자율운영 컨테이너 데이터베이스 Data Guard 연관 리소스 대신 자율운영 컨테이너 데이터베이스 리소스에서 수행되는 새 사용자 환경으로 전환됩니다.
Autonomous Data Guard Associations 리소스는 다중 대기 지원과 함께 Autonomous Data Guard Groups 리소스로 변환됩니다. 기존 자율운영 데이터베이스 또는 Data Guard 설정에는 영향을 주지 않습니다.
자율운영 Data Guard 기능을 사용하도록 프로비전한 후 ACD의 세부정보 페이지에서 자율운영 Data Guard를 사용으로 설정해야 합니다.
역할을 기본 ACD 또는 페일오버로 각각 전환하려는 대기 ACD에서 스위치오버 및 페일오버 작업을 시작해야 합니다.
자율운영 Data Guard 구성 관리 API에서 대체 API로 나열된 새 자율운영 Data Guard 그룹 API로 전환합니다. 기존 Autonomous Data Guard Associations API는 더 이상 사용되지 않으며 2026년 3월부터는 제공되지 않습니다.
자율운영 Data Guard 이벤트 유형에 나열된 새 자율운영 Data Guard 그룹 이벤트를 구독해야 합니다. 기존 Autonomous Data Guard Associations 이벤트는 이전 Autonomous Data Guard Associations API에서만 작동하며 해당 API와 함께 더 이상 사용되지 않습니다.

롤 전환 및 작업

ACD(자율운영 컨테이너 데이터베이스)가 생성된 후에는 스위치오버 또는 복구 작업을 사용하여 피어 데이터베이스의 롤을 변경할 수 있습니다. 자동 복구가 사용으로 설정된 경우 자율운영 Data Guard는 어떤 이유로든 기본 데이터베이스를 사용할 수 없게 될 때마다 자동으로 복구 작업을 수행합니다.

스위치오버는 기본 데이터베이스와 해당 대기 데이터베이스 간의 역할 전환입니다. switchover는 데이터 손실을 방지합니다. switchover 동안 primary database가 standby 롤로 전환되고 standby database가 primary 롤로 전환됩니다. 전환 작업을 수행하려면 자율운영 Data Guard 구성의 롤 전환을 참조하십시오.

페일오버는 기본 데이터베이스를 사용할 수 없는 경우입니다. 복구를 수행하면 대기 데이터베이스가 기본 롤로 전환됩니다. 자동 페일오버가 사용으로 설정되지 않은 경우 Fail Over to the Standby in an Autonomous Data Guard Configuration에 설명된 대로 수동 페일오버를 수행할 수 있습니다.

복구 작업 후 데이터베이스의 가용성 및 상태는 다음 두 가지 복구 목표가 특징입니다.

RTO(복구 시간 목표). 페일오버 후 응용 프로그램에서 데이터베이스를 사용할 수 있게 되는 데 필요한 최대 시간인 RTO이며 실패 시점의 적용 지연과 어느 정도 관련이 있습니다. 자율운영 Data Guard의 경우 RTO는 초 단위에서 최대 2분입니다.
RPO(복구 지점 목표). RPO는 실패한 기본 데이터베이스에서 잠재적 데이터 손실이 발생할 수 있는 최대 기간이며 실패 시 전송 지연과 어느 정도 관련이 있습니다. 자율운영 Data Guard의 경우 RPO가 거의 0에 가깝습니다.

페일오버 후 실패한 기본 데이터베이스가 사용 안함으로 설정된 대기가 되고 데이터베이스 연결에 사용할 수 없는 상태로 유지됩니다. reinstate 작업을 수행하여 다시 사용으로 설정하고 정상 대기로 전환할 수 있습니다. 실패한 primary가 standby database로 복원되면 switchover를 수행하여 원래의 primary 롤로 되돌릴 수 있습니다. 복원 작업을 수행하려면 자율운영 Data Guard 구성에서 사용 안함으로 설정된 대기 복원을 참조하십시오.

자동 Failover 또는 Fast-Start Failover

자동 페일오버를 사용하면 지역 장애, 가용성 도메인 장애, Exadata Infrastructure 또는 AVMC(Autonomous Exadata VM Cluster) 장애 또는 ACD 자체 장애로 인해 기본 ACD를 사용할 수 없게 될 때마다 자동으로 대기 ACD로 페일오버됩니다. 이를 Fast-Start Failover라고도 합니다.

ACD에서 자율운영 Data Guard를 구성하는 동안에는 자동 복구를 사용으로 설정할 수 없습니다. ACD 세부정보 페이지에서 자율운영 Data Guard 설정을 업데이트하는 동안만 자동 복구를 사용 또는 사용 안함으로 설정할 수 있습니다.

주:

영역 간 자율운영 Data Guard 설정을 사용하여 Exadata Cloud@Customer에 배치된 Autonomous Database에 대해 자동 복구를 사용으로 설정할 수 없습니다.

첫번째 대기 ACD에 대해 자동 복구가 활성화된 상태에서 두번째 대기 ACD를 추가할 수 없습니다. 따라서 두번째 대기 ACD를 생성하기 전에 자율운영 Data Guard 설정 업데이트를 사용하여 자동 복구를 사용 안함으로 설정하고 필요한 경우 나중에 다시 사용으로 설정합니다.

최대 성능 및 최대 가용성 보호 모드는 모두 자동 복구를 지원합니다.

Maximum availability 모드에서 자동 페일오버를 사용하면 데이터 손실이 전혀 발생하지 않습니다.
최대 성능 모드에서 자동 페일오버는 대기 데이터베이스가 빠른 시작 페일오버 지연 제한에 지정된 값을 초과하여 기본 데이터베이스보다 뒤처지지 않도록 합니다. 기본적으로 Fast Start failover lag limit는 30초로 설정되며 최대 성능 모드에만 적용할 수 있습니다. 이 경우 standby의 적용 지연(잠재적 데이터 손실)이 구성된 지연 제한을 초과하지 않는 경우에만 자동 failover가 가능합니다. Fast Start Failover 지연 제한을 5에서 3600 사이의 값으로 수정할 수 있습니다.

자세한 내용은 자율운영 Data Guard 설정 업데이트를 참조하십시오.

하드웨어 Failure, 가용성 도메인 운용중단 및 지역/국가별 운용중단 외에도 아래 나열된 것과 같이 Fast-Start Failover를 트리거할 수 있는 데이터베이스 상태 조건이 몇 가지 더 있습니다.

데이터베이스 상태 조건	설명
손상된 제어 파일	디스크 오류로 인해 제어 파일이 영구적으로 손상되었습니다.
손상된 딕셔너리	위기 데이터베이스의 딕셔너리 손상입니다. 현재 이 상태는 데이터베이스가 열려 있을 때만 감지할 수 있습니다.
데이터 파일 쓰기 오류	임시 파일, 시스템 데이터 파일 및 언두 파일을 포함한 모든 데이터 파일에서 쓰기 오류가 발생합니다.

자동 failover의 결과로 실패한 primary database의 롤이 Disabled Standby가 되고 잠시 후에 standby database가 primary database의 롤을 맡습니다. 자동 복구가 완료되면 장애 조치가 발생했음을 알리는 메시지가 비활성화된 standby database의 details 페이지에 표시됩니다.

서비스가 이전의 기본 자율운영 컨테이너 데이터베이스 문제를 해결한 후에는 수동 전환을 수행하여 두 데이터베이스를 초기 롤로 반환할 수 있습니다. 대기 데이터베이스를 프로비저닝한 후에는 다음을 포함하여 대기 데이터베이스와 관련된 다양한 관리 작업을 수행할 수 있습니다.

수동으로 기본 데이터베이스를 대기 데이터베이스로 전환
수동으로 primary database를 standby database로 failover합니다.
복구 후 기본 데이터베이스를 대기 롤로 복원하는 중입니다.
standby database를 종료합니다.

다중 대기 데이터베이스 및 자동 복구를 사용하는 자율운영 Data Guard 설정:

수동 복구를 수행하려면 새 대기 데이터베이스가 되는 원래 기본 데이터베이스를 수동으로 복원해야 합니다.
자동 페일오버가 발생할 때마다 Autonomous Database on Dedicated Exadata Infrastructure는 이전 기본 데이터베이스를 대기 데이터베이스로 복원하려고 시도합니다. 그러나 이 시도가 실패하면 수동으로 복원해야 합니다.

스냅샷 대기 데이터베이스

스냅샷 대기 데이터베이스는 대기 ACD(자율운영 컨테이너 데이터베이스)를 스냅샷 대기 ACD로 변환하여 생성된 완전히 업데이트 가능한 대기 데이터베이스입니다. 단계별 지침은 물리적 대기 데이터베이스를 스냅샷 대기로 변환을 참조하십시오.

스냅샷 standby database는 primary database로부터 리두 데이터를 수신하고 아카이브하지만 적용되지는 않습니다. 그러나 Primary Database의 실시간 변경은 적용되지 않으므로 RTO(Recovery Time Objective)가 늘어납니다.

Snapshot Standby 기능은 다양한 사용 사례를 지원하지만 주요 사용 사례는 다음과 같습니다.

기본 및 대기 응용 프로그램 인스턴스를 읽기/쓰기 모드로 기본 및 대기 데이터베이스에 연결하여 초기 구성을 수행합니다.
먼저 스냅샷 대기 데이터베이스를 패치하고 대기 애플리케이션 인스턴스로 테스트하여 패치 안정성을 확인하십시오. 이렇게 하려면 먼저 물리적 대기 데이터베이스를 스냅샷 대기로 변환해야 합니다. 따라서 스냅샷 대기 데이터베이스에 패치를 적용할 수 있습니다.

주:

자동 복구가 사용으로 설정된 상태에서 물리적 대기 자율운영 컨테이너 데이터베이스를 스냅샷 대기로 변환할 수 없습니다.

Snapshot Standby로 변환하는 동안 Snapshot 모드로만 활성화된 새 데이터베이스 서비스를 활성화하거나 Primary Database와 동일한 서비스 집합을 사용할 수 있습니다. 그러나 스냅샷 standby database에서 primary database 서비스를 활성화하면 스냅샷 standby 연결 요청이 primary database로 전달될 수 있습니다(잘못된 데이터베이스 연결 문자열을 사용하는 경우 그 반대로). 따라서 primary database 및 snapshot standby database에 연결하는 동안에는 적절한 연결 문자열을 주의하여 사용해야 합니다.

주:

스냅샷 대기로 새 서비스를 생성하면 스냅샷 대기 ACD에 있는 모든 Autonomous Database에 대한 전자 지갑이 업데이트됩니다. 데이터베이스에 액세스하려면 대기 Autonomous Database에서 전자 지갑을 다시 로드하고 스냅샷 대기 접속 문자열을 사용합니다.

스냅샷 대기 ACD를 Oracle Cloud Infrastructure(OCI)에서 수동으로 물리적 대기 ACD로 다시 변환할 수 있습니다. 자세한 지침은 Convert Snapshot Standby to Physical Standby를 참조하십시오. 스냅샷 대기가 수동으로 물리적 대기로 변환되지 않으면 생성 후 7일 후에 자동으로 물리적 대기로 다시 변환됩니다. 어떤 경우든 스냅샷 대기를 물리적 대기 데이터베이스로 다시 변환하면 스냅샷 대기 데이터베이스에 대한 모든 로컬 업데이트가 폐기되고 기본 데이터베이스에서 수신한 리두 데이터가 적용됩니다.

대기 ACD가 스냅샷 대기 모드에 있으면 기본 ACD에 대해 다음 작업을 수행할 수 없습니다.

자율운영 데이터베이스 생성 또는 종료
자율운영 데이터베이스 확장 또는 축소
자율운영 데이터베이스 복원

상황에 따라 기본 데이터베이스에서 스냅샷 대기로 수동으로 페일오버할 수 있습니다. 이 경우 failover는 스냅샷 standby에 수행된 모든 로컬 갱신 사항을 폐기하고 primary database의 데이터를 적용하여 스냅샷 standby database를 물리적 standby database로 변환합니다. 단계별 지침은 자율운영 Data Guard 구성의 대기로 페일오버를 참조하십시오.

기본 데이터베이스와 해당 스냅샷 대기 데이터베이스 간의 스위치오버는 허용되지 않습니다. 전환을 시도하기 전에 수동으로 스냅샷 대기를 물리적 대기로 변환해야 합니다.

클라이언트 응용 프로그램에서 Standby Database 액세스

Autonomous Data Guard 구성에서는 클라이언트 응용 프로그램이 일반적으로 primary database에 연결되고 primary database에서 작업을 수행합니다.

물리적 대기 데이터베이스에 접속

이러한 일반 연결 외에도 자율운영 Data Guard는 대기 데이터베이스에서 읽기 전용 작업을 수행하는 클라이언트 애플리케이션을 연결할 수 있는 옵션을 제공합니다. 이 옵션을 활용하기 위해 Predefined Database Service Names for Autonomous Databases에 설명된 대로 클라이언트 응용 프로그램은 "_RO"("읽기 전용"의 경우)를 포함하는 데이터베이스 서비스 이름을 사용하여 데이터베이스에 연결합니다.

스냅샷 대기 데이터베이스에 접속

또한 자율운영 Data Guard를 사용하면 읽기/쓰기 작업을 수행하는 클라이언트 애플리케이션을 스냅샷 대기 데이터베이스에 연결할 수 있습니다. 이러한 작업은 스냅샷 대기 데이터베이스의 로컬이며 기본 데이터베이스는 수정하지 않습니다. 스냅샷 대기 데이터베이스에 접속하기 위해 클라이언트 애플리케이션은 자율운영 데이터베이스에 대해 미리 정의된 데이터베이스 서비스 이름에 설명된 대로 "_SS"("스냅샷 대기"의 경우)를 포함하는 데이터베이스 서비스 이름을 사용할 수 있습니다.

주:

standby database가 snapshot standby 모드인 경우 이름에 "_RO" 서비스가 포함된 모든 데이터베이스 서비스는 비활성 상태이므로 연결에 사용할 수 없습니다.

모니터링 지연 시간

자율운영 Data Guard를 사용하는 데이터베이스가 실행 중이므로 사이드 메뉴의 리소스에서 자율운영 Data Guard 연관을 선택하여 데이터베이스(또는 컨테이너 데이터베이스) 세부정보 페이지에서 전송 지연을 모니터하고 지연 시간을 적용할 수 있습니다. 또한 OCI 콘솔 또는 관찰 API를 사용하여 전송 지연을 모니터링하고 알람 및 통지를 구성할 수 있습니다. 자세한 내용은 Database Observability with Autonomous Database Metrics를 참조하십시오.

시간이 지남에 따라 데이터베이스 ebbs 및 흐름의 작업 로드가 약간 변동될 것으로 예상됩니다. 그러나 지연 시간의 상향 추세가 계속 나타나는 경우 다음 작업을 수행하여 상황을 해결할 수 있습니다.

적용 지연의 상향 추세입니다. 적용 지연의 상향 추세가 계속 나타나면 standby database가 primary database에서 가져온 리두 레코드를 따라갈 수 있는 충분한 용량이 없음을 나타냅니다. 이 상황을 해결하려면 Add CPU or Storage Resources to a Dedicated Autonomous Database에 설명된 대로 데이터베이스의 OCPU를 확장합니다.
운송 지연의 상향 추세입니다. 전송 지연 추세가 계속 상승하면 네트워크 성능 문제가 나타납니다. Oracle Cloud 운영 직원은 지속적으로 네트워크 성능을 모니터링하므로 어떠한 조치도 취하지 않고도 상황이 해결되는 것을 확인할 수 있습니다. 그러나 원하는 경우 Create a Service Request in My Oracle Support에 설명된 대로 서비스 요청을 발생시켜 운영 담당자에게 상황을 제공할 수 있습니다.

자율운영 Data Guard 구성 옵션

자율운영 Data Guard가 사용으로 설정된 자율운영 컨테이너 데이터베이스를 생성할 때 대기 데이터베이스를 생성할 Exadata 인프라 및 자율운영 Exadata VM 클러스터 리소스를 지정하고, 사용할 데이터 보호 모드를 지정합니다.

대기 데이터베이스에 사용할 Exadata 인프라 및 자율운영 Exadata VM 클러스터 리소스를 지정할 때 다음 선택사항이 있습니다.

기본 데이터베이스의 Exadata 인프라 및 자율운영 Exadata VM 클러스터와 다른 리전에서:
이 선택은 외부 네트워크 연결의 심각한 손실 또는 전체 영역에 대한 전원을 포함하여 재해에 대한 최고 수준의 보호를 제공합니다.

이러한 영역 간 보호를 최대한 활용하려면 영역 간 보호를 지원하도록 응용 프로그램 계층도 구성해야 합니다. 따라서 응용 프로그램 계층이 이미 이러한 방식으로 구성되었거나 영역 간 보호를 지원하도록 재구성하려는 경우 Oracle은 이 옵션을 선택할 것을 권장합니다.

다른 영역에서 대기 데이터베이스를 찾도록 선택한 경우 Oracle은 최대 성능 보호 모드를 사용할 것을 권장합니다.
기본 데이터베이스의 Exadata 인프라 및 자율운영 Exadata VM 클러스터와 다른 AD(가용성 도메인):
이 옵션은 외부 네트워크 연결의 심각한 손실 또는 지역 내의 가용성 도메인에 대한 전원을 포함하여 재해에 대한 높은 수준의 보호를 제공합니다.

이러한 선택은 애플리케이션 계층에서 데이터 보호와 구성 단순성 간의 적절한 균형을 제공합니다.

다른 가용성 도메인에서 대기 데이터베이스를 찾도록 선택한 경우 Oracle은 최대 가용성 보호 모드를 사용할 것을 권장합니다.
기본 데이터베이스의 Exadata 인프라 및 자율운영 Exadata VM 클러스터와 동일한 가용성 도메인(AD):
이 옵션은 재해에 대한 최소 보호 레벨을 제공하며, Oracle은 이를 선택하지 않을 것을 권장합니다.

기본 데이터베이스의 Exadata 인프라 및 자율운영 Exadata VM 클러스터 리소스가 하나의 가용성 도메인만 있는 영역에 있을 경우, Oracle은 "다른 영역에서" 옵션을 사용할 것을 권장합니다.

동일한 가용성 도메인에서 대기 데이터베이스를 찾도록 선택할 경우 Oracle은 최대 가용성 보호 모드를 사용할 것을 권장합니다.
기본 데이터베이스의 Exadata 인프라 및 자율운영 Exadata VM 클러스터와 다른 테넌시:
적용 대상: Oracle Public Cloud 전용

이 옵션을 선택하면 다른 테넌시의 대기 데이터베이스를 추가하여 데이터베이스가 해당 교차 테넌시 대기 데이터베이스로 복구 또는 스위치오버할 수 있습니다. 원격 테넌시에 스냅샷 대기를 생성할 수도 있습니다. 테넌시 간 대기 데이터베이스를 사용하면 테넌시 간 데이터베이스 마이그레이션에 도움이 될 수 있습니다.

교차 테넌시 Standby Database:
- ECPU 또는 OCPU 컴퓨트 모델로 사용으로 설정할 수 있습니다. 대기 데이터베이스는 기본 데이터베이스와 동일한 계산 모델을 사용해야 합니다.
- 자동 페일오버를 지원하지 않습니다. 대신 수동 페일오버만 사용할 수 있습니다.
- Oracle Cloud Infrastructure 콘솔을 사용하여 추가할 수 없습니다. CLI 또는 REST API를 통해서만 교차 테넌시 대기 데이터베이스를 추가할 수 있습니다.

보호 모드 정보

자율운영 Data Guard는 다음과 같은 데이터 보호 모드를 제공합니다.

최대 가용성. 이 보호 모드는 primary database의 가용성에 손상시키지 않는 최상위 레벨의 데이터 보호 기능을 제공합니다.

primary database는 데이터가 standby에서 수신되었다는 확인을 받을 때까지 트랜잭션을 커밋하지 않습니다(디스크에 기록되지 않음). primary database가 30초 내에 이러한 확인을 받지 못하면 primary database가 다시 승인을 적시에 수신할 때까지 primary database 가용성을 유지하기 위해 최대 성능 모드인 것처럼 작동합니다.

이 보호 모드는 대기 데이터베이스 실패 후 기본 데이터베이스 실패와 같은 이중 결함이 있는 경우를 제외하고 데이터 손실이 없도록 보장합니다.
최대 성능. 기본 보호 모드입니다. 기본 데이터베이스의 성능에 영향을 주지 않는 최상위 레벨의 데이터 보호 기능을 제공합니다.

해당 트랜잭션에 의해 생성된 모든 리두 데이터가 온라인 리두 로그에 기록되는 즉시 primary database가 트랜잭션을 커밋합니다. 또한 리두 데이터를 standby database로 보내지만 트랜잭션 커밋과 관련하여 비동기적으로 수행되므로 standby database에 리두 데이터를 쓰는 지연으로 인해 primary database 성능이 영향을 받지 않습니다.

이 보호 모드는 최대 가용성 모드에 비해 약간 적은 데이터 보호를 제공하며 기본 데이터베이스 성능에 미치는 영향을 최소화합니다.

자율운영 Data Guard 설정의 보호 모드는 OCI(Oracle Cloud Infrastructure) 콘솔에서 변경할 수 있습니다. 단계별 지침은 자율운영 Data Guard 설정 업데이트를 참조하십시오.

자율운영 Data Guard 기능의 기반이 되는 Oracle Data Guard의 보호 모드에 대한 자세한 내용은 Oracle Data Guard 보호 모드 in Oracle Data Guard Concepts and Administration를 참조하십시오.

자율운영 Data Guard 구성 중 최적의 사용법

Autonomous Database는 자율운영 Data Guard로 최대 두 개의 대기 ACD를 생성할 수 있지만, 요구사항에 따라 단일 또는 다중 대기 ACD를 사용하도록 선택할 수 있습니다. 그러나 Autonomous Database가 제공하는 가장 탄력적인 재해 복구 옵션을 사용하려면 한 개의 로컬 대기 ACD 및 한 개의 원격 또는 영역 간 대기 ACD를 데이터 보호 모드로 최대 가용성으로 추가할 수 있습니다.

이 디자인의 이점을 이해합시다:

로컬 대기:
- 동일한 리전의 로컬 대기로 자동 페일오버를 수행하면 로컬 재해 격리 및 애플리케이션 페일오버 단순성이 크게 향상됩니다.
- 로컬 standby database의 업무 가치는 데이터 손실이 없는 failover로 나타나며 응용 프로그램 다운타임은 초 단위로 감소합니다.
- 응용 프로그램 서버와 데이터베이스 간에 동일한 대기 시간을 유지하면서 응용 프로그램이 로컬 Standby Database로 자동 및 투명하게 Failover합니다. 대기 시간이 길수록 처리량과 전체 응용 프로그램 응답 시간에 큰 영향을 줄 수 있으므로 OLTP 및 패키지 응용 프로그램에 특히 중요합니다.
원격 대기:
- 지역 재해로 인해 기본 및 로컬 대기 시스템에 액세스할 수 없는 경우 응용 프로그램 및 데이터베이스가 원격 대기로 페일오버될 수 있습니다.
- 지역 재해 발생 시에도 데이터베이스 다운타임은 여전히 매우 낮지만 보조 리전으로의 DNS, 애플리케이션 및 데이터베이스 페일오버 작업에 필요한 추가 통합관리로 인해 애플리케이션 다운타임이 더 높아질 수 있습니다.
최대 가용성:
- 자동 Failover 또는 FFSFO(Fast Start Failover)가 사용으로 설정된 경우 기본 ACD를 사용할 수 없게 되면 자율운영 Data Guard가 데이터 손실이 없고 애플리케이션의 데이터베이스 대기 시간이 변경되지 않고 로컬 대기 데이터베이스로 페일오버됩니다.
- 자동 Failover 또는 FFSFO(Fast Start Failover)가 사용으로 설정된 경우 전체 기본 영역에 액세스할 수 없게 되면 잠재적 데이터 손실로 인해 시스템이 원격 대기로 페일오버됩니다.

자율운영 Data Guard가 표준 관리 작업에 미치는 영향

경우에 따라 자율운영 컨테이너 데이터베이스에서 수행하는 표준 관리 작업은 표준 컨테이너 데이터베이스와 비교하여 자율운영 Data Guard 구성의 기본 및 대기 컨테이너 데이터베이스에서 다르게 작동합니다. 다음 목록에서는 이러한 차이점에 대해 설명합니다.

유지보수 일정 변경
기본 컨테이너 데이터베이스와 해당 대기 데이터베이스의 유지 관리 일정이 연결됩니다. 대기 데이터베이스에서 유지 관리는 기본 데이터베이스에서 유지 관리되기 며칠 전에 수행됩니다. 기본값은 7일입니다. 기본 컨테이너 데이터베이스를 생성할 때는 1일에서 7일 사이로, 유지 관리 세부 정보를 편집하여 나중에 선택할 수 있습니다.
유지 관리 유형 변경
기본 컨테이너 데이터베이스와 해당 대기 데이터베이스의 유지 관리 유형은 동일해야 합니다. 기본 컨테이너 데이터베이스를 생성할 때나 나중에 Maintenance Details를 편집하여 기본 및 대기 데이터베이스에 대한 유지 관리 유형을 선택합니다.
자동 백업 사용 안함
자율운영 Data Guard로 ACD(자율운영 컨테이너 데이터베이스)를 프로비전하는 동안 자동 백업을 사용 안함으로 설정할 수 없습니다.
스케줄링된 유지 관리 관리 관리
기본 컨테이너 데이터베이스와 해당 대기의 일정이 잡힌 유지보수를 별도로 관리할 수 있습니다. 그러나 두 데이터베이스의 유지 관리가 연결되어 있으므로 예약된 유지 관리 시간을 재정의하도록 선택한 경우 기본 대기 전에 대기 데이터베이스에서 예약된 유지 관리를 수행해야 합니다.
다른 구획으로 이동
기본 및 대기 컨테이너 데이터베이스를 표준 컨테이너 데이터베이스와 마찬가지로 별도로 독립적으로 다른 구획으로 이동할 수 있습니다. 그러나 표준 컨테이너 데이터베이스와 마찬가지로 컨테이너 데이터베이스를 이동할 때는 해당 클라우드 사용자 그룹이 컨테이너 데이터베이스에 계속 액세스할 수 있도록 주의해야 합니다.
재시작
기본 및 대기 컨테이너 데이터베이스를 표준 컨테이너 데이터베이스와 마찬가지로 별도로 독립적으로 재시작할 수 있습니다.
암호화 키를 교체합니다.
기본 ACD 또는 기본 데이터베이스에서 암호화 키를 교체할 수 있습니다.
종료
기본 및 대기 컨테이너 데이터베이스를 별도로 종료할 수 있습니다. 그러나 기본 컨테이너 데이터베이스를 종료하고 대기 컨테이너 데이터베이스를 종료하면 다음과 같은 결과가 다릅니다.
- 기본 컨테이너 데이터베이스를 종료하면 기본 컨테이너 데이터베이스와 대기 컨테이너 데이터베이스가 모두 종료됩니다. 자율운영 데이터베이스를 포함하는 기본 컨테이너 데이터베이스를 종료할 수 없습니다.
- 대기 컨테이너 데이터베이스를 종료하면 대기 컨테이너 데이터베이스가 종료되고 자율운영 Data Guard 구성에서 제거됩니다. 기본 노드만 남아 있는 경우 자율운영 Data Guard 구성이 제거되고 기본 데이터베이스가 독립형 컨테이너 데이터베이스로 전환됩니다.

단계별 가이드

자율운영 컨테이너 데이터베이스에서 자율운영 Data Guard 구성을 관리하는 방법에 대한 단계별 지침은 다음을 참조하십시오.

API를 사용하여 자율운영 Data Guard 구성을 보고 관리할 수도 있습니다. 자세한 내용은 API to Manage Autonomous Data Guard Configuration를 참조하십시오.