Note:
Moving your environment from a test to a production environment is deprecated in this release. It will not be supported in a future release.Topics:
Note:
The procedures in this chapter are valid for Oracle Fusion Middleware 12c (12.2.1.1) 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 Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure.
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.
Before you move your environment, you should understand the movement scripts, check the source environment, prepare the target environment, and understand the limitations and restrictions.
This section describes important information that you should know before you begin moving your environment. It includes the following topics:
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 as an .xml file (called moveplan.xml) and other files from the archive file created by the copyConfig operation.
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 and Oracle SOA Suite.
Table 20-1 shows which Oracle Fusion Middleware components support the movement scripts.
Table 20-1 Support for Movement Scripts
Component | Supported? |
---|---|
Oracle Application Development Framework |
Yes |
Oracle B2B |
Yes |
Oracle B2B for Healthcare |
Yes |
Oracle Business Activity Monitoring |
Yes |
Oracle Business Intelligence |
No |
Oracle Business Process Management |
Yes |
Oracle Coherence |
Yes |
Oracle Data Integrator |
Yes |
Oracle Enterprise Data Quality |
Yes |
Oracle Enterprise Scheduler |
Yes |
Oracle Forms Services |
Yes |
Oracle HTTP Server |
Yes |
Oracle HTTP Server WebGate |
Yes |
Oracle Managed File Transfer |
Yes |
Oracle Reports |
No |
Oracle Platform Security Services |
Yes |
Oracle Real-Time Integration Business Insight |
No. However, domains that contain Insight can be moved using the scripts. You can move the Insight configuration, particularly Models, Connections and Consoles by exporting them from the source and importing them into the target after you run the scripts. |
Oracle Service Bus |
Yes |
Oracle SOA Suite |
Yes |
Oracle Traffic Director |
Yes |
Oracle User Messaging Service |
Yes |
Oracle Web Services Manager |
Yes |
Oracle WebCenter Capture |
Yes |
Oracle WebCenter Content |
Yes |
Oracle WebCenter Portal |
Yes |
Oracle WebCenter Sites |
Yes |
Oracle WebLogic Server |
Yes |
Many of the components have specific move plan properties, as described in Table A-11.
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 Oracle SOA Suite.
Created the needed schemas in the source environment using RCU. See Oracle Fusion Middleware 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 Services, created security policies and stored credentials in the Credential Store Framework (CSF).
Deployed one or more applications or SOA Composite applications. The applications may have internal and external references.
Also, note the following about the source environment:
Before you execute the copyConfig script in a WebLogic Server domain, make sure that the Administration Server and Managed Servers are running.
On Windows, before you execute the copyConfig script in a WebLogic Server domain, you must shut down Node Manager if the environment is a WebLogic Server domain with system components. The Administration server and Managed Servers must be running, but the system components should not be running
On operating systems other than Windows, for WebLogic Server domains and standalone domains, 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.
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.
Oracle Fusion Middleware supports two types of keystores:
JKS: Java Keystore
KSS: Oracle Platform Security Services Keystore Service. The Keystore Service is available only if you created a domain that includes Oracle JRF.
Keystore-related properties are populated for all servers in the move plan in the following circumstances:
If SSL is enabled (either the Administration Server port or the SSL port of the Administration Server) in the source domain, irrespective of which keystores configured.
If only non-SSL ports are enabled in the source domain and the keystores of the Administration Server are one of the following types:
CustomIdentityandCustomTrust
CustomIdentityandJavaStandardTrust
CustomIdentityandCommandLineTrust
If only non-SSL ports are enabled and DemoIdentityAndDemoTrust keystores are configured in the source domain, the keystore-related properties are not populated in the move plan.
Irrespective of how the source environment is configured, note the following about how the move plan properties must be configured before you move the configuration to the target using the pasteConfig script:
For domains configured with Oracle JRF:
All servers must have the same keystores.
The keystore type (JKS or KSS) must be the same across all servers.
You can modify the move plan to change the keystore type from JKS to KSS or KSS to JKS.
For domains not configured with Oracle JRF:
All servers must have the same keystores.
You can only use JKS keystores.
You can change keystores from source to target both for domains configured with Oracle JRF and those configured without Oracle JRF. Except when the source is only non-SSL and DemoIdentityAndDemoTrust, you can change the value of the keystore to one of following, whatever the value of keystores are at source:
DemoIdentityAndDemoTrust
CustomIdentityAndCustomTrust
CustomIdentityAndJavaStandardTrust
CustomIdentityAndCommandLineTrust
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, such as pasteBinary, 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 host must have JDK 1.8.0_x or higher installed.
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 source environment uses a consolidated schema and consolidated data sources, the target environment must use a similar consolidated schema, with the exact same constituent schemas.
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.
If the source environment is an SSL-only environment, make sure that you configure the keystores and credentials in the source environment before you execute the movement scripts.
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_HOME/oracle_common/bin/pasteBinary.sh (Windows) ORACLE_HOME\oracle_common\bin\pasteBinary.cmd
Note that on Windows, you do not copy pasteBinary.sh.
Copy the following file in the source host to the target host:
(UNIX) ORACLE_HOME/oracle_common/jlib/cloningclient.jar (Windows) ORACLE_HOME\oracle_common\jlib\cloningclient.jar
If you run the pasteBinary script from a different location than ORACLE_HOME/oracle_common/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_HOME/oracle_common/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.
The ports that you specify in the move plans must be available on the target machine.The pasteConfig script checks that the specified ports are available.
On Windows, the file MSVCR90.DLL must exist on the target host. Otherwise, pasteConfig will fail.
This file (or various versions of it) are located in the directory tree underneath:
(Windows 32 bit) C:\Windows\System32 (Windows 64 bit) C:\Windows\winsxs
On Windows, to successfully move Oracle Traffic Director and Oracle HTTP Server, MS Visual C++ version 12.0 must be installed.
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.
The movement scripts do not support domains that use multi-tenancy.
The movement scripts do not support WebSphere-based environments.
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.
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.8, the target must use 1.8.
You cannot use the same shared security store for more than one domain.
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 Movement Scripts Syntax.
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.
The movement scripts do not support dynamic cluster configuration.
To work around this, disable dynamic cluster configuration before you execute the copyConfig script. Then, after you execute the pasteConfig script, you can enable it.
If Oracle Service Bus is configured in the domain, during the pasteConfig operation, when the Administration Server is started for the first time, you may see the following error:
Failed to initialize the application "Service Bus Framework Starter Application" due to error java.lang.RuntimeException: OSB system user authentication failed java.lang.RuntimeException: OSB system user authentication failed
You can ignore this error.
This section describes the general steps in moving installations from a source environment to a target environment. Figure 20-1 shows a flowchart illustrating the steps.
Figure 20-1 Flowchart for Moving Your Environment
The general steps are:
Check your source environment. See Checking the Source Environment.
Prepare your target environment. See Preparing the Target Environment.
If your environment uses a database, create a new database. See Installing the Database on the Target Environment.
Move a copy of the binary files in the Oracle home from the source environment to the target environment
Using the copyBinary and pasteBinary scripts, as described in Moving the Oracle Home and the Binary Files Using the Scripts.
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 Moving the Oracle Home and Binary Files Using Storage-Level Cloning Tools.
You can use this method if your environment is located on one disk volume.
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 Moving the Configuration of a WebLogic Server Domain.
To move the configuration of a standalone domain containing system components, see Moving the Configuration of a Standalone Domain.
In certain situations, as described in Moving the Configuration of Node Manager, you must separately move a copy of the configuration of Node Manager if it is configured in the source environment.
Take any additional steps that are required for some components. See Additional Steps or Information for Certain Components for information specific to each component.
Move other data, such as UMS user messaging preferences or data for the Oracle WebCenter Portal application. Modify any information that is specific to the new environment such as host name or ports. See Additional Steps or Information for Certain Components for information specific to each component.
Start the servers and components. See Starting Managed Servers and Components.
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 20-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:
Moving the Oracle Home and the Binary Files Using the Scripts
Moving the Oracle Home and Binary Files Using Storage-Level Cloning Tools
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 Moving Distributed Topologies.
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 obfuscatePassword Script and API.
Some components, such as Oracle Application Development Framework and Oracle SOA Suite, 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.
You can install a new database or you can copy the database from the source environment:
Install a new database. You can use this for most components, except Identity Management components. Take the following steps:
Install and configure the database software.
Create the required schemas in the target database using RCU. See the Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility.
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. Use this method if you are moving Identity Management components. The duplicate database must be created with a different DBID than the source database, so that it functions entirely independently.
Note:
The RMAN utility refers to the source database (that is the original database) as the target database. It refers to the database that is created with the DUPLICATE command as the auxiliary database.
In the following steps, the source database name is referred to as test_DB_name; the target (auxiliary) database name is referred to as prod_DB_name.
To create a duplicate Oracle Database in the target environment:
On the target environment, install the Oracle Database software, but do not create a database. To do this, select Install Database Software only in the Select Configuration Option screen.
Note that the Oracle Database RMAN documentation refers to this as the auxiliary host.
On the target environment, create a password file. The path of the file should be:
ORACLE_HOME/dbs/orapwSID
The sys password must be the same as the password for the sys account in the database in the source environment. Use the following commands:
setenv ORACLE_HOME /scratch/dbhome/ setenv ORACLE_SID SID $ORACLE_HOME/bin/orapwd password= password file=$ORACLE_HOME/dbs/orapwSID
On the target environment, create the startup pfile in the following location:
$ORACLE_HOME/dbs/initSID.ora
Note that the file name for init
SID
.ora
is crucial and is case-sensitive.
Enter the following into the file:
DB_NAME=prod_DB_name db_recovery_file_dest='/full_path_to_DBHOME/dest_file_recovery_db' DB_RECOVERY_FILE_DEST_SIZE=2048m *.remote_login_passwordfile='EXCLUSIVE' *.local_listener='LISTENER_prod_DB_name' audit_trail='NONE' audit_file_dest='/full_path_to_DBHOME/audtrl'
The directories for the db_recovery_file_dest and audit_file_dest must exist. Create them if they do not exist.
On the target environment, create the following file, which you will execute in a subsequent step:
ORACLE_HOME/dbs/dup.cmd
Enter the following information in the file. In the example, the source database has the database name test_DB_name
. The duplicate database has the database name prod_DB_name
:
run { allocate channel c1 device type disk; allocate auxiliary channel c2 device type disk ; DUPLICATE TARGET DATABASE to prod_DB_name FROM ACTIVE DATABASE NOFILENAMECHECK SPFILE SET DB_name='prod_DB_name' SET DB_UNIQUE_NAME='prod_DB_name' SET LOG_FILE_NAME_CONVERT 'test_DB_name','prod_DB_name' SET DB_FILE_NAME_CONVERT 'test_DB_name','prod_DB_name' SET audit_file_dest='/full_path_to_DBHOME/audtrl' SET CONTROL_FILES='/full_path_to_DBHOME/dup.ctl' set db_recovery_file_dest_size '1G' set db_recovery_file_dest='/full_path_to_DBHOME/dest_file_recovery_db' SET diagnostic_dest='/full_path_to_DBHOME'; }
On the target, create the following directory for the data files:
/full_path_to_DBHOME/oradata/prod_DB_name
On the target environment, create the following file:
ORACLE_HOME/network/admin/listener.ora
Add the following to the file
LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num)) ) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = prod_DB_name) (ORACLE_HOME = /full_path_to_prod_DBHOME) (GLOBAL_DBNAME = prod_DB_name) ) (SID_DESC = (SID_NAME = test_DB_name ) )
On the target environment, create the following file:
ORACLE_HOME/network/admin/tnsnames.ora
Add the following to the file:
test_DB_name = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = test_DB_name.host.domain) ) ) LISTENER_test_DB_name = (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num)) prod_DB_name = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = prod_DB_name) (SERVICE_NAME = prod_DB_name) ) ) LISTENER_prod_DB_name = (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num)
On the source environment, edit the tnsnames.ora file, adding an entry for the database on the target environment.
prod_DB_name = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = host_name) (PORT = port_num)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = prod_DB_name) (SERVICE_NAME = prod_DB_name) ) ) LISTENER_prod_DB_name = (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num))
On the source environment, edit the listener.ora file, adding an entry for the database on the target environment.
The following shows the added entry:
LISTENER_prod_DB_name = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.2.4) (PORT = 1521)(IP = FIRST)) ) ) SID_LIST_LISTENER_prod_DB_name = (SID_LIST = (SID_DESC = (SID_NAME = prod_DB_name) (ORACLE_HOME = full_path_to_ORACLE_HOME) ) )
On the source, start the listener:
setenv ORACLE_HOME full_path_to_ORACLE_HOME setenv ORACLE_SID test_DB_SID $ORACLE_HOME/bin/lsnrctl start
On the source, start the database. Use the following SQLPlus command:
$ORACLE_HOME/bin/sqlplus " /as sysdba" SQL> STARTUP NOMOUNT PFILE='ORACLE_HOME/dbs/pfile'
Validate that the source database has Archive Log mode enabled.
SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST
If Archive Log mode is not enabled, execute the following commands:
SQL> shutdown immediate; SQL> startup mount; SQL> alter database archivelog; SQL> alter database open; SQL> alter system archive log current;
On the target, start the database in NOMOUNT mode. For example:
SQL> STARTUP NOMOUNT PFILE='ORACLE_HOME/dbs/pfile'
On the target, change to the directory that contains the file created in Step 4. For example:
cd ORACLE_HOME/dbs
On the target, use RMAN to connect to the source and duplicate databases:
ORACLE_HOME/bin/rman TARGET sys/password@test_DB_name AUXILIARY sys/password@prod_DB_name
On the target, run the file created in Step 4.
RMAN> @dup.cmd
RMAN automatically copies the server parameter file to the destination host, starts the auxiliary instance with the server parameter file, copies all necessary database files and archived redo logs over the network to the destination host, and recovers the database. Finally, RMAN opens the database with the RESETLOGS option to create the online redo logs.
For detailed steps, see the Oracle Database Backup and Recovery User's Guide.
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:
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:
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.
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 Oracle Fusion Middleware 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:
If you are using an IBM JDK, set the maximum permanent generation space (-XX:MaxPermSize=
value
) using the T2P_JAVA_OPTIONS parameter of the copyConfig and pasteConfig scripts.
To move a copy of the domain configuration:
At the source, make sure that the Administration Server and all Managed Servers are started.
For an Oracle SOA Suite that has an SSL-only environment, enable SSL, as described in Configuring SSL in the Oracle Fusion Middleware Administering Oracle SOA Suite and Oracle Business Process Management Suite.
On Windows, before you execute the copyConfig script in a WebLogic Server domain, you must shut down Node Manager if the environment is a WebLogic Server domain with system components.
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:
In the Administration Console, click Preferences.
In the User Preferences tab, clear Automatically Acquire Lock and Activate Changes.
Click Save.
In the Change Center, click Release Configuration, if applicable.
At the source, run the following script to generate an obfuscated password file for the domainAdminPasswordFile parameter.
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh -javaHome path_to_java_home (Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
The script prompts you to enter the password and the path, including the file name, where the password file is to be written.
At the source, copy the domain configuration by executing the copyConfig script.
The copyConfig script is located in:
(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh (Windows) ORACLE_HOME\oracle_common\bin\copyConfig.cmd
See copyConfig Script for Oracle WebLogic Server Domains 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.8.0_40 -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
For Oracle Service Bus, when you use the copyConfig script, you must pass it the -additionalParams
option, with the key osb.configuration.passphrase.file
and the key value specifying the absolute path to the file containing the passphrase. For example:
-additionalParams osb.configuration.passphrase.file=/scratch/passwd/osb_passwd
If you do not specify this option, the exported configuration will not be password protected.
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 for the syntax of the extractMovePlan script.
For example:
extractMovePlan.sh -javaHome /scratch/oracle/jdk1.8.0_40 -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.
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.
For the Oracle WebCenter Content server or Oracle WebCenter Content: Records, you specify one of the following options in the move plan:
copy: This option copies the entire source system, including configuration and data, to the target system. Although this is the default, Oracle does not recommend using this option because it moves test data, which might not be appropriate for your environment.
init: This option initializes a new Content Server or Records instance in the target system. It does not move data.
You specify the copy or init option in the move plan, in the MoveType configProperty, as described in Table A-26. Then, you modify the properties listed in that configGroup.
See Additional Information and Procedures for Moving Oracle WebCenter Content for information about these options.
If the extractMovePlan script generated deployment plans, update the Oracle home and domain home location in the deployment plan file, which is located at:
planDirLoc/deployment_plans
Copy the edited move plan, along with any folders created by the extractMovePlan script, to the target. (These folders are located in the location specified by the planDirLoc parameter.)
During the pasteConfig operation, you specify the location using the -movePlanLoc option.
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_HOME/oracle_common/bin/obfuscatePassword.sh -javaHome path_to_java_home (Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
The script prompts you to enter the password and the path, including the file name, 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 WebLogic Server Domains 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.8.0_40 -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
If Managed Servers are not located on the same host 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.
Configure users and groups, as described in Configuring Users and Groups.
When you complete this task, you may need to perform additional steps for some components, as described in Additional Steps or Information for Certain Components.
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:
If Node Manager is configured in the source environment, you must separately move Node Manager in the following circumstances:
The Node Manager is "per host."
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:
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 Fusion Middleware Administering Oracle WebCenter Enterprise Capture LDAP store and you need to move users, groups, and passwords from the source environment to the target environment:
If you are moving an environment that is configured for SSL only, note the following:
On Windows, for an SSL-only environment with Demo KSS certificates, set the following environment variable before starting Managed server:
set JAVA_OPTIONS=-Dweblogic.security.SSL.ignoreHostnameVerification=true
Then, start the Managed Server using the additional parameter noted in the next item.
For an SSL-only environment with Demo KSS certificates, pass the following additional parameter to start the Managed Server:.
-Dweblogic.security.SSL.ignoreHostnameVerification=true)
For example:
StartManagedWebLogic.sh Managed_Server_name https://hostname:port_num -Dweblogic.security.SSL.ignoreHostnameVerification=true
For an SSL-only environment with custom JKS certificates, take one of the following steps:
Before starting the Managed Servers, import the certificates to the target, using a command similar to the following:
keytool -importcert -trustcacerts -alias hostalias -file /scratch/oracle/keystores/hostalias_identity_exportcert.cer -keystore /scratch/oracle/ORACLE_HOME/wlserver/server/lib/cacerts -storepass changeit
Explicitly pass the trust keystore location when you start the Managed Server. For example:
startManagedWebLogic.sh Managed_Server_name https://hostname:port_num "-Dweblogic.security.SSL.trustedCAKeyStore=/scratch/Oracle/keystores/Hostname_trust.jks"
When the movement procedure completes, the Administration Server, Managed Servers, Node Manager, and the components are stopped. Take the following steps:
Some components require additional step to complete the movement process from a test to a production environment.
Table 20-2 shows whether any additional steps are needed to complete the movement of particular components or provides additional information.
Table 20-2 Components Requiring Additional Steps for Movement to a New Environment
Component | Additional Procedures |
---|---|
Oracle Application Development Framework |
None |
Oracle B2B |
|
Oracle Business Activity Monitoring |
None |
Oracle Business Process Management |
See Additional Steps for Moving Oracle Business Process Management |
Oracle Coherence |
None |
Oracle Data Integrator |
|
Oracle Enterprise Data Quality |
None |
Oracle Enterprise Scheduler |
None |
Oracle Forms Services |
|
Oracle HTTP Server |
None |
Oracle Managed File Transfer |
None |
Oracle Service Bus |
See Step 6 in Moving the Configuration of a WebLogic Server Domain |
Oracle SOA Suite |
None |
Oracle Traffic Director |
|
Oracle User Messaging Service |
None |
Oracle WebCenter Content |
See Additional Information and Procedures for Moving Oracle WebCenter Content for information about using the |
Oracle WebCenter Portal |
|
Oracle WebCenter Sites |
|
Oracle Web Services Manager |
None |
Oracle WebLogic Server |
None |
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 Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility.
Make sure that both the work and master repositories in the target environment are created with unique IDs across your entire organization, including your development and source repositories. Also 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).
The ODI Work Repository Name, created as part of RCU's Custom Variables for Oracle Data Integrator, is reflected as <configProperty id="WORKREP1"> in the moveplan.xml file, as shown in the following example:
... <configProperty id="WORKREP1"> <configProperty> <name>Url</name> <value>jdbc:oracle:thin:@localhost:1521:ora1120</value> <itemMetadata> <dataType>STRING</dataType> <scope>READ_WRITE</scope> </itemMetadata> </configProperty> <configProperty> <name>User</name> <value>odi_work_11g</value> <itemMetadata> <dataType>STRING</dataType> <scope>READ_WRITE</scope> </itemMetadata> </configProperty> <configProperty> @ <name>Password File</name> <value>/tmp/all_pswd.txt</value> <itemMetadata> <dataType>STRING</dataType> @ <password>true</password> <scope>READ_WRITE</scope> </itemMetadata> </configProperty> </configProperty> ...
It is important to note that if default ODI Work Repository name, WORKREP
reflected as WORKREP1
in the moveplan.xml, is changed, the corresponding name change is correctly modified and followed in the production environment.
For more details about creating schemas, see Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility. Additional information is provided in the Online Help for RCU.
Create Projects and Models by using the ODI Client (Studio) before running the movement scripts.
When you run the copyConfig script, note the following:
You must pass a configuration file to the copyConfig script when the Agent is configured. 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 -domainPortNum 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/plugin/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</url>
<schema>odi_master_12c</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. You must use the proper syntax based on the usage of SID or service name.Use one of the following formats:
<url>jdbc:oracle:thin:@hostname:port/servicename</url> <url>jdbc:oracle:thin:@hostname:port:SID</url>
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.
Oracle B2B is moved to the target environment when you execute the movement scripts. However, you must take the following additional steps:
To move Oracle Business Process Management organizational units and dashboards to the new target environment:
To create organizational units, see "Managing Organizational Units in Process Workspace" in the Oracle Fusion Middleware Managing and Monitoring Processes with Oracle Business Process Management.
To move dashboards, use the ant-t2p-workspace.xml migration tool. The migration tool is available as an ant target that can be executed in the command line. It calls a configuration file that you create specifying the input parameters for the migration of data, as described in this task.
This script moves dashboards data with the BAM_WIDGET data type in the BPMUserApplicationData table to the target environment.
Note that the migration tool does not move any user-specific configuration because users in the source and target environments would not be same.
You use the following script:
ORACLE_HOME/soa/bin/ant-t2p-workspace.xml
The command has the following format:
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=MIGRATION_CONFIG_FILE
Take the following steps:
Ensure that the PATH environment variable contains the required JAVA_HOME and ANT_HOME environment variables and that they point to the locations within the Oracle SOA Suite installation.
Set the encryption key oracle.bpm.services.client.key
as an environment variable. For example:
oracle.bpm.services.client.key=1XXXX6XXXXX98XXX
You can also set the encryption key by passing it as an argument to the ant command. If you do not specify it, the ant task prompts you to enter it.
Export dashboards from the source environment:
Create a configuration file to export dashboards:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <testToProductionMigrationConfiguration xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config" xmlns:ns2="http://xmlns.oracle.com/bpm/common" override="true" skip="true"> <sourceEndPoint> <serverEndPoint> <serverURL>t3://host:port</serverURL> <adminUserLogin>admin_username</adminUserLogin> <adminUserPassword>admin_password</adminUserPassword> <realm>jazn.com</realm> </serverEndPoint> </sourceEndPoint> <targetEndPoint> <fileEndPoint> <migrationFile>/tmp/bpm_dashboard.xml</migrationFile> </fileEndPoint> </targetEndPoint> <operation>EXPORT</operation> <object>DASHBOARD</object> <objectDetails> <login>username</login> <password>password</password> <identityContext>jazn.com</identityContext> <userApplicationData> <ownerId>username/ownerId> <option>CUSTOMLAYOUT</option> </userApplicationData> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must specify the values for the source environment in the following elements:
serverURL: The SOA server URL.
adminUserLogin: The Administration user name.
adminUserPassword: The password for the Administration user.
migrationFile. The file that was generated by the export operation.
objectDetails: The login and password elements.
userApplicationData: The ownerID element.
Export dashboards, using the following command:
ant -f ant-t2p-workspace.xml -Dbea.home=WLS_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
Import dashboards:
Create a configuration file to import dashboards:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <testToProductionMigrationConfiguration xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config" xmlns:ns2="http://xmlns.oracle.com/bpm/common" override="true" skip="true"> <sourceEndPoint> <fileEndPoint> <migrationFile>/tmp/bpm_dashboard.xml</migrationFile> </fileEndPoint> </sourceEndPoint> <targetEndPoint> <serverEndPoint> <serverURL>t3://host:port</serverURL> <adminUserLogin>admin_username</adminUserLogin> <adminUserPassword>admin_password</adminUserPassword> <realm>jazn.com</realm> </serverEndPoint> </targetEndPoint> <operation>IMPORT</operation> <object>DASHBOARD</object> <objectDetails> <login>username</login> <password>password</password> <identityContext>jazn.com</identityContext> <userApplicationData> <ownerId>username/ownerId> <option>CUSTOMLAYOUT</option> </userApplicationData> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must update the following elements with the values for the target environment:
serverURL: The SOA server URL.
adminUserLogin: The Administration user name.
adminUserPassword: The password for the Administration user.
The password will be encrypted when you first run the ant-t2p-workspace.xml tool.
migrationFile. The file that was generated by the export operation.
objectDetails: The login and password elements.
The password will be encrypted when you first run the ant-t2p-workspace.xml tool.
userApplicationData: The ownerID element.
Import dashboards, using the following command:
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
Oracle Forms Services is moved to the target environment when you execute the movement scripts. However, you must take the following additional steps:
After you move the configuration of Oracle Traffic Director, you must reconfigure the certificates in the target environment. See "Managing Certificates" in Oracle Fusion Middleware Administering Oracle Traffic Director.
Oracle WebCenter Portal is moved to the target environment when you execute the movement scripts. However, you must take the additional steps in the following topics:
If you want to move Oracle WebCenter Portal data such as data associated with events, lists, links, tags, and people connections, to the target environment:
If you want to move data stored through WebCenter Portal in Oracle WebCenter Content, move Oracle WebCenter Content using the copy option, as described in Additional Information and Procedures for Moving Oracle WebCenter Content.
If your Oracle WebCenter Portal application uses the Discussions service, move the discussion server data from the source environment to the target environment:
Export the discussion server data using the Oracle Database export utility from the ORACLE_HOME
/bin
(UNIX) and the ORACLE_HOME
\bin
(Windows) directories, where ORACLE_HOME
is the Oracle home for the Oracle Database:
expdp "sys/password@connect_id as sysdba" OWNER=src_prefix_DISCUSSIONS DUMPFILE=dumpFileName.dmp STATISTICS=none schemas=src_prefix_DISCUSSIONS directory=directory dumpfile=filename schemas=src_prefix_DISCUSSIONS_CRAWLER directory=directory dumpfile=filename
Import the discussion server data:
Shut down the target discussions server.
Go to the ORACLE_HOME/bin directory of the database where WebCenter Portal's discussions server schema is installed, and connect to the database using sqlplus as sysdba:
ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"
Drop the target user and create a new user:
drop user trgt_prefix_DISCUSSIONS cascade; create user trgt_prefix_DISCUSSIONS identified by password default tablespace trgt_prefix_IAS_DISCUSSIONS temporary tablespace name_IAS_TEMP;
Grant connect and resource to the user:
grant connect,resource, create view to trgt_prefix_DISCUSSIONS;
Exit SQLPlus:
exit;
Import the discussion server data, using the Oracle Database import utility from the ORACLE_HOME
/bin
(UNIX) and the ORACLE_HOME
\bin
(Windows) directories, where ORACLE_HOME
is the Oracle home for the Oracle Database:
impdp \"sys/password@serviceid as sysdba\" remap_schema=src_prefix_DISCUSSIONS:trgt_prefix_DISCUSSIONS remap_schema=src_prefix_DISCUSSIONS_CRAWLER:trgt_prefix_DISCUSSIONS_CRAWLER remap_tablespace=source_tablespace:target_tablespace exclude=user DUMPFILE=dumpFileName STATISTICS=none
Oracle WebCenter Content is moved to the target environment when you execute the movement scripts. For the Oracle WebCenter Content server or Oracle WebCenter Content: Records, you have two options for moving the component:
copy: This option copies the entire source system, including configuration and data, to the target system. Although this is the default, Oracle does not recommend using this option because it moves test data, which might not be appropriate for your environment. In addition, that step:
Copies the configuration, including the modified settings, of Oracle WebCenter Content and its components.
Copies the BPEL credentials.
Moves Oracle WebCenter Capture.
Moves Oracle Web Services Manager policies.
Sets the Listen address for the Managed Server that contains Oracle Application Extension Framework (AXF).
Starts the Administration Server and Managed Servers.
init: This option initializes a new Content Server or Records instance in the target system. It does not move data. It copies the source domain and Managed Servers to the target system.
In addition, when you use the init option, the pasteConfig script copies the following initialization properties from the source system:
IDC_Name IDC_Id InstanceMenuLabel InstanceDescription IntradocServerPort IdcCommandServerHost SocketHostAddressSecurityFilter HttpServerAddress HttpRelativeWebRoot UseSSL MailServer SysAdminAddress IsAutoNumber AutoNumberPrefix AdditionalRegisteredComponents AdditionalEnabledComponents
You specify the copy or init option in the move plan, in the MoveType configProperty, as described in Table A-26. Then, you modify the properties listed in that configGroup.
Note that if custom certificates are used, custom certificates are generated and identity and trust keystores are updated accordingly in the move plan. For an SSL-only environment, follow the procedure in Additional Considerations in an SSL-Only Environment.
If your target environment is an SSL-only environment with Demo certificates, take the following steps after you run the copyConfig script.
Oracle WebCenter Sites is moved to the target environment when you execute the movement scripts. However, you must take additional steps: to configure Oracle WebCenter Sites, as described in Switching from Test Mode to Production Mode in Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Sites.
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.
There are special considerations when you have a distributed topology, such as a multiple host or Oracle RAC environment.
The following topics describe considerations when you have a distributed topology:
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 Common Procedures for Moving to a Target Environment on the Administration Server host:
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 Oracle Fusion Middleware 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 Creating a JDBC Data Source Using Fusion Middleware Control.
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:
When you move any environment which contains a Web Tier component, such as Oracle HTTP Server, the copyBinary script may return the following message:
Warning Message :1 Nov 20, 2014 10:47:57 - WARNING - CLONE-20266 Unable to archive a file. Nov 20, 2014 10:47:57 - CAUSE - CLONE-20266 The file "/scratch/oracle/webtier6400/network/log/cgisock.9465" did not have sufficient permission to access. Nov 20, 2014 10:47:57 - ACTION - CLONE-20266 Correct the permission of above file and run copyBinary again.
You can safely ignore this message.
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 you need to re-run the pasteConfig script and your environment includes Oracle Platform Security Services, set the following environment variable:
setenv T2P_JAVA_OPTIONS="-Dopssdata.import=false"
This setting prevents the pasteConfig script from attempting to import data into the OPSS schema. If the data already exists in the schema, the pasteConfig script will fail.
If the pasteBinary script returns an error while moving the Oracle home directory at the target:
Delete the target Oracle home.
Remove the Oracle home entry from the Oracle inventory, if it is present.
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:
Stop all processes related to the domain.
Delete the following directories:
ORACLE_HOME/user_projects/domains/domain_name ORACLE_HOME/user_projects/applications/domain_name
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 encounter the following error when you are using the copyConfig script for an Oracle SOA Suite installation, use the T2P_JAVA_OPTIONS environment variable to increase the message size:
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000080' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'.
You use the T2P_JAVA_OPTIONS environment variable, as described in About the Movement Scripts, to pass the -Dweblogic.MaxMessageSize=20000000 property to both the copyConfig and pasteConfig scripts.
When you use the pasteConfig operation and Oracle B2B inbound/outbound dispatcher is configured, you may receive the following error:
oracle.mds.exception.MDSRuntimeException: java.sql.SQLException: Data Source mds-soa does not exist. Data Source mds-soa does not exist.
In this situation, after the failure, kill the Managed Server process and manually restart the Managed Server.
If you receive an error when you attempt to start the Oracle SOA Suite Managed Server, you must modify system parameters using the Administration Console after you run the pasteConfig script. (Note that the pasteConfig script sets these system parameters with temporary values.)
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand Environment.
Click Servers. The Summary of Servers page appears.
Select the server.
Select the Server Start tab.
In the Arguments field, enter the following parameters:
-Dtangosol.coherence.wkan=hostname -Dtangosol.coherence.localhost=hostname -Dtangosol.coherence.localport=localport_number -Dtangosol.coherence.wka1.port=port_number_for_Coherence
Click Save and Activate Changes.
Start the server.