3/26/2020 Document 1491855.

1
Copyright (c) 2020, Oracle. All rights reserved. Oracle Confidential.

Business Continuity for Oracle E-Business Suite Release 12.2 Using Oracle 11g (11gR2)
Physical Standby Database (Doc ID 1491855.1)

Oracle E-Business Suite Release 12.2.x 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.2.x environment to use Oracle Database
11gR2 as a physical standby. This document covers both non-RAC and RAC configurations with single or multiple
Application tiers.

The most current version of this note is available as My Oracle Support Knowledge Document 1491855.1, Business
Continuity for Oracle E-Business Suite Release 12.2 Using Oracle 11g (11gR2) 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.

Note: There are some limitations when using these configurations, which are are explained throughout this
document. Even though an ADOP patching cycle may appear to continue following a failover event, you must abort
and restart the ADOP cycle as resuming is not supported.

There is a change log is 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: Configure the Application Tiers After the Standby Database has been 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 Data Guard Broker (DGMGRL) to Manage Standby Databases
Appendix G: Creating Non-RAC Standby for RAC Primary
Appendix H: Handling Online Patching Following A Standby Failover Event

A number of conventions are used in this document:

Convention Meaning

Machines running forms, web, concurrent processing and other servers. Sometimes called middle
Application tier
tier.

Database tier Machines running Oracle E-Business Suite database.

Primary system Primary Oracle E-Business Suite system, which will 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>.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 1/42
3/26/2020 Document 1491855.1

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.

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
TNS alias to connect to primary database.
database alias

Standby TNS
TNS alias to connect to standby database.
Alias

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.

There are three types of standby databases:

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

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 2/42
3/26/2020 Document 1491855.1

Oracle Data Guard is a set of services that create, manage, and monitor 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 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. It 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 the following three components:

Data Guard GUI through Enterprise Manager

Data Guard command-line interface (DGMGRL)
Data Guard monitor

The broker automates and simplifies the following operations:

Standby database creation

The Enterprise Manager wizards 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: This document contains specific steps to set up a physical standby with Oracle E-Business Suite for both
RAC and non-RAC.

Role transitions
This 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 with Oracle E-Business Suite. For further details, refer to
Appendix D: Using DataGuard Broker (DGMGRL) to Manage Standby Databases.

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

Section 2: Before You Start

This section shows the classic/traditional architecture of an Oracle E-Business Suite 12.2 DataGuard Configuration, where
the systems are replicated across the primary and standby sites. This traditional approach is described in more detail in
https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 3/42
3/26/2020 Document 1491855.1

Configuration 1: Configuring the Standby application tiers to connect the STANDBY Database
section 5.1 , and an
Configuring the
alternative where all the application tiers are connected the primary (for patching purposes) in section 5.2
Standby application tiers to connect to the PRIMARY Database.

2.1 Design Considerations

This note assumes you already have 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.
Have sufficient network bandwidth between the data centers to handle the peak redo and concurrent manager
output: 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
locations.
Ideally mirror the number and type of the production machines, though fewer DR machines could be used with
reduced performance.

g
You should be familiar with the Oracle11 database server and have at least a basic knowledge of possible standby
database configurations.

Refer to the following documentation for further information:

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

Oracle Data Guard Concepts and Administration 11g Release 2 (11.2)
In addition, you should be familiar with the following Oracle E-Business Suite Release 12 documentation:

My Oracle Support Knowledge Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid
Clone
My Oracle Support Knowledge Document 1679270.1, Cloning Oracle E-Business Suite Release 12.2 RAC Enabled
Systems with Rapid Clone
https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 4/42
3/26/2020 Document 1491855.1

2.2 Software Prerequisites

This document assumes the following minimum software versions:

Software Applicable
Additional Information
Component Version(s)

12.2.4,
Oracle E- This document was developed using a fresh install database from an Oracle E-Business
12.2.5,
Business Suite Release 12.2 Rapid Install with the prerequisite patches listed in the "Prerequisite
12.2.6,
Suite Tasks" section of chapter 17 in the Oracle E-Business Suite 12.2 Setup Guide.
12.2.7

Oracle 11.2.0.3
Database and
g
11 R2 11.2.0.4

Note: The standby and primary systems must use the same Oracle Database and Oracle E-Business Suite versions.

This document refers to the following top-level directories:

Directory Purpose
RDBMS_ORACLE_HOME g
Oracle 11 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

FMW_HOME FMW_HOME installed by Oracle E-Business Suite on application tier

INST_TOP Directory that contains application instance directories and files

Note:
For non-RAC configurations: Refer to My Oracle Support Knowledge Document 1383621.1, Cloning Oracle E-
Business Suite Release 12.2 with Rapid Clone
and ensure that you have applied all the required application and
database cloning patches.
For RAC configurations: Refer to My Oracle Support Knowledge Document 1679270.1, Cloning Oracle E-Business
Suite Release 12.2 RAC Enabled Systems with Rapid Clone
and ensure that you have applied all the required patches
for RAC to RAC cloning.

Prerequisite Patches:

Oracle strongly recommends that you always apply the latest version of the AD and TXK release update packs. For the
latest patches, refer to My Oracle Support Knowledge Document 1617461.1 Applying the Latest AD and TXK Release
Update Packs to Oracle E-Business Suite Release 12.2 .

If you are on Delta 6, you will also need to apply:

Patch 21878338 Required to fix the ADOP issues in a Data Guard Configuration.

Note: Oracle recommends that you upgrade to a minimum of DELTA 7 in order to implement Data Guard.

Section 3: Preparing the Primary Database for Standby Database Creation

At this point, you will have a server on which you will create the physical standby. The top-level mount points on each
secondary site server need to be the same as on the corresponding primary server. Ownership and permissions must be
https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 5/42
3/26/2020 Document 1491855.1

set appropriately for each mount point and you need a mechanism and appropriate system permissions to perform remote
file copies. The steps for preparing the primary database for standby database creation are divided into the following
steps:

3.1 Enable Forced Logging

3.2 Configure Oracle Net Communication To and From the Standby
3.3 Set Up Secure Connections
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 the APPL_TOP and Oracle E-Business Suite Technology Stacks to Application Tiers on the 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 that will be used to create the
standby database.

Use the following SQL command to set FORCE LOGGING on the primary database:

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 the Standby System

The primary and standby databases must be able to communicate using Oracle Net. This means that on the standby, a
listener needs to be running in order to handle incoming requests from the primary. In addition, TNS aliases must be
created on both the primary and standby systems. Configure ifiles under the TNS_ADMIN directory for the aliases and
listener. Although you can use either a service model (dynamic registration) or SID (static registration) model, but
Autoconfig only uses static registration and so this is the approach used throughout this document.

Standby Listener

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

TNS Aliases

The fal_server initialization parameter specifies one or more Oracle Net service names for the databases from which the
standby database can fetch (request) missing archived redo log files Refer to A1 of Appendix A: Oracle Net Files for an
example.

Note For RAC Configurations: The TNS alias requirements are different. Refer to A2 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 a Data
Guard configuration. These redo transport sessions are authenticated using either the Secure Sockets Layer (SSL) protocol
or a remote login password file. Use the following command to create a password file:

$ cd <RDBMS_ORACLE HOME>/dbs
$ orapwd file=orapw <SID> password= <SYS password> entries= <max privileged users> ignorecase=y

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 6/42
3/26/2020 Document 1491855.1

Note For RAC Configurations: Create password files for all instances. This document uses a password file. For
further information refer to My Oracle Support Knowledge <Document 1367293.1>, Enabling SSL or TLS in Oracle E-
Business Suite Release 12.2 , for the database SSL setup.

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

