Fusion Middleware Documentation
Advanced Search


Administering Oracle Fusion Middleware
Close Window

Table of Contents

Show All | Collapse

19 Moving from a Test to a Production Environment

This chapter describes how to move Oracle Fusion Middleware from a source environment, such as a test environment, to a target environment, such as a production environment. You can develop and test applications in a source environment, and then eventually roll out the test applications and, optionally, test data to your target environment. You can also use this approach for testing and rolling out upgrades.

This chapter includes the following sections:

Note:

  • The procedures in this chapter are valid for Oracle Fusion Middleware 12c (12.1.2) and the components that are part of that release.

  • The procedures in this chapter for the most part assume that you are using the standard installation topology, which consists of a WebLogic Server domain that contains an Administration Server and a cluster containing two Managed Servers or a standalone domain.

    For more information about the standard topology, see "Understanding the Oracle Fusion Middleware Infrastructure Standard Installation Topology" in Installing and Configuring the Oracle Fusion Middleware Infrastructure.

19.1 Introduction to Moving Oracle Fusion Middleware Components

You can move Oracle Fusion Middleware components from a source environment to a target environment.

Moving Oracle Fusion Middleware components minimizes 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 install, configure, customize, and validate Oracle Fusion Middleware in a source environment. Once the system is stable and performs as desired, you can create the target environment by moving a copy of the components and their configurations from the source environment, instead of redoing all the changes that were incorporated into the source environment.

19.2 Planning for Moving Your Environment

This section describes important information that you should know before you begin moving your environment. It includes the following topics:

19.2.1 Introduction to the Movement Scripts

Oracle Fusion Middleware provides a series of scripts that you can use to move your environment:

  • copyBinary: Copies the binary files of the source Oracle home.

  • pasteBinary: Applies the copied Oracle home to the target.

  • copyConfig: Used for any of the following:

    • Copies the configuration of a WebLogic Server domain, including any Java components or system components in the domain.

    • Copies the configuration of a standalone domain, including any system components in the domain.

    • Copies the configuration of Node Manager.

  • extractMovePlan: Extracts a move plan from the domain or component.

  • pasteConfig: Used for any of the following:

    • Applies the copied configuration of a WebLogic Server domain, including any Java components or system components in the domain.

    • Applies the copied configuration of a standalone domain, including any system components in the domain.

    • Applies the copied configuration of Node Manager.

The scripts enable you to copy an Oracle home and Oracle WebLogic Server domains, as well as the configuration of certain Oracle Fusion Middleware components, such as Oracle HTTP Server.

Table 19-1 shows which Oracle Fusion Middleware components support the movement scripts.

Table 19-1 Support for Movement Scripts

Component Supported?

Oracle Application Development Framework

Yes

Oracle Coherence

Yes

Oracle Data Integrator

Yes

Oracle HTTP Server

Yes

Oracle HTTP Server WebGate

Yes

Oracle Platform Security Services

Yes

Oracle User Messaging Service

Yes

Oracle Web Services Manager

Yes

Oracle WebLogic Server

Yes


19.2.2 Checking the Source Environment

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.

  • Created the needed schemas in the source environment using RCU. See Creating Schemas with the Repository Creation Utility.

  • Installed and configured Oracle Fusion Middleware products. For example, you have installed Oracle WebLogic Server and Oracle Web Services Manager, created the Oracle home, and configured an Oracle WebLogic Server domain.

    When you configure the domain, you can choose one of two modes:

    • Development mode: In this mode, the security configuration is relatively relaxed. User name and password are required to deploy applications.

    • Production mode: In this mode, the security configuration is relatively stringent, requiring a user name and password to deploy applications and to start the Administration Server.

  • Alternatively, you have installed and configured system components, such as Oracle HTTP Server, in a standalone domain.

  • Configured security policies.

  • For Oracle Platform Security, created security policies and stored credentials in the Credential Store Framework (CSF).

  • Deployed one or more applications. The applications may have internal and external references.

  • Before you execute the copyConfig script in a WebLogic Server domain, make sure that the Administration Server and Managed Servers are running.

  • For Oracle Web Services Manager, before you execute the copyConfig script, the server on which the Oracle Web Services Manager Policy Manager application is deployed must be running.

