You are on page 1of 45

Business Continuity for Oracle E-Business Release 12.

1 Using Oracle 11g Release 2


Physical Standby Database (Doc ID 1070033.1)

Oracle E-Business Suite Release 12 has numerous configuration options that can be chosen to
suit particular business scenarios, hardware capabilities, and availability requirements.

This document describes how to configure an Oracle E-Business Suite Release 12 environment
to use Oracle Database 11gR2 as physical standby.

The most current version of this note is available as My Oracle Support Knowledge Document
1070033.1, Business Continuity for Oracle E-Business Suite Release 12 Using Oracle 11g
Release 2 Physical Standby Database.

This document applies to Oracle Database 11g Release 2. For Oracle Database 11g Release 1,
refer to My Oracle Support Knowledge Document 1545920.1, Business Continuity for Oracle
E-Business Suite Release 12 Using Oracle 11g (11gR1) Physical Standby Database.

There is a change log at the end of this document.

In This Document

This document is divided into the following sections:

Section 1: Overview
Section 2: Before You Start

Section 3: Preparing the Primary Database for Standby Database Creation

Section 4: Creating a Physical Standby Database

Section 5: Configuration on Application Tiers After Standby Database is Enabled

Section 6: Role Transitions

Section 7: Oracle E-Business Suite Maintenance With Standby Database

Appendix A: Oracle Net Files

Appendix B: Using Oracle Applications Manager to Register Standby Database

Appendix C: Example Standby Database Commands

Appendix D: Using RMAN to Create Physical Standby Database


Appendix E: RAC RMAN Clone Example

Appendix F: Using adclone scripts to clone Oracle RAC primary to standby

Appendix G: Creating Non-RAC Standby for RAC Primary

Appendix H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases

Note: While the general concepts in this paper apply to all operating systems and hardware
architectures that Oracle supports, the procedure has not been validated on the Windows
platform.

A number of conventions are used in this document:

Convention Meaning
Application Machines running forms, web, concurrent processing and other servers.
tier Sometimes called middle tier.
Database tier Machines running Oracle E-Business Suite database.
Primary Primary Oracle E-Business Suite system, which will be used to create a
system standby system.
Standby
Oracle E-Business Suite system created as a copy of the production system.
system
oracle User account that owns the database file system (database ORACLE_HOME and files).
CONTEXT_NAME
The CONTEXT_NAME variable specifies the name of the applications context that is
used by AutoConfig. The default is <SID>_<hostname>.
STNDBY_CONTEXT The default is <SID>_<stdby_hostname>.
Full path to the applications context file on the application tier or database tier.
The default locations are as follows:
CONTEXT_FILE Application tier context file: <INST_TOP>/appl/admin/CONTEXT_name.xml

Database tier context file: <RDBMS_ORACLE_HOME>/appsutil/<CONTEXT_name>.xml


APPSpwd Oracle E-Business Suite database user password.
If the appsTier and dbTier are on different hosts, either choose:
/tmp or /usr/tmp

APPLTMP If the appsTier and dbTier are on the same host, then there are more options
like:
/tmp, /usr/tmp, or
$RDBMS_ORACLE_HOME/appsutil/outbound/<CONTEXT_NAME>
Monospace Text
Represents command line text. Type such a command exactly as shown,
excluding prompts such as '%'.
Text enclosed in angle brackets represents a variable. Substitute a value for the
<>
variable text. Do not type the angle brackets.
On UNIX, the backslash character can be entered at the end of a command line
\
to indicate continuation of the command on the next line.
Primary database
alias TNS alias to connect to primary database.
Standby TNS
Alias TNS alias to connect to standby database

Note: This document covers both non-RAC and RAC configurations. "Note for Oracle RAC
configurations" denotes a step specific to Oracle RAC.

Section 1: Overview

1.1 Standby Database


1.2 Oracle Data Guard
1.3 Oracle Data Guard Broker

1.1 Standby Database

A standby database is a transactionally consistent copy of the primary database. Using a backup
copy of the primary database, you can create up to 30 standby databases and incorporate them
in Oracle Data Guard configuration.

Standby databases can be of three types:

Physical Standby
Provides a physically identical copy of the primary database, with on-disk database
structures that are identical to the primary database on a block-for-block basis. The
database schemas, including indexes, are the same. A physical standby database is kept
synchronized with the primary database by recovering the redo data received from the
primary database.

Logical Standby
Contains the same logical information as the primary database, although the physical
organization and structure of the data can be different. It is kept synchronized with the
primary database by transforming the data in the redo logs received from the primary
database into SQL statements and then executing the SQL statements on the standby
database.

Snapshot Standby
A fully updatable standby database. Like a physical or logical standby database, a
snapshot standby database receives and archives redo data from a primary database.
Unlike a physical or logical standby database, a snapshot standby database does not
apply the redo data that it receives.

This document details the steps for setting up the first of these types, a physical standby
database.

Note: Logical standby databases are not supported with Oracle E-Business Suite standard
functionality. Snapshot standby databases should be used with caution as the data will be out of
sync with the primary.

1.2 Oracle Data Guard

Oracle Data Guard is a set of services that creates, manages, and monitors one or more standby
databases to enable a primary database to survive disasters and data corruption. If the primary
database becomes unavailable due to a planned or an unplanned outage, Oracle Data Guard can
switch a standby database to the primary role, minimizing the downtime.

Oracle Data Guard offers three modes of data protection:

Maximum Protection
This mode offers the highest level of data protection. Data is synchronously transmitted
to the standby database from the primary database, and transactions are not committed
on the primary database unless the redo data is available on at least one standby
database configured in this mode. If the last standby database configured in this mode
becomes unavailable, processing stops on the primary database. This mode guarantees
no data loss.

Maximum Availability
This mode is similar to the maximum protection mode, including no data loss.
However, if a standby database becomes unavailable (for example, due to network
connectivity problems), processing continues on the primary database. When the fault is
corrected, the standby database is resynchronized with the primary database. If there is
a need to fail over before the standby database is resynchronized, some data may be
lost.

Maximum Performance
This mode offers slightly less data protection on the primary database, but higher
performance than maximum availability mode. In this mode, as the primary database
processes transactions, redo data is asynchronously shipped to the standby database.
The commit operation on the primary database does not wait for the standby database to
acknowledge receipt of redo data before completing write operations on the primary
database. If any standby destination becomes unavailable, processing continues on the
primary database, and there is little effect on primary database performance.

1.3 Oracle Data Guard Broker

The Oracle Data Guard broker is a distributed management framework that automates and
centralizes the creation, maintenance, and monitoring of Data Guard configurations.

The Data Guard broker logically groups the primary and standby databases into broker
configuration that allows the broker to manage and monitor them together as an integrated unit.

The Data Guard broker consists of three components:

Data Guard GUI through Enterprise Manager


Data Guard Command-line interface (DGMGRL)

Data Guard Monitor

The following describes the operations that the broker automates and simplifies:

Standby Database Creation


Provides the Enterprise Manager wizards that automate and simplify the steps required
to create a configuration with an Oracle database on each site, including creating the
standby control file, online redo log files, data files, and server parameter files.

Note: Customers should follow this document for setting up a physical standby, as is it
includes steps specific to Oracle E-Business Suite.

Role Transitions
Simplifies the switchover and failover process, including automatically setting up redo
transport and log apply services, and automating failover.

Note: Fast-start failover is currently not supported for Oracle E-Business Suite. For
further details, see Appendix H: Using Data Guard Broker [DGMGRL] to manage
Standby Databases.

Monitoring
Provides continuous monitoring of the configuration health, database health, and other
runtime parameters.

Section 2: Before You Start

2.1 Design Considerations


2.2 Software Prerequisites
2.1 Design Considerations

This note assumes you have already provided a secondary site for your standby environment. In
general, the secondary data center should:

Be physically separate from the primary environment, to protect against local and
regional disasters. It is common for a corporation to put its business continuance
environment in a data center in a different city than its primary data center.
Have network bandwidth between data centers sufficient to handle peak redo data
generation plus, if you choose to synchronize your concurrent manager output,
synchronization of report log and output files.
Have reliable and efficient network services to the primary data center, to the standby
data center, and to the user point of presence.
Have the same type of servers as at the primary site, in the desired number for DR
protection.

The reader of this document should be familiar with the Oracle11g database server and have at
least a basic knowledge of standby database configurations.

Refer to the following documentation for further information:

Oracle Database Administrator's Guide 11g Release 2 (11.2)


Oracle Data Guard Concepts and Administration 11g Release (11.2)

In addition, you should be familiar with the following Oracle E-Business Suite Release 12
documentation:

My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications


Release 12 with Rapid Clone
My Oracle Support Knowledge Document 559518.1, Cloning Oracle Applications
Release 12 RAC-Enabled Systems with Rapid Clone [Oracle RAC environments only]
My Oracle Support Knowledge Document 823587.1, Using Oracle 11g Release 2 Real
Application Clusters with Oracle E-Business Suite Release 12 [Oracle RAC
environments only]

2.2 Software Prerequisites

This document assumes the following minimum software versions:

Software Applicable
Additional Information
Component Version
Oracle E- 12.0.4 or higher This document was developed using a fresh install database
Business Suite and 12.1.x from an Oracle E-Business Suite Release 12.1.1 Rapid
Install with the prerequisite patches listed in My Oracle
Support Knowledge Document 406982.1, Cloning Oracle
Applications Release 12 with Rapid Clone, applied.
For Oracle RAC enabled systems, additional prerequisite
patches listed in My Oracle Support Knowledge Document
559518.1, Cloning Oracle E-Business Suite Release 12
RAC-Enabled Systems with Rapid Clone, were applied.
Database upgraded by following My Oracle Support
Knowledge Document 1058763.1, Interoperability Notes
11.2.0.1.0, EBS 12.0 and 12.1 with Database 11gR2.
Oracle Database 11.2.0.2.0, For Oracle RAC configurations: Databases configured for
11gR2 11.2.0.3.0, Oracle RAC should refer to My Oracle Support
11.2.0.4.0 Knowledge Document 823587.1, Using Oracle 11g Release
2 Real Application Clusters with Oracle E-Business Suite
Release 12.

The standby system must use the same database and Oracle E-Business Suite versions.

This document refers to the following top-level directories:

Directory Purpose
RDBMS_ORACLE_HOME Oracle 11g R2 Database ORACLE_HOME
APPL_TOP Directory that contains the application product directories and files.
COMMON_TOP
Directory that contains directories and files used across application
products
OracleAS 10.1.2 ORACLE_HOME installed by Oracle E-Business Suite on the application
ORACLE_HOME
tier
INST_TOP Directory that contains application instance directories and files

Prerequisite Patches:

For both Oracle RAC and non-RAC, apply the Oracle E-Business Suite one-off Patch
20319158. This patch keeps the internal monitor active after the database configuration in
section 6.2.7 in a failover event. Without this patch internal monitor is disabled in standby site
after failover.

Note: Ensure that you have applied all of the required application and database patches for
cloning as discussed in My Oracle Support Knowledge Document 406982.1, Cloning Oracle
Applications Release 12 with Rapid Clone.

Section 3: Preparing the Primary Database for Standby Database Creation

At this point, you have a server to create the physical standby. The top-level mount points on
each secondary site server are exactly the same as on their matching primary site server.
Ownership and permissions are set appropriately for each mount point. You have a mechanism
in place for making remote file copies, including network connectivity as well as appropriate
system permissions. The configuration steps are divided up as follows:

3.1 Enable Forced Logging


3.2 Configure Oracle Net Communication To and From Standby
3.3 Set Up Secure Connections
3.4 Set Primary Database Initialization Parameters
3.5 Enable Archive Logging on the Primary System
3.6 Add Standby Redo Logs
3.7 Invite Communications From the Standby
3.8 Gather Temporary File Information
3.9 Run the Application Tier and Database Pre-Clones
3.10 Copy APPL_TOP and Oracle E-Business Suite Technology Stacks to Application Tiers in
Standby Environment

3.1 Enable Forced Logging

To protect against unlogged direct writes in the primary database that cannot be propagated to
the standby database, turn on FORCE LOGGING at the primary database before performing data file
backups for standby creation.

Place the primary database in FORCE LOGGING mode by using the following SQL statement:
SQL>ALTER DATABASE FORCE LOGGING;

Note: This statement may take a considerable amount of time to complete, because it has to
wait for all unlogged direct write I/O operations to finish.

3.2 Configure Oracle Net Communication To and From Standby System

The primary and standby databases need to be able to communicate using Oracle Net. This
means that on the standby, a listener needs to be running to handle incoming requests from the
primary. In addition, TNS aliases must be created on both the primary and standby systems. For
both aliases and listener, you should configure ifiles under the TNS_ADMIN directory. You can use
either a service (dynamic registration) or SID (static registration) model. This document uses
static registration, as used in the standard AutoConfig files.

Standby Listener

This listener only runs while the server is hosting a standby database. On switchover/failover
etc, the standard AutoConfig listener is used. Use the same structure as the AutoConfig listener,
substituting different values for port, host and listener name. See Appendix A: Oracle Net
Files for an example.

TNS Aliases

The aliases will be used by the fal_server init.ora parameters, allowing two-way
communication between the primary and standby. The fal_server alias is a connect string to the
primary. See Appendix A: Oracle Net Files for an example.

Note for Oracle RAC configurations: The TNS alias requirements are different. See A1. TNS
Alias Requirements in Oracle RAC Configuration of Appendix A: Oracle Net Files for an
example.

3.3 Set Up Secure Connections

Oracle Data Guard uses Oracle Net sessions to transport redo data and control messages
between the members of an Oracle Data Guard configuration. These redo transport sessions are
authenticated using either the Secure Sockets Layer (SSL) protocol or a remote login password
file. For Oracle RAC configurations, create password files for all instances. This document
uses a password file - see My Oracle Support Knowledge Document 376700.1, Enabling SSL
in Oracle E-Business Suite Release 12, for database SSL setup.
$ cd <RDBMS_ORACLE_HOME>/dbs
$ orapwd file=orapw <SID> password= <SYS password> entries= <max privileged users> ignorecase=y

To complete the implementation of the password file, you must add the
parameter remote_login_passwordfile to your init.ora file as described in the next section.

3.4 Set Primary Database Initialization Parameters

On the primary database, define initialization parameters that control redo transport services
while the database is in primary role.

Note: This document uses a static init.ora include file to record parameters. If you are using an
spfile, disregard the ifile actions and use the appropriate "alter system" command to make the
necessary changes.

Define an archive log destination directory on the file system. Then add these parameters to
your database init.ora file via the ifile found at <RDBMS_ORACLE_HOME>/dbs/<CONTEXT_name>_ifile.ora.

Primary database: primary role initialization parameters

Parameters relating to archive destinations and transmission of redo data to the standby system.

Note: FAL_CLIENT is deprecated in Oracle Database 11gR2 and should not be used.

Parameter Description
log_archive_dest_1
Archives redo data generated on primary database to the local file
system.
Transmits redo data to the remote physical standby destination.

Options used:

SERVICE : Standby service name. This is the DB_UNIQUE_name.


Redo log information can be transmitted in one of
two ways from primary to physical standby by
LGWR:
either LGWR or ARCH process. LGWR is used in this
document.
Specifies that network I/O is to be performed
asynchronously for the destination. You can
ASYNC : optionally specify a block count (from 0 to
log_archive_dest_2
102,400) that determines the size of the SGA
network buffer to be used.
The minimum number of seconds before the log
REOPEN : writer process (LGWR) should try again to access a
previously failed destination.
The maximum number of reopen attempts before
MAX_FAILURE: the primary database permanently gives up on the
standby database.
Specifies the number of seconds the log writer
process on the primary system waits for status from
NET_TIMEOUT:
the network server (LNS n) process before
terminating the network connection.
When set to ENABLE, allows redo transport services to transmit redo
log_archive_dest_state_2 data to the specified destination. Set this value to ENABLE on
primary site to send archive log files automatically to standby.
log_archive_format
Used to specify the filename format when archiving redo log files.
Will use system defaults if not set.
log_archive_min_succeed_dest
Defines the minimum number of destinations that must succeed in
order for the online log file to be available for reuse.
Enables or disables the sending of redo logs to remote destinations
log_archive_config
and the receipt of remote redo logs, and specifies the unique
database names (DB_UNIQUE_name) for each database in the Data
Guard configuration.
db_unique_name
Unique name to identify the primary and standby (For example
'dg12' for primary and 'dg12s' for physical standby).
fal_server
Specifies the TNS network service name that the standby database
should use to connect to the FAL server process. FAL Server is
Fetch Archive Log (FAL) Server which services requests for
archive redo logs from FAL clients running on multiple standby
databases. Set this parameter to primary database service
name dg12 (for example) to request missing archived redo log
files if primary is unable to send the missing log files
automatically.
Set to AUTO. Whenever data files are added or dropped from
standby_file_management primary database, corresponding changes will be made
automatically to the standby.
Specify the path name and file name location of data files and
redo log files. db_file_name_convert parameter do not need to be set
db_file_name_convert, when the directory structures are the same on both the primary
log_file_name_convert
and standby. Although log_file_name_convert should be set to
dummy values if you are using the same directory structure to
enable redo log clearing.
This parameter checks whether Oracle checks for a password file.
Remote_login_passwordfile Since we are using password authentication, this parameter should
set.

For further explanation of the initialization parameters, refer to the "Set Primary Database
Initialization Parameters" section of Oracle Data Guard Concepts and Administration 11g
Release 2 (11.2).

The configuration examples use the names shown in the following table.

Primary Physical Oracle RAC Oracle RAC


Database Standby Primary Standby
Oracle Net Service
dg12 dg12s prod stdby
Name
SID dg12 dg12 prod1 and prod2 prod1 and prod2
DB_UNIQUE_name dg12 dg12s prod stdby

Note: The database SID is the same on both the primary and physical standby databases.

The following example shows the relevant initialization parameters for the primary database:
db_unique_name = dg12 ---- You need to change this to dg12s (Standby db_unique_name, for example) when you copy this
file to physical standby
log_archive_dest_1 = LOCATION=/arch1/dg12/ MANDATORY
log_archive_dest_2 = SERVICE=dg12s LGWR ASYNC=20480 DB_UNIQUE_name=dg12s OPTIONAL REOPEN=15 MAX_FAILURE=10
NET_TIMEOUT=30
log_archive_config='dg_config=(dg12,dg12s)'
# log_archive_dest_state_2 = defer
# log_archive_dest_state_2 = enable

log_archive_min_succeed_dest = 1

standby_file_management = AUTO
Remote_login_passwordfile = exclusive
log_archive_format = <name >%s_%t_%r. <ext > # Or can just leave as default.

# db_file_name_convert: do not need; same directory structure


# log_file_name_convert: do not need; same directory structure
fal_server = dg12
log_file_name_convert = xx,xx # Specify dummy values to trigger log clearing

Note for Oracle RAC Configurations: Configure <instance>_<node>_ifile.ora on all nodes in the
primary Oracle RAC system. To prevent overwriting of archive logs of different nodes on a
shared file system, a specific format must be used for naming the archive logs of each node.
The following configuration assumes that prod and stdby are the service names/db_unique_names on
the primary and standby respectively.
db_unique_name=prod
log_archive_dest_1='LOCATION=<ORACLE_HOME>/dbs/arch/prod MANDATORY'
log_archive_dest_2='service=stdby valid_for=(online_logfiles,primary_role) db_unique_name=stdby LGWR ASYNC=20480
OPTIONAL REOPEN=15 NET_TIMEOUT=30'
log_archive_dest_state_1 = enable
log_archive_dest_state_2 = enable
fal_server=prod
log_archive_format=prod1_%s_%t_%r.log
db_file_name_convert='<SHARED DATA LOCATION ON PRIMARY>','<SHARED DATA LOCATION STANDBY>'
log_file_name_convert='<Shared Log Files Location on Primary>','<Shared Log Files Location on StANDBY>'
standby_file_management=auto

