Data Guard

Document Display
1 of 29
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-stat...
Business Continuity for Oracle E-Business Release 12 Using Oracle 11g (11gR1) Physical Standby Database
(Doc ID 1545920.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 your Oracle E-Business Suite Release 12 environment to use Oracle Database 11gR1 as a physical
standby.
Note: This document applies to Oracle Database 11.1.0.7 only. For the equivalent information about Oracle Database version 11.2.0.1
or above, refer to My Oracle Support Knowledge Document 1070033.1.
The most current version of this document can be obtained in My Oracle Support Knowledge Document 1545920.1, Business Continuity for
Oracle E-Business Suite Release 12 Using Oracle 11g (11gR1) Physical Standby Database.
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.
There is a change log at the end of this document.
In This Document
This document is divided into the following sections:
Section
Section
Section
Section
Section
Section
Section
1:
2:
3:
4:
5:
6:
7:
Appendix
Appendix
Appendix
Appendix
Appendix
Appendix
Appendix
Appendix
Overview
Before You Start
Preparing the Primary Database for Standby Database Creation
Creating a Physical Standby Database
Configuration on Application Tiers After Standby Database is Enabled
Role Transitions
Oracle E-Business Suite Maintenance With Standby Database
A: Oracle Net Files

B: Using Oracle Applications Manager to Register Standby Database
C: Example Standby Database Commands
D: Using RMAN to Create Physical Standby Database
E: RAC RMAN Cloning Example
F: Example Cloning Script
G: Creating a Non-RAC Standby for the RAC Primary
H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases
A number of conventions are used in this document:

Convention
Meaning
Application tier
Machines running forms, web, concurrent processing and other servers. Sometimes called middle tier.
Database tier
Machines running Oracle E-Business Suite database.
Primary system
Primary Oracle E-Business Suite system, which will be used to create a standby system.
Standby system
Oracle E-Business Suite system created as a copy of the production 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>.
APPSpwd
Oracle E-Business Suite database user password.
Monospace text
Represents command line text; type such a command exactly as shown, excluding prompts such as '%'.
< >
Text enclosed in angle brackets represent a variable. Substitute a value for the variable text. Do not type the angle
brackets.
5/28/2015 12:31 AM
Document Display
2 of 29
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 schema, including indexes, is 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. Although 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
5/28/2015 12:31 AM
Document Display
3 of 29
standby database is resynchronized with the primary database. If there is a need to failover 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 a 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 the Oracle E-Business Suite.
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 Oracle 11g database server and have at least a basic knowledge of standby
database configurations.
Refer to the following documentation for further information:
5/28/2015 12:31 AM
Document Display
4 of 29
Oracle Database Administrator's Guide 11g Release 1(11.1), Part No. B28310-04
Oracle Data Guard Concepts and Administration 11g Release 1 (11.1), Part No. B28294-03
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 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 [Oracle RAC environments only]
2.2 Software Prerequisites

This document assumes the following minimum software versions:
Software
Component
Oracle
E-Business
Suite
Oracle
Database
11gR1
Minimum
Version
Additional Information
12.0.4 or
12.1.1
This document was developed using a fresh install database 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 pre-requisite 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 735276.1, Interoperability Notes
E-Business Suite 12.0 with Oracle Database 11gR1 (11.1.0).
11.1.0.7
For Oracle RAC Configurations: Databases configured for Oracle RAC configurations should refer to My
Oracle Support Knowledge Document 466649.1, Using Oracle 11g Release 1 Real Application Clusters and
Automatic Storage Management with Oracle E-Business Suite Release 12.
Note: 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 R1/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 ORACLE_HOME installed by Oracle E-Business Suite on application tier
INST_TOP
Directory that contains application instance directories and files
Note: If you want to ensure you have applied all the required application and database patches for cloning, refer to My Oracle Support
Knowledge Document 406982.1, Cloning Oracle Applications Release 12 with Rapid Clone for the latest patch information.
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 steps for
preparing the primary database for standby database creation 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
5/28/2015 12:31 AM
Document Display
5 of 29
3.4 Set Primary Database Initialization Parameters

3.5 Enable Archive Logging on 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 and 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 on 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 as it must 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_client.server init.ora parameters, allowing two-way communication between the primary and the
standby. The fal_client alias is a connect string to the standby; the fal_server alias is the reverse, 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 in 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.
Note 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 step.
3.4 Set Primary Database Initialization Parameters
5/28/2015 12:31 AM
Document Display
6 of 29
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

The table below lists the parameters relating to archive destinations and transmission of redo data to the standby system:
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:
log_archive_dest_2
SERVICE:
Standby Service Name - this is the DB_UNIQUE_NAME
LGWR:
Redo Log information can be transmitted in one of two ways from primary to
physical standby either LGWR or ARCH process. LGWR is used in this
document.
ASYNC:
Specifies that network I/O is to be performed asynchronously for the

destination. You can optionally specify a block count (from 0 to 102,400) that
determines the size of the SGA network buffer to be used.
REOPEN:
The minimum number of seconds before the log writer process (LGWR)
should try again to access a previously failed destination.
MAX_FAILURE:
The maximum number of reopen attempts before the primary database

permanently gives up on the standby database.
NET_TIMEOUT:
Specifies the number of seconds the log writer process on the primary system
waits for status from the network server (LNS n) process before terminating
the network connection.
log_archive_dest_state_2
When set to ENABLE, allows redo transport services to transmit redo 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 file name 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.
log_archive_config
Enables or disables the sending of redo logs to remote destinations 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.
fal_client
Specifies the TNS network service name that the primary database should use to connect to the
standby.
5/28/2015 12:31 AM
Document Display
7 of 29
standby_file_management
Set to AUTO. Whenever data files are added or dropped from primary database, corresponding
changes will be made automatically to the standby.
db_file_name_convert,
log_file_name_convert
Specify the path name and file name location of data files and redo log files. db_file_name_convert
parameter need not be set when the directory structures are same on primary and standby. But
log_file_name_convert should set to dummy values if you are using same directory structure to
enable redo log clearing.
Remote_login_passwordfile
This parameter checks specifies whether Oracle checks for a password file. Since we are using
password authentication this parameter should set.
For further explanation of the initialization parameters, refer to Oracle Data Guard Concepts and Administration 11g Release 1 (11.1).
The configuration examples use the names shown in the following table:
Primary Database Physical Standby Oracle RAC Primary Oracle RAC Standby
Oracle Net Service name dg12
dg12s
prod
stdby
SID
dg12
dg12
prod1 and prod2
stdby1 and stdby2
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 of 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
fal_client = dg12s
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
fal_client=stdby
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 Primary System
5/28/2015 12:31 AM
Document Display
8 of 29
Enable archiving on primary system if it is not already enabled.
3.6 Add Standby Redo Logs

Standby redo logs are required to use real-time apply. As the remote file server (RFS) process writes the redo data to standby redo log files
on the standby database, apply services can recover redo from standby redo log files as they are being filled.
Best practice is to add them in both the primary and the standby database so switchovers between the environments are quicker and easier.
Here, you will add them in production so they are in place when you clone the database for the standby.
Standby redo logs are additional redo log groups with a different type. You can only have as many redo log groups overall as the maximum
setting for your database for log file groups and log file members.
Standby redo log groups should be multiplexed in the same manner as online redo log groups.
To create standby redo log groups, as the ORACLE user on the primary database server, connect to SQL*Plus as sysdba and issue a
command like this for each standby redo log group you will create:
SQL>alter database add standby logfile group N (<log_file >) size NNN;
For an example, refer to Appendix C: Example Standby Database Commands.

Note for Oracle RAC Configurations: Ensure 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 for 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/<context_name>
$ 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_TOP and Oracle E-Business Suite technology
stack software.
5/28/2015 12:31 AM
Document Display
9 of 29
$ cd INST_TOP/admin/scripts/<context_name>
$ 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 Support 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 Your 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 files open, put the tablespace in the 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 and for RAC
Appendix E: RAC RMAN Cloning Example for examples of usage.
If you used 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: This is an optional step. 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
5/28/2015 12:31 AM
Document Display
10 of 29
$ 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: In addition, perform the following steps.
1. Run adclonectx and adclone on all nodes.
2. 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 F:
Example Cloning Script.
3. Modify the init parameter files to point the correct diagnostic destination and utl_file_dir with standby context directory.
4. 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 these steps 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
5/28/2015 12:31 AM
Document Display
11 of 29
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
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 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 a 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.
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:
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 and 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 which logs have been sent/received and applied:
5/28/2015 12:31 AM
Document Display
12 of 29
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 Your 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 now. You collected the temporary file names and sized 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 in 4.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;
4.11 Data Guard Broker Configuration (optional)

If you wish to use Oracle Data Guard Broker to manager an Oracle E-Business Suite standby database, follow sections H1 and H2 of
Appendix H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases.
Section 5: Configuration on Application Tiers After Standby Database is Enabled

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
Note: Ignore database connection failures while running the above command.
Refer to My Oracle Support Knowledge Document 406982.1 Cloning Oracle Applications Release 12 with Rapid Clone for details.
2. When the script has finished and the context file is created, execute the following commands, again resolving he 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 tries to connect to the database,
so some portions will fail, but the environment scripts should be created successfully.
5/28/2015 12:31 AM
Document Display
13 of 29
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, 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. The following 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, supporting 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.
The following role transitions are discussed:
6.1 Performing a Switchover
6.2 Performing a Failover
6.3 Performing a Switchback to Primary After Switchover/Failover
For all three transitions, applications 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

Note: If you are using Oracle Data Guard Broker to manage the standby database, follow section H3 in Appendix H: Using Data Guard
Broker [DGMGRL] to Manage Standby Databases, then proceed 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.
Sections 3, 4, and 5 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 logfile 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.
5/28/2015 12:31 AM
Document Display
14 of 29
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 switchover on the primary database

Note for Oracle RAC Configurations: For switchover, only one primary instance should be mounted. All others must be shut down.
After switchover, LOG_ARCHIVE_DEST_STATE_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_STATE_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;
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
5/28/2015 12:31 AM
Document Display
15 of 29
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
$ lsnrctl start <SID>
4. On the new standby server, stop and start the listener for standby services:
$ lsnrctl
$ lsnrctl start <Standby Service>
5. For application-specific configurations, follow the steps in 6.4 Configurating 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 Oracle Data Guard Broker to manage standby databases, follow the steps under "Manual Failover" in section H3
of Appendix H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases, then go to 6.2.6 Complete the database
configuration.
You may need to failover to your standby site due to the complete failure of the primary site. This section describes the steps in the event of
failure of the primary site.
Sections 3, 4 and 5 define how to set up your environments so there will be minimal parameter changing during failover. 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 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.2 Identify and resolve any archives 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
5/28/2015 12:31 AM
Document Display
16 of 29
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.3 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.
6.2.4 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:
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.5 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.6 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:
5/28/2015 12:31 AM
Document Display
17 of 29
SQL>lsnrctl stop
SQL>lsnrctl start <SID>
To complete application-specific configurations, follow the steps in 6.4 Application Tier Configuration After a Role Transition
(switchover/failover/switchback).
Note for Oracle RAC Configurations: Repeat above steps 2 and 3 for each instance.
6.3 Performing Switchback to Primary After Switchover/Failover

6.3.1 Switchback to primary site after a switchover
After switchover 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.
2.
3.
4.
Verify primary database at standby site is open and standby database at primary site is mounted.
Verify all the redo logs are transferred to standby and applied.
Check whether switchover_status from v$database is showing TO STANDBY.
On the primary database, issue the command:
SQL>alter database commit to switchover to physical standby
5.
6.
7.
8.
Adjust the LOG_ARCHIVE_DEST_STATE_2 defer at standby site(primary database) and enable at primary site (standby database).
Adjust the network configurations as mentioned in 6.1.5 Switch the selected standby database to the primary role.
Shut down and mount the database as standby at the standby site.
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 commands.
11. For application-specific configurations, follow the steps in 6.4 Application Tier Configuration After a Role Transition
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.
2.
3.
4.
5.
6.
7.
Make a consistent backup of activated standby database at standby site.

Restore the backup created at standby site to primary database.
Run AutoConfig on both the database tier and application tier.
Shut down and start up the database.
On the original primary site, create or modify the initialization parameter file with the appropriate values.
Create a new standby database at the original standby site. Follow instructions in Sections 3, 4 and 5.
For application-specific configurations, follow the steps in 6.4 Application Tier Configuration After a Role Transition
6.4 Application Tier Configuration After a 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
5/28/2015 12:31 AM
Document Display
18 of 29
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_requests table
to the name of the new primary server (that was the standby before the role transition):
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=' ';
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 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.
Applying an application patch when standby is configured requires:
Syncing of standby with the primary after applying the patch. There are two choices:
Syncing File system using rsync, and redo log apply for the database.
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:
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
5/28/2015 12:31 AM
Document Display
19 of 29
standby recovery before applying patches. This document uses the approach of stopping recovery.
If you have enough disk space, backup both the databases and Oracle E-Business Suite file system before patching.
These steps are broken into three major sections:

7.1 Prepare to Apply Application Patch
7.2 Patch the Primary
7.3 After Applying the Patch
7.1 Prepare to Apply Application Patch

7.1.1 On the standby: stop recovery delay 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 Oracle RAC Configurations: Perform switching on each instance.

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.
7.2 Patch the Primary

Check that the patch applied successfully.
7.3 After Applying the Patch

Perform the following steps after successful patch application.
5/28/2015 12:31 AM
Document Display
20 of 29
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:
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):
$ 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 these directories: APPL_TOP, COMMON_TOP, 10.1.2 ORACLE_HOME, and 10.1.3
ORACLE_HOME.
For an Oracle E-Business Suite technology stack upgrade, synchronize these directories: OracleAS 10.1.2 ORACLE_HOME and
OracleAS 10.1.3 ORACLE_HOME.
7.3.4 Start Application Tier Services on Primary

As the APPLMGR user, start all application tier services:
$ 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 the standby is different to the primary then you need to run "perl adcfgclone.pl atTechStack
<STNDBYCONTEXT>.xml"
Refer to My Oracle Support Knowledge Document 406982.1, Cloning 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)
5/28/2015 12:31 AM
Document Display
21 of 29
Note for Oracle RAC Configurations: 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>
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_client/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.
#
# This entry must point to the current standby server - i.e. this is the
# fal_client alias used to communicate from primary to standby.
# 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 =
5/28/2015 12:31 AM
Document Display
22 of 29
(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
Appendix 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, and also 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

Example for standby redo log files:
Alter database add standby logfile group 4 ('/d1/MAABCU/primary/dg12data/log5.dbf') size 50M ;
5/28/2015 12:31 AM
Document Display
23 of 29
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

Perform the following steps when using RMAN to create a physical standby database:
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 the standby.

3. Change DB_UNIQUE_NAME to standby DB_UNIQUE_NAME - this should be different from the 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
using this file.
Appendix E: RAC RMAN Cloning Example

If you are using Rapid Clone for cloning an Oracle RAC primary database to standby, take the following steps for RMAN backup and restore.
1. Take a hot backup using RMAN:
configure
configure
backup as
backup as
device type disk parallelism 5 backup type to backupset;

maxsetsize to 4200m;
backupset tag 'RapidClone_RAC' database format '/oradata/MAABCU/RAC12STDBY/backupsets/%U';
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
5/28/2015 12:31 AM
Document Display
24 of 29
-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: Example Cloning Script

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
5/28/2015 12:31 AM
Document Display
25 of 29
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 a Non-RAC Standby for the RAC Primary

1. 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 primary RAC.
2. 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 is <RDBMS 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 Cloning Example for complete RMAN instructions.
3. Perform the file base 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>.
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 need to enter 'n' as standby is non-RAC.
Note: If adlnkoh.sh fails, re-link Oracle using the rac_off option, and 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
5/28/2015 12:31 AM
Document Display
26 of 29
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 to 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 parameter (PFILE).
Put the standby database in 'managed recover' mode.
For application tier configuration, follow the steps in Section 4: Creating a Physical Standby Database from 4.8 Start Shipping
Redo From the Primary to the Standby Database Server through 4.10 Add Your Temp Files to the Standby Database, and then
all the steps in Section 5: Configuration on Application Tiers After Standby Database is Enabled.
Appendix H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases

Oracle 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.
1. Prerequisites
2. Configure Oracle Data Guard Broker
3. Role Transitions
H1. Prerequisites:
Prior to using Oracle 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.
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>)
)
5/28/2015 12:31 AM
Document Display
27 of 29
Option 2:
Set the primary and standby databases StaticConnectIdentifier property, to a TNS alias that resolves to a statically registered
descriptor.
DGMGRL>edit database
alias to connect the
DGMGRL>edit database
alias to connect the
<Primary Database> set property StaticConnectIdentifier='<dg_prim>' where dg_prim is TNS