19.2.3 Preparing the Target Environment

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 Oracle 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.

    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. 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.

  • The host must have JDK 1.7.0_15 or higher installed. In addition, ensure that the PATH, CLASSPATH, and JAVA_HOME environment variables point to the JDK.

    For example, the CLASSPATH variable should contain the following:

    $ORACLE_HOME/lib:/scratch/jdkn/lib
    
  • If you are applying the archive of an Oracle home on a host that does not yet have Oracle Fusion Middleware installed, note the following:

    • 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.

      If you are running pasteBinary on a host that has no prior Oracle Fusion Middleware installations, ORACLE_COMMON_HOME/bin will not exist prior to running pasteBinary, and therefore the pasteBinary script and cloningclient.jar must be in the same directory.

    • Ensure that the files have execute permission.

  • When you execute the copyConfig command on the source environment, any system components can be started or shut down. In either case, the copyConfig operation will complete. This pertains to both WebLogic Server domains and standalone domains.

  • On Windows, the file MSVCR90.DLL must exist on the target host. Otherwise, pasteConfig will fail.

    The file is located in:

    (Windows 32 bit) C:\Windows\System32 
    (Windows 64 bit) C:\Windows\winsxs
    

19.2.4 Limitations in Moving from Source to Target

Note the following limitations and restrictions:

  • The source and the target environment must use the same encoding. For example, if the source environment uses the encoding ja_JP.utf8 locale and the target environment uses the encoding ja_JP locale, some file names may not be handled correctly in the target.

  • 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.)

  • If a custom application uses an internal data source (for example, the application was created and deployed with an internal data source using JDeveloper), the internal data source is not migrated during the pasteConfig operation.

    To work around this, create an external data source in the domain, modify the application to use that data source, and deploy the application again.

  • If the source Oracle home uses a JDK that is external to the Oracle home, the pasteBinary operation must also use an external JDK.

  • The JDK used in the source and target must be the same type. For example, if the source uses Java SE, the target must use Java SE. In addition, the vendor must be the same. For example, if the source uses an Oracle JDK, the target must use a JDK from Oracle.

    • The JDK used in the source and target must be the same type. For example, if the source uses Java SE, the target must use Java SE.

    • The vendor used in the source and target must be the same. For example, if the source uses an Oracle JDK, the target must use a JDK from Oracle.

    • The major version of the JDK used in the source and target must be the same. For example, if the source uses version 1.7, the target must use 1.7.

  • If there is not enough space in the temporary directory when you are moving an entity, an error is returned, noting the space needed. To work around this problem, specify a different location for the temporary directory by using the T2P_JAVA_OPTIONS environment variable as described in Section A.1.1.

  • If you have moved your environment and executed the pasteBinary script using a custom inventory location (using the invPtrLoc parameter), you must invoke runInstaller with the following argument:

    -invPtrLoc custom_inventory_pointer_location
    
  • When you are moving Oracle Platform Security Services and the data is moving from LDAP to LDAP, the source and target LDAP domain component hierarchy must be same. If it is not, the Oracle Platform Security Services data movement will fail. For example, if the source is hierarchy is configured as dc=us,dc=com, the target LDAP must have the same domain component hierarchy.

  • If your environment contains both IPV4 and IPV6 protocols, when you update the move plan, any IP addresses must use the IPV4 protocol.

19.2.5 Overview of Procedures for Moving from a Source to a Target Environment

This section describes the general steps in moving installations from a source environment to a target environment. Figure 19-1 shows a flowchart illustrating the steps.

Figure 19-1 Flowchart for Moving Your Environment

Description of Figure 19-1 follows
Description of "Figure 19-1 Flowchart for Moving Your Environment"

The general steps are:

  1. Check your source environment. See Section 19.2.2.

  2. Prepare your target environment. See Section 19.2.3.

  3. If your environment uses a database, create a new database. See Section 19.3.1.

  4. Move a copy of the binary files in an Oracle home from the source environment to the target environment

    • Using the copyBinary and pasteBinary scripts, as described in Section 19.3.2.

    • Using storage-level cloning tools, if supported by your environment, to create a copy of an existing disk volume and move it to a different location. Then, you use the pasteBinary script to transform the target Oracle home to a proper Oracle home, creating or updating the necessary inventory information, file permissions, and string substitutions for the correct ORACLE_HOME path. See Section 19.3.3.

      You can use this method if your environment is located on one disk volume.

  5. Move a copy of the configuration of the domain and components. In most cases, you use the copyConfig, extractMovePlan, and pasteConfig scripts. The procedure you follow differs depending on your topology:

    • To move the configuration of a WebLogic Server domain containing only Java components, or Java components and system components, see Section 19.3.4.

    • To move the configuration of a standalone domain containing system components, see Section 19.3.5.

  6. In certain situations as described in Section 19.3.6, you must separately move a copy of the configuration of Node Manager if it is configured in the source environment.

  7. Start the servers and components. See Section 19.3.8.

19.3 Common Procedures for Moving to a Target Environment

Many of the Oracle Fusion Middleware components use some of the same procedures to move from a source environment to a target environment. Note, however that not all components use all or some these procedures. In addition, some components may require additional steps. You must check Table 19-2 to see if there are additional steps you need to take when moving a particular component.