3.5 Enable Archive Logging on the Primary System

Enable archiving on primary system if it is not already enabled.

3.6 Add Standby Redo Logs

Redo data transmitted from the primary database is received by the remote file server (RFS)
process on the standby system. The RFS process writes the redo data to archived log files or
standby redo log files. Redo data can be applied either after the redo is written to the archived
redo log file or standby redo log file, or, if real-time apply is enabled, directly from the standby
redo log file as it is being filled. Standby redo logs are required if you want to use, for example,
maximum protection and maximum availability levels of data protection, or real-time apply.

A best practice is to add them to both the primary and the standby database so that switchover
between the environments is quicker and easier. In this case, you will add them to production,
so that they are in place and will be cloned to the standby. There are two considerations:

On the primary: The standard Oracle recommendation is to multiplex redo logs on the
primary when using NORMAL redundancy, but not when using ASM with high
redundancy.

On the standby: Standby redo log files can be multiplexed using multiple members,
thereby improving reliability over archived log files. However, multiplexing redo logs
adds more IO overhead that could impact the standby's redo apply rate as multiplexing
generates N*3 writes write IOs (where N is the number of multiplex redo logs you
have). This is the reason why some references state "Do not multiplex the standby redo
logs". Clearly, there are several factors to consider and therefore it is highly
recommended that you test whichever solution you decide to implement.

As a general rule, follow the same best practice as for the primary for the online redo logs.

Standby redo logs still count towards the total allocation of redo log groups and members,
which are limited by the database MAXLOGFILES and MAXLOGMEMBERS parameters respectively.

To create standby redo log groups, as the oracle user on the primary database server, connect to
SQL*Plus as sysdba and issue the following command for each of the standby redo log groups.
Refer to Appendix C: Example Standby Database Commands for an example.
SQL>alter database add standby logfile group N (<log_file>) size NNN;

Note for Oracle RAC Configurations: Ensure that standby logs are created for each redo
thread.

3.7 Invite Communications From the Standby

Release 12 has a new security feature that restricts remote connections to the database for
clients that are not registered on the system. This feature is enabled by default.

When this option is enabled, any additional computers that require direct access to the Oracle
E-Business Suite database (via SQL*Plus, SQL*Navigator, etc.) will need to be 'Registered
Nodes' to explicitly obtain access. This is achieved by setting the invited nodes value in
sqlnet.ora file. If you have enabled invited nodes in SQLNET.ORA, then the standby host
needs to be added to the list of nodes. You can perform this step using OAM. Refer
to Appendix B: Using Oracle Applications Manager to Register Standby Database for detailed
steps.

3.8 Gather Temporary File Information

You will need to manually recreate your temporary files on the standby database. Gather the
required data now from the primary database with the following SQL*Plus query:
SQL>select file_name, bytes from dba_temp_files;

Save the output for use in a later step. For an example of the output, refer to Appendix C:
Example Standby Database Commands.

3.9 Run the Application Tier and Database Tier Pre-Clone Scripts

1. As the oracle user, run the database pre-clone utility on the primary database server:

Note for Oracle RAC Configurations: Run pre-clone scripts on all database nodes and
application tier nodes.
$ cd $RDBMS_ORACLE_HOME/appsutil/scripts/context_name/
$ perl adpreclone.pl dbTier

Supply the APPS password when requested.

2. As the applmgr user, run the application tier pre-clone utility on each primary application
tiers that has an APPL_TOP (or only on one, if it is shared by all):
$ cd $INST_TOP/admin/scripts/
$ perl adpreclone.pl appsTier

3. (Optional) Shut down all application tier services to copy the APPL_TOP. If your operating
system returns errors when copying open files, you may need to shut down application
tier services to successfully copy the APPL_TOPand Oracle E-Business Suite technology
stack software.
$ cd INST_TOP/admin/scripts
$ adstpall.sh apps/<apps password>

3.10 Copy APPL_TOP and Oracle E-Business Suite Technology Stacks to Application Tiers on the Standby
Environment

For the list of directories to copy, refer to My Oracle Supuport Knowledge Document
406982.1, Cloning Oracle Applications Release 12 with Rapid Clone. For details of cloning
Oracle RAC systems, refer to My Oracle Support Knowledge Document 559518.1, Manually
Cloning Oracle Applications Release R12 with 10g or 11g RAC.

Section 4: Creating a Physical Standby Database

4.1 Copy the ORACLE_HOME and Database to the Standby Database Server
4.2 Generate a Standby Control File, Copy to Standby Database Server (optional)
4.3 Perform File-Based Configurations on Standby Database Server
4.4 Stop the Database Listener on the Standby Database Server
4.5 Configure Oracle Net for Redo Transmission, Start the Listener
4.6 Modify the Database init.ora Parameters on the Standby Server
4.7 Mount the Physical Standby, Start Processing Redo on the Standby
4.8 Start Shipping Redo from the Primary to the Standby Database Server
4.9 Verify Redo is Shipping
4.10 Add Temp Files to the Standby Database
4.11 Configure Data Guard Broker (optional)

4.1 Copy the ORACLE_HOME and Database to the Standby Database Server

Copy the Oracle Home file system to the standby database server. If you natively compile your
PL/SQL, be sure you include the file system directories holding the compiled objects. The
standard location for this is<RDBMS_ORACLE_HOME>/plsql/nativelib.

There are three choices for backing up or copying the database to the standby site:
Manual Cold backup
With the database shut down, copy all the database files and redo log files to the
standby site.

Manual Hot Backup


With the open, put the tablespace in backup mode and copy the data files to the standby
site.

RMAN
Use the 'duplicate database' command. See Appendix D: Using RMAN to Create
Physical Standby Database. For RAC examples of usage, refer to Appendix E: RAC
RMAN Clone Example.

If you use RMAN to perform your backup, you do not need to place the tablespaces in 'hot
backup' mode, or manually create your standby control file. Refer to the RMAN documentation
in the Oracle Database Backup and Recovery User's Guide for more details. RMAN restores a
backup control file, and copies all necessary database files and archived redo logs over the
network to the standby host. However, while RMAN recovers the standby database, it does not
place it in manual or managed recovery mode.

4.2 Generate a Standby Control File and Copy it to Standby Database Server (optional)

Note: If you used RMAN to copy the database, skip this step.

If the backup procedure required you to shut down the primary database, create the control file
for the standby database.

You will need to recover past the time the control file is created, so switch logs and note the
new log number.
SQL>alter database create standby controlfile as <directory >/ <controlfile name >;
SQL>alter system switch logfile;
SQL>select thread#, sequence#-1 from v$log where status = CURRENT;

Copy the control file to the standby database server.

Note the thread# and sequence# for later use: you will only be able to open the standby
database after this log has been applied on the standby.

4.3 Perform File-based Configurations on the Standby Database Server

After the database software copies are complete (which can be done before the database itself is
finished copying), log into the standby database server as the oracle user and execute the
following commands to update the file system configurations for the new environment. Since
your environment scripts are not yet set up, you will need to manually resolve the reference
to <RDBMS_ORACLE_HOME>.
$ cd <RDBMS_ORACLE_HOME>/appsutil/clone/bin
$ perl adcfgclone.pl dbTechStack

Answer the questions when prompted. If you receive any errors registering the new ORACLE_HOME,
follow the instructions given by the script to correct them.

Note for Oracle RAC Configurations:

[RAC Only] These steps should be repeated for each RAC instance on the standby site.

Create a file named pairsfile.txt under $<ORACLE_HOME>/appsutil/clone folder and add the
following settings:
s_undo_tablespace
Undo tablespace name for this instance
s_dbClusterInst
Total number of instances in a cluster
s_db_oh
Target system RDBMS ORACLE_HOME directory

For example:
s_undo_tablespace=UNDOTBS1 [UNDOTBS2 for 2nd node]
s_dbClusterInst=2
s_db_oh=/u01/dbhome/r12/db/tech_st/11.2.0

Execute the adclonectx.pl script for each new database Oracle home on the standby site:

Run adclonectx and adclone on all nodes.

Answer the questions when prompted. Enter 'Y' when prompted Current node is the first
node in an N Node RAC Cluster (y/n)[n]:y on every node, otherwise it will prompt for "Live
RAC node", which will not be available at this time. Refer to Appendix G: Creating
Non-RAC Standby for RAC Primary for more information.
Modify the init parameter files to point the correct diagnostic destination
and utl_file_dir with standby context directory.
Run the following commands (shown split over a number of lines for readability):
$ perl <RDBMS_ORACLE_HOME>/appsutil/clone/bin/adclonectx.pl \ contextfile=<RDBMS_ORACLE_HOME>/appsutil/<SID>_<Primary
Application Host>.xml \ template=$Standby_ORACLE_HOME/appsutil/template/adxdbctx.tmp \
pairsfile=<RDBMS_ORACLE_HOME>/appsutil/clone/pairsfile.txt

$ perl adclone.pl java <RDBMS_ORACLE_HOME>/appsutil/clone/jre \


component=dbTechStack \
mode=apply \
stage=<RDBMS_ORACLE_HOME>/appsutil/clone \
method=custom \
dbctxtg=<RDBMS_ORACLE_HOME>/appsutil/<Stndby SID1>_<stndby Host>.xml \
rmanstage=<rman backup directory path> \
rmantgtloc=<rman target data files location> \
srcdbname=<source db name> \
pwd=<apps password>

Your oracle user environment scripts are now ready to use. Source them for the next steps,
using the appropriate OS command.
For example, in sh or ksh on UNIX:
$ cd <RDBMS_ORACLE_HOME>
$ ./<STNDBY_CONTEXT>.env

If you have implemented native PL/SQL compilation, set up an rsync job from the primary
database server to the standby database server for the file system directories holding the
compiled objects.

The standard location for this is <RDBMS_ORACLE_HOME>/plsql/nativelib.

4.4 Stop the Database Listener on the Standby Database Server

The above step starts the database listener. It is not yet completely configured, so should be
stopped. As the oracle user on the standby database server, enter the following command:
$ lsnrctl stop

4.5 Configure Oracle Net for Redo Transmission, Start the Listener

Note for Oracle RAC Configurations: Perform this step on all nodes.
1. As the oracle user, copy the listener_ifile.ora and <CONTEXT_name>_ifile.ora from the
primary server's <TNS_ADMIN> directory to the standby server's <TNS_ADMIN> directory. As part
of the copy, rename the primary<CONTEXT_name>_ifile.ora to the
standby's <STNDBY_CONTEXT>_ifile.ora matching the spelling and case in the file name in the
last line of the standby server's tns_names.ora file.
2. In the <STNDBY_CONTEXT>_ifile.ora, be sure the entry for the standby service's HOST
parameter holds the standby database host name and the FAL service's host name is the
primary host name.
3. In the listener_ifile.ora file, ensure that the HOST for the standby service entry points
to the standby database host.
4. As the oracle user, start the database listener for the standby:
$ lsnrctl start <standby service name>

4.6 Modify the Database init.ora Parameters on the Standby Server

As the oracle user on the standby database server, create an ifile for the standby database from
the one you created earlier for the primary database:
$ cd <ORACLE_HOME>/dbs
$ cp <CONTEXT_name>_ifile.ora <STNDBY_CONTEXT>_ifile.ora

Update the following parameters:

DB_UNIQUE_name to a name different from primary: for example dg12s


LOG_ARCHIVE_DEST_2 to point to the standby service. This is required when standby is
switched to primary and ships redo to new standby
o e.g. LOG_ARCHIVE_DEST_2 for 'service=dg12s ASYNC REGISTER
VALID_FOR=(online_logfile,primary_role) DB_UNIQUE_name=dg12'

If you are using an spfile, and are therefore not using the AutoConfig generated init.ora, make
the following additional changes:

diagnostic_dest to <RDBMS_ORACLE_HOME >/admin/ <STNDBY_CONTEXT>


utl_file_dir for context specific directories

Finally, add an entry for the standby control file you created on the primary and copied to this
server:
control_files = (<control file directory>/<standby control file>, <control file directory>/<standby control file>)

Note for Oracle RAC Configurations: log_archive_dest_1 should be set to the same shared
location on all standby instances. The standby redo logs will be archived to this location and
should be accessible by all other standby instances.

4.7 Mount the Physical Standby, Start Processing Redo on the Standby

Note: Ensure that the password file created in 3.3 Set Up Secure Connections exists
under $ORACLE_HOME/dbs.

As the oracle user on the standby database server, do the following after the database copy is
complete:

1. Mount the standby database. Connect to SQL*Plus as sysdba and issue these
commands:

Note: Skip this step if you used RMAN for standby creation.
SQL>startup nomount pfile= <RDBMS_ORACLE_HOME>/dbs/init <primary SID>.ora | spfile
SQL>alter database mount standby database;

2. Put the standby database in 'managed recover' mode


SQL>alter database recover managed standby database disconnect from session;

4.8 Start Shipping Redo from the Primary to the Standby Database Server

As the oracle user on the primary database server, set log_archive_dest_state_2 to enable in the
database initialization file.
# log_archive_dest_state_2 = defer
# log_archive_dest_state_2 = enable
4.9 Verify Redo is Shipping

Check to see that the database is shipping redo, by connecting to the primary database and
causing a log switch:
SQL>alter system switch logfile;

Still on the primary, check for the status of the archive destinations to determine the most
recently archived redo log file at each redo transport destination. The most recently archived
redo log file should be the same for each destination. If it is not, a status other than VALID may
identify an error encountered during the archival operation to that destination:
SQL>select * from v$archive_dest_status where status != 'INACTIVE';

On each database server, this query will show the logs that have been sent /received and
applied:
SQL>select sequence#, applied, to_char(first_time,'mm/dd/yy hh24:mi:ss') first from v$archived_log order by
first_time;

On the standby database server, monitor the database alert log for recovery progress.

4.10 Add Temp Files to the Standby Database

Note: Skip this step if you used RMAN for standby creation.

To save time on failover, add your temp files to the standby database at this point. You
previously collected the temporary file names and sizes in 3.8 Gather Temporary File
Information.

To do this, you will need to open the database in read-only mode. You will not be able to open
the database read-only until recovery has progressed past the time the control file was created -
the log sequence number was noted in4.2 Generate a Standby Control File and Copy it to
Standby Database Server.

Execute the following commands:


SQL>alter database recover managed standby database cancel;
SQL>alter database open read only;
SQL>alter tablespace temp add tempfile ' <file spec>' size <size> reuse;
[enter as many lines as you have temporary data files]
SQL>shutdown immediate;
SQL>startup mount;
SQL>alter database recover managed standby database disconnect from session;

4.11 Data Guard Broker Configuration (optional)

If you wish to use Data Guard Broker to manage an Oracle E-Business standby database,
follow the steps outlined in Appendix H: Using Data Guard Broker [DGMGRL] to Manage
Standby Databases.
Section 5: Configuration on Application Tiers After Standby Database is Enabled

1. Perform file-based configurations on standby application tiers

1. After the application tier software copies are complete, the file system
configurations need to be updated to reflect the new environment. To do this on
the application tiers, log onto each standby application tier system as
the applmgr user and execute the following commands. Since your environment
scripts are not yet set up, you will need to manually resolve the reference
to <COMMON_TOP> and <APPL_TOP>:

Note: If the directory structure on standby is different than the primary then you
need to run perl adcfgclone.pl atTechStack instead of adclonectx.
$ cd <COMMON_TOP>/clone/bin
$ perl adclonectx.pl <INST_TOP>/appl/admin/<PRIMARY CONTEXT>.xml

For further information, refer to My Oracle Support Knowledge Document


406982.1, Cloning Oracle Applications Release 12 with Rapid Clone.

2. When the script has finished and the context file has been created, execute the
following commands, again resolving the reference to <APPL_TOP> manually:

Note: If the application tier is configured as a concurrent server only, then


modify the context variable s_isWeb to YES. After executing the commands below,
change it back to NO. For further information refer to Bug 14253714.
$ cd APPL_TOP/ad/12.0.0/bin
$ perl adconfig.pl contextfile=$INST_TOP/appl/admin/<STNDBY CONTEXT>.xml run=INSTE8

Answer the questions when prompted. This creates your environment files on
the application tier. It then tries to connect to the database, so some portions will
fail, but the environment scripts should be created successfully.

2. Optionally, set up rsync for log and out files.

If you wish to synchronize your concurrent manager log and out files from the primary to the
standby, create directories that correspond to the APPLCSF environment variables on the
standby application tier server(s). For example:
$ mkdir -p <APPLCSF from PRODUCTION>/log
$ mkdir -p <APPLCSF from PRODUCTION>/out

Repeat this on the primary server, creating directories matching the standby context name, so as
to be ready for a switchover operation.

For UNIX systems, on the primary application tier(s), set up an rsync job in cron, to run every
few minutes. This example synchronizes the log directory:
$ rsync av <APPLCSF>/log <standby_host>: <APPLCSF from PRODUCTION>/log --rsync-path=/usr/local/bin/rsync

Section 6: Role Transitions

A database can operate in either a primary or standby role: these roles are mutually exclusive.
Oracle Data Guard enables you to change these roles dynamically by issuing SQL commands,
and supports the following transitions:

Switchover
Allows the primary database to switch roles with one of its standby databases. There is
no data loss during a switchover. After a switchover, each database continues to
participate in the Oracle Data Guard configuration with its new role.

Failover
Changes a standby database to the primary role in response to a primary database
failure.
Switchback
Recreate the primary database on the original primary site.

The following role transitions are discussed:

6.1 Performing a Switchover


6.2 Performing a Failover
6.3 Performing Switchback to Primary After Switchover/Failover

For all three transitions, application configuration is required. As most application


configuration steps are common to all transition types, it is discussed in the final part of this
section:

6.4 Application Tier Configuration After a Role Transition (switchover/failover/switchback)

6.1 Performing a Switchover

If you are using Data Guard Broker to manage the standby database, follow the steps in H3.
Role Transitions of Appendix H: Using Data Guard Broker [DGMGRL] to Manage Standby
Databases, then go to 6.1.6 Complete the database configurations.

A switchover is typically used to reduce primary database downtime during planned outages,
such as operating system or hardware upgrades, or rolling upgrades of the Oracle database
software and patch sets. A switchover takes place in two phases. In the first phase, the existing
primary database undergoes a transition to a standby role. In the second phase, a standby
database undergoes a transition to primary. In this case the primary site is accessible and
involved in the switchover.

Section 3: Preparing the Primary Database for Standby Database Creation, Section 4: Creating
a Physical Standby Database, and Section 5: Configuration on Application Tiers After Standby
Database is Enabled define how to set up your environments so there will be minimal
parameter changing when switching. This section assumes you have configured your parameter
files as described in these sections.

6.1.1 Preparing for switchover to standby server

1. Verify the primary database instance is open and standby database instance is mounted.

2. Verify there are no active users connected to the database. Shut down all the sessions in
the primary database.

3. Ensure that the last redo data transmitted from the primary database was applied on the
standby database. Issue the following SQL command on the primary and standby
databases to find out. If necessary, perform a log file switch before the first command.
SQL>select sequence#,applied from v$archived_log;

4. Check whether the primary is ready for switch. Query the switchover_status column of
the v$database fixed view to determine whether the database is ready to switch modes.
SQL>select switchover_status from v$database;

If this query returns "TO STANDBY", then the environment is ready to switch. If it
returns "ACTIVE SESSIONS", then the switch command should be used with the
'session shutdown' option.

6.1.2. Initiate the switch over on the primary database

Note for an Oracle RAC Configuration: For switchover, only one primary instance should be
mounted. All others must be shut down. After switchover, LOG_ARCHIVE_DEST_STATUS_2 should be set
for all instances.

Connect as sysdba and issue the following SQL command:


SQL>connect / as sysdba;
SQL>alter database commit to switchover to physical standby with session shutdown;

After this statement completes, the primary database is converted to a standby database. As part
of the statement's execution, the current control file is backed up to the current SQL session's
trace file, making it possible to reconstruct the control file if necessary.
Change the value of LOG_ARCHIVE_DEST_STATUS_2 to defer on primary.