On the primary database, define initialization parameters that control redo transport services.

Note: This document uses a static init.ora include file to record the necessary 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 ifile:
<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 the 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:

SERVICE: Standby Service Name. This is the DB_UNIQUE_NAME.

Redo Log information can be transmitted in one of two ways

LGWR: from primary to physical standby 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 optionally specify a block count
ASYNC:
(from 0 to 102,400) that determines the size of the SGA
log_archive_dest_2
network buffer to be used.

The minimum number of seconds before the log writer

REOPEN: process (LGWR) should try to access a previously failed
destination.

The maximum number of reopen attempts before the

MAX_FAILURE: primary database gives up trying to connect to the standby
database.

Specifies the number of seconds the log writer process on

the primary system waits for the status from the network
NET_TIMEOUT:
server (LNS n) process before terminating the network
connection.

When set to ENABLE. this allows the redo transport services to transmit redo
log_archive_dest_state_2 data to the specified destination. Set this value to ENABLE on the primary site
to send archive log files automatically to the standby.

log_archive_format
Specifes the filename format for use when archiving redo log files. System
defaults are used if this is 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.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 7/42
3/26/2020 Document 1491855.1
log_archive_config Enables or disables the sending of redo logs from the primary to one or more
remote destinations.

db_unique_name
Unique Name to identify the primary and standby databases (For example,
'dg12' for primary and 'dg12s' for physical standby).

Specifies the TNS network service name that the standby database should use
to connect to the FAL (Fetch Archive Log) server process. The FAL Server
services request archive redo logs from the FAL clients that are running on the
fal_server standby database(s). Set this parameter to the primary database service name
(such as dg12 ) in order to request missing archived redo log files if the primary
is unable to send the missing log files automatically or there was an interruption
to the connection or hardware availability.

fal_client No longer needs to be set as of RDBMS version 11.2.0.3.

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.

Specify the path and file name locations of data files and redo log files. The
db_file_name_convert parameter does not need to be set when the directory
db_file_name_convert,
log_file_name_convert structures are the same on both the primary and standby. The
log_file_name_convert parameter should be 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. As
we are using password authentication, it is essential that this parameter is set.

For further explanation of the initialization parameters, refer to Oracle Data Guard Concepts and Administration 11g
Release 2 (11.2) .

The configuration examples used throughout this document 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
DB_NAME dg12 dg12 prod prod
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 on the primary database.

db_unique_name = dg12 ---- You need to change this to the standby db_unique_name (such as dg12s) when you
copy this file to the 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 you can just leave it set to the default.

# db_file_name_convert: ---- you do not need to specify this if you use the same directory structure
# log_file_name_convert: ---- you do not need to specify this if you use the same directory structure
fal_server = dg12
log_file_name_convert = xx,xx ---- Specify dummy values to trigger log clearing

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 8/42
3/26/2020 Document 1491855.1

Note For RAC Configurations: When using a shared file system, in order to prevent overwriting archive log files for
different nodes, you need to use a specific format when naming the archive logs on each node. This is configured in
the <instance>_<node>_ifile.ora file on each of the nodes that form the primary Oracle RAC system. The
<instance>_<node>_ifile.ora configuration assumes that prod and stdby are the service
names/db_unique_names on the primary and standby respectively. log_archive_dest_1 should be in a shared
location.

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

Enable archiving on the 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 online redo logs: create standby redo log files with
the same sizes, groups and number of membersas on the primary.

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. It is therefore important that you size the files
accordingly.

To create standby redo log groups, as the ORACLE user on the primary database server, connect to SQL*Plus as sysdba
and use the following command as a template for each standby redo log group that you will create:

SQL>alter database add standby logfile group N (<log_file>) size NNN;

For additional examples, refer to Appendix C: Example Standby Database Commands.

Note For RAC Configurations: Ensure that the standby logs are created for each redo thread. For an example,
refer to Appendix C: Example Standby Database Commands.