Primary
<Standby Database> set property StaticConnectIdentifier='<dg_stndby>' where dg_stndby is TNS
Standby
Add the two TNS aliases to ifile (<sid>_<node>_ifile.ora) under TNS_ADMIN on both 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 will be $ORACLE_HOME/dbs/ directory.
alter system set dg_broker_start=TRUE
2. Configure Data Guard Broker using DGMGRL.

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

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

Database - dbbrok
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
dbbrok
Database Status:
SUCCESS
DGMGRL> show database stndby

Database - stndby
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Instance(s):
dbbrok
Database Status:
SUCCESS
5/28/2015 12:31 AM
Document Display
28 of 29
2. Issue the switchover command.

DGMGRL>switchover to <standby database>;
3. Verify the switchover has been successful.

show configuration
Databases:
stndby - Primary database
dbbrok - Physical standby database
4. To complete the switchover, follow the steps in Section 6: Role Transitions starting from 6.1.6 Complete the Database Configurations.
3.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.
3.3 Failover
There are two types of failover using Oracle 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: Role Transitions starting from 6.2.6 Complete the database configuration.
Automatic Failover
Automatic failover is not supported in the Oracle E-Business Suite environment, since you need to run AutoConfig before bringing the
standby environment online. During this time, this section will be updated when post failover configurations are automated.
Change Log
Date
Description
03 Jun 2014
Performed editorial and style review.
06 Apr 2014
Updated post review validation.
26 Feb 2014
Modified security info, corrected missing documents.
01 Aug 2013
Modified for log_archive_dest_state parameter.
16 Apr 2013
Initial publication.
My Oracle Support Knowledge Document 1545920.1, Business Continuity for Oracle E-Business Suite Release 12 Using Oracle 11g (11gR1)
Physical Standby Database, by Oracle E-Business Suite Development.
Documentation Notices
Copyright 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
5/28/2015 12:31 AM
Document Display
29 of 29
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.
Didn't find what you are looking for?
5/28/2015 12:31 AM