6.1.3 Shut down and mount the primary database

To complete the transition, the database must be shut down and restarted in a mounted state. In
addition, recovery can be started in preparation for transition.
SQL>shutdown immediate
SQL>startup nomount pfile=$ORACLE_HOME/dbs/init<SID>.ora | spfile
SQL>alter database mount standby database;
SQL>alter database recover managed standby database disconnect from session;

At this point in the switchover, both databases are standby databases.

6.1.4 Verify the switchover status on the standby server

As the oracle user on the standby-to-be-primary database server, verify it is ready to switch to
primary:
SQL>select switchover_status from v$database;

This should return a value 'TO PRIMARY'. Any other value, such as SESSIONS ,
ACTIVE NOT ALLOWED, and
so on, should be investigated and corrected as in step 2 above.

6.1.5 Switch the selected standby database to the primary role

Note for Oracle RAC Configurations: For switchover, only one standby instance should be
mounted. All others must be shut down.

For the switchover process to be coordinated, a standby database must be either mounted and in
Redo Apply mode, or open ready only. Once it is mounted in an appropriate mode, issue the
following command to transition it to the primary role:
SQL>alter database commit to switchover to primary with session shutdown;

Adjust the network parameters on both database servers

As the oracle user on both the primary and standby database servers, in
the <CONTEXT_name>_ifile.ora and <STNDBY_CONTEXT>_ifile.ora files in the <TNS_ADMIN> directories,
change the host name in the standby service definitions to point to the new standby server.

Change the LOG_ARCHIVE_DEST_STATE_2 to enable.

To complete the transition, the database must be shut down and re-started:
SQL>shutdown immediate
SQL>startup pfile=$ORACLE_HOME/dbs/init<SID>.ora | spfile

6.1.6 Complete the database configurations


1. Connect to the new primary database using SQL*Plus as user APPS, and execute the
following commands:
SQL>exec fnd_net_services.remove_system('<SID>');
SQL>commit;
SQL>exec fnd_conc_clone.setup_clean ;

2. As the oracle user on the new primary database server, use AutoConfig to complete
configuration for primary operations, providing the APPS password when prompted:
$ cd <RDBMS_ORACLE_HOME>/appsutil/scripts/<context>
$ ./adautocfg.sh

3. When this completes, stop and start the listener on the new primary database server:
$ lsnrctl stop <SID>
$ lsnrctl start <SID>

4. On the new standby server, stop and start the listener for standby services:
$ lsnrctl stop <sid>
$ lsnrctl start <Standby Service>

5. For application-specific configurations, follow the steps in 6.4 Configuring application


tiers after role transition (switchover, failover, switchback).

Note for Oracle RAC Configurations: Repeat above steps 2-4 for each instance. Rerun
AutoConfig on all nodes after completing steps 2-4 for each instance to update all
configuration files with all nodes in the cluster.

6.2 Performing a Failover

Note: If you are using Data Guard Broker to manage the standby databases follow the
instructions in section H3.3 of Appendix H: Using Data Guard Broker [DGMGRL] to Manage
Standby Databases, then proceed to 6.2.7 Complete the database configuration.

You may need to fail over to your standby site due to complete failure of the primary site. This
section describes the steps in the event of failure of the primary site.

Section 3: Preparing the Primary Database for Standby Database Creation, Section 4: Creating
a Physical Standby Database, and Section 5: Configuration on Application Tiers After Standby
Database is Enabled define how to set up your environments so there will be minimal
parameter changing when failing over. This section assumes you have configured your
parameter files as described in these sections.

Performing a failover separates the standby database from the primary. You must create a new
standby database environment from the environment to which you failed over, to restore
disaster recovery protection.

6.2.1 Flush any unsent redo from the primary database to the target standby database
If the primary database can be mounted, it may be possible to flush any urgent archived and
correct redo from the primary database to the standby database. Ensure that redo apply is active
on standby server. Mount the database, but do not open it.
SQL>alter system flush redo to 'target_db_name';

This statement flushes any unsent redo from the primary database to the standby database, and
waits for that redo to be applied to the standby database.

6.2.2 Verify that standby database has the most recently archived redo log file for each primary database redo
thread

Query the V$ARCHIVED_LOG view on the target standby database to obtain the highest log sequence
number for each redo thread:
SQL>SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

6.2.3 Identify and resolve any archived redo log gaps

On the standby database server, connect as sysdba to the standby database.


Query v$archive_gap to determine whether there are missing archive logs:
SQL>select * from v$archive_gap;

If this query returns a row, it indicates at least one archived redo log is missing from the
standby. If you still have access to your primary database, you can determine the full name of
the redo logs by querying v$archived_log, using the low_sequence# and high_sequence# returned
above:
SQL>select name from v$archived_log
where thread# = <thread# from above query>
and sequence# between <low_sequence# above> and <high_sequence# above>;

Locate the missing logs and copy them to the standby server's standby redo log destination,
then register them:
SQL>alter database register physical logfile '<filespec/name on standby>';

Note only one gap at a time is reported in v$archive_gap. If you find a gap and resolve it, repeat
this process until no more gaps are reported.

6.2.4 Adjust standby archive destination status

On the standby database server, change the initialization parameter for the destination state of
the archive logs to be shipped from primary to standby from 'defer' to 'enable'.

Make the changes in <RDBMS_ORACLE_HOME>/dbs/<STNDBY_CONTEXT>_ifile.ora, commenting out the


'defer' line.
# log_archive_dest_state_2 = enable
# log_archive_dest_state_2 = defer

6.2.5 Stop redo apply and finish applying all received redo data

Note for Oracle RAC Configurations: Shut down all other instances before you perform the
following steps

When all available logs are present and registered on the standby, stop redo apply:
SQL>alter database recover managed standby database cancel;

Finish the recovery session:


SQL>alter database recover managed standby database finish;

When that completes, convert the physical standby to a primary database role:
SQL>alter database commit to switchover to primary;
SQL>shutdown immediate;
SQL>startup pfile=?/dbs/init<SID>.ora

Note: You should back up this database without delay, as you cannot recover any changes made
after the failover without a fresh backup.

6.2.6 Update TNS parameters for new standby database location

As the oracle user on the new-primary database server:

1. Open the <TNS_ADMIN>/<STNDBY_CONTEXT>_ifile.ora file for editing.


2. Change the value for the HOST name in the standby service definition to point to a new
primary host.
3. Save the changes and close the file.

6.2.7 Complete the database configuration

1. Connect to the new primary database using SQL*Plus as the APPS user, and execute
the following commands:
SQL>exec fnd_net_services.remove_system(<SID>);
SQL>commit;
SQL>exec fnd_conc_clone.setup_clean;

2. As the oracle user on the new primary database server, use AutoConfig to complete
configuration for primary operations, providing the APPS password when prompted:
$ cd <ORACLE_HOME>/appsutil/scripts/<CONTEXT_name>
$ ./adautocfg.sh

3. When this completes, stop and start the listener on the new primary database server:
SQL>lsnrctl stop
SQL>lsnrctl start <SID>

To complete the application-specific configurations, follow the steps in 6.4 Configuring


Application Tiers After Role Transition (switchover, failover, switchback).
Note for Oracle RAC Configurations: Repeat above steps 2 and 3 for each instance.

6.3 Performing Switchback

6.3.1 Switch back to primary site after a switch over

After switch over to standby and maintenance is complete you need to switch back to the
primary site. In this case, the pre-switchback configuration will be as follows:

Standby Site Primary Site


Primary database Standby database

Steps to perform the switchback to primary site:

1. Verify primary database at standby site is open and standby database at primary site is
mounted.
2. Verify all the redo logs are transferred to standby and applied.
3. Check whether switchover_status from v$database is showing TO STANDBY.
4. On the primary database, issue the following command:
SQL>alter database commit to switchover to physical standby

5. Adjust the LOG_ARCHIVE_DEST_STATE_2 defer at standby site (primary database) and enable at
primary site (standby database).
6. Adjust the network configurations as mentioned in 6.1.5 Switch the selected standby
database to the primary role.
7. Shut down and mount the database as standby at the standby site.
8. Start the recovery by issuing the following commands at the primary site:
SQL>alter database commit to switchover to physical primary

9. Shut down and start up the database at the primary site.


10. Verify the redo log shipping. Refer to 6.1 Performing a Switchover for the necessary
commands.
11. For application-specific configurations, follow the steps in 6.4 Application Tier
Configuration After a Role Transition (switchover/failover/switchback).

6.3.2 Recreating the original primary database after failover

If you performed failover to a standby database, then resolved the problem at the original
primary site that necessitated the failover operation, you can now recreate the primary database
on the original primary site:
1. Make a consistent backup of activated standby database at standby site.
2. Restore the backup created at standby site to primary database.
3. Run AutoConfig on both the database tier and application tier.
4. Shut down and start up the database.
5. On the original primary site, create or modify the initialization parameter file with the
appropriate values.
6. Create a new standby database at the original standby site. Follow instructions
in Section 3: Preparing the Primary Database for Standby Database Creation, Section 4:
Creating a Physical Standby Database and Section 5: Configuration on Application
Tiers After Standby Database is Enabled.
7. For application-specific configurations, follow the steps in 6.4 Configuring application
tiers after role transition (switchover, failover, switchback).

6.4 Configuring Application Tiers After Role Transition (switchover, failover, switchback)

6.4.1 Finish Oracle E-Business Suite configuration on application tiers

After the primary database configuration is complete and its listeners have started, log in to
each now-primary application tier server as the applmgr user, and run the final configuration
steps:
$ cd $INST_TOP/admin/scripts>
$ ./adautocfg.sh

Provide the APPS password when prompted.

6.4.2 Update host name in fnd_concurrent_requests and fnd_conc_req_outputs tables

If you synchronize your concurrent manager log and out directories, you must change the host
name in the fnd_concurrent_requeststable to the standby server name:
SQL>update apps.fnd_concurrent_requests
set logfile_node_name = <new application tier node>,
outfile_node_name = <new application tier node>
where logfile_node_name = <old application tier node>
and outfile_node_name = <old application tier node>;

