You can expand your environment by adding Managed Servers, expanding your WebLogic Server domain to include other products, or copying your existing Oracle Fusion Middleware environment, including components such as Oracle SOA Suite or Oracle HTTP Server, from one source to another.
This chapter contains the following topics:
Extending a WebLogic Server Domain to Support Additional Components
Adding Additional Managed Servers to a WebLogic Server Domain
Scalability is the ability of a system to provide throughput in proportion to, and limited only by, available hardware resources. A scalable system is one that can handle increasing numbers of requests without adversely affecting response time and throughput.
The growth of computational power within one operating environment is called vertical scaling. Horizontal scaling is leveraging multiple systems to work together on a common problem in parallel.
Oracle Fusion Middleware scales both vertically and horizontally. Horizontally, Oracle Fusion Middleware can increase its throughput with several Managed Servers grouped together to share a workload. Also, Oracle Fusion Middleware provides great vertical scalability, allowing you to add more Managed Servers or components in the same host.
High availability refers to the ability of users to access a system. Deploying a high availability system minimizes the time when the system is down (unavailable) and maximizes the time when it is running (available). Oracle Fusion Middleware is designed to provide a wide variety of high availability solutions, ranging from load balancing and basic clustering to providing maximum system availability during catastrophic hardware and software failures.
High availability solutions can be divided into two basic categories: local high availability and disaster recovery.
See Also:
Oracle Fusion Middleware High Availability Guide for more information about high availability
When you create an Oracle WebLogic Server domain, you create it using a particular domain template. That template supports a particular component or group of components, such as the Oracle SOA Suite. If you want to add other components, such as Oracle WebCenter Portal, to that domain, you can extend the domain by creating additional Managed Servers in the domain, using a domain template for the component which you want to add.
See Also:
The table "Supported Domain Extensions" in the Oracle Fusion Middleware Administrator's Guide for information about which components you can add to an existing domain and the domain templates needed
When you extend a domain, the domain must be offline.
To extend a domain, you use the Oracle WebLogic Server Configuration Wizard from an Oracle home into which the desired component has been installed. Then, you select the domain that you want to extend and the component you want to add.
For example, to extend a domain that was initially created to support Oracle SOA Suite so that it can now also support Oracle WebCenter Portal:
Use RCU to add any required schemas for the component, as described in Section 3.2.1.
Install Oracle WebCenter Portal, as described in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter.
From an Oracle home that was installed for the component you want to add, (for example, for Oracle WebCenter Portal), invoke the Configuration Wizard, using the following command:
(UNIX) ORACLE_HOME/common/bin/config.sh (Windows) ORACLE_HOME\common\bin\config.cmd
The Configuration Wizard's Welcome screen is displayed.
Select Extend an existing WebLogic Domain.
Click Next.
The Select a WebLogic Domain Directory screen is displayed.
Select the directory for the domain to which you want to add the components.
Click Next.
The Select Extension Source screen is displayed.
Select Extend my domain automatically to support the following added products, Then, select the source from which this domain is to be extended. For example, select Oracle WebCenter Spaces.
Click Next.
The Configure JDBC Data Sources screen is displayed.
Select the schemas for the new component you added, entering the following information:
For Vendor, select Oracle.
For Driver, select Oracle's Driver (Thin) for Service connections; Versions:9.0.1,9.2.0,10,11.
For Schema Owner, do not enter anything. Each data source uses the user name specified in the table.
If you used the same password when you created the schemas, select all of the schemas and enter the password in Schema Password.
Alternatively, you can specify different passwords for each data source by selecting each schema individually and entering the password.
With all of the schemas selected, for DBMS/Service, enter the SID of the database.
With all of the schemas selected, for Host Name, enter the host name of the database.
With all of the schemas selected, for Port, enter the listening port of the database.
Click Next.
The Test Component Schema screen is displayed.
If the test succeeds, click Next.
The Select Optional Configuration screen is displayed.
In this and the following customization screens, you can choose to customize. To do so, select the type of customization. If you do not want to customize the settings, click Next.
The Configuration Summary screen is displayed.
Review the information on the screen and if it is correct, click Extend.
When the operation completes, click Done.
See Also:
Oracle WebLogic Server Administration Console Online Help for more information about creating additional Managed Servers
You can add Managed Servers to a domain to increase the capacity of your system. The Managed Servers can be added to a cluster.
When a Managed Server is added to a cluster, it inherits the applications and services that are targeted to the cluster. When a Managed Server is added to a domain, it does not automatically inherit the applications and services from the template.
To add a Managed Server to a domain, you can use the Oracle WebLogic Server Administration Console or WLST.
See:
Administration Console Online Help and Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for complete information about adding Managed Servers
To create an additional Managed Server using the Administration Console:
Display the Administration Console, as described in Section 2.3.1.
Lock the Oracle WebLogic Server configuration, as described in Section 2.3.2.
In the left pane, expand Environment, then select Servers.
In the Servers table, click New.
The Create a New Server: Server Properties page is displayed.
Enter the following information:
For Name, enter a name for the server.
Each server within a domain must have a name that is unique for all configuration objects in the domain. Within a domain, each server, computer, cluster, JDBC connection pool, virtual host, and any other resource type must be named uniquely and must not use the same name as the domain.
For Listen Address, if you want to limit the valid addresses for a server instance, enter an IP address or DNS name. Otherwise, URLs to the server can specify the host computer's IP address, any DNS name that maps to one of the IP addresses, or the localhost string.
For Listen Port, enter the port number from which you want to access the server instance.
If you run multiple server instances on a single computer, each server must use its own listen port.
Specify whether or not this server will be a standalone server or will belong to an existing cluster or a new cluster.
If this server is to be a standalone server, select No, this is a stand-alone server.
If this server is to be part of an existing cluster, select Yes, make this server a member an existing cluster. Then, select the cluster.
This option is not shown if there are no existing clusters.
If this server is to be part of a new cluster, select Yes, create a new cluster for this server.
Click Next.
The Review Choices page is displayed.
Review the information. If it is correct, click Finish.
Apply Oracle JRF to the Managed Server or cluster as described in Section 9.3.1.
Note that you can also use Fusion Middleware Control to add a Managed Server to a domain. From the Farm menu, choose Create/Delete Components. Then, in the Fusion Middleware Components page, select Create, then WebLogic Server.
Oracle JRF (Java Required Files) consists of those components not included in the Oracle WebLogic Server installation and that provide common functionality for Oracle business applications and application frameworks.
JRF consists of a number of independently developed libraries and applications that are deployed into a common location. The components that are considered part of Java Required Files include Oracle Application Development Framework shared libraries and ODL logging handlers.
You must apply the JRF template to a Managed Server or cluster in certain circumstances. You can only apply JRF to Managed Servers that are in a domain in which JRF was configured. That is, you must have selected Oracle JRF in the Configuration Wizard when you created or extended the domain.
Note the following points about when you apply JRF:
When you add a Managed Server to an existing cluster that is already configured with JRF, you do not need to apply JRF to the Managed Server.
When you add a Managed Server to a domain and the Managed Server requires JRF services, but the Managed Server is not part of a cluster, you must apply JRF to the Managed Server.
When you create a new cluster and the cluster requires JRF, you must apply JRF to the cluster.
You do not need to apply JRF to Managed Servers that are added by product templates during the template extension process (though you must select JRF in the Configuration Wizard).
You must restart the server or cluster after you apply JRF.
If you create a server using Fusion Middleware Control, the JRF template is automatically applied.
You use the custom WLST command applyJRF to configure the Managed Servers or cluster with JRF. To use the custom WLST commands, you must invoke the WLST script from the Oracle Common home. See Section 2.4.1.1 for more information.
The format of the applyJRF command is:
applyJRF(target={server_name | cluster_name | *}, domainDir=domain_path
[,shouldUpdateDomain= {true | false}])
You can use the applyJRF command online or offline:
In online mode, the JRF changes are implicitly activated if you use the shouldUpdateDomain option with the value true (which is the default.) In online mode, this option calls the online WLST save() and activate() commands.
In offline mode, you must restart the Administration Server and the Managed Servers or cluster. (In offline mode, if you specify the shouldUpdateDomain option with the value true, this option calls the WLST updateDomain() command.)
To configure a Managed Server with JRF, use the following command:
applyJRF(target='server1', domainDir='/scratch/Oracle/Middleware/user_projects/domains/domain1')
To configure all Managed servers in the domain with JRF, specify an asterisk (*) as the value of the target option.
To configure a cluster with JRF, use the following command:
applyJRF(target='cluster', domainDir='/scratch/Oracle/Middleware/user_projects/domains/domain1')
See Also:
"Java Required Files Custom WLST Commands" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference
"Using a Different Version of Spring" in the Oracle Fusion Middleware Administrator's Guide to use a different version of Spring than that which is supplied with JRF
A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same computer, or be located on different computers. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing computer, or you can add computers to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.
You can create a cluster of Managed Servers using WLST, the Oracle WebLogic Server Administration Console, or Fusion Middleware Control. This section describes how to create a cluster using Fusion Middleware Control.
Note:
For Identity Management components, Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer, if one or more Managed Servers that you want to include in a cluster is on a remote host, the WebLogic Server home must have the same full path as the WebLogic Server home of the other Managed Servers.
For example, you have a Managed Server on Host A and a Managed Server on Host B, and you want to include them in a cluster. If the WebLogic Server home on Host A is located in /scratch/oracle/Middleware/wlserver_10.3, the WebLogic Server home on Host B must also be located in /scratch/oracle/Middleware/wlserver_10.3.
To create a cluster of two Managed Servers, soa_server1 and soa_server2, using Fusion Middleware Control:
From the Farm menu, choose Create/Delete Components.
The Fusion Middleware Components page is displayed.
Choose Create, then WebLogic Cluster.
The Create WebLogic Cluster page is displayed.
For Name, enter a name for the cluster.
In the Cluster Messaging Mode section, select one of the following:
Unicast. Then, for Unicast Broadcast Channel, enter a channel. This channel is used to transmit messages within the cluster.
Multicast. Then, for Multicast Broadcast Channel, enter a channel. A multicast address is an IP address in the range from 224.0.0.0 to 239.255.255.255. For Multicast Port, enter a port number.
Note:
You must ensure that the multicast address is not in use.
In the Servers section, select one or more servers to be added to the cluster. In this scenario, select soa_server1 and soa_server2.
Click Create.
Now, you have a cluster with two members, soa_server1 and soa_server2.
See Also:
Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server for more information about clusters
If you create a server using Fusion Middleware Control, the JRF template is automatically applied.
You can expand your environment to meet growing demands by copying existing Middleware homes and Oracle homes and some components to the same host or another host. Oracle Fusion Middleware provides a series of scripts that you can use to copy your environment, for example moving a test environment to a production environment. The scripts, called movement scripts, enable you to copy a Middleware home and the Oracle homes and Oracle WebLogic Server domains, as well as the configuration of certain Oracle Fusion Middleware components, such as Oracle SOA Suite, Oracle HTTP Server, Oracle Internet Directory, and Oracle Virtual Directory.
The movement scripts minimize the amount of work that would otherwise be required to reapply all the customization and configuration changes made in one environment to another. You can use these scripts to:
Create a Middleware home that is a copy of a production, test, or development environment. The scripts create a new Middleware home with all patches applied to all of the Oracle homes and the WebLogic Server home in a single step. This is in contrast to separately installing and applying any patches to the WebLogic Server home and separate Oracle homes.
Prepare a "gold" image of a patched Middleware home and deploying it to many hosts.
Move the configuration of a domain or Oracle instance, including the components in the domain or Oracle instance, from one environment to another.
You can move the following, to the same host or a different host. The source and target environments must share the same operating system and the same platform architecture (in terms of number of bits).
Middleware home: You can copy the Middleware home, the Oracle WebLogic Server home, and all of the Oracle homes within the Middleware home. (You can copy a Middleware home that contains no Oracle homes, but you must use the cloningclient.jar file and movement scripts that are compatible with the version of the Middleware home that you want to copy.)
Java components: You can copy the configuration of a domain containing Java components, such as Oracle SOA Suite and Oracle Business Activity Monitoring, to the same or a different Middleware home.
An Oracle instance: You can copy the configuration of an Oracle instance to the same or a different Middleware home. When you move an Oracle instance, you move all configuration files in that instance for all system components in that Oracle instance.
Alternatively, you can move one of the system components, such as Oracle HTTP Server, within an Oracle instance. In that case, the configuration of the Oracle instance and the specified component are moved. You can move the following system components in this way:
Oracle HTTP Server
Oracle Virtual Directory
Oracle Internet Directory
Oracle BI Enterprise Edition
You use the following scripts to copy a Middleware home or component:
Copy the source Middleware home:
(UNIX) ORACLE_COMMON_HOME/bin/copyBinary.sh (Windows) ORACLE_COMMON_HOME\bin\copyBinary.cmd
Apply the copied Middleware home to the target:
(UNIX) ORACLE_COMMON_HOME/bin/pasteBinary.sh (Windows) ORACLE_COMMON_HOME\bin\pasteBinary.cmd
Copy the source component configuration:
(UNIX) ORACLE_COMMON_HOME/bin/copyConfig.sh (Windows) ORACLE_COMMON_HOME\bin\copyConfig.cmd
Extract a move plan from the source component:
(UNIX) ORACLE_COMMON_HOME/bin/extractMovePlan.sh (Windows) ORACLE_COMMON_HOME\bin\extractMovePlan.cmd
Apply the copied component configuration to the target:
(UNIX) ORACLE_COMMON_HOME/bin/pasteConfig.sh (Windows) ORACLE_COMMON_HOME\bin\pasteConfig.cmd
Generate a file containing an obfuscated password:
(UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
Note that all movement scripts ask if you want to continue whenever you do not specify the -silent true option. To continue, you must type yes, which is not case sensitive. Any words other than yes causes the script to return an error. Also note that, in silent mode, the scripts generate an error if you do not provide passwords where they are needed.
To specify additional Java options, define the T2P_JAVA_OPTIONS environment variable and specify the options in the variable definition. The following examples set the value for the Java temp directory:
On Linux or UNIX:
setenv T2P_JAVA_OPTIONS "-Djava.io.tmpdir=/home/t2p/temp" export T2P_JAVA_OPTIONS="-Djava.io.tmpdir=/home/t2p/temp"
On Windows:
set T2P_JAVA_OPTIONS="-Djava.io.tmpdir=c:\home\t2p\temp"
See Also:
"Using the Movement Scripts" in the Oracle Fusion Middleware Administrator's Guide for complete information about the scripts, including the syntax
Note:
If you are applying the archive of a Middleware home on a host that does not yet have Oracle Fusion Middleware installed, note the following
The host must have JDK 1.6.04 or higher installed. In addition, ensure that the PATH, CLASSPATH, and JAVA_HOME environment variables point to the JDK.
Copy the pasteBinary script from the following location in the source host to the target host:
(UNIX) ORACLE_COMMON_HOME/bin/pasteBinary.sh (Windows) ORACLE_COMMON_HOME\bin\pasteBinary.cmd
Copy the following file from the following location in the source host to the target host:
(UNIX) ORACLE_COMMON_HOME/jlib/cloningclient.jar (Windows) ORACLE_COMMON_HOME\jlib\cloningclient.jar
If you run the pasteBinary script from a different location than ORACLE_COMMON_HOME/bin, then the pasteBinary script and the cloningclient.jar file must be in the same directory.
Ensure that the files have execute permission.
This section describes the general steps in moving installations from a source environment to a target environment.
The general steps are:
Prepare your source environment. See Section 9.5.3.
Prepare your target environment. See Section 9.5.4.
If your environment uses a database, create a new database or copy the database from the source environment to the target environment. See Section 9.5.5.
Move Oracle Identity Management to the target environment. See "Moving Identity Management to a New Target Environment" in the Oracle Fusion Middleware Administrator's Guide.
Move a copy of the Middleware home and the binary files from the source environment to the target environment using the copyBinary and pasteBinary scripts, as described in Section 9.5.6.
Move a copy of the configuration of components, as described in Section 9.5.7 or Section 9.5.8. In most cases, you use the copyConfig, extractMovePlan, and pasteConfig scripts.
Move other data, such as UMS user messaging preferences, data for Oracle WebCenter Portal applications, or Oracle Web Cache configuration files. Modify any information that is specific to the new environment such as host name or ports. See "Moving Oracle Fusion Middleware Components" in the Oracle Fusion Middleware Administrator's Guide for information specific to each component.
The procedures in this chapter assume that you have installed and configured Oracle Fusion Middleware on the source environment, including some or all of the following:
Installed one or more databases to be used by Oracle Fusion Middleware components such as Identity Management, Oracle SOA Suite, or Oracle WebCenter Portal.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Installed Oracle WebLogic Server and created the Middleware home.
Installed and configured Identity Management.
This can include creating the desired LDAP trees and entries, in particular, users and groups for Oracle Internet Directory, creating adapters to data sources for Oracle Virtual Directory, creating policies for Oracle Web Services Manager. In addition, it can include configuring self-signed certificates for SSL. (In the target environment, you use trusted CA-signed certificates.)
Installed and configured Oracle Fusion Middleware components such as Oracle SOA Suite or Oracle WebCenter Portal.
Configured security policies.
Deployed one or more applications or SOA Composite applications. The applications may have internal and external references.
Note that all Oracle homes in the Middleware home on the source environment must be registered in the same Oracle inventory. If you have installed multiple components under the same Middleware home, but used different Oracle inventory locations, the scripts are not able to detect all of the Oracle homes.
To use the procedures in this chapter, your target environment must meet the following prerequisites:
You must use the cloningclient.jar file and movement scripts that are compatible with the version of the Middleware home and components that you want to copy. The procedures in this chapter presume that you are using the current version of the cloningclient.jar file and movement scripts.
The target environment must be on the same operating system as the source environment. Also, the operating system architecture must be the same in both environments. For example, both environments must be running 32-bit operating systems or 64-bit operating systems.
All Oracle homes in the Middleware home must be either all 32 bit or all 64 bit. The operation does not support a mix of 32-bit and 64-bit Oracle homes.
When you execute the scripts, you must specify a matching Java home. That is, if the Oracle homes are 64 bit, you must specify a 64-bit Java home. If the Oracle homes are 32 bit, you must specify a 32-bit Java home.
The target environment must have the same superuser or administrative user as the user at the source environment. The user's password can be different; you specify it on the command line when you use the pasteConfig script.
After you complete the movement of the installation, you can modify the user on the target environment.
The database in the target environment must be the same type of database as in the source environment. For example, if the database in the source environment is an Oracle Database, the database in the target environment must be an Oracle Database. The database on the target environment should be the same version as on the source environment.
If the database is not tuned correctly, the copyConfig and pasteConfig operations can incur performance issues. To avoid these performance issues, in addition to following standard database performance tuning guidelines, ensure that you have sufficient RAM allocated for your database for the import of the MDS tables. Also run statistics against the target database by executing the following procedure:
BEGIN
dbms_stats.gather_schema_stats(ownname => 'prefix_MDS',
METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
CASCADE => TRUE, ESTIMATE_PERCENT => NULL);
END;
In the procedure, prefix_MDS is the MDS schema name for your installation.
Many components, such as Oracle Internet Directory, Oracle SOA Suite, and Oracle WebCenter Portal, require a database.
Note that the database in the target environment must be the same type of database as in the source environment. For example, if the database in the source environment is an Oracle Database, the database in the target environment must be an Oracle Database. The database on the target environment should be the same version as on the source environment.
You can install a new database or you can copy the database from the source environment:
Install a new database:
Install and configure the database software.
Create the required schemas in the target database using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Create any custom schemas used by your applications. For example, if your application uses a custom schema in the source environment, create the schema in the target environment.
Create a duplicate database using the Oracle Database RMAN duplicate command. The duplicate database must be created with a different DBID than the source database, so that it functions entirely independently.
For information about creating a duplicate Oracle Database, Release 11g, in the target environment, see "Installing the Database on the Target Environment" in the Oracle Fusion Middleware Administrator's Guide.
You can move a copy of the Middleware home to the target environment using the copyBinary and pasteBinary scripts. The Oracle WebLogic Server home, the Oracle homes, and the binary files in the Middleware home are also moved.
To move the Middleware home:
On Windows, at the source, stop the Administration Server and any Managed Servers running in the Middleware home. (On UNIX, you do not need to stop the servers.)
At the source, execute the copyBinary script, which copies the Middleware home and the WebLogic Server home and the Oracle homes contained within the Middleware home. If there are no Oracle homes in the source Middleware home, no Oracle homes are present in the archive. See "copyBinary Script" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the copyBinary script.
For example, to copy a Middleware home that is located at /scratch/Oracle /Middleware1, use the following command:
copyBinary.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/mw_copy.jar
-sourceMWHomeLoc /scratch/Oracle/Middleware1
-invPtrLoc /scratch/oracle/oraInst.loc
If you are copying the Middleware home to a different host, copy the archive file to that system.
Copy the pasteBinary script and the cloningclient.jar file to the target system and ensure that they have execute permission. See Section 9.5.1 for the locations of the files.
Do not copy the other scripts, such as pasteConfig. Those scripts are generated when you extract the files, as in step 5.
At the target, extract the files from the archive using the pasteBinary script, See "pasteBinary Script" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the pasteBinary script.
For example, to apply the archive to the directory /scratch/oracle/MW_Home_prod, use the following command:
pasteBinary.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/mw_copy.jar
-targetMWHomeLoc /scratch/oracle/MW_Home_prod
The Middleware home is extracted to /scratch/oracle/MW_Home_prod and the WebLogic Server home and all of the Oracle homes are extracted under it with the same names as that of the source Oracle home names.
At the target, delete the Node Manager directory and the files in it. The default location of the directory is:
WL_hOME/common/nodemanager
You will move the Node Manager configuration in Section 9.5.7, Step 8.
You can move a copy of the domain configuration for Java components, such as Oracle SOA Suite, using the copyConfig, extractMovePlan, and pasteConfig scripts. This step moves a copy of the configuration, including the domain, the Administration Server and Managed Servers. Then, it starts the Administration Server. You also move a copy of the Node Manager configuration.
Because, in most cases, the user-specific data is not the same in the target environment as in the source environment, this process does not move user-specific data.
Notes:
When you move the configuration of a component, the scripts replicate the topology of the source. For example, if the source domain contains Managed Servers server_1 and server_2 on Host A and Managed Servers server_3 and server_4 on Host B, you must specify a similar relationship between Managed Servers and hosts at the target. (You specify the hosts for each Managed Server in the move plan.)
The domain directory is local to each machine, pasteConfig is performed only on the Administration Server domain directory. Subsequently, if the Managed Servers are not in the same directory as the Administration Server, you must re-create the domain directory for those Managed Servers by using the Oracle WebLogic Server pack and unpack commands. For more information, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.
To move a copy of the domain configuration and Node Manager configuration:
At the source, make sure that the Administration Server and all Managed Servers are started.
At the source, copy the domain configuration by executing the copyConfig script. See "copyConfig Script for Java Components" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the copyConfig script.
For example, to copy the configuration of the Oracle SOA Suite domain named SOA_domain1 in the Middleware home /scratch/Oracle/Middleware1, use the following command:
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/soa.jar
-sourceDomainLoc /scratch/Oracle/Middleware1/user_projects/domains/SOA_domain1
-sourceMWHomeLoc /scratch/Oracle/Middleware1
-domainHostName example.com
-domainPortNum 8001
-domainAdminUserName domain_admin_username
-domainAdminPassword /scratch/admin/passwd.txt
-logDirLoc /tmp/logs
If you are copying the domain configuration to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script. See "extractMovePlan Script" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the extractMovePlan script.
For example:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/soa.jar
-planDirLoc /tmp/Oracle/t2p_plans/soa
Edit the move plan, modifying the properties to reflect the values for the target environment. See the table "Move Plan Properties for Components" in the Oracle Fusion Middleware Administrator's Guide to find the list of properties for the type of component you are moving.
If you are moving only one domain in an environment that contains more than one domain, in the move plan, remove the entries for the domains that you are not moving.
At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.
ORACLE_COMMON_HOME/bin/obfuscatePassword.sh
The script prompts you to enter the password and the location where the password file is to be written.
At the target, extract the files from the archive using the pasteConfig script. See "pasteConfig Script for Java Components" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the script.
For example, to apply the archive to the Middleware home /scratch/Oracle/Middleware1, use the following command:
pasteConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/soa.jar
-movePlanLoc /tmp/Oracle/t2p_plans/soa/moveplan.xml
-targetDomainLoc /scratch/Oracle/Middleware1/user_projects/domains/SOA_domain1
-targetMWHomeLoc /scratch/Oracle/Middleware1/
-domainAdminPassword /scratch/pwd_dir/pass.txt
At the source, copy the Node Manager configuration, by executing the copyConfig script. See "copyConfig Script for Node Manager" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the script. For example, use the following command:
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/nm.jar
-sourceNMHomeLoc /scratch/Oracle/Middleware/wlserver_10.3/common/nodemanager
-logDirLoc /tmp/logs
If you are copying the Node Manager to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script. See "extractMovePlan Script" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the extractMovePlan script.
For example:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/nm.jar
-planDirLoc /tmp/Oracle/t2p_plans/nm
Edit the move plan, modifying the properties to reflect the values for the target environment. See the table "Move Plan Properties for Node Manager" in the Oracle Fusion Middleware Administrator's Guide to find the list of properties for Node Manager.
At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.
ORACLE_COMMON_HOME/bin/obfuscatePassword.sh
The script prompts you to enter the password and the location where the password file is to be written.
At the target, extract the files from the archive using the pasteConfig script. See "pasteConfig Script for Node Manager" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the script. For example, use the following command:
pasteConfig -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/
-archiveLoc /tmp/nm.jar
-targetNMHomeLoc /scratch/Oracle/Middleware1/wlserver_10.3/common/nodemanager
-targetMWHomeLoc /scratch/Oracle/Middleware1
-movePlanLoc /tmp/Oracle/t2p_plans/nm/moveplan.xml
-silent true
When you complete this task, you may need to perform additional steps for each component, as described in "Moving Oracle Fusion Middleware Components" in the Oracle Fusion Middleware Administrator's Guide.
You can move and Oracle instance and system components, such as Oracle HTTP Server, Oracle Internet Directory, Oracle Virtual Directory, and Oracle BI EE, in one of the following ways:
You can move an Oracle instance and all of its system components, as described in this section.
You can move an individual system component, as described in "Moving an Individual System Component" in the Oracle Fusion Middleware Administrator's Guide.
In both cases, you use the copyConfig, extractMovePlan, and pasteConfig scripts. The only difference is in the options that you pass to the scripts.
To move the entire Oracle instance, including the configuration of all of the system components within that instance:
At the source, execute the copyConfig script. See "copyConfig Script for Oracle Instances" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the script.
For example, to copy the Oracle instance located in /scratch/Oracle/Middleware1/webtier_1, use the following command:
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-sourceInstanceHomeLoc /scratch/Oracle/Middleware1/webtier_1
If you are copying the component to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script. See "extractMovePlan" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the script.
For example:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-planDirLoc /tmp/Oracle/t2p_plans/ohs
Edit the move plan, modifying the properties for the particular components to reflect the values for the target environment. See the table "Move Plan Properties for Components" in the Oracle Fusion Middleware Administrator's Guide to find the list of properties for the type of component you are moving.
At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.
ORACLE_COMMON_HOME/bin/obfuscatePassword.sh
The script prompts you to enter the password and the location where the password file is to be written.
At the target, extract the files from the archive using the pasteConfig script. See "pasteConfig Script for Oracle Instances" in the Oracle Fusion Middleware Administrator's Guide for the complete syntax of the script.
For example, to apply the archive to the Oracle instance webtier_2 and name the target Oracle HTTP Server instance ohs_cl, use the following command:
pasteConfig.sh -javaHome /scratch/Oracle/Middleware/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-movePlanLoc /tmp/Oracle/t2p_plans/ohs/moveplan.xml
-targetOracleHomeLoc /scratch/Oracle/Middleware/Oracle_WebTier
-targetInstanceHomeLoc /scratch/Oracle/Middleware/webtier_2
-targetInstanceName webtier_2
-targetComponentName ohs_cl
-domainHostName myhost
-domainPortNum 7001
-domainAdminUserName domain_admin_username
-domainAdminPasswordFile domain_admin_password_file
Note that the Oracle instance name must be unique in the domain. If you are applying the archive of the Oracle instance to the same domain, use the -targetInstanceName option to specify a different name for the instance.
When you complete this task, you may need to perform additional steps for each component, as described in "Moving Oracle Fusion Middleware Components" in the Oracle Fusion Middleware Administrator's Guide.
When you move Oracle Fusion Middleware components, you run the extractMovePlan script to create a move plan for the component that you are moving. The extractMovePlan script extracts configuration information from the archive into a move plan. It also extracts any needed configuration plans. Before you apply the archive to the target, you must edit the move plan to reflect the values of the target environment.
The following shows an excerpt of a move plan for WebLogic Java components:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<movePlan>
<movableComponent>
<componentType>J2EEDomain</componentType>
<moveDescriptor>
<configProperty>
<name>Startup Mode</name>
<value>PRODUCTION</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configGroup>
<type>SERVER_CONFIG</type>
<configProperty id="Server1">
<configProperty>
<name>Server Name</name>
<value>AdminServer</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_ONLY</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>Listen Address</name>
<value>example.com</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
You can modify properties with the scope of READ_WRITE. Do not modify the properties with the scope of READ_ONLY.
The properties that you edit differ depending on the type of component. See the table in "Modifying Move Plans" in the Oracle Fusion Middleware Administrator's Guide for information about the properties to edit for each type of component.
For more information about the topics covered in this chapter, see:
Oracle WebLogic Server Administration Console Online Help for information about adding Managed Servers to a WebLogic Server domain
Oracle Fusion Middleware Installation Planning Guide for information about extending a domain
"Using the Movement Scripts" and "Moving from a Test to a Production Environment" in the Oracle Fusion Middleware Administrator's Guide