Creating a Physical Standby using RMAN Duplicate (RAC or Non-RAC)
(Doc ID 1617946.1)
Last updated on APRIL 26, 2024
Applies to:
Oracle Database - Enterprise Edition - Version 12.1.0.2 and laterInformation in this document applies to any platform.
Goal
For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:
Primary hosts: exa503,exa504
Standby hosts: exa505,exa506
Primary Db_unique_name: CHICAGO
Standby Db_unique_name: BOSTON
Primary instance names: chicago1, chicago2
Standby instance names: boston1, boston2
Service name: srv_rman
Maximum Availability Architecture
The Maximum Availability Architecture (MAA) defines Oracle’s most comprehensive architecture for reducing downtime for scheduled outages as well as preventing, detecting and recovering from unscheduled outages. Real Application Clusters (RAC) and Oracle Data Guard are integral components of the Database MAA reference architectures and solutions.
More detailed information, such as a discussion of the purpose of MAA and the benefits it provides, can be found on the Oracle Technology Network (OTN) at http://www.oracle.com/technetwork/database/features/availability/maa-096107.html
Purpose of this Document
The purpose of this document is to provide a step-by-step guide for creating a standby database in an 11.2 environment integrating the MAA Data Guard configuration best practices. This paper assumes that the following conditions exist:
- A Primary RAC or single instance database utilizing ASM for data file storage
- The Primary database is in archive log mode
- All Standby target hosts have existing Oracle software installation
- The Standby target database storage will utilize ASM
- It is recommended that you consult the Data Guard Concepts and Administration guide as well as the HA Best Practice guide for more information and full MAA Best Practices.
Supported Versions
This document applies to both Oracle Server versions 11.2.0.x and 12.1.0.x or higher. There are some important differences in how the DUPLICATE FOR STANDBY FROM ACTIVE DATABASE functions between the two releases which are noted below:
11.2:
- DUPLICATE FROM ACTIVE DATABASE uses datafile image copies and does not support section size, compression, or encryption.
12c:
- DUPLICATE FROM ACTIVE DATABASE supports backup sets.
- SECTION SIZE support is available. If section size is used, then use multiple auxiliary channels for parallelism.
- Compression is supported but do not use compression on backups or data that has already been compressed (e.g. using OLTP, HCC compression) or encrypted since the compression benefits is very small and the overall impact (e.g. CPU resources and increased in elapsed time) can be significant.
- Encryption is supported.
All of the examples illustrated in this document use the following fictitious naming used only as examples to describe the procedure:
Hosts and Databases used in this Example |
||
|
Primary |
Standby |
Hosts |
exa503, exa504 |
exa505, exa506 |
Database Unique Name |
chicago |
boston |
Instance names |
chicago1, chicago2 |
boston1, boston2 |
Solution
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
Goal |
Solution |
References |