ERROR
-----------------------
ORA-06508: PL/SQL: could not find program unit being called in Package
OE_Order_PVT Procedure Lines
STEPS
-----------------------
The issue can be reproduced at will with the following steps:
1. Try to Create a sales Order
3.Click on the 'Line Items' tab
-- Error displayed--
BUSINESS IMPACT
-----------------------
The issue has the following business impact:
Due to this issue, users cannot create orders for customers.
Changes
New migartion and schema was refrehsed on week end for go live
Cause
This issue is caused by some packages not being current.
Solution
1. Have your dba recompile/rebuild the ONT schema. This can be completed with the compile_schema utility as follows:
exec dbms_utility.compile_schema('ONT)
OR
2. If specific object is invalid, such as the following seen in output of Diagnostics: Apps Check,
OE_MASS_CHANGE_PVT OEXVMSCB.pls 120.8.12010000.5 BODY INVALID
do in this sequence:
alter package oe_mass_change_pvt compile specification;
alter package oe_mass_change_pvt compile body;
Using Cygwin to Maintain Oracle Applications Release 11i on Windows
November 2010
This document describes how to use Cygwin in place of MKS toolkit to maintain Oracle Applications Release 11i on Windows. It leads you through the process of installing and using Cygwin, whether you are doing a fresh install of 11i or migrating from MKS on an existing system.
Attention
Cygwin is a collection of tools/packages that provide a Linux-like environment for Windows which may be used in lieu of MKS Toolkit for the installation and maintenance of the Oracle E-Business Suite (EBS). Some versions of these packages (outlined below) are the only versions known to work with Oracle Applications Release 11i. Due to the large number of packages and their frequent updates, users may see unforeseen issues with latest versions of these packages as they're released. Please file a Service Request (SR) with Oracle Support outlining the details of the issue for Oracle Development to be notified.
Note
Cygwin is free software, and is not supported unless you purchase a support contract from a third party.
MKS toolkit is required if you are using Discoverer or installing the End User Layer as discussed in document 139516.1, "Using Discoverer 4i with Oracle Applications 11i."
MKS toolkit is also required while using the Oracle Diagnostics shell-based tools.
This document serves as a supplement to "General Requirements for Windows" in the Oracle Applications Installation Update Notes. Please read the Installation Update Notes carefully before proceeding to this document. The most current version of these notes is document 302895.1 on My Oracle Support. It contains the following sections:
Includes all machines running Forms, Web, and other servers. Also called middle tier.
�
Database Tier
Includes machine(s) running Oracle Applications database.
�
CONTEXT_NAME
The CONTEXT_NAME variable specifies the name of theApplications context that is used by AutoConfig. The default is _. For systems installed with Rapid Install 11.5.8 or earlier, the context name will typically be .
�
CONTEXT_FILE
Full path to the Applications context file on the application tier or database tier. The default locations are as follows. Applications context file: /admin/.xml Database context file: /appsutil/.xml
�
Monospace Text
Represents command line text. Type this command exactly as shown.
�
<�>
Text enclosed in angle brackets represents a variable. Substitute a value for the variable text. Do not type the angle brackets.
Section 1: Prerequisites
This section describes software component version requirements that must be met before using Cygwin to maintain Release 11i on Windows. Make any necessary upgrades to an existing or newly installed 11isystem before proceeding.
If you have not yet installed Oracle Applications, perform sections 2, 3 and 5. If you are using MKS Toolkit with an existing Oracle Applications system, perform sections 2, 4 and 5.
The following table shows the versions of particular tools known to work with EBS 11i:
Cygwin Package
Versions
cygwin
1.7.1-1 or higher
make
3.80-1*
bash
3.1.17-6 (from the package version 3.1-9), 3.2.9-11, and 3.2.25-16
*: Note that this version of make requires a separate download and is a downgrade from the latest available make (3.81) which is known to not work with E-Business Suite
An alternative to the 3.80-1 version of the Cygwin make is the utility from MinGW:
MinGW Package
Versions
make
3.81
See Instructions below in Section 2 for downlading and installing this MinGW package
Section 2: Downloading and Installing Cygwin
Conduct the following steps to download and install the Cygwin software.
Step 1 - Log inLog in as a local administrative user (the user who runs the Rapid Install.)
Step 2 - Create a Cygwin directoryCreate the directory where you plan to install Cygwin (called the Root Directory). This directory cannot be under Program Files, or any other directory with blank spaces in its name. In addition, it cannot be under the APPL_TOP.
Step 3 - Download the Cygwin software
Do the following to download the Cygwin software:
Navigate to http://www.cygwin.com and click on "Install or Update Now!" to download setup.exe to your machine.
Run setup.exe and click Next, which will bring up the Choose Installation Type screen.
Choose Option 2, Download without Installing.
Click on Next to go through the next few screens, where you will be asked to choose the directory to store the packages (called the Local Package Directory), your Internet connection type, and a download site.
Click on Next again to get to the Select Packages screen, and select the following packages (click on to toggle):
All Install
Ensure that the 'Hide Obsolete Packages' check box is unselected.
Click on Next again to download the full set of files (required with the latest Cygwin 1.7.1 or higher for use with EBS 11i)
Step 4 - Install CygwinOnce the download is complete, perform the following steps to install Cygwin.
Launch setup.exe again to conduct the install.
From the Choose Installation Type screen, choose Option 3, Install from Local Directory.
Click Next, and specify the Root Directory where you wish to install Cygwin (created in Step 2), and DOS as the Default Text File Type.
Click Next and specify the same Local Package Directory from Step 3.
Click Next to get to the Select Packages screen.
Choose All Install (click on to toggle). Note: Do not choose All Default, since this will not include all the necessary files.
Ensure that the 'Hide Obsolete Packages' check box is unselected.
Click on Next again to conduct the installation.
Step 5 - Verify package versionsVerify that the versions of packages, such as bash and make, are the ones known to work with Oracle Applications Release 11i. See the Attention note at the top of this document for these versions.
To determine the package versions:
C:\> cd [cygwin directory] C:\> uname -a C:\> make --version C:\> bash --version
Note
Depending on how the packages are installed, the Cygwin Installer may display the incorrect package version information. Use the command-line interface to verify the correct package version.
If any of the package versions do not match, perform the following to update the specific package:
Download or build the correct version of the package from one of the following sites:
If these websites are down, use an internet search engine to find similar sites that host the relevant Cygwin packages.
If downloading a version, you must pverwrite the existing version of the package with the new version of the package:C:\> cd [cygwin directory] C:\> tar -xjvf [package download location]\[package name]
Otherwise if you are building from source, copy the gnumake executable built in the previous step to the Cygwin bin directory.
Step 6 - Download and install MinGW make if required If you don't have or are unable to obtain the version of Cygwin make noted above, use the following instructions to obtain the MinGW make (3.81) utility instead:
Scroll down and select the MinGW -> make folder on this web page
Open make-3.81-20090914-mingw32
Copy make-3.81-20090914-mingw32-bin.tar.gz to a location on your local hard drive and extract the files
Copy the file MINGW32-MAKE.EXE executable to the bin subdirectory under your cygwin Home and rename it as gnumake.exe
Step 7 - Add the Cygwin directory to system pathAdd the cygwin bin directory to the system path. For instance:
C:\> set path = %path%;D:\cygwin\bin
Attention
If you use Cygwin with Oracle Applications, use the make utility installed with Cygwin. The system path must contain only the gnumake.exe in the Cygwin bin directory.
Section 3: Using Cygwin for a New 11i Installation
Follow these instructions if you are installing 11i for the first time, and do not have MKS Toolkit installed on your system. Otherwise, go to the next section.
Note
Releases 11.5.10.2 and greater contain the software known to work with Cygwin. If you are installing 11.5.10.2 or greater for the first time, there is no need to perform the software upgrades in Step 3.
Step 1 - Rename Cygwin's rmdir executableIf installing 11i with Cygwin 1.7 for the first time, users are required to rename rmdir.exe to some other name (like rmdir_cygwin_orig.exe) in the Cygwin directory before proceeding with running Rapid Install to ensure that the Windows command shell RMDIR is used instead .
Step 2 - Run the Rapid Install Review Installing Oracle Applications, Oracle Applications Release Notes, and Oracle Applications Installation Update Notes before beginning. Follow the instructions to invoke the Rapid Install wizard and install Oracle Applications 11i. On one of the configuration screens, where you are asked to specify the MKS directory, provide the pathname to the bin directory under the Cygwin Root Directory instead (in this example, "D:\cygwin\bin").
Figure 1: MKS Directory prompt within Rapid Install Wizard.
Step 3 - Verify AD and ADX versions
Verify the minimum required AD and ADX Minipack versions and update the system, if necessary. Refer to the instructions in "Section 1: Prerequisites."
Section 4: Migrating to Cygwin from MKS Toolkit
Follow these instructions if you have both MKS Toolkit and Oracle Applications Release 11i installed on your system, and wish to migrate to Cygwin.
Step 1 - Verify AD and ADX versions
Verify the minimum required AD and ADX Minipack versions and update the system, if necessary. Refer to the instructions in "Section 1: Prerequisites."
Step 2 - Deinstall MKS Toolkit Navigate to the Control Panel, choose Add or Remove Programs, highlight MKS Toolkit, and click Remove.
Step 3 - Modify configuration parameters
Use the Oracle Applications Manager (OAM) AutoConfig utility to edit the MKS Directory (s_mksdir) system configuration parameter to point to the bin directory under the Cygwin Root Directory (see "Modify Configuration Parameters" in Oracle Applications Maintenance Procedures). Change the value of variable s_mksdir from "D:\mksnt" to "D:\cygwin\bin", for example.
Step 4- Run AutoConfig
Run AutoConfig on the application tier:
C:\> cd \admin\scripts\[CONTEXT_NAME] C:\> adautocfg.cmd
Section 5: Testing Cygwin with Release 11i
Perform the following tests to insure that the Cygwin implementation is successful.
Step 1 - Relink FND programs Use AD Administration (adadmin) to relink FND programs, and review the log file for any errors.
Step 2 - Generate graphics files
Use the AD Administration (adadmin) to generate graphics files for any 2 products, and review the log file for errors.
Rapid clone will update the site level profile options only, we need to update instance level profile options manually
2.Update the printer settings
3.Update the workflow configuration settings
Cloning an Oracle Applications instance will not update the host and instance specific information used by Oracle Workflow. Review the following tables and columns to verify there is no instance specific data in the Workflow configuration on the target system.
Important Notes:
a).While running Postclone in appsTier it prompts hostname, we should give like hostname.domainname for example sys10.sample.com
b).While running post clone in appsTier it prompts visual studio directory don\u2019t include bin folder. For example give like c:\vc\VC, don\u2019t give like c:\vc\VC\bin
Sometime if you try to access home page after any maintenance activity, it displays a blank page. This may occure due to jsp/class corruptions in $COMMON_TOP/_pages.
how do we come to know that there is jsp/class corruption ? Enable and Collect Debug for HTTP, OC4J and OPMN in R12 , we may see in: $LOG_HOME/ora/10.1.3/j2ee/oacore/oacore_default_group_1/application.log (for various class files:
Concurrent Managers Fail To Start After New Install of Release
12
Applies to:
Oracle
Applications Technology Stack - Version 12.0 and later Information in this document applies to any
platform. Checked for relevance on 03-Oct-2011
Symptoms
On
12.0.0, after fresh install from Rapidwiz, when attempting to start the
concurrent managers the following error occurs:
ERROR
APP-FND-01564: ORACLE error 12899 in insert_icm_record
Cause: insert_icm_record failed due to ORA-12899: value too large for column
"APPLSYS"."FND_CONCURRENT_PROCESSES"."NODE_NAME"
(actual: 31, maximum: 30)
Cause
The
Host name / machine name is greater than 30 characters
On
UNIX use the following command to identify the host machine name
uname -a
Linux . 2.6.9-42.0.3.ELsmp #1 SMP Mon
Sep 25
17:28:02 EDT 2006 i686 i686 i386 GNU/Linux
If the Host name is more than 30 characters then this issue will occur.
Solution
To
implement the solution, please execute the following steps:
1. The Hostname / Domain name must be less than 30 characters
The limitation is on the table - FND_CONCURRENT_PROCESSES with the column -
NODE_NAME VARCHAR2(30)
1. Minimum Hardware Requirements
- 1.0 GB (1024 MB) of physical RAM
- The following table describes the relationship between installed RAM and
the configured swap space requirement.
RAM Swap Space
===== =============
Between 512 MB and 2048 MB 1.5 times the size of RAM
Between 2049 MB and 8192 MB Equal to the size of RAM
More than 8192 MB 0.75 times the size of RAM
- 400 MB of disk space (and less than 2Tb of disk space) in the /tmp directory.
- between 1.5 GB and 3.5 GB of disk space for the Oracle software, depending on the installation type.
- 1.6 GB of disk space for a preconfigured database that uses file system storage (optional)
2. Install the required OS Packages
Red Hat Enterprise Linux 5 OR Oracle Enterprise Linux 5 with Kernel 2.6.18-8.el5 or higher.
As is specified in section 1.2.2 of the Oracle Database Installation Guide for 11gR1 on Linux (part number B32002-01), Oracle recommends that you install the Linux operating system with the default software packages (RPMs); do not customize the RPMs during installation. For additional information on "default-RPMs", please see Note 376183.1, "Defining a "default RPMs" installation of the RHEL OS"
The exact version number details of this list are based upon 32-bit (x86) RHEL Server 5.0. When a higher "update" level is used, the RPM release numbers (such as 2.2.11-7.1) may be slightly higher (such as 2.2.11-8 or 2.6.12). Since "update 0" and greater of RHEL 5 are certified, this is fine so long as you are still using 32-bit Linux (x86) RHEL Server 5 RPMs.
Other required RPMS's (as per Install Guide, release Notes)
(these get installed during a "Default RPM" installation of the
RHEL 5 OS. Additional RPMs may be needed if a "less-than-default-RPMs" installation of
RHEL 5 is performed. For additional information on "default-RPMs", please see the Metalink NOTE cited above.)
binutils-2.17.50.0.6-2.el5
elfutils-libelf-0.125-3.el5
glibc-2.5-12
glibc-common-2.5-12
libaio-0.3.106
libgcc-4.1.1-52
libstdc++-4.1.1
make-3.81-1.1
* Please note the following :
- RPM's
elfutils-libelf-devel-0.125-3.el5.i386.rpm
elfutils-libelf-devel-static-0.125-3.el5.i386.rpm
are depend upon the other. So they must be installed together in one "rpm-ivh" command
as follows:
% rpm -ivh elfutils-libelf-devel-0.125-3.el5.i386.rpm elfutils-libelf-devel-static-0.125-3.el5.i386.rpm
- RPM "gcc-4.1.1-52" depends on
glibc-devel-2.5-12 (which in turn requires glibc-headers-2.5-12)
libgomp-4.1.1-52.el5.2
Install all these 4 RPM's in one command as follows:
% rpm -ivh glibc-devel-2.5-12.i386.rpm glibc-headers-2.5-12.i386.rpm gcc-4.1.1-52.el5.i386.rpm libgomp-4.1.1-52.el5.i386.rpm
3. Set the Kernel Parameters
- Edit /etc/sysctl.conf file and add the following entries
If the current value for any parameter is higher than the value listed, then do not change the value of that parameter. Range values (such as net.ipv4.ip_local_port_range) must match exactly.
kernel.shmall = physical RAM size / pagesize For most systems, this will be the value 2097152. See Note 301830.1 for more information.
kernel.shmmax = 1/2 of physical RAM, but not greater than 4GB. This would be the value 2147483648 for a system with 4Gb of physical RAM.
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 512 x processes (for example 6815744 for 13312 processes)
net.ipv4.ip_local_port_range = 9000 65500
a.) The runInstaller (OUI) checks may expect this to be the old guidance of "1024 65000". The new guidance from Oracle development is "9000 65500". Please allow the runInstaller (OUI) to proceed with the new guidance from Oracle development.
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
- For the above kernel settings to take effect execute following command
# sysctl -p
4. Verify and make sure that host name has been set by using the hostname command as follows:
# hostname
The output of this command should be similar to the following:
myhost.mycomputer.com
# hostname -i
The output of this command should be IP address of this host
- Add the following lines to the /etc/security/limits.conf file:
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
- Add or edit the following line in the /etc/pam.d/login file
session required /lib/security/pam_limits.so
session required pam_limits.so
- Add the following lines to /etc/profile
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -u 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
7. Create, change ownership, and change permission of the $ORACLE_BASE/../ directory, using the appropriate section of the 11gR1 Install Guide for x86 Linux. Please be careful not to overlook the fact that the default oraInventory location for first-time installs has changed to $ORACLE_BASE/../oraInventory in 11gR1. As is explained in section 2.9.2 of the Oracle Database Installation Guide for 11gR1 on Linux (part number B32002-01), this means that the account used to install the Oracle software must have write permissions from $ORACLE_BASE/../ (aka /mount_point/app/) and downwards. For additional information, please refer to Note 452780.1, "11gR1 OUI Error: 'OUI-10035 OR OUI-10033' "
8. If you are installing Oracle RDBMS 11gR1 software onto either the RHEL 5 or the OEL 5 operating system, please set the Linux feature "SELinux" to "Permissive" mode. This issue is described more fully in Metalink Note 454196.1, "./sqlplus: error on libnnz11.so: cannot restore segment prot after
reloc".
9. Start the Oracle Software installation
- Login as Oracle Software owner
- If the ORACLE_SID, ORACLE_HOME or TNS_ADMIN environment variable is set
then remove/unset them from the environment
- Unset following environment variables (if set)
- LD_LIBRARY_PATH
- Java References (like JAVA_HOME..etc)
- Oracle Home references in $PATH
- set 'umask 0022' and ulimit stack size to 32768
% umask 0022
% ulimit -s 32768
- start the installer from the “database” directory of your 11g installation media
% cd database
% ./runInstaller
ADDITIONAL NOTES
Supported Linux releases of Linux x86 (32-bit) can run on on AMD64/EM64T and Intel Processor Chips that adhere to the x86_64 architecture
Oracle 32-bit running on AMD64/EM64T with 32-bit OS is supported, and is covered by this NOTE.
Oracle 32-bit running on AMD64/EM64T with 64-bit OS is not supported.
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:
ConventionMeaning
Application TierMachines running Forms, Web, Concurrent Processing and other servers. Sometimes called middle tier.
Database TierMachines running Oracle E-Business Suite database.
Primary SystemPrimary Oracle E-Business Suite system, which will used to create a standby system.
Standby SystemOracle E-Business Suite system created as a copy of the production system.
oracleUser account that owns the database file system (database ORACLE_HOME and files).
CONTEXT_NAMEThe CONTEXT_NAME variable specifies the name of the Applications context that is used by AutoConfig. The default is _ .
STNDBY_CONTEXTThe default is _
CONTEXT_FILEFull path to the Applications context file on the application tier or database tier. The default locations are as follows.
Application tier context file: /appl/admin/CONTEXT_NAME.xml
Database tier context file: /appsutil/.xml
APPSpwdOracle E-Business Suite database user password.
Monospace TextRepresents 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 aliasTNS alias to connect to primary database.
Standby TNS AliasTNS 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
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 ComponentMinimum VersionAdditional Information
Oracle E-Business Suite12.0.4 or 12.1.1This 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 applied. For Oracle RAC enabled systems, additional pre-requisite patches listed in My Oracle Support Knowledge were applied.
Oracle Database 11gR111.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 11gR211.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:
DirectoryPurpose
RDBMS_ORACLE_HOMEOracle 11g R1/R2 Database ORACLE_HOME
APPL_TOPDirectory that contains the application product directories and files.
COMMON_TOPDirectory that contains directories and files used across application products
OracleAS 10.1.2 ORACLE_HOMEORACLE_HOME installed by Oracle E-Business Suite on application tier
INST_TOPDirectory 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 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 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 /dbs/_ifile.ora.
Primary database: primary role initialization parameters
Parameters relating to archive destinations and transmission of redo data to the standby system.
ParameterDescription
log_archive_dest_1Archives 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_2When 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_formatUsed to specify the filename format when archiving redo log files. Will use system defaults if not set.
log_archive_min_succeed_destDefines the minimum number of destinations that must succeed in order for the online logfile to be available for reuse.
log_archive_configenables 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_nameUnique Name to identify the primary and standby (For example 'dg12' for primary and 'dg12s' for physical standby).
fal_serverSpecifies 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_clientSpecifies the TNS network service name that the primary database should use to connect to the standby.
standby_file_managementSet 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_convertSpecify 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 DatabasePhysical StandbyOracle RAC PrimaryOracle RAC Standby
Oracle Net Service namedg12dg12sprod
stdby
SIDdg12dg12prod1 and prod2
stdby1 and stdby2
DB_UNIQUE_NAMEdg12dg12sprod
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 = %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 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 __ifile.ora on all nodes in the primary Oracle RAC system. To prevent overwriting of archive logs of different nodes on a shared file system, a specific format must be used for naming the archive logs of each node. The following configuration assumes that prod and stdby are the service names/db_unique_names on the primary and standby respectively.
db_unique_name=prod
log_archive_dest_1='LOCATION=/dbs/arch/prod MANDATORY'
log_archive_dest_2='service=stdby valid_for=(online_logfiles,primary_role) db_unique_name=stdby LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30'
log_archive_dest_state_1 = enable
log_archive_dest_state_2 = enable
fal_server=prod
fal_client=stdby
log_archive_format=prod1_%s_%t_%r.log
db_file_name_convert='',''
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 ( ) size NNN;
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 /plsql/nativelib.
There are three choices for backing up or copying the database to the standby site:
Manual Cold backup
With the database shut down, copy all the database files and redo log files to the standby site.
Manual Hot Backup
With the open, put the tablespace in backup mode, and copy the data files to the standby site.
RMAN
Use the 'duplicate database' command. See Appendix D 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 /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 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 /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 server for 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 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 _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 the standby's _ifile.ora matching the spelling and case in the file name in the last line of the standby server's tns_names.ora file.
In the _ifile.ora, be sure the entry for the standby service's HOST parameter holds the standby database host name and the FAL service's host name is the primary host name.
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 /dbs
$ cp _ifile.ora _ifile.ora
Update the following parameters:
DB_UNIQUE_NAME to a name different from primary : for example dg12s
LOG_ARCHIVE_DEST_2 to point to the standby service. This is required when standby is switched to primary and ships redo to new standby
e.g. LOG_ARCHIVE_DEST_2 for 'service=dg12s ASYNC REGISTER VALID_FOR=(online_logfile,primary_role) DB_UNIQUE_NAME=dg12'
If you are using an spfile, and are 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 = ( / , /)
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= /dbs/init .ora | spfile
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.
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 ' ' size reuse;
[enter as many lines as you have temporary data files]
SQL>shutdown immediate;
SQL>startup mount;
SQL>alter database recover managed standby database disconnect from session;
4.11 Data Guard Broker Configuration (Optional)
If you wish to use Data Guard Broker to manage an 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 and :
If the directory structure on standby is different than the primary then you need to run "perl adcfgclone.pl atTechStack" instead of adclonectx.
$ cd /clone/bin
$ perl adclonectx.pl /appl/admin/.xml
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. manually:
$ 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. /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 /log
$ mkdir -p /out
Repeat this on the primary server, creating directories matching the standby context name, so as to be ready for a switchover operation.
For UNIX systems, on the primary application tier(s), set up an rsync job in cron, to run every few minutes. This example synchronizes the log directory:
$ rsync av < APPLCSF>/log : /log --rsync-path=/usr/local/bin/rsync
Section 6: Role Transitions
A database can operate in either a primary or standby role: these roles are mutually exclusive. Oracle Data Guard enables you to change these roles dynamically by issuing SQL commands, and supports the following transitions:
Switchover Allows the primary database to switch roles with one of its standby databases. There is no data loss during a switchover. After a switchover, each database continues to participate in the Oracle Data Guard configuration with its new role.
Failover Changes a standby database to the primary role in response to a primary database failure.
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.ora | spfile
SQL>alter database mount standby database;
SQL>alter database recover managed standby database disconnect from session;
At this point in the switchover, both databases are standby databases.
6.1.4 Verify the switchover status on the standby server
As the ORACLE user on the standby-to-be-primary database server, verify it is ready to switch to primary:
SQL>select switchover_status from v$database;
This should return a value 'TO PRIMARY'. Any other value, such as SESSIONS ACTIVE, NOT ALLOWED, and so on, should be investigated and corrected as in Step 2 above.
6.1.5 Switch the selected standby database to the primary role
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 _ifile.ora and _ifile.ora files in the directories, change the host name in the standby service definitions to point to the new standby server.
Change the LOG_ARCHIVE_DEST_STATE_2 to enable.
To complete the transition, the database must be shut down and re-started:
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 /appsutil/scripts/
$ ./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 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 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 /dbs/ _ifile.ora. , commenting out the 'defer' line.
log_archive_dest_state_2 = enable
# log_archive_dest_state_2 = defer
6.2.5 Stop redo apply and finish applying all received redo data
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 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 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 /_ifile.ora file for editing.
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 /appsutil/scripts/
$ ./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 SitePrimary Site
Primary DatabaseStandby 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.
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 /appsutil/scripts/
$ 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 .xml"
Refer to My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications Release 12 with Rapid Clone, for further details.
When the script is finished and the context file is created, run the following commands (the perl command is entered on one line):
$ cd $APPL_TOP/ad/12.0.0/bin
$ perl adconfig.pl contextfile= /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 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 /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:
The examples in this section use the following convention where SID is same on both primary and physical standby:
PrimaryPhysical Standby
Oracle Net Service Namedg12dg12s
SIDdg12dg12
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= )
(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= (CONNECT_DATA=(SID=dg12) ) )
Standby LISTENER.ORA file when server is running as standby
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=(PORT=1529))
)
(CONNECT_DATA=(SERVICE_NAME=prod))
)
stdby=
(DESCRIPTION=
(LOAD_BALANCE=NO)
(FAILOVER=YES)
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=tcp)
(HOST=(PORT=1529))
(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:
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 .ora from primary to standby.
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/ 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 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=/appsutil/_.xml template=$ORACLE_HOME/appsutil/template/adxdbctx.tmp pairsfile=/appsutil/clone/pairsfile.txt
Provide the values required for creation of the new Database Context file.
Do you want to use a virtual hostname for the target node (y/n) [n] ?:
Target hostname [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]:
/oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/appsutil/stdby1_rws60001atg.xml
perl adclone.pl java=/appsutil/clone/jre component=dbTechStack mode=apply stage=/appsutil/clone/ method=custom dbctxtg=/appsutil/stdby1_rws60001atg.xml rmanstage=/oradata/MAABCU/RAC12STDBY/backupsets/ rmantgtloc=/oradata/MAABCU/RAC12STDBY/db/apps_st/data/ srcdbname=prod pwd=apps Beginning rdbms home Apply - Fri Mar 12 00:46:03 2010
-e /appsutil/stdby1_rws60001atg.xml
-stage /appsutil/clone/
-rmanstage
/oradata/MAABCU/RAC12STDBY/backupsets/
-rmantgtloc
/oradata/MAABCU/RAC12STDBY/db/apps_st/data/
-srcdbname
prod
APPS Password : apps
Log file located at /appsutil/log/stdby1_rws60001atg/ApplyDBTechStack_03120046.log
Completed Apply...
Fri Mar 12 01:27:09 2010
Beginning APPSDB_stdby1 registration to central inventory...
ORACLE_HOME NAME : APPSDB_stdby1
ORACLE_HOME PATH : /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0
Using Inventory location in /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/oraInst.loc
Log file located at /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0/oraInventory/logs/OracleHomeCloner_03120127.log
ORACLE_HOME /oradata/MAABCU/RAC12STDBY/db/tech_st/11gR2/11.2.0 was registered successfully.
Appendix 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 _ifile.ora to configure net redo transmission , refer creating physical standby non-RAC Section 4
Startup Instance in nomount
sqlplus / as sysdba
startup nomount
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 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 [ /_ifile.ora ]. If you choose the DGMGRL default, then configure as per Option 1 below; if you are using a different static descriptor, then set the DGMGRL StaticConnectIdentifier property, as per Option 2.
Option 1 :
The default option is for the broker to assume the service " _DGMGRL. " has been statically registered 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 = )
)
Option 2 :
Set the primary and standby databases StaticConnectIdentifier property, to a TNS alias that resolves to a statically registered descriptor.
DGMGRL>edit database set property StaticConnectIdentifier='' where dg_prim is TNS alias to connect the Primary
DGMGRL>edit database set property StaticConnectIdentifier='' where dg_stndby is TNS alias 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)))
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 '' AS PRIMARY DATABASE IS '' CONNECT IDENTIFIER IS ;
Add Standby database using following command
ADD DATABASE '' AS CONNECT IDENTIFIER IS ;
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 set property LogXptMode='SYNC'
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
