Oracle® Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1) E10105-02 |
|
![]() Previous |
![]() Next |
This chapter describes recommended recovery strategies and procedures for recovering Oracle Fusion Middleware from different types of failures and outages.
This chapter includes the following topics:
This section provides an overview of recovery strategies for outages that involve actual data loss or corruption, host failure, or media failure where the host or disk cannot be restarted and are permanently lost. This type of failure requires some type of data restoration before the Oracle Fusion Middleware environment can be restarted and continue with normal processing.
Note: The procedures in this chapter assume that no administrative changes were made since the last backup. If administrative changes were made since the last backup, they must be reapplied after recovery is complete. |
When you restore the files, use your preferred tool to extract the compressed files.
For example, for online recovery on Windows, use copy; for offline recovery on Windows, use copy, xcopy, or jar. Do not use Winzip because it does not work with long filenames or extensions.
For example, for Linux and UNIX, use tar.
Do not use the jar utility to archive and compress the file system. This avoids warnings or errors from the zip tool about zipping open files (for example, the ORACLE_HOME/jdk files).
Ensure that the tool you are using preserves the permissions and timestamps of the files.
Rename existing files and directories before you begin restoring the files from backup so that you do not unintentionally override necessary files.
This section describes recovery strategies for outages that involve actual data loss or corruption, or media failure where the disk cannot be restored. It also describes recovery strategies for applications that are no longer functioning properly. This type of failure requires some type of data restoration before the Oracle Fusion Middleware environment can be restarted and continue with normal processing. It contains the following topics:
You can recover a Middleware home that was corrupted or from which files were deleted.
Stop all relevant processes. That is, stop all processes that are running from that Middleware home.
For example, stop the Oracle WebLogic Server Administration Server processes and the Node Manager processes.
Recover the Middleware home directory from backup. For example:
cd MW_HOME
(UNIX) tar -xf mw_home_backup_092909.tar
(Windows) jar xtf mw_home_backup_092909.jar
Start all relevant processes. That is, start all processes that run in the Middleware home. For example, start the Administration Server:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
You can recover an Oracle WebLogic Server domain that was corrupted or deleted from the file system.
Caution: Performing a domain-level recovery can impact other aspects of a running system and all of the configuration changes performed after the backup was taken will be lost. |
To recover an Oracle WebLogic Server domain that was corrupted or deleted from the file system:
Stop all relevant processes. That is, stop all processes that are related to the domain. For example, stop the Administration Server and Managed Servers. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script to stop the Administration Server:
DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
Recover the domain directory from backup:
cd DOMAIN_HOME
(UNIX) tar -xf domain_backup_092909.tar
(Windows) jar xtf domain_backup_092909.jar
Start all relevant processes. That is, start all processes that are related to the domain. For example, start the Administration Server:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
An Oracle instance home contains configuration information for system components, such as Oracle HTTP Server or Oracle Internet Directory. (See Section 3.5.2 for a list of system components.) The following topics describe how to recover an Oracle instance home:
To recover an Oracle instance home that was corrupted or deleted from the file system:
Stop all relevant processes. That is, kill all processes that are related to that Oracle instance
Recover the Oracle instance home directory from a backup file. For example:
cd ORACLE_INSTANCE
(UNIX) tar -xf sc_home_backup_092909.tar
(Windows) jar xtf sc_home_backup_092909.jar
Start all relevant processes. That is, start all processes that are related to that Oracle instance:
opmnctl startall
To recover an Oracle instance home that was deregistered from the domain:
Recover the Oracle instance home directory from a backup file. For example, on Linux:
cd ORACLE_INSTANCE
tar -xf Instance_home_backup_092909.tar
Register the Oracle instance, along with all of its components, with the Administration Server, using the opmnctl registerinstance
command. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -oracleInstance ORACLE_INSTANCE_dir -oracleHome ORACLE_HOME_dir -instanceName Instance_name -wlserverHome Middleware_Home
If the Administration Server configuration has been lost because of file deletion or file system corruption, the Administration Server console continues to function if it was already started when the problem occurred. The Administration Server directory is regenerated automatically, except for security information. As a result, whenever you start the Administration Server, it prompts for a user name and password. To prevent this, you can recover the configuration.
Caution: Performing a domain-level recovery can impact other aspects of a running system and all of the configuration changes performed after the backup was taken will be lost. |
To recover the Administration Server configuration:
Stop all processes, including the Administration Server, Managed Servers, and Node Manager if they are started. You can use the Oracle WebLogic Server Administration Console, WLST, or a script. For example, to stop the Administration Server on Linux, use the following script:
DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
Recover the Administration Server configuration by recovering the domain home backup to a temporary location. Then, restore the config directory to the following location:
DOMAIN_HOME/config
Start the Administration Server. You can use WLST or the following script:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
Verify that the Administration Server starts properly and is accessible.
On the next configuration change, the configuration from the Administration Server is pushed to the Managed Servers. On each Managed Server restart, the configuration is retrieved from the Administration Server.
You can recover a Managed Server's files, including its configuration files if they are deleted or corrupted.
The following topics describe how to recover a Managed Server's files:
Recovering a Managed Server When It Does Not Function Correctly
Recovering an Oracle SOA Suite Managed Server That Has a Separate Directory
This section pertains when Oracle SOA Suite is configured in a domain and no Managed Servers share the domain directory with the Administration Server.
In this scenario, the Managed Server does not operate properly or cannot be started because the configuration has been deleted or corrupted or the configuration was mistakenly changed and you cannot ascertain what was changed.
To recover a Managed Server when it cannot be started:
If the Administration Server is not reachable, recover the Administration Server, as described in Section 17.2.4.
If the Managed Server fails to start or if the file system is lost, take the following steps:
Recover the Middleware home from the backup, if required.
tar -xf mw_home_backup_092909.tar
Create a domain template jar file for the Administration Server, using the pack utility. For example:
pack.sh -domain=MW_HOME/user_projects/domains/domain_name -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option.
Unpack the domain template jar file, using the unpack utility:
unpack.sh -template=/scratch/aime1/ms.jar -domain=MW_HOME/user_projects/domains/domain_name -log=/scratch/logs/new.log -log_priority=info
Ensure that the application artifacts are accessible from the Managed Server host. That is, if the application artifacts are not on the same server as the Managed Server, they must be in a location accessible by the Managed Server.
Note:
See Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server for information about stage, no-stage, and external-stage mode applications. |
Start the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
The Managed Server connects to the Administration Server and updates its configuration changes.
In this scenario, the Managed Server is running, but the file system for the Managed Server has been lost or corrupted:
To recover the Managed Server:
Stop the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:
DOMAIN_HOME/bin/stopManagedWeblogic.sh managed_server_name admin_url username password
Recover the Middleware home from the backup, if required:
tar -xf mw_home_backup_092909.tar
Create a domain template jar file for the Administration Server, using the pack utility. For example:
pack.sh -domain=MW_HOME/user_projects/domains/WLS_SOAWC
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true
Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option.
Unpack the domain template jar file, using the unpack utility:
unpack.sh -template=/scratch/aime1/ms.jar
-domain=MW_HOME/user_projects/domains/WLS_SOAWC
-log=/scratch/logs/new.log -log_priority=info
Ensure that the application artifacts are accessible from the Managed Server host. That is, if the application artifacts are not on the same server as the Managed Server, they must be in a location accessible by the Managed Server.
Note:
See Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server for information about deploying applications. |
Restart the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
When Oracle SOA Suite is configured in a domain and no Managed Servers share the domain directory with the Administration Server, you must restore the Managed Server directory. For example, a domain contains two Managed Servers, one of which contains Oracle SOA Suite, but neither of the Managed Server's directories are in the same directory structure as the Administration Server.
In this case, you must restore the Managed Server from backup:
Restore the Managed Server from backup:
cd ManagedServer_Home
tar -xf managed_server_backup_092909.tar
Restart the Managed Server:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
The following topics describe how to recover a component:
Recovering After a Component's Files Are Deleted or Corrupted
Recovering a Component That Is Not Functioning Properly After Configuration Change
You can recover a component's files if they are deleted or corrupted. The steps you take depend on the type of component:
For a Java component, such as Oracle SOA Suite, you recover the Managed Server, as described in Section 17.2.5.
For system components, such as Oracle HTTP Server or Oracle Web Cache:
Stop the component. For example, to stop Oracle HTTP Server:
opmnctl stopproc ias-component=component_name
For information on stopping components, see Section 4.3.
Recover the component-specific files from backup. Section 15.5 lists the directories and files needed for each component. For example, to recover Oracle HTTP Server files, you recover the following directories:
ORACLE_INSTANCE/config/OHS/component_name ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
Start the component. For example, to start Oracle HTTP Server:
opmnctl startproc ias-component=component_name
For information on starting components, see Section 4.3.
You can recover a component that cannot be started or is not functioning properly because the component's configuration was changed and committed. You may not be able to ascertain what change is causing the problem and you want to revert to an earlier version.
The steps you take depend on the type of component:
For a Java component, such as Oracle SOA Suite, you recover the Managed Server, as described in Section 17.2.5.
For system components, such as Oracle HTTP Server:
Stop the component. For example, to stop Oracle HTTP Server:
opmnctl stopproc ias-component=component_name
For information on stopping components, see Section 4.3.
Recover the component-specific files from backup. Section 15.5 lists the directories and files needed for each component. For example, to recover Oracle HTTP Server files, you recover the following directories:
ORACLE_INSTANCE/config/OHS/component_name ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
Start the component. For example, to start Oracle HTTP Server:
opmnctl startproc ias-component=component_name
For information on starting components, see Section 4.3.
You can recover components in a cluster when the components cannot be started or are not functioning properly because the configuration was changed and committed at the cluster level. You may not be able to ascertain what change is causing the problem and you want to revert to an earlier version.
Caution: Performing a domain-level recovery can impact other aspects of a running system and all of the configuration changes performed after the backup was taken will be lost. |
To recover the components:
Stop all processes, such as the Managed Servers and the Administration Server. You can use the Oracle WebLogic Server Administration Console, WLST or a script. For example, to stop the Administration Server on Linux, use the following script:
DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
Recover the Administration Server configuration by recovering the domain home backup to a temporary location. Then, restore the config directory to the following location:
DOMAIN_HOME/config
Start the Administration Server. You can use WLST or the following script:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
Start the cluster. You can use the Oracle WebLogic Server Administration Console or WLST. For example, to use the WLST start command:
start('clusterName', 'Cluster')
The latest configuration is retrieved from the Administration Server to every member of the cluster.
The following topics describe how to recover a cluster:
Recovering a Cluster After Deletion or Cluster-Level Configuration Changes
Recovering a Cluster After Membership Is Mistakenly Modified
In this scenario, the cluster has been erroneously deleted or the cluster-level configuration, such as the JMS configuration or container-level data sources, was mistakenly changed and committed. The server cannot be started or does not operate properly or the services running inside the server are not starting. You cannot ascertain what was changed.
Caution: Performing a domain-level recovery can impact other aspects of a running system and all of the configuration changes performed after the backup was taken will be lost. |
If the configuration changes are few, then the easiest way is to redo the configuration changes. If that is not feasible, use the following procedure to recover the configuration:
Stop the cluster. You can use the Oracle WebLogic Server Administration Console or WLST. For example, to use WLST:
stop('clusterName', 'Cluster')
Stop the Administration Server. You can use WLST or the following script:
DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
Recover the Administration Server configuration by recovering the domain home backup to a temporary location. Then, restore the config directory to the following location:
DOMAIN_HOME/config
Start the Administration Server. You can use WLST or the following script:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
Start the cluster. You can use the Oracle WebLogic Server Administration Console or WLST. For example, to use WLST:
start('clusterName', 'Cluster')
You can recover a cluster when the cluster's membership has been mistakenly modified. For example, if you inadvertently delete a member from the cluster, you can restore the member to the cluster.
Caution: Performing a domain-level recovery can impact other aspects of a running system and all of the configuration changes performed after the backup was taken will be lost. |
To recover the cluster membership:
Stop all processes, such as the Managed Servers and the Administration Server. You can use the Oracle WebLogic Server Administration Console, WLST or a script. For example, to stop the Administration Server on Linux, use the following script:
DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
Recover the Administration Server configuration by recovering the domain home backup to a temporary location. Then, restore the config directory to the following location:
DOMAIN_HOME/config
Start the Administration Server. You can use WLST or the following script:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
The deleted member is now back in the cluster.
Start all processes, such as the Managed Servers. You can use WLST or a script. For example, to start the Managed Server on Linux, use the following script:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Start the cluster. You can use the Oracle WebLogic Server Administration Console or WLST. For example, to use WLST:
start('clusterName', 'Cluster')
The deleted member is now part of the cluster.
Start all cluster members if they are not started:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
The following topics describe how to recover an application:
Note the following about recovering applications:
If the application is staged, the Administration server copies the application bits to the staged directories on the Managed Server hosts.
If the deployment mode is no-stage or external stage, ensure that additional application artifacts are available. For example, applications may reside in directories outside of the domain directory. Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.
See Also: Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server for information about deploying applications |
If an application's artifacts, such as the .ear file, have been lost or corrupted, you can recover the application.
To recover the application:
Start the Managed Server to which the application was deployed. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
This synchronizes the configuration with the Administration Server.
On each Managed Server restart, the configuration and application artifacts are retrieved from the Administration Server.
If a Java EE application was redeployed to a Managed Server (whether or not the Managed Server is part of a cluster) and the application is no longer functional, you can recover it.
To recover the application:
Recover the application files from backup, if needed.
Redeploy the old version of the application from the backup.
You cannot just copy the original ear file. Even if the original ear file (from the backup) is copied back to the Managed Server stage directory and you restart the Managed Server, the application is still not recovered. You must redeploy the original version.
If a deployed application was undeployed from Oracle WebLogic Server, you can recover it.
To recover the application:
Recover the application files from backup, if needed.
Redeploy the old version of the application from the backup. If the application was deployed to a cluster, redeploy the application to the same cluster.
You cannot just copy the original ear file. Even if the original ear file (from the backup) is copied back to the Managed Server stage directory and you restart the Managed Server, the application is still not recovered. You must redeploy the original version.
A new version of a composite application (such as SOA application) was redeployed to a Managed Server or cluster. The application is no longer functional.
To recover the application:
Recover the application files from backup, if needed.
Redeploy the old version of the application. If the application was deployed to a cluster, redeploy the application to the same cluster.
If your database that contains your metadata repository, including the MDS Repository, is corrupted, you can recover it using RMAN. You can recover the database at the desired granularity, either a full recovery or a tablespace recovery.
For best results, recover the database to the most current state, using point-in-time recovery (if the database is configured in Archive Log Mode.) This ensures that the latest data is recovered. For example:
rman> restore database; rman> recover database;
See Appendix D for the schemas used by each component.
For detailed steps, see the Oracle Database Backup and Recovery User's Guide, which is available at:
http://www.oracle.com/technology/documentation/database.html
This section describes how to recover your Oracle Fusion Middleware environment after losing the original operating environment. For example, you could have a serious system malfunction or loss of media. The sections includes the following topics:
Note: When you are recovering in the case of loss of host, you must restore the files using the same path as on the original host. |
If you lose a host that contains the Administration Server, you can recover it to the same host or a different host, as described in the following topics:
In this scenario, you recover the Administration Server either to the same host after the operating system has been reinstalled or to a new host that has the same host name. For example, the Administration Server is running on Host A and the Managed Server is running on Host B. Host A has failed for some reason and the Administration Server needs to be recovered.
To recover the Administration Server:
Attempt to start the Administration Server. You can use WLST, or the following script:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
If the Administration Server starts, you do not need to take any further steps.
If the Administration Server fails to start, take the following steps on Host A:
Stop all relevant processes. That is, stop all processes that are related to the domain. For example, stop the Administration Server and Managed Servers. You can use WLST or the following script to stop the Administration Server:
DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
Recover the Middleware home, if needed:
tar -xf mw_home_backup_092909.tar
If the domain directory does not reside in the Middleware home, recover the domain directory from backup:
cd DOMAIN_HOME
tar -xf domain_backup_092909.tar
Start the Administration Server. You can use WLST or the following script:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
Start the Node Manager:
java weblogic.WLST wls:/offline> startNodeManager()
Now you can start and stop the Managed Server on Host B using the Administration Console running on Host A.
In this scenario, the Administration Server is running on Host A and the Managed Server is running on Host B. Host A has failed for some reason and the Administration Server needs to be moved to Host C.
Recover the Middleware home to Host C (the new Host where the Administration Server will be recovered).
cd MW_HOME
tar -xf mw_home_backup_092909.tar
If the domain directory does not reside in the Middleware home, recover the domain directory from backup:
cd DOMAIN_HOME tar -xf domain_backup_092909.tar
Start the Node Manager on Host C if it was configured on the original host:
java weblogic.WLST wls:/offline> startNodeManager()
Start the Administration Server. You can use WLST or the following script:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
Ensure that additional application artifacts are available. For example, if the deployment mode is no-stage or external stage, applications may reside in directories outside of the domain directory. Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.
If the application is staged, the Administration Server copies the application bits to the staged directories on the Managed Server hosts.
Update Oracle Inventory, as described in Section 17.3.4.4.
Edit the targets.xml file for Fusion Middleware Control, as described in Section 17.3.4.2.
Oracle Management Service, which is part of Fusion Middleware Control, is on the original host and is recovered to the new host when you restore the Administration Server. Oracle Management Agent connects to Oracle Management Service to monitor certain components. If your environment contains components, such as Oracle Internet Directory and Oracle Virtual Directory, that use Oracle Management Agent, but they are located on a different host, you must take the following steps on each host containing the components. For example, the Administration Server was on Host A, but is restored, along with Oracle Management Service, to Host B. Oracle Internet Directory is on Host C and Oracle Virtual Directory is on Host D. You must take these steps on both Host C and Host D.
Edit the following file:
(UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties (Windows)ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties
Update the following entries, replacing the host name with the new host for the Administration Server:
emdWalletSrcUrl=http://newhost.domain.com:port/em/wallets/emd REPOSITORY_URL=http://newhost.domain.com:port/em/upload/
Shut down and restart the EM Agent process:
cd $ORACLE_INSTANCE/EMAGENT/emagent_dir
./emctl stop agent
./emctl start agent
./emctl status agent
The status command will show the REPOSITORY_URL pointing to the new host.
Now you can start and stop the Managed Server on Host B using the Administration Console running on Host C.
If you are recovering the Administration Server for a Web Tier installation, see Section 17.3.4 for information about additional actions you must take.
If you lose a host that contains a Managed Server, you can recover it to the same host or a different host, as described in the following topics:
Recovering an Oracle SOA Suite Managed Server That Has a Separate Directory
This section pertains when Oracle SOA Suite is configured in a domain and no Managed Servers share the domain directory with the Administration Server.
In this scenario, you recover a Managed Server to the same host after the operating system has been reinstalled or to a new host that has the same host name. The Administration Server is running on Host A and the Managed Server is running on Host B. Host B failed for some reason and the Managed Server needs to be recovered to Host B.
Start the Node Manager on Host B:
java weblogic.WLST wls:/offline> startNodeManager()
Start the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
If the Managed Server starts, it connects to the Administration Server and updates its configuration changes. You do not need to take any further steps.
If the Managed Server fails to start or if the file system is lost, take the following steps:
Stop the Node Manager:
java weblogic.WLST wls:/offline> stopNodeManager()
Recover the Middleware home to Host B from the backup, if required:
tar -xf mw_home_backup_092909.tar
If the Managed Server contains Oracle Portal, Oracle Reports, Oracle Forms Services, or Oracle Business Intelligence Discoverer, and the Managed Server domain directories reside outside of the Middleware home, restore the domain, in addition to the Middleware home. For example:
cd Domain_Home
tar -xf domain_home_backup_092909.tar
Go to Step e.
If the Managed Server does not contain the components listed in Step c, take the following steps:
Create a domain template jar file for the Administration Server running in Host A, using the pack utility. For example:
pack.sh -domain=MW_HOME/user_projects/domains/domain_name -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option.
Unpack the domain template jar file in Host B, using the unpack utility:
unpack.sh -template=/scratch/aime1/ms.jar -domain=MW_HOME/user_projects/domains/domain_name -log=/scratch/logs/new.log -log_priority=info
Ensure that the application artifacts are accessible from the Managed Server host. That is, if the application artifacts are not on the same server as the Managed Server, they must be in a location accessible by the Managed Server.
Note:
See Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server for information about deploying applications. |
If the Node Manager is not started, start it:
java weblogic.WLST wls:/offline> startNodeManager()
Start the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
The Managed Server connects to the Administration Server and updates its configuration changes.
In this scenario, the Administration Server is running on Host A and the Managed Server is running on Host B. Host B failed for some reason and the Managed Server needs to be recovered to Host C.
Important: Recover the Middleware home to the same location as the original. |
Take the following steps:
Recover the MW_HOME for the Managed Server to Host C.
tar -xf mw_home_backup_092909.tar
If the Managed Server contains Oracle Portal, Oracle Reports, Oracle Forms Services, or Oracle Business Intelligence Discoverer, and the Managed Server domain directories reside outside of the Middleware home, restore the domain, in addition to the Middleware home. For example:
cd Domain_Home
tar -xf domain_home_backup_092909.tar
Go to Step 4.
If the Managed Server does not contain the components listed in Step 2, take the following steps:
Create a domain template jar file from the Administration Server running in Host A, using the pack utility. For example:
pack.sh -domain=MW_HOME/user_projects/domains/domain_name -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true
Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option.
Unpack the domain template jar file on Host C, using the unpack utility:
unpack.sh -template=/scratch/aime1/ms.jar -domain=MW_HOME/user_projects/domains/domain_name -log=/scratch/logs/new.log -log_priority=info
If you are recovering to a different domain home, use the -app_dir switch in the unpack command.
Ensure that the application artifacts are accessible from the Managed Server host. That is, if the application artifacts are not on the same server as the Managed Server, they must be in a location accessible by the Managed Server.
Note:
See Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server for information about deploying applications. |
Start the Node Manager on Host C, if it is not started:
java weblogic.WLST wls:/offline> startNodeManager()
Using WLST, connect to the Administration Server and then enroll the Node Manager running in the new host with the Administration Server:
connect('username','password','http://host:port') nmEnroll('MW_HOME/user_projects/domains/domain_name', 'MW_HOME/wlserver_n/common/nodemanager')
Change the Managed Server configuration to point to the new host:
In the WebLogic Server Administration Console, create a machine, which is a logical representation of the computer that hosts one or more WebLogic Servers, and point it to the new host. (From the Home page, select Machines. Then, click New.) Follow the directions in the Administration Console help.
If you identify the Listen Address by IP address, you must disable Host Name Verification on the Administration Servers that access Node Manager. For more information and instructions, see "Using Hostname Verification" in Oracle Fusion Middleware Securing Oracle WebLogic Server.
Change the Managed Server configuration to point to the new machine. (From the left pane of the Console, expand Environment and then Servers. Then, select the name of the server. Select the Configuration tab, then the General tab. In the Machine field, select the machine to which you want to assign the server.)
Change Listen Address to the new host. (If the listening address was set to blank, you do not need to change it.)
Start the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
The Managed Server connects to the Administration Server and updates its configuration changes.
Update Oracle Inventory, as described in Section 17.3.4.4.
Edit the targets.xml file for Fusion Middleware Control, as described in Section 17.3.4.2.
Now you can start and stop the Managed Server on Host C using the Administration Server running on Host A.
When Oracle SOA Suite is configured in a domain and no Managed Servers share the domain directory with the Administration Server, you must restore the Managed Server directory. For example, a domain contains two Managed Servers, one of which contains Oracle SOA Suite, but neither of the Managed Server's directories are in the same directory structure as the Administration Server.
You use the following steps when you are restoring to the same host or a different host:
Restore the Managed Server from backup:
cd ManagedServer_Home
tar -xf managed_server_backup_092909.tar
Restart the Managed Server:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
If you lose a host that contains a component (and its Managed Server, if applicable), you can recover it to the same host or a different host, as described in the following topics:
To recover a Java component, such as Oracle SOA Suite:
Recover the Managed Server, as described in Section 17.2.5.1.
However, note that some components require additional steps, which are described in subsequent sections.
To recover a Java component, such as Oracle SOA Suite:
Recover the Managed Server, as described in Section 17.3.2.2.
Edit the targets.xml file for Fusion Middleware Control, as described in Section 17.3.4.2.
However, note that some components require additional steps, which are described in subsequent sections.
To recover a system component, such as Oracle HTTP Server, you take the following general steps. However, note that some components require additional steps.
Stop all relevant processes. That is, stop all processes that are related to the component. For example, to stop Oracle HTTP Server:
opmnctl stopproc ias-component=component_name
For information on stopping components, see Section 4.3.
Recover the component-specific files from backup. Section 15.5 lists the directories and files needed for each component. For example, to recover Oracle HTTP Server files, you recover the following directories:
ORACLE_INSTANCE/config/OHS/component_name ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
If the Oracle instance home has been deregistered from the Administration Server, register the Oracle instance:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -wlserverHome wlserver_home_location
If only the file system is being recovered, you do not need to register the Oracle instance.
Start all relevant processes, as described in Section 4.3.
To recover a system component, such as Oracle HTTP Server, you take the following general steps. However, note that most components require additional steps, which are described in separate sections.
Recover the Middleware home, as described in Section 17.2.1.
Start all relevant processes. Section 4.3 explains how to start components.
Update the registration of the Oracle instance with the Administration Server, using the opmnctl updateinstanceregistration
command on the new host. For example:
opmnctl updateinstanceregistration -adminHost admin_server_host
This command updates OPMN's instance.properties file.
Update the registration of the component with the Administration Server, using the opmnctl updatecomponentregistration
command on the new host. For example, to update the registration for Oracle Virtual Directory, use the following command:
opmnctl updatecomponentregistration -Host new_host -Port nonSSLPort -componentName ovd1 -componentType OVD
Edit the targets.xml file for Fusion Middleware Control, as described in Section 17.3.4.2.
Depending on the components, you may need to take additional actions. See the subsequent sections for more information.
Note that when Oracle SOA Suite is configured in a domain and no Managed Servers share the domain directory with the Administration Server, take the steps described in Section 17.3.2.3. Otherwise, follow the steps in this section.
To recover the Oracle SOA Suite Managed Server to the same host after loss of host:
Recover the Managed Server, as described in Section 17.3.2.1.
To recover the Oracle SOA Suite Managed Server to a different host after loss of host:
Before you recover, update the WSDL file to point to the new host name and port.
Recover the Managed Server, as described in Section 17.3.2.2.
After you recover the Oracle SOA Suite Managed Server, take the following actions:
If the ant command is used to deploy composites, edit the deploy-sar.xml file, which is located in:
(UNIX) ORACLE_HOME/bin (Windows) ORACLE_HOME\bin
In the following line, replace the previous host name with the new host name:
<property name="wlsHost" value="newhostname"/>
If a Load Balancer is used, do not modify this property. Instead, register the new host with the Load Balancer.
Change the host name in the soa-infra MBean:
In Fusion Middleware Control, navigate to the Managed Server.
From the WebLogic Server menu, choose System MBean Browser.
Expand Application Defined MBeans, then oracle.as.soainfra.config, then Server: server_name and then SoaInfraConfig. Select soa-infra.
In the Attributes tab, click ServerURL. If the ServerURL attribute contains a value, change the host name to the new host name.
Click Apply.
Redeploy all applications which have the WSDL files updated to the new host name.
Note: If there is no Load Balancer configured with the environment and Oracle SOA Suite needs to be recovered to a different host, then in-flight instances that are pending a response from task flow and asynchronous responses are not recovered. Oracle recommends that you use a Load Balancer to ensure that you can recover to a different host. |
If a Load Balancer is configured with the environment, follow steps in Section 17.3.2.2. Then, take the following additional steps:
Log in to the Oracle WebLogic Server Administration Server.
In Domain Structure, navigate to Servers. For each Managed Server, select the Protocol tab, then the HTTP tab.
For Frontend Host, enter the new host name.
For Frontend HTTP Port and Frontend HTTPs Port, if applicable, enter the new port number.
Restart each Managed Server.
To recover Oracle Business Activity Monitoring to a different host:
Recover the Managed Server, as described in Section 17.3.2.2.
To recover Oracle WebCenter to a different host:
Recover the Managed Server, as described in Section 17.3.2.2.
The Web tier consists of Oracle HTTP Server and Oracle Web Cache. The following topics describe how to recover these components:
To recover Oracle HTTP Server to a different host:
Recover the component as described in Section 17.3.3.4.
Recover Oracle Management Agent, as described in Section 17.3.4.3.
Modify the ServerName entry in the following file to have the new host name:
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/httpd.conf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\httpd.conf
To recover Oracle Web Cache to a different host:
Recover the component as described in Section 17.3.3.4.
Recover Oracle Management Agent, as described in Section 17.3.4.3.
Edit the webcache.xml file, replacing the previous host name with the new host name. The file is located in:
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
For most Identity Management components, you recover the Managed Server, as described in Section 17.3.2.2.
Some components require additional steps to recover the components to a different host, as described in the following topics:
Recovering Oracle Directory Integration Platform to a Different Host
Recovering Oracle Directory Services Manager to a Different Host
To recover Oracle Internet Directory to a different host:
Recover the component as described in Section 17.3.3.4.
On UNIX and Linux systems, before you attempt to start Oracle Internet Directory, set the following to have root permission:
ORACLE_HOME/bin/oidldapd
For example:
chown root oidldapd chmod 4710 oidldapd
Recover Oracle Management Agent, as described in Section 17.3.4.3.
If the Managed Server on which Oracle Directory Services Manager is deployed is moved to different host and if SSL is enabled, you must delete the following file on the new host:
DOMAIN_HOME/servers/wls_ods1/tmp/_WL_user/odsm_11.1.1.1.0/randomid/war/conf/odsm.cer
Oracle Directory Services Manager uses this file as its key store and trust store and the password is stored in JKS. However, when Oracle Directory Services Manager is copied to another host and is started, it generates a different password than odsm.cer. If you delete the file, Oracle Directory Services Manager creates a new file when it starts.
To recover Oracle Virtual Directory to a different host:
Recover the component as described in Section 17.3.3.4.
Recover Oracle Management Agent, as described in Section 17.3.4.3.
To recover Oracle Directory Integration Platform to a different host:
Recover the Managed Server, as described in Section 17.3.2.2.
Before starting the Managed Server, restore the files in the following directory:
DOMAIN_HOME/servers/wls_ods1/stage/DIP/11.1.1.1.0/
Start the Managed Servers and Oracle instances.
If Oracle Internet Directory is also moved to a different host, execute the following commands immediately after the Managed Server and the Oracle instance are started:
set ORACLE_HOME Oracle_home_path set WLS_HOME WLS_Home_path cd ORACLE_HOME/bin ./manageDIPServerConfig set -h dip_server_host -p dip_server_port -D weblogic_user -attribute oidhostport -value oid_host:oid_ssl_port
The manageDIPServerConfig command prompts you for a password.
For example:
./manageDIPServerConfig set -h hostname -p 19523 -D weblogic -attribute oidhostport -value hostname.domain.com:24163
Register the Oracle instance, along with all of its components, with the Administration Server, using the opmnctl registerinstance
command on the new host. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -wlserverHome wlserver_home_location
To recover Oracle Directory Services Manager to a different host:
Recover the component as described in Section 17.3.3.4.
Because Oracle Identity Federation provides SSO functionality, if the host name on which Oracle Identity Federation runs is changed as part of loss of host recovery, it impacts remote partners. In that case, remote partners must make changes regarding the host name to continue to operate. It may take many days for remote partners to update their data and this will cause production delays that are unacceptable. Oracle strongly recommends that you do not change the host name of a standalone Oracle Identity Federation server.
If a load balancer is part of the environment and the host where Oracle Identity Federation is being recovered is in the list of VIPs, then no host name changes are required.
In the case of a standalone installation of Oracle Identity Federation, Oracle recommends using a new host with the same name to minimize the impact. However, if, for whatever reason, you need to use a different host name for recovering Oracle Identity Federation, then the host name needs to be updated manually for Oracle Identity Federation and remote partners.
To recover Oracle Identity Federation to a different host:
Recover the Managed Server, as described in Section 17.3.2.2.
Recover Oracle Management Agent, as described in Section 17.3.4.3.
Register the Oracle instance, along with all of its components, with the Administration Server, using the opmnctl registerinstance
command on the new host. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -wlserverHome wlserver_home_location
Provide the updated data to remote partners.
Modify the host name using Fusion Middleware Control:
In the navigation pane, expand the farm and then Identity and Access.
Select the Oracle Identity Federation instance.
From the Oracle Identity Federation menu, choose Administration, then Server Properties.
The Server Properties page is displayed.
For Host, replace the old host name with the new host name.
For Port, replace the port number if it has changed.
For SOAP Port, replace the port number if it has changed.
Click Apply.
Restart the Managed Server to which Oracle Identity Federation is deployed:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
If Oracle Identity Federation is acting as an SSL server, you must replace the SSL certificate presented by Oracle Identity Federation to clients with a new one that has the new host name. Otherwise, host name verification by clients may fail.
The following topics describe how to recover these components to a different host:
To recover Oracle Portal to a different host:
Restore the Middleware home, domain directory, and the Oracle instance directory to the new host. See Section 17.3.2.2 for more information.
Recover Oracle Management Agent, as described in Section 17.3.4.3.
Register the Oracle instance, along with all of its components, with the Administration Server, using the opmnctl registerinstance
command on the new host. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -wlserverHome wlserver_home_location
Modify the following files, replacing the old host name with the new host name:
ORACLE_INSTANCE/config/OHS/ohs_name/httpd.conf ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf/portal.conf
Run the ssoreg script, which is located in:
Identity_Management_ORACLE_HOME/sso/bin
Use the following command:
ssoreg.sh -site_name newhost:http_listen_port -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file any_new_file_path -admin_info cn=orcladmin -virtualhost -remote_midtier
For example:
ssoreg.sh -site_name example.com:8090 -mod_osso_url http://example.com:8090 -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf -admin_info cn=orcladmin -virtualhost -remote_midtier
Copy the file from the previous step to the new host.
In the new host, modify the OssoConfigFile section in the following file to include the path of the file in step 5:
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf
For example:
<IfModule mod_osso.c> OssoIpCheck off OssoSecureCookies off OssoIdleTimeout off OssoConfigFile /tmp/path_of_file_created
Edit the following files, replacing the previous host name with the new host name:
webcache.xml. This file is located in:
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
Replace all occurrences of the previous host name with the new host name.
instance.properties. The file is located in:
(UNIX) ORACLE_INSTANCE/config/OPMN/opmn (Windows) ORACLE_INSTANCE\config\OPMN\opmn
In the following line, replace the previous host name with the new host name if the Administration Server host name has changed.
adminHost=host_name
If the published host used to access Oracle Portal is changing, take the following steps. This could happen if you have a single node install which contains both Oracle Web Cache and WLS_PORTAL, and those processes need to move to a different host. Another scenario is when you have Oracle Web Cache running on a node remotely from WLS_PORTAL, and Oracle Web Cache needs to move to a different host. In both these cases, take the following steps to update the Published Host information within Oracle Portal. (Note: If you have a load balancer or reverse proxy configuration, the steps are not needed.)
Recursively delete all content from the following directory, but do not delete the directory itself:
ORACLE_INSTANCE/portal/cache
Log in to Fusion Middleware Control. Expand the farm and right-click Portal. Then, choose Settings, then Wire Configuration.
In the Portal Midtier section, update Published Host with the new host name.
In the Oracle Web Cache section, update Host with the new host name.
Restart the WLS_PORTAL instance.
To recover Oracle Business Intelligence Discoverer to a different host:
Recover the Managed Server as described in Section 17.3.2.2.
Recover Oracle Management Agent, as described in Section 17.3.4.3.
Register the Oracle instance, along with all of its components, with the Administration Server, using the opmnctl registerinstance
command on the new host. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -wlserverHome wlserver_home_location
Edit the following files, replacing the previous host name with the new host name:
module_disco.conf. This file is located in:
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name//moduleconf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf
webcache.xml. This file is located in:
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
Replace all occurrences of the previous host name with the new host name.
Run the ssoreg script, which is located in:
Identity_Management_ORACLE_HOME/sso/bin
Use the following command:
ssoreg.sh -site_name newhost:http_listen_port -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file any_new_file_path -admin_info cn=orcladmin -virtualhost -remote_midtier
For example:
ssoreg.sh -site_name example.com:8090 -mod_osso_url http://example.com:8090 -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf -admin_info cn=orcladmin -virtualhost -remote_midtier
Copy the file from the previous step to the new host.
In the new host, modify the OssoConfigFile section in the following file to include the path of the file in step 5:
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf
For example:
<IfModule mod_osso.c> OssoIpCheck off OssoSecureCookies off OssoIdleTimeout off OssoConfigFile /tmp/path_of_file_created
To recover Oracle Reports to a different host:
Recover the Managed Server as described in Section 17.3.2.2.
Recover Oracle Management Agent, as described in Section 17.3.4.3.
Register the Oracle instance, along with all of its components, with the Administration Server, using the opmnctl registerinstance
command on the new host. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -wlserverHome wlserver_home_location
Edit the following files, replacing the previous host name with the new host name:
reports_install.properties. The file is located in:
(UNIX) ORACLE_INSTANCE/reports (Windows) ORACLE_INSTANCE\reports
Edit the parameters SERVER_NAME, OHS_HOST and REPORTS_MANAGED_WLS_HOST.
webcache.xml. This file is located in:
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
Replace all occurrences of the previous host name with the new host name.
instance.properties. The file is located in:
(UNIX) ORACLE_INSTANCE/config/OPMN/opmn (Windows) ORACLE_INSTANCE\config\OPMN\opmn
In the following line, replace the previous host name with the new host name if the Administration Server host name has changed.
adminHost=host_name
reports_ohs.conf. The file is located in:
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf
rwservlet.properties. The file is located in:
(UNIX) MW_HOME/user_projects/domains/domain_name/servers/WLS_REPORTS/stage/reports/reports/configuration (Windows) MW_HOME\user_projects\domains\domain_name\servers/WLS_REPORTS\stage\reports\reports\configuration
In the file, modify the <server> element to use the new host name.
In the following directory, rename the subdirectory to have the new host name:
(UNIX) ORACLE_INSTANCE/diagnostics/logs/ReportsServer (Windows) ORACLE_INSTANCE\diagnostics\logs\ReportsServer
In the following directory, rename the old_host_name.dat file to the new host name:
(UNIX) ORACLE_INSTANCE/reports/server (Windows) ORACLE_INSTANCE\reports\server
In the following directory, rename the subdirectory to have the new host name:
(UNIX) ORACLE_INSTANCE/config/ReportsServer (Windows) ORACLE_INSTANCE\config\ReportsServer
Run the ssoreg script, which is located in:
Identity_Management_ORACLE_HOME/sso/bin
Use the following command:
ssoreg.sh -site_name newhost:http_listen_port -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file any_new_file_path -admin_info cn=orcladmin -virtualhost -remote_midtier
For example:
ssoreg.sh -site_name example.com:8090 -mod_osso_url http://example.com:8090 -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf -admin_info cn=orcladmin -virtualhost -remote_midtier
Copy the file from the previous step to the new host.
In the new host, modify the OssoConfigFile section in the following file to include the path of the file in step 8:
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf
For example:
<IfModule mod_osso.c> OssoIpCheck off OssoSecureCookies off OssoIdleTimeout off OssoConfigFile /tmp/path_of_file_created
To recover Oracle Forms Services to a different host:
Recover the Managed Server as described in Section 17.3.2.2.
Recover Oracle Management Agent, as described in Section 17.3.4.3.
Register the Oracle instance, along with all of its components, with the Administration Server, using the opmnctl registerinstance
command on the new host. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -wlserverHome wlserver_home_location
Edit the following files, replacing the previous host name with the new host name:
webcache.xml. This file is located in:
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
Replace all occurrences of the previous host name with the new host name.
instance.properties. The file is located in:
(UNIX) ORACLE_INSTANCE/config/OPMN/opmn (Windows) ORACLE_INSTANCE\config\OPMN\opmn
In the following line, replace the previous host name with the new host name if the Administration Server host name has changed.
adminHost=host_name
forms.conf. The file is located in:
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf
Replace the host name in the parameter WebLogicHost with the name of the new host.
On the Administration Server host, edit the following file:
DOMAIN_HOME/opmn/topology.xml
Add properties for the <ias-component id> element for Oracle Forms Services. The following example shows the element after you modify it:
</ias-component> <ias-component id="forms" type="FormsComponent" > <em-properties> <property name="OracleHome" value="/path_to_oracle_home" /> <property name="instName" value="instance_name" /> <property name="EMTargetType" value="oracle_forms" /> <property name="version" value="11.1.1" /> </em-properties> </ias-component>
On the host where the Oracle instance has been recovered, update the registration of the component with the Administration Server, using the opmnctl updatecomponentregistration
command on the new host.
For example:
opmnctl updatecomponentregistration -Host new_host -Port nonSSLPort -componentName forms -componentType FormsComponent
Run the ssoreg script, which is located in:
Identity_Management_ORACLE_HOME/sso/bin
Use the following command:
ssoreg.sh -site_name newhost:http_listen_port -mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file any_new_file_path -admin_info cn=orcladmin -virtualhost -remote_midtier
For example:
ssoreg.sh -site_name example.com:8090 -mod_osso_url http://example.com:8090 -config_mod_osso TRUE -oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf -admin_info cn=orcladmin -virtualhost -remote_midtier
Copy the file from the previous step to the new host.
In the new host, modify the OssoConfigFile section in the following file to include the path of the file in step 7:
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf
For example:
<IfModule mod_osso.c> OssoIpCheck off OssoSecureCookies off OssoIdleTimeout off OssoConfigFile /tmp/path_of_file_created
Depending on the entity that you are recovering, you may need to take additional actions after loss of host. The sections about each entity may require you to follow one or more of the following procedures. If so, that is noted in the section describing how to recover the entity.
Changing the Host Name in the targets.xml File for Fusion Middleware Control
Recovering Oracle Management Agent When Components Are Recovered to a Different Host
To recover Fusion Middleware Control to a different host, take the following steps:
Update the host name in the following file:
MW_HOME/user_projects/domains/domain_name/servers/AdminServer/tmp/_WL_user/em/hsz5x1/META-INF/emoms.properties
In the file, change the host name for the following properties:
mas.conn.url oracle.sysman.emSDK.svlt.ConsoleServerHost
Edit the following file:
(UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties (Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties
In the file, edit the following entry for each component monitored by Oracle Management Agent, replacing the host name:
REPOSITORY_URL=http://newhost.domain.com:port/em/upload/
When you recover a component to a different host, you must update the targets.xml file for Fusion Middleware Control. The file is located at:
MW_HOME/user_projects/domains/domain_name/sysman/state/targets.xml
In the file, change the host name to the new host name for components that are recovered to a different host.
For many components, when you recover to a different host, as in the case of loss of host, you must take actions to recover Oracle Management Agent so that Fusion Middleware Control can manage the components. This pertains to the following installation types and components:
Identity Management components
Oracle Identity Federation
Oracle Portal
Oracle Business Intelligence Discoverer
Oracle Forms Services
Oracle Reports
To recover Oracle Management Agent, take the following actions:
Edit the following file:
(UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/emd/targets.xml (Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\emd\targets.xml
In the file, edit the following element, replacing the host name:
<Target TYPE="host" NAME="newhost.domain.com" DISPLAY_NAME="newhost.domain.com"/>
Edit the following file:
(UNIX) ORACLE_INSTANCE/EMAGENT/emagent_name/sysman/config/emd.properties (Windows) ORACLE_INSTANCE\EMAGENT\emagent_name\sysman\config\emd.properties
Update the following entry, replacing the host name:
EMD_URL=http://newhost.domain.com:port/emd/main
Start Oracle Management Agent, using the following command:
opmnctl startproc ias-component=EMAGENT
Start the Administration Server:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
Starting the Administration Server also starts Fusion Middleware Control.
For many components, when you recover to a different host, as in the case of loss of host, you need to update the Oracle inventory. To do so, execute the following script:
ORACLE_HOME/oui/bin/attachHome.sh
In addition, you must update beahomelist to edit the location of a Middleware home. Edit the following file to update the Middleware home information:
(UNIX) user_home/bea/beahomelist
(Windows) C:\bea\beahomelist
When you recover any component to a different host on Windows, as in the case of loss of host, you need to recover the following Windows Registry key.
HKEY_LOCAL_MACHINE\Software\oracle
In addition, when you recover system components, such as Oracle Web Cache, you must recover the following Windows Registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
To import a key that you have previously exported, use the following command:
regedit /I <FileName>
For example:
regedit /I C:\oracleregistry.reg
You can also use the Registry Editor to import the key. See the Registry Editor Help for more information.
If the host that contained your database is lost, you can recover it using RMAN. You can recover the database at the desired granularity, either a full recovery or a tablespace recovery.
For example:
rman> restore database; rman> recover database;
For best results, recover the database to the most current state, using point-in-time recovery (if the database is configured in Archive Log Mode.) This ensures that the latest data is recovered. Note the following:
See Appendix D for the schemas used by each component.
For Oracle BPEL Process Manager, point-in-time recovery ensures that the latest process definitions and in-flight instances are restored. However, this may result in reexecution of the process steps. Oracle recommends that you strive for idempotent Oracle BPEL Process Manager processes. If the system contains processes that are not idempotent, you must clean them up from the dehydration store before starting Oracle Fusion Middleware. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for more information.
For detailed steps, see the Oracle Database Backup and Recovery User's Guide, which is available at:
http://www.oracle.com/technology/documentation/database.html