3.7 Invite Communications from the Standby

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 9/42
3/26/2020 Document 1491855.1

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 and tcp.validnode_checking = yes will be set in
$TNS_ADMIN/sqlnet.ora. In this case, the standby hosts and additional computers with direct access to the Oracle E-
Business Suite database (using SQL*Plus, etc.) will need to be explicitly defined by IP or Hostname as Invited Nodes. For
example, tcp.invited_nodes = (IP Address, hostname.example.com. There are two options for configuring the
invited node list to ensure that they are not overwritten by AutoConfig. You can use OAM; refer to Appendix B: Using
Oracle Applications Manager to Register Standby Database for detailed steps. Alternatively you can list the nodes in the
ifile: sqlnet_ifile.ora.

tcp.validnode_checking = yes
tcp.invited_nodes = (<IP Address>, hostname.example.com)

3.8 Gather Temporary File Information

You will need to manually recreate temporary files on the standby database. Use the following query to gather the
required data now from the primary database:

SQL>select file_name, bytes from dba_temp_files;

Save the output from this query as you will need to refer to it in a later step.

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

Note: Although there shouldn't be an open patching cycle in this case, it is good practice before running pre-clone
scripts to always ensure that there is no open ADOP cycle.

1. 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 APPSpwd when requested.

Note For RAC Configurations: Run these pre-clone scripts on all database and application tier hosting the
WLS admin server.

2. Log on to the run edition file system on the Weblogic Admin server node on the source system as the APPLMGR
user. Run the following preclone command on both the run and patch edition file systems:

Note: Before executing this step, ensure the AdminServer on both the Run Edition File System and the Patch
Edition File System is running. The AdminServer on the Patch Edition File System can be shut down after
completion of adpreclone.pl.

$ cd $INST_TOP/admin/scripts/
$ perl adpreclone.pl appsTier

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

Refer to the the following for the list of the directories that you need to copy:

For single node refer to My Oracle Support Knowledge Document 1383621.1,Cloning Oracle E-Business Suite
Release 12.2 with Rapid Clone.
For Oracle RAC systems, refer to My Oracle Support Knowledge Document 1679270.1, Cloning Oracle E-Business
Suite Release 12.2 RAC Enabled Systems with Rapid Clone.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 10/42
3/26/2020 Document 1491855.1

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.

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

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 Clone the database and mount the Physical Standby and 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 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. For further information, refer to Appendix D: Using RMAN to Create a
Physical Standby Database.

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.

Note For RAC Configurations: To create the RAC standby this document uses RMAN duplicate database for
standby from Active Database.The benefit of using this command is that it only mounts the database in standby
mode.

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

Note: Skip this step if you used RMAN to copy the database.

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

You will need to recover past the time that the control file was created, and so you will have to 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';

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 11/42
3/26/2020 Document 1491855.1

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

Once the database software copies have completed (which can be done before the database itself has finished copying),
log onto the standby database server as the ORACLE user and execute the following commands to update the file system
configuration for the new environment. As 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

Note For RAC Configurations: Perform the following steps:

Run adclonectx to create the context file and then run the following command on all nodes:

$ perl adclonectx.pl contextfile=<Primary Node Context File> template=

<ORACLE_HOME>/appsutil/template/adxdbctx.tmp pairsfile=<ORACLE_HOME>/appsutil/clone/pairsfile.txt
initialnode

Answer each of the questions. When prompted, use the initial node option for adclonectx on all nodes,
otherwise it will prompt for the "Live RAC node", which will not be available at this time.

Modify the initialization parameter files so that they point to the correct thread and have the correct diagnostic
destination. Ensure that utl_file_dir points to the standby context directory. On completion, run the
following command:

$ perl adcfgclone.pl dbTechStack <Context file created in the step above>

If using role separation, manually run setasmgidwrap as the Grid user to change and correct the permission of
the oracle binary to the asmadmin group:

$ <CRS_HOME>/bin/setasmgidwrap -o <ORACLE_HOME>/bin/oracle

If you receive any errors when answering the questions and registering the new ORACLE_HOME, follow the instructions to
correct them.

Your ORACLE user environment scripts are now ready to use. Source them prior to continuing, using the appropriate OS
command.

For example, in sh or ksh on UNIX:

$ cd <RDBMS_ORACLE_HOME>
$ . <STNDBY_CONTEXT>.env

If you use 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

Adcfgclone in step 4.3 starts the database listener. This needs to be stopped as the standby database listener is not yet
fully configured. As the ORACLE user on the standby database server, enter the following command:

$ lsnrctl stop <listener name>

4.5 Configure Oracle Net for Redo Transmission, Start the Listener

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 12/42
3/26/2020 Document 1491855.1

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 tnsnames.ora file.
2. In the <STNDBY_CONTEXT>_ifile.ora, ensure the standby service's HOST parameter includes the standby
database host name, and that 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. Refer to Appendix A: Oracle Net Files for example entries.
4. As the ORACLE user, start the database listener on 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 based on 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 should be updated to a name different from the primary: for example dg12s.
LOG_ARCHIVE_DEST_2 should point to the standby service. This is necessary when the servers are reversed as the
standby is changed to act as the primary and will now ship redo to the new standby.
For example, LOG_ARCHIVE_DEST_2 for 'service= dg12ASYNC 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 to the standby control file that you created on the primary and copied to this server:

control_files = <control file directory>/<standby control file>, <control file directory>/<standby control
file>

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

Note For RAC Configurations: Create the physical standby RAC database using the RMAN duplicate command. For
instructions, refer to Appendix D: Using RMAN to Create a RAC Physical Standby Database.

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, perform the following once the database copy has completed:

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 into 'managed recover' mode.

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

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 13/42
3/26/2020 Document 1491855.1

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

4.9 Verify Redo is Shipping

Check to ensure that the database is shipping redo, by connecting to the primary database and forcing a log switch:

SQL>alter system switch logfile;

While still on the primary, check for the status of the archive destinations to determine the most recently archived redo log
file at each of the redo transport destinations. The most recently archived redo log file should be the same at 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, the following query will show the which logs 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 Your Temp Files to the Standby Database

Note: Skip this step if you used RMAN to create the standby.

To save time on failover, add your temp files to the standby database at this point using the temporary file names and
sizes collected 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 that 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;
SQL>alter database recover managed standby database disconnect from session;

4.11 Data Guard Broker Configuration (Optional)

If you wish to use the Oracle Data Guard broker to manage an Oracle E-Business Suite standby database, follow the steps
outlined in F1 and F2 of Appendix F: Using Data Guard Broker (DGMGRL) to Manage Standby Databases.

Section 5: Configure the Application Tiers After the Standby Database has been
Enabled
In Oracle E-Business Suite 12.1.3 an application patch on the primary would be copied to the standby tiers and the the
cloning scripts would update the configuration. In Oracle E-Business Suite 12.2, this is complicated by the run and patch
file systems which need to be kept in sync.The process described in this document takes the approach of patching both
the primary and standby application tiers. the alternative approach is to connect both the primary and standy application
tiers to the primary database, which means that in the event of a failover or switchover, you just need to connect them to
the standby database.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 14/42
3/26/2020 Document 1491855.1

This section explains the two possible methods to configure the Standby application tiers:

5.1 Configuration 1: Configuring the Standby application tiers to connect the STANDBY Database
5.2 Configuration 2: Configuring the Standby application tiers to connect to the PRIMARY Database

5.1 Configuration 1: Configuring the Standby application tiers to connect the STANDBY Database

Under this configuration, the stanby application tiers are connected to the standby database. We can have following
topologies for this configuration:

Symmetric Configuration
Scale Down Configuration

5.1a Symmetric Configuration

The following diagram shows the symmetrical configuration of a disaster recovery site, where the application tiers connect
to their respective instance (primary or standby).

5.1b Scale Down Configuration

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 15/42
3/26/2020 Document 1491855.1

The following diagram shows the scale down configuration of a disaster recovery site, where the primary and standby sites
may not contain the same number of nodes.

After the application tier software copies have completed, you need to clone the applications tier, which will require a
connection to the database. The standby database will not be open. Open the standby database in snapshot mode and
then execute adcfgclone to clone the application tiers. Once this has completed, change the standby back into standby
mode.

5.1.1 Convert the Standby to a Snapshot Standby

5.1.2 Configure the Standby Application Tiers
5.1.3 Revert the Physical Standby Database Back to its Original State

5.1.1 Convert the Standby to a Snapshot Standby

1. The first step is to configure the physical standby database to use flashback logging for flashback database
operations.

2. A flashback database requires that the flashback logs reside in the Flash Recovery Area (FRA). Although the FRA
may already be configured for your environment, the flashback logs can significantly increase FRA usage. It is not
unheard of to double the size of the FRA to utilize flashback database and so you need to take this into account.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 16/42
3/26/2020 Document 1491855.1

SQL>alter system set db_recovery_file_dest_size=32g scope=both;

SQL>alter system set db_recovery_file_dest='/u03/flash_recovery_area' scope=both;
SQL>alter system set db_flashback_retention_target=1440 scope=both;

Note: If you are using a pfile, add the following entries to the ifile located in <contextname_ifile>.ora
under $ORACLE_HOME/dbs:
db_recovery_file_dest_size=32G
db_recovery_file_dest='/u03/flas_recovery_area'
db_flashback_retention_target=1440

Substitute an appropriate destination size for your system.

3. Stop redo apply on the physical standby database:

SQL>alter database recover managed standby database cancel;

4. Turn on flashback logging:

SQL>alter database flashback on;

5. Convert the standby database into a snapshot standby database:

Note For RAC Configurations: Shutdown all other instances except one, which is the one you will be using
to execute the following command.

SQL>alter database convert to snapshot standby;

6. Shut down the snapshot standby database and startup the database (it will be opened for read/write access):

SQL>shutdown immediate;
SQL>startup

Note for RAC configurations: Startup all the instances.

7. Remove the applications configuration.

$ sqlplus apps/<password>
SQL>exec fnd_conc_clone.setup_clean;
SQL>exec ad_zd_fixer.clear_valid_nodes_info;

8. Run AutoConfig on the database tier.

$ $ORACLE_HOME/appsutil/scripts/<CONTEXT_DIRECTORY>/adautocfg.sh

Note For RAC Configurations: Run AutoConfig on all of the RAC database nodes once, and then run it again
on each node so that it updates the sqlnet.ora with all the node names.

9. Add the application nodes to the $TNS_ADMIN/sqlnet.ora file on each of the standby database nodes.

10. Reload the database listeners so that they reread the sqlnet.ora using the following command:

$ lsnrctl reload <EBS Listener Name>

5.1.2 Configure the Standby Application Tiers

1. Log on to the run edition file system on the standby system as the APPLMGR user and enter the following
commands:

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 17/42
3/26/2020 Document 1491855.1

$ cd <COMMON_TOP>/clone/bin
$ perl adcfgclone.pl appsTier

2. Run adpreclone.pl on the run edition file system in the standby system.

3. Copy the Oracle E-Business Suite application directories (<APPL_TOP>, <common_top>,Oracle AS Tools 10.1.2
Oracle_Home) from the run edition file system to the patch edition file system on the standby system.

Note: When copying files, ensure that the symbolic links are also created (under <OracleAS Tools 10.1.2
ORACLE_HOME> and <COMMON_TOP>.

4. Once you have cloned the run file system, you also need to clone the patch file system from the run file system.

Note: In AD-TXK Delta 7, we recommend you clone the Application tier run and patch file systems in a single
operation, using the 'dualfs' option. Separate cloning of the run and patch file systems will be deprecated in the
future.

Run the following command as the APPLMGR user on the patch edition file system in the target standby system:

$ cd <COMMON_TOP>/clone/bin
$ perl adcfgclone.pl appsTier

Note: For detailed instructions on creating standby application tier(either single node or master node in a multi
node configurations), refer to My Oracle Support Knowledge Document 1383621.1, Cloning Oracle E-Business
Suite Release 12.2 with Rapid Clone.

5. To configure multiple non-shared application tiers:

1. Execute $INST_TOP/scripts/adpreclone.pl appsTier on both run and patch file system of the
first/master node.
2. Copy the EBSapps directory for both run and patch systems to the other node. For example, the master
node has fs1 as run and fs2 as patch then copy fs1/EBSapps and fs2/EBSapps to the other node.
3. Execute $COMMON_TOP/clone/bin adcfgclone.pl appsTier on both run and patch file system by
selecting add node option on the other node.

Note: For detailed instructions on configuring non-shared multiple nodes, refer to Section 5.2 of My
Oracle Support Knowledge Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with
Rapid Clone.

5.1.3 Revert the Physical Standby Database Back to its Original State

1. Change the standby database back into its standby mode (from snapshot mode) as follows:

SQL>startup mount force;

SQL>alter database convert to physical standby;
SQL>shutdown immediate;
SQL>startup nomount;
SQL>alter database mount standby database;

2. Enable redo log apply.

SQL>alter database recover managed standby database using current logfile disconnect;

3. On the primary database, issue the following statement to re-enable archiving to the physical standby database:

SQL>alter system set log_archive_dest_state_2=enable scope=both;

5.2 Configuration 2: Configuring the Standby application tiers to connect to the PRIMARY Database

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 18/42
3/26/2020 Document 1491855.1

The following diagram shows all the standby application tiers are connected to the primary database, which simplifies
patching as all tiers will participate in a patching cycle. Note that the services on the standby applications tiers will be
disabled. Also note that the standby master node is separate to this group and will need to be be replicated separately
from the primary master node. On switchover or failover, the standby application tiers will need to be connected to the
standby database, which will become primary following a role transition. This simplifies patching as compared to the
previous approach, but the trade-off is that there are several configuration steps that need to be performed.

This section describes the primary and standby configuration of an example two node RAC with 3 non-shared multiple
application tiers.

Primary Site
prdbnode1 stdbnode1
Database Tier (RAC)
prdbnode2 stdbnode2

Application Tier stdby-node1

prim-node1 (Admin Node)
switchover/f
prim-node2 stdby-node2

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 19/42
3/26/2020 Document 1491855.1

prim-node3 stdby-node3

Note: In this configuration the Admin server node APPL_TOP should not be shared with any of the slave nodes. The
slave nodes can have shared APPL_TOP so long as they are not shared with the Admin node of either the primary or
standby sites. The reason is that the admin server is replicated to the standby site and it makes the switch over faster
and reduces the number of steps.

To add the standby application tiers to the primary database:

1. Setup the standby admin server application node to use shared storage such that the file systems can be replicated
from the primary site admin server node using disk replication. Refer to the Storage Replication
section of the
Fusion Middleware Disaster Recovery Guide for further information.

2. Configure the secondary nodes as follows:

Note: It is important that you familiarize yourself with the concepts and overview discussed in the Cloning a
Multi-Node System section of Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone Document
1383621.1 .

Note: The following six steps are not required if you only have a single node standby applications on the
standby site.

1. Run the pre-clone scripts on the primary application admin server node on both the RUN (fs1 for
example) and PATCH (fs2 for example)file systems. In th table above, the admin server is hosted on
prim-node1.

$ perl $INST_TOP/scripts/adpreclone.pl appsTier

2. Copy the EBSapps directories to the new standby application tiers (on the slave nodes) from the RUN (under
fs1) and PATCH (under fs2) file systems on the primary application tier.

3. Run the clone scripts to add the standby application tiers to the primary using the add node option. During
cloning, the admin server on the primary server needs to be up and running to access both the run and
patch file system.

$ perl $COMMON_TOP/clone/bin/adcfgclone.pl appsTier

Use the following questions and answers:

"Target System File Edition type [run]:" answer 'run'
"Do you want to add a node (yes/no):" answer 'yes'

4. At this point, all the standby application tiers will have been added to the primary database. To copy the
Weblogic domain configuration to newly added nodes, start any of the mananged servers and then stop it.

$ admanagedsrvctl.sh start <any manager server for example oacore_server4>

5. Disable the services on standby application tier nodes in order to avoid having the services startup whenever
cutover is run . In the run and patch file system context files, set the services to a disabled state on all of
the standby slave nodes.

<oa_service_group_status oa_var="s_root_status">disabled</oa_service_group_status>
<oa_service_group_status oa_var="s_web_admin_status">disabled</oa_service_group_status>
<oa_service_group_status oa_var="s_web_entry_status">disabled</oa_service_group_status>
<oa_service_group_status oa_var="s_web_applications_status">disabled</oa_service_group_status>
<oa_service_group_status oa_var="s_batch_status">disabled</oa_service_group_status>
<oa_service_group_status oa_var="s_other_service_group_status">disabled</oa_service_group_status>

6. Run AutoConfig on all standby application tier slave nodes after disabling the services.

Section 6: Role Transitions

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 20/42
3/26/2020 Document 1491855.1

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.

The following role transitions are discussed:

6.1 Performing a Switchover

6.2 Performing a Failover
6.3 Performing a Switchback to the Primary Following A Switchover/Failover

Each of these three transitions requires some application configuration to be performed. Most of the
application configuration steps are common to all of the transitions and so are grouped 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 Data Guard broker to manage the standby database, follow the steps provided in the F3
Role Transitions section of Appendix F: Using Data Guard Broker (DGMGRL) to Manage Standby Databases,
then skip to to step 6.1.6 Complete the Database Configuration.

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

There will be minimal parameters to change on switchover if you have configured your parameter files as
previously defined in sections 3,4 and 5.

6.1.1 Preparing for switchover to standby server

Note: Before proceeding, it is essential that you complete the ADOP patching cycle: prepare, apply, cutover,
cleanup. When using an online patch or hotpatch run fs_clone to make sure that both run and patch file
systems are at the same patchlevel.

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

2. Shut down all the application tier services on all nodes on the primary site.

$ adstpall.sh <appsuser>/<appspass>

3. Verify there are no active users connected to the database and shut down all of the sessions in the primary
database.

4. Issue the following SQL command on the primary and standby databases to ensure that the last redo data
file transmitted from the primary database has been applied to the standby database. If necessary, perform
a log file switch prior to running the query.

SQL>select sequence#,applied from v$archived_log;

5. Query the switchover_status column of v$database to determine whether the database is ready to
switch modes.
https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 21/42
3/26/2020 Document 1491855.1

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 RAC Configurations: Only one primary instance should be open during a switchover; all others
must be shut down. After switchover LOG_ARCHIVE_DEST_STATE_2 should be set for all instances (on the
current primary after switchover).

Connect as sysdba and issue the following SQL command:

SQL>alter database commit to switchover to physical standby with session shutdown;

After this statement completes, the primary database will have been 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,
which makes it possible to reconstruct the control file if necessary.

Change the value of LOG_ARCHIVE_DEST_STATE_2 to defer on the 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 the 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;

Note: 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 that it is ready to switch to become
the 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 6.1.2 above.

6.1.5 Switch the Selected Standby Database to the Primary Role

Note For RAC Configurations: As in section 6.1.2, only one primary instance should be open during a
switchover; 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 read-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;

Update the network parameters on both database servers

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

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 22/42
3/26/2020 Document 1491855.1

Change the LOG_ARCHIVE_DEST_STATE_2 to enable. on the new primary.

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 configuration

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;
SQL>exec ad_zd_fixer.clear_valid_nodes_info;

2. As the ORACLE user on the new primary database server, run AutoConfig to complete the configuration,
providing the APPSpwd when prompted:

$ cd <RDBMS_ORACLE_HOME>/appsutil/scripts/<context>
$ ./adautocfg.sh

3. Once autoconfig has completed, 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 <standby service>

$ lsnrctl start <standby service>

Note For RAC Configurations: Repeat steps 2-4 on each instance (each node will have its own
listener). Rerun AutoConfig on all nodes after completing steps 2-4 for each instance to update all
configuration files with all nodes in the cluster.

5. For applications-specific configurations, follow the steps in 6.4 Configuring Application Tiers After Role
Transition (Switchover/Failover/Switchback).

6.2 Performing a Failover

Note: If you are using Data Guard broker to manage standby databases, follow the steps provided in the F3
Role Transtions section of Appendix F: Using Data Guard Broker (DGMGRL) to Manage Standby Databases,
then go to 6.2.7 Complete the database configuration.

This section describes the steps necessary to perform a failover to your standby site due to a complete
failure of the primary site.

There will be minimal parameters to change on switchover if you have configured your parameter files as
previously defined in sections 3,4 and 5.

Performing a failover means that you will need to create a new standby database environment from the
environment to which you failed over as soon as possible to ensure maximum disaster recovery protection.

Note: If there is an incomplete ADOP patching cycle, follow the steps in Appendix H: Handling Online
Patching Following A Standby Failover Event in order to abort the patch cycle after you have performed
the Database failover steps.

6.2.1 Flush any Unsent Redo from the Primary Database to the Target Standby Database

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 23/42
3/26/2020 Document 1491855.1

If the primary database can be mounted, it may be possible to flush any archived 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 the 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 that 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, as shown in the
commands below:

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 the 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 Redo Data

Note For 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 the redo apply:

SQL>alter database recover managed standby database cancel;

Finish the recovery session:

SQL>alter database recover managed standby database finish;

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 24/42
3/26/2020 Document 1491855.1

When that completes, convert the physical standby to perform 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 the TNS parameters for the 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;
SQL>exec ad_zd_fixer.clear_valid_nodes_info ;

2. As the ORACLE user on the new primary database server, use AutoConfig to complete the configuration for
the 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 <SID>

SQL>lsnrctl start <SID>

To complete the application-specific configuration, follow the steps in 6.4 Configuring Application Tiers After
a Role Transition (Switchover/Failover/Switchback).

6.3 Performing a Switchback to the Primary Following A Switchover/Failover

6.3.1 Switch Back to the Primary Site after a Switchover

Note: Before proceeding, it is essential that you complete the ADOP patching cycle: prepare, apply, cutover,
cleanup. When using an online patch or hotpatch run fs_clone to make sure that both run and patch file
systems are at the same patchlevel.

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

Standby Site Primary Site

Primary database Standby database

Steps to perform the switchback to the primary site:

1. Verify the primary database at the standby site is open and the standby database at the primary site is
mounted.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 25/42
3/26/2020 Document 1491855.1

2. Verify all the redo logs are transferred to the standby and applied.
3. On the primary site, check whether switchover_status from v$database is showing: TO STANDBY.
4. Shutdown all the services on the primary application tier.
5. On the primary database, issue the command:

Note For RAC Configurations: Shut down all the other instances before you perform the following
steps.

SQL>alter database commit to switchover to physical standby;

6. Adjust the LOG_ARCHIVE_DEST_STATE_2 defer at the standby site (primary database) and enable it at the
primary site (standby database).
7. Update the network configurations as mentioned in 6.1.5 Switch the selected standby database to the
primary role.
8. Shut down and mount the database as a standby at the standby site.
9. Start the recovery by issuing the following commands at the primary site:

SQL>alter database commit to switchover to physical primary;

10. Shut down and start up the database at the primary site. Complete the database configuration by following
6.1.6 Complete the database configurations.
11. Verify that the redo log files are shipping as expected. Refer to 6.1 Performing a Switchover for the
commands.
12. 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 Following a Failover

If you performed a failover to a standby database and then resolved the problem at the original primary site,
you can now recreate the primary database on the original primary site:

1. Make a consistent backup of the activated standby database at the standby site.
2. Restore the backup created at the standby site to the primary database.
3. Run AutoConfig on database tiers.
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 the instructions in Sections 3, 4 and 5.
7. For application-specific configurations, follow the steps in 6.4 Application Tier Configuration After a Role
Transition (Switchover/Failover/Switchback).

6.4 Configuring Application Tiers After Role Transition (Switchover/Failover/Switchback)

There are two methods explained in this document to configure application tiers Configuration 1 and
Configuration 2 in Section 5.
6.4.1 Configuring the Application Tiers after a role transition when the application tiers are configured using
Configuration 1
6.4.2 Configuring the Application Tiers after a role transition when the application tiers are configured using
Configuration 2

6.4.1 Configuring the Application Tiers after a role transition when the application tiers are
configured using Configuration 1

6.4.1.1 Finish the Oracle E-Business Suite configuration on the Application Tiers

Note: Ensure that you have added all application node names to sqlnet.ora file under $TNS_ADMIN on all
database nodes.

After the primary database configuration is complete and its listeners have started, log in to each primary
application tier server as the APPLMGR user, and run the final configuration steps on the run file systems:

$ cd $INST_TOP/admin/scripts
$ ./adautocfg.sh

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 26/42
3/26/2020 Document 1491855.1

Provide the APPSpwd when prompted.

On the patch file system go to $AD_TOP/bin/ and run the following command:

$ perl adconfig.pl contextfile= <INST_TOP>/appl/admin/PATCH CONTEXT.xml -syncctx

6.4.1.2 Update the Host Name in FND_CONCURRENT_REQUESTS and FND_CONC_REQ_OUTPUTS

If you synchronize your concurrent manager log and out directories, you must update the host name in the
fnd_concurrent_requests table 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=' ';

If you run the later 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.1.3 Perform the Cloning Finishing Tasks

Perform the Finishing Tasks outlined in My Oracle Support Knowledge < Document 1383621.1>, Cloning
Oracle E-Business Suite Release 12.2 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.1.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.1.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.1.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.

6.4.2 Configuring the Application Tiers after a role transition when the application tiers are
configured using Configuration 2

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 27/42
3/26/2020 Document 1491855.1

The following configuration steps need to be performed only on the slave nodes. The admin server is
replicated to another server on standby In this configuration.

6.4.2.1 Configure the Standby Admin Server Application Tier.

In this configuration, you need to replicate the primary admin server application tier. If
necessary (depending on the method of disk replication that you are using) for the standby
WLS Admin server, you may need to attach the storage to the new server.

1. On the Standby admin server, change the hostname and IP address in /etc/hosts,
/etc/sysconfig/network, and the /etc/sysconfig/network-scripts/ifcfg-eth0 files.
In /etc/hosts add an entry with primary admin node name and IP address in the following
format:

IPAddress prim-node1.domain prim-node1

In /etc/sysconfig/network:

NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=prim-node1.example.com

In /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0 ONBOOT=yes
BOOTPROTO=static
IPADDR=<New IP Address>
NETMASK=<netmask>
GATEWAY=<gateway>
TYPE=Ethernet

2. Reboot the server.

3. Modify the context variables in the context file and tnsnames.ora to connect to the new
primary database. Follow all the steps in Section 6.4.2.1.
4. Configure password less SSH to each of the slave nodes from this node.

6.4.2.2 Modify the context variables in run and patch context files to change the Database connectivity to new
primary on slave application tiers.

Note for Switchover : Run steps [1-6] on all slave nodes of both the primary and the standby so that all the
application tiers will be connected to current primary database.
Note for Failover : Run steps [1-6] on all slave nodes only as the primary application tiers are not available.

1. In the context files, change s_dbhost and s_dbport to point to the first node of the current primary RAC
database. - As we mentioned in the heading , not there in steps

from:
<dbhost oa_var="s_dbhost">prdbnode1</dbhost>
to:
<dbhost oa_var="s_dbhost">stdbnode1</dbhost>

2. Mark the services as being enabled on standby application tier:

<oa_service_group_status oa_var="s_root_status">enabled</oa_service_group_status>
<oa_service_group_status oa_var="s_web_admin_status">disabled</oa_service_group_status>
<oa_service_group_status oa_var="s_web_entry_status">enabled</oa_service_group_status>
<oa_service_group_status oa_var="s_web_applications_status">enabled</oa_service_group_status>
<oa_service_group_status oa_var="s_batch_status">enabled</oa_service_group_status> ********
Enable this if you are using ICM on that node.
<oa_service_group_status oa_var="s_other_service_group_status">disabled</oa_service_group_status>

3. Change the JDBC context variables s_apps_jdbc_connect_descriptor,

s_apps_jdbc_patch_connect_descriptor to the new Database Nodes/SCAN Host in the context file:

<jdbc_url oa_var="s_apps_jdbc_connect_descriptor">jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(LOAD_BALANCE=YES)(FAILOVER=YES)

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 28/42
3/26/2020 Document 1491855.1
(ADDRESS=(PROTOCOL=tcp) (HOST=<NEW SCAN NAME)(PORT=<NEW SCAN PORT>)))(CONNECT_DATA=(SERVICE_NAME=
<Service Name>)))</jdbc_url>

