This document describes the process of using the Oracle E-Business Suite Rapid Clone utility to create a clone (copy) of an Oracle E-Business Suite Release 12.2 system that utilizes the Oracle Database Real Application Clusters (Oracle RAC) feature.The resulting duplicate Oracle E-Business Suite Release 12.2 Oracle RAC environment can then be used for purposes such as:
Note: For cloning procedures in Oracle E-Business Suite environments that do not use Oracle RAC, refer to My Oracle Support Knowledge Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone.
There is a Change Log at the end of this document.In This Document
Note: At present, the procedures described in this document apply to UNIX and Linux platforms only, and are not suitable for Oracle E-Business Suite Release 12.2 RAC-enabled systems running on Windows.
A number of conventions are used in describing the Oracle E-Business Suite architecture:
Section 1: Overview, Prerequisites and Restrictions1.1 OverviewConverting Oracle E-Business Suite Release 12.2 from a single instance database to a multi-node Oracle Real Application Clusters (Oracle RAC) enabled database (described inDocument 1453213.1, Using Oracle 11g Release 2 Real Application Clusters and Automatic Storage Management with Oracle E-Business Suite Release 12.2 and Document 1626606.1,Using Oracle 12c Release 1 (12.1) Real Application Clusters with Oracle E-Business Suite Release R12.2) is a complex and time-consuming process. It is therefore common for many sites to maintain only a single system in which Oracle RAC is enabled with the E-Business Suite environment. Typically, this will be the main production system.In many large enterprises, however, there is often a need to maintain two or more Oracle RAC-enabled environments that are exact copies (or clones) of each other. This may be needed, for example, when undertaking specialized development, testing patches, working with Oracle Support, and other scenarios. It is not advisable to carry out such tasks on a live production system, even if it is the only environment enabled to use Oracle Real Application Clusters. The goal of this document (and the patches mentioned herein) is to provide a rapid, clear-cut, and easily achievable method of cloning an Oracle RAC-enabled E-Business Suite Release 12.2 environment to a new set of machines on which a duplicate Oracle RAC-enabled Oracle E-Business Suite system is to be deployed. This process will be referred to as RAC-To-RAC cloning from here on. 1.1.2 Cluster TerminologyYou should understand the terminology used in a cluster environment. Key terms include the following.
1.3 Prerequisites
1.4 RestrictionsBefore using RapidClone to create a clone of an Oracle E-Business Suite Release 12.2 Oracle RAC-enabled system, you should be aware of the following restrictions and limitations:
Section 2: Configuration Requirements for Source Oracle RAC System2.1 Required AD/TXK Patches
Note: As a general principle, you are strongly encouraged always to be on the latest AD/TXK codelevel. Refer to My Oracle Support Knowledge Document 1583092.1, Oracle E-Business Suite Release 12.2: Suite-Wide Rollup and AD/TXK Delta Information, and apply the most recent delta patches.
To be able to use RAC-to-RAC cloning, you must first be on the codelevel arrived at by application of these patches:
Once all these patches have been applied, proceed to the next steps. 2.2 AutoConfig Setup
2.3 Supported Oracle RAC MigrationThe source Oracle E-Business Suite RAC environment must be created in accordance with Document 1453213.1, Using Oracle 11g Release 2 Real Application Clusters and Automatic Storage Management with Oracle E-Business Suite Release 12.2 and Document 1626606.1, Using Oracle 12c Release 1 (12.1) Real Application Clusters with Oracle E-Business Suite Release R12.2). The RAC-To-RAC cloning process described here has only been validated for use on Oracle E-Business Suite Release 12.2 systems that have been converted to use Oracle RAC as per this document, or installed in Oracle RAC mode via Rapid Install.2.4 AutoConfig Compliance on Oracle RAC NodesAlso in accordance with the Document 1453213.1 and Document 1626606.1, AutoConfig must have been used during Oracle RAC configuration of the source system (following conversion).2.5 Supported Data File Storage MethodsThe storage method used for the source system data files must be one of the following Oracle 11g/12c R1 Oracle RAC Certified types:
2.6 Archive Log ModeThe source system database instances must be in archive log mode, and the archive log files must be located within the shared storage area where the data files are currently stored. This conforms to standard Oracle RAC best practices.
Note: If the source system was not previously in archive log mode, but it has recently been enabled, or if the source system parameter ARCHIVE_LOG_DEST was at some point set to any local disk directory location, you must ensure that RMAN has a properly maintained list of valid archive logs located exclusively in the shared storage area.
To confirm RMAN knows only of your archive logs located on the shared disk storage area, do the following. First, use SQL*Plus or RMAN to show the locations of the archive logs. For example: SQL>archive log listIf the output shows a local disk location, change this location appropriately, and back up or relocate any archive log files to the shared storage area. It will then be necessary to correct the RMAN archive log manifest, as follows: RMAN>crosscheck archivelog all;Review the output archive log file locations and, assuming you have relocated or removed any locally stored archive logs, you will need to correct the invalid or expired archive logs as follows: RMAN>delete expired archivelog all;It is essential to carry out the above steps (if applicable) before you continue with the Oracle E-Business Suite Release 12.2 Oracle RAC cloning procedure. 2.7 Control File LocationThe database instance control files must be located in the shared storage area as well.Section 3: Configuration Requirements for Target Oracle RAC System3.1 User Equivalence between Oracle RAC NodesSet up ssh and rsh user equivalence (that is, without password prompting) between primary and secondary target Oracle RAC nodes. This is described in Oracle Grid Infrastructure Installation Guide 11g Release 2 (11.2), with the required steps being listed in Section E.1.2, "Configuring SSH on All Cluster Nodes". For Oracle Grid Infrastructure 12c Release 1 (12.1), the steps are described in Section F.1.2. "Configuring SSH on All Cluster Nodes" in Oracle Grid Infrastructure Installation Guide 12c Release 1 (12.1).
Note: If the Oracle RAC ORACLE_HOME was installed using Rapid Install, SSH may already have been configured as part of the installation.
Note: SSH connectivity can also be setup automatically during installation. This is described in:
3.2 Install Oracle Grid InfrastructureInstall Oracle Grid Infrastructure and update the version to match that of the source system database. For example, if the original source system database is 11.2.0.3, Oracle Grid Infrastructure must also be patched to the 11.2.0.3 level.
Note: For detailed instructions regarding the installation and usage of Oracle's Clusterware software as it relates to Oracle Real Applications Clusters, see the following articles:
3.3 Verify Shared Mount Points or DisksEnsure that all shared disk sub-systems are fully and properly configured: they need to have adequate space, be writeable by the future oracle software owner, and be accessible from both primary and secondary nodes.
Note: For details on configuring ASM, OCFS2, and NFS with NetApp Filer, refer to the following documents as applicable:
Note: For ASM target deployments, you are strongly advised to install a separate $ORACLE_HOME for ASM management, whatever the location of your ASM listener configuration. It is required to change the default listener configuration via the
netca executable.3.4 Verify Network Layer InterconnectsEnsure that the network layer is properly defined for private, public and VIP (Clusterware) Interconnects. That is,runcluvfy.sh from the Oracle Clusterware software stage area should have executed without error prior to CRS installation.Section 4: Preparing the Source Oracle RAC System for Cloning4.1 Update the File System With Latest Oracle RAC PatchesAs per Section 2 of this document, the latest AD and TXK consolidated update patches, any post-patch steps described in the READMEs, and all prerequisite patches should now have been applied.After application of all these patches, adpreclone.pl must be executed on the primary database node you are going to archive. Use the following command: $ cd $ORACLE_HOME/appsutil/scripts/[context_name]adpreclone.pl, perform the following steps.4.2 Create Database Image
Note: Do not shut down the source system database services to complete the steps on this section. The database must remain mounted and open for the imaging process to successfully complete. RapidClone for Oracle RAC-enabled Oracle E-Business Suite Release 12.2 systems operates differently from single instance cloning.
Log in to the primary Oracle RAC node, navigate to [ORACLE_HOME]/appsutil/clone/bin, and run the adclone.pl utility from a shell as follows:$ perl adclone.pl \
After the stage creation is completed, navigate to [stage]/data/stage. In this directory, you will find several 2GB RMAN backup/image files. These files will have names like "1jj9c44g_1_1". The number of files present will depend on the source system configuration. The files, along with the "backup_controlfile.ctl", will need to be transferred to the target system on which you wish to create your new primary Oracle RAC node. These files should be placed into a temporary holding area, which will ultimately be removed later. 4.3 Archive the ORACLE_HOME
Note: The database can be left open during the ORACLE_HOME archive creation process.
Create an archive of the source system ORACLE_HOME on the primary node:$ cd $ORACLE_HOME/..
Note: Consider using data integrity utilities such as md5sum, sha1sum, or cksum to validate the file sum both before and after transfer to the target system.
It is not required to place the archived home in the target ORACLE_HOME location. You can untar it to the ORACLE_HOME location from a shared location that is accessible to all Oracle RAC nodes.Section 5: RAC-to-RAC Cloning5.1 Target System Primary Node Configuration (Clone Initial Node)Follow the steps below to clone the primary node (i.e. Node 1) to the new target system.5.1.1 Uncompress ORACLE_HOMEUncompress the ORACLE_HOME archive that was transferred from the source system. Choose a suitable location, and rename the extracted top-level directory name to something meaningful on the new target system.$ tar -xvzf rac_db_oh.tgz5.1.2 Create pairsfile.txt File for Primary NodeCreate a [NEW_ORACLE_HOME]/appsutil/clone/pairsfile.txt text file with contents as shown below:s_undo_tablespace=[Source system primary instance undo tablespace name]5.1.3 Create Context File for Primary NodeYou will now execute theadclonectx.pl utility to create a new context file, providing carefully determined answers to the prompts.Navigate to [NEW_ORACLE_HOME]/appsutil/clone/bin and run adclonectx.pl with the following parameters:$ perl adclonectx.pl \
Note: A new and unique global database name (DB name) must be selected when creating the new target system context file. Do not use the source system global database name or sid name during any of the context file interview prompts as shown below.
You will be presented with the following questions [sample answers provided]: Target System Hostname (virtual or normal) [kawasaki]
[Enter appropriate value if not defaulted]Do you want to enable SCAN addresses (y/n) [y] ? : [if y, answer next 2 questions]Target System Port Pool [0-99] : <provide the port_pool>
Note: If cloning to ASM, a full path is needed. For example:
Target System DATA_TOP Directory 1 : +DATA/dbfile/VISIONThis path must be created on the ASM system target manually.
Note: It is critical that the correct values are selected above: if you are uncertain, review the newly-written context file and compare it with values selected during source system migration to RAC (as per My Oracle Support Knowledge Document 1453213.1 for Oracle 11g Release 2 (11.2) RAC or My Oracle Support Knowledge Document 1626606.1 for Oracle 12c Release 1 (12.1) RAC) .
When making comparisons, always ensure that any path differences between the source and target systems are understood and accounted for. 5.1.4 Restore Database on Target System Primary Node
Warning: It is not recommended to clone a E-Business Suite RAC enabled environments to the same host. If the source and target systems must be the same host, ensure the source system is cleanly shut down and the data files moved to a temporarily inaccessible location prior to restoring/recovering the new target system.
Failure to heed this warning could result in corrupt redo logs on the source system. Same host RAC cloning requires the source system to be down.
Warning: In addition to same node RAC cloning, it is also not recommended to attempt cloning E-Business Suite RAC enabled environments to a target system which can directly access source system dbf files (perhaps via an nfs shared mount). If the intended target file system has access to the source dbf files, corruption of redo log files can occur on the source system. It is also possible that corruption might occur if any dbf files exist on the new intended target file system which match the original source mount point [i.e. /xyz/datafiles]. If existing data files on the target are in a file system location as is present on the source server [i.e. /xyz/datafiles], shut down the database that owns these data files.Failure to heed this warning could result in corrupt redo logs on the source system or any existing database on the target host that has a mount point the same as the original (and perhaps unrelated) source system. If unsure, shut down any database that stores data files in a path which existed on the source system and in which data files were stored.
5.1.4.1 Run adclone.pl to Restore and Rename Database on New Target SystemNavigate to [NEW_ORACLE_HOME]/appsutil/clone/bin and run Rapid Clone (adclone.pl utility) with the following parameters:$ perl adclone.pl \
Note: If cloning to ASM, a full PATH is needed. For example:
Target System DATA_TOP Directory 1 : +DATA/dbfile/VISIONThis path must be created on the ASM target system manually. Additionally, the rmantgtloc (rman target location) parameter in adclone.pl command should also have the full path if restoring to ASM.
Note: The directories and mount points selected for the rmanstage and rmantgtloc locations should not contain data files for any other databases. The presence of unrelated data files may result in very lengthy restore operations, and on some systems a potential hang of the adclone.pl restore command.
Running the adclone.pl command may take several hours. You can monitor progress by running the following command from a terminal window:$ tail -f [ORACLE_HOME]/appsutil/log/$CONTEXT_NAME/ApplyDBTier_[time].log
Note: If the database version is 12c Release 1, ensure to add the following line in your sqlnet_ifile.ora after adclone.pl execution completes:
5.1.4.2 Verify TNS Listener has been startedAfter the above process exits, and it has been confirmed that no errors were encountered, you will have a running database and TNS listener, with the new SID name chosen earlier.Execute the following command to confirm that the TNS listener is running and has the appropriate service name format: $ ps -ef | grep tns | awk '{ print $9}'s_db_listener. If it does not, verify the listener.ora file in the $TNS_ADMIN location before continuing with the next steps: the listener must be open and running before AutoConfig is executed.5.1.4.3 Run AutoConfigAt this point, the new database is fully functional. However, to complete the configuration you must navigate to [ORACLE_HOME]/appsutil/scripts/[CONTEXT_NAME] and run AutoConfig with the following command:$ ./adautocfg.sh appspass=[APPS Password]5.2 Target System Secondary Node Configuration (Clone Additional Nodes)Follow the steps below to clone the secondary nodes (for example, Node 2) on to the target system.5.2.1 Add Secondary RAC node information to sqlnet.oraThis is a two-node Oracle RAC example.Go to the primary node and add the secondary node information to the sqlnet.ora file: RAC node 1: host1.example.comFROM:TO:
Note: The
host1 entries should be there after a successful clone.5.2.2 Uncompress archived ORACLE_HOME transferred from Source SystemUncompress the source system ORACLE_HOME archive to a location matching that on your target system primary node. The directory structure should match that present on the newly created target system primary node.$ tar -xvzf rac_db_oh.tgz5.2.3 Archive [ORACLE_HOME]/appsutil directory structure from New Primary NodeLog in to the new target system primary node, and execute the following commands:$ cd [ORACLE_HOME]5.2.4 Copy appsutil_node1.zip to Secondary Target NodeTransfer and then expand the appsutil_node1.zip into the secondary target RAC node [NEW ORACLE_HOME].$ cd [NEW ORACLE_HOME]5.2.5 Update pairsfile.txt for Secondary Target NodeAlter the existing pairsfile.txt (from the first target node) and change the s_undo_tablespace parameter.The [NEW_ORACLE_HOME]/appsutil/clone/pairsfile.txt will look like this example: s_undo_tablespace=[Source system secondary node undo tablespace name]5.2.6 Create Context File for Secondary NodeNavigate to [NEW_ORACLE_HOME]/appsutil/clone/bin and run the adclonectx.pl utility as follows:$ perl adclonectx.pl \
Note: When answering the questions below, review your responses carefully before entering them. The rest of the inputs (not shown) are the same as those encountered during the context file creation on the initial node (primary node).
Host name of the live RAC node : kawasaki
[enter appropriate value if not defaulted]
Target System Base Directory : [Enter the base directory that contains the new_oh_loc dir]
Oracle OS User [oracle] :
Oracle OS Group [dba] :
Target System utl_file_dir Directory List : /usr/tmp [Specify an appropriate location for your requirements]
Number of DATA_TOP's on the Target System [2] : 1 [At present, you can only have one data_top with RAC-To-RAC cloning]
Target System DATA_TOP Directory 1 : +APPS_RAC_DISK [The shared storage location; ASM diskgroup/NetApps NFS mount point/OCFS2 mount point]
Do you want to preserve the Display [null] (y/n) ? : [Respond according to your requirements]
Target System Display [null] : [Respond according to your requirements]
New context path and file name [/s1/atgrac/racdb/appsutil/motoGP1_kawasaki.xml] : [Double-check proposed location, and amend if needed]:
Note: At the conclusion of these "interview" questions related to context file creation, look carefully at the generated context file and ensure that the values contained therein compare to the values entered during context file creation on Node 1. The values should be almost identical, a small but important exception being the local instance name will have a number 2 instead of a 1.
5.2.7 Configure NEW ORACLE_HOMERun the commands below to move to the correct directory and continue the cloning process:$ cd [NEW ORACLE_HOME]/appsutil/clone/bin
Note: If the database version is 12c Release 1, ensure to add the following line in your sqlnet_ifile.ora after adcfgclone.pl execution completes:
5.2.8 Source the new environment file in the ORACLE_HOMERun the commands below to move to the correct directory and source the environment:$ cd [NEW ORACLE_HOME]5.2.9 Modify [SID]_APPS_BASE.oraEdit the [SID]_APPS_BASE.ora file in <NEW ORACLE_HOME>/dbs and change the control file parameter to reflect the correct control file location on the shared storage. This will be the same value as in the [SID]_APPS_BASE.ora on the target system primary node which was just created.5.2.10 Start Oracle RAC DatabaseStart the database using the following commands:$ sqlplus /nolog5.2.11 Execute AutoConfigRun AutoConfig to generate the correct listener.ora and tnsnames.ora files:$ cd $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME5.3 Carry Out Target System (Primary Node) Final Oracle RAC Configuration Tasks5.3.1 Recreate TNSNAMES and LISTENER.ORALog in to the target primary node (Node 1) and run AutoConfig to perform the final Oracle RAC configuration and create new listener.ora and tnsnames.ora. This is needed as the FND_NODES table did not contain the second node hostname until AutoConfig was run on the secondary target RAC node.$ cd $ORACLE_HOME/appsutil/scripts/[CONTEXT_NAME]
Note: This execution of AutoConfig on the primary target Oracle RAC Node 1 will add the second Oracle RAC Node connection information to the first node's tnsnames.ora, such that listener load balancing can occur. If you have more than two nodes in your new target system cluster, you must repeat Sections 4.2 and 4.3 for all subsequent nodes.
Section 6: RAC to Single Instance CloningIt is now possible to clone from a RAC enabled E-Business Suite (source) environment to a Single Instance E-Business Suite (target) environment following nearly the same process detailed above in Section 5.To clone from a RAC source environment to a Single Instance target, the image creation process as noted in Section 4 remains unchanged. On the target host system however, while working through Section 5, the context file creation (step 5.1.3 above) should be done as in the case of Single Instance cloning. All other primary target restore tasks remain the same from Section 5 in the case of Single Instance Restore. Disregard any references to secondary node configuration (starting at step 5.2) as they will not apply here. For example: Target Instance is RAC (y/n) [y] : [Enter n]The Rapid Clone command to restore the database on the target system (Step 5.1.4) remains the same whether the target is Oracle RAC or Single Instance. The final step is to edit the init[sid].ora file and remove the duplicate entries for aq_tm_processes and job_queue_processes (which are set to 0). Ensure you restart the database after you make these changes.
Note: In the Oracle RAC to Single Instance Cloning scenario, no changes are made to the database with regard to undo tablespaces or redo log groups or members. These data structures will therefore be as were present in the source system Oracle RAC database. Optionally, you may decide to reduce the complexity that was carried over from the source Oracle RAC environment to the single instance.
Section 7: Application Tier Cloning for Oracle RACThe target system application tier may be located in any one of the following locations:
7.1 Clone the Application TierTo clone the application tier, follow the standard steps for the application node listed in My Oracle Support Knowledge Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone. The procedure includes adpreclone steps, copying the bits to the target, the configuration portion, and the finishing tasks.
Note: On the application tier, during adcfgclone.pl execution, you will be asked for a database to which the application tier services should connect. Enter the database name (DB_NAME). On successful completion of this step, the application tier services will be started, and you should be able to log in and use the new target system Oracle E-Business Suite system.
7.2 Configure Application Tier JDBC and Listener Load BalancingYou now need to configure the context variables on the application tier nodes to enable database listener and instance load balancing.Implement load balancing for the database connections as follows:
$ cd $ADMIN_SCRIPTS_HOMESection 8: Advanced Cloning Scenarios8.1 Cloning the Database SeparatelyIn certain cases, customers may require the RAC database to be recreated separately, without using the full mechanism employed during a regular E-Business Suite RAC Rapid Clone scenario.This section documents the steps needed to allow for manual creation of the target RAC database control files (or the reuse of existing control files) within the Rapid Clone process. Unless otherwise noted, all commands are specific to the primary target database instance. Follow only Step 1 and Step 2 from the "Standard Cloning Tasks" section of My Oracle Support Knowledge Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, then continue with the steps below to complete Cloning the Database Separately.
8.2 Additional Advanced RAC Cloning ScenariosRapid Clone is only certified for RAC-to-RAC and RAC-to-Single Instance Cloning at present. The addition or removal of Oracle RAC nodes during the cloning process is not currently supported.Appendix A: Configuring Oracle Clusterware on the Target System Database NodesAssociating Target System Oracle RAC Database instances and listeners with Clusterware (CRS)As the oracle user, run the following commands to add the target system database, instances, and listeners to CRS:$ srvctl add database -d [database_name] -o [oracle_home]
Note: For detailed instructions regarding the installation and usage of Oracle Clusterware software as it relates to Oracle Real Applications Clusters, refer to the following documents, as applicable:
|
