data guard

Business Continuity for Oracle E-Business Release 12 Using Oracle 11g (11gR1) Physical Standby Database(Doc ID 1545920.1)

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

This document describes how to configure your Oracle E-Business Suite Release 12 environment to use Oracle Database 11gR1 as a physicalstandby.

Note: This document applies to Oracle Database 11.1.0.7 only. For the equivalent information about Oracle Database version 11.2.0.1or above, refer to My Oracle Support Knowledge Document 1070033.1.

The most current version of this document can be obtained in My Oracle Support Knowledge Document 1545920.1, Business Continuity forOracle E-Business Suite Release 12 Using Oracle 11g (11gR1) Physical Standby Database.

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

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

In This Document

This document is divided into the following sections:

Section 1: OverviewSection 2: Before You StartSection 3: Preparing the Primary Database for Standby Database CreationSection 4: Creating a Physical Standby DatabaseSection 5: Configuration on Application Tiers After Standby Database is EnabledSection 6: Role TransitionsSection 7: Oracle E-Business Suite Maintenance With Standby Database

Appendix A: Oracle Net FilesAppendix B: Using Oracle Applications Manager to Register Standby DatabaseAppendix C: Example Standby Database CommandsAppendix D: Using RMAN to Create Physical Standby DatabaseAppendix E: RAC RMAN Cloning ExampleAppendix F: Example Cloning ScriptAppendix G: Creating a Non-RAC Standby for the RAC PrimaryAppendix H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases

A number of conventions are used in this document:

Convention Meaning

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

Database tier Machines running Oracle E-Business Suite database.

Primary system Primary Oracle E-Business Suite system, which will be used to create a standby system.

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

ORACLE User account that owns the database file system (database ORACLE_HOME and files).

CONTEXT_NAME The CONTEXT_NAME variable specifies the name of the applications context that is used by AutoConfig. The defaultis _.

STNDBY_CONTEXT The default is _.

APPSpwd Oracle E-Business Suite database user password.

Monospace text Represents command line text; type such a command exactly as shown, excluding prompts such as '%'.

< > Text enclosed in angle brackets represent a variable. Substitute a value for the variable text. Do not type the anglebrackets.

Document Display https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-stat...

1 of 29 5/28/2015 12:31 AM

\ On UNIX, the backslash character can be entered at the end of a command line to indicate continuation of thecommand on the next line.

Primary databasealias

TNS alias to connect to primary database.

Standby TNS alias TNS alias to connect to standby database.

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

Section 1: Overview

1.1 Standby Database1.2 Oracle Data Guard1.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 cancreate up to 30 standby databases and incorporate them in Oracle Data Guard configuration.

Standby databases can be of three types:

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

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

Snapshot StandbyA fully updatable standby database. Like a physical or logical standby database, a snapshot standby database receives and archivesredo data from a primary database. Although unlike a physical or logical standby database, a snapshot standby database does notapply 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 databasesshould be used with caution as the data will be out of sync with the primary.

1.2 Oracle Data Guard

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

Oracle Data Guard offers three modes of data protection:

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

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


2 of 29 5/28/2015 12:31 AM

standby database is resynchronized with the primary database. If there is a need to failover before the standby database isresynchronized, some data may be lost.

Maximum PerformanceThis mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. Inthis mode, as the primary database processes transactions, redo data is asynchronously shipped to the standby database. Thecommit operation on the primary database does not wait for the standby database to acknowledge receipt of redo data beforecompleting write operations on the primary database. If any standby destination becomes unavailable, processing continues on theprimary 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, andmonitoring of Data Guard configurations.

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

The Data Guard Broker consists of three components:

Data Guard GUI through Enterprise ManagerData Guard command-line interface (DGMGRL)Data Guard Monitor

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

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

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

Role TransitionsSimplifies the switchover and failover process, including automatically setting up redo transport and log apply services, andautomating failover.

Note: Fast-start failover is currently not supported for the Oracle E-Business Suite.

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

Section 2: Before You Start

2.1 Design Considerations2.2 Software Prerequisites

2.1 Design Considerations

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

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

The reader of this document should be familiar with the Oracle 11g database server and have at least a basic knowledge of standbydatabase configurations.

Refer to the following documentation for further information:


3 of 29 5/28/2015 12:31 AM

Oracle Database Administrator's Guide 11g Release 1(11.1), Part No. B28310-04Oracle Data Guard Concepts and Administration 11g Release 1 (11.1), Part No. B28294-03

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

My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications Release 12 with Rapid CloneMy Oracle Support Knowledge Document 559518.1, Cloning Oracle Applications Release 12 RAC-Enabled Systems with Rapid Clone[Oracle RAC environments only]My Oracle Support Knowledge Document 466649.1, Using Oracle 11g Release 1 (11.1.0.7) Real Application Clusters and AutomaticStorage Management with Oracle E-Business Suite Release 12 [Oracle RAC environments only]

2.2 Software Prerequisites

This document assumes the following minimum software versions:

SoftwareComponent

MinimumVersion Additional Information

OracleE-BusinessSuite

12.0.4 or12.1.1

This document was developed using a fresh install database from an Oracle E-Business Suite Release12.1.1 Rapid Install with the prerequisite patches listed in My Oracle Support Knowledge Document406982.1, Cloning Oracle Applications Release 12 with Rapid Clone applied. For Oracle RAC enabledsystems, additional pre-requisite patches listed in My Oracle Support Knowledge Document 559518.1,Cloning Oracle E-Business Suite Release 12 RAC-Enabled Systems with Rapid Clone were applied.

OracleDatabase11gR1

11.1.0.7

Database upgraded by following My Oracle Support Knowledge Document 735276.1, Interoperability NotesE-Business Suite 12.0 with Oracle Database 11gR1 (11.1.0).

For Oracle RAC Configurations: Databases configured for Oracle RAC configurations should refer to MyOracle Support Knowledge Document 466649.1, Using Oracle 11g Release 1 Real Application Clusters andAutomatic Storage Management with Oracle E-Business Suite Release 12.

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

This document refers to the following top-level directories:

Directory Purpose

