Cloning Oracle Applications Release 11i An Oracle White Paper December 6, 2002

1

Cloning Oracle Applications, Release 11i

This cloning process is for Release 11.5.1 to 11.5.5 non-AutoConfig enabled Oracle Applications systems. Please see the Cloning Oracle Applications FAQ (OracleMetaLink Note 216664.1) to determine the best cloning method for your system.

INTRODUCTION

Cloning is the act of creating an identical copy of an already existing Oracle Applications system.* The new system including component versions, operating system, and platform type must be initially identical to the existing system. There are cases where you can clone from one operating system version to another, if they are binary compatible. For example, if you have an existing single-node Oracle Applications system on Solaris 2.6, you could clone it to a node running Solaris 8, but not to a node running HP-UX. Another example of binary compatibility for the purpose of cloning Oracle Applications 11i is HP-UX 11.0 and HP-UX 11i.

You may want to clone an Applications system for several reasons. Situations that may require cloning include:

• Creating a test system from a recent copy of the production system in order to test patches against before applying to production.

* An Applications system is an implementation of Oracle Applications to serve a specific purpose. Each Applications system has a single Applications database, one or more APPL_TOP file systems, related ORACLE_HOMEs, and all of the required supporting services and installed objects.

2

• Periodically refreshing a test system from a production system in order to keep the test system current.

• Moving an existing system to a different machine.

With the flexible and sophisticated architecture of Oracle Applications Release 11i, simply copying all of the components will not provide you with a working Applications system. For instance, there are numerous configuration files in your file system that must be modified based upon the physical topology. In addition, the Rapid Install installation process utilizes Oracle Universal Installer (OUI), which writes key information about the installation to a binary registry file. When you copy the system to a target location, you invalidate the binary registry file. Consequently, you will not be able to apply patches to the OUI-based components.

In this paper, the system to be cloned is referred to as the source system and the newly created system is referred to as the target system.

This document assumes familiarity with DBA tasks and the Rapid Install.

The Installing Oracle Applications manual provides instructions on running Rapid Install.

CLONING ORACLE APPLICATIONS

Cloning an Oracle Applications Release 11i system involves the following general steps:

• Run Rapid Install.

• Copy the existing database.

• Copy the existing file system (APPL_TOP, JAVA_TOP, and OA_HTML).

• Update the configuration information.

Install the AD cloning utility on the source system

Download and apply patch # 2115451 in pre-install mode to all APPL_TOPs on the source system. This patch contains the AD cloning utility. We recommend backing up the source system Applications files and database before performing the AD cloning process. We also suggest changing the APPS, APPLSYS and APPLSYSPUB passwords to their default values. The Oracle Applications System Administrator’s Guide contains details on the Oracle Applications schema password change utility (FNDCPASS).

Note: The source system APPL_TOP will be copied to the target system later in the cloning process. This copy of the AD cloning utility will be run at that time. Do not run the AD cloning utility against the source system.

3

Prepare the target system

Complete the following steps to prepare the target system for cloning.

1. Run Rapid Install to install a new instance

Use the Rapid Install you originally used to create the source system. For instance, if you originally installed 11.5.4 and applied a subsequent maintenance pack (for example, 11.5.5), run the 11.5.4 Rapid Install. Choose the “Install Oracle Applications” option to install all Oracle Applications components. Identify the name of the target system database and choose to install a “fresh install database”. Create a new configuration file. This file will be used later during the cloning process.

The following options in the target system must match the source system:

• Type of database (that is, if the source system database is a Vision demonstration database, the target system database must be a Vision demonstration database; if the source system database is a fresh install database, the target system database must be a fresh install database.)

• Base language

• Default territory

• APPL_TOP character set

• Server and node configuration (for example, if the source system has two nodes −one node for admin, concurrent processing, and database and the other for forms and web− the target system must be identically configured in two nodes.)

• Platform

The following configuration options for the target system may differ from the source system:

• Port numbers

• Server hostname

• Domain name

• Disk mount points

• Operating system installation account and/or group

• Database name

You may disregard the Product Selection and the Country-specific Functionality screens, as all product and country-specific functionality licensing information are already stored in the database from the source system.

If you are cloning a multi-node Oracle Applications system, install the data server node first. Copy the new configuration file to each node in the target

4

system and run Rapid Install on each of the additional nodes by using the “Read configuration from file” option.

When cloning a multi-node system, repeat the remaining steps in this section on each node in your system.