SQL>update apps.fnd_conc_req_outputs set file_node_name=<new applications tier node>


where file_node_name=<old applications tier node>;

If you do not synchronize your concurrent manager log and out directories, blank out the host
name in the fnd_concurrent_requests table to avoid network timeout errors:
SQL>update apps.fnd_concurrent_requests
set logfile_node_name = null,
outfile_node_name = null;

SQL>update apps.fnd_conc_req_outputs set file_node_name=null;

If you run the latter update, you must execute it before starting the concurrent managers on the
system. If you do not execute it before starting the managers, you must add a where clause to
limit the rows updated to those pointing to the old host names. This does not need to complete
before you run the next step. However, if you let users on to the system before it is committed,
they will get errors if they try to access a report's log or out file that was generated on the old
primary system.

6.4.3 Perform the cloning finishing tasks

Perform the Finishing Tasks outlined in My Oracle Support Knowledge Document


406982.1, Cloning Oracle Applications Release R12 with Rapid Clone.

Instance specific profile options at other than site level (Rapid Clone updates the site
level instance specific profile options)
Printer settings as necessary

Workflow configuration settings

APPLCSF variable if necessary

6.4.4 Direct users to the new system

The standby system should be available to your users as your new primary system. Direct your
users to the new URL.

6.4.5 Establish a new standby system

Perform this step if you have performed a failover. Failing over to the standby database
(versus switching over) separates it from the old primary. You must create a new standby
environment from this new system to again provide disaster recovery protection.

6.4.6 Re-point your CM log and out directories, and native PL/SQL object directory rsync scripts (Optional)

If you are keeping your concurrent manager log and out directories synchronized across the
environments, set up your rsync scripts to move the files from the new primary server to the
new standby server.

Section 7: Oracle E-Business Suite Maintenance with Standby Database

This section describes how to apply an Oracle E-Business Suite patch in on the primary, and
incrementally update the standby.

7.1 Preparing to Apply the Application Patch


7.2 Patch Primary
7.3 After Applying the Patch

Applying an application patch when standby is configured requires:

Syncing of standby with the primary after applying the patch. There are two choices:
o Syncing File system using rsync, and redo log apply for the database.

o Recreate the standby completely. When the patch is a major upgrade of the
application this is the recommended approach.

Protecting the primary as well as standby from any problems during patch application:

o If your standby database is running during patch application, the database


changes on primary will be automatically pushed to the standby. If you do not
want these changes pushed to standby until after patching is complete, you
should shut down standby recovery before applying patches. This document
uses the approach of stopping recovery.
o If you have enough disk space, backup both the databases and Oracle E-
Business Suite file system before patching.

7.1 Preparing to Apply the Application Patch

7.1.1 Stop recovery delay on the standby if it is set

If you have recovery delay set for redo log application on the standby, stop the delay. On the
standby database, run the following command as a privileged user:
SQL>alter database recover managed standby database nodelay;

7.1.2 Shut down the application tier services on the primary

As the applmgr user, shut down all application tier services and stop the listeners on all
application tier servers:
$ cd $INST_TOP/admin/scripts
$ adstpall.sh apps/<apps password>

7.1.3 Switch redo logs in the primary database

On the primary database server, log into SQL*Plus as sysdba and issue the following
commands to switch logs, and then discover the last log sequence number:

Note for an Oracle RAC Configuration: Perform switching on each instance.


SQL>alter system switch logfile;
SQL>select sequence# -1 from v$log where status = 'CURRENT';

7.1.4 Ensure that the last log is applied on the standby

On the standby database server, connect as sysdba and monitor the system to see that this last
log has been shipped and applied there, to bring the standby to the point in time services were
stopped on the primary:
SQL>select sequence#, applied, to_char(first_time, 'mm/dd/yy hh24:mi:ss') first
from v$archived_log
order by first_time;
7.1.5 Stop recovery on the standby

Note for Oracle RAC Configurations: Shut down all instances except the recovery standby
instance.

On the standby database server, stop recovery after the last redo log is applied, and before
applying the patch: if there are issues in applying the patch, the primary system can be restored
from standby.
SQL>alter database recover managed standby database cancel;

7.2 Patch Primary

Test to ensure that the patch applied successfully.

7.3 After Applying the Patch

Perform the following steps after successful patch application.

7.3.1 Restart redo data shipping and apply on standby

If the patch applied successfully, restart recovery on the standby database server. Connect to
SQL*Plus as sysdba, and run the command:
SQL>alter database recover managed standby database disconnect from session;

7.3.2 Run the application tier and database pre-clones

As the applmgr user, run the application tier pre-clone utility on each primary application tier that
has an APPL_TOP (or only on one, if it is shared by all):
$ cd $INST_TOP/admin/scripts
$ perl adpreclone.pl appsTier

If the patch required updating the database ORACLE_HOME with a new set of apps utilities
(appsutil.zip), you should also reconfigure the database server. As the oracle user, run the
database pre-clone utility on the primary database server:
$ cd <RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_name>
$ perl adpreclone.pl dbTier

Supply the APPS password when requested.

Note for Oracle RAC Configurations: Perform the pre-clone procedure on each instance.

7.3.3 Synchronize the appropriate file systems

Depending on what was patched, synchronize the appropriate standby server directories with
the changes made on the primary servers using an OS utility such as rsync or rdist. Within the
scenario of freezing the DR image until the patch is complete, these synchronization commands
should be executed manually after the patch is finished and tested, not via cron.

Note the standby database and environment are not viable as a DR solution until the
synchronization command completes.
For an Oracle E-Business Suite patch, synchronize the following directories: APPL_TOP,
COMMON_TOP, 10.1.2 ORACLE_HOME, and the 10.1.3 ORACLE_HOME.

For an Oracle E-Business Suite technology stack upgrade, synchronize these


directories: OracleAS 10.1.2 ORACLE_HOME and the OracleAS 10.1.3 ORACLE_HOME.

7.3.4 Start application tier services on primary

As the applmgr user, start all application tier services:


$ cd $INST_TOP/admin/scripts
$ adstrtall.sh apps/<apps password>

7.3.5 Reconfigure the standby application tier file systems

Log in to the standby application tier systems as the applmgr user and execute the following
commands:

Note: If the directory structure on standby is different than the primary, then you must run perl
adcfgclone.pl atTechStack <STNDBYCONTEXT>.xml.

Refer to My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications


Release 12 with Rapid Clone, for further details.

When the script is finished and the context file is created, run the following commands (the perl
command is entered on one line):
$ cd $APPL_TOP/ad/12.0.0/bin
$ perl adconfig.pl contextfile= <INST_TOP>/appl/admin/<STNDBY CONTEXT>.xml run=INSTE8

This recreates your environment files on the application tier. It tries to connect to the database,
so some portions fail, but the environment scripts should be successfully created.

7.3.6. Reconfigure the standby database file systems (optional)

Note for an Oracle RAC Configuration: Perform the following steps on each instance.

If you had to synchronize the apps utilities on the database server in the previous step, you
should also reconfigure the database server. As the oracle user on the standby database server,
first stop the listener if it is running, then use the cloning toolkit to define the database tier
topology at the standby site:
$ lsnrctl stop <SID>
$ cd <RDBMS_ORACLE_HOME>/appsutil/clone/bin
$ perl adcfgclone.pl dbTechStack
Answer the questions when prompted.

The above step starts the database listener for primary services. You need to stop and re-start it
for standby services:
$ lsnrctl stop <SID>
$ lsnrctl start <standby service name>

Appendix A: Oracle Net Files

The examples in this section use the following convention where SID is same on both primary
and physical standby:

Primary Physical Standby


Oracle Net Service Name dg12 dg12s
SID dg12 dg12

A sample <TNS_ADMIN>/<CONTEXT_name>_ifile.ora file, used to support fal_server communication.

##################################################################
#
# Created to define net services to support a Oracle Data Guard physical
# standby environment.
#
##################################################################

#
# The Oracle Data Guard physical standby of primary runs on <standby host >.
#Oracle Data Guard uses the tcp protocol only.
#
#
# # MUST BE CHANGED on switchover:
dg12s=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)
(HOST= < standby DB host name >)
(PORT= <Same PORT as primary>)
)
(CONNECT_DATA=(SID=dg12)
)
) #
# Fetch Archive Log (FAL) service definition.
# This entry can be set up for use when THIS server hosts a
# standby database (thus will not need to be changed on switchover),
# and should point to what would be the PRIMARY AT THAT TIME -
# i.e. this is the fal_server alias used to communicate from the standby to primary.
dg12=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)
(HOST= <prod DB host name when this is standby >)
(PORT= <same port as primary)
(CONNECT_DATA=(SID=dg12) ) )

Standby LISTENER.ORA file when server is running as standby


dg12s =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)
(HOST= < standby DB host >)
(PORT= <same as production >)
)
)

SID_LIST_dg12s =
(SID_LIST =
(SID_DESC =
(ORACLE_HOME= <RDBMS_ORACLE_HOME >)
(SID_name=dg12)
)
)

STARTUP_WAIT_TIME_dg12s = 0
CONNECT_TIMEOUT_dg12s = 10 TRACE_LEVEL_dg12s = OFF

LOG_DIRECTORY_dg12s = <same as production >


LOG_FILE_dg12s = STDBY
TRACE_DIRECTORY_dg12s = <same as production >
TRACE_FILE_dg12s = STDBY
ADMIN RESTRICTIONS_dg12s = OFF

A1. TNS Alias Requirements in Oracle RAC Configuration

For Oracle RAC configurations, the entries for the TNS aliases should be as follows, where
prod and stdby are the primary and standby service names, respectively. The entries must be the
same on all nodes in the cluster as well as in the standby instances.
prod=
(DESCRIPTION=
(LOAD_BALANCE=NO)
(FAILOVER=YES)
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=<Primary DB Host1>)
(PORT=1529))
(ADDRESS=
(PROTOCOL=tcp)
(HOST=<Primary DB Host2)
(PORT=1529))
)
(CONNECT_DATA=(SERVICE_name=prod))
)
stdby=
(DESCRIPTION=
(LOAD_BALANCE=NO)
(FAILOVER=YES)
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=<Stndby DB Host1)
(PORT=1529))
(ADDRESS=
(PROTOCOL=tcp)
(HOST=<Stndby DB Host2>)
(PORT=1529))
)
(CONNECT_DATA=(SERVICE_name=stdby))
)

