18.1 Overview of Recovering Your Environment

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, as described in Section 16.4.

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 only restore an entity to the same path as the original entity. That path can be on the same host or a different host.

18.2.1 Recovering a Middleware Home

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:

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.

18.2.3 Recovering an Oracle Home

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

18.2.4 Recovering an Oracle Instance Home

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:

18.2.5Recovering the Administration Server Configuration

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 usernamepassword [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:

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.

18.2.6 Recovering a Managed 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:

This section pertains when Oracle SOA Suite is configured in a domain and no Managed Servers share the domain directory with the Administration Server.

18.2.6.1 Recovering a Managed Server When It Cannot Be Started

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:

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.

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.

18.2.6.3 Recovering an Oracle SOA Suite Managed Server That Has a Separate Directory

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_nameadmin_url

18.2.7 Recovering Components

For most components, the following topics describe how to recover a component:

18.2.7.1 Recovering a Component That Is Not Functioning Properly

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:

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:

18.2.7.2 Recovering a Component After Cluster Configuration Change

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 usernamepassword [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:

18.2.7.3 Recovering Oracle Identity Manager

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 ensure 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, ensure that the Oracle Identity Manager application is again available to the end users. You can monitor the reconciliation with the Oracle Identity Manager console.

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.

18.2.7.10.4 Reconciling the LDAP database with Web Catalog

If the LDAP database is restored to a previous point in time resulting in the LDAP database being behind in time to the Web Catalog, use the following command to reconcile the LDAP database with the Web Catalog:

runcat.cmd -cmd forgetAccounts

18.2.7.11 Recovering Oracle Business Intelligence Publisher

To recover Oracle Business Intelligence Publisher:

Recover the Managed Server containing the Oracle Business Intelligence Publisher component, as described in Section 18.2.6.

If necessary, restore the database containing the Oracle Business Intelligence Publisher schemas, as described in Section 18.2.10.

If backup artifacts are restored from different times, then user accounts, user reports, and user permissions revert to the restored version. Restore all artifacts from the same point in time.

18.2.7.12 Recovering Oracle Real-Time Decisions

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 a different time, the analytic models miss a period of learning, but their intelligence is unaffected.

18.2.7.20 Recovering Oracle Universal Content Management

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.

18.2.7.21 Recovering Oracle Universal Records Management

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

18.2.8 Recovering a Cluster

18.2.8.1 Recovering a Cluster After Deletion or Cluster-Level Configuration Changes

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 usernamepassword [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:

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.

18.2.9.1 Recovering Application Artifacts

If an application's artifacts, such as the .ear file, have been lost or corrupted, you can recover the application.

To recover the application:

Start the Managed Server to which the application was deployed. For example:

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_nameadmin_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.

18.2.9.2 Recovering a Redeployed Application That Is No Longer Functional

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.

18.2.9.3 Recovering an Undeployed Application

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.

18.2.9.4 Recovering a Composite Application

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.

18.2.10 Recovering a Database

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:

18.3 Recovering After Loss of Host

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:

18.3.2.1 Recovering the Administration Server to the Same Host

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:

Recover the file system. For example, recover the domain containing the Administration Server, as described in Section 18.3.1.

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

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.

This section pertains when Oracle SOA Suite is configured in a domain and no Managed Servers share the domain directory with the Administration Server.

18.3.3.1 Recovering a Managed Server to the Same Host

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 Node Manager on Host B:

java weblogic.WLST
wls:/offline> startNodeManager()

Start the Managed Server. For example:

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_nameadmin_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 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:

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

The Managed Server connects to the Administration Server and updates its configuration changes.

18.3.3.2 Recovering a Managed Server to a Different Host

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:

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

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_nameadmin_url

The Managed Server connects to the Administration Server and updates its configuration changes.

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.

18.3.3.3 Recovering an Oracle SOA Suite Managed Server That Has a Separate Directory

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.

18.3.4 Recovering After Loss of Component Host

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:

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:

18.3.4.4 Recovering a System Component to a Different Host

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.

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:

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.

18.3.4.5.4Recovering Oracle Identity Federation to a Different Host

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.

Restart the Managed Server to which Oracle Identity Federation is deployed:

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_nameadmin_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.

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.

18.3.4.5.7 Recovering Oracle Access Manager to a Different Host

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 with Oracle Security Token Service. Also see "OSSO Remote Registration Request" in the same manual.

18.3.4.5.8 Recovering Oracle Adaptive Access Manager to a Different Host

Reassociate the weblogic user with any groups, as described in Section 18.3.5.6.

18.3.4.6 Recovering Oracle SOA Suite After Loss of Host

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.

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.

18.3.4.7 Recovering Web Tier Components to a Different Host

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:

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:

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 must 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:

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.

It is important that you set -DDomainRegistrationEnabled=true whenever you start a Node Manager which must manage the Administration Server. If there is no Administration Server on this computer, and if this computer is not an Administration Server failover node, then Node Manager can be started as follows:

./startNodeManager.sh

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. Fusion Middleware Control prompts you to restart the instances after you have changed their configuration. Restart the instances.

Because instance1 on Host A is no longer available, you must modify its count of BI Servers, Presentation Servers, and JavaHosts to be 0. Fusion Middleware Control prompts you to restart the instances after you have changed their configuration. Restart the instances.

Make instance2 the primary instance and instance3 the secondary instance using Fusion Middleware Control:

Make instance 2 the primary instance and specify the secondary instance as none. Activate and restart the instance as prompted by Fusion Middleware Control.

Make instance3 the secondary instance. Activate and restart the instance as prompted by Fusion Middleware Control.

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.

Start the Oracle BI EE Managed Server and all of the OPMN-managed components.

18.3.4.9.3 Additional Steps for Recovering Oracle BI EE

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:

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:

18.3.4.9.4 Importing Oracle BI Enterprise Edition Registry Entries

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.

18.3.4.10 Recovering Oracle Business Intelligence Publisher to a Different Host

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 revert to the restored version. Restore all artifacts from the same point in time.

18.3.4.11 Recovering Oracle Real-Time Decisions to a Different Host

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 miss a period of learning, but their intelligence is unaffected.

18.3.4.12 Recovering Oracle Essbase After Loss of Host

If Oracle Essbase is in a clustered environment, and the failed host contained Essbase system component clustering using OPMN, take the following additional steps to recover Oracle Essbase. In this scenario, Oracle Essbase clustering is set up on Node A and B, and you lose Node A. You create a new Essbase component on Node C and a new cluster with Essbase components on Node C and Node B. The old cluster is gone and should not be recovered at any time.

Scale out the Oracle BI EE system and the system components on the new host, Node C, as described in Steps 6 and 7 in Section 18.3.4.9.

Mount the shared ARBORPATH directory to the same path on both Node B and Node C. For example, on Windows, map the directory to Drive Y on both Node B and Node C.

Edit the following file on Node B and Node C, to update the adminHost property:

ORACLE_INSTANCE/config/OPMN/opmn/instance.properties

For example:

adminHost=ADMINVHN

On Node C, copy the wallet and push it to the Administration Server:

Copy the wallet from Node B to Node C. The wallet is located in:

ORACLE_INSTANCE/config/OPMN/opmn/wallet

Ensure that the opmn.xml file has ssl enabled="true".

Push the wallet to the Administration Server, using the following command:

./opmnctl updateinstanceregistration

This command prompts for an Oracle WebLogic Server Administrator password. The updateinstanceregistration command updates information registered on the Administration Server for the Oracle instances. Specifically, the updateinstanceregistration command updates the registered OPMN remote port, remote host, and wallet from the current OPMN settings.

Restart OPMN on all nodes:

opmnctl startall

Shut down the Oracle Essbase instance on Node B because it will be made part of the new cluster:

If you lose a host that contains Oracle Hyperion Financial Reporting, you can recover it to the same host or a different host. To recover Oracle Hyperion Financial Reporting, recover the Oracle home, as described in Section 18.2.3 and the Oracle instance, as described in Section 18.2.4.

If the database host has changed, update the host name using the following commands:

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.

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

18.3.5Additional Actions for Recovering Entities After Loss of Host

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.

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/

18.3.5.2 Changing the Host Name in the targets.xml File for Fusion Middleware Control

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.

18.3.5.3 Recovering Oracle Management Agent When Components 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:

18.3.5.5 Creating a New Machine for Certain Components

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:

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.

18.3.5.7 Updating Oracle Inventory

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

18.3.5.8 Recovering the Windows Registry

When you recover any component to a different host on Windows, as in the case of loss of host, you must import any Windows Registry keys related to Oracle Fusion Middleware to the new host. (You exported the Registry keys in Section 17.3.3.

Recover the following Registry key.

HKEY_LOCAL_MACHINE\Software\Oracle

In addition, recover each node that begins with Oracle within the following registry keys:

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.

18.3.6 Recovering After Loss ofDatabase Host

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:

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: