Oracle Autonomous Database로 DR 솔루션 구성

재해 발생 시 비즈니스 연속성을 보장하기 위해 Oracle WebLogic Suite 애플리케이션에 대한 DR(재해 복구) 전략을 구현해야 합니다. 이 솔루션은 데이터 보호를 제공하며 Oracle Autonomous Database를 사용하여 데이터 손실과 생산성을 최소화하면서 대기 시스템으로 빠르게 전환할 수 있습니다.

Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace 또는 Oracle Fusion Middleware를 사용하는 기타 중간 계층 Oracle Cloud Infrastructure(OCI) 서비스용 Oracle Autonomous Database를 데이터베이스로 사용하는 재해 복구 시스템을 설정하고 관리할 수 있습니다.

Oracle Autonomous Database Serverless 및 Oracle Exadata Database Service on Dedicated Infrastructure는 스냅샷 대기 기능을 제공합니다. 이렇게 하면 임시로 standby database를 읽기/쓰기로 열 수 있습니다. standby database를 snapshot standby로 변환하면 완전히 갱신할 수 있습니다. 원격 소스 데이터베이스에서 redo 데이터를 계속 수신하지만(그래서 여전히 DR 보호 상태임), 물리적 대기 데이터베이스로 다시 변환될 때까지 redo가 적용되지 않습니다. 스냅샷 대기 데이터베이스에서 수행된 모든 변경 사항은 물리적 대기 데이터베이스로 다시 변환될 때 되돌려집니다. 이 기능을 사용하여 대기 영역에서 중간 계층 시스템을 프로비전합니다. DR 시스템의 수명 주기 동안 이 기능을 사용하여 전체 전환을 수행하지 않고 대기 시스템을 검증할 수도 있습니다.

스냅샷 대기 기능 외에도 Oracle Autonomous Database Serverless는 원격 새로고침 가능 복제본을 제공합니다. 이 기능은 기존 Oracle Data Guard 스냅샷 대기 데이터베이스 기능과 동일한 기능을 제공하지만 추가 데이터베이스를 사용합니다. 원격 새로고침 가능 복제본은 Oracle Autonomous Data Guard 대기와 별도로 개별적으로 관리됩니다. Oracle Autonomous Database Serverless를 사용하는 경우 스냅샷 대기 데이터베이스 대신 원격 새로고침 가능 복제를 사용하여 보조 영역에 중간 계층 시스템을 프로비전하거나 테스트, 검증 열기, 패치 적용 등과 같은 대기 작업을 수행할 수 있습니다. 그러나 대기 및 새로고침 가능 복제본 데이터베이스는 서로 다른 접속 전자 지갑을 사용하며 이러한 작업을 수행하려면 해당 접속 문자열을 제대로 관리해야 합니다.

시작하기 전에

