Oracle® Application Server Administrator's Guide 10g Release 3 (10.1.3) B25209-03 |
|
![]() Previous |
![]() Next |
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.
You can quickly create a cloned copy of a test, development, or production installation by using either the command-line cloning scripts or Oracle Enterprise Manager 10g Grid Control Console.
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 J2EE and Oracle HTTP Server middle tier that is not connected to Oracle Identity Management.
Figure 9-1 Cloning a J2EE 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:
J2EE Server and Process Management middle tier
Web Server and Process Management middle tier
Integrated Web Server, J2EE Server, and Process Management middle tier
See Section 9.5, "Considerations and Limitations for Cloning", especially the subsections Section 9.5.2, Section 9.5.3, and Section 9.5.4, for details of considerations affecting specific components in the cloned Oracle home.
Note the following:
You cannot clone Oracle TopLink.
You cannot clone an OracleAS Infrastructure, but you can clone a middle tier that is connected to 10.1.2 or 9.0.4 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.5, "Configuring Instances to Use 10.1.2 and 9.0.4 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.4, "Cloning the Instance".
You can clone a middle-tier instance that is a member of a cluster. See Section 9.4.6, "Cloning Instances That Are Members of a Cluster Topology" 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.3, "Preparing the Source" 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. This script makes use of the cloning functionality in Oracle Universal Installer. 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.4, "Cloning the Instance" 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.
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
You copy the cloning scripts from the Companion CD, which ships with Oracle Application Server 10g Release 3 (10.1.3).
Copy the scripts from the following location in the Companion CD and unzip the files:
Disk2/clone/clone.zip
The examples in this chapter assume that you have copied the files to the following directory:
(UNIX) ORACLE_HOME/clone/bin (Windows) ORACLE_HOME\clone\bin
To prepare the source Oracle home to be cloned, take the following steps at the source instance:
If the source instance is a member of a cluster, remove it, as described in Section 9.4.6.
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] [-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. |
-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.5, "Locating and Viewing Log Files" 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_Password] [-oc4jadmin_new_password New_Admin_Password] [-Ostring] [-silent] [-debug] [-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. The administrator |
-oc4jadmin_new_password |
Required. 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. |
-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. |
-help |
Prints the usage for the script. |
For example:
perl clone.pl ORACLE_HOME=/opt/oracle/Ora_1013_B
ORACLE_HOME_NAME=OH_1013_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'
-silent
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 the source instance was a member of a cluster, add it to the cluster again. If you want the cloned instance to be a member of a cluster, add it to the cluster. See Section 9.4.6 for more information.
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/cloneActions
timestamp
.log
: Contains a detailed log of the actions that occur during the Oracle Universal Installer part of the cloning.
Oracle_inventory
/logs/oraInstall
timestamp
.err
: Contains information about errors that occur when Oracle Universal Installer is running.
Oracle_inventory
/logs/oraInstall
timestamp
.out
: Contains other miscellaneous messages generated by Oracle Universal Installer.
Oracle_Home
/clone/logs/clone
timestamp
.log
: Contains a detailed log of the actions that occur during the precloning and cloning operations.
Oracle_Home
/clone/logs/error
timestamp
.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.
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 an Oracle Application Server Cluster Topology. However, you must remove the instance from the cluster before you clone the instance. You can add the instance back to the cluster after cloning.
How you remove the instance from the cluster depends on the type of cluster. For example, to remove an instance from a multicast discovery cluster, use the following command:
opmnctl config topology delete discover
Similarly, how you add an instance to a cluster after cloning depends on the type of cluster. For example, to add an instance to a multicast discovery cluster, use the following command:
opmnassociate *multicastAddress:multicastPort -restart
See Also: The chapter, "Configuring and Managing Clusters" in the Oracle Containers for J2EE Configuration and Administration Guide for detailed information about adding instances to and removing instances from a cluster. |
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 TopLink
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 12 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.5, "Configuring Instances to Use 10.1.2 and 9.0.4 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, "Assigning Custom Ports". 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 file is not updated with information about the cloned instance. It contains information about the source instance:
(UNIX) Oracle_Home/install/readme.txt (Windows) Oracle_Home\install\readme.txt
To find the port numbers for the cloned instance, use the following command:
(UNIX) Oracle_Home/opmn/bin/opmnctl status -l (Windows) Oracle_Home\opmn\bin\opmnctl status -l
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, "Updating Custom Data" 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, "Updating Custom Data" 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 or OracleAS Web Cache 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 and describes which OC4J components are preserved:
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, "Understanding the Cloning Process" for details.
In a J2EE and Process Management installation, if the OPMN-managed processes of the source instance are stopped when the clone.pl script is run, the cloned instance will use the same ports as the source instance. This creates a port conflict. If this happens, take the following steps for the cloned instance:
Stop all OPMN processes:
(UNIX) Oracle_Home/opmn/bin/opmnctl stopall (Windows) Oracle_Home\opmn\bin\opmnctl stopall
Edit the following file:
(UNIX) Oracle_Home/opmn/conf/opmn.xml (Windows) Oracle_Home\opmn\conf\opmn.xml
Under the element <ias-component id="OC4J">, change the port number in the following line:
<port id="default-web-site" range="8888" protocol="http"/>
Select a port number from the range 8888 to 8898. (Using a number at the upper end of the range will make it less likely that the port is in use.)
Save the file.
Start all OPMN processes:
(UNIX) Oracle_Home/opmn/bin/opmnctl startall (Windows) Oracle_Home\opmn\bin\opmnctl startall
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.
Note that each OC4J instance in a group must have the same oc4jadmin
password. See Section 2.3.6.3 for information about groups.
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.
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:
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, separate each argument with a space.
In addition, you can specify information to be passed to the Oracle Universal Installer command line by using the -O
string
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 configuration file 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 following line to the cs.properties
file:
clone_command_line = oracle.iappserver.iapptop: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.iappserver.iapptop: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.4, "Cloning the Instance" 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 J2EE 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. The cloned instance will be part of the same cluster as the source instance.
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.3:
If the source instance is a member of a cluster, remove it, as described in Section 9.4.6.
Perform Step 2, as described in Section 9.4.3.
Perform Step 3 in Section 9.4.3.
In that step, use a command similar to the following:
perl prepare_clone.pl ORACLE_HOME=/opt/oracle/Ora_1013
Perform Step 4 as described in Section 9.4.3.
Clone the source instance to create a new instance, using the steps described in Section 9.4.4:
Perform Steps 1, 2, and 3 as described in Section 9.4.4.
Perform Step 4 in Section 9.4.4.
In that step, you must change the name of the cloned instance, by specifying it on the command line, as shown in the following example:
perl clone.pl ORACLE_HOME=/opt/oracle/Ora_1013_B
ORACLE_HOME_NAME=OH_1013_B
-instance J2EE_B
-oc4jadmin_old_password my_old_admin_pass
-oc4jadmin_new_password my_new_admin_pass
In this example, the instance name for the cloned instance is J2EE_B.
If the source instance was a member of a cluster, add it to the cluster again. If you want the cloned instance to be a member of a cluster, add it to the cluster. See Section 9.4.6 for more information.