Note: Platinum 5.1 customers may use the 11.5.5 Rapid Install and Platinum 4.2 customers may use the 11.5.4 Rapid Install, as the technology stacks are identical.

2. Modify user configuration (required for 11.5.1 UNIX users only)

If you are cloning an Applications system originally installed using the Release 11.5.1 Rapid Install on UNIX or Linux and the Applications system was installed with the multi-user option, you need to change the COMMON_TOP file system owner from the oracle user to the applmgr user to conform with the new structure.

Shutdown all services owned by the oracle user on the source system and the target system:

$ cd <COMMON_TOP>/admin/scripts $ adapcctl.sh stop $ adcmctl.sh <APPS_username>/<APPS_password> stop $ adfmcctl.sh stop $ adfmsctl.sh stop $ adfroctl.sh stop $ adrepctl.sh stop $ adalnctl.sh stop APPS_<SID>

Once the services have been shut down, perform the following as the oracle user on both the source system and the target system:

$ cd <COMMON_TOP> $ chown -R <applmgr user> ./util/apache $ cd admin/scripts $ chown <applmgr user> adapcctl.sh adcmctl.sh \ adfmcctl.sh adfmsctl.sh adfroctl.sh adrepctl.sh \ adalnctl.sh

Note: Do not change ownership of all scripts in the directory, as some must remain owned by the oracle user.

3. Install the AD cloning utility on the target system

Download and apply the latest AD cloning patch (2115451) in pre-install mode to all APPL_TOPs on the target system.

4. Preserve Oracle Applications configuration files specific to the target system

To save the target system configuration, log in as the applmgr user on the target system, do not run or execute the Applications environment setup file, and run the AD cloning utility.

Attention: The AD cloning utility is meant to preserve the configuration of the target system and should not be run from the source system.

5

The AD cloning utility is written in the Perl language. Perl is located in the Apache directory of your Applications system (i.e. …/Apache/perl/bin/perl). For release 11.5.1, Apache is located in the COMMON_TOP directory and for later releases it is located in the iAS ORACLE_HOME.

Add the .../perl/bin directory used by Apache to the PATH variable before running the adclone command. Validate this by ensuring the "which" command returns the correct location.

UNIX: $ PATH=<APACHE directory>/perl/bin:${PATH} $ export PATH $ which perl

Windows:

C:\> set PATH=%PATH%<APACHE directory>/perl/bin C:\> which perl

Note: If you updated your system to Apache 1.3.12, verify that the PERL5LIB environment variable is set properly. It should be set to <iAS ORACLE_HOME>/Apache/perl/lib/5.00503: <iAS ORACLE_HOME>/Apache/perl/lib/site_perl/5.005;.

For all users:

Run the AD cloning utility in preclone mode from a temporary directory not located under the APPL_TOP of the target system with the following command: perl <ad_top>/bin/adclone.pl -mode=preclone \ -env_name=<SID> \ -node_name=<hostname> \ -config_file=<config file> \ -ad_top=<ad_top> For example:

perl /d02/apps115/TESTappl/ad/11.5.0/bin/adclone.pl \ -mode=preclone -env_name=TEST -node_name=ap100sun \ -config_file=/d01/apps115/config.txt \ -ad_top=/d02/apps115/TESTappl/ad/11.5.0

The arguments are as follows:

Argument Description

mode The mode of operation. Specify preclone or postclone.

env_name The ORACLE_SID value.

node_name The name of your target system node, excluding the domain name.

config_file Full pathname of the configuration file created by Rapid Install for the target system.

6

Argument Description

ad_top Full pathname of the AD_TOP directory.

The AD cloning utility in preclone mode:

• Shuts down any running services on the current node

• Saves the configuration files from the APPL_TOP

• Saves the configuration files from the COMMON_TOP

• Removes APPL_TOP, JAVA_TOP, and OA_HTML directory contents

If you are cloning a multi-node Applications system, run the AD cloning utility in preclone mode on each of the additional nodes of the target system.

The configuration files are saved to COMMON_TOP/admin/clone. Do not edit these files during the cloning process.

5. Upgrade the database ORACLE_HOME (conditionally required)

If you upgraded the database ORACLE_HOME of the source system to a different version than the one included with Rapid Install, upgrade the database ORACLE_HOME of the target system. For example, if the source system was installed with Rapid Install version 11.5.3, the original version of the database was ORACLE 8.1.6. Since that time you may have upgraded the database to ORACLE 8.1.7. If so, you need to upgrade the database ORACLE_HOME of the target system to match the database ORACLE_HOME of the source system.