<patch_jdbc_url oa_var="s_apps_jdbc_patch_connect_descriptor">jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)
(HOST=<New SCAN Host)(PORT=<New Scan port>))(CONNECT_DATA=(SERVICE_NAME=ebs_patch)
(INSTANCE_NAME=r122b1)))</patch_jdbc_url>

Note: If you have configured VIP instead of SCAN, change all the database host names to the new
primary database nodes VIP host names and port.

4. Update the EBS Database Source. Change directory to $EBS_DOMAIN_HOME/config/jdbc/ and edit
EBSDataSource-<n>-jdbc.xml as follows:

<url>jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=YES)(FAILOVER=YES)(ADDRESS=
(PROTOCOL=tcp)(HOST=<SCAN HOST>)(PORT=<SCAN PORT>)))(CONNECT_DATA=(SERVICE_NAME=<service name)))
</url>

5. Run AutoConfig on the run file system on all of the nodes.

$ $INST_TOP/admin/scripts/adautocfg.sh

6. To sync the patch file system with above changes, check whether an ADOP cycle is open.

$ adop -status

If the ADOP is open then execute AutoConfig on patch file system. (Skip this step if ADOP cycle is not
open)

$ $INST_TOP/admin/scripts/adautoconfig.sh

If there is no open ADOP cycle, source the patch file system go to $AD_TOP/bin/ and run the
following command :