Oracle WebLogic Server for Oracle Cloud Infrastructure 및 Oracle SOA Suite on Marketplace(이러한 미들웨어 시스템에서 Oracle Base Database Service를 사용할 때 DR(재해 복구) 시스템을 설정하는 방법을 설명하는 여러 가지 MAA(Oracle Maximum Availability Architecture) 기술 개요가 있습니다.

Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace 및 Oracle Fusion Middleware DR 토폴로지는 능동-수동 모델을 사용합니다. 기본 시스템은 Oracle Cloud Infrastructure(OCI) 데이터 센터이며 다른 원격 OCI 데이터 센터에 있는 보조 시스템입니다.

각 사례에 대한 자세한 내용과 토폴로지는 다음을 검토하십시오.

위 백서에서는 Oracle WebLogic Server for Oracle Cloud Infrastructure 및 Oracle SOA Suite on Marketplace에 대한 자세한 내용, 설정 및 관리 단계와 기타 여러 고려 사항을 제공합니다.

기술 개요 외에도 이 가이드에 설명된 분석 및 단계를 진행하기 전에 네트워킹, 컴퓨트 인스턴스, 로드 밸런싱 및 Oracle Autonomous Database를 포함한 Oracle Cloud Infrastructure(OCI) 개념 및 관리에 익숙해야 합니다.

이 플레이북의 단계와 예는 다음 시나리오에 대해 OCI용 Oracle WebLogic Server 및 Oracle SOA Suite on Marketplace를 통해 확인됩니다.

Oracle Exadata Database Service on Dedicated Infrastructure의 Oracle Autonomous Data Guard, 재해 복구 설정에 스냅샷 대기 기능 사용.
Oracle Autonomous Database Serverless의 Oracle Autonomous Data Guard, 재해 복구 설정에 스냅샷 대기 기능 사용.
Oracle Autonomous Database Serverless의 Oracle Autonomous Data Guard, 재해 복구 설정에 원격 새로고침 가능 복제본 사용.

세 가지 시나리오에서는 대부분의 단계가 일반적입니다. 일부 단계만 다르며 각각의 경우에 따라 다릅니다.

Oracle Autonomous Database를 사용하는 Oracle WebLogic Server 또는 Oracle Fusion Middleware 시스템에 맞게 단계를 조정하기란 쉽지 않습니다.

구조

이 아키텍처 다이어그램은 이 플레이북에 사용된 접근 방식에 대한 DR(재해 복구) 시스템의 토폴로지를 보여줍니다. 기본 데이터베이스에 상주하는 모든 런타임, 구성 및 메타데이터 정보는 Oracle Autonomous Data Guard를 사용하여 지역 1에서 지역 2로 복제됩니다. Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace 및 Oracle Fusion Middleware DR 토폴로지는 능동-수동 모델을 사용합니다. 기본 시스템은 Oracle Cloud Infrastructure(OCI) 데이터 센터이며 다른 원격 OCI 데이터 센터에 있는 보조 시스템입니다.

Oracle WebLogic 도메인 구성은 기본 영역의 Oracle Cloud Infrastructure File Storage(OCI File Storage) 스테이지 디렉토리를 사용하여 복제되며, 보조 영역의 OCI 파일 스토리지 스테이지 디렉토리로 복제됩니다. 그런 다음 구성이 보조 도메인의 실제 도메인 디렉토리로 복사됩니다. 도메인의 직접 복사본은 스테이지 디렉토리를 사용하여 피할 위험이 있습니다. 파일 복사본은 트랜잭션이 아닌 작업이므로 스테이지 디렉토리에 대한 첫번째 복사가 수행됩니다. 파일은 먼저 이 중간 디렉토리에서 확인된 다음 실제(최종) Oracle WebLogic 도메인으로 전송됩니다.

그림 wls-dr-adb.png에 대한 설명

wls-dr-adb-oracle.zip

토폴로지는 일반적으로 OCI의 Oracle WebLogic Server, Oracle SOA 또는 Oracle Fusion Middleware 재해 복구 환경에서 사용됩니다. 대기 중간 계층을 프로비전하고 보조 테스트와 같은 수명 주기 작업을 위해 대기 Oracle Autonomous Database를 스냅샷 대기 데이터베이스로 변환하거나 원격 새로고침 가능 복제본을 사용합니다.

Remote Refreshable Clone을 사용하는 경우 초기 프로비저닝 및 보조 데이터베이스의 테스트 및 검증 작업에 대한 "보조 데이터베이스"(원격 영역의 새로고침 가능한 복제본)가 있습니다. 이 경우 보조 중간 계층은 데이터 소스로 구성되며 전환 및 페일오버 이벤트 시 대기 주소로 다시 변경해야 합니다.

이 구조는 다음 구성 요소를 지원합니다.

지역
Oracle Cloud Infrastructure 지역은 가용성 도메인이라고 하는 하나 이상의 데이터 센터를 포함하는 지역화된 지리적 영역입니다. 지역은 다른 지역과 독립적이며 거리가 멀면 국가 또는 대륙을 가로질러 분리할 수 있습니다.
가용성 도메인
가용성 도메인은 한 지역 내의 독립형 독립형 데이터 센터입니다. 각 가용성 도메인의 물리적 리소스는 결함 허용을 제공하는 다른 가용성 도메인의 리소스와 격리됩니다. 가용성 도메인은 전원이나 냉각과 같은 인프라나 내부 가용성 도메인 네트워크를 공유하지 않습니다. 따라서 한 가용성 도메인에서 장애가 발생해도 해당 지역의 다른 가용성 도메인에는 영향을 미치지 않습니다.
결함 도메인
장애 도메인은 한 가용성 도메인 내에서 하드웨어와 인프라를 그룹화한 것입니다. 각 가용성 도메인에는 독립 전원과 하드웨어가 있는 장애 도메인 3개가 있습니다. 여러 장애 도메인에 리소스를 분산하면 애플리케이션이 장애 도메인 내부의 물리적 서버 장애, 시스템 유지보수 및 전원 장애를 허용할 수 있습니다.
VCN(가상 클라우드 네트워크) 및 서브넷
VCN은 Oracle Cloud Infrastructure 지역에서 설정한 커스터마이징 가능한 소프트웨어 정의 네트워크입니다. 기존 데이터 센터 네트워크와 마찬가지로 VCN은 네트워크 환경을 완벽하게 제어할 수 있습니다. VCN에는 VCN 생성 후 변경할 수 있는 겹치지 않는 여러 CIDR 블록이 있을 수 있습니다. VCN을 서브넷으로 세그먼트할 수 있으며, 지역 또는 가용성 도메인으로 범위를 지정할 수 있습니다. 각 서브넷은 VCN의 다른 서브넷과 겹치지 않는 연속된 주소 범위로 구성됩니다. 생성 후 서브넷의 크기를 변경할 수 있습니다. 서브넷은 공용 또는 전용일 수 있습니다.
로드 밸런서
Oracle Cloud Infrastructure Load Balancing Service는 단일 시작점에서 백엔드의 여러 서버로 트래픽을 자동으로 배포합니다.
Oracle WebLogic 도메인
도메인은 WebLogic 서버 인스턴스에 대한 기본 관리 단위입니다. 도메인은 단일 Administration Server로 관리하는 하나 이상의 WebLogic 서버 인스턴스(및 연관된 리소스)로 구성됩니다. Oracle WebLogic 도메인은 고가용성을 위한 Oracle Maximum Availability Architecture(MAA) 모범 사례에 따라 구성됩니다.
DRG(Dynamic routing gateway)
DRG는 VCN과 지역 외부 네트워크(예: 다른 Oracle Cloud Infrastructure 지역 내 VCN, 온프레미스 네트워크 또는 다른 클라우드 제공업체의 네트워크) 간 동일한 지역의 VCN 간 전용 네트워크 트래픽 경로를 제공하는 가상 라우터입니다.
보안 목록
각 서브넷에 대해 서브넷에 들어오고 나가야 하는 트래픽의 소스, 대상 및 유형을 지정하는 보안 규칙을 생성할 수 있습니다.
Oracle Cloud Infrastructure File Storage
Oracle Cloud Infrastructure File Storage 서비스는 내구성과 확장성이 뛰어나며 안전한 엔터프라이즈급 네트워크 파일 시스템을 제공합니다. VCN(Virtual Cloud Network)의 베어 메탈, 가상 시스템 또는 컨테이너 인스턴스에서 파일 스토리지 서비스 파일 시스템에 연결할 수 있습니다. 파일 스토리지 서비스에서는 Network File System 버전 3.0(NFSv3) 프로토콜을 지원합니다. 이 서비스에서는 파일 잠금 기능에 사용되는 NLM(Network Lock Manager) 프로토콜을 지원합니다.

Oracle Cloud Infrastructure File Storage는 서로 다른 장애 도메인에 위치한 5방향 복제 스토리지를 사용하여 복원력 있는 데이터 보호를 위한 리던던시를 제공합니다. 데이터는 삭제 인코딩으로 보호됩니다. 이 서비스는 광범위한 사용 사례에서 엔터프라이즈 파일 시스템이 필요한 애플리케이션 및 사용자의 요구를 충족하도록 설계되었습니다.
Autonomous Database
Oracle Autonomous Database는 트랜잭션 처리 및 데이터 웨어하우징 워크로드에 사용할 수 있는 사전 구성된 전담 관리 데이터베이스 환경입니다. 하드웨어를 구성 또는 관리하거나 소프트웨어를 설치할 필요가 없습니다. Oracle Cloud Infrastructure는 데이터베이스 생성, 데이터베이스 백업, 패치, 업그레이드 및 조정을 처리합니다.
Oracle Autonomous Database on Dedicated Exadata Infrastructure
Oracle Autonomous Database on Dedicated Exadata Infrastructure는 퍼블릭 클라우드에 프라이빗 데이터베이스 클라우드를 갖춘 Oracle Autonomous Database입니다. 전용 데이터베이스를 사용하면 완벽한 전용 컴퓨트, 스토리지, 네트워크 및 데이터베이스 서비스를 통해 최고 수준의 보안, 격리 및 거버넌스 수준을 제공할 수 있습니다.
Oracle Autonomous Database Serverless

Oracle Autonomous Database Serverless는 Oracle Autonomous Database입니다. Oracle이 데이터베이스 배치에서 백업 및 업데이트에 이르기까지 데이터베이스 수명 주기의 모든 측면을 자율적으로 운영하는 완전히 탄력적인 데이터베이스가 있습니다.
Data Guard
Oracle Data Guard는 하나 이상의 대기 데이터베이스를 생성, 유지, 관리 및 모니터링하여 운영 Oracle 데이터베이스를 중단 없이 계속 사용할 수 있도록 하는 포괄적인 서비스 세트를 제공합니다. Oracle Data Guard는 이러한 대기 데이터베이스를 운용 중인 데이터베이스의 복사본으로 유지 관리합니다. 그런 다음 계획되거나 계획되지 않은 운용중단으로 인해 운용 중인 데이터베이스를 사용할 수 없게 되면 Oracle Data Guard는 대기 데이터베이스를 운용 롤로 전환하여 운용중단과 연관된 작동 중지 시간을 최소화할 수 있습니다.
Oracle Autonomous Data Guard
Oracle Autonomous Data Guard에서는 대기(피어) 데이터베이스가 Autonomous Database 인스턴스에 대한 데이터 보호 및 재해 복구를 제공할 수 있습니다. 하나 이상의 대기 데이터베이스를 생성, 유지, 관리 및 모니터링하여 운영 Oracle 데이터베이스를 중단 없이 계속 사용할 수 있도록 하는 종합적인 서비스 세트를 제공합니다. Oracle Data Guard는 이러한 대기 데이터베이스를 운용 중인 데이터베이스의 복사본으로 유지 관리합니다. 그런 다음 계획되거나 계획되지 않은 운용중단으로 인해 운용 중인 데이터베이스를 사용할 수 없게 되면 모든 standby database를 운용 롤로 전환하여 운용중단과 연관된 작동 중지 시간을 최소화할 수 있습니다.
스냅샷 대기
{\f2732 snapshot standby database}는 물리적{\f2732 standby database}를 스냅샷{\f2732 standby database}로 변환하여 생성되는 완전히 갱신 가능한{\f2732 standby database}입니다{\f2732 .}

{\f2732 snapshot standby database}는{\f2732 primary database}로부터{\f2732 redo }데이터를 수신하고 아카이브하지만 적용하지는 않습니다{\f2732 .} 스냅샷{\f2732 standby database}에 대한 모든 로컬 갱신 사항을 삭제한 후{\f2732 primary database}에서 수신한{\f2732 redo }데이터는{\f2732 snapshot standby database}가 다시 물리적{\f2732 standby database}로 변환되면 적용됩니다{\f2732 .}
새로고침 가능한 복제
Oracle Autonomous Database는 활성 인스턴스의 전체 복제본을 생성하거나, 메타데이터 복제본을 생성하거나, 새로고침 가능 복제본을 생성하도록 선택할 수 있는 복제를 제공합니다. 새로고침 가능 복제본을 사용하면 시스템이 소스 데이터베이스의 변경사항으로 쉽게 업데이트할 수 있는 복제본을 생성합니다.

중간 계층에 대한 고려 사항

중간 계층에 대한 Oracle WebLogic Server for Oracle Cloud Infrastructure 재해 복구 및 Oracle Cloud Infrastructure Marketplace 재해 복구의 SOA Suite의 모든 고려 사항은 이 문서에 설명된 Oracle Autonomous Database 시나리오에 적용됩니다.

Middle tier의 다음 측면을 고려하십시오.

프론트 엔드 주소
클라이언트에서 Oracle WebLogic Server 시스템으로의 액세스는 기본 사이트로 사용되는 사이트에 영향을 받지 않아야 합니다. 이를 위해 시스템에 액세스하는 데 사용되는 프론트 엔드 주소 이름은 고유해야 하며 항상 기본 시스템을 가리켜야 합니다. 일반적으로 이 이름을 가상 프론트 엔드 또는 베니티 URL이라고 합니다.

기존 시스템의 프론트 엔드 호스트 이름 주소를 재해 보호를 위한 가상 프론트 엔드로 재사용할 수 있습니다. 예를 들어, 원래 시스템의 기본 시스템에 대한 베니티 URL이 mywebapps.example.com인 경우 스위치오버 또는 페일오버 후에 동일한 가상 호스트 이름을 두번째 사이트의 로드 밸런서 IP로 다시 매핑할 수 있습니다.

각 사이트에 매핑할 프런트엔드 이름에 적합한 DNS(Domain Name System) 서비스를 사용합니다. 예: (Oracle Cloud Infrastructure DNS 서비스, 기타 상용 DNS, 로컬 DNS 또는 로컬 호스트 확인)
인스턴스 이름 접두사
OCI용 Oracle WebLogic Server 또는 Oracle SOA Suite on Marketplace를 프로비저닝할 때 Instance Name Prefix를 제공하십시오. 이 등록 정보는 WebLogic 서버 도메인 이름, 클러스터 이름, WebLogic 서버 이름, VM의 호스트 이름 등을 포함하여 모든 리소스의 이름을 구성하는 데 사용됩니다.

두 시스템의 Oracle WebLogic 리소스 이름이 동일하도록 기본 및 보조 Oracle WebLogic Server 시스템에서 Instance Name Prefix를 동일한 값으로 설정합니다. 동일한 이름을 사용하면 일관성이 보장되며 JMS 메시지 및 TLogs 복구에 필요합니다. 또한 두 사이트 모두에서 사용자 정의 및 작업을 단순화합니다.

동일한 Oracle Cloud 테넌시의 여러 인스턴스에서 동일한 Instance Name Prefix를 사용할 수 있습니다(여러 지역 또는 구획에 생성하는 경우). 각 인스턴스는 특정 지역 및 구획에만 표시됩니다.

Oracle SOA Suite on Marketplace 프로비저닝 프로세스는 도메인, 클러스터, 관리 서버, 관리 서버의 접두어 등에 대한 사용자정의 이름을 구성할 수 있는 선택적 기능을 제공합니다. 이 경우 이름은 Instance Name Prefix에서 파생되지 않습니다. 대신 제공된 값을 사용합니다. 제공된 사용자 정의 이름이 기본 및 대기 시스템에서 동일한 경우 이 문서에 설명된 DR(재해 복구) 토폴로지에서 이 기능을 사용할 수 있습니다.
사용자 지정 파일
WebLogic Cloud에서 사용하는 대부분의 OCI용 Oracle WebLogic Server 도메인 구성은 처음에는 사이트 간에 다음 고려 사항과 동기화됩니다.

각 WebLogic 시스템은 DR 설정이 완료된 후에도 로컬 데이터베이스에 연결하는 데 사용되는 원래 JDBC URL을 유지 관리합니다. 두 위치가 동일한 스키마(기본 스키마)를 가리키도록 스키마 접두어만 변경됩니다.

WebLogic 도메인 인프라 기능은 weblogic_domain_name/config 디렉토리의 구성을 동일한 도메인의 다른 노드로 자동으로 배포합니다.

사용자 정의 응용 프로그램 배치(ear/war 파일, 배치 계획 등) 및 Oracle WebLogic Administration Server 도메인 디렉토리 아래에 있는 모든 항목(임시 데이터 제외)은 처음에 이 문서에 설명된 절차를 사용하여 사이트 간에 동기화됩니다. Oracle WebLogic Administration Server에서 다른 노드 또는 도메인 디렉토리 외부에 있는 데이터를 사용하는 경우 수동으로 보조 위치에 복사해야 합니다. 구성 복제에 대한 추가 세부정보는 나중에 제공됩니다.

Oracle Autonomous Database Serverless에서 Snapshot Standby 고려 사항

이 솔루션을 구현할 때 Oracle Autonomous Database Serverless 데이터베이스에서 Snapshot Standby를 사용으로 설정할 때는 다음을 고려하십시오.

서버리스 인프라의 스냅샷 대기 시간 제한
Oracle Autonomous Database Serverless의 스냅샷 대기가 48시간 내에 다시 연결되지 않으면 스냅샷 대기가 소스 데이터베이스에 자동으로 다시 연결됩니다.
재해 복구 피어로 되돌리기
Oracle은 읽기/쓰기 작업을 위해 대기 데이터베이스를 열어야 하는 작업을 수행하는 즉시 스냅샷 대기를 재해 복구 피어로 다시 변환할 것을 권장합니다. 재해 복구 피어로 다시 변환하면 소스 데이터베이스의 누적된 변경 사항이 피어에 적용됩니다. 이 기간 동안 기본 데이터베이스에 진행 중인 변경 사항이 있다고 가정하여 재해 복구 피어를 더 오랫동안 스냅샷 대기로 열어 두면 재해 복구 피어로 다시 변환하는 데 시간이 더 오래 걸립니다.
Oracle Autonomous Database Serverless에서 스냅샷 대기의 비용 영향
스냅샷 대기 CPU 사용량은 컴퓨트 자동 스케일링이 사용으로 설정된 경우 기본 CPU 수 및 추가 CPU 사용량에 따라 비용이 청구됩니다. 기본 CPU 수는 Oracle Cloud Infrastructure 콘솔의 ECPU 개수 또는 OCPU 개수 필드에 표시된 대로 ECPU(데이터베이스가 OCPU를 사용하는 경우 OCPU) 수로 지정됩니다.

스냅샷 대기 스토리지 사용량은 스냅샷 대기의 스토리지에 소스 기본 데이터베이스의 스토리지의 1배를 더한 값을 기준으로 청구됩니다.

자세한 내용은 재해 복구 스냅샷 대기 데이터베이스 정보를 참조하십시오.

Oracle Autonomous Database on Dedicated Exadata Infrastructure의 Snapshot Standby 고려 사항

이 솔루션을 구현할 때는 Oracle Autonomous Database on Dedicated Exadata Infrastructure에서 Snapshot Standby를 사용으로 설정할 때 다음 사항을 고려하십시오.

전용 인프라의 스냅샷 대기 시간 제한
Oracle Autonomous Database on Dedicated Exadata Infrastructure의 스냅샷 대기가 7일 내에 물리적 대기로 변환되지 않으면 스냅샷 대기가 자동으로 물리적 대기로 변환됩니다.
물리적{\f2732 standby database}로 다시 변환
Oracle은 읽기/쓰기 작업을 위해 대기 데이터베이스를 열어야 하는 작업을 마치는 즉시 스냅샷 대기를 물리적 대기로 다시 변환할 것을 권장합니다. 물리적{\f2732 standby database}를 다시 변환하면 원본 데이터베이스의 누적된 변경 사항이{\f2732 standby}에 적용됩니다{\f2732 .} {\f2732 standby database}를 더 오랫동안{\f2732 snapshot standby}로 열린 상태로 유지하는 경우 이 시간 동안{\f2732 primary database}가 계속 변경되어도 물리적{\f2732 standby database}로 다시 변환하는 데 시간이 더 오래 걸립니다{\f2732 .}
스냅샷 대기로 변환할 때의 데이터베이스 서비스
Oracle Autonomous Database on Dedicated Exadata Infrastructure에서 "스냅샷 대기로 변환" 대화상자에 두 가지 옵션이 표시됩니다.
- 새 데이터베이스 서비스 사용: 스냅샷 대기 모드에서만 활성화되는 새 서비스를 사용하여 스냅샷 대기에 접속하려면 이 옵션을 선택합니다.
- 기본 데이터베이스 서비스 사용: 기본 데이터베이스와 동일한 서비스를 사용하여 스냅샷 대기 데이터베이스에 접속하려면 이 옵션을 선택합니다.
재해 복구 설정을 위해 대기를 물리적 대기로 변환할 때 기본 데이터베이스 서비스 사용 옵션을 사용합니다. 이렇게 하면 보조 중간 계층에서 Oracle WebLogic Server에 의해 구성된 연결 별칭 이름이 기본 이름과 일치합니다.

자세한 내용은 자율운영 Data Guard 정보를 참조하십시오.

Oracle Autonomous Database Serverless에서 원격 새로고침 가능 복제본 고려 사항

Oracle Autonomous Database Serverless 새로고침 가능 복제를 사용하여 보조 Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace 또는 Oracle Fusion Middleware 시스템을 테스트하고 검증하는 경우 다음을 고려하십시오.

새로 고칠 수 있는 복제본 수명 주기
기존 Oracle Data Guard Standby와 달리 Remote Refresh 가능 복제본은 별도로 사용으로 설정되고 Primary 및 Standby와 별도로 관리됩니다. 이 개체는 소스 데이터베이스(기본)와 동기화되는 새로고침 작업을 넘어 자체 수명 주기를 가진 별도의 개체입니다.
CPU 리소스 할당
원격 새로고침 가능 복제본은 기본 또는 대기 시스템의 CPU 리소스 할당에 따라 생성되지 않습니다. 따라서 Refreshable Clone에 대해 OCPU 옵션을 별도로 지정해야 합니다. 기본 시스템의 용량과 일치하도록 원격 새로고침 가능 복제본에서 작업 로드 테스트를 수동으로 구성해야 합니다. 테스트 작업량이 보조 데이터베이스에서 현실적이 되도록 기본 데이터베이스와 일치하는 구성으로 원격 새로고침 가능 복제본을 생성하는 것이 이상적입니다. 그러나 원격 새로고침 가능 복제본은 기본에서 사용된 스토리지 구성을 "이동"합니다.
패치 작업
주별 유지보수 기간별로 Oracle Autonomous Database Serverless에서 매주 패치가 자동으로 적용되므로 주, 대기 및 원격 새로고침 가능 복제본 간에 패치가 지속적으로 강제 동기화됩니다.
Service limits(서비스 제한)
원격 새로고침 가능 복제본은 일류 엔티티로, 공식 Autonomous Database의 스토리지, CPU 및 라이센스 영향당 추가 비용이 발생하며 Oracle Autonomous Database Serverless에 대한 해당 지역의 서비스 한도에 포함됩니다.
스위치오버 시 새로 고칠 수 있는 복제
페일오버 또는 "비즉시 전환할 수 있는 스위치오버"가 수행되면 기본 시스템에 새로 고침 가능한 복제본을 수동으로 만들어 현재 보조 시스템인 테스트 및 유지 관리 작업에 대비한 시스템을 적절한 서비스 제한, 관리 및 기타 고려 사항과 함께 유지해야 합니다. 원격 새로고침 가능 복제본에는 롤 취소 제어가 없습니다.

보조로 스위치오버한 후 생성된 새로고침 가능 복제본은 더 이상 새로고침할 수 없으며(소스가 대기 상태이므로) 접속이 해제된 것으로 표시됩니다. 24시간이 지나면 새로고침이 불가능하고 연결이 끊긴 복제본이 됩니다.
새로 고칠 수 있는 복제본 새로고침 창
적어도 일주일에 한 번 원격 새로고침 가능 복제본을 새로 고쳐야 합니다. 그 후에 기본 데이터와 동기화하려면 새 원격 새로고침 가능 복제본을 생성하고 새로 고치지 않은 복제본을 폐기해야 합니다.
새로 고칠 수 있는 복제본 쓰기 모드
원격 새로고침 가능 복제본은 24시간 이상 쓰기 모드(기본에서 접속 해제)에 있을 수 없습니다. 이 기간이 지나면 원격 새로고침 가능 복제 데이터베이스를 해당 기본 데이터베이스에 다시 연결할 수 없습니다. 그 후에 기본 데이터와 동기화하려면 새 Remote Refreshable Clone을 만들고 새로 고치지 않은 클론을 폐기해야 합니다.

`tns_admin` 구성 폴더 위치에 대한 고려 사항

tns_admin 구성 폴더에 대해 다음을 고려하십시오.

tns_admin 폴더에 대해 일관된 위치 사용
WebLogic 도메인의 중간 계층은 폴더를 사용하여 Oracle Autonomous Database 전자 지갑 및 tnsnames.ora 파일을 저장합니다. oracle.net.tns_admin 속성은 데이터 소스 및 jps 구성 파일에서 이 폴더를 가리킵니다. 이 폴더의 경로는 기본 및 대기 중간 계층에서 동일해야 합니다. 폴더 경로가 다른 경우 DR(재해 복구) 설정 스크립트를 실행하기 전에 기본 또는 대기 폴더에서 동일한 폴더를 사용하도록 폴더를 변경합니다.
참고:
다음은 이 폴더 위치에서 기본 및 대기 간에 차이를 발생시킬 수 있습니다.
- 2023년 2월 말(릴리스 23.1.1 이전) 이전에 프로비전된 Oracle SOA Suite on Marketplace 인스턴스는 tns_admin 폴더에 $DOMAIN_HOME/config/atp를 사용합니다. 릴리스 23.1.1부터는 위치가 $DOMAIN_HOME/config/tnsadmin입니다.
domain config 폴더 아래의 tns_admin 폴더
WebLogic 데이터 소스 구성에서 Oracle Autonomous Database 전자 지갑의 위치를 확인합니다. 전자 지갑이 DOMAIN_HOME/config 디렉토리 아래에 없는 경우 전자 지갑 디렉토리의 콘텐츠에 대한 변경사항은 Oracle WebLogic Server 기반 구조에 의해 자동으로 다른 노드로 복제되지 않습니다. 이 경우 전자 지갑 디렉토리를 변경하고 필요한 데이터 소스 구성을 업데이트하거나 업데이트될 때 다른 노드에 수동으로 복사해야 합니다.