Once the database ORACLE_HOME upgrade is complete, update the DBS_ORA816 parameter of the Rapid Install configuration file with the new ORACLE_HOME path. If the new ORACLE_HOME was installed with the Oracle Universal Installer (OUI), and not Rapid Install, create an ORACLE_HOME/appsutil directory and copy the contents from the old ORACLE_HOME/appsutil directory to the newly created one. Then, update ORACLE_HOME/appsutil/install/adupdlib.sql to reflect the new target system ORACLE_HOME location (for releases before 11.5.3, update adupdprf.sql).

6. Remove the database files from the target system

As you will be using copies of the database files from the source system, the database files created by Rapid Install for the target system can be removed.

Use the database server process control script (addbctl.sh) to shutdown the database of the target system.

Delete all of the database files (*.dbf files) from the target system.

7. Copy the source system database

To copy the source system database to the target system, perform the following steps.

7

a) On the source system database, create a list of datafiles and online redo log files of your source system database by issuing an "alter database backup controlfile to trace" command in the source system database. Examine the resultant trace file located in the user_dump_dest directory.

b) Perform a normal shutdown of the source system database.

c) Perform a cold backup of the source system database.

d) Log on to the target system as the oracle user and set the database environment using the database environment file.

The environment file for the database server is located in the database server ORACLE_HOME, and is called <SID>.env (UNIX or Linux) or <SID>.cmd (Windows).

e) Copy the database files to the target system.

Identify the new mount points for the database files and copy the database files from the backup of the source system to the new target system.

f) Verify the target system init.ora parameters.

You may have updated the database initialization file in your source system. Verify that the parameter changes are reflected in the init.ora of your target system. Check all parameters, especially the location of your control files and the names of your rollback segments.

g) Create a new control file.

To create new control files:

• Update the trace file from step a) with SID and mount point information pertinent for the target system and use it to create a control file creation script.

• Start up the target system instance, but do not mount or open the database.

• Create a new control file for the database using the control file creation script. Specify the RESETLOGS option if the database SID was renamed. Otherwise, use the NORESETLOGS option.

See the Oracle8i Administrator's Guide for details on creating control files.

h) Open the database.

If RESETLOGS was specified when creating the control file, use ALTER DATABASE OPEN RESETLOGS, else use ALTER DATABASE OPEN.

i) Reset the database identifier (required for Oracle Recovery Manager users)

If you use Oracle Recovery Manager (RMAN) with Oracle Applications, you must reset the database identifier (DBID) with a unique ID. RMAN requires that each database instance have a unique DBID. As the target

8

system database files are copied directly from the source system, they retain the source system DBID.

The DBID is stored in the generic file header of the control file, datafiles, temp files and online log files. To reset the DBID in all of these locations perform the following steps:

• Cleanly shut down the database

• Start the instance and mount the database, but leave it closed

Attention: Do not perform the following step with the database open

• Delete the existing DBID. Perform this command in SQL*Plus as the SYS user:

SQL> exec sys.dbms_backup_restore.zerodbid(fno => 0);

• A new DBID will be generated when you create a new control file by using the CREATE CONTROLFILE statement

j) Update the GLOBAL_NAME (conditionally required)

If the database name was changed, perform this command in SQL*Plus as the SYSTEM user to change the GLOBAL_NAME in the database:

SQL> alter database rename global_name \ to <new GLOBAL_NAME>

k) Start the Net8 listener and verify that it allows remote connections to the database.

8. Copy the source system files

To copy the source APPL_TOP, OA_HTML, and JAVA_TOP directories to the target system, perform the following steps:

a) Verify that all users have logged off the source system and that all Applications server processes have been shut down.

b) Log on as the applmgr user on the target system.

c) Copy the source APPL_TOP, OA_HTML, and JAVA_TOP.

Copy these directory trees from each node of the source system to each corresponding node of the new target system. If your target system is on the same machine as your source system or the disks are NFS mounted, you can copy an entire directory tree at once.

UNIX:

For example, if your source system APPL_TOP is /d01/apps115/PRODappl: $ cp -r /d01/apps115/PRODappl /d02/apps115/TESTappl The arguments for the copy command may differ depending upon the UNIX operating system type.

9

Windows:

For example, if your source system APPL_TOP is d:\PRODappl: C:\> xcopy /s /e /i d:\PRODappl e:\TESTappl

If the target system is on a separate node, you can zip or tar the source system directories and FTP them to the target system node.

Replace the target system configuration

In the “Prepare the target system” section, the configuration specific to the target system was saved before replacing files with those from the source system. Perform the following steps to re-implement the saved configuration on the target system:

1. Verify that the database is started and the Net8 listener allows remote connections to the database

2. Run the AD cloning utility

Log on as the applmgr user, do not run or execute the Applications environment setup file, and run the AD cloning utility in postclone mode to configure the target system. The AD cloning utility is located in the AD_TOP/bin directory.

Note: The AD cloning utility will prompt you for the SYSTEM and APPS passwords when running in postclone mode.

For all users: perl adclone.pl -mode=postclone -env_name=<SID> -node_name=<hostname> -config_file=<config file> -ad_top=<ad_top>

The AD cloning utility in postclone mode will:

• Configure the database profiles

• Replace the configuration files associated with the APPL_TOP

• Replace the configuration files associated with the COMMON_TOP

• Generate the database security (DBC) file

• Update the interMedia shared library path

• Startup the services for this node

When cloning a multi-node system, repeat the steps in this section on each node in your system.

Perform finishing tasks

This section describes the tasks you may need to perform to complete the cloning process.

10

1. Apply technology stack patches and configuration changes (conditionally required)

If you have applied patches or tuned the parameter settings in the source system for any technology stack components not referred to in this paper, you will need to apply the patches and re-implement the settings in the target system. Common examples of technology stack updates include upgrading Oracle Developer (Forms, Reports, Graphics), upgrading JInitiator, adjusting parameters such as Oracle HTTP Server parameters in the httpd.conf file located in the iAS ORACLE_HOME/Apache/Apache/conf directory, and updating profile options such as the Applications Framework Agent.

2. Modify the web configuration file (conditionally required)

The web configuration file appsweb.cfg exists in two locations on the Applications file system: FND_TOP/resource and OA_HTML/bin. If appsweb.cfg was patched, updated or customized in the source system you must update this file in the target system:

a) Back up appsweb.cfg from FND_TOP/resource and OA_HTML/bin of the target system.

b) Copy appsweb.cfg from FND_TOP/resource and OA_HTML/bin of the source system to the target system.

c) Modify the values in the ENVIRONMENT SPECIFIC PARAMETERS section of the appsweb.cfg of the target system to reflect the values in the backup copy that you created in step a). These parameters should reflect the values for your target system.

3. Update Self-Service parameters (conditionally required)

If you use Internet Explorer and changed the default SESSION_COOKIE_DOMAIN from null to some other value, update the Self-Service parameters directly using SQL*Plus:

sqlplus <APPS username>/<APPS password> SQL> update ICX_PARAMETERS 2> set SESSION_COOKIE_DOMAIN = '<domain>’;

4. Sign the Java archive files

Applications R11i requires that all Java archive (JAR) files used in the client tier be certified using a customer specific digital certificate.

If you plan to use the same digital signature on both the source and target systems, copy the identitydb.obj from the source system to the target system. This file is located in the home directory of the source system’s main Applications user. Copy it to the home directory of the target system’s application user. If a different digital certificate is to be used for the target system, create a new one. Follow the instructions for creating a certificate in the Installing Oracle Applications manual.

11

Whether a new or existing digital certificate is used, run AD Administration (adadmin) to generate product JAR files. When prompted to force regeneration of all jar files, type yes. Perform this step on each node of the target system

5. Relink the f60webmx executable (conditionally required)

If the target system utilizes the HP platform, you need to relink the f60webmx executable. Run AD Administration and choose Relink Applications programs from the Maintain Applications Files menu. See the Maintaining Oracle Applications manual for instructions. After relinking successfully, run 'chatr +s enable f60webmx' to resolve issues with Shared Library path. The f60webmx executable is located in the FND_TOP/bin directory.

6. Relink Applications executables (recommended)

Relinking all of your Applications executables is recommended. Use the relink Applications programs task of AD Administration to relink your Applications executables. Perform this step on each node of the target system

7. Reconfigure Portal (conditionally required)

If you use Oracle Portal, update the configuration by performing step 1.7 (Register Portal and Login Server URLs Using ssodatan) in OracleMetaLink Note 146469.1.

TEST THE TARGET SYSTEM