$ perl adconfig.pl contextfile= <INST_TOP>/appl/admin/PATCH CONTEXT.xml -syncctx

Next execute the following command from run file system on the admin/primary node:

Note: Run this step on the admin/primary node only.

$ adop phase=prepare,cutover

7. Start the services on slave nodes

$ adstrtal.sh <apps_user>/<apps_password>

6.4.2.3 After a Failover Remove the Primary Slave Nodes from the Configuration.

Following a failover to the standby site, the primary slave nodes do not exist in the new configuration and
therefore it is essential that they are deleted using the following command from the admin server node:

$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-delete-node -contextfile=<CONTEXT_FILE> -

hostname=<node_name_to_be_deleted> -logfile=<LOG_FILE>

For further information on deleting a node, refer My Oracle Support Knowledge Document 1383621.1, Cloning Oracle E-
Business Suite Release 12.2 with Rapid Clone.
Section 7: Oracle E-Business Suite Maintenance with Standby Database

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 29/42
3/26/2020 Document 1491855.1

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

7.1 Prepare to Apply an Application Patch

7.2 Patch the Primary
7.3 After Applying the Patch

Note: If your standby database is running during a patch application, the database changes on primary will be
automatically pushed or replicated on the standby. To protect both the integrity of the primary and standby
from any problems during patch application, backup both the databases and Oracle E-Business Suite file system
before patching. You may be able to achieve this more quickly with certain types of disk systems that use
mirroring.