This section describes the common procedures and contains the following topics:

The procedures in this section assume that you are using the standard installation topology. This topology consists of a WebLogic Server domain that contains an Administration Server and a cluster of two Managed Servers on one host or a standalone domain containing system components

If you have distributed your topology across multiple machines, see Section 19.6.

Note:

In the scripts used in these procedures and in the move plans, you often need to provide files containing passwords. To generate a file that contains an obfuscated password, use the obfuscatePassword script, which is described in Section A.1.1.10.

19.3.1 Installing the Database on the Target Environment

Some components, such as Oracle Application Development Framework, may use a database to store metadata.

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.

To install a new database:

  1. Install and configure the database software.

  2. Create the required schemas in the target database using RCU. See Creating Schemas with the Repository Creation Utility.

  3. 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.

19.3.2 Moving the Oracle Home and the Binary Files Using the Scripts

You can move a copy of the Oracle home to the target environment using the copyBinary and pasteBinary scripts:

  • The copyBinary script prepares the source and creates an archive. It also records the file permissions of the Oracle home.

    The archive contains the Oracle home, including the product homes, such as Oracle WebLogic Server home and the Oracle HTTP Server home.

  • The pasteBinary script checks to see that the prerequisites are met at the destination. It extracts the files from the archive file, registers the Oracle home with the Oracle inventory.

    The script then restores the file permissions and relinks any files if necessary.

Note the following:

  • The copyBinary and pasteBinary scripts do not carry over all the dependencies of the source Oracle home and the product homes, such as the WebLogic Server home, such as loadable modules or application-specific libraries to the target home, because the scripts proceed by copying the Oracle home and the entire source product homes to the destination Oracle home. Any files outside the source WebLogic Server or Oracle home are not automatically copied. Hence, any applications that refer to files outside the source WebLogic Server or Oracle home may not work properly in the target home.

  • When you copy an Oracle home, only the read-only portions of the Oracle home are copied. Any user configuration files, such as the user_projects directory, are excluded from the archive. The WebLogic Server domain is not copied. (Use the copyConfig and pasteConfig scripts to copy the domain.)

  • You cannot move an Oracle Home if its path is a symbolic link.

See:

Table A-1 for the location of the scripts used in this section.

To move the Oracle home:

  1. At the source, execute the copyBinary script, which copies the Oracle home and the product homes, such as the WebLogic Server home, contained within the Oracle home.

    See Section A.1.1.1 for the syntax of the copyBinary script.

    For example, to copy an Oracle home that is located at /scratch/oracle/Oracle_home1, use the following command:

    copyBinary.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
                  -archiveLoc /tmp/oh_copy.jar
                  -sourceOracleHomeLoc /scratch/oracle/Oracle_home1
                  -invPtrLoc /scratch/oracle/oraInst.loc
    
  2. If you are copying the Oracle home to a different host, copy the archive file to that system, or if you are using storage-level cloning, copy the snapshot copy of the volume to the target system and mount the volume.

  3. Copy the pasteBinary script and the cloningclient.jar file to the target system and ensure that they have execute permission.

    The cloningclient.jar file is located in:

    (UNIX) ORACLE_COMMON_HOME/jlib/cloningclient.jar
    (Windows) ORACLE_COMMON_HOME\jlib\cloningclient.jar
    

    Do not copy the other scripts, such as pasteConfig. Those scripts are generated when you extract the files, as in step 5.

  4. On Linux and UNIX, if the target system does not contain any installed Oracle products, you must create an oraInst.loc file, specifying a group whose members are given access to write to the Oracle inventory (oraInventory), and where you want to put Oracle inventory. For example, the oraInst.loc file could contain the following:

    inst_group=dba
    inventory_loc=/scratch/oracle1/oraInventory
    

    Then, if the location is not the default location (/etc/oraInst.loc.), use the -invPtrLoc option to the pasteBinary script to specify the location of the oraInst.loc file.

  5. At the target, extract the files from the archive using the pasteBinary script. See Section A.1.1.2 for the syntax of the pasteBinary script.

    Note:

    If the parent directory for the Oracle home does not exist, the pasteBinary script will create it.

    The actual directory for the Oracle home (for example, Oracle_Home_prod) cannot exist.

    For example, to apply the archive to the directory /scratch/oracle/ORACLE_HOME_prod, use the following command:

    pasteBinary.sh -javaHome /scratch/oracle/jdk1.7.0_17 
                   -archiveLoc  /tmp/oh_copy.jar 
                   -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod 
                   -targetOracleHomeName ORACLE_HOME_prod
    

    The Oracle home is extracted to /scratch/oracle/ORACLE_HOME_prod and the product homes are extracted under it with the same names as that of the source product home names.

  6. The copyBinary and pasteBinary scripts copy and paste any domain directories that are in the Oracle home, but not under the user_projects directory. These domain directories are not properly configured, so that they are not functional.

    Delete the domain directories from the target before you run the pasteConfig command, which will recreate properly configured domain directories on the target environment, as described in Section 19.3.4.

  7. At the target, if the Node Manager is per machine and is located under the Oracle home, delete the Node Manager directory and the files in it.

    In this situation, you will move the Node Manager configuration in Section 19.3.6.