RDBMS_ORACLE_HOME Oracle 11g R1/R2 Database ORACLE_HOME

APPL_TOP Directory that contains the application product directories and files

COMMON_TOP Directory that contains directories and files used across application products

OracleAS 10.1.2 ORACLE_HOME ORACLE_HOME installed by Oracle E-Business Suite on application tier

INST_TOP Directory that contains application instance directories and files

Note: If you want to ensure you have applied all the required application and database patches for cloning, refer to My Oracle SupportKnowledge Document 406982.1, Cloning Oracle Applications Release 12 with Rapid Clone for the latest patch information.

Section 3: Preparing the Primary Database for Standby Database Creation

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

3.1 Enable Forced Logging3.2 Configure Oracle Net Communication To and From Standby3.3 Set Up Secure Connections


4 of 29 5/28/2015 12:31 AM

3.4 Set Primary Database Initialization Parameters3.5 Enable Archive Logging on Primary System3.6 Add Standby Redo Logs3.7 Invite Communications From the Standby3.8 Gather Temporary File Information3.9 Run the Application Tier and Database Pre-clones3.10 Copy APPL_TOP and Oracle E-Business Suite Technology Stacks to Application Tiers and Standby Environment

3.1 Enable Forced Logging

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

Place the primary database in FORCE LOGGING mode by using the following SQL statement:

SQL> ALTER DATABASE FORCE LOGGING;

Note: This statement may take a considerable amount of time to complete as it must wait for all unlogged direct write I/O operations tofinish.

3.2 Configure Oracle Net Communication To and From Standby System

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

Standby Listener

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

TNS Aliases

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

Note for Oracle RAC Configurations: The TNS alias requirements are different. See A1 in Appendix A: Oracle Net Files for anexample.

3.3 Set Up Secure Connections

Oracle Data Guard uses Oracle Net sessions to transport redo data and control messages between the members of an Oracle Data Guardconfiguration. These redo transport sessions are authenticated using either the Secure Sockets Layer (SSL) protocol or a remote loginpassword file.

Note for Oracle RAC Configurations: Create password files for all instances.

This document uses a password file - see My Oracle Support Knowledge Document 376700.1, Enabling SSL in Oracle E-Business SuiteRelease 12 for database SSL setup.

$ cd /dbs$ orapwd file=orapw password= entries= ignorecase=y

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

3.4 Set Primary Database Initialization Parameters


5 of 29 5/28/2015 12:31 AM

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

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

Define an archive log destination directory on the file system. Then, add these parameters to your database init.ora file via the ifile foundat /dbs/_ifile.ora.

Primary database: primary role initialization parameters

The table below lists the parameters relating to archive destinations and transmission of redo data to the standby system:

Parameter Description

log_archive_dest_1 Archives redo data generated on primary database to the local file system.

log_archive_dest_2

Transmits redo data to the remote physical standby destination.

Options used:

SERVICE: Standby Service Name - this is the DB_UNIQUE_NAME

LGWR:Redo Log information can be transmitted in one of two ways from primary tophysical standby either LGWR or ARCH process. LGWR is used in thisdocument.

ASYNC:Specifies that network I/O is to be performed asynchronously for thedestination. You can optionally specify a block count (from 0 to 102,400) thatdetermines the size of the SGA network buffer to be used.

REOPEN: The minimum number of seconds before the log writer process (LGWR)should try again to access a previously failed destination.

MAX_FAILURE: The maximum number of reopen attempts before the primary databasepermanently gives up on the standby database.

NET_TIMEOUT:Specifies the number of seconds the log writer process on the primary systemwaits for status from the network server (LNS n) process before terminatingthe network connection.

log_archive_dest_state_2When set to ENABLE, allows redo transport services to transmit redo data to the specifieddestination. Set this value to ENABLE on primary site to send archive log files automatically tostandby.

log_archive_format Used to specify the file name format when archiving redo log files. Will use system defaults if notset.

log_archive_min_succeed_dest Defines the minimum number of destinations that must succeed in order for the online log file to beavailable for reuse.

log_archive_configEnables or disables the sending of redo logs to remote destinations and the receipt of remote redologs, and specifies the unique database names (DB_UNIQUE_NAME) for each database in the DataGuard configuration.

DB_UNIQUE_NAME Unique Name to identify the primary and standby (For example 'dg12' for primary and 'dg12s' forphysical standby).

fal_server

Specifies the TNS network service name that the standby database should use to connect to theFAL server process. FAL Server is Fetch Archive Log (FAL) Server which services requests forarchive redo logs from FAL clients running on multiple standby databases. Set this parameter toprimary database service name dg12 (for example) to request missing archived redo log files ifprimary is unable to send the missing log files automatically.

fal_client Specifies the TNS network service name that the primary database should use to connect to thestandby.


6 of 29 5/28/2015 12:31 AM

standby_file_management Set to AUTO. Whenever data files are added or dropped from primary database, correspondingchanges will be made automatically to the standby.

db_file_name_convert,log_file_name_convert

Specify the path name and file name location of data files and redo log files. db_file_name_convertparameter need not be set when the directory structures are same on primary and standby. Butlog_file_name_convert should set to dummy values if you are using same directory structure toenable redo log clearing.

Remote_login_passwordfile This parameter checks specifies whether Oracle checks for a password file. Since we are usingpassword authentication this parameter should set.

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

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

Primary Database Physical Standby Oracle RAC Primary Oracle RAC Standby

Oracle Net Service name dg12 dg12s prod stdby

SID dg12 dg12 prod1 and prod2 stdby1 and stdby2

DB_UNIQUE_NAME dg12 dg12s prod stdby

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

The following example shows the relevant initialization parameters of the primary database.

db_unique_name = dg12 ---- You need to change this to dg12s (Standby db_unique_name, for example) when you copy this file tophysical standbylog_archive_dest_1 = LOCATION=/arch1/dg12/ MANDATORYlog_archive_dest_2 = SERVICE=dg12s LGWR ASYNC=20480 DB_UNIQUE_NAME=dg12s OPTIONAL REOPEN=15 MAX_FAILURE=10 NET_TIMEOUT=30log_archive_config='dg_config=(dg12,dg12s)'# log_archive_dest_state_2 = defer# log_archive_dest_state_2 = enablelog_archive_min_succeed_dest = 1standby_file_management = AUTORemote_login_passwordfile = exclusivelog_archive_format = %s_%t_%r. # Or can just leave as default.

