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 they 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:
On Windows, for online recovery, use copy; for offline recovery, use copy, xcopy, or jar.
Note that for some versions of Windows, any file name with more than 256 characters will fail. You can use the xcopy command with the following switches to work around this issue:
xcopy /s/e "C:\Temp\*.*" "C:\copy"
See the xcopy help for more information about syntax and restrictions.
Do not use Winzip because it does not work with long filenames or extensions.
On Linux and UNIX, use tar.
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.
To recover the Middleware home:
Stop all relevant processes. That is, stop all processes that are related to the domain, such as the Administration Server, Node Manager, and Managed Servers. For example, to stop the Administration Server on Linux:
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
Recover the Middleware home directory from backup. For example:
cd MW_HOME
(UNIX) tar -xf mw_home_backup_092010.tar
(Windows) jar xtf mw_home_backup_092010.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, such as the Administration Server and Managed Servers. For example, 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_092010.tar
(Windows) jar xtf domain_backup_092010.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
If you cannot start the Administration Server, recover it, as described in Section 18.2.5.
If you cannot start a Managed Server, recover it, as described in Section 18.2.6.
To recover your Oracle home for a particular component:
Recover the Oracle home to the original directory from a backup file. For example:
cd ORACLE_HOME
tar -xf Oracle_home_backup_092010.tar
Restart the Managed Server to which applications are deployed, using the WLST start command. For example:
wls:/mydomain/serverConfig> start('myserver','Server')
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 Instance_home_backup_092010.tar
(Windows) jar xtf Instance_home_backup_092010.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_092010.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. For example, to stop the Administration Server:
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. For example:
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 18.2.5.
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. For example:
tar -xf mw_home_backup_092010.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:
For stage mode applications, the Administration server copies the application bits to the staged directories on the Managed Server hosts.
For nostage and external_stage mode applications, ensure that application files are available in the stage directories of the Managed Server.
See Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server for information about stage, nostage, and external_stage mode applications.
Start the Managed Server. For example:
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. For example:
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_092010.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:
For stage mode applications, the Administration server copies the application bits to the staged directories on the Managed Server hosts.
For nostage and external_stage mode applications, ensure that application files are available in the stage directories of the Managed Server.
See Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server for information about deploying applications.
Restart the Managed Server. For example:
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_092010.tar
Restart the Managed Server:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
For most components, the following topics describe how to recover a component:
For some components, you must take different steps. Table 18-1 lists those components and the section that describes the procedures to recover them.
Table 18-1 Recovery Procedures for Particular Components
| Component | Procedure |
|---|---|
|
Oracle Access Manager |
|
|
Oracle Adaptive Access Manager |
|
|
Oracle BI Enterprise Edition |
|
|
Oracle Business Intelligence Publisher |
|
|
Oracle Business Process Management |
|
|
Oracle Real-Time Decisions |
|
|
Oracle Data Integrator |
|
|
Oracle Identity Manager |
|
|
Oracle Identity Navigator |
|
|
Oracle Imaging and Process Management |
|
|
Oracle Information Rights Management |
|
|
Oracle Universal Content Management |
|
|
Oracle Universal Records Management |
|
|
Oracle WebCenter Activity Graph |
|
|
Oracle WebCenter Analytics |
You can recover a component if the component's files have been deleted or corrupted or if the component 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.
For Java components, such as Oracle SOA Suite, you recover the Managed Server, as described in Section 18.2.6.
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 16.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 the cluster:
stop('cluster_name', 'Cluster')
Stop all processes, such as the Managed Servers and the Administration Server. For example, to stop the Administration Server on Linux:
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. For example:
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.
To recover Oracle Identity Manager:
Restore the domain, as described in Section 18.2.2.
Restore the Oracle home, as described in Section 18.2.3.
Restore the database containing the OIM, MDS, SOAINFRA, and the OID schemas to the same point in time. See Section 18.2.10.
Oracle Identity Manager stores users and roles in the LDAP store. If you restore the database to a different point in time than the LDAP store, the reconciliation engine checks the change logs and reapplies all the changes that happened in the time period between the restore of the LDAP store and the database. For example, if the database is restored so that is 10 hours behind the LDAP store, the reconciliation engine checks the change logs and reapplies all the changes that happened in the last 10 hours in the LDAP store to the database.
You do not need to explicitly trigger the reconciliation. LDAP synchronization is set up as a periodic scheduled task to submit reconciliation events periodically. You can also start the reconciliation process manually and monitor the reconciliation events from the Oracle Identity Manager console. See "Reconciliation Configuration" in Oracle Fusion Middleware User's Guide for Oracle Identity Manager.
Note:
Oracle recommends that you make sure that the Oracle Identity Manager application is unavailable to the end users when a bulk reconciliation is occurring (as in the above recovery scenario). When the bulk reconciliation is complete, make sure that the Oracle Identity Manager application is again available to the end users. You can monitor the reconciliation with the Oracle Identity Manager console.To recover Oracle Identity Navigator:
Restore the domain, as described in Section 18.2.2.
Restore the Oracle home, as described in Section 18.2.3.
Restore the file-based MDS repository, using the WLST importMetadata command. For example:
importMetadata(application='oinav', server='server_name', fromLocation='export_directory')
To recover Oracle Access Manager:
Restore the Middleware home and the domain home for the Oracle Access Manager Managed Server, as described in Section 18.2.1.
Restore the domain, as described in Section 18.2.2.
Restore the Oracle home for the Oracle HTTP Server that contains the WebGate, if necessary, as described in Section 18.2.3.
Restore the Oracle instance for the Oracle HTTP Server that contains the WebGate, if necessary, as described in Section 18.2.4.
Restore the database containing the schema used by OES for the Oracle Access Manager policy store, if necessary. See Section 18.2.10.
To recover Oracle Adaptive Access Manager:
Restore the domain, as described in Section 18.2.2.
Restore the Oracle home, as described in Section 18.2.3.
Restore the database containing the OAAM schemas, if necessary. See Section 18.2.10.
To recover Oracle Business Process Management:
Restore the Managed Server, as described in Section 18.2.6.
Restore the Oracle homes, as described in Section 18.2.3.
To recover Oracle WebCenter Activities Graph:
Restore the domain, as described in Section 18.2.2.
Restore the Oracle home, as described in Section 18.2.3.
Restore the database containing the ACTIVITIES schema, if necessary.
To recover Oracle WebCenter Analytics:
Restore the domain, as described in Section 18.2.2.
Restore the Oracle home, as described in Section 18.2.3.
Restore the database containing the ACTIVITIES and MDS schemas, if necessary.
The following topics describe how to recover Oracle BI EE:
Recovering Oracle BI Enterprise Edition in a Non-Clustered Environment
Recovering Oracle BI Enterprise Edition in a Clustered Environment
Note:
When you recover Oracle BI EE, you must ensure that the Web Catalog and the Oracle BI EE repository (RPD) are restored to the same point in time, by using the same backup set.This scenario assumes that Oracle BI Enterprise Edition is running in a non-clustered environment.
Restore the following, depending on the extent of the failure:
If the entire Middleware home is lost, restore the Middleware home, as described in Section 18.2.1.
If the Oracle instance home is lost, restore the Oracle instance home, as described in Section 18.2.4.
If the domain home is lost on the Administration Server node, restore it, as described in Section 18.2.5.
If the domain home is lost on the Managed Server node, restore it, as described in Section 18.2.6.
Restore the database containing the Oracle BI EE schemas, if necessary. See Section 18.2.10.
Reconcile the LDAP Database with the Web Catalog and the Oracle BI EE repository (RPD), as described in Section 18.2.7.10.3.
This scenario assumes that Oracle BI Enterprise Edition is running in a non-clustered environment. Recover the following, depending on the extent of the failure:
Restore the following, depending on the extent of the failure:
If the entire Middleware home is lost, restore the Middleware home, as described in Section 18.2.1.
If the Oracle instance home is lost, restore the Oracle instance home, as described in Section 18.2.4.
If the domain home is lost on the Administration Server node, restore it, as described in Section 18.2.5.
If the domain home is lost on the Managed Server node, restore it, as described in Section 18.2.6.
Recover the Administration Server, as described in Section 18.2.5.
Recover the Managed Server, as described in Section 18.2.6.
Restore the database containing the Oracle BI EE schemas, if necessary. See Section 18.2.10.
Reconcile the LDAP Database with the Web Catalog and the Oracle BI EE repository (RPD), as described in Section 18.2.7.10.3.
You must reconcile the LDAP database with the Web Catalog and the Oracle BI EE repository (RPD).
Oracle BI Enterprise Edition provides a method to perform synchronization. You can enable automatic synchronization, at all times, or temporarily to perform the synchronization.
To enable synchronization, edit the following file:
INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI
Set the flag FMW_UPDATE_ROLE_AND_USER_REF_GUIDS to yes. Then, restart the servers. The information in the LDAP database and the Web Catalog and RPD will be synchronized.
On Windows, the Oracle BI Administration Tool provides a Consistency Check Manager that checks the validity of your repository and allows you to correct the inconsistencies. For more information, see "Checking the Consistency of Repository Objects" in the Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition.
To recover Oracle Business Intelligence Publisher:
Recover the Managed Server containing the Oracle Business Intelligence Publisher component, as described in Section 18.2.6.
Restore the database containing the Oracle Business Intelligence Publisher schemas, if necessary. See Section 18.2.10.
If backup artifacts are restored from different times, then user accounts, user reports, and user permissions will revert to the restored version. Restore all artifacts from the same point in time.
To recover Oracle Real-Time Decisions:
Recover the Managed Server containing the Oracle Real-Time Decisions component, as described in Section 18.2.6.
Note that if backup artifacts are restored from different time, the analytic models will have missed a period of learning, but their intelligence will be unaffected.
To recover Oracle Data Integrator:
If the database must be restored, restore it, as described in Section 18.3.6.
Recover the Oracle Data Integrator Oracle home from backup, as described in Section 18.2.3.
cd ORACLE_HOME
tar -xf oracle_home_backup_092010.tar
Recover the domain directory from backup:
cd DOMAIN_HOME
tar -xf domain_backup_092010.tar
To recover Oracle Information Rights Management:
Restore the domain, as described in Section 18.2.2.
Restore the shared file system.
Restore the database, if necessary. See Section 18.2.10.
Note that the database and the keystore must be kept synchronized. If you restore one, restore the other to the same point in time.
Restore the keystore.
Oracle Imaging and Process Management stores data in the following locations:
A database for Oracle I/PM configuration data
A database that functions as a document repository
JMS persistent queues
When you recover Oracle I/PM, you should ensure that all data is restored from the same point-in-time.
To recover Oracle I/PM:
Restore the domain, as described in Section 18.2.2.
Restore the database containing the IPM and OCS schemas, if necessary. See Section 18.2.10.
To recover Oracle Universal Content Management:
If the database must be restored, restore it, as described in Section 18.3.6.
Restore the domain, as described in Section 18.2.2.
If the Vault, WebLayout, or Search directories are not located in the domain directory, restore those directories, if necessary. For example, if the Vault directory is located on a shared drive in /net/home/vault, restore it from backup:
cd /net/home/vault tar -xf vault_backup_092010.tar
Note that you should restore the database and the shared file system at the same time. If you cannot do that, you can use the IDCAnalyse utility to determine if there are any inconsistencies between the database and the shared file system. If there are, you can perform a manual recovery using IDCAnalyse.
Because Oracle Universal Records Management depends on Oracle Universal Content Management and has no additional backup and recovery artifacts, see the recovery procedure for Oracle Universal Content Management in Section 18.2.7.16.
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. For example:
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. For example:
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. For example, to stop the Administration Server on Linux:
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. For example:
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. 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 nostage 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 applicationsIf 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. For example:
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.To recover an Oracle WebLogic Server domain:
Stop all relevant processes. That is, stop all processes that are related to the domain, such as the Administration Server and Managed Servers. For example, 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_092010.tar
(Windows) jar xtf domain_backup_092010.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
If you cannot start the Administration Server, recover it, as described in Section 18.3.2.
If you cannot start a Managed Server, recover it, as described in Section 18.3.3.
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 must be recovered.
To recover the Administration Server to the same host:
Attempt to start the Administration Server. For example:
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, such as the Administration Server and Managed Servers. For example, to stop the Administration Server on Linux:
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]
Recover the Middleware home, if needed:
tar -xf mw_home_backup_092010.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_092010.tar
Start the Administration Server. For example:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
Start the Managed Servers, specifying the Administration URL for the host:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Start the Node Manager:
java weblogic.WLST wls:/offline> startNodeManager()
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 must be moved to Host C.
To recover the Administration Server to a different host:
Recover the Middleware home to Host C (the new Host):
cd MW_HOME
tar -xf mw_home_backup_092010.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_092010.tar
If the Administration Server has a Listen address, create a new machine with the new host name, as described in Section 18.3.5.5.
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. For example:
DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
Start the Managed Servers. The section "Restarting a Failed Administration Server" in the Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server describes different ways to restart them, depending on how they were configured.
One option is to use the following script, specifying the Administration URL of the new host:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
Ensure that additional application artifacts are available. For example, if the deployment mode is nostage 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 18.3.5.7.
If your environment contains Oracle HTTP Server, modify the mod_wl_ohs.conf file, as described in Section 18.3.5.4.
Edit the targets.xml file for Fusion Middleware Control, as described in Section 18.3.5.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 shows 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 18.3.5 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 must be recovered to Host B.
To recover a Managed Server to the same host:
Start the Node Manager on Host B:
java weblogic.WLST wls:/offline> startNodeManager()
Start the Managed Server. For example:
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_092010.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_092010.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:
For applications that are deployed in nostage or external_stage mode, copy the application artifacts from the Administration Server host directory.
For applications that are deployed in stage mode, the Administration server copies the application bits to the staged directories on the Managed Server hosts.
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. For example:
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 must be recovered to Host C.
Important:
Recover the Middleware home to the same location as the original.To recover a Managed Server to a different host:
Recover the Middleware home for the Managed Server to Host C.
tar -xf mw_home_backup_092010.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_092010.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:
For applications that are deployed in nostage or external_stage mode, copy the application artifacts from the Administration Server host directory.
For applications that are deployed in stage mode, the Administration server copies the application bits to the staged directories on the Managed Server hosts.
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. For example:
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 18.3.5.7.
If your environment contains Oracle HTTP Server, modify the mod_wl_ohs.conf file, as described in Section 18.3.5.4.
Edit the targets.xml file for Fusion Middleware Control, as described in Section 18.3.5.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.
To recover to the same host or a different host, use the procedures in Section 18.2.6.3.
If you lose a host that contains a component (and its Managed Server, if applicable), you can recover most components to the same host or a different host using the procedures described in the following topics:
Some components require additional actions, which are described in the sections listed in Table 18-2.
Table 18-2 Recovery Procedures for Loss of Host for Particular Components
| Component | Procedure |
|---|---|
|
Oracle Access Manager |
|
|
Oracle Adaptive Access Manager |
|
|
Oracle BI Discoverer |
|
|
Oracle BI Enterprise Edition |
|
|
Oracle BI Publisher |
|
|
Oracle Business Process Management |
No additional steps needed for loss of host. See Section 18.2.7.7 for information about recovering Oracle Business Process Management. |
|
Oracle Data Integrator |
|
|
Oracle Directory Integration Platform |
|
|
Oracle Forms Services |
|
|
Oracle HTTP Server |
|
|
Oracle Identity Federation |
|
|
Oracle Identity Manager |
|
|
Oracle Identity Navigator |
|
|
Oracle Imaging and Process Management |
No additional steps needed for loss of host. See Section 18.2.7.15 for information about recovering Oracle Imaging and Process Management. |
|
Oracle Information Rights Management |
No additional steps needed for loss of host. See Section 18.2.7.14 for information about recovering Oracle Information Rights Management. |
|
Oracle Internet Directory |
|
|
Oracle Portal |
|
|
Oracle Real-Time Decisions |
|
|
Oracle Reports |
|
|
Oracle SOA Suite |
No additional steps needed if recovering to the same host. See Section 18.3.4.6 for information about recovering to a different host. |
|
Oracle Universal Content Management |
|
|
Oracle Universal Records Management |
|
|
Oracle Virtual Directory |
|
|
Oracle Web Cache |
|
|
Oracle WebCenter Activity Graph |
No additional steps needed for loss of host. See Section 18.2.7.8 for information about recovering Oracle WebCenter Activity Graph. |
|
Oracle WebCenter Analytics |
No additional steps needed for loss of host. See Section 18.2.7.9 for information about recovering Oracle WebCenter Analytics. |
To recover a Java component to the same host, such as Oracle SOA Suite:
Recover the Managed Server, as described in Section 18.2.6.1.
If the component requires additional steps, as noted in Table 18-2, take those steps.
To recover a Java component to a different host, such as Oracle SOA Suite:
Recover the Managed Server, as described in Section 18.3.3.2.
Edit the targets.xml file for Fusion Middleware Control, as described in Section 18.3.5.2.
However, note that some components require additional steps, as noted in Table 18-2.
To recover a system component, such as Oracle HTTP Server, to the same host, you take the following general steps. However, note that some components require additional steps, as noted in Table 18-2.
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 16.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, to a different host, you take the following general steps. However, note that most components require additional steps, as noted in Table 18-2.
Recover the Middleware home, as described in Section 18.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 18.3.5.2.
For most Identity Management components, you recover the Managed Server, as described in Section 18.3.3.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 Adaptive Access Manager to a Different Host
To recover Oracle Internet Directory to a different host:
Recover the component as described in Section 18.3.4.4.
On UNIX and Linux systems, before you attempt to start Oracle Internet Directory, set the following file to have root permission:
ORACLE_HOME/bin/oidldapd
For example:
chown root oidldapd chmod 4710 oidldapd
Recover Oracle Management Agent, as described in Section 18.3.5.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 keystore 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. If you delete the file, Oracle Directory Services Manager creates a new file when it starts, with the new password.
To recover Oracle Virtual Directory to a different host:
Recover the component as described in Section 18.3.4.4.
Recover Oracle Management Agent, as described in Section 18.3.5.3.
To recover Oracle Directory Integration Platform to a different host:
Recover the Managed Server, as described in Section 18.3.3.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
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 may 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 must use a different host name for recovering Oracle Identity Federation, then the host name must 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 18.3.3.2.
Recover Oracle Management Agent, as described in Section 18.3.5.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.
To recover Oracle Identity Manager to a different host:
Restore the domain, as described in Section 18.3.2.
Restore the Oracle home, as described in Section 18.2.3.
Restore the database containing the OIM, OID, MDS, and SOAINFRA schemas, if necessary. See Section 18.2.10.
Synchronize the Oracle Identity Manager database and the LDAP provider. See the Oracle Fusion Middleware Command Reference for Oracle WebLogic Server for more information.
Export the oim-config.xml file, using the weblogicExportMetadata.sh script. Then, edit the file, changing the host name or IP address for the SOA URL. Import the file into MDS, using the weblogicImportMetadata.sh script.
Create a new machine with the new host name, as described in Section 18.3.5.5.
Reassociate the weblogic user with any groups, as described in Section 18.3.5.6.
To recover Oracle Identity Navigator to a different host:
Create a new machine with the new host name, as described in Section 18.3.5.5.
Reassociate the weblogic user with any groups, as described in Section 18.3.5.6.
To recover Oracle Access Manager to a different host:
Follow the instructions in Section 18.2.7.5.
To restore the WLS Agent, restore the Managed Server, as described in Section 18.3.3.2.
Log into the Oracle Access Manager console.
Select the Oracle Access Manager proxy server.
Modify Host, specifying the new host name.
If you have protected pages, you must reregister Oracle Single Sign-On or WebGate as partners with Oracle Access Manager, using the oamreg tool, described in "About the Remote Registration Tool" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager. Also see "OSSO Remote Registration Request" in the same manual.
Create a new machine with the new host name, as described in Section 18.3.5.5.
Edit the WebGate configuration file, obAccessClient.xml, to update the host name for the Oracle Access Manager server. The file is located in the following directory:
DOMAIN_HOME/output/agentName/
Reassociate the weblogic user with any groups, as described in Section 18.3.5.6.
To recover Oracle Adaptive Access Manager to a different host:
Follow the instructions in Section 18.2.7.6.
Create a new machine with the new host name, as described in Section 18.3.5.5.
Reassociate the weblogic user with any groups, as described in Section 18.3.5.6.
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 18.3.3.3. Otherwise, follow the steps in this section.
To recover the Oracle SOA Suite Managed Server to the same host, recover the Managed Server, as described in Section 18.3.3.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 18.3.3.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 must 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, 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.
The Web tier consists of Oracle HTTP Server and Oracle Web Cache. The following topics describe how to recover these components to a different host:
To recover Oracle HTTP Server to a different host:
Recover the component as described in Section 18.3.4.4.
Recover Oracle Management Agent, as described in Section 18.3.5.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 18.3.4.4.
Recover Oracle Management Agent, as described in Section 18.3.5.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
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, the domain directory, and the Oracle instance directory to the new host. See Section 18.3.3.2 for more information.
Recover Oracle Management Agent, as described in Section 18.3.5.3.
If the instance has been deregistered, 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
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.
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 6:
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 must 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 Forms Services to a different host:
Recover the Managed Server as described in Section 18.3.3.2.
Recover Oracle Management Agent, as described in Section 18.3.5.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
To recover Oracle Reports to a different host:
Recover the Managed Server as described in Section 18.3.3.2.
Recover Oracle Management Agent, as described in Section 18.3.5.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) DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration (Windows) DOMAIN_HOME\config\fmwconfig\servers\server_name\applications\reports_version\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
In the following file, replace occurrences of the host name with the new host name:
(UNIX) DOMAIN_HOME/servers/server_name/tmp/_WL_user/reports_version/random_string/META-INF/mbeans.xml (Windows) DOMAIN_HOME\servers\server_name\tmp\_WL_user\reports_version\random_string\META-INF\mbeans.xml
In the following file, replace occurrences of the host name with the new host name:
ORACLE_INSTANCE/EMAGENT/emagent_<instanceName>/sysman/emd/targets.xml
You change the host name in the elements beginning with the following:
<Target TYPE="oracle_repapp" ..> <Target TYPE="oracle_repserv" ..>
To recover Oracle Business Intelligence Discoverer to a different host:
Recover the Managed Server as described in Section 18.3.3.2.
Recover Oracle Management Agent, as described in Section 18.3.5.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
You can recover Oracle BI Enterprise Edition to a different host, but the new host must have the same name as the original host.
Note:
You cannot recover Oracle BI EE or any other component which is co-located with Oracle BI EE to a new host that has a new host name. You can only recover Oracle BI EE and other components to a new host with the same host name as the original host. For example, if Oracle BI EE is co-located with Oracle Real-Time Decisions and Oracle Business Intelligence Publisher, none of these components can be recovered to a new host with different host name.The following topics describe how to move Oracle BI EE to a different host with the same name:
Recovering Oracle BI Enterprise Edition to a Different Host in a Non-Clustered Environment
Recovering Oracle BI Enterprise Edition to a Different Host in a Clustered Environment
The steps you take to recover Oracle BI EE to a different host depends on the operating system:
On UNIX, take the following steps:
Restore the Middleware home, as described in Section 18.2.1.
Restore the database containing the Oracle BI EE schemas, if necessary. See Section 18.3.6.
On Windows, take the following steps:
Restore the Middleware home from backup, as described in Section 18.2.1, overwriting the Middleware home that you created with the new installation.
Restore the database containing the Oracle BI EE schemas, if necessary. See Section 18.3.6.
Install the C++ libraries from Microsoft, by executing the following file:
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
Import the Registry entries that you exported into the new host, as described in Section 18.3.4.9.4.
In this scenario, you have an Oracle BI EE cluster on two hosts, Host A and Host B. Host A must be replaced for some reason, such as losing the original operating system, and you must recover to Host C.
Take the following steps:
Restore the Middleware home from backup to Host C, as described in Section 18.2.1.
Restore the database containing the Oracle BI EE schemas, if necessary. See Section 18.3.6.
On Windows, install the C++ libraries from Microsoft, by executing the following file:
Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe
On Windows, import the Registry entries that you exported into the new host, as described in Section 18.3.4.9.4.
If the failed node contained the Administration Server, recover it, as described in steps 1 through 5 in Section 18.3.2.2.
Scale out the Oracle BI EE system, as described in "Scaling Out the BI System on APPHOST2" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
When you enter the directory specifications for the Domain Home and Applications Home, enter specifications for directories that do not yet exist or that are empty.
Scale out the system components, as described in "Scaling Out the System Components" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
Because instance1 on Host A is no longer available, you must modify its count of BI Servers, Presentation Servers, and JavaHosts to be 0.
Then, instance2 on Host B automatically becomes the primary instance. The new instance on Host C, instance3, becomes the secondary instance.
The Oracle BI Cluster Controllers and Oracle BI Scheduler are singleton components that operate in active/passive mode. Configure a secondary instance of these components so that they are distributed for high availability, as described in "Configuring Secondary Instances of Singleton System Components" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
Set the listen address of the bi_servern Managed Server, as described in "Setting the Listen Address for the bi_server2 Managed Server" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
Disable host name verification for the bi_servern Managed Server, as described in "Disabling Host Name Verification for the bi_server2 Managed Server" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
Depending on your configuration, perform additional configuration, as described in "Performing Additional Configuration for Oracle Business Intelligence Availability" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
If Oracle HTTP Server is installed, set the frontend HTTP host and port for the Oracle WebLogic Server cluster to ensure that Oracle BI Search URLs are set correctly, as described in "Setting the Frontend HTTP Host and Port" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
Configure Node Manager for the Managed Servers as described in "Configuring Node Manager for the Managed Servers" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
Start the Oracle BI EE Managed Server and all of the OPMN-managed components.
Depending on your environment, you may need to take additional steps after you perform the steps in Section 18.3.4.9.2:
If the failed host contained the master BI Server, primary cluster controller, and primary Oracle BI Scheduler and you want the new instance to be the master BI Server, take the following steps as appropriate. Note that if you want to leave instance2 as the master BI server, you do not need to take these additional steps.
If the master BI Server is lost:
Stop Oracle WebLogic Server and OPMN processes on all nodes.
Update the following configuration file to designate a new master BI Server:
INSTANCE_HOME/config/OracleBIApplication/coreapplication/ClusterConfig.xml
For example, change the instance number in the NodeId element and change the host name or IP address in the HostNameOrIP element;
<Node>
<NodeType>Server</NodeType>
<!--This Configuration setting is managed by Oracle Business
Intelligence Enterprise Manager-->
<MasterServer>true</MasterServer>
<!--This Configuration setting is managed by Oracle Business
Intelligence Enterprise Manager-->
<NodeId>instance2:coreapplication_obis1</NodeId>
<!--This Configuration setting is managed by Oracle Business
Intelligence Enterprise Manager-->
<HostNameOrIP>host1.example.com</HostNameOrIP>
<!--This Configuration setting is managed by Oracle Business
Intelligence Enterprise Manager-->
<ServicePort>9703</ServicePort>
<!--This Configuration setting is managed by Oracle Business
Intelligence Enterprise Manager--><MonitorPort>9701</MonitorPort>
</Node>
If the primary cluster controller or scheduler is lost, it fails over to the standby cluster controller or scheduler. You must determine whether you want to reconfigure it to be the primary cluster controller or scheduler or leave it as secondary that has been activated because the primary components have failed. For more information, see "Configuring Secondary Instances of Singleton System Components" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.
If the failed host contained the BI Server, the secondary cluster controller, and the secondary Oracle BI Scheduler, designate the new host as the secondary cluster controller or scheduler.
If the failed host contained the BI Server and system components such as BI Presentation Services and BI Java hosts, no additional steps are needed.
If the failed host contained the following related components, recover them:
Oracle Business Intelligence Publisher: See Section 18.3.4.10.
Oracle Real-Time Decisions: See Section 18.3.4.11.
On Windows, you must import the Oracle BI Enterprise Edition Registry entries to the new host. Section 17.3.3 describes how to export them from the original host.
Copy all the files that you exported from the original host to the new host.
Double-click each file you copied from the original host. Click Yes when prompted, to import the file into the Registry.
To recover Oracle Business Intelligence Publisher to a different host:
Recover the Managed Server containing the Oracle Business Intelligence Publisher component, as described in Section 18.3.3.
Restore the database containing the Oracle Business Intelligence Publisher schemas, if necessary. See Section 18.2.10.
If backup artifacts are restored from different time, then user accounts, user reports, and user permissions will revert to the restored version. Restore all artifacts from the same point in time.
To recover Oracle Real-Time Decisions to a different host:
Recover the Managed Server containing the Oracle Real-Time Decisions component, as described in Section 18.3.3.
Note that if backup artifacts are restored from different time, the analytic models will have missed a period of learning, but their intelligence will be unaffected.
To recover Oracle Data Integrator to a different host:
If the database must be restored to a different host, restore it as described in Section 18.3.6.
Recover the Oracle Data Integrator Oracle home from backup, as described in Section 18.2.3
Restore the domain, as described in Section 18.3.2.
Stop each standalone agent, and stop the Oracle Data Integrator applications deployed in Oracle WebLogic Server.
Modify the repository connection information in the topology, if the database is on a different host:
Connect to the restored Oracle Data Integrator repository using ODI Studio. Create a new connection for the master repository to the new database host, as described in "Connecting to the Master Repository" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Edit each of the Work Repositories. Click Connection and edit the connection information so that the JDBC URL points to the new database host containing the work repository.
Edit each physical agent's configuration and provide the updated Host Name value and, if changed, the Port value.
If there are standalone agent scripts generated and they contain the -PORT property, change the -PORT value to the new port value. The scripts are named agentName_agent.sh or agentName_agent.bat.
For each standalone agent, edit the following files and change the ODI_MASTER_URL parameter to match the new database host location, if the database is on a different host:
oracledi/agent/bin/odiparams.*
Edit the following file to change the database connection information and the port number:
oracledi/agent/bin/odi_opmn_standaloneagent_template.xml
In the Oracle WebLogic Server configuration, edit the Data Sources to match the new database host location.
Restart the standalone agents and the Oracle Data Integrator applications deployed in Oracle WebLogic Server.
The following sections describe how to recover Oracle Universal Content Management and Oracle Universal Records Management to a different host:
Recovering Oracle Universal Content Management to a Different Host
Recovering Oracle Universal Records Management After Loss of Host
To recover Oracle Universal Content Management to a different host:
If the database must be restored to a different host, restore it, as described in Section 18.3.6.
Restore the domain, as described in Section 18.3.2.
If the Vault, WebLayout, or Search directories are not located in the domain directory, restore those directories, if necessary. For example, if the Vault directory is located on a shared drive in /net/home/vault, restore it from backup:
cd /net/home/vault tar -xf vault_backup_092010.tar
Edit the following file:
DOMAIN_HOME/ucm_domain/ucm/cs/config/config.cfg
In the file, change the HttpServerAddress setting to specify the new host. For example:
HttpServerAddress=hostname:port_number
Note that you should restore the database and the shared file system at the same time. If you cannot do that, you can use the IDCAnalyse utility to determine if there are any inconsistencies between the database and the shared file system. If there are, you can perform a manual recovery using IDCAnalyse.
Because Oracle Universal Records Management depends on Oracle Universal Content Management and has no additional backup and recovery artifacts, see the recovery procedure for Oracle Universal Content Management in Section 18.3.4.13.1.
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.
The following topics describe the actions you may need to take:
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:
DOMAIN_HOME/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:
DOMAIN_HOME/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.
When you recover an Administration Server or a Managed Server to a different host and your environment includes Oracle HTTP Server, you must modify the following file on the new host:
(UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/mod_wl_ohs.conf (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\mod_wl_ohs.conf
Modify all of the instances of the host name, port, and clusters (elements such as WebLogicHost, WebLogicPort, and WebLogicCluster) entries in that file. For example:
<Location /console>
SetHandler weblogic-handler
WebLogicHost Admin_Host
WeblogicPort Admin_Port
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
.
.
.
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8001,*SOAHOST2VHN1*:*8001*
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
For the following Identity Management components (and for the Administration Server if it has an Listen address,) you must create a new machine with the new host name before you start the Administration Server:
Oracle Access Manager
Oracle Adaptive Access Manager
Oracle Identity Manager
Oracle Identity Navigator
Take the following steps:
Create a new machine with the new host name. Use the following WLST commands, in offline mode:
wls:/offline> readDomain('DomainHome')
wls:/offline/sampledomain> machine = create('newhostname', 'Machine')
wls:/offline/sampledomain> cd('/Machine/newhostname')
wls:/offline/sampledomain> nm = create('newhostname', 'NodeManager')
wls:/offline/sampledomain> cd('/Machine/newhostname/NodeManager/newhostname')
wls:/offline/sampledomain> set('ListenAddress', 'newhostname')
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()
For the Administration Server, set the machine with the new host name, using the following WLST command, in offline mode:
wls:/offline> readDomain('DomainHome')
wls:/offline/sampledomain> cd ('/Machine/newhostname')
wls:/offline/sampledomain> machine = cmo
wls:/offline/sampledomain> cd ('/Server/AdminServer')
wls:/offline/sampledomain> set('Machine', machine)
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()
When you restore a backup of the following Identity Management components, the weblogic user is no longer associated with groups to which it had previously been associated:
Oracle Access Manager
Oracle Adaptive Access Manager
Oracle Identity Manager
Oracle Identity Navigator
You must reassociate the weblogic user with the groups.
For information about associating a user with a group, see the section "Add Users to Groups" in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
For many components, when you recover to a different host, as in the case of loss of host, you must 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 must 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 the database using RMAN.
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. Also, use the same name for the database. 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 and Oracle Business Process Management Suite for more information.
For detailed steps about recovering a database and using RMAN, see the Oracle Database Backup and Recovery User's Guide, which is available at:
http://www.oracle.com/technology/documentation/database.html