| Oracle® Application Server Administrator's Guide 10g Release 3 (10.1.3.2.0) Part Number B32196-01 |
|
|
View PDF |
| Oracle® Application Server Administrator's Guide 10g Release 3 (10.1.3.2.0) Part Number B32196-01 |
|
|
View PDF |
This chapter provides information on cloning an installation of an Oracle Application Server middle-tier instance.
It contains the following topics:
Cloning is the process of copying an existing installation to a different location while preserving its configuration. Some situations in which cloning an installation of Oracle Application Server is useful are:
Creating an installation that is a copy of a production, test, or development installation. Cloning enables you to create a new installation with all patches applied to it in a single step. This is in contrast to separately installing, configuring and applying any patches to Oracle Application Server.
Rapidly deploying an instance and the applications it hosts.
Preparing a "gold" image of a patched home and deploying it to many hosts.
The cloned installation behaves the same as the source installation. For example, the cloned instance can be deinstalled or patched using Oracle Universal Installer. It can also be used as the source for another cloning operation.
You can create a cloned copy of a test, development, or production installation by using the command-line cloning scripts.
The default cloning procedure is adequate for most usage cases. However, you can also customize various aspects of the cloning process, for example, to specify custom port assignments, or preserve custom settings.
Figure 9-1 shows cloning a Oracle WebCenter Framework and Oracle HTTP Server middle tier that is not connected to Oracle Identity Management.
Figure 9-1 Cloning a Oracle WebCenter Framework and Oracle HTTP Server Middle Tier
The cloning process works by copying all files from the source Oracle home to the destination Oracle home. Hence, any files used by the source instance that are located outside the source Oracle home's directory structure are not copied to the destination location.
After the files are copied, a set of scripts is used to update the information in key configuration files. For example, all references to the host name and the Oracle home in httpd.conf are updated to their new values.
Any applications deployed in the source instance are also copied to the cloned instance and automatically deployed, provided they are located in the source Oracle home's directory structure.
In this release, you can clone the following types of middle-tier installations:
Oracle WebCenter Framework
Oracle WebCenter Framework with Oracle HTTP Server
Oracle HTTP Server
See Section 9.5 for details of considerations and limitations affecting specific components in the cloned Oracle home.
Note the following:
You cannot clone an instance that contains Oracle Content DB. However, you can clone an instance that uses Oracle Content DB (in a different instance) as a repository for Oracle WebCenter Framework.
You cannot clone an OracleAS Infrastructure, but you can clone a middle tier that is connected to Oracle Identity Management. However, the cloned instance is not associated with Oracle Identity Management; you must manually associate it with Oracle Identity Management. See Section 6.6, "Configuring Instances to Use 10.1.4 or 10.1.2 Oracle Identity Management" for instructions.
The cloned instance must have a different instance name than the source instance. You specify the instance name when you clone the instance, as described in Section 9.4.3.
You can clone a middle-tier instance that is a member of a cluster, but only if it is based on multicast discovery or static node discovery. See Section 9.4.5 for more information.
The cloning process makes use of the cloning functionality in Oracle Universal Installer. The operation is driven by a set of scripts that are included in the Oracle Application Server installation. The following sections describe the processes involved in cloning an instance:
At the source, you run the script called prepare_clone.pl. This is a Perl script that prepares the source for cloning. It takes a snapshot of the information required for cloning.
During this phase, prepare_clone.pl parses files in the source Oracle home to extract and store required values and backs up required files.
Then, you tar the Oracle home directories.
See Section 9.4.2 for specific instructions for preparing the source instance.
At the destination, you extract the Oracle home from the tar file. Then, you run the script called clone.pl. This is a Perl script that performs all parts of the cloning operation automatically, calling various other utilities and Oracle Universal Installer, as needed. When you invoke the clone.pl script, it goes through the following three phases:
Pre-cloning phase
During this phase, the clone.pl script lays the groundwork necessary to ensure that cloning can be done.
Cloning phase
During this phase, the clone.pl script invokes Oracle Universal Installer in clone mode with the necessary arguments to perform the Oracle Universal Installer home cloning. This re-instantiates all files (after creating backups of the existing instantiated files), sets environment variables, updates links, and so on. In other words, it repeats all actions that were performed at installation time, with the exception of the file copying.
Post-cloning phase
The postinstallation configuration assistants are not designed to be run again at clone time. Consequently, some of the instance-specific configuration files that should be updated by the configuration assistants are not updated at the end of the Oracle Universal Installer cloning session. Instead, Oracle has created a set of post-cloning scripts that update those files to bring the cloned home to a working state.
The post-cloning steps performed by the script are:
Sets the new Oracle home.
Updates configuration files. In this step, many configuration files that have been re-instantiated by Oracle Universal Installer during the cloning phase are restored from their backups. Those files are then updated with the new values that reflect the new environment, if needed. For example, if a file has a reference to the source Oracle home, that reference is updated to reflect the destination Oracle home.
Calls the home's chgiphost command to change the host name and IP number information in the cloned home. Before calling chgiphost, the script must collect the following required information to invoke chgiphost in silent mode:
Source host name
Source IP address
Destination host name
Destination IP address
Note that when chgiphost is run as part of cloning, it does not run all of the configuration tools that are run when chgiphost is run standalone (as when you change hostname or domain name).
If the source instance is connected to Oracle Internet Directory, adds information about the clone to Oracle Internet Directory.
After all the operations for cloning are completed, starts services, as well as the Application Server Control Console, to verify the success of the cloning operation.
Note that you do not need to perform each of these phases manually, because the clone.pl script takes care of all three phases automatically. The information is provided only for conceptual understanding.
See Section 9.4.3 for specific instructions on the tasks you do at the destination.
Files Updated During the Post-Cloning Phase
During the post-cloning phase, a set of important configuration files are restored from their backup versions and updated. Typical changes made to the files include updating environment-specific variables such as host name, Oracle home, and port numbers to their new values.
The following list shows some of the key files that are updated. Note that this is not an exhaustive list of the files being updated.
Oracle_Home/sysman/j2ee/application-deployments/ascontrol/orion-web.xml
Oracle_Home/backup_restore/config/config_misc_files.inp
The format of the paths are shown in UNIX format. For Windows, invert the slashes.
To clone an Oracle Application Server instance, you copy the scripts from the Companion CD. Then, you first prepare the source Oracle home and then you clone the destination.
For cloning, Perl 5.83 or higher must be installed on your system. Before running the cloning Perl scripts, you must set the PERL5LIB environment variable to the path of the Perl directory in the Oracle home. This path must be the first one listed in the variable definition. For example:
On UNIX
export PERL5LIB=$ORACLE_HOME/perl/lib/5.8.3/i686-linux-thread-multi:$ORACLE_HOME/perl/lib/5.8.3:$ORACLE_HOME/perl/lib/site_perl/5.8.3/i686-linux-thread-multi/
On Windows:
set PERl5LIB=%ORACLE_HOME%\perl\5.8.3\lib;%ORACLE_HOME%\perl\5.8.3\lib\MSWin32-x86-multi-thread;%ORACLE_HOME%\perl\site\5.6.1\lib;%ORACLE_HOME%\perl\site\5.8.3\lib
To prepare the source Oracle home to be cloned, take the following steps at the source instance:
Change to the following directory:
(UNIX) ORACLE_HOME/clone/bin (Windows) ORACLE_HOME\clone\bin
Run the script prepare_clone.pl. This script prepares the source to be cloned.
The command line for the script has the following format:
perl prepare_clone.pl [ORACLE_HOME=OH_dir] [-silent] [-debug] [-export] [-help]
In the example, substitute the following for perl:
On UNIX:
$ORACLE_HOME/perl/bin/perl
On Windows:
%ORACLE_HOME%\perl\5.8.3\bin\MSWin32-x86-multi-thread\perl5.8.3
Table 9-1 describes the parameters and options for the prepare_clone.pl script.
Table 9-1 Parameters and Options for the prepare_clone.pl Script
| Parameter or Option | Description |
|---|---|
|
ORACLE_HOME |
The complete directory specification for the source Oracle home. If you do not supply this parameter, the script uses the ORACLE_HOME environment variable, if it exists. If the environment variable does not exist, the script assumes that ORACLE_HOME is the directory from which the script is being run. Do not use a trailing slash (UNIX) or backslash (Windows) when specifying the Oracle home. Use the value that was provided during installation; do not use symbolic links. If ORACLE_HOME is invalid, the script exits and logs an error to standard output (STDOUT). |
|
-silent |
Runs the script in silent mode. If the command line does not contain the required password-related options, the script exits. |
|
-debug |
Runs the script in debug mode. |
|
-export |
Exports the page customizations and portlet metadata that are stored in MDS on the source instance to an .ear file. Also exports the portlet customizations (preferences) to the .ear file. Use this option to migrate customizations that are associated to a WebCenter application from one location to another if the cloned instance will use a different MDS location. This option calls the export mode of the Oracle WebCenter Framework Predeployment tool. For more information about the Predeployment tool, see "Deploying Your WebCenter Application" in the Oracle WebCenter Framework Developer's Guide. The script creates an .ear file with the suffix (UNIX) ORACLE_HOME/j2ee/instance/applications/app_name/app_name_clone_export.ear (Windows) ORACLE_HOME\j2ee\instance\applications\app_name\app_name_clone_export.ear |
|
-help |
Prints the usage for the script. |
Archive and compress the source Oracle home, using your preferred tool for archiving. For example, you can use WinZip on Windows and tar and gzip on UNIX. Make sure that the tool you are using preserves the permissions and timestamps of the files. The following example shows how to archive and compress the source on UNIX:
cd Source_Oracle_Home
tar cf - * | gzip > oracleas.tar.gz
The tar utility may issue warnings if the sticky bit is set on some files. You can safely ignore these warnings.
Note that you should not use the jar utility to archive and compress the Oracle home.
At the destination, to clone the source instance, take the following steps:
Copy the compressed Oracle home from the source machine to the destination machine.
Extract the compressed Oracle home into a directory, which will become the new Oracle home at the destination location. Use your preferred tool to extract the compressed files. For example, you can use WinZip on Windows and tar and gunzip on UNIX. Make sure that the tool you are using preserves the permissions and timestamps of the files. The following example shows how to extract the files on UNIX:
mkdir -p Destination_Oracle_Home cd Destination_Oracle_Home gunzip < Dir_Containing_Tar/oracleas.tar.gz | tar xf -
Note:
Make sure that the tar and gzip/gunzip versions on the source and destination machines are compatible. You may encounter problems unzipping the archive if these versions differ.Change to the following directory:
(UNIX) ORACLE_HOME/clone/bin (Windows) ORACLE_HOME\clone\bin
Run the clone.pl script. You must have write permission to the directory containing the Oracle inventory file. (See Section 9.4.4 for information about the location of the Oracle inventory directory.)
The command line for the script has the following format:
perl clone.pl ORACLE_HOME=OH_dir ORACLE_HOME_NAME=OH_Name -instance Instance_Name {-oc4jadmin_old_password old_admin_pass | -oc4jadmin_obf_old_password old_obf_admin_pass} {-oc4jadmin_new_password new_admin_pass | -oc4jadmin_obf_new_password new_obf_admin_pass} [-Ostring] [-silent] [-debug] [-import] [-help]
In the example, substitute the following for perl:
On UNIX:
$ORACLE_HOME/perl/bin/perl
On Windows:
%ORACLE_HOME%\perl\5.8.3\bin\MSWin32-x86-multi-thread\perl5.8.3
Table 9-2 describes the parameters and options for the clone.pl script.
Table 9-2 Parameters and Options for the clone.pl Script
| Parameter or Option | Description |
|---|---|
|
ORACLE_HOME |
Required. The complete directory specification for the destination Oracle home. This parameter is required. If you do not supply this parameter, or if the value is invalid, the script exits. Do not use a trailing slash (UNIX) or backslash (Windows) when specifying the Oracle home. |
|
ORACLE_HOME_NAME |
Required. The name for the destination Oracle home (the Oracle home of the clone.) |
|
-instance |
Required. The instance name for the clone. The instance name must be different from the source instance and any other instances that use the same OracleAS Infrastructure or that are part of the same cluster topology. |
|
-oc4jadmin_old_password |
Required if -oc4jadmin_obf_old_password is not used. The administrator |
|
-oc4jadmin_obf_old_password |
Required if -oc4jadmin_old_password is not used. The obfuscated administrator |
|
-oc4jadmin_new_password |
Required if -oc4jadmin_obf_new_password is not used. A new password for the administrator This password is used for the default OC4J instance, not for any other OC4J instances. See Section 9.5.3 for more information. |
|
-oc4jadmin_obf_new_password |
Required if -oc4jadmin_new_password is not used. A new obfuscated password for the administrator This password is used for the default OC4J instance, not for any other OC4J instances. See Section 9.5.3 for more information. |
|
-O |
Specifies that any text following the option is passed to the Oracle Universal Installer command line. For example, you can use this option to pass the location of the '-O-paramFile C:\OraHome_1\oui\oraparam.ini' Note that if the text you want to pass contains spaces or other delimiting characters, you must enclose the option in double quotation marks ("). To pass multiple parameters to Oracle Universal Installer using this option, you can either pass all parameters with a single -O option or pass individual parameters using multiple -O options. |
|
-silent |
Runs the script in silent mode. If the command line does not contain the required password-related options, the script exits. |
|
-debug |
Runs the script in debug mode. |
|
-import |
Imports the page customizations and portlet metadata that are stored in MDS on the source instance to cloned instance. Also imports the portlet customizations (preferences). It imports the customizations from the .ear file generated by the -export option on the prepare_clone.pl command line. Use this option to migrate customizations that are associated to a WebCenter application from one location to another if the new instance will use a different MDS location. This option calls the import mode of the Oracle WebCenter Framework Predeployment tool. For more information about the Predeployment tool, see "Deploying Your WebCenter Application" in the Oracle WebCenter Framework Developer's Guide. The script imports the ear file created by the |
|
-help |
Prints the usage for the script. |
For example:
perl clone.pl ORACLE_HOME=/scratch/oracle/Ora_10131_B
ORACLE_HOME_NAME=OH_10131_B
-instance orcl_B
-oc4jadmin_old_password my_old_admin_pass
-oc4jadmin_new_password my_new_admin_pass
'-O-paramFile /var/opt/oracle/oui/oraparam.ini'
-import
-silent
If the source instance contains deployed WebCenter applications, the cloning script asks whether you want to use the same MDS location or a different location.
For example, if you are moving from a test environment to a production environment, you can specify a new MDS location. However, if you are expanding your environment by adding a new instance, Oracle recommends that you use the same MDS as the source instance.
Specified mds path is mds_path. Do you want to keep the original settings [n|y] [y]:
To use the same MDS location, specify y.
To use a different MDS location, specify n. Then at the prompt, enter the new location. Note that you must specify an absolute path and that the location of the MDS must be accessible. That is, the user must have read and write permission.
If you specify an incorrect location, you can change the location after the cloning operation is complete. Change the location in the adf-config.xml file, which is located in the following directory:
ORACLE_HOME/j2ee/OC4J_Instance/applications/apps_name/adf/META-INF
In the directory specification, OC4J_instance is the name of the OC4J instance, and apps_name is the name of the applications.
If the source instance is a member of a multicast dynamic node discovery or static node discovery cluster, the script asks whether or not you want to keep the original cluster settings. See Section 9.4.5 for more details.
On UNIX, run the root.sh script in the Oracle home so that the cloned instance works properly. You must be logged in as the root user to run the script. The script is located in the cloned instance's Oracle home directory.
For example:
$ORACLE_HOME/root.sh
On UNIX, if this is the first Oracle installation on the computer, you must run the orainstRoot.sh script as the root user to register the Oracle Inventory directory. The script in located in the oraInventory directory.
The following file contains the location of the oraInventory directory:
ORACLE_HOME/clone/logs/clonetimestamp.log
If you are using a new MDS location, redeploy your applications on the cloned instance using Application Server Control Console. See "Deploying Your WebCenter Application" in the Oracle WebCenter Framework Developer's Guide for information on deploying WebCenter applications.
If the cloned instance is not using the same MDS location and it contains WebCenter applications, see "Using Cloning to Move from Stage to Production" in the Oracle WebCenter Framework Developer's Guide for additional steps.
Restart the cloned instance:
On UNIX systems:
ORACLE_HOME/opmn/bin/opmnctl stopall ORACLE_HOME/opmn/bin/opmnctl startall
On Windows systems:
ORACLE_HOME\opmn\bin\opmnctl stopall ORACLE_HOME\opmn\bin\opmnctl startall
Now, the cloned instance's configuration is identical to that of the source instance. Application Server Control Console and OPMN are able to start and stop all processes in the cloned instance, including any OC4J custom instances. All applications deployed should be visible and able to run as expected.
The cloning script invokes multiple tools, each of which generates its own log files. However, the following log files, which are generated by Oracle Universal Installer and the cloning scripts, are the key ones of interest for diagnostic purposes:
Oracle_inventory/logs/cloneActionstimestamp.log: Contains a detailed log of the actions that occur during the Oracle Universal Installer part of the cloning.
Oracle_inventory/logs/oraInstalltimestamp.err: Contains information about errors that occur when Oracle Universal Installer is running.
Oracle_inventory/logs/oraInstalltimestamp.out: Contains other miscellaneous messages generated by Oracle Universal Installer.
Oracle_Home/clone/logs/clonetimestamp.log: Contains a detailed log of the actions that occur during the precloning and cloning operations.
Oracle_Home/clone/logs/errortimestamp.log: Contains information about errors that occur during the precloning and cloning operations. In addition, it contains all messages written to standard error (STDERR) by the multiple tools that are invoked by the cloning script. Depending upon the tool, some of these messages may be informational messages or error messages.
The format of the path is shown in UNIX format. For Windows, invert the slashes.
Note:
The following file contains the location of the Oracle Inventory directory:Oracle_Home/clone/logs/clonetimestamp.log
For example:
Wed Jul 5 09:42:51 2006 INFO: Please check /scratch/oracleas/oraInventory/logs/cloneActions2006-07-05_09-38-30AM.log for more details.
On Windows systems, the location can be obtained from the registry: HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\INST_LOC
After the clone.pl script finishes running, consult these log files to get more information about the cloning process. To view the log files from Application Server Control Console, take the following steps:
Select Logs from the Home page.
In the View Logs page, select ASClone from the Available Components box. Click Move to move the selection to the Selected Components box.
Click Search.
The log files are displayed in the Results table.
To view the log, click the log name in the Log File column.
You can clone a middle-tier instance that is a member of a cluster, but only if it is based on multicast dynamic node discovery or static node discovery. In these cases, the cloning script asks whether or not you want to keep the original cluster settings. For example:
cluster Config:<Multi Casting>detected for Source Instance:Do you want to keep the original cluster settings(n|y)[y]:
If you respond y, the cloned instance will be part of the same cluster as the source instance.
If you respond n, the cloning script prompts you for a new IP address and port for the cluster. The type of cluster is preserved. For example, if the source instance is a member of a dynamic node discovery cluster and you respond n, you are prompted to enter a new multicast discovery IP address and port. You cannot change the cluster type to a different type, such as a static node discovery cluster, during the cloning procedure.
You cannot clone an instance that is a member of a cluster based on a cross-topology gateway or manual node-to-node configuration. You must remove them from the cluster first.
The following sections provide details of considerations and limitations affecting cloning in general and specific components in the cloned Oracle home:
For this release, you cannot clone the following:
OracleAS Infrastructure components (Oracle Identity Management and OracleAS Metadata Repository)
Oracle Content DB
Note the following important additional considerations about cloning:
The user may need to update the security certificates to match the new host name and to set up the certificates. See Chapter 11 for information about managing wallets and certificates.
You can clone an Oracle Application Server middle tier that is connected to Oracle Identity Management. However, the cloned middle-tier instance will not be associated with Oracle Identity Management. You must manually associate the cloned middle tier instance to Oracle Identity Management. To associate the middle tier with Oracle Identity Management, see Section 6.6, "Configuring Instances to Use 10.1.4 or 10.1.2 Oracle Identity Management" for instructions.
If you have changed the default file permissions for configuration files, those file permissions are not preserved by cloning.
User customizations for the following components are not preserved. The status of these components are reset to the default:
Cloning does not carry over all the dependencies of the source Oracle home, such as loadable modules or application-specific libraries to the cloned home, because cloning proceeds by copying the entire source Oracle home to the destination Oracle home. Any files outside the source Oracle home are not automatically copied. Hence, any applications that refer to files outside the source Oracle home may not work properly in the cloned home.
You may need to copy the files manually to the destination host after extracting the archived source Oracle home, but before running the clone.pl script.
If you created symbolic links to files or applications outside the source Oracle home (for example, to Oracle Wallet files that are not stored in the default location), you must re-create the link manually in the cloned home for your applications to work properly.
The cloning operation generates default ports for the cloned instance. To specify other ports, you can use the staticports.ini file as described in Section 9.6.2. If you specify ports less than 1024 on UNIX, the cloned instance will not start during the cloning operation. After the cloning process is completed, you must run the root.sh script with root privileges, then start the processes.
The cloning process does not configure a Load Balancing Router to recognize the cloned instance. If you use a Load Balancing Router in your environment, you must manually configure the Load Balancing Router, including any invalidation port.
If a cloning operation fails, but it results in the Oracle home being registered with Oracle Inventory, you cannot use the same Oracle home in subsequent cloning operations. Either use another directory and name for the Oracle home in subsequent cloning operations or deinstall the Oracle home before attempting another cloning operation.
The following describes important information about cloning Oracle HTTP Server:
All configuration information in the following files is updated:
The format of the paths are shown in UNIX format. For Windows, invert the slashes.
The cloning script preserves the source settings and updates these files with new environment parameters.
Note that cloning only updates the files it knows about, that is, files that are part of the original installation. In particular, cloning does not update configuration files that the user added to the "include" list in files such as httpd.conf, oracle_apache.conf, dads.conf, plsql.conf, olap.conf, or moddav.conf. You can, however, explicitly add the "include" files to the list of files that cloning will update. See Section 9.6.3 for details on how to update custom settings.
Cloning preserves all VirtualHost directives in httpd.conf. It replaces any references to the source home inside these directives. However, cloning does not change the IP numbers or port numbers that these virtual hosts listen to.
If these values are not valid for the destination environment, then you must do one of the following:
Register these changes with the clone script to be updated during cloning. See Section 9.6.3 for more information.
Update them manually in httpd.conf after cloning.
If you changed the port number in httpd.conf to use the Load Balancing Router port rather than the local Oracle HTTP Server port, that change is lost after cloning. You must edit the httpd.conf file in the cloned home to change the port number to the Load Balancing Router port.
Cloning is not supported if you are using Oracle HTTP Server based on Apache 1.3 or Apache 2.0. (These are not installed by default, but are included in the companion CD-ROM.)
This following lists considerations in cloning OC4J:
On the source Oracle home during the prepare phase of the cloning process, do not attempt to undeploy OC4J applications or perform other administrative work for OC4J applications while the prepare_clone.pl script is running.
You must manually register files that contain environment-specific information in custom OC4J instances so that those files are updated during cloning. An example of such a file is oc4j.properties. See Section 9.3 for details.
If the OC4J instance uses an Oracle HTTP Server instance that is not part of the source Oracle home, the cloning procedure does not update the mod_oc4j.conf file for the Oracle HTTP Server. You must manually add the instance to the mod_oc4j.conf file.
During cloning, you specify a password for the default OC4J instance. If the source instance contains OC4J instances other than the default, the OC4J instances in the cloned instance will use the same password as those in the source. That is, they will not use the password specified for the default OC4J instance. You can change the password using Application Server Control Console.
Note that each OC4J instance in a group must have the same oc4jadmin password. See Section 2.3.3.2, "Using Application Server Control to Manage Groups" for more information.
OPMN can manage all cloned default and custom OC4J instances.
Grid Control Console on the cloned instance can manage default and custom OC4J instances.
The following describes which OC4J components are preserved:
All default OC4J instances are preserved.
Custom OC4J instances that you created, as well as applications deployed in them, are preserved. However, external dependencies for these applications that are not in the Oracle home are not copied to the cloned home and will be lost.
User configurations in jms.xml, java2.policy, jazn.xml, jazn-data.xml, global-web-application.xml, and application.xml are preserved.
Note the following considerations for cloning Application Server Control Console:
If the source instance contains its own Application Server Control, the cloned instance will contain its own Application Server Control, which will manage the cloned instance.
If the source instance is managed by an Application Server Control that is deployed in a different Oracle home, the cloned instance will be managed by the same Application Server Control.
The SSL settings of the source instance are preserved, by preserving the default-web-site.xml file. In other words, if the source Application Server Control Console was configured for HTTPS, then the cloned Application Server Control Console will be as well.
Note the following considerations for cloning Oracle WebCenter Framework:
If the Oracle Metadata Services (MDS) location used by WebCenter applications is not located within the Oracle home, the cloned instance cannot use the MDS location unless it is on a shared drive.
If the source instance contains deployed WebCenter applications, the cloning script asks whether you want to use the same MDS location or a different location.
For example, if you are moving from a test environment to a production environment, you can specify a new MDS location. However, if you are expanding your environment by adding a new instance, Oracle recommends that you use the same MDS location as the source instance.
To copy customizations, such as those made to the Producers of a deployed application, on the source instance to a new MDS location, use the -export option on the prepare_clone command line and the -import option on the clone command line. See Section 9.4.3.
For more information about cloning and Oracle WebCenter Framework, see the section "Cloning WebCenter Applications" in the Oracle WebCenter Framework Developer's Guide.
The default cloning process is adequate for most cases. However, you can customize some aspects of the cloning process by performing manual configuration steps, as described in the following sections:
Oracle Application Server Administrator's Guide
When cloning an instance, you do not directly invoke Oracle Universal Installer. However, you can still pass information to Oracle Universal Installer indirectly, by specifying any Oracle Universal Installer parameters that you normally specify on the command line in the configuration file cs.properties. This file is located in the following directory:
(UNIX) ORACLE_HOME/clone/ias/config (Windows) ORACLE_HOME\clone\ias\config
For example, to specify a nondefault location for the Oracle inventory file on UNIX, you can add the following line to the cs.properties file:
clone_command_line= -invptrloc /private/oracle/oraInst.loc
To specify multiple arguments, append the argument to the clone_command_line, separating each argument with a space. Do not add additional clone_command_line lines. The following example shows how to specify two arguments, on Linux:
clone_command_line= -silent -invptrloc /private/oracle/oraInst.loc oracle.as.j2ee.top:szl_PortListSelect="{YES,/tmp/staticports.ini}"
In addition, you can specify information to be passed to the Oracle Universal Installer command line by using the -Ostring option. For example, you can use this option to pass the location of the oraparam.ini file to be used by Oracle Universal Installer, by using the following code:
'-O-paramFile C:\OraHome_1\oui\oraparam.ini'
By default, the cloning script automatically assigns free ports to the components. The algorithm for assigning default ports when cloning is the same as that used when installing Oracle Application Server.
When installing a new Oracle Application Server instance, you can specify the ports to be used by listing them in a staticports.ini file. Then, this file is passed as the value of a parameter when calling Oracle Universal Installer. For more information on how ports are assigned and on using the staticports.ini file, please refer to the Oracle Application Server Installation Guide for your platform.
When cloning an instance, you do not directly invoke Oracle Universal Installer. Hence, you cannot assign custom ports by specifying a staticports.ini file on the command line. However, you can still pass port information to Oracle Universal Installer indirectly, by specifying the location of the staticports.ini file in the following configuration file:
(UNIX) ORACLE_HOME/clone/ias/config/cs.properties (Windows) ORACLE_HOME\clone\ias\config\cs.properties
For example, if you want to use ports less than 1024, you can specify them in the staticports.ini file and specify the location of the staticports.ini file in the cs.properties file.
To assign custom ports during cloning:
List the port numbers in the staticports.ini file, as explained in the Oracle Application Server Installation Guide for your platform.
Specify the location of the staticports.ini file by adding the information to the clone_command_line in the cs.properties file. For example, on Linux:
clone_command_line= -silent oracle.as.j2ee.top:szl_PortListSelect="{YES,/tmp/staticports.ini}"
The ports listed in the staticports.ini file are read during cloning, and Oracle Universal Installer assigns the port numbers accordingly.
If you specify ports less than 1024 on UNIX, the cloned instance will not start during the cloning operation. After the cloning process is completed, you must run the root.sh script with root privileges, then start the processes.
Note:
By default, Oracle Universal Installer saves all user input at installation and uses it to automate the actions when cloning. As a result, if you used astaticports.ini file to install the source instance, Oracle Universal Installer will, by default, use the same staticports.ini file. This happens even if you do not specify a staticports.ini file when you clone the instance. To override this behavior and let Oracle Universal Installer generate new ports, use the following line to the cs.properties file:
oracle.as.j2ee.top:szl_PortListSelect="{\"NO\", \"\"}"
By default, the cloning scripts update key configuration files in the Oracle home so that they contain the correct information for the destination environment. Section 9.4.3 contains a partial listing of the files that are updated.
You can modify the default cloning process to update custom data that is not updated by default. Information about which files to update during cloning and which entries to update in those files is contained in another set of files, which are read by the cloning scripts. By editing these files, you can:
Preserve changes you have made to files present in the source Oracle home that are not updated by default during cloning
Preserve changes you have made to files that are updated by default during cloning, but which are not normally preserved by the cloning process
These changes are made by a Java utility called FileFixer, which searches for specific text strings in a file by matching regular expressions, and updates them to their new values. Note that FileFixer searches for patterns one line at a time. It cannot match patterns across lines.
The changes that you can make include the following:
Change the host name in a file.
To do this, for the file in which the host name needs to be changed, add the path name for the file, relative to the Oracle home, to the following file:
(UNIX) ORACLE_HOME/chgip/config/hostname.lst (Windows) ORACLE_HOME\chgip\config\hostname.lst
Update all occurrences of the Oracle home in a file from the old to the new value.
To do this, add a replace element tag in the XML configuration file, fixup_script.xml.tmpl. This file is located in the following directory:
(UNIX) ORACLE_HOME/clone/ias/config (Windows) ORACLE_HOME\clone\ias\config
The value of the file_name attribute specifies the name and location of the file in which the replacement should occur. For example, the following tag updates the Oracle home value in the file server.xml.
<cfw:operation>
<replace file_name="%NEW_HOME%/j2ee/home/config/server.xml">
<cfw:replaceCommand>
<cfw:pattern>(%OLD_HOME%)</cfw:pattern>
<cfw:value_ref>1</cfw:value_ref>
<cfw:new_value>%NEW_HOME%</cfw:new_value>
</cfw:replaceCommand>
</replace>
</cfw:operation>
A common use of cloning is to expand the size of an Oracle Application Server cluster topology. Consider a cluster consisting of multiple Oracle WebCenter Framework and Oracle HTTP Server middle tiers, with identical configuration and application deployment. To expand the cluster, you want to create a new middle-tier instance that has the same configuration as the other instances and is part of the same cluster.
This example assumes that:
The source instance is a member of a cluster based on multicast dynamic node discovery. The cloned instance will be part of the same cluster as the source instance.
The source instance contains a file-based MDS that is located in the Oracle home and is on an NFS-shared disk.
The strategy for expanding a cluster topology consists of the following steps:
Prepare the source instance for cloning, using the steps described in Section 9.4.2:
Perform Step 1, as described in Section 9.4.2.
Perform Step 2 in Section 9.4.2.
In that step, use the -export option to export customizations made to the producers of a deployed application on the source instance to an .ear file. For example:
perl prepare_clone.pl ORACLE_HOME=/scratch/oracleas/Ora_10132 -export
Perform Step 3 as described in Section 9.4.2.
Clone the source instance to create a new instance, using the steps described in Section 9.4.3:
Perform Steps 1, 2, and 3 as described in Section 9.4.3.
Perform Step 4 in Section 9.4.3.
In that step, you must change the name of the cloned instance, by specifying it on the command line. In addition, you must specify the -import option to import the .ear file generated by the prepare_clone operation. For example:
perl clone.pl ORACLE_HOME=/scratch/oracle/Ora_10132_B
ORACLE_HOME_NAME=OH_10132B
-instance WebC
-oc4jadmin_old_password my_old_admin_pass
-oc4jadmin_new_password my_new_admin_pass
-import
In this example, the instance name for the cloned instance is WebC.
Perform Steps 6 through 8 in Section 9.4.3, if necessary.
Perform Steps 9 through 10 in Section 9.4.3, if necessary.
Perform Step 11 in Section 9.4.3.
