Creating a Physical Standby database using RMAN restore from service
(Doc ID 2283978.1)
Last updated on AUGUST 14, 2020
Applies to:
Oracle Cloud Infrastructure - Database Service - Version N/A and laterOracle Database Backup Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Information in this document applies to any platform.
Goal
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
Starting in Oracle 12.1, the RMAN “restore..from service” clause can be used to simplify the instantiation of a standby database through an Oracle Net connection to the primary database. The purpose of this document is to provide a step-by-step guide for creating a physical standby database utilizing the ‘from service’ clause.
- This document applies to Oracle Database Server versions 12.1 or higher.
- SECTION SIZE support is available. The section size clause used with multiple RMAN channels enables parallelization of the restore by dividing large files into smaller pieces to more efficiently utilize the parallel processes.
- Encryption is supported.
- Compression is supported. It is not recommended to 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 elapsed time) can be significant.
About RMAN Restore..from Service
The RMAN ‘restore..from service’ clause enables the restore and recover of primary database files to a standby database across the network. This functionality can be used to instantiate a standby database in lieu of the RMAN DUPLICATE DATABASE command and is more intuitive and less error prone thus saving time. Additionally, utilizing the SECTION SIZE clause with multiple RMAN channels improves the efficiency of parallelization of the restore, further improving the time required to instantiate.
This paper assumes that the following conditions exist:
- The network between the Primary and Standby sites has been assessed and determined to support the peak redo generation rate of the primary. See note 2064368.1 for details on assessing the network.
- A Primary database utilizing ASM for data file storage as well as Oracle Managed Files(OMF).
- The Primary database is in archive log mode.
- Password and Spfile are stored in ASM.
- The target Standby host has all the required Oracle software installed and configured.
- The Standby target database storage will utilize ASM storage and OMF.
- The Standby target resides on separate hardware.
- If role separation is used in your environment set the environment based on the roles with oracle or grid. In our example the oracle user owns both grid and oracle software installations.
All of the example names illustrated in this document use the following naming:
Hosts and Databases Used in this Example |
||
|
Primary |
Standby |
Hosts |
<primaryhost1>,<primaryhost2> |
<standbyhost1>,<standbyhost2> |
Database Unique Name |
<primary unique name> |
<standby unique name> |
Instance names |
<primary unique name>1, <primary unique name>2 |
<standby unique name>1, <standby unique name>2 |
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 |
Steps to Create a Physical Standby Database using “restore from service” |
Force Logging |
Create Standby Redo Logs |
Enable Standby File Management |
Password Copy |
Create net alias for the primary and standby databases. On each host create the local_listener entry to match the <node-vip> on that host. |
Create a pfile from the spfile on the primary database. |
On all standby hosts create the audit directory for the standby database. |
On the standby hosts, determine the IB IP's. |
Modify the parameters on the Primary/Standby to include data guard parameters and on the Standby update the instance specific RAC parameters. For example: |
Copy the modified pfile to the first standby host and mount the standby database. |
Update the Control File parameter |
Start the Standby instance |
Enable Parallelism |
Restore the Standby Database from the primary database service |
Store the password file in ASM |
Register the standby database with clusterware |
Set the parameters and create the Broker configuration. |
Stop and Start the standby database |
Validate broker configuration |
References |