Appendix B: Using Oracle Applications Manager to Register Standby Database

1. From a client, connect to OAM to register the standby database server as a node.
Navigate as follows:

Site Map > Administration > System Configuration > Hosts > Register (button under
"Other Hosts")

2. Next, use OAM to add this host to the list of hosts that need access to the database:

Applications Dashboard > Security > Manage Security Options > Enable Restricted
Access > Run Wizard

3. Select the host you just added, and click 'Continue'.


4. If the displayed list is correct and includes your new host, click 'Submit'.

Appendix C: Example Standby Database Commands

The following is an example for standby redo log files:


Alter database add standby logfile group 4 ('/d1/MAABCU/primary/dg12data/log5.dbf') size 50M ;
Alter database add standby logfile group 5 ('/d1/MAABCU/primary/dg12data/log6.dbf') size 50M ;
Alter database add standby logfile group 6 ('/d1/MAABCU/primary/dg12data/log7.dbf') size 50M ;

Gathering temporary tablespace information to creating temporary tablespace on standby:


SQL>select file_name, bytes from dba_temp_files;
FILE_name BYTES
------------------------------------------
/d1/MAABCU/primary/dg12data/tmp1.dbf 2097152000

Appendix D: Using RMAN to Create Physical Standby Database

Steps to be performed:

1. Create initialization parameter file for standby. Run the following command on the
primary:
SQL>create pfile from spfile

2. Copy init<SID>.ora from primary to standby.

3. Change db_unique_name to standby db_unique_name. This should be different from primary.


For example, db_unique_name=dg12s.

4. For log_archive_dest_2, specify primary db_unique_name. For


example, log_archive_dest_2='SERVICE=dg12s LGWR ASYNC DB_UNIQUE_name=dg12

db_unique_name should specify to ship redo logs from standby site to primary site after
switchover.

5. Connect as sysdba and issue the following command to start up, but not mount the
standby.
SQL>startup nomount pfile= <pfile created in above step >

6. Connect to target and auxiliary databases using RMAN:


$ rman target sys/manager@dg12 auxiliary sys/manager@dg12s
(In this example, dg12 = primary service name and dg12s = standby service name)
Recovery Manager: Release 11.2.0.1.0 - Production on Wed Jan 20 03:16:56 2010 Copyright (c) 1982, 2009,
Oracle and/or its affiliates. All rights reserved.
connected to target database: dg12 (DBID=3753412759)
connected to auxiliary database: dg12 (not mounted)
RMAN >

7. Execute the RMAN DUPLICATE command on standby:


RMAN >DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
DORECOVER
SPFILE SET "db_unique_name"="dg12s"
SET LOG_ARCHIVE_DEST_2="service=dg12s ASYNC REGISTER
VALID_FOR=(online_logfile,primary_role)DB_UNIQUE_name=dg12"
SET FAL_SERVER="dg12" COMMENT "Is primary"
SET DIAGNOSTIC_DEST=$ORACLE_HOME/admin/ <STNDBY_CONTEXT_name > COMMENT "DIAGNOSTIC Destination on standby
server"
SET UTL_FILE_DIR= <Appropriate value depending on standby context name >
NOFILEnameCHECK;

In the above example, RMAN automatically copies the server parameter file to the
standby host and then starts the auxiliary instance with this file.

Appendix E: RAC RMAN Clone Example

If you are using Rapid Clone for cloning an Oracle RAC primary database to standby, use the
following commands for RMAN backup and restore.

1. Take a hot backup using RMAN:


configure device type disk parallelism 5 backup type to backupset;
configure maxsetsize to 4200m;
backup as backupset tag 'RapidClone_RAC' database format '/oradata/MAABCU/RAC12STDBY/backupsets/%U';
backup as backupset tag 'RapidClone_RAC' archivelog all format '/oradata/MAABCU/RAC12STDBY/backupsets/%U';

2. Restore the and create standby database using RMAN. On the standby system first
node, start up the database in nomount mode (using a pfile) and run the following
command:
-bash-3.00$ rman target sys/manager@prod auxiliary /
Recovery Manager: Release 11.1.0.7.0 - Production on Thu Mar 11 02:17:43 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: PROD (DBID=3908691352)
connected to auxiliary database: PROD (not mounted)
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY;

3. Enable recovery on the node that is to be used for the recovery process.

Appendix F: Using adclone scripts to clone Oracle RAC primary to standby

This example shows how to use the adclonectx.pl and adclone.pl scripts in cloning an Oracle
RAC primary database to a standby.
$ perl $Standby_ORACLE_HOME/appsutil/clone/bin/adclonectx.pl contextfile=<STANDBY_ORACLE_HOME>/appsutil/<primary
instance>_<primary Host>.xml template=$ORACLE_HOME/appsutil/template/adxdbctx.tmp
pairsfile=<STANDBY_ORACLE_HOME>/appsutil/clone/pairsfile.txt
Provide the values required for creation of the new Database Context file.

Do you want to use a virtual hostname for the target node (y/n) [n] ?:

Target hostname [sales_west_001]:

It is recommended that your inputs are validated by the program.


However you might choose not to validate your inputs under following circumstances:
-If cloning a context on source system for a remote system.
-If cloning a context on a machine where the ports are taken and you do not want to shutdown the services at this
point.
-If cloning a context but the database it needs to connect is not available.
Do you want the inputs to be validated (y/n) [n] ?:

Target instance is a Real Application Cluster (RAC) instance (y/n) [y]:

Current node is the first node in an N Node RAC Cluster (y/n)[n]:y

Target System database name [prod]:stdby

Clone Context uses the same port pool mechanism as the Rapid Install

Enter the port pool number [0-99]:

8 Database port is 1529

Provide information for the Node 1 (current node):

Host name [sales_west_001]:

Instance number [1]:

Private interconnect name [sales_west_001]:sales_west_001-rac

Target system quorum disk location required for cluster manager and node monitor []:/tmp

Target system cluster manager service port [9998]:

Oracle OS User [oracle]:

Oracle OS Group [oinstall]:

Target system utl_file accessible directories list [/usr/tmp, /usr/tmp]:/usr/tmp

Number of DATA_TOP's on the target system [1]:

Target system DATA_TOP 1 [/oradata/MAABCU/RAC12/db/apps_st/data]:/oradata/MAABCU/RAC12STDBY/db/apps_st/data

Do you want to preserve the Display set to 192.0.2.10:64.0 (y/n) [y] ?:

Perl executable location is set to:

/usr/bin/perl

New context path and file name


[/oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/appsutil/stdby1_sales_west_001.xml]:

Creating the new Database Context file from :

/oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/appsutil/template/adxdbctx.tmp

The new database context file has been created :

/oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/appsutil/stdby1_sales_west_001.xml

$ perl adclone.pl java=<STANDBY_ORACLE_HOME>/appsutil/clone/jre component=dbTechStack mode=apply


stage=<STANDBY_ORACLE_HOME>/appsutil/clone/ method=custom
dbctxtg=<STANDBY_ORACLE_HOME>/appsutil/stdby1_sales_west_001.xml rmanstage=/oradata/MAABCU/RAC12STDBY/backupsets/
rmantgtloc=/oradata/MAABCU/RAC12STDBY/db/apps_st/data/ srcdbname=prod pwd=apps Beginning rdbms home Apply - Fri Mar 12
00:46:03 2010
-e
<STANDBY_ORACLE_HOME>/appsutil/stdby1_sales_west_001.xml
-stage
<STANDBY_ORACLE_HOME>/appsutil/clone/
-rmanstage
/oradata/MAABCU/RAC12STDBY/backupsets/
-rmantgtloc
/oradata/MAABCU/RAC12STDBY/db/apps_st/data/
-srcdbname
prod
APPS Password: apps
Log file located at <STANDBY_ORACLE_HOME>/appsutil/log/stdby1_sales_west_001/ApplyDBTechStack_03120046.log
Completed Apply...
Fri Mar 12 01:27:09 2010

Beginning APPSDB_stdby1 registration to central inventory...

ORACLE_HOME name: APPSDB_stdby1


ORACLE_HOME PATH: /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0
Using Inventory location in /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/oraInst.loc
Log file located at /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/oraInventory/logs/OracleHomeCloner_03120127.log
ORACLE_HOME /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0 was registered successfully.

Appendix G: Creating Non-RAC Standby for RAC Primary


G1. Configure Primary RAC to Create Non-RAC Standby
G2. Create Physical Standby

G1. Configure Primary RAC to Create Non-RAC Standby

Follow the instructions given in Section 3: Preparing the Primary Database for Standby
Database Creation to configure the primary RAC.

G2. Create Physical Standby

1. Copy ORACLE_HOME to Standby database server.

Copy the Oracle Home file system to the standby database server. If you natively
compile your PL/SQL, be sure you include the file system directories holding the
compiled objects. The standard location for this isRDBMS_ORACLE_HOME/plsql/nativelib.

2. Backup the primary RAC to backupsets using RMAN.

You should take the backup of the primary RAC database and copy the backupsets to
standby server. Refer to step 1 of Appendix E: RAC RMAN Clone Example for
complete RMAN instructions.
3. Perform file-based configuration on the standby database server.

After the database software copies are complete (which can be done before the database
itself is finished copying), log into the standby database server as the oracle user and
execute the following commands to update the file system configurations for the new
environment. Since your environment scripts are not yet set up, you will need to
manually resolve the reference to RDBMS_ORACLE_HOME.
$ cd RDBMS_ORACLE_HOME/appsutil/clone/bin
$ perl adcfgclone.pl dbTechStack

Answer the questions when prompted. If you receive any errors registering the new
ORACLE_HOME, follow the instructions given by the script to correct them.