Perform the following steps to verify the newly created system:

1. Check client tier connectivity.

Use the following URLs:

• Database PL/SQL Cartridge Connection:

With Apache single listener (11.5.2 and later or migrated 11.5.1) Go to http://<apache host>:<apache port>/pls/<dad name>/FND_WEB.PING With WebDB 2.5 (default configuration for 11.5.1) Go to http://<webdb host>:<webdb port>/<dad name>/FND_WEB.PING You should see a table with information about your database.

• Apache Jserv:

Go to http://<apache host>:<apache port>/servlets/IsItWorking You should see a message reassuring you that Apache JServ is working.

• Applications logon and Apache Server:

Go to the Rapid Install portal page: http://<apache host>:<apache port> Click on Apps Logon Links, then click on the personal home page link. Log on to Self-Service Applications as SYSADMIN. Click on the link to the System Administration responsibility. This should bring up forms.

12

2. Verify that you can start and use the target system successfully with the source system shut down.

1. Shutdown the source system

2. Start the target system

3. Carry out login checks on the target system

OTHER CONSIDERATIONS

1. Update patch history database

If you are using the Patch History Database and the target system APPL_TOP name or the target system name is different from the source system, export the patch history database information from the target system and import it using the new target system APPL_TOP name and the target system name. See Migrating Patch History Information in the AD Procedures Guide.

2. Update tables with target system environment information

The following tables and columns may contain references to the source system. If so, update these to reflect the target system configuration:

• WF_NOTIFICATION_ATTRIBUTES.TEXT_VALUE

• WF_ITEM_ATTRIBUTE_VALUES.TEXT_VALUE

• FND_FORM_FUNCTIONS.WEB_HOST_NAME

• FND_FORM_FUNCTIONS.WEB_AGENT_NAME

• FND_FORM_FUNCTIONS.WEB_HTML_CALL

• FND_PROFILE_OPTION_VALUES.PROFILE_OPTION_VALUE

• FND_PRODUCT_GROUPS.APPLICATIONS_SYSTEM_NAME

The following table and columns may contain PATH references to the source system. If so, update these to reflect the target system configuration:

• FND_CONCURRENT_REQUESTS.LOGFILE_NAME

• FND_CONCURRENT_REQUESTS.OUTFILE_NAME

3. Verify target system profile options

The following profile options may references to the source system. If so, update these to reflect the target system configuration:

• WF_NOTIFICATION_ATTRIBUTES

• FND_FORM_FUNCTIONS

• POR_RESUBMIT_URL

• POR_UPDATE_REQ

• ICX_AP_WEB_OPEN_EXP

13

• WF_WEB_AGENT

• POR_SSP_HOME

• POR_SSP_ECMANAGER

• Applications Help Web Agent

• Applications Web Agent

• Apps Servlet Agent

• Help System Base URL

• ICX: Forms Launcher

• ICX: Report Images

• ICX: Report Launcher

• ICX: Report Link

• ICX:Report Cache

• JTF_BIS_OA_HTML

• TCF:HOST

4. Additional product specific steps

There may be additional product specific steps required to complete the cloning process. For example, if you are using Oracle Payroll (US), you may need to re-identify the location of the Quantum data files. See the Implementing Oracle HRMS (US) manual for instructions.

SUMMARY

The method of cloning covered in this white paper is applicable for Oracle Applications Release 11i and is fully supported by Oracle Corporation. We recognize the need to have multiple systems that are identical to the production system. By utilizing the method of cloning outlined in this white paper, you should be able to fulfill the cloning requirement of your enterprise.

14

Cloning Oracle Applications Release 11i

December 2002

Copyright © Oracle Corporation 2001, 2002

All Rights Reserved Printed in the U.S.A.

This document is provided for informational purposes

only and the information herein is subject to change

without notice. Please report any errors herein to

Oracle Corporation. Oracle Corporation does not

provide any warranties covering and specifically

disclaims any liability in connection with this document.

Oracle is a registered trademark and Enabling the

Information Age is a trademark of Oracle Corporation.

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Electronic mail: apps_relgrp_us@oracle.com

FAX: 650.506.1113 Attn: Oracle Applications Release Group

Postal service:

Oracle Corporation

Oracle Applications Release Group

500 Oracle Parkway, M/S 3op4

Redwood Shores, CA 94065

U.S.A.

Copyright © Oracle Corporation 2001, 2002

All Rights Reserved