Data Guard

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Data Guard

Загружено:

Авторское право:

Доступные форматы

Document Display

A: Oracle Net Files

A number of conventions are used in this document:

Machines running Oracle E-Business Suite database.

Oracle E-Business Suite system created as a copy of the production system.

The default is <SID>_<stdby_hostname>.

Oracle E-Business Suite database user password.

TNS alias to connect to primary database.

Standby TNS alias

TNS alias to connect to standby database.

1.1 Standby Database

1.2 Oracle Data Guard

1.3 Oracle Data Guard Broker

Section 2: Before You Start

2.1 Design Considerations

2.2 Software Prerequisites

Oracle 11g R1/R2 Database ORACLE_HOME

Directory that contains the application product directories and files

Directory that contains application instance directories and files

Section 3: Preparing the Primary Database for Standby Database Creation

3.4 Set Primary Database Initialization Parameters

3.1 Enable Forced Logging

3.2 Configure Oracle Net Communication To and From Standby System

3.3 Set Up Secure Connections

3.4 Set Primary Database Initialization Parameters

Primary database: primary role initialization parameters

Standby Service Name - this is the DB_UNIQUE_NAME

Specifies that network I/O is to be performed asynchronously for the

The maximum number of reopen attempts before the primary database

prod1 and prod2