For Target instance is a Real Application Cluster (RAC) instance (y/n) [y]: n

You should enter 'n' as the standby is non-RAC.

Note: Re-link oracle with rac_off option if adlnkoh.sh is failing then run adcfgclone
again.

Your oracle user environment scripts are now ready to use. Source them for the next
steps, using the appropriate OS command.
For example, in sh or ksh on UNIX:

$ cd RDBMS_ORACLE_HOME
$ ./STNDBY_CONTEXT.env

If you have implemented native PL/SQL compilation, set up an rsync job from the
primary database server to the standby database server for the file system directories
holding the compiled objects. The standard location for this
is RDBMS_ORACLE_HOME/plsql/nativelib.

Modify the initialization parameter as per 4.6 Modify the Database init.ora
Parameters on the standby server.

4. Stop the standby listener and configure for net redo transmission

Stop the listener and modify the <StandbySID>_ifile.ora to configure net redo
transmission, refer creating physical standby non-RAC Section 4: Creating a Physical
Standby Database.

5. Startup instance in nomount.


sqlplus / as sysdba
startup nomount

6. Create the standby database using RMAN.


rman target sys/<passwd>@<primaryservice> auxiliary sys/<passwd>@<stndbyservice>
rman>DUPLICATE DATABASE FOR STANDBY;

After the above the command execution the database will be in mount state running
with the initialization parametet (pfile).

Put the standby database in 'managed recover' mode.


SQL>alter database recover managed standby database disconnect from session;

Follow the steps from 4.8 Start shipping redo from the primary to the standby database
server to the end of Section 5: Configuration on Application Tiers After Standby
Database is Enabled for application tier configuration.

Appendix H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases

Data Guard Broker is an easy to use interface to manage standby databases. It is easy to
perform role transitions with a single command either for switchover or failover. This section
covers DGMGRL - the command line interface used to manage standby databases.

H1. Prerequisites
H2. Configure Data Guard Broker
H3. Role Transitions

H1. Prerequisites:

Prior to using Data Guard Broker, the standby database should be configured.
You must be using a server parameter file (spfile).

The Data Guard Broker starts database instances during switchover or failover using a
statically registered service name. Therefore, it is necessary to add a static descriptor to
the custom listener.ora file[<TNS_ADMIN>/<CONTEXT_name>_ifile.ora]. If you choose the
DGMGRL default, then configure as per option 1 below; if you are using a different
static descriptor, then set the DGMGRL StaticConnectIdentifier property, as per option
2.

o Option 1:
The default option is for the broker to assume the service
"<db_unique_name>_DGMGRL.<db_domain>" has been statically registered with the
listener of each instance. Add a SID_DESC entry as below:
(SID_DESC =
(GLOBAL_DBname=<DB_UNIQUE_name>_DGMGRL.us.oracle.com)
(ORACLE_HOME= <ORACLE_HOME>)
(SID_name = <SID>)
)

o Option 2:
Set the primary and standby databases StaticConnectIdentifier property, to a
TNS alias that resolves to a statically registered descriptor.
DGMGRL>edit database <Primary Database> set property StaticConnectIdentifier='<dg_prim>' where
dg_prim is TNS alias to connect the Primary
DGMGRL>edit database <Standby Database> set property StaticConnectIdentifier='<dg_stndby>' where
dg_stndby is TNS alias to connect the Standby

Add the two TNS aliases to ifile (<sid>_<node>_ifile.ora) under TNS_ADMIN on both
the standby and primary. For example:
dg_prim=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<primary host>(PORT=<port>))
(CONNECT_DATA=(SID=<sid>)(SERVER=DEDICATED)))
dg_stndby=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<standby host>(PORT=<port>))
(CONNECT_DATA=(SID=<sid>)(SERVER=DEDICATED)))

H2. Configure Data Guard Broker:

1. Start the Data Guard Broker on both primary and standby databases. The Data Guard
Broker will create two files under the location specified by the initialization
parameter DG_BROKER_CONFIG_FILEn. The default location is the $ORACLE_HOME/dbs/ directory.
alter system set dg_broker_start=TRUE.
2. Configure Data Guard broker using DGMGRL as follows:
dgmgrl sys/****@<primary database alias>
DGMGRL>CREATE CONFIGURATION '<Any Name>' AS PRIMARY DATABASE IS '<db_unique_name>' CONNECT IDENTIFIER IS
<Primary database alias>;

3. Add Standby database using the following command:


ADD DATABASE '<standby unique name>' AS CONNECT IDENTIFIER IS <Standby TNS Alias>;

4. Check the configuration using Show Configuration .

5. View the configuration using the Show Configuration command.

6. Set the following Data Guard Broker properties:

1. Set the configuration protection mode to maximum availability. At any time you
can change the protection mode of configuration. Note that this protection mode
requires that there be at least one standby database configured to use standby
redo log files, with its LogXptMode configurable database property set to
SYNC on both primary and standby.
DGMGRL>EDIT database <database name> set property LogXptMode='SYNC'
DGMGRL>EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

2. Do not enable FAST_START_FAILOVER as automatic failover is not supported.

H3. Role Transitions

H3.1 Switchover

1. Verify that the primary and the target standby databases are in the following states:
Primary TRANSPORT-ON and Standby APPLY-ON.

On Primary On Standby
DGMGRL> show database dbbrok DGMGRL> show database stndby
Database - dbbrok Database - stndby
Role: PRIMARY Role: PHYSICAL STANDBY
Intended State: TRANSPORT-ON Intended State: APPLY-ON
Instance(s): Instance(s):
dbbrok dbbrok
Database Status: Database Status:
SUCCESS SUCCESS

2.
3. Issue switch over command
DGMGRL>switchover to <standby database>;

4. Verify the switchover has been successful


show configuration
Databases:
stndby - Primary database
dbbrok - Physical standby database

5. To complete the switchover, follow the steps in Section 6 from 6.1.6 Complete the
database configurations.

H3.2 Switchback

Follow the same steps from the above section, but change the database name to switch over.
For example
DGMGRL> switchover to dbbrok; --> where dbbrok is current standby after a switchover.

H3.3 Failover

There are two types of failover using Data Guard Broker

Manual failover
Automatic failover using FAST START FAILOVER option (not Supported for Oracle E-
Business Suite)

Manual Failover

1. Connect DGMGRL to the standby database.


dgmgrl sys/manager@<Standby Database alias>
DGMGRL> failover to <Standby Database>
Performing failover NOW, please wait...
Failover succeeded, new primary is "stndby"

2. To complete the failover follow the steps in Section 6 starting from 6.2.7 Complete the
database configuration.

Automatic Failover

Automatic failover is not supported in Oracle E-Business Suite environments, since you need
to run AutoConfig before bringing standby environment online.

This section will be updated when post failover configurations are automated.

Change Log

Date Description
May 09, 2016 Implemented Remarks.
Jan 25, 2016 Changed the Minimum Version table. Updated Remarks.
Completed editorial and style review. Inserted Appendix G and updated
Jun 25, 2014
navigation.
Apr 12, 2014 Updated post internal review
Feb 25, 2014 Modified security info, corrected missing documents, readability.
Apr 22, 2013 Removed FAL_CLEINT occurrences as it is depricated in 11gR2
Jun 28, 2012 Implemented Remarks
Dec 01, 2011 Modified [Sep 05, 2011] change log description
Implemented Remarks, changed synchronize directories list in Step
Sep 05, 2011
7.3.4
July 19, 2011 Added Data Guard broker configuration in Appendix H
Implemented remarks, added Appendix F Creating non-rac standby
May 11, 2011
from RAC
Mar 15, 2011 Added atTechStack note box in section 5.1 and 7.3.5
Jan 25, 2011 Modified for Context file location under section 5.1
Oct 08, 2010 Changed for order of steps network configurations.
Jul 20, 2010 Changed for RAC Configuration
Mar 22, 2010 Initial publication.

My Oracle Support Knowledge Document 1070033.1, Business Continuity for Oracle E-


Business Suite Release 12 Using Oracle 11g Release 2 and Later Physical Standby Database,
by Oracle E-Business Suite Development.

Documentation Notices

Copyright 2010, 2014, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing
restrictions on use and disclosure and are protected by intellectual property laws. Except as
expressly permitted in your license agreement or allowed by law, you may not use, copy,
reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish,
or display any part, in any form, or by any means. Reverse engineering, disassembly, or
decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be
error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone
licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system,
integrated software, any programs installed on the hardware, and/or documentation, delivered
to U.S. Government end users are "commercial computer software" pursuant to the applicable
Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use,
duplication, disclosure, modification, and adaptation of the programs, including any operating
system, integrated software, any programs installed on the hardware, and/or documentation,
shall be subject to license terms and license restrictions applicable to the programs. No other
rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management
applications. It is not developed or intended for use in any inherently dangerous applications,
including applications that may create a risk of personal injury. If you use this software or
hardware in dangerous applications, then you shall be responsible to take all appropriate fail-
safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its
affiliates disclaim any liability for any damages caused by use of this software or hardware in
dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be
trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC
trademarks are used under license and are trademarks or registered trademarks of SPARC
International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks
or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The
Open Group.

This software or hardware and documentation may provide access to or information on content,
products, and services from third parties. Oracle Corporation and its affiliates are not
responsible for and expressly disclaim all warranties of any kind with respect to third-party
content, products, and services. Oracle Corporation and its affiliates will not be responsible for
any loss, costs, or damages incurred due to your access to or use of third-party content,
products, or services.

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility
Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For
information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or
visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

REFERENCES

NOTE:1070033.1 - Business Continuity for Oracle E-Business Release 12.1 Using Oracle 11g
Release 2 Physical Standby Database
NOTE:466649.1 - Using Oracle 11g Release 1 (11.1.0.7) Real Application Clusters and
Automatic Storage Management with Oracle E-Business Suite Release 12
NOTE:559518.1 - Cloning Oracle E-Business Suite Release 12 RAC-Enabled Systems with
Rapid Clone
NOTE:406982.1 - Cloning Oracle Applications Release 12 with Rapid Clone

Didn't find what you are looking for?