19.3.3 Moving the Oracle Home and Binary Files Using Storage-Level Cloning Tools

As an alternative to the copyBinary script, you can use storage-level cloning tools, such as Oracle Solaris ZFS or NetApp Flex Cloning, to create a copy of an existing disk volume and move it to a different location.

You can use this method if your environment is located on one disk volume.

To move the Oracle home and binary files using storage-level cloning tools:

  1. Use the cloning tool to replicate the disk volume to the target environment.

    Refer to the documentation for your disk volume for more specific information.

  2. At the target, use the pasteBinary script using the -ohAlreadyCloned option. With this option, the pasteBinary script creates or updates the necessary inventory information, file permissions, and string substitutions for the correct ORACLE_HOME path.

    See Section A.1.1.2 for the syntax of the pasteBinary script.

    For example, to apply the archive to the directory /scratch/oracle/ORACLE_HOME_prod, use the following command:

    pasteBinary.sh -javaHome /scratch/oracle/jdk1.7.0_17 
                   -ohAlreadyCloned  true 
                   -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod 
                   -targetOracleHomeName ORACLE_HOME_prod
    
  3. At the target, if the Node Manager is "per machine" and is located under the Oracle home, delete the Node Manager directory and the files in it.

    In this situation, you will move the Node Manager configuration in Section 19.3.6.

  4. Because the storage-level cloning tools copy the entire user directory, it copies not just the binary files, but also the domain directories if they have been configured in the source environment. However, these domain directories are not properly configured, so that they are not functional.

    Delete the domain directories from the target before you run the pasteConfig command, which will recreate properly configured domain directories on the target environment, as described in Section 19.3.4.

19.3.4 Moving the Configuration of a WebLogic Server Domain

You can move a copy of the WebLogic Server domain configuration using the copyConfig, extractMovePlan, and pasteConfig scripts. This step moves a copy of the configuration, including the domain, the Administration Server and Managed Servers and any components in the domain. Then, it starts the Administration Server.

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. The pasteConfig script 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 Creating Templates and Domains Using the Pack and Unpack Commands.

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.

See:

Table A-1 for the location of the scripts used in this section.

Note:

By default, during the copyConfig and pasteConfig operations, the following, which specify the maximum heap size and the maximum permanent generation space, are set:

-Xmx512m -XX:MaxPermSize=256m

You can modify the values using the T2P_JAVA_OPTIONS parameter of the copyConfig and pasteConfig scripts.