7.1 Prepare to Apply an Application Patch

7.1.1 Stop/remove the recovery delay if is set on the standby

If you have recovery delay set for redo log application on the standby, change the delay. On the standby
database, run the following command as a privileged user:

SQL>alter database recover managed standby database cancel;

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

7.1.2 Switch redo logs on the primary database

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

SQL>alter system switch logfile;

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

Note For RAC Configurations: Repeat this command to switch the logs on each instance.

7.1.3 Ensure all log files are applied on the standby

On the standby database server, connect as sysdba and monitor the system to ensure that all log files have
been shipped 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;

7.2 Patch the Primary

Open a patch cycle and apply the patch, either as a hotpatch or an online patch.

Note: If using hotpatch mode, stop the recovery on the standby. With online patching, before starting the
cutover phase, ensure that you shipped all the redo log files and applied them on the standby. Stop the redo
shipping and recovery on to the standby, which will isolate it and maintain it's integrity.
On the Standby stop the recovery using:

SQL>alter database recover managed standby database cancel;

On the Primary stop the redo shipping:

SQL>alter system set log_archive_dest_state_<n>=defer;

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 30/42
3/26/2020 Document 1491855.1

Note: If there is a failover during a patching cycle, after performing Database failover steps , then follow the
steps in Appendix H: Handling Online Patching Following A Standby Failover Event in order to abort the patch
cycle.

7.3 After Applying the Patch

Restart the redo log shipping once you have checked that there are no issues.

7.3.1 Complete the patch cycle

It is essential that you complete the ADOP patching cycle: prepare, apply, cutover, cleanup. When using an
online patch or hotpatch run fs_clone to make sure that both run and patch file systems are at the same
patchlevel.

7.3.2 Syncronize the Primary and Standby Application Tiers

The primary and standby databases are in sync with the patch data, to syncronize the application tiers:

7.3.2.1 Put the Standby database into Snapshot Standby mode.

1. Synchronize the primary and standby database by forcing a redo log switch on the primary (In the
case of RAC, on all instances):

SQL>alter system switch logfile;

2. Follow all of the steps [1-10] in Section 5.1.1 to open the standby database in Snapshot Standby
mode, so that the database can be updated by AutoConfig.

7.3.2.2 Run AutoConfig

Execute AutoConfig on each of the standby application tiers.

7.3.2.3 Apply the patches to the Standby using hotpatch mode with the nodatabaseportion option

