Professional Documents
Culture Documents
Release 11i
An Oracle White Paper
December 6, 2002
Cloning Oracle Applications, Release 11i
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.
1
• 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.
2
Prepare the target system
Complete the following steps to prepare the target system for cloning.
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
3
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.
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.
Download and apply the latest AD cloning patch (2115451) in pre-install mode
to all APPL_TOPs on 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.
4
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:
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
Argument Description
5
Argument Description
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.
To copy the source system database to the target system, perform the following
steps.
6
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
7
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.
The arguments for the copy command may differ depending upon the
UNIX operating system type.
8
Windows:
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.
1. Verify that the database is started and the Net8 listener allows remote connections to
the database
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>
9
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.
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.
10
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
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.
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.
• Apache Jserv:
Go to http://<apache host>:<apache port>/servlets/IsItWorking
You should see a message reassuring you that Apache JServ is working.
Click on Apps Logon Links, then click on the personal home page link.
11
2. Verify that you can start and use the target system successfully with the source
system shut down.
OTHER CONSIDERATIONS
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.
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
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
12
• 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
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.
13
Cloning Oracle Applications Release 11i
December 2002
Copyright © Oracle Corporation 2001, 2002
All Rights Reserved Printed in the U.S.A.
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.
14