Business Continuity for Oracle E-Business Release 12 Using Oracle 11g Physical Standby Database
Oracle E-Business Suite Release 12 has numerous configuration options that can be chosen to suit particular business scenarios, hardware capability, and availability requirements. This document describes how to configure an Oracle E-Business Suite Release 12 environment to use Oracle Database 11gR1 or
11gR2 as a physical standby.
Note: This document covers both non-RAC and RAC configurations. "For Oracle RAC configuration:" denotes a step specific to Oracle RAC.
The most current version of this note is available as My Oracle Support Knowledge Document 1070033.1.
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. The implementation details on Windows may be different.
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 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
STNDBY_CONTEXT The default is
CONTEXT_FILE Full path to the Applications context file on the application tier or database tier. The default locations are as follows.
Application tier context file:
Database tier context file:
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 database alias TNS alias to connect to primary database.
Standby TNS Alias TNS alias to connect to standby database
This document is divided into the following sections:
Section 1: Overview
Section 2: Before You Start
Section 3: Preparing the Primary Database for Standby Database Creation
Section 4: Creating a Physical Standby Database
Section 5: Configuration on Application Tiers After Standby Database is Enabled.
Section 6: Role Transitions
Section 7: Oracle E-Business Suite Maintenance With Standby Database
Appendix A: Oracle Net Files
Appendix B: Using Oracle Applications Manager to Register Standby Database
Appendix C: Example Standby Database Commands
Appendix D: Using RMAN to Create Physical Standby Database
Appendix F: Creating non-RAC Standby for RAC Primary
Appendix G: Using Data Guard Broker [DGMGRL] to manage Standby Databases
Section 1: Overview
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 thirty standby databases and incorporate them in Data Guard configuration.
Standby databases can be of three types:
Physical Standby
Provides a physically identical copy of the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. A physical standby database is kept synchronized with the primary database by recovering the redo data received from the primary database.
Logical Standby
Contains the same logical information as the primary database, although the physical organization and structure of the data can be different. It is kept synchronized with the primary database by transforming the data in the redo logs received from the primary database into SQL statements and then executing the SQL statements on the standby database.
Snapshot Standby
A fully updatable standby database. Like a physical or logical standby database, a snapshot standby database receives and archives redo data from a primary database. Unlike a physical or logical standby database, a snapshot standby database does not apply the redo data that it receives.
This document details the steps for setting up the first of these types, a Physical Standby database.
Note: Logical standby databases are not supported with Oracle E-Business Suite standard functionality. Snapshot standby databases should be used with caution as the data will be out of sync with the primary.
1.2 Oracle Data Guard
Oracle Data Guard is a set of services that 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 because of a planned or an unplanned outage, Oracle Data Guard can switch a standby database to the primary role, minimizing the downtime.
Oracle Data Guard offers three modes of data protection:
Maximum Protection
This mode offers the highest level of data protection. Data is synchronously transmitted to the standby database from the primary database, and transactions are not committed on the primary database unless the redo data is available on at least one standby database configured in this mode. If the last standby database configured in this mode becomes unavailable, processing stops on the primary database. This mode guarantees no data loss.
Maximum Availability
This mode is similar to the maximum protection mode, including no data loss. However, if a standby database becomes unavailable (for example, due to network connectivity problems), processing continues on the primary database. When the fault is corrected, the standby database is resynchronized with the primary database. If there is a need to fail over before the standby database is resynchronized, some data may be lost.
Maximum Performance
This mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped to the standby database. The commit operation on the primary database does not wait for the standby database to acknowledge receipt of redo data before completing write operations on the primary database. If any standby destination becomes unavailable, processing continues on the primary database, and there is little effect on primary database performance.
1.3 Oracle Dataguard Broker
The Oracle Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations.
The Dataguard broker logically groups the primary and standby databases into broker configuration that allows the broker to manage and monitor them together as an integrated unit.
The data guard broker consists of three components :
Data Guard GUI through Enterprise Manager.
Data Guard Command-line interface(DGMGRL)
Data Guard Monitor
The following describes the operations that the broker automates and simplifies :
Standby Database Creation
Provides the Enterprise Manager wizards that automate and simplify the steps required to create a configuration with an Oracle database on each site, including creating the standby control file, online redo log files, datafiles, and server parameter files.
Note: Customers should follow this document for setting up a physical standby, as is it includes steps specific to the E-Business Suite.
Role Transitions
Simplifies the switchover and failover process, including automatically setting up redo transport and log apply services, and automating failover.
Note: Fast-Start Failover is currently not supported for the E-Business Suite. For further details, see Appendix G
Monitoring
Provides continuous monitoring of the configuration health, database health, and other runtime parameters.
Section 2: Before You Start
2.1 Design Considerations
2.2 Software Prerequisites
2.1 Design Considerations
This note assumes you have already provided a secondary site for your standby environment. In general, the secondary data center should:
Be physically separate from the primary environment, to protect against local and regional disasters. It is common for a corporation to put its business continuance environment in a data center in a different city than its primary data center.
Have network bandwidth between data centers sufficient to handle peak redo data generation plus, if you choose to synchronize your Concurrent Manager output, synchronization of report log and output files.
Have reliable and efficient network services to the primary data center, to the standby data center, and to the user point of presence.
Have the same type of servers as at the primary site, in the desired number for DR protection.
The reader of this document should be familiar with the Oracle11g database server, and have at least a basic knowledge of standby database configurations.
Refer to the following documentation for further information.
Oracle Database 11g Release 1:
Oracle Database Administrator's Guide 11g Release 1 (11.1), Part No. B28310-04)
Oracle Data Guard Concepts and Administration 11g Release 1 (11.1), Part No. B28294-03
Oracle Database 11g Release 2:
Oracle Database Administrator's Guide 11 g Release 2 (11.2) Part No. E10595-06
Oracle Data Guard Concepts and Administration 11g Release 2 (11.2), Part number E10700-02
In addition, you should be familiar with the following Oracle E-Business Suite Release 12 documentation:
My Oracle Support Knowledge Document 406982.1 - Cloning Oracle Applications Release 12 with Rapid Clone
My Oracle Support Knowledge Document 559518.1 - Cloning Oracle Applications Release 12 RAC-Enabled Systems with Rapid Clone [Oracle RAC environments only]
My Oracle Support Knowledge Document 466649.1 - Using Oracle 11g Release 1 (11.1.0.7) Real Application Clusters and Automatic Storage Management with Oracle E-Business Suite Release 12 [Oracle RAC environments only]
My Oracle Support Knowledge Document 823587.1 - Using Oracle 11g Release 2 Real Application Clusters with Oracle E-Business Suite Release 12 [Oracle RAC environments only]
2.2 Software Prerequisites
This document assumes the following minimum software versions:
Software Component Minimum Version Additional Information
Oracle E-Business Suite 12.0.4 or 12.1.1 This document was developed using a fresh install database from an E-Business Suite Release 12.1.1 Rapid Install with the pre-requisite patches listed in My Oracle Support Knowledge
Oracle Database 11gR1 11.1.0.7
Database upgraded by following My Oracle Support Knowledge
For Oracle RAC Configuration : Database configured for Oracle RAC by following My Oracle Support Knowledge Document 466649.1, Using Oracle 11g Release 1 Real Application Clusters and Automatic Storage Management with Oracle E-Business Suite Release 12.
Oracle Database 11gR2 11.2.0.1
Database upgraded by following My Oracle Support Knowledge
For Oracle RAC configuration: Database configured for Oracle RAC by following My Oracle Support Knowledge Document 823587.1 , Using Oracle 11g Release 2 Real Application Clusters with Oracle E-Business Suite Release R12 .
The standby system must use the same database and Oracle E-Business Suite versions.
This document refers to the following top-level directories:
Directory Purpose
RDBMS_ORACLE_HOME Oracle 11g R1/R2 Database ORACLE_HOME
APPL_TOP Directory that contains the application product directories and files.
COMMON_TOP Directory that contains directories and files used across application products
OracleAS 10.1.2 ORACLE_HOME ORACLE_HOME installed by Oracle E-Business Suite on application tier
INST_TOP Directory that contains application instance directories and files
Note: If you want to ensure you have applied all the required application and database patches for cloning, refer to My Oracle Support Knowledge Document 406982.1 for the latest patch information.
Section 3: Preparing the Primary Database for Standby Database Creation
At this point, you have a server to create the physical standby. The top-level mount points on each secondary site server are exactly the same as on their matching primary site server. Ownership and permissions are set appropriately for each mount point. You have a mechanism in place for making remote file copies, including network connectivity as well as appropriate system permissions. The configuration steps are divided up as follows.
3.1 Enable forced logging
3.2 Configure Oracle Net communication to and from standby
3.3 Set up secure connections
3.4 Set primary database initialization parameters
3.5 Enable archive logging on primary system
3.6 Add standby redo logs
3.7 Invite communications from the standby
3.8 Gather temporary file information
3.9 Run the application tier and database pre-clones
3.10 Copy APPL_TOP and Oracle E-Business Suite technology stacks to application tiers in standby environment.
3.1 Enable forced logging
To protect against unlogged direct writes in the primary database that cannot be propagated to the standby database, turn on FORCE LOGGING at the primary database before performing datafile backups for standby creation.
Place the primary database in FORCE LOGGING mode by using the following SQL statement:
SQL>ALTER DATABASE FORCE LOGGING;
Note: This statement may take a considerable amount of time to complete, because it has to wait for all unlogged direct write I/O operations to finish.
3.2 Configure Oracle Net communication to and from standby system
The primary and standby databases need to be able to communicate using Oracle Net. This means that on the standby, a listener needs to be running to handle incoming requests from the primary. In addition TNS aliases must be created on both the primary and standby systems. For both aliases and listener, you should configure ifiles under the TNS_ADMIN directory. You can use either a service (dynamic registration) or SID (static registration) model. This document uses static registration, as used in the standard AutoConfig files.
Standby Listener
This listener only runs while the server is hosting a standby database. On switchover/failover etc, the standard autoconfig listener is used. Use the same structure as the autoconfig listener, substituting different values for port,host and listener name. See Appendix A 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 standby. The fal_client alias is a connect string to the standby; the fal_server alias is the reverse, a connect string to the primary. See Appendix A for an example.
Oracle RAC configuration: The TNS alias requirements are different. See Appendix A1 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 Oracle Data Guard configuration. These redo transport sessions are authenticated using either the Secure Sockets Layer (SSL) protocol or a remote login password file. For Oracle RAC configuration , create password files for all instances.This document uses a password file - see My Oracle Support Knowledge
$ cd
$ orapwd file=orapw
To complete the implementation of the password file, you must add the parameter remote_login_passwordfile to your init.ora file as described in the next section.
3.4 Set primary database initialization parameters
On the primary database, define initialization parameters that control redo transport services while the database is in primary role.
Note: This document uses a static init.ora include file to record parameters. If you are using an spfile, disregard the ifile actions and use the appropriate "alter system" command to make the necessary changes.
Define an archive log destination directory on the file system. Then add these parameters to your database init.ora file via the ifile found at
Primary database: primary role initialization parameters
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 to physical standby either LGWR or ARCH process. LGWR is used in this document.
ASYNC: Specifies that network I/O is to be performed asynchronously for the destination. You can optionally specify a block count (from 0 to 102,400) that determines the size of the SGA network buffer to be used.
REOPEN: The minimum number of seconds before the log writer process (LGWR) should try again to access a previously failed destination.
MAX_FAILURE: The maximum number of reopen attempts before the primary database permanently gives up on the standby database.
NET_TIMEOUT: Specifies the number of seconds the log writer process on the primary system waits for status from the network server (LNS n ) process before terminating the network connection.
log_archive_dest_state_2 When set to ENABLE,allows redo transport services to transmit redo data to the specified destination. Set this value to ENABLE on primary site to send archive log files automatically to standby.
log_archive_format Used to specify the filename format when archiving redo log files. Will use system defaults if not set.
log_archive_min_succeed_dest Defines the minimum number of destinations that must succeed in order for the online logfile to be available for reuse.
log_archive_config enables or disables the sending of redo logs to remote destinations and the receipt of remote redo logs, and specifies the unique database names ( DB_UNIQUE_NAME ) for each database in the Data Guard configuration.
db_unique_name Unique Name to identify the primary and standby (For example 'dg12' for primary and 'dg12s' for physical standby).
fal_server Specifies the TNS network service name that the standby database should use to connect to the FAL server process. FAL Server is Fetch Archive Log (FAL) Server which services requests for archive redo logs from FAL clients running on multiple standby databases. Set this parameter to primary database service name dg12 (for example) to request missing archived redo log files if primary is unable to send the missing log files automatically.
fal_client Specifies the TNS network service name that the primary database should use to connect to the standby.
standby_file_management Set to AUTO. Whenever datafiles are added or dropped from primary database, corresponding changes will be made automatically to the standby.
db_file_name_convert, log_file_name_convert Specify the path name and file name location of datafiles and redo log files. db_file_name_convert parameter need not be set when the directory structures are same on primary and standby. But log_file_name_convert should set to dummy values if you are using same directory structure to enable redo log clearing.
Remote_login_passwordfile
This parameter checks specifies whether Oracle checks for a password file. Since we are using password authentication this parameter should set.
For further explanation of the initialization parameters, refer to Oracle Data Guard Concepts and Administration 11g Release 2 (11.2).
The configuration examples use the names shown in the following table.
Primary Database Physical Standby Oracle RAC Primary Oracle RAC Standby
Oracle Net Service name dg12 dg12s prod
stdby
SID dg12 dg12 prod1 and prod2
stdby1 and stdby2
DB_UNIQUE_NAME dg12 dg12s prod
stdby
Note: The database SID is the same on both the primary and physical standby databases.
The following example shows the relevant initialization parameters of the primary database.
db_unique_name = dg12 ---- You need to change this to dg12s (Standby db_unique_name, for example) when you copy this file to physical standby
log_archive_dest_1 = LOCATION=/arch1/dg12/ MANDATORY
log_archive_dest_2 = SERVICE=dg12s LGWR ASYNC=20480 DB_UNIQUE_NAME=dg12s OPTIONAL REOPEN=15 MAX_FAILURE=10 NET_TIMEOUT=30
log_archive_config='dg_config=(dg12,dg12s)'
# log_archive_dest_state_2 = defer
# log_archive_dest_state_2 = enable
log_archive_min_succeed_dest = 1
standby_file_management = AUTO
Remote_login_passwordfile = exclusive
log_archive_format =
# db_file_name_convert: do not need; same directory structure
# log_file_name_convert: do not need; same directory structure
fal_server = dg12
fal_client = dg12s
log_file_name_convert = xx,xx # Specify dummy values to trigger log clearing
For Oracle RAC Configuration: Configure
db_unique_name=prod
log_archive_dest_1='LOCATION=
log_archive_dest_2='service=stdby valid_for=(online_logfiles,primary_role) db_unique_name=stdby LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30'
log_archive_dest_state_1 = enable
log_archive_dest_state_2 = enable
fal_server=prod
fal_client=stdby
log_archive_format=prod1_%s_%t_%r.log
db_file_name_convert='
log_file_name_convert='
standby_file_management=auto
3.5 Enable archive logging on primary system
Enable archiving on primary system if it is not already enabled.
3.6 Add standby redo logs
Standby redo logs are required to use real-time apply. As the remote file server (RFS) process writes the redo data to standby redo log files on the standby database, apply services can recover redo from standby redo log files as they are being filled.
Best practice is to add them in both the primary and the standby database so switchovers between the environments are quicker and easier. Here, you will add them in production so they are in place when you clone the database for the standby.
Standby redo logs are additional redo log groups, with a different type. You can only have as many redo log groups overall as the maximum setting for your database for logfile groups and logfile members.
Standby redo log groups should be multiplexed in the same manner as online redo log groups.
To create standby redo log groups, as the ORACLE user on the primary database server, connect to SQL*Plus as sysdba and issue a command like this for each standby redo log group you will create: For an example, refer to Appendix C.
SQL>alter database add standby logfile group N (
For Oracle RAC Configuration: Ensure standby logs are created for each redo thread.
3.7 Invite communications from the standby
Release 12 has a new security feature that restricts remote connections to the database for clients that are not registered on the system. This feature is enabled by default.
When this option is enabled, any additional computers that require direct access to the Oracle E-Business Suite database (via SQL*Plus, SQL*Navigator, etc.) will need to be 'Registered Nodes' to explicitly obtain access.This is achieved by setting the invited nodes value in sqlnet.ora file. If you have enabled invited nodes in SQLNET.ORA, then the standby host needs to be added to the list of nodes. You can perform this step using OAM. Refer to Appendix B for detailed steps.
3.8 Gather temporary file information
You will need to manually recreate your temporary files on the standby database. Gather the required data now from the primary database with the following SQL*Plus query:
SQL>select file_name, bytes from dba_temp_files;
Save the output for use in a later step. For an example of the output, refer to Appendix C.
3.9 Run the application tier and database tier pre-clone scripts
As the ORACLE user, run the database pre-clone utility on the primary database server:
For Oracle RAC Configuration : Run pre-clone scripts on all database nodes and application tier nodes.
$ cd $RDBMS_ORACLE_HOME/appsutil/scripts/context_name/
$ perl adpreclone.pl dbTier
Supply the APPS password when requested.
As the APPLMGR user, run the application tier pre-clone utility on each primary application tiers that has an APPL_TOP (or only on one, if it is shared by all):
$ cd $INST_TOP/admin/scripts/
$ perl adpreclone.pl appsTier
(Optional) Shut down all application tier services to copy the APPL_TOP. If your operating system returns errors when copying open files, you may need to shut down application tier services to successfully copy the APPL_TOP and Oracle E-Business Suite technology stack software.
$ 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 with Rapid Clone. For details of cloning Oracle RAC systems, refer to My Oracle Support Knowledge Document 559518.1, Manually Cloning Oracle Applications Release R12 with 10g or 11g RAC.
Section 4: Creating a Physical Standby Database
4.1 Copy the ORACLE_HOME and database to the standby database server
4.2 (Optional) Generate a standby control file, copy to standby DB server
4.3 Do file-based configurations on standby database server
4.4 Stop the database listener on the standby database server
4.5 Configure Oracle Net for redo transmission, start the listener
4.6 Modify the database init.ora parameters on the standby server
4.7 Mount the physical standby, start processing redo on the standby
4.8 Start shipping redo from the primary to the standby database server
4.9 Verify redo is shipping
4.10 Add your temp files to the standby database
4.11 Configure Data Guard Broker (Optional)
4.1 Copy the ORACLE_HOME and database to the standby database server
Copy the Oracle Home file system to the standby database server. If you natively compile your PL/SQL, be sure you include the file system directories holding the compiled objects. The standard location for this is
There are three choices for backing up or copying the database to the standby site:
Manual Cold backup
With the database shut down, copy all the database files and redo log files to the standby site.
Manual Hot Backup
With the open, put the tablespace in backup mode, and copy the data files to the standby site.
RMAN
Use the 'duplicate database' command. See Appendix D and for RAC Appendix E examples of usage.
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.See the RMAN documentation for more details. RMAN restores a backup control file, and copies all necessary database files and archived redo logs over the network to the standby host. However, while RMAN recovers the standby database, it does not place it in manual or managed recovery mode.
4.2 Generate a standby control file and copy it to standby database server
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 the standby.
4.3 Do file-based configurations on the standby database server
After the database software copies are complete (which can be done before the database itself is finished copying), log into the standby database server as the ORACLE user and execute the following commands to update the file system configurations for the new environment. Since your environment scripts are not yet set up, you will need to manually resolve the reference to
$ cd
$ 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 Oracle RAC Configuration:
Run adclonectx and adclone on all nodes.
Answer the questions when prompted. Enter 'Y' when prompted Current node is the first node in an N Node RAC Cluster (y/n)[n]:y on every node, otherwise it will prompt for "Live RAC node", which will not be available at this time: refer to Appendix F.
Modify the init parameter files to point the correct diagnostic destination and utl_file_dir with standby context directory.
Run the following commands (shown split over a number of lines for readability).
$ perl
$ perl adclone.pl java
component=dbTechStack \
mode=apply \
stage=
method=custom \
dbctxtg=
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
$ ./
If you have implemented native PL/SQL compilation, set up an rsync job from the primary database server to the standby database server for the file system directories holding the compiled objects. The standard location for this is
4.4 Stop the database listener on the standby database server
The above step starts the database listener. It is not yet completely configured, so should be stopped. As the ORACLE user on the standby database server, enter the following command:
$ lsnrctl stop
4.5 Configure Oracle Net for redo transmission, start the listener
For Oracle RAC Configuration: Perform this step on all nodes.
As the ORACLE user, copy the listener_ifile.ora and
In the
In the listener_ifile.ora file, ensure that the HOST for the standby service entry points to the standby database host.
As the ORACLE user, start the database listener for the standby:
$ lsnrctl start
4.6 Modify the database init.ora parameters on the standby server
As the ORACLE user on the standby database server, create an ifile for the standby database from the one you created earlier for the primary database:
$ cd
$ cp
Update the following parameters:
DB_UNIQUE_NAME to a name different from primary : for example dg12s
LOG_ARCHIVE_DEST_2 to point to the standby service. This is required when standby is switched to primary and ships redo to new standby
e.g. LOG_ARCHIVE_DEST_2 for 'service=dg12s ASYNC REGISTER VALID_FOR=(online_logfile,primary_role) DB_UNIQUE_NAME=dg12'
If you are using an spfile, and are therefore not using the autoconfig generated init.ora, make the following additional changes:
diagnostic_dest to
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 = (
For Oracle RAC Configuration: log_archive_dest_1 should be set to the same shared location on all standby instances. The standby redo logs will be archived to this location, and should be accessible by all other standby instances.
4.7 Mount the physical standby, start processing redo on the standby
Ensure that the password file created in Section 3.3 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 sysdba and issue these commands:
Note: Skip this step if you used RMAN for standby creation.
SQL>startup nomount pfile=
SQL>alter database mount standby database;
Put the standby database in 'managed recover' mode
SQL>alter database recover managed standby database disconnect from session;
4.8 Start shipping redo from the primary to the standby database server
As the ORACLE user on the primary database server, set log_archive_dest_state_2 to enable in the database initialization file.
# log_archive_dest_state_2 = defer
log_archive_dest_state_2 = enable
4.9 Verify redo is shipping
Check to see that the database is shipping redo, by connecting to the primary database and causing a log switch:
SQL>alter system switch logfile;
Still on the primary, check for the status of the archive destinations to determine the most recently archived redo log file at each redo transport destination. The most recently archived redo log file should be the same for each destination. If it is not, a status other than VALID may identify an error encountered during the archival operation to that destination:
SQL>select * from v$archive_dest_status where status != INACTIVE;
On each database server, this query will show the 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 for standby creation.
To save time on failover, add your temp files to the standby database now. You collected the temporary file names and sizes in Step 3.8.
To do this, you will need to open the database in read only mode. You will not be able to open the database read only until recovery has progressed past the time the control file was created - the log sequence number was noted in Step 4.2.
Execute the following commands:
SQL>alter database recover managed standby database cancel;
SQL>alter database open read only;
SQL>alter tablespace temp add tempfile '
[enter as many lines as you have temporary data files]
SQL>shutdown immediate;
SQL>startup mount;
SQL>alter database recover managed standby database disconnect from session;
4.11 Data Guard Broker Configuration (Optional)
If you wish to use Data Guard Broker to manage an E-Business standby database, follow, Section 1 and Section 2 of Appendix G
Section 5: Configuration on application tiers after standby database is enabled
5.1 Configure standby application tiers
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 new environment. To do this on the application tiers, log onto each standby application tier system as the APPLMGR user and execute the following commands. Since your environment scripts are not yet set up, you will need to manually resolve the reference to
If the directory structure on standby is different than the primary then you need to run "perl adcfgclone.pl atTechStack" instead of adclonectx.
$ cd
$ perl adclonectx.pl
Refer to My Oracle Support Knowledge Document 406982.1 Cloning Oracle Applications Release 12 with Rapid Clone for details.
When the script is finished and the context file is created, execute the following commands, again resolving the reference to
If the application tier is configured as a concurrent server only, then modify the context variable s_isWeb to YES . After executing the commands below, change it back to NO.
$ cd APPL_TOP/ad/12.0.0/bin
$ perl adconfig.pl contextfile=$INST_TOP/appl/admin/
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. /LI>
Optionally, set up rsync for log and out files.
If you wish to synchronize your concurrent manager log and out files from primary to the standby, first create directories matching matching to the APPLCSF environment variables in the appropriate place on the standby application tier server(s). For example:
$ mkdir -p
$ mkdir -p
Repeat this on the primary server, creating directories matching the standby context name, so as to be ready for a switchover operation.
For UNIX systems, on the primary application tier(s), set up an rsync job in cron, to run every few minutes. This example synchronizes the log directory:
$ rsync av < APPLCSF>/log
Section 6: Role Transitions
A database can operate in either a primary or standby role: these roles are mutually exclusive. Oracle Data Guard enables you to change these roles dynamically by issuing SQL commands, and supports the following transitions:
Switchover Allows the primary database to switch roles with one of its standby databases. There is no data loss during a switchover. After a switchover, each database continues to participate in the Oracle Data Guard configuration with its new role.
Failover Changes a standby database to the primary role in response to a primary database failure.
The following role transitions are discussed :
6.1 Performing a switchover
6.2 Performing a failover
6.3 Performing switchback to primary after switchover/failover
For all three transitions, applications configuration is required. As most application configuration steps are common to all transition types, it is discussed in the final part of this section:
6.4 Application tier configuration after a role transition (switchover/failover/switchback)
6.1 Performing a switchover
If you are using Data Guard Broker to manage the standby database, follow section 3 in Appendix G then go to Step 6.1.6
A switchover is typically used to reduce primary database downtime during planned outages, such as operating system or hardware upgrades, or rolling upgrades of the Oracle database software and patch sets. A switchover takes place in two phases. In the first phase, the existing primary database undergoes a transition to a standby role. In the second phase, a standby database undergoes a transition to primary. In this case the primary site is accessible and involved in the switchover.
Sections 3,4 and 5 define how to set up your environments so there will be minimal parameter changing when switching. This section assumes you have configured your parameter files as described in these sections.
6.1.1 Preparing for switchover to standby server
Verify the primary database instance is open and standby database instance is mounted.
Verify there are no active users connected to the database. Shut down all the sessions in the primary database.
Ensure that the last redo data transmitted from the primary database was applied on the standby database. Issue the following SQL command on the primary and standby databases to find out. If necessary, perform a logfile switch before the first command.
SQL>select sequence#,applied from v$archived_log;
Check whether the primary is ready for switch. Query the switchover_status column of the v$database fixed view to determine whether the database is ready to switch modes.
SQL>select switchover_status from v$database;
If this query returns "TO STANDBY", then the environment is ready to switch. If it returns "ACTIVE SESSIONS", then the switch command should be used with the 'session shutdown' option.
6.1.2. Initiate the switch over on the primary database
For Oracle RAC Configuration: For switchover, only one primary instance should be mounted. All others must be shut down. After switchover, LOG_ARCHIVE_DEST_STATUS_2 should be set for all instances.
Connect as sysdba and issue the following SQL command:
SQL>connect / as sysdba;
SQL>alter database commit to switchover to physical standby with session shutdown;
After this statement completes, the primary database is converted to a standby database. As part of the statement's execution, the current control file is backed up to the current SQL session's trace file, making it possible to reconstruct the control file if necessary.
Change the value of LOG_ARCHIVE_DEST_STATUS_2 to defer on primary.
6.1.3 Shut down and mount the primary database
To complete the transition, the database must be shut down and restarted in a mounted state. In addition, recovery can be started in preparation for transition.
SQL>shutdown immediate
SQL>startup nomount pfile=$ORACLE_HOME/dbs/init
SQL>alter database mount standby database;
SQL>alter database recover managed standby database disconnect from session;
At this point in the switchover, both databases are standby databases.
6.1.4 Verify the switchover status on the standby server
As the ORACLE user on the standby-to-be-primary database server, verify it is ready to switch to primary:
SQL>select switchover_status from v$database;
This should return a value 'TO PRIMARY'. Any other value, such as SESSIONS ACTIVE, NOT ALLOWED, and so on, should be investigated and corrected as in Step 2 above.
6.1.5 Switch the selected standby database to the primary role
For Oracle RAC Configuration: 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
Change the LOG_ARCHIVE_DEST_STATE_2 to enable.
To complete the transition, the database must be shut down and re-started:
SQL>shutdown immediate
SQL>startup pfile=$ORACLE_HOME/dbs/init
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 ;
As the ORACLE user on the new primary database server, use AutoConfig to complete configuration for primary operations, providing the APPS password when prompted:
$ cd
$ ./adautocfg.sh
When this completes, stop and start the listener on the new primary database server:
$ lsnrctl stop
$ lsnrctl start
On the new standby server, stop and start the listener for standby services:
$ lsnrctl
$ lsnrctl start
For applications-specific configurations, follow the steps in Section 6.4.
For Oracle RAC Configuration: Repeat above steps [2-4] for each instance. Rerun AutoConfig on all nodes after completing steps [2-4] for each instance to update all configuration files with all nodes in the cluster.
6.2 Performing a failover
If you are using Data Guard Broker to manage standby databases follow Section 3 "Manual Failover" in Appendix G then go to Step 6.2.7
You may need to fail over to your standby site due to complete failure of the primary site. This section describes the steps in the event of failure of the primary site.
Sections 3, 4 and 5 define how to set up your environments so there will be minimal parameter changing when failing over. This section assumes you have configured your parameter files as described in these sections.
Performing a failover separates the standby database from the primary. You must create a new standby database environment from the environment to which you failed over, to restore disaster recovery protection.
6.2.1 Flush any unsent redo from the primary database to the target standby database
Note: This is a new feature in Oracle Database 11g Release 2 . Skip this step if you are using Database 11g Release 1(11.1.0.7).
If the primary database can be mounted, it may be possible to flush any urgent archived and correct redo from the primary database to the standby database. Ensure that redo apply is active on standby server. Mount the database, but do not open it.
SQL>alter system flush redo to 'target_db_name';
This statement flushes any unsent redo from the primary database to the standby database, and waits for that redo to be applied to the standby database.
6.2.2 Verify that standby database has the most recently archived redo log file for each primary database redo thread
Query the V$ARCHIVED_LOG view on the target standby database to obtain the highest log sequence number for each redo thread:
SQL>SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
6.2.3 Identify and resolve any archived redo log gaps
On the standby database server, connect as sysdba to the standby database. Query v$archive_gap to determine whether there are missing archive logs:
SQL>select * from v$archive_gap;
If this query returns a row, it indicates at least one archived redo log is missing from the standby. If you still have access to your primary database, you can determine the full name of the redo logs by querying v$archived_log, using the low_sequence# and high_sequence# returned above:
SQL>select name from v$archived_log
where thread# =
and sequence# between
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 are reported.
6.2.4 Adjust standby archive destination status
On the standby database server, change the initialization parameter for the destination state of the archive logs to be shipped from primary to standby from 'defer' to 'enable'. Make the changes in
log_archive_dest_state_2 = enable
# log_archive_dest_state_2 = defer
6.2.5 Stop redo apply and finish applying all received redo data
For Oracle RAC Configuration: 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
Note: You should back up this database without delay, as you cannot recover any changes made after the failover without a fresh backup.
6.2.6 Update TNS parameters for new standby database location
As the ORACLE user on the new-primary database server:
Open the
Change the value for the HOST name in the standby service definition to point to a new primary host.
Save the changes and close the file.
6.2.7 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;
As the ORACLE user on the new primary database server, use AutoConfig to complete configuration for primary operations, providing the APPS password when prompted:
$ cd
$ ./adautocfg.sh
When this completes, stop and start the listener on the new primary database server:
SQL>lsnrctl stop
SQL>lsnrctl start
To complete the application-specific configurations, follow the steps in Section 6.4.
For Oracle RAC Configuration: Repeat above steps 2 and 3 for each instance.
6.3 Performing switchback
6.3.1 Switch back to primary site after a switch over
After switch over to standby and maintenance is complete you need to switch back to the primary site. In this case, the pre-switchback configuration will be as follows:
Standby Site Primary Site
Primary Database Standby Database
Steps to perform the switchback to primary site:
Verify primary database at standby site is open and standby database at primary site is mounted.
Verify all the redo logs are transferred to standby and applied.
Check whether switchover_status from v$database is showing TO STANDBY.
On the primary database, issue the command:
SQL> alter database commit to switchover to physical standby
Adjust the LOG_ARCHIVE_DEST_STATE_2 defer at standby site(primary database) and enable at primary site (standby database).
Adjust the network configurations as mentioned in Step 6.1.5 of Section 6.1
Shut down and mount the database as standby at the standby site.
Start the recovery by issuing the following commands at the primary site:
SQL>alter database commit to switchover to physical primary
Shut down and start up the database at the primary site.
Verify the redo log shipping. Refer Section 6.1 for the commands.
For application-specific configurations, follow the steps in Section 6.4.
6.3.2 Recreating the original primary database after failover
If you performed failover to a standby database, then resolved the problem at the original primary site that necessitated the failover operation, you can now recreate the primary database on the original primary site:
Make a consistent backup of activated standby database at standby site.
Restore the backup created at standby site to primary database.
Run AutoConfig on both the database tier and application tier.
Shut down and start up the database.
On the original primary site, create or modify the initialization parameter file with the appropriate values.
Create a new standby database at the original standby site. Follow instructions in Sections 3, 4 and 5.
For application-specific configurations, follow the steps in Section 6.4.
Section 6.4 Configuring application tiers after role transition (switchover, failover, switchback)
6.4.1 Finish Oracle E-Business Suite configuration on application tiers
After the primary database configuration is complete and its listeners have started, log in to each now-primary application tier server as the APPLMGR user, and run the final configuration steps:
$ cd $INST_TOP/admin/scripts>
$ ./adautocfg.sh
Provide the APPS password when prompted.
6.4.2 Update host name in fnd_concurrent_requests and fnd_conc_req_outputs tables
If you synchronize your concurrent manager log and out directories, you must change the host name in the fnd_concurrent_requests table to the standby server name:
SQL>update apps.fnd_concurrent_requests
set 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_requests table to avoid network timeout errors:
SQL>update apps.fnd_concurrent_requests
set logfile_node_name = null,
outfile_node_name = null;
SQL>update apps.fnd_conc_req_outputs set file_node_name=null;
If you run the latter update, you must execute it before starting the concurrent managers on the system. If you do not execute it before starting the managers, you must add a where clause to limit the rows updated to those pointing to the old host names. This does not need to complete before you run the next step. However, if you let users on to the system before it is committed, they will get errors if they try to access a report's log or out file that was generated on the old primary system.
6.4.3 Perform the cloning finishing tasks
Perform the Finishing Tasks outlined in My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications Release R12 with Rapid Clone.
Instance specific profile options at other than site level (Rapid Clone updates the site level instance specific profile options)
Printer settings as necessary
Workflow configuration settings
APPLCSF variable if necessary
6.4.4 Direct users to the new system
The standby system should be available to your users as your new primary system. Direct your users to the new URL.
6.4.5 Establish a new standby system
Perform this step if you have performed a failover. Failing over to the standby database (versus switching over) separates it from the old primary. You must create a new standby environment from this new system to again provide disaster recovery protection.
6.4.6 (Optional) Re-point your CM log and out and native PL/SQL object directory rsync scripts
If you are keeping your concurrent manager log and out directories synchronized across the environments, set up your rsync scripts to move the files from the new primary server to the new standby server.
Section 7: Oracle E-Business Suite Maintenance with Standby Database
This section describes how to apply an Oracle E-Business Suite patch in on the primary, and incrementally update the standby.
Applying an application patch when standby is configured requires:
Syncing of standby with the primary after applying the patch. There are two choices:
Syncing File system using rsync, and redo log apply for the database.
Recreate the standby completely. When the patch is a major upgrade of the application this is the recommended approach.
Protecting the primary as well as standby from any problems during patch application:
If your standby database is running during patch application, the database changes on primary will be automatically pushed to the standby. If you do not want these changes pushed to standby until after patching is complete, you should shut down 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.
7.1 Preparing for applying application patch
7.1.1 On the standby: stop recovery delay if it is set
If you have recovery delay set for redo log application on the standby, stop the delay. On the standby database, run the following command as a privileged user:
SQL>alter database recover managed standby database nodelay;
7.1.2 Shut down the application tier services on the primary
As the APPLMGR user, shut down all application tier services and stop the listeners on all application tier servers:
$cd $INST_TOP/admin/scripts
$adstpall.sh apps/
7.1.3 Switch redo logs in the primary database
On the primary database server, log into SQL*Plus as sysdba and issue the following commands to switch logs, and then discover the last log sequence number:
For Oracle RAC Configuration: Perform switching on each instance.
SQL>alter system switch logfile;
SQL>select sequence# -1 from v$log where status = 'CURRENT';
7.1.4 Ensure that the last log is applied on the standby
On the standby database server, connect as sysdba and monitor the system to see that this last log has been shipped and applied there, to bring the standby to the point in time services were stopped on the primary:
SQL>select sequence#, applied
to_char(first_time, 'mm/dd/yy hh24:mi:ss') first
from v$archived_log
order by first_time;
7.1.5 Stop recovery on the standby
For Oracle RAC Configuration: Shut down all instances except the recovery standby instance.
On the standby database server, stop recovery after the last redo log is applied, and before applying the patch: if there are issues in applying the patch, the primary system can be restored from standby.
SQL>alter database recover managed standby database cancel;
7.2 Patch Primary
Test that the patch applied successfully.
7.3 After Applying the Patch
Perform the following steps after successful patch application.
7.3.1 Restart redo data shipping and apply on standby
If the patch applied successfully, restart recovery on the standby database server. Connect to SQL*Plus as sysdba, and run the command:
SQL>alter database recover managed standby database disconnect from session;
7.3.2 Run the application tier and database pre-clones
As the APPLMGR user, run the application tier pre-clone utility on each primary application tier that has an APPL_TOP (or only on one, if it is shared by all):
$cd $INST_TOP/admin/scripts
$perl adpreclone.pl appsTier
If the patch required updating the database ORACLE_HOME with a new set of Apps utilities (appsutil.zip), you should also reconfigure the database server. As the ORACLE user, run the database pre-clone utility on the primary database server:
$ cd
$ perl adpreclone.pl dbTier
Supply the APPS password when requested.
For Oracle RAC Configuration: Perform the pre-clone procedure on each instance.
7.3.4 Synchronize the appropriate file systems
Depending on what was patched, synchronize the appropriate standby server directories with the changes made on the primary servers using an OS utility such as rsync or rdist. Within the scenario of freezing the DR image until the patch is complete, these synchronization commands should be executed manually after the patch is finished and tested, not via cron.
Note the standby database and environment are not viable as a DR solution until the synchronization command completes.
For an Oracle E-Business Suite patch, synchronize these directories:> APPL_TOP , COMMON_TOP , 10.1.2 ORACLE_HOME , and 10.1.3 ORACLE_HOME.
For an Oracle E-Business Suite technology stack upgrade, synchronize these directories: OracleAS 10.1.2 ORACLE_HOME , OracleAS 10.1.3 ORACLE_HOME > .
7.3.5 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.6 Reconfigure the standby application tier file systems
Log in to the standby application tier systems as the APPLMGR user and execute the following commands:
If the directory structure on standby is different than the primary then you need to run "perl adcfgclone.pl atTechStack
Refer to My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications Release 12 with Rapid Clone, for further details.
When the script is finished and the context file is created, run the following commands (the perl command is entered on one line):
$ cd $APPL_TOP/ad/12.0.0/bin
$ perl adconfig.pl contextfile=
This recreates your environment files on the application tier. It tries to connect to the database, so some portions fail, but the environment scripts should be successfully created.
7.3.7. Reconfigure the standby database file systems (optional)
For Oracle RAC Configuration: Perform the following steps on each instance.
If you had to synchronize the apps utilities on the database server in the previous step, you should also reconfigure the database server. As the ORACLE user on the standby database server, first stop the listener if it is running, then use the cloning toolkit to define the database tier topology at the standby site:
$ lsnrctl stop
$ cd
$ 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
##################################################################
#
# 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=
(CONNECT_DATA=(SID=dg12)
)
) #
# Fetch Archive Log (FAL) service definition.
# This entry can be set up for use when THIS server hosts a
# standby database (thus will not need to be changed on switchover),
# and should point to what would be the PRIMARY AT THAT TIME -
# i.e. this is the fal_server alias used to communicate from the standby to primary.
dg12=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)
(HOST=
(PORT=
Standby LISTENER.ORA file when server is running as standby
dg12s =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)
(HOST= < standby DB host >)
(PORT=
)
)
SID_LIST_dg12s =
(SID_LIST =
(SID_DESC =
(ORACLE_HOME=
(SID_NAME=dg12)
)
)
STARTUP_WAIT_TIME_dg12s = 0
CONNECT_TIMEOUT_dg12s = 10 TRACE_LEVEL_dg12s = OFF
LOG_DIRECTORY_dg12s =
LOG_FILE_dg12s = STDBY
TRACE_DIRECTORY_dg12s =
TRACE_FILE_dg12s = STDBY
ADMIN RESTRICTIONS_dg12s = OFF
Appendix A1: TNS Alias Requirements in Oracle RAC Configuration
For Oracle RAC configuration, the entries for the TNS aliases should be as follows, where prod and stdby are the primary and standby service names respectively. The entries must be the same on all nodes in the cluster, and also in the standby instances.
prod=
(DESCRIPTION=
(LOAD_BALANCE=NO)
(FAILOVER=YES)
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=
(PORT=1529))
(ADDRESS=
(PROTOCOL=tcp)
(HOST=
)
(CONNECT_DATA=(SERVICE_NAME=prod))
)
stdby=
(DESCRIPTION=
(LOAD_BALANCE=NO)
(FAILOVER=YES)
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=
(PORT=1529))
)
(CONNECT_DATA=(SERVICE_NAME=stdby))
)
Appendix B: Using Oracle Applications Manager to Register Standby Database
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)
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
Select the host you just added, and click 'Continue'.
If the displayed list is correct and includes your new host, click 'Submit'.
Appendix C: Example Standby Database Commands
Example for standby redo log files:
Alter database add standby logfile group 4 ('/d1/MAABCU/primary/dg12data/log5.dbf') size 50M ;
Alter database add standby logfile group 5 ('/d1/MAABCU/primary/dg12data/log6.dbf') size 50M ;
Alter database add standby logfile group 6 ('/d1/MAABCU/primary/dg12data/log7.dbf') size 50M ;
Gathering temporary tablespace information to creating temporary tablespace on standby
SQL>select file_name, bytes from dba_temp_files;
FILE_NAME BYTES
------------------------ ------------------
/d1/MAABCU/primary/dg12data/tmp1.dbf 2097152000
Appendix D: Using RMAN to Create Physical Standby Database
Steps to be performed:
Create initialization parameter file for standby. Run the following command on the primary:
SQL>create pfile from spfile
Copy init
Change db_unique_name to standby db_unique_name - this should be different from primary.
For example, db_unique_name=dg12s
For log_archive_dest_2, specify primary db_unique_name.
For example, log_archive_dest_2='SERVICE=dg12s LGWR ASYNC DB_UNIQUE_NAME=dg12
db_unique_name should specify to ship redo logs from standby site to primary site after switch over
Connect as sysdba and issue the following command to start up but not mount the standby.
SQL>startup nomount pfile=
Connect to target and auxiliary databases using RMAN:
$ rman target sys/manager@dg12 auxiliary sys/manager@dg12s
(In this example, dg12 = primary service name and dg12s = standby service name)
Recovery Manager: Release 11.2.0.1.0 - Production on Wed Jan 20 03:16:56 2010 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: dg12 (DBID=3753412759)
connected to auxiliary database: dg12 (not mounted)
RMAN >
Execute the RMAN DUPLICATE command on standby:
RMAN >DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
DORECOVER
SPFILE SET "db_unique_name"="dg12s"
SET LOG_ARCHIVE_DEST_2="service=dg12s ASYNC REGISTER VALID_FOR=(online_logfile,primary_role)DB_UNIQUE_NAME=dg12"
SET FAL_SERVER="dg12" COMMENT "Is primary"
SET DIAGNOSTIC_DEST=$ORACLE_HOME/admin/
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 instance with this file.
Appendix E - RAC RMAN Clone Example
If you are using Rapid Clone for cloning an Oracle RAC primary database to standby, use the following commands for RMAN backup and restore.
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';
Restore the and create standby database using RMAN:
On the standby system first node, start up the database in nomount mode (using a pfile) and run the following command
-bash-3.00$ rman target sys/manager@prod auxiliary /
Recovery Manager: Release 11.1.0.7.0 - Production on Thu Mar 11 02:17:43 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: PROD (DBID=3908691352)
connected to auxiliary database: PROD (not mounted)
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY;
Enable recovery on the node that is to be used for the recovery process.
Appendix F
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=
Provide the values required for creation of the new Database Context file.
Do you want to use a virtual hostname for the target node (y/n) [n] ?:
Target hostname [rws60001atg]:
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 [rws60001atg]:
Instance number [1]:
Private interconnect name [rws60001atg]:rws60001atg-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 130.35.33.95: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_rws60001atg.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_rws60001atg.xml
perl adclone.pl java=
-e
-stage
-rmanstage
/oradata/MAABCU/RAC12STDBY/backupsets/
-rmantgtloc
/oradata/MAABCU/RAC12STDBY/db/apps_st/data/
-srcdbname
prod
APPS Password : apps
Log file located at
Completed Apply...
Fri Mar 12 01:27:09 2010
Beginning APPSDB_stdby1 registration to central inventory...
ORACLE_HOME NAME : APPSDB_stdby1
ORACLE_HOME PATH : /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0
Using Inventory location in /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/oraInst.loc
Log file located at /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/oraInventory/logs/OracleHomeCloner_03120127.log
ORACLE_HOME /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0 was registered successfully.
Appendix F - Creating non-RAC Standby for RAC Primary
Configure primary RAC to create non-RAC Standby
Follow the instructions given in Section 3 to configure primary RAC.
Create Physical Standby
Copy ORACLE_HOME to Standby database server.
Copy the Oracle Home file system to the standby database server. If you natively compile your PL/SQL, be sure you include the file system directories holding the compiled objects. The standard location for this is RDBMS ORACLE_HOME /plsql/nativelib.
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 step 1 of Appendix E for complete rman instructions.
Do File base configuration on Standby Database Server
After the database software copies are complete (which can be done before the database itself is finished copying), log into the standby database server as the ORACLE user and execute the following commands to update the file system configurations for the new environment. Since your environment scripts are not yet set up, you will need to manually resolve the reference to RDBMS ORACLE_HOME .
$ cd RDBMS ORACLE_HOME /appsutil/clone/bin
$ perl adcfgclone.pl dbTechStack
Answer the questions when prompted. If you receive any errors registering the new ORACLE_HOME, follow the instructions given by the script to correct them.
For Target instance is a Real Application Cluster (RAC) instance (y/n) [y]: n
you need to enter 'n' as standby is non-RAC
Relink oracle with rac_off option if adlnkoh.sh is failing then run adcfgclone again
Your ORACLE user environment scripts are now ready to use. Source them for the next steps, using the appropriate OS command.
For example, in sh or ksh on UNIX:
$ cd RDBMS ORACLE_HOME
$ ./ STNDBY_CONTEXT .env
If you have implemented native PL/SQL compilation, set up an rsync job from the primary database server to the standby database server for the file system directories holding the compiled objects. The standard location for this is RDBMS ORACLE_HOME /plsql/nativelib.
Modify the initialization parameter as per step 4.6 under section 4.
Stop the standby listener and configure for net redo transmission
Stop the listener and modify the
Startup Instance in nomount
sqlplus / as sysdba
startup nomount
Create the standby database using RMAN.
rman target sys/
rman>DUPLICATE DATABASE FOR STANDBY;
After the above the command execution the database will be in mount state running with the initialization parametet (PFILE).
Put the standby database in 'managed recover' mode
SQL>alter database recover managed standby database disconnect from session;
Follow the steps from step 4.8 of Section 4 and Section 5 for application tier configuration.
Appendix G - Using Data Guard Broker [DGMGRL] to manage Standby Databases
Data Guard Broker is an easy to use interface to manage standby databases. It is easy to perform role transitions with a single command either
for switchover or failover. This section covers DGMGRL - the command line interface used to manage standby databases.
Pre Requisites
Configure Data Guard Broker
Role Transitions
1. Pre Requisites :
Prior to using Data Guard Broker, the standby database should be configured.
You must be using a server parameter file (SPFILE).
The data guard broker starts database instances during switchover or failover using a statically registered service name. Therefore, it is necessary to
add a static descriptor to the custom listener.ora file [
Option 1 :
The default option is for the broker to assume the service "
(SID_DESC =
(GLOBAL_DBNAME=
(ORACLE_HOME=
(SID_NAME =
)
Option 2 :
Set the primary and standby databases StaticConnectIdentifier property, to a TNS alias that resolves to a statically registered descriptor.
DGMGRL>edit database
DGMGRL>edit database
Add the two TNS aliases to ifile (
for Example :
dg_prim=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=
dg_stndby=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=
2. 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 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.
Configure Data Guard broker using DGMGRL
dgmgrl sys/****@
DGMGRL>CREATE CONFIGURATION '
Add Standby database using following command
ADD DATABASE '
Check the configuration using "Show Configuration"
View the configuration using Show Configuration command.
Data Guard Broker properties recommended to use
Setting the configuration protection mode to maximum availability. At any time you can change the protection mode of configuration. Note that
this protection mode requires that there be at least one standby database configured to use standby redo log files, with its LogXptMode configurable
database property set to SYNC on both primary and standby.
DGMGRL>EDIT database
DGMGRL>EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Do not enable FAST_START_FAILOVER as Automatic Failover is not supported
3. Role Transitions
3.1 Switch Over
Verify that the primary and the target standby databases are in the following states - Primary TRANSPORT-ON and Standby APPLY-ON.
On Primary :
DGMGRL> show database dbbrok
Database - dbbrok
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
dbbrok
Database Status:
SUCCESS
On Standy :
DGMGRL> show database stndby
Database - stndby
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Instance(s):
dbbrok
Database Status:
SUCCESS
Issue switch over command
DGMGRL>switchover to
Verify the switchover has been successful
show configuration
Databases:
stndby - Primary database
dbbrok - Physical standby database
To complete the switchover, follow the steps in Section 6 from step 6.1.6
3.2 Switchback
Follow the same steps from the above section , but change the database name to switch over.
For example
DGMGRL> switchover to dbbrok; --> where dbbrok is current standby after a switchover.
3.3 Failover
There are two types of failover using Data Guard Broker
Manual failover
Automatic Failover using FAST START FAILOVER option. (Not Supported for 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"
To complete the failover follow the steps in Section 6 from step 6.2.7
Automatic Failover
Automatic Failover doesn't support with E-Business Suite environment, since you need to run AutoConfig before bringing standby environment online. In this course of time this section will be updated when post failover configurations are automated.
References
NOTE:1070033.1 - Business Continuity for Oracle E-Business Release 12 Using Oracle 11g Physical Standby Database
NOTE:406982.1 - Cloning Oracle Applications Release 12 with Rapid Clone
NOTE:466649.1 - Using Oracle 11g Release 1 (11.1.0.7) Real Application Clusters and Automatic Storage Management with Oracle E-Business Suite Release 12
NOTE:559518.1 - Cloning Oracle E-Business Suite Release 12 RAC-Enabled Systems with Rapid Clone
No comments:
Post a Comment