# db_file_name_convert: do not need; same directory structure# log_file_name_convert: do not need; same directory structurefal_server = dg12fal_client = dg12slog_file_name_convert = xx,xx # Specify dummy values to trigger log clearing

Note for Oracle RAC Configurations: Configure __ifile.ora on all nodes in the primary Oracle RAC system. Toprevent overwriting of archive logs of different nodes on a shared file system, a specific format must be used for naming the archivelogs of each node. The following configuration assumes that prod and stdby are the service names/DB_UNIQUE_NAMES on the primaryand standby respectively.

db_unique_name=prodlog_archive_dest_1='LOCATION=/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 = enablelog_archive_dest_state_2 = enablefal_server=prodfal_client=stdbylog_archive_format=prod1_%s_%t_%r.logdb_file_name_convert='',''log_file_name_convert='',''standby_file_management=auto

3.5 Enable Archive Logging on Primary System


7 of 29 5/28/2015 12:31 AM

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

3.6 Add Standby Redo Logs

Standby redo logs are required to use real-time apply. As the remote file server (RFS) process writes the redo data to standby redo log fileson the standby database, apply services can recover redo from standby redo log files as they are being filled.

Best practice is to add them in both the primary and the standby database so switchovers between the environments are quicker and easier.Here, you will add them in production so they are in place when you clone the database for the standby.

Standby redo logs are additional redo log groups with a different type. You can only have as many redo log groups overall as the maximumsetting for your database for log file groups and log file members.

Standby redo log groups should be multiplexed in the same manner as online redo log groups.

To create standby redo log groups, as the ORACLE user on the primary database server, connect to SQL*Plus as sysdba and issue acommand like this for each standby redo log group you will create:

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

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

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

3.7 Invite Communications From the Standby

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

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

3.8 Gather Temporary File Information

You will need to manually recreate your temporary files on the standby database. Gather the required data now from the primary databasewith the following SQL*Plus query:

SQL>select file_name, bytes from dba_temp_files;

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

3.9 Run the Application Tier and Database Tier for Pre-clone Scripts

As the ORACLE user, run the database pre-clone utility on the primary database server.

Note for Oracle RAC Configurations: Run pre-clone scripts on all database nodes and application tier nodes.

$ cd $RDBMS_ORACLE_HOME/appsutil/scripts/$ perl adpreclone.pl dbTier

Supply the APPS password when requested.

1.

As the APPLMGR user, run the application tier pre-clone utility on each primary application tiers that has an APPL_TOP (or only onone, if it is shared by all):

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

2.

OPTIONAL: Shut down all application tier services to copy the APPL_TOP. If your operating system returns errors when copying openfiles, you may need to shut down application tier services to successfully copy the APPL_TOP and Oracle E-Business Suite technologystack software.

3.


8 of 29 5/28/2015 12:31 AM

$ cd INST_TOP/admin/scripts/$ adstpall.sh apps/

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

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

Section 4: Creating a Physical Standby Database

4.1 Copy the ORACLE_HOME and Database to the Standby Database Server4.2 Generate a Standby Control File, Copy to Standby Database Server (optional)4.3 Perform file-based Configurations on Standby Database Server4.4 Stop the Database Listener on the Standby Database Server4.5 Configure Oracle Net for Redo Transmission, Start the Listener4.6 Modify the Database init.ora Parameters on the Standby Server4.7 Mount the Physical Standby, Start Processing Redo on the Standby4.8 Start Shipping Redo From the Primary to the Standby Database Server4.9 Verify Redo is Shipping4.10 Add Your Temp Files to the Standby Database4.11 Configure Data Guard Broker (optional)

4.1 Copy the ORACLE_HOME and Database to the Standby Database Server

Copy the Oracle Home file system to the standby database server. If you natively compile your PL/SQL, be sure you include the file systemdirectories holding the compiled objects. The standard location for this is /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 siteManual Hot Backup - With the files open, put the tablespace in the backup mode, and copy the data files to the standby site.RMAN - Use the 'duplicate database' command. See Appendix D: Using RMAN to Create Physical Standby Database and for RACAppendix E: RAC RMAN Cloning Example for examples of usage.

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

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

Note: This is an optional step. If you used RMAN to copy the database, skip this step.

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

You will need to recover past the time the control file is created, so switch logs and note the new log number.

SQL>alter database create standby controlfile as /;SQL>alter system switch logfile;SQL>select thread#, sequence#-1 from v$log where status = CURRENT;

Copy the control file to the standby database server.

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

4.3 Perform File-based Configurations on the Standby Database Server

After the database software copies are complete (which can be done before the database itself is finished copying), log into the standbydatabase server as the ORACLE user and execute the following commands to update the file system configurations for the new environment.Since your environment scripts are not yet set up, you will need to manually resolve the reference to .

$ cd /appsutil/clone/bin


9 of 29 5/28/2015 12:31 AM

$ 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 scriptto correct them.

Note for Oracle RAC Configurations: In addition, perform the following steps.

Run adclonectx and adclone on all nodes.1. Answer the questions when prompted: Enter 'Y" when prompted Current node is the first node in an N Node RAC Cluster(y/n)[n]:y on every node, otherwise it will prompt for "Live RAC node", which will not be available at this time: refer to Appendix F:Example Cloning Script.

2.

Modify the init parameter files to point the correct diagnostic destination and utl_file_dir with standby context directory.3. Run the following commands (shown split over a number of lines for readability).4.

$ perl /appsutil/clone/bin/adclonectx.pl \ contextfile=/appsutil/_.xml \ template=$Standby_ORACLE_HOME/appsutil/template/adxdbctx.tmp \ pairsfile=/appsutil/clone/pairsfile.txt

$ perl adclone.pl java /appsutil/clone/jre \component=dbTechStack \mode=apply \stage=/appsutil/clone \method=custom \dbctxtg=/appsutil/_.xml \rmanstage= \rmantgtloc= \srcdbname= \pwd=

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

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

