Creating a Physical Standby using RMAN Duplicate (RAC or Non-RAC).pdf

吾喾

440

9页

0次

2022-07-07

5墨值下载

2022/7/7 16:07

Document 1617946.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=358247282051399&id=1617946.1&_afrWindowMode=0&_adf.ctrl-state=435

…

1/9

PowerView is Off

Last Login: July 7, 2022 3:48 PM CST

(0)

xingjian (Available)

In this Document

Goal

Solution

References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.1.0.2 and later

Information in this document applies to any platform.

GOAL

NOTE: In the images and/or the document content below, the user information and environment data used

represents fictitious data from the Oracle sample schema(s), Public Documentation delivered with an Oracle

database product or other training material. Any similarity to actual environments, actual persons, living or

dead, is purely coincidental and not intended in any manner.

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:

1. A Primary RAC or single instance database utilizing ASM for data file storage

2. The Primary database is in archive log mode

3. All Standby target hosts have existing Oracle software installation

4. 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

Was this document helpful?

Document Details

Type:

Status:

Last Major

Update:

Last

Update:

Language:

HOWTO

PUBLISHED

29-Oct-2019

30-Dec-2021

English

Recently Viewed

Creating a Physical Standby using RMAN Duplicate (RAC or Non-RAC) (Doc ID 1617946.1)

To Bottom

Yes

Creating a Physical

Standby using RMAN

Duplicate (RAC or Non-

RAC) [1617946.1]

收集数据库升级/迁移诊断

信息的脚本

(dbupgdiag.sql)

[1577288.1]

Script to Collect DB

Upgrade/Migrate

Diagnostic Information

(dbupgdiag.sql)

[556610.1]

Latest Java SE Patch

Updates on MOS

[1414485.1]

Oracle Java SE 7 End of

Extended Support

[2809708.1]

Dashboard Service Requests Patches & UpdatesKnowledge

Give Feedback...

2022/7/7 16:07

Document 1617946.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=358247282051399&id=1617946.1&_afrWindowMode=0&_adf.ctrl-state=435

…

2/9

Primary Standby

Hosts exa503, exa504 exa505, exa506

Database Unique Name chicago boston

Instance names chicago1, chicago2 boston1, boston2

SOLUTION

Prerequisite:

To expedite active database RMAN duplicate commands, use multiple RMAN channels to spread across primary nodes. By doing

this we can utilize more network interfaces for the data transfer.

Parallelize backups across all primary database nodes leveraging disk and network bandwidth as available.

MAA best practice recommend using 8 channels minimum or 2 channels per node.

Use automatic load balancing to distribute RMAN channels among the allocated nodes. With auto load balancing the channel

distribution is approximate point in time. Analyze the impact on existing production databases and reduce the RMAN parallelism

if necessary.

Make the following RMAN configuration changes at the Primary. Our example uses 16 pre-configured channels for RMAN to use

during the standby creation step. These 16 channels will suffice for 2-4 node RAC clusters but will need to be increased if your

Production RAC cluster is larger than 4 nodes.

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 16;

You will use Oracle Net service load balancing to distribute these RMAN channels evenly among the allocated instances.

1) Create a service to run RMAN on allocated instances in the cluster:

srvctl add service –db chicago -service srv_rman -preferred chicago1,chicago2

srvctl start service -db chicago -service srv_rman

Note: If you need to restrict the RMAN process to specific instances only specify those instances in the service definition

2) When running RMAN, use the service name in the connect string for the “target” parameter.

rman target sys/<password>@<prim_scan>/srv_rman

Steps to Duplicate the Primary Database

The following are the steps used to create the Data Guard Standby database. The ORACLE_HOME used in the examples uses the

latest release Oracle 12.2. Please change as per your environment.

1. Create standby redo logs on the primary database that are the same size of the online redo logs. This will ensure that

standby redo log files are automatically created at the standby during the RMAN duplication process and that standby redo log

files are available on the current Primary after a role transition occurs in the future and the Primary becomes a standby.

Oracle recommends having the same number of standby redo log files as there are online redo log files plus one additional

standby redo log for each thread. Our primary database has 6 online redo log files, 3 per thread. We therefore need 4 Standby

Redo Log files per thread (Primary 3 plus 1) for a total of 8 Standby Redo Log files. As per MAA Best Practice we recommend to

create only one member for standby redo log . For example:

SQL> alter database add standby logfile thread 1

group 7 ('+DATAC1') size 512M,

group 8 ('+DATAC1') size 512M,

group 9 ('+DATAC1') size 512M,

group 10 ('+DATAC1')size 512M;

SQL> alter database add standby logfile thread 2

group 11 ('+DATAC1') size 512M,

group 12 ('+DATAC1') size 512M,

group 13 ('+DATAC1') size 512M,

group 14 ('+DATAC1') size 512M;

2. Database force logging is recommended as an MAA Data Guard best practice. To enable force logging, use the following

command on the primary:

SQL> alter database force logging;