To move a copy of the domain configuration:

  1. At the source, make sure that the Administration Server and all Managed Servers are started.

  2. At the source, make sure that the domain configuration is not set to automatically acquire locks. If you configured the domain in development mode, automatically acquiring locks is enabled. If you configured the domain in production mode, it is disabled by default. Take the following steps:

    1. In the Administration Console, click Preferences.

    2. In the User Preferences tab, clear Automatically Acquire Lock and Activate Changes.

    3. Click Save.

    4. In the Change Center, click Release Configuration, if applicable.

  3. At the source, copy the domain configuration by executing the copyConfig script.

    The copyConfig script is located in:

    (UNIX) ORACLE_COMMON_HOME/bin/copyConfig.sh
    (Windows) ORACLE_COMMON_HOME\bin\copyConfig.cmd
    

    See Section A.1.1.3 for the syntax of the copyConfig script.

    For example, to copy the configuration of the domain named WLS_domain1 in the Oracle home /scratch/oracle/Oracle_home1, use the following command:

    copyConfig.sh -javaHome /scratch/oracle/jdk1.7.0_17 
                  -archiveLoc /tmp/wls.jar
                  -sourceDomainLoc /scratch/oracle/domains/WLS_domain1
                  -sourceOracleHomeLoc /scratch/oracle/Oracle_home1
                  -domainHostName example.com
                  -domainPortNum 8001
                  -domainAdminUserName domain_admin_username
                  -domainAdminPasswordFile /scratch/admin/passwd.txt
                  -logDirLoc /tmp/logs
    
  4. If you are copying the domain configuration to a different host, copy the archive file to that system.

  5. At the source, extract the move plan from the archive, using the extractMovePlan script.

    See Section A.1.1.6 for the syntax of the extractMovePlan script.

    For example:

    extractMovePlan.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
                     -archiveLoc /tmp/wls.jar
                     -planDirLoc /tmp/Oracle/t2p_plans/wls
    

    Note:

    You must extract a new move plan each time you use the copyConfig script even if no changes have been made to the source environment. The pasteConfig scripts checks that the move plan and archive match. If they do not, the script returns an error.

  6. Edit the move plan, modifying the properties to reflect the values for the target environment. Edit all properties, such as host names, port numbers, listen addresses, that have different values in the target environment. See Table A-11 to find the list of properties for the type of component you are moving.

  7. Copy the edited move plan to the target. (During the pasteConfig operation, you specify the location using the -movePlanLoc option.)

  8. At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.

    (UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh
    (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
    

    The script prompts you to enter the password and the location where the password file is to be written.

  9. At the target, if the -opssDataExport parameter was set to true during the copyConfig operation (it is set to true by default), you must set the following environment variable, which sets the initial and maximum heap size:

    CONFIG_JVM_ARGS "-Xmx2048M -Xms2048M"
    
  10. At the target, extract the files from the archive using the pasteConfig script

    See Section A.1.1.7 for the syntax of the script.

    For example, to apply the archive to the Oracle home /scratch/oracle/Oracle_home1, use the following command:

    pasteConfig.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
                -archiveLoc /tmp/wls.jar
                -movePlanLoc /tmp/Oracle/t2p_plans/wls/moveplan.xml
                -targetDomainLoc /scratch/oracle/config/domains/WLS_domain1
                -targetOracleHomeLoc /scratch/oracle/Oracle_home1/
                -domainAdminPasswordFile /scratch/pwd_dir/passwd.txt
     
    
  11. If Managed Servers are not located 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 Creating Templates and Domains Using the Pack and Unpack Commands.

When you complete this task, you may need to perform additional steps for some components, as described in Section 19.4.

19.3.5 Moving the Configuration of a Standalone Domain

You can move the configuration of standalone domain containing system components. For example, you may have installed Oracle HTTP Server in a standalone domain.

See:

Table A-1 for the location of the scripts used in this section.

To move the configuration of a standalone domain containing system components:

  1. At the source, copy the configuration by executing the copyConfig script.

    See Section A.1.1.4 for the syntax of the copyConfig script.

    For example, to copy the configuration of the domain named WLS_domain1 in the Oracle home /scratch/oracle/Oracle_home1, use the following command:

    copyConfig.sh -javaHome /scratch/oracle/jdk1.7.0_17 
                   -archiveLoc /tmp/a.jar
                   -sourceDomainLoc /scratch/oracle/domains/WLS_domain1 
                   -sourceOracleHomeLoc /scratch/oracle/Oracle_home1/
    
  2. If you are copying the configuration to a different host, copy the archive file to that system.

  3. At the source, extract the move plan from the archive created by the copyConfig script, using the extractMovePlan script.

    See Section A.1.1.6 for the syntax of the extractMovePlan script.

    For example:

    extractMovePlan.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
                     -archiveLoc /tmp/wls.jar
                     -planDirLoc /tmp/Oracle/t2p_plans/wls
    

    Note:

    You must extract a new move plan each time you use the copyConfig script even if no changes have been made to the source environment. The pasteConfig scripts checks that the move plan and archive match. If they do not, the script returns an error.

  4. Edit the move plan, modifying the properties to reflect the values for the target environment. See Table A-11 to find the list of properties for the type of component you are moving.

  5. Copy the edited move plan to the target. (During the pasteConfig operation, you specify the location using the -movePlanLoc option.)

  6. At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.

    (UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh
    (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
    

    The script prompts you to enter the password and the location where the password file is to be written.

  7. At the target, extract the files from the archive using the pasteConfig script

    See Section A.1.1.7 for the syntax of the script.

    For example, to apply the archive to the Oracle home /scratch/oracle/Oracle_home1, use the following command:

    pasteConfig.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
                -archiveLoc /tmp/java_ee_cl.jar
                -targetDomainLoc /scratch/oracle/config/domains/dom_cl
                -targetOracleHomeLoc /scratch/oracle/Oracle_home1 
                -movePlanLoc /scratch/oracle/java_ee/move_plan.xml
                -logDirLoc /tmp/log
    

19.3.6 Moving the Configuration of Node Manager

If Node Manager is configured in the source environment, you must separately move Node Manager in the following circumstances:

  • The Node Manager is "per machine".

  • The Node Manager is "per domain" but its configuration is located outside of the domain directory.

  • In an environment on multiple hosts, the Node Manager is "per domain" and its configuration is within the domain directory, but each host has customized Node Manager properties that are applicable to only that host.

If the Node Manager is per domain, the scripts for moving the domain also move the Node Manager.

See:

Table A-1 for the location of the scripts used in this section.

To move the Node Manager configuration:

  1. At the source, copy the Node Manager configuration, by executing the copyConfig script.

    See Section A.1.1.5 for the syntax of the script. For example, use the following command:

    copyConfig.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
                  -archiveLoc /tmp/nm.jar
                  -sourceNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager
                  -logDirLoc /tmp/logs
    
  2. If you are copying the Node Manager to a different host, copy the archive file to that system.

  3. At the source, extract the move plan from the archive, using the extractMovePlan script.

    See Section A.1.1.6 for the syntax of the extractMovePlan script.

    For example:

    extractMovePlan.sh -javaHome /scratch/oracle/jdk1.7.7.0_17
                     -archiveLoc /tmp/nm.jar
                     -planDirLoc /tmp/Oracle/t2p_plans/nm
    
  4. Edit the move plan, modifying the properties to reflect the values for the target environment. See Table A-14 to find the list of properties for Node Manager.

  5. Copy the edited move plan to the target. (During the pasteConfig operation, you specify the location using the -movePlanLoc option.)

  6. At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.

    (UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh
    (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
    

    The script prompts you to enter the password and the location where the password file is to be written.

  7. At the target, extract the files from the archive using the pasteConfig script.

    See Section A.1.1.9 for the syntax of the script.

    For example, use the following command:

    pasteConfig -javaHome /scratch/oracle/jdk1.7.7.0_17
                -archiveLoc /tmp/nm.jar
                -targetNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager
                -targetOracleHomeLoc /scratch/oracle/Oracle_home1
                -movePlanLoc /tmp/Oracle/t2p_plans/nm/moveplan.xml
    

19.3.7 Configuring Users and Groups

You must configure security in the new target environment. The steps you take depends on the configuration of your environment and application.

The target environment LDAP identity store may not use the same users and groups as the source environment, or it may already be populated with users and groups. Take the following steps only if the LDAP store is an Oracle Internet Directory LDAP store and you need to move users, groups, and passwords from the source environment to the target environment:

  1. Export the users and groups from LDAP identity store on the source environment, using the ldapsearch command. This produces an ldif file that you later import into the LDAP identity store in the target environment. The ldapsearch command is located in the ORACLE_HOME/bin directory of the Identity Management components. For example:

    ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port 
      -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
    
  2. Import the ldif file that you exported from the source environment into the target environment, using the ldapaddmt command, as shown in the following example. (ORACLE_HOME is the Oracle home for Identity Management.)

    ORACLE_HOME/bin/ldapaddmt -h production_oid_host
       -p production_oid_port -D "cn=orcladmin"
       -w "production_orcladmin_passwd" -r -f ldif_filename
    

19.3.8 Starting Managed Servers and Components

When the movement procedure completes, the Administration Server is started. However, the Managed Servers, Node Manager, and the components are stopped. Take the following steps:

  1. Start Node Manager, as described in Section 4.2.2.

  2. Start the Managed Servers, as described in Section 4.2.3

  3. Start components, as described in Section 4.3.

19.4 Additional Steps for Certain Components

Table 19-2 shows whether any additional steps are needed to complete the movement of particular components:

Table 19-2 Components Requiring Additional Steps for Movement to a Different Environment

Component Additional Procedures

Oracle Application Development Framework

None

Oracle Coherence

None

Oracle Data Integrator

See Section 19.4.1

Oracle HTTP Server

None

Oracle User Messaging Service

None

Oracle Web Services Manager

None

Oracle WebLogic Server

None


19.4.1 Additional Steps for Moving Oracle Data Integrator

Note the following additional steps that you must take when moving Oracle Data Integrator:

  • Create the required master and work repositories schemas in the target database using RCU. See the Creating Schemas with the Repository Creation Utility.

    Make sure that the target work repository is created with the same type as the source repository (For example, if the source work repository is created as a development repository, the target work repository must also be created as a development repository).

  • When you run the copyConfig script, note the following:

    • You must pass a configuration file to the copyConfig script. You pass this using the -additionalParams option with the argument odiCustomArg. For example:

      ./copyConfig.sh -javaHome /private/Middleware/jrockit_160_26_D1.2.0-5
         -archiveLocation /tmp/ar.jar 
         -sourceOracleHomeLoc /private/Middleware 
         -sourceDomainLoc /scratch/oracle/domains/base_domain 
         -domainHostName host1.example.com 
         -domainPortNo 7001 
         -domainAdminUserName weblogic 
         -domainAdminPasswordFile /tmp/wls_pswd.txt 
         -additionalParams odiCustomArg=/private/t2p/odiCustomArg.xml
      

      The file odiCustomArg.xml is the configuration file. A sample file is located in:

      ORACLE_HOME/ODI_Oracle_Home/odi/pluggin/t2p/odiCustomArg.xml
      

      The configuration file that you pass to the script contains the connection information for all Oracle Data Integrator master repositories. The following shows a sample configuration file:

      <?xml version="1.0" encoding="UTF-8" ?>
      <config>
         <masterRepositories>
             <masterRepository>
                 <driver>oracle.jdbc.OracleDriver</driver>
                 <url>jdbc:oracle:thin:@localhost:1521:sid_or_service_name/example.com</url>
                 <schema>odi_master_11g</schema>
                 <schema_password_file>/tmp/all_pswd.txt</schema_password_file>
                  <supervisor>SUPERVISOR</supervisor>
                  <supervisor_password_file>/tmp/sup_pswd.txt</supervisor_password_file>
             </masterRepository>
             <masterRepository>
                              .....content for 2nd master repository
             </masterRepository>
          </masterRepositories>
      </config> 
      

      The following explains the entries in the configuration file:

      • masterRepositories: Contains the list of ODI Master Repositories.

      • masterRepository: The section for ODI Master Repositories.

      • driver: The JDBC Driver to connect to the ODI Master Repository.

      • url: The JDBC URL to connect to the ODI Master Repository.

      • schema: The schema name for the ODI Master Repository.

      • schema_password_file: The path for the file containing the password for the schema.

      • supervisor: The supervisor user for the ODI Master Repository.

      • supervisor_password_file: The path for the file containing the password for the supervisor user.

  • The movement scripts update the physical architecture in the target environment according to the information you specified in the move plan. Review the following items in the physical architecture in the target environment before proceeding:

    • Physical Agents: Change the host, port, and Web application context (for Java EE Agent) to match the configuration of the target environment.

    • Data Servers: Change the data server connection information (JDBC, JNDI, data source name) to match the configuration of the target environment.

    • Physical Schemas: The schemas (including file folder location) defined for the data servers must match the configuration of the target environment.

  • After you complete the movement, restart the Java EE agents in the target environment. These agents start processing the scheduled scenarios.

19.5 Incrementally Moving Artifacts

The movement scripts are intended for moving to a new target environment. They do not support moving artifacts to an already existing environment.

If you have already moved your environment to a new target, at some later time, you may want to move artifacts that have changed in your source environment to your target environment. For information about moving artifacts that have changed, see the documentation for the particular component, such as Oracle HTTP Server.

19.6 Moving Distributed Topologies

The following topics describe considerations when you have a distributed topology:

19.6.1 Considerations with a Multiple Host Environment

If your domain is distributed across multiple hosts, you must take additional steps to complete the movement.

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.)

These steps assume that you have taken the steps in Section 19.3 on the Administration Server host:

  1. If you do not use shared disks, use the pasteBinary command to create an Oracle home on the remote host, for example, Host B. You use the same archive that you created in Section 19.3.2 Step 1.

    For example:

    pasteBinary.sh -javaHome /scratch/oracle/jdk1.7.0_17 
                   -archiveLoc  /tmp/oh_copy.jar 
                   -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod 
                   -targetOracleHomeName ORACLE_HOME_prod
    
  2. Re-create the domain directory for the remote Managed Servers by using the Oracle WebLogic Server pack and unpack commands. For more information, see Creating Templates and Domains Using the Pack and Unpack Commands.

19.6.2 Considerations in Moving to and from an Oracle RAC Environment

If you are moving your environment to or from an Oracle Real Application Cluster (Oracle RAC) environment, note the following:

  • If you are moving from a source environment that is not an Oracle RAC environment to a target environment that uses Oracle RAC, the move plan will have one entry for a generic data source (for example mds-adf.) You update the move plan to point to one of the Oracle RAC instances and complete the move from the source environment to the target environment.

    Then, you configure your target environment for Oracle RAC, as described in the High Availability Guide, especially "Database Considerations."

  • Multi data sources are moved to the target environment, even though they are not listed in the move plan.

  • If you are moving from a source environment that uses Oracle RAC to a target environment that does not use Oracle RAC, the move plan will have multiple entries for generic data sources. For example, if you have four Oracle RAC instances, you will have four generic data sources that are named mds-adf-rac1 through mds-adf-rac4. You update the move plan to point all generic data sources to the single non-RAC instance in the target environment.

  • If you are moving from a source environment that uses Oracle RAC to a target environment that uses Oracle RAC, but you have more Oracle RAC instances in the target environment, the move plan will have multiple entries for generic data sources. For example, if you have three Oracle RAC instances on the source environment, you will have three generic data sources that are named mds-adf-rac1 through mds-adf-rac3. You have four Oracle RAC instances in the target environment. You update the move plan to point the generic data sources to the first three generic data sources in the target environment.

  • If you are moving from a source environment that uses Oracle RAC to a target environment that uses Oracle RAC, but you have fewer Oracle RAC instances in the target environment, the move plan will have multiple entries for generic data sources. For example, if you have four Oracle RAC instances on the source environment, you will have four generic data sources that are named mds-adf-rac1 through mds-adf-rac4. You have three Oracle RAC instances in the target environment. You update the move plan to point the first three generic data sources to the three generic data sources in the target environment. You point the last generic data source to the third generic data source. (The third Oracle RAC instance will contain both mds-adf-rac3 and mds-adf-rac4).

    Then, you can add an additional data source, as described in Section 9.2.2.1.

19.7 Recovering from Test to Production Errors

When you execute the pasteBinary or pasteConfig scripts and enter incorrect information in the move plan, the scripts return an error. In some cases, the scripts may have partially completed the paste operation. To recover, take the following actions, depending on the script that returned the error:

  • On Windows if you are using the Sun JDK, the copyBinary, pasteBinary, copyConfig, or pasteConfig operations may fail with the following error:

    java.nio.channels.OverlappingFileLockException
    

    In this case, use the T2P_JAVA_OPTIONS to set the system property sun.nio.ch.disableSystemWideOverlappingFileLockCheck as shown in the following example:

    set T2P_JAVA_OPTIONS=
    -Dsun.nio.ch.disableSystemWideOverlappingFileLockCheck=true
    

    Then, retry the operation.

  • If the pasteBinary script returns an error while moving the Oracle home directory at the target:

    1. Delete the target Oracle home.

    2. Remove the Oracle home entry from the Oracle inventory, if it is present.

    3. For Windows, remove the shortcut for the Oracle home.

  • The copyConfig script requires that all servers be running, but that they are idle, so that no directories are being modified. If a server is not idle, the copyConfig script reports that the cloning operation completed successfully and the copyConfig error log file will remain at 0 bytes. However, the copyConfig standard log file will contain an error regarding writing to the packed_domain.jar. That error will cause the pasteConfig process to fail.

    To work around this issue, wait for a short period of time, then retry the copyConfig operation again.

  • If the pasteConfig script returns an error while moving Java components:

    1. Stop all processes related to the domain.

    2. Delete the following directories:

      ORACLE_HOME/user_projects/domains/domain_name
      ORACLE_HOME/user_projects/applications/domain_name
      
    3. Drop the schemas and re-create them using RCU.

    In addition, if the Oracle Platform Security reassociation failed:

    • If you are moving from a file-based store to an LDAP store, specify a different value in the move plan.

    • For an LDAP store, delete the domain node.

    • For a database-based store, drop the schema and re-create it using RCU.

  • If you encounter an out-of-memory error when you are using the pasteConfig script, you can work around this in one of the following ways:

    • Increase the JVM heap size: Use the option -Xmx for maximum heap size, and -Xms for initial heap size. For example:

      CONFIG_JVM_ARGS="-Xms512m -Xmx1024m"
      
    • Often, the Oracle WebLogic Server domain directory structure contains some large, unnecessary files, such as large older log files. You can delete these files, then run the copyConfig and pasteConfig scripts again.

  • If you are moving Oracle Identity Manager, the pasteConfig script may generate the following error:

    NOTIFICATION: PManager instance is created without multitenancy support as
    JVM flag "oracle.multitenant.enabled" is not set to enable multitenancy
    support.
    Sep 24, 2013 10:26:55 PM
    oracle.security.jps.internal.config.xml.XmlConfigurationFactory
    initDefaultConfiguration
    SEVERE: java.io.FileNotFoundException: ./config/jps-config.xml (No such file
    or directory)
    Sep 24, 2013 10:26:55 PM oracle.mds
    NOTIFICATION: Auditing is disabled for component MDS.
    Sep 24, 2013 10:26:55 PM oracle.mds
    NOTIFICATION: PManager instance is created without multitenancy support as
    JVM flag "oracle.multitenant.enabled" is not set to enable multitenancy
    support.
    Sep 24, 2013 10:26:55 PM
    oracle.security.jps.internal.config.xml.XmlConfigurationFactory
    initDefaultConfiguration
    SEVERE: java.io.FileNotFoundException: ./config/jps-config.xml (No such file
    or directory)
    Sep 24, 2013 10:26:55 PM oracle.mds
    NOTIFICATION: Auditing is disabled for component MDS.
    Sep 24, 2013 10:26:55 PM oracle.mds
     
    

    This error is benign and can be safely ignored.