stdby1 and stdby2

# db_file_name_convert: do not need; same directory structure

3.5 Enable Archive Logging on Primary System

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

3.6 Add Standby Redo Logs

For an example, refer to Appendix C: Example Standby Database Commands.

3.7 Invite Communications From the Standby

3.8 Gather Temporary File Information

Supply the APPS password when requested.

Section 4: Creating a Physical Standby Database

Copy the control file to the standby database server.

4.3 Perform File-based Configurations on the Standby Database Server

$ perl adcfgclone.pl dbTechStack

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

4.4 Stop the Database Listener on the Standby Database Server

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

Update the following parameters:

SQL>startup nomount pfile= <RDBMS ORACLE_HOME>/dbs/init <primary SID>.ora | spfile

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

4.9 Verify Redo is Shipping

4.10 Add Your Temp Files to the Standby Database

4.11 Data Guard Broker Configuration (optional)

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

Optionally, set up rsync for log and out files.

Section 6: Role Transitions

6.1 Performing a Switchover

6.1.1 Preparing for switchover to standby server

SQL>select switchover_status from v$database;

6.1.2 Initiate the switchover on the primary database

6.1.3 Shut down and mount the primary database

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

6.1.4 Verify the switchover status on the standby server

6.1.5 Switch the selected standby database to the primary role

Adjust the network parameters on both database servers