4.4 Stop the Database Listener on the Standby Database Server

The above step starts the database listener. It is not yet completely configured, so should be stopped. As the ORACLE user on the standbydatabase server, enter the following command:

$ lsnrctl stop

4.5 Configure Oracle Net for Redo Transmission, Start the Listener

Note for Oracle RAC Configurations: Perform these steps on all nodes.

As the ORACLE user, copy the listener_ifile.ora and _ifile.ora from the primary server's directory to the standby server's directory. As part of the copy, rename the primary _ifile.ora to thestandby's _ifile.ora matching the spelling and case in the file name in the last line of the standby server'stns_names.ora file.

1.

In the _ifile.ora, be sure the entry for the standby service's HOST parameter holds the standby database hostname and the FAL service's host name is the primary host name.

2.

In the listener_ifile.ora file, ensure that the HOST for the standby service entry points to the standby database host.3. As the ORACLE user, start the database listener for the standby:

$ lsnrctl start

4.

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

As the ORACLE user on the standby database server, create an ifile for the standby database from the one you created earlier for the primary


10 of 29 5/28/2015 12:31 AM

database:

$ cd /dbs$ cp _ifile.ora _ifile.ora

Update the following parameters:

DB_UNIQUE_NAME to a name different from primary: for example dg12sLOG_ARCHIVE_DEST_2 to point to the standby service. This is required when standby is switched to primary and ships redo to newstandby

e.g. LOG_ARCHIVE_DEST_2 for 'service=dg12s ASYNC REGISTER VALID_FOR=(online_logfile,primary_role)DB_UNIQUE_NAME=dg12'

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

diagnostic_dest to /admin/ utl_file_dir for context specific directories

Finally, add an entry for the standby control file you created on the primary and copied to this server:

control_files = (/, /)

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

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

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

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

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

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

SQL>startup nomount pfile= /dbs/init .ora | spfileSQL>alter database mount standby database;

1.

Put the standby database in 'managed recover' mode

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

2.

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

As the ORACLE user on the primary database server, set log_archive_dest_state_2 to enable in the database initialization file.

# log_archive_dest_state_2 = defer# log_archive_dest_state_2 = enable

4.9 Verify Redo is Shipping

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

SQL>alter system switch logfile;

Still on the primary, check for the status of the archive destinations to determine the most recently archived redo log file at each redotransport destination. The most recently archived redo log file should be the same for each destination. If it is not, a status other than VALIDmay identify and error encountered during the archival operation to that destination:

SQL>select * from v$archive_dest_status where status != 'INACTIVE';

On each database server, this query will show which logs have been sent/received and applied:


11 of 29 5/28/2015 12:31 AM

SQL>select sequence#, applied, to_char(first_time, 'mm/dd/yy hh24:mi:ss') first from v$archived_log order by first_time;

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

4.10 Add Your Temp Files to the Standby Database

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

To save time on failover, add your temp files to the standby database now. You collected the temporary file names and sized in 3.8 GatherTemporary 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 hasprogressed past the time the control file was created - the log sequence number was noted in 4.2 Generate a Standby Control File and Copyit 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 '' 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 Oracle Data Guard Broker to manager an Oracle E-Business Suite standby database, follow sections H1 and H2 ofAppendix H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases.

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

Perform file-based configurations on standby application tiers:

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

Note: If the directory structure on standby is different than the primary, then you need to run perl adcfgclone.platTechStack instead of adclonectx.

$ cd /clone/bin$ perl adclonectx.pl /appl/admin/.xml

Note: Ignore database connection failures while running the above command.

Refer to My Oracle Support Knowledge Document 406982.1 Cloning Oracle Applications Release 12 with Rapid Clone for details.

1.

When the script has finished and the context file is created, execute the following commands, again resolving he reference to manually:

Note: If the application tier is configured as a concurrent server only, then modify the context variable to YES. Afterexecuting the commands below, change it back to NO. For further information, refer to Bug 14253714.

$ cd APPL_TOP/ad/12.0.0/bin$ perl adconfig.pl contextfile=$INST_TOP/appl/admin/.xml run=INSTE8

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

2.


12 of 29 5/28/2015 12:31 AM

Optionally, set up rsync for log and out files.

If you wish to synchronize your concurrent manager log and out files from the primary to the standby, create directories that correspond tothe APPLCSF environment variables on the standby application tier server(s).

For example:

$ mkdir -p /log$ mkdir -p /out

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

For UNIX systems, on the primary application tier(s), set up an rsync job in cron, to run every few minutes. The following examplesynchronizes the log directory:

$ rsync av /log : /log --rsync-path=/usr/local/bin/rsync

Section 6: Role Transitions

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

Switchover - Allows the primary database to switch roles with one of its standby databases. There is no data loss during aswitchover. 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 Switchover6.2 Performing a Failover6.3 Performing a Switchback to Primary After Switchover/Failover

For all three transitions, applications configuration is required. As most application configuration steps are common to all transition types, itis discussed in the final part of this section:

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

6.1 Performing a Switchover

Note: If you are using Oracle Data Guard Broker to manage the standby database, follow section H3 in Appendix H: Using Data GuardBroker [DGMGRL] to Manage Standby Databases, then proceed to 6.1.6 Complete the database configurations.

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

Sections 3, 4, and 5 define how to set up your environments so there will be minimal parameter changing when switching. This sectionassumes you have configured your parameter files as described in these sections.

6.1.1 Preparing for switchover to standby server

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

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

Ensure that the last redo data transmitted from the primary database was applied on the standby database. Issue the following SQLcommand on the primary and standby databases to find out. If necessary, perform a logfile switch before the first command

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

3.

Check whether the primary is ready for switch. Query the switchover_status column of the v$database fixed view to determinewhether the database is ready to switch modes.

4.


13 of 29 5/28/2015 12:31 AM

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 switchcommand should be used with the 'session shutdown' option.

6.1.2 Initiate the switchover on the primary database

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

Connect as sysdba and issue the following SQL command:

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

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

Change the value of LOG_ARCHIVE_DEST_STATE_2 to defer on primary.

6.1.3 Shut down and mount the primary database

To complete the transition, the database must be shut down and restarted in a mounted state. In addition, recovery can be started inpreparation for transition.

SQL>shutdown immediateSQL>startup nomount pfile=$ORACLE_HOME/dbs/init.ora | spfileSQL>alter database mount standby database;SQL>alter database recover managed standby database disconnect from session;

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

6.1.4 Verify the switchover status on the standby server

As the ORACLE user on the standby-to-be-primary database server, verify it is ready to switch to primary:

SQL>select switchover_status from v$database;

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

6.1.5 Switch the selected standby database to the primary role

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

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

SQL>alter database commit to switchover to primary with session shutdown;

Adjust the network parameters on both database servers

As the ORACLE user on both the primary and standby database servers in the _ifile.ora and_ifile.ora files in the directories, change the host name in the standby service definitions to point to thenew standby server.

Change the LOG_ARCHIVE_DEST_STATE_2 to enable.

To complete the transition, the database must be shut down and re-started:

SQL>shutdown immediateSQL>startup pfile=$ORACLE_HOME/dbs/init.ora | spfile


14 of 29 5/28/2015 12:31 AM

6.1.6 Complete the database configurations

Connect to the new primary database using SQL*Plus as user APPS, and execute the following commands:

SQL>exec fnd_net_services.remove_system '');SQL>commit;SQL>exec fnd_conc_clone.setup_clean ;

1.

As the ORACLE user on the new primary database server, use AutoConfig to complete configuration for primary operations, providingthe APPS password when prompted:

$ cd /appsutil/scripts/$ ./adautocfg.sh

2.

When this completes, stop and start the listener on the new primary database server:

$ lsnrctl stop$ lsnrctl start

3.

On the new standby server, stop and start the listener for standby services:

$ lsnrctl$ lsnrctl start

4.

For application-specific configurations, follow the steps in 6.4 Configurating Application Tiers After Role Transition (switchover,failover, switchback).

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

5.

6.2 Performing a Failover

Note: If you are using Oracle Data Guard Broker to manage standby databases, follow the steps under "Manual Failover" in section H3of Appendix H: Using Data Guard Broker [DGMGRL] to Manage Standby Databases, then go to 6.2.6 Complete the databaseconfiguration.

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

Sections 3, 4 and 5 define how to set up your environments so there will be minimal parameter changing during failover. This sectionassumes you have configured your parameter files as described in these sections.

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

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

Query the V$ARCHIVED_LOG view on the target standby database to obtain the highest log sequence number for each redo thread:

SQL>SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

6.2.2 Identify and resolve any archives redo log gaps

On the standby database server, connect as sysdba to the standby database. Query v$archive_gap to determine whether there are missingarchive logs:

SQL>select * from v$archive_gap;

If this query returns a row, it indicates at least one archived redo log is missing from the standby. If you still have access to your primarydatabase, you can determine the full name of the redo logs by querying v$archived_log, using the low_sequence# and high_sequence#returned above:

SQL>select name from v$archived_log


15 of 29 5/28/2015 12:31 AM

where thread# = and sequence# between and ;

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

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

6.2.3 Adjust standby archive destination status

On the standby database server, change the initialization parameter for the destination state of the archive logs to be shipped from primaryto standby from 'defer' to 'enable'. Make the changes in /dbs/ _ifile.ora, commenting out the'defer' line.

# log_archive_dest_state_2 = enable# log_archive_dest_state_2 = defer

6.2.4 Stop redo apply and finish applying all received redo data

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

When all available logs are present and registered on the standby, stop redo apply:

SQL>alter database recover managed standby database cancel;

Finish the recovery session:

SQL>alter database recover managed standby database finish;

When that completes, convert the physical standby to a primary database role:

SQL>alter database commit to switchover to primary;SQL>shutdown immediate;SQL>startup pfile=?/dbs/init.ora

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

6.2.5 Update TNS parameters for new standby database location

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

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

6.2.6 Complete the database configuration

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('');SQL>commit;SQL>exec fnd_conc_clone.setup_clean;

1.

As the ORACLE user on the new primary database server, use AutoConfig to complete configuration for primary operations, providingthe APPS password when prompted:

$ cd /appsutil/scripts/$ ./adautocfg.sh

2.

When this completes, stop and start the listener on the new primary database server:3.


16 of 29 5/28/2015 12:31 AM

SQL>lsnrctl stopSQL>lsnrctl start

To complete application-specific configurations, follow the steps in 6.4 Application Tier Configuration After a Role Transition(switchover/failover/switchback).

Note for Oracle RAC Configurations: Repeat above steps 2 and 3 for each instance.

6.3 Performing Switchback to Primary After Switchover/Failover

6.3.1 Switchback to primary site after a switchover

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

Standby Site Primary Site

Primary Database Standby Database

Steps to perform the switchback to primary site:

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

SQL>alter database commit to switchover to physical standby

4.

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

SQL>alter database commit to switchover to physical primary

8.

Shut down and start up the database at the primary site.9. Verify the redo log shipping. Refer to 6.1 Performing a Switchover for the commands.10. For application-specific configurations, follow the steps in 6.4 Application Tier Configuration After a Role Transition(switchover/failover/switchback).

11.

6.3.2 Recreating the original primary database after failover

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

Make a consistent backup of activated standby database at standby site.1. Restore the backup created at standby site to primary database.2. Run AutoConfig on both the database tier and application tier.3. Shut down and start up the database.4. On the original primary site, create or modify the initialization parameter file with the appropriate values.5. Create a new standby database at the original standby site. Follow instructions in Sections 3, 4 and 5.6. For application-specific configurations, follow the steps in 6.4 Application Tier Configuration After a Role Transition(switchover/failover/switchback).

7.

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

6.4.1 Finish Oracle E-Business Suite configuration on application tiers

After the primary database configuration is complete and its listeners have started, log in to each now-primary application tier server as theAPPLMGR user, and run the final configuration steps:

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


17 of 29 5/28/2015 12:31 AM

Provide the APPS password when prompted.