Note: Ensure that you have closed the ADOP cycle on primary site before applying patches to the
standby.

Apply all the patches which were applied to the primary using online patching on the standby.

1. If the primary and standby run file systems are different, flip the file system on the Standby application tiers
to be the same as the Primary using the following commands/steps.

1. Upload the Patch file system context file to the Database. In a new terminal source PATCH
environment and execute CtxSynchronizer to load the PATCH context file to the database.

$ $ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer action=upload contextfile=<full

path to patch context file> logfile=/tmp/patchctxupload.log

2. Now source the RUN environment and execute one of the following commands to flip the file system.

If you only have one standby applications tier, run the following command on that node (which is the
master node):

$ perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl -action=ctxupdate -

contextfile=<full path to current run context file on standy> -patchcontextfile=<full path
to current patch file system context file on standby> -outdir=<full path to out directory>

If you have multiple standby applications tiers, run the following command on the master node,
which includes the -multinode=Yes parameter:

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 31/42
3/26/2020 Document 1491855.1

$ perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl -action=ctxupdate -

multinode=Yes -contextfile=<full path to current run context file on standby> -
patchcontextfile=<full path to current patch file system context file on standby> -outdir=
<full path to out directory>

Note: If either of these commands fail, manually create the TXK_CTRL_ctxupdate directory in
the outdir directory if it doesn't exist. Once the file system has been changed, run the
environment file so that it now points to the new run file system.

2. After flipping the filesystem, run AutoConfig to populate ADOP_VALID_NODES table before starting ADOP
session.

3. Copy the $PATCH_TOP to the application tier in the standby site.

4. Apply the patches using hotpatch in the order that they were applied on the Primary. Use
options=nodatabaseportion so that the they are applied without updating the database:

$ adop phase=apply patches=patch number apply_mode=hotpatch options=nodatabaseportion

Note: If you apply a patch using hotpatch mode, you could, but do not need to, run: adop
phase=fs_clone to synchronize the patch file system as this will be done during the next adop
phase=prepare phase.

5. If you have previously applied FMW Patches (for example FMW 10.1.2 Oracle Home patches) on the
primary, also apply those patches to the current run file system on the standby site. In this case you will
need to run the cloning command to synchronize the patch file system on the standby site.:

$ adop phase=fs_clone

6. Synchronize the code on any other Application Tiers.

7. Put the snapshot standby database into Physical Standby mode by executing the steps in section 5.1.3.

7.3.3 Reconfigure the standby database file systems (optional)

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:

1. Source the Oracle Applications environment and run the following command to create the file appsutil.zip in
<INST_TOP>/admin/out

$ perl <AD_TOP>/bin/admkappsutil.pl

2. Copy appsutil.zip to the database servers and uncompress appsutil.zip under the <RDBMS ORACLE_HOME>

$ cd <ORACLE_HOME>
$ unzip -o appsutil.zip

3. 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 - Answer the questions when prompted.

$ lsnrctl stop <SID>

$ cd < RDBMS_ORACLE_HOME>/appsutil/clone/bin
$ perl adcfgclone.pl dbTechStack

4. The step above starts the database listener for the primary services. You need to stop and restart it for the standby
services:

$ lsnrctl stop <SID>

$ lsnrctl start < standby service name>

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 32/42
3/26/2020 Document 1491855.1

Appendix A: Oracle Net Files

This appendix is divided into a common section (Common Listener Configuration for RAC and Non-RAC) and then:

A1: TNS Alias Requirements in a non-RAC Configuration

A2: TNS Alias Requirements in an Oracle RAC Configuration

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

Primary Physical Standby

Oracle Net Service Name dg12 dg12s

SID dg12 dg12

Common Listener Configuration for RAC and Non-RAC:

A sample <TNS_ADMIN>/listener_ifile.ora file

##################################################################
#
# Created to define net services to support a Oracle Data Guard physical
# standby environment.
#
##################################################################
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= ) (GLOBAL_NAME=dg12s)
(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 a non-RAC Configuration

Sample < TNS_ADMIN>/<CONTEXT_NAME>_ifile.ora file.

##################################################################
#
# 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.
# IT MUST BE CHANGED on switchover:
dg12s=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)
(HOST= < standby DB host name>)
(PORT= <Same PORT as primary)
)
(CONNECT_DATA=(SID=dg12)
)
https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 33/42
3/26/2020 Document 1491855.1
) #
# 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) ) )

A2: TNS Alias Requirements in an 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.

Sample <TNS_ADMIN>/<CONTEXT_NAME>_ifile.ora file.

##################################################################
#
# 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
# IT MUST BE CHANGED on switchover:
prod=
(DESCRIPTION=
(LOAD_BALANCE=NO)
(FAILOVER=YES)
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=<Primary DB Host1>)
(PORT=<dbport>))
(ADDRESS=
(PROTOCOL=tcp)
(HOST=<Primary DB Host2)
(PORT=<dbport>)) )
(CONNECT_DATA=(SERVICE_name=prod))
)
stdby=
(DESCRIPTION=
(LOAD_BALANCE=NO)
(FAILOVER=YES)
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=<Stndby DB Host1)
(PORT=<dbport>))
(ADDRESS=
(PROTOCOL=tcp)
(HOST=<Stndby DB Host2>)
(PORT=<dbport>))
)
(CONNECT_DATA=(SERVICE_name=stdby)(UR=A))
)

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:

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 34/42
3/26/2020 Document 1491855.1

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:

SQL>Alter database add standby logfile group 4 ('/d1/MAABCU/primary/dg12data/log5.dbf') size 50M;

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

Note For RAC Configurations: Add standby redo log files for each thread using the following example
command that uses a 300MB file.

SQL>alter database add standby logfile thread 1 group 10 ('+DATA/dbfiles/stdbylog1.dbf') size 300M;

Appendix D: Using RMAN to Create a Physical Standby Database

Perform the following steps when using RMAN to create a physical standby database :

1. Ensure that you have completed steps 4.1 to 4.4 in Section 4.

2. Ensure that you have completed the network configurations and started the standby database listeners.
3. Start the standby database in nomount mode

sqlplus / as sysdba
SQL>startup nomount;

4. Verify the connections to primary and auxiliary database.

$ sqlplus sys/<password>@<TNS alias to primary>

$ sqlplus sys/<password>@<TNS alias to standby> as sysdba

5. Create initialization parameter file for standby. Run the following command on the primary database server:

SQL>create pfile from spfile

6. Copy init_<SID>.ora from the primary to the standby database server.

7. Change the db_unique_name to the standby db_unique_name; this should be different from the primary
database.

For example, db_unique_name=dg12s

8. For log_archive_dest_2, specify the primary db_unique_name.

For example, log_archive_dest_2='SERVICE=dg12 LGWR ASYNC DB_UNIQUE_NAME=dg12'

db_unique_name should specify to ship redo logs from the standby site to the primary site after switch over.

9. Connect as sysdba and issue the following command to start up but not mount the standby database.

SQL>startup nomount pfile=<pfile created in above step>

10. Connect to target and auxiliary databases using RMAN:

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 35/42
3/26/2020 Document 1491855.1

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

11. 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=dg12 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 to clone an Oracle RAC primary database to a standby, use the following
commands for RMAN backup and restore.

1. Take a hot backup using RMAN as given in the following example:

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

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

$ sqlplus "/as sysdba"

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

Appendix F: Using Data Guard Broker (DGMGRL) to Manage Standby

Databases
The 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.

F1. Prerequisites
F2. Configure Data Guard Broker
F3. Role Transitions

F1. Prerequisites:

Prior to using Data Guard broker, the standby database should be configured.
https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 36/42
3/26/2020 Document 1491855.1

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 seen below:

(SID_DESC =
(GLOBAL_DBNAME=<DB_UNIQUE_NAME>_DGMGRL.example.com)
(ORACLE_HOME= <ORACLE_HOME>)
(SID_NAME = <SID>)
)

Option 2:
Set the StaticConnectIdentifier property of both the primary and standby databases 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 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)))

F2. 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 the 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 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.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 37/42
3/26/2020 Document 1491855.1

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.

F3. Role Transitions

F3.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): dbbrok
Instance(s): dbbrok
Database Status: SUCCESS
Database Status: SUCCESS

2. Issue 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 from 6.1.6 Complete the database configurations.

F3.2 Switchback

Follow the same steps from the above section, but change the database name to switchover.

For example
DGMGRL> switchover to dbbrok; --> where dbbrok is current standby after a switchover.

F3.3 Failover

There are two types of failover using Data Guard broker:

Manual failover
Automatic failover using the fast start failover option (not supported in 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 from 6.2.7 Complete the database configuration.

Automatic Failover

Automatic failover is not supported in Oracle E-Business Suite, as you need to run AutoConfig before
bringing the standby environment online. At this time, this section will be updated when post failover

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 38/42
3/26/2020 Document 1491855.1

configurations are automated.

Appendix G: Creating Non-RAC Standby for RAC Primary

This appendix describes the steps to create a non-RAC standby.

G1. Configure a Primary RAC to Create a Non-RAC Standby

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

G2. Create a Physical Standby

1. Copy the ORACLE_HOME to the Standby database server.

Copy the Oracle Home file system to the standby database server. 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 that contain 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 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. As 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

Enter 'n' as the standby is non-RAC.

Note: Re-link oracle with rac_off option. If adlnkoh.sh fails 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

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.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 39/42
3/26/2020 Document 1491855.1

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 file (pfile).

Put the standby database in 'managed recover' mode.

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

For the applications tier configuration, follow the steps given in Section 4: Creating a Physical Standby
Database starting at step 4.8 Start shipping redo from the primary to the standby database server up
to the end of the section. Next perfom all the steps given in Section 5: Configuration on Application
Tiers After Standby Database is Enabled.

Appendix H: Handling Online Patching Following A Standby Failover Event

Oracle E-Business Suite 12.2 supports online patching. However, if there is a failover event during a patch
cycle, there is no option to resume the patch on the standby. If you want to apply the patches to the
standby, you will first need to run a script to modify the status of the online patching, and then abort the
current patch cycle. Steps are included for both possible standby application tier configurations.

For Configuration 1: The standby Application Tiers are connected to the standby database.

The steps to perform on a failover during patching are as follows:

1. Make sure that you have applied all the patches listed in PreRequisite section.
2. Before running fnd_conc_clone.setup_clean in the next step, run the following query to get the appltop_id
for each of the primary nodes:

SQL>SELECT aat.appl_top_id,node_name
FROM FND_OAM_CONTEXT_FILES focf, AD_APPL_TOPS aat
WHERE aat.name=EXTRACTVALUE(XMLType(focf.TEXT),'//APPL_TOP_NAME')
AND focf.node_name=<Primary Node Name>
AND EXTRACTVALUE(XMLType(TEXT),'//file_edition_type') = 'run';

3. Execute the instructions in step 6.2.7 and also all the steps in Section 6.4.
4. Get the appl_top_id for each of the standby nodes using the query in step 2; substitute the <standby
node name> in place of the <primary node name>.
5. In order to be able to restart a patching cycle, you need to change the node names from the primary to the
standby(current primary). As the APPS user execute the following:

SQL>exec AD_ZD_FIXER.fix_adop_repo_tables(<Primary appltop_id (from Step 2)>,<Primary

Node Name>, <Standby appltop_id (from step 4)>,<Standby Node Name >);

Note: In case of a scale down configuration, there will not be same number of application tier nodes on
primary site and standby site. Use the following command for scale down configuration:

SQL>exec AD_ZD_FIXER.fix_adop_repo_tables(<Primary appltop_id (from Step 2)>,

<Master Node on Primary Site>, <Standby appltop_id (from step 4)>,<Master Node on
Standby Site>);

6. The EBS Technology Codelevel Check needs to be run on the database node. Download and apply Patch
17537119. Execute checkDBpatch.sh on the database node.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 40/42
3/26/2020 Document 1491855.1

Note: If you do not do this, you will be prompted when you run prepare.

7. On the standby, abort online patching that was initiated on the primary site by executing the following
command:

$ ADOP phase=abort

You will then be able to restart the patch cycle.

For Configuration 2: The standby Application Tiers are connected to the primary database.

1. Perform the failover steps detailed in Section 6.2 to configure the application tiers
2. On the standby(New Primary), abort online patching that was initiated on the primary site by executing the
following command:

$ ADOP phase=abort

You will then be able to restart the patch cycle.

Change Log

Date Description

Oct 28, 2019 Updated hostname with generic value throught the document.

Aug 07, 2019 Added setasmgidwrap with role separation in section 4.

June 1, 2018 Updated section 7 to implement MOS comments

Sept 11, 2017 Updated for EBS 12.2.7 and added options in section 3.7

Aug 30, 2017 Added remark with reference to deprecated fal_client parameter

Feb 22, 2017 Clarified step 6 of 6.4.2

Feb 10, 2017 Review and Implemented comments. Revised patch advice.

Jul 15, 2016 Improved clarity in section 7.3.3 and added failover warning note in 6.2

Jun 15, 2016 Corrected Typo in section 7.3.2.1

Implemented comments (Sections 3.9 Step 2 and 5.1.2). Corrections as per Bug 22096908:
May 09, 2016
ADMIN_RESTRICTIONS_dg12s

Feb 12, 2016 Updated applicable version(s) in section 2.2 to include Oracle E-Business Suite 12.2.5

Added new appendices E and G. Updated section 5 and appendices D, F, and H. Added support
Jan 07, 2016
for scale down configuration.

Oct 16, 2015 Updated for Delta 7

Jul 14, 2015 Updated to include an additional standby configuration..

May 29, 2015 Updated RAC Configurations.

Jan 09, 2015 Updated title and env command.

Added file system synchronization and modified Cloning document from Setup Guide to
Jun 12, 2014
Knowledge Support Document 1383621.1.

Jun 03, 2014 Updated post internal review.

Mar 03, 2014 Modified for latest Cloning Steps and removed RAC related steps.

Feb 27, 2014 Modified Cloning document reference to Oracle E-Business Suite 12.2 Setup Guide.

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 41/42
3/26/2020 Document 1491855.1

Feb 18, 2014 Changes to header and navigation. Formatting.

Oct 12, 2012 Initial Draft

My Oracle Support Knowledge Document 1491855.1 by Oracle E-Business Suite Development

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

Didn't find what you are looking for?

Document Attributes
Author: SRMAHEND.IN;VJUTTIGA.IN;PRADESAH.IN;ATREMAYN.UK; Status: PUBLISHED(EXTERNAL)
Owner: PRADESAH.IN Publisher: JFARRING.UK
Alias: Content Type: TEXT/X-HTML
Distribution: EXTERNAL Visibility: EXTERNAL
Created By: SRMAHEND.IN Created: Sep 18, 2012
Modified By: MIBROWN.US Modified: Dec 6, 2019
Reviewed By: JFARRING.UK Reviewed: Mar 26, 2020
Source: AWIZ Exception: Yes
Priority: 3

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=dya4hznrr_324&id=1491855.1 42/42