6.4.2 Update host name in fnd_concurrent_requests and fnd_conc_req_outputs tables

If you synchronize your concurrent manager log and out directories, you must change the host name in the fnd_concurrent_requests tableto the name of the new primary server (that was the standby before the role transition):

SQL>update apps.fnd_concurrent_requestsset logfile_node_name = ,outfile_node_name = where logfile_node_name = and outfile_node_name = ;

SQL>update apps.fnd_conc_req_outputs set file_node_name=where file_node_name=;

If you do not synchronize your concurrent manager log and out directories, blank out the host name in the fnd_concurrent_requeststable to avoid network timeout errors:

SQL>update apps.fnd_concurrent_requestsset logfile_node_name = null,outfile_node_name = null;

SQL>update apps.fnd_conc_req_outputs set file_node_name=' ';

If you run the latter update, you must execute it before starting the concurrent managers on the system. If you do not execute it beforestarting the managers, you must add a where clause to limit the rows updated to those pointing to the old host names. This does not needto 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 toaccess a report's log or out file that was generated on the old primary system.

6.4.3 Perform the cloning finishing tasks

Perform the Finishing Tasks outlined in My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications Release R12 withRapid Clone.

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

6.4.4 Direct users to the new system

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

6.4.5 Establish a new standby system

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

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

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

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

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

Applying an application patch when standby is configured requires:

Syncing of standby with the primary after applying the patch. There are two choices:Syncing File system using rsync, and redo log apply for the database.Recreate the standby completely. When the patch is a major upgrade of the application this is the recommended approach.

Protecting the primary as well as standby from any problems during patch application:If your standby database is running during patch application, the database changes on primary will be automatically pushed tothe standby. If you do not want these changes pushed to standby until after patching is complete, you should shut down


18 of 29 5/28/2015 12:31 AM

standby recovery before applying patches. This document uses the approach of stopping recovery.If you have enough disk space, backup both the databases and Oracle E-Business Suite file system before patching.

These steps are broken into three major sections:

7.1 Prepare to Apply Application Patch7.2 Patch the Primary7.3 After Applying the Patch

7.1 Prepare to Apply Application Patch

7.1.1 On the standby: stop recovery delay if it is set

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

SQL>alter database recover managed standby database nodelay;

7.1.2 Shut down the application tier services on the primary

As the APPLMGR user, shut down all application tier services and stop the listeners on all application tier servers:

$ cd $INST_TOP/admin/scripts$ adstpall.sh apps/

7.1.3 Switch redo logs in the primary database

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

Note for Oracle RAC Configurations: Perform switching on each instance.

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

7.1.4 Ensure that the last log is applied on the standby

On the standby database server, connect as sysdba and monitor the system to see that this last log has been shipped and applied there, tobring the standby to the point in time services were stopped on the primary:

SQL>select sequence#, appliedto_char(first_time, 'mm/dd/yy hh24:mi:ss') firstfrom v$archived_logorder by first_time;

7.1.5 Stop recovery on the standby

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

On the standby database server, stop recovery after the last redo log is applied, and before applying the patch: if there are issues inapplying the patch, the primary system can be restored from standby.

SQL>alter database recover managed standby database cancel;

7.2 Patch the Primary

Check that the patch applied successfully.

7.3 After Applying the Patch

Perform the following steps after successful patch application.


19 of 29 5/28/2015 12:31 AM

7.3.1 Restart redo data shipping and apply on standby

If the patch applied successfully, restart recovery on the standby database server. Connect to SQL*Plus as sysdba, and run the command:


7.3.2 Run the application tier and database pre-clones

As the APPLMGR user, run the application tier pre-clone utility on each primary application tier that has an APPL_TOP (or only on one, if it isshared by all):

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

If the patch required updating the database ORACLE_HOME with a new set of Apps utilities (appsutil.zip), you should also reconfigure thedatabase server. As the ORACLE user, run the database pre-clone utility on the primary database server:

$ cd /appsutil/scripts/$ perl adpreclone.pl dbTier

Supply the APPS password when requested.

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

7.3.3 Synchronize the appropriate file systems

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

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

7.3.4 Start Application Tier Services on Primary

As the APPLMGR user, start all application tier services:

$ cd $INST_TOP/admin/scripts$ adstrtall.sh apps/

7.3.5 Reconfigure the standby application tier file systems

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

Note: If the directory structure on the standby is different to the primary then you need to run "perl adcfgclone.pl atTechStack.xml"

Refer to My Oracle Support Knowledge Document 406982.1, Cloning Applications Release 12 with Rapid Clone, for further details.

When the script is finished and the context file is created, run the following commands (the perl command is entered on one line):

$ cd $APPL_TOP/ad/12.0.0/bin$ perl adconfig.pl contextfile= /appl/admin/.xml run=INSTE8

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

7.3.6 Reconfigure the standby database file systems (optional)


20 of 29 5/28/2015 12:31 AM

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

If you had to synchronize the apps utilities on the database server in the previous step, you should also reconfigure the database server. Asthe ORACLE user on the standby database server, first stop the listener if it is running, then use the cloning toolkit to define the database tiertopology at the standby site:

$ lsnrctl stop $ cd /appsutil/clone/bin$ perl adcfgclone.pl dbTechStack

Answer the questions when prompted.

The above step starts the database listener for primary services. You need to stop and re-start it for standby services:

$ lsnrctl stop $ lsnrctl start

Appendix A: Oracle Net Files

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

Primary Physical Standby

Oracle Net Service Name dg12 dg12s

SID dg12 dg12

A sample /_ifile.ora file, used to support fal_client/server communication.

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

## The Oracle Data Guard physical standby of primary runs on .#Oracle Data Guard uses the tcp protocol only.## This entry must point to the current standby server - i.e. this is the# fal_client alias used to communicate from primary to standby.# MUST BE CHANGED on switchover:dg12s=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST= < standby DB host name >)(PORT=

(ORACLE_HOME= )(SID_NAME=dg12)))

STARTUP_WAIT_TIME_dg12s = 0CONNECT_TIMEOUT_dg12s = 10 TRACE_LEVEL_dg12s = OFF

LOG_DIRECTORY_dg12s = LOG_FILE_dg12s = STDBYTRACE_DIRECTORY_dg12s = TRACE_FILE_dg12s = STDBYADMIN RESTRICTIONS_dg12s = OFF

Appendix A1: TNS Alias Requirements in Oracle RAC Configuration

For Oracle RAC configurations, the entries for the TNS aliases should be as follows, where prod and stdby are the primary and standbyservice names respectively. The entries must be the same on all nodes in the cluster, and also in the standby instances.

prod=(DESCRIPTION=(LOAD_BALANCE=NO)(FAILOVER=YES)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1529))(ADDRESS=(PROTOCOL=tcp)(HOST= System Configuration > Hosts > Register (button under Other Hosts)

1.

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

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

2.

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

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

Appendix C: Example Standby Database Commands

Example for standby redo log files:

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


22 of 29 5/28/2015 12:31 AM

Gathering temporary tablespace information to creating temporary tablespace on standby:

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

Appendix D: Using RMAN to Create Physical Standby Database

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

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

SQL>create pfile from spfile

1.

Copy init .ora from primary to the standby.2.

Change DB_UNIQUE_NAME to standby DB_UNIQUE_NAME - this should be different from the primary.

For example, DB_UNIQUE_NAME=dg12s

3.

For log_archive_dest_2, specify primary DB_UNIQUE_NAME.

For example, log_archive_dest_2='SERVICE=dg12s LGWR ASYNC DB_UNIQUE_NAME=dg12DB_UNIQUE_NAME should specify to ship redo logs from standby site to primary site after switchover

4.

Connect as sysdba and issue the following command to start up but not mount the standby:

SQL>startup nomount pfile=

5.

Connect to target and auxiliary databases using RMAN:

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

6.

Execute the RMAN DUPLICATE command on standby:

RMAN >DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASEDORECOVERSPFILE SET "db_unique_name"="dg12s"SET LOG_ARCHIVE_DEST_2="service=dg12s ASYNC REGISTER VALID_FOR=(online_logfile,primary_role)DB_UNIQUE_NAME=dg12"SET FAL_SERVER="dg12" COMMENT "Is primary"SET DIAGNOSTIC_DEST=$ORACLE_HOME/admin/ COMMENT "DIAGNOSTIC Destination on standby server"SET UTL_FILE_DIR= NOFILENAMECHECK;

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

7.

Appendix E: RAC RMAN Cloning Example

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

Take a hot backup using RMAN:

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

1.

Restore the and create standby database using RMAN:

On the standby system first node, start up the database in nomount mode (using a pfile) and run the following command

2.


23 of 29 5/28/2015 12:31 AM

-bash-3.00$ rman target sys/manager@prod auxiliary /Recovery Manager: Release 11.1.0.7.0 - Production on Thu Mar 11 02:17:43 2010Copyright (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;

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

Appendix F: Example Cloning Script

This example shows how to use the adclonectx.pl and adclone.pl scripts in cloning an Oracle RAC primary database to a standby.

#perl $Standby_ORACLE_HOME/appsutil/clone/bin/adclonectx.pl contextfile=/appsutil/_.xml template=$ORACLE_HOME/appsutil/template/adxdbctx.tmp pairsfile=/appsutil/clone/pairsfile.txtProvide the values required for creation of the new Database Context file.

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

Target hostname [sales_west_001]:

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

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

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

Target System database name [prod]:stdby

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

Enter the port pool number [0-99]:

8 Database port is 1529

Provide information for the Node 1 (current node):

Host name [sales_west_001]:

Instance number [1]:

Private interconnect name [sales_west_001]:sales_west_001-rac

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

Target system cluster manager service port [9998]:

Oracle OS User [oracle]:

Oracle OS Group [oinstall]:

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

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

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

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

Perl executable location is set to:

/usr/bin/perl

New context path and file name [/oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/appsutil/stdby1_sales_west_001.xml]:Creating the new Database Context file from :

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

The new database context file has been created :

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

#perl adclone.pl java=/appsutil/clone/jre component=dbTechStack mode=apply stage=/appsutil/clone/ method=custom dbctxtg=/appsutil/stdby1_sales_west_001.xml


24 of 29 5/28/2015 12:31 AM

rmanstage=/oradata/MAABCU/RAC12STDBY/backupsets/ rmantgtloc=/oradata/MAABCU/RAC12STDBY/db/apps_st/data/ srcdbname=prodpwd=apps Beginning rdbms home Apply - Fri Mar 12 00:46:03 2010-e/appsutil/stdby1_sales_west_001.xml-stage/appsutil/clone/-rmanstage/oradata/MAABCU/RAC12STDBY/backupsets/-rmantgtloc/oradata/MAABCU/RAC12STDBY/db/apps_st/data/-srcdbnameprodAPPS Password : appsLog file located at /appsutil/log/stdby1_sales_west_001/ApplyDBTechStack_03120046.logCompleted Apply...Fri Mar 12 01:27:09 2010

Beginning APPSDB_stdby1 registration to central inventory...

ORACLE_HOME NAME : APPSDB_stdby1ORACLE_HOME PATH : /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0Using Inventory location in /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/oraInst.locLog file located at /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/oraInventory/logs/OracleHomeCloner_03120127.logORACLE_HOME /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0 was registered successfully.

Appendix G: Creating a Non-RAC Standby for the RAC Primary

Configure primary RAC to create non-RAC StandbyFollow the instructions given in Section 3: Preparing the Primary Database for Standby Database Creation to configure primary RAC.

1.

Create Physical StandbyCopy ORACLE_HOME to Standby database server.

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

1.

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 ofAppendix E: RAC RMAN Cloning Example for complete RMAN instructions.

2.

Perform the file base configuration on the Standby Database Server.

After the database software copies are complete (which can be done before the database itself is finished copying), log intothe standby database server as the ORACLE user and execute the following commands to update the file system configurationsfor the new environment. Since your environment scripts are not yet set up, you will need to manually resolve the reference to.

$ cd /appsutil/clone/bin$ perl adcfgclone.pl dbTechStack

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

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

You need to enter 'n' as standby is non-RAC.

Note: If adlnkoh.sh fails, re-link Oracle using the rac_off option, and then run adcfgclone again.

Your ORACLE user environment scripts are now ready to use. Source them for the next steps, using the appropriate OScommand.

For example, in sh or ksh on UNIX:

$ cd $ ./ .env

3.

2.


25 of 29 5/28/2015 12:31 AM

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

Modify the initialization parameter, as per 4.6 Modify the Database init.ora Parameters on the Standby Server.

Stop the standby listener and configure for net redo transmission.

Stop the listener and modify the _ifile.ora to configure net redo transmission. Refer to Section 4 Creating aPhysical Standby Database.

4.

Startup instance in nomount.

sqlplus / as sysdbastartup nomount

5.

Create the standby database using RMAN.

rman target sys/@ auxiliary sys/@rman>DUPLICATE DATABASE FOR STANDBY;

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

Put the standby database in 'managed recover' mode.


For application tier configuration, follow the steps in Section 4: Creating a Physical Standby Database from 4.8 Start ShippingRedo From the Primary to the Standby Database Server through 4.10 Add Your Temp Files to the Standby Database, and thenall the steps in Section 5: Configuration on Application Tiers After Standby Database is Enabled.

6.

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

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

Prerequisites1. Configure Oracle Data Guard Broker2. Role Transitions3.

H1. Prerequisites:

Prior to using Oracle Data Guard Broker, the standby database should be configured.You must be using a server parameter file (SPFILE).The data guard broker starts database instances during switchover or failover using a statically registered service name. Therefore, itis necessary to add a static descriptor to the custom listener.ora file [/_ifile.ora]. If you choosethe DGMGRL default, then configure as per option 1 below; if you are using a different static descriptor, then set the DGMGRLStaticConnectIdentifier property, as per option 2.

Option 1:The default option is for the broker to assume the service "_DGMGRL." has been staticallyregistered with the listener of each instance. Add a SID_DESC entry as below :

(SID_DESC =(GLOBAL_DBNAME=_DGMGRL.us.oracle.com)(ORACLE_HOME= )(SID_NAME = ))


26 of 29 5/28/2015 12:31 AM

Option 2:Set the primary and standby databases StaticConnectIdentifier property, to a TNS alias that resolves to a statically registereddescriptor.

DGMGRL>edit database set property StaticConnectIdentifier='' where dg_prim is TNSalias to connect the PrimaryDGMGRL>edit database set property StaticConnectIdentifier='' where dg_stndby is TNSalias to connect the Standby

Add the two TNS aliases to ifile (__ifile.ora) under TNS_ADMIN on both standby and primary.

For Example:dg_prim=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=(PORT=))(CONNECT_DATA=(SID=)(SERVER=DEDICATED)))dg_stndby=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=(PORT=))(CONNECT_DATA=(SID=)(SERVER=DEDICATED)))

H2. Configure Data Guard Broker:

Start the Data Guard Broker on both primary and standby databases. The Data Guard Broker will create two files under the locationspecified by the initialization parameter DG_BROKER_CONFIG_FILEn. The default location will be $ORACLE_HOME/dbs/ directory.

alter system set dg_broker_start=TRUE

1.

Configure Data Guard Broker using DGMGRL.

dgmgrl sys/****@DGMGRL>CREATE CONFIGURATION '' AS PRIMARY DATABASE IS '' CONNECT IDENTIFIER IS ;

2.

Add standby database using the following command:

ADD DATABASE '' AS CONNECT IDENTIFIER IS ;

3.

Check the configuration using "Show Configuration".4.

View the configuration using Show Configuration command.5.

Set the following Data Guard Broker properties:

Set the configuration protection mode to maximum availability. At any time you can change the protection mode ofconfiguration. Note that this protection mode requires that there be at least one standby database configured to use standbyredo log files, with its LogXptMode configurable database property set to SYNC on both primary and standby.

DGMGRL>EDIT database set property LogXptMode='SYNC'DGMGRL>EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

1.

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

6.

H3. Role Transitions

3.1 Switchover

Verify that the primary and the target standby databases are in the following states - primary TRANSPORT-ON and standbyAPPLY-ON.

On Primary On Standby

DGMGRL> show database dbbrokDatabase - dbbrokRole: PRIMARYIntended State: TRANSPORT-ONInstance(s):dbbrokDatabase Status:SUCCESS

DGMGRL> show database stndbyDatabase - stndbyRole: PHYSICAL STANDBYIntended State: APPLY-ONInstance(s):dbbrokDatabase Status:SUCCESS

1.


27 of 29 5/28/2015 12:31 AM

Issue the switchover command.

DGMGRL>switchover to ;

2.

Verify the switchover has been successful.

show configurationDatabases:stndby - Primary databasedbbrok - Physical standby database

3.

To complete the switchover, follow the steps in Section 6: Role Transitions starting from 6.1.6 Complete the Database Configurations.4.

3.2 Switchback

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

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

3.3 Failover

There are two types of failover using Oracle Data Guard Broker:

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

Manual Failover

Connect DGMGRL to the standby database.

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

1.

To complete the failover, follow the steps in Section 6: Role Transitions starting from 6.2.6 Complete the database configuration.2.

Automatic Failover

Automatic failover is not supported in the Oracle E-Business Suite environment, since you need to run AutoConfig before bringing thestandby environment online. During this time, this section will be updated when post failover configurations are automated.

Change Log

Date Description

03 Jun 2014 Performed editorial and style review.

06 Apr 2014 Updated post review validation.

26 Feb 2014 Modified security info, corrected missing documents.

01 Aug 2013 Modified for log_archive_dest_state parameter.

16 Apr 2013 Initial publication.

My Oracle Support Knowledge Document 1545920.1, Business Continuity for Oracle E-Business Suite Release 12 Using Oracle 11g (11gR1)Physical Standby Database, by Oracle E-Business Suite Development.

Documentation Notices

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

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are


28 of 29 5/28/2015 12:31 AM

protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy,reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by anymeans. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

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

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

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

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

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

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

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

data guard

Documents