17 Recovering Your Environment

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:

17.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 are permanently lost. This type of failure requires some type of data restoration before the Oracle Fusion Middleware environment can be restarted and continue with normal processing.

Note:

The procedures in this chapter assume that no administrative changes were made since the last backup. If administrative changes were made since the last backup, they must be reapplied after recovery is complete.

When you restore the files, use your preferred tool to extract the compressed files.

For example, for online recovery on Windows, use copy; for offline recovery on Windows, use copy, xcopy, or jar. Do not use Winzip because it does not work with long filenames or extensions.

For example, for Linux and UNIX, use tar.

Do not use the jar utility to archive and compress the file system. This avoids warnings or errors from the zip tool about zipping open files (for example, the ORACLE_HOME/jdk files).

Ensure that the tool you are using preserves the permissions and timestamps of the files.

Rename existing files and directories before you begin restoring the files from backup so that you do not unintentionally override necessary files.

17.2 Recovering After Data Loss, Corruption, Media Failure, or Application Malfunction

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:

17.2.1 Recovering a Middleware Home

You can recover a Middleware home that was corrupted or from which files were deleted.

  1. Stop all relevant processes. That is, stop all processes that are running from that Middleware home.

    For example, stop the Oracle WebLogic Server Administration Server processes and the Node Manager processes.

  2. Recover the Middleware home directory from backup. For example:

    cd MW_HOME
    (UNIX) tar -xf mw_home_backup_092909.tar
    (Windows) jar xtf mw_home_backup_092909.jar
    
  3. 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
    

17.2.2 Recovering an Oracle WebLogic Server Domain

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:

  1. Stop all relevant processes. That is, stop all processes that are related to the domain. For example, stop the Administration Server and Managed Servers. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script to stop the Administration Server:

    DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
    
  2. Recover the domain directory from backup:

    cd DOMAIN_HOME
    (UNIX) tar -xf domain_backup_092909.tar 
    (Windows) jar xtf domain_backup_092909.jar 
    
  3. 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
    

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

17.2.3.1 Recovering After Oracle Instance Home Deleted from File System

To recover an Oracle instance home that was corrupted or deleted from the file system:

  1. Stop all relevant processes. That is, kill all processes that are related to that Oracle instance

  2. Recover the Oracle instance home directory from a backup file. For example:

    cd ORACLE_INSTANCE
    (UNIX) tar -xf sc_home_backup_092909.tar 
    (Windows) jar xtf sc_home_backup_092909.jar
    
  3. Start all relevant processes. That is, start all processes that are related to that Oracle instance:

    opmnctl startall
    

17.2.3.2 Recovering After Oracle Instance Home Deregistered

To recover an Oracle instance home that was deregistered from the domain:

  1. Recover the Oracle instance home directory from a backup file. For example, on Linux:

    cd ORACLE_INSTANCE
    tar -xf Instance_home_backup_092909.tar 
    
  2. 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
    

17.2.4 Recovering 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:

  1. Stop all processes, including the Administration Server, Managed Servers, and Node Manager if they are started. You can use the Oracle WebLogic Server Administration Console, WLST, or a script. For example, to stop the Administration Server on Linux, use the following script:

    DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
    
  2. 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
    
  3. Start the Administration Server. You can use WLST or the following script:

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
       -Dweblogic.management.password=password
       -Dweblogic.system.StoreBootIdentity=true
    
  4. 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.

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

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

  1. If the Administration Server is not reachable, recover the Administration Server, as described in Section 17.2.4.

  2. If the Managed Server fails to start or if the file system is lost, take the following steps:

    1. Recover the Middleware home from the backup, if required.

      tar -xf mw_home_backup_092909.tar 
      
    2. 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.

    3. 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
      
    4. 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 takes care of pushing the bits to the stage directories in the Managed Server.

      • For no-stage 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, no-stage, and external-stage mode applications.

    5. Start the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
                admin_url 
      

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

17.2.5.2 Recovering a Managed Server When It Does Not Function Correctly

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:

  1. Stop the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:

    DOMAIN_HOME/bin/stopManagedWeblogic.sh managed_server_name admin_url
            username password
    
  2. Recover the Middleware home from the backup, if required:

    tar -xf mw_home_backup_092909.tar 
    
  3. 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.

  4. 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
    
  5. 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 takes care of pushing the bits to the stage directories in the Managed Server.

    • For no-stage 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.

  6. Restart the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
              admin_url 
    

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

  1. Restore the Managed Server from backup:

    cd ManagedServer_Home
    tar -xf managed_server_backup_092909.tar 
    
  2. Restart the Managed Server:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
              admin_url 
    

17.2.6 Recovering Components

The following topics describe how to recover a component:

17.2.6.1 Recovering After a Component's Files Are Deleted or Corrupted

You can recover a component's files if they are deleted or corrupted. The steps you take depend on the type of component:

  • For a Java component, such as Oracle SOA Suite, you recover the Managed Server, as described in Section 17.2.5.

  • For system components, such as Oracle HTTP Server or Oracle Web Cache:

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

    2. Recover the component-specific files from backup. Section 15.5 lists the directories and files needed for each component. For example, to recover Oracle HTTP Server files, you recover the following directories:

      ORACLE_INSTANCE/config/OHS/component_name
      ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
      
    3. 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.

17.2.6.2 Recovering a Component That Is Not Functioning Properly After Configuration Change

You can recover a component that cannot be started or is not functioning properly because the component's configuration was changed and committed. You may not be able to ascertain what change is causing the problem and you want to revert to an earlier version.

The steps you take depend on the type of component:

  • For a Java component, such as Oracle SOA Suite, you recover the Managed Server, as described in Section 17.2.5.

  • For system components, such as Oracle HTTP Server:

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

    2. Recover the component-specific files from backup. Section 15.5 lists the directories and files needed for each component. For example, to recover Oracle HTTP Server files, you recover the following directories:

      ORACLE_INSTANCE/config/OHS/component_name
      ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
      
    3. 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.

17.2.6.3 Recovering Components 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:

  1. Stop all processes, such as the Managed Servers and the Administration Server. You can use the Oracle WebLogic Server Administration Console, WLST or a script. For example, to stop the Administration Server on Linux, use the following script:

    DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
    
  2. 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
    
  3. Start the Administration Server. You can use WLST or the following script:

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
     -Dweblogic.management.password=password
     -Dweblogic.system.StoreBootIdentity=true
    
  4. 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.

17.2.7 Recovering a Cluster

The following topics describe how to recover a cluster:

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

  1. Stop the cluster. You can use the Oracle WebLogic Server Administration Console or WLST. For example, to use WLST:

    stop('clusterName', 'Cluster')
    
  2. Stop the Administration Server. You can use WLST or the following script:

    DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
    
  3. 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
    
  4. Start the Administration Server. You can use WLST or the following script:

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
     -Dweblogic.management.password=password
     -Dweblogic.system.StoreBootIdentity=true
    
  5. Start the cluster. You can use the Oracle WebLogic Server Administration Console or WLST. For example, to use WLST:

    start('clusterName', 'Cluster')
    

17.2.7.2 Recovering a Cluster After Membership Is Mistakenly Modified

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:

  1. Stop all processes, such as the Managed Servers and the Administration Server. You can use the Oracle WebLogic Server Administration Console, WLST or a script. For example, to stop the Administration Server on Linux, use the following script:

    DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
    
  2. 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
    
  3. Start the Administration Server. You can use WLST or the following script:

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
       -Dweblogic.management.password=password
       -Dweblogic.system.StoreBootIdentity=true
    

    The deleted member is now back in the cluster.

  4. Start all processes, such as the Managed Servers. You can use WLST or a script. For example, to start the Managed Server on Linux, use the following script:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
              admin_url 
    
  5. 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.

  6. Start all cluster members if they are not started:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
    

17.2.8 Recovering Applications

The following topics describe how to recover an application:

Note the following about recovering applications:

  • If the application is staged, the Administration server copies the application bits to the staged directories on the Managed Server hosts.

  • If the deployment mode is no-stage or external stage, ensure that additional application artifacts are available. For example, applications may reside in directories outside of the domain directory. Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.

See Also:

Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server for information about deploying applications

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

  1. Start the Managed Server to which the application was deployed. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
    

    This synchronizes the configuration with the Administration Server.

    On each Managed Server restart, the configuration and application artifacts are retrieved from the Administration Server.

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

  1. Recover the application files from backup, if needed.

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

17.2.8.3 Recovering an Undeployed Application

If a deployed application was undeployed from Oracle WebLogic Server, you can recover it.

To recover the application:

  1. Recover the application files from backup, if needed.

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

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

  1. Recover the application files from backup, if needed.

  2. Redeploy the old version of the application. If the application was deployed to a cluster, redeploy the application to the same cluster.

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

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

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

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.

17.3.1 Recovering After Loss of Administration Server Host

If you lose a host that contains the Administration Server, you can recover it to the same host or a different host, as described in the following topics:

17.3.1.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 needs to be recovered.

To recover the Administration Server:

  1. Attempt to start the Administration Server. You can use WLST, or the following script:

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
     -Dweblogic.management.password=password
     -Dweblogic.system.StoreBootIdentity=true
    

    If the Administration Server starts, you do not need to take any further steps.

  2. If the Administration Server fails to start, take the following steps on Host A:

    1. Stop all relevant processes. That is, stop all processes that are related to the domain. For example, stop the Administration Server and Managed Servers. You can use WLST or the following script to stop the Administration Server:

      DOMAIN_HOME/bin/stopWeblogic.sh username password admin_url
      
    2. Recover the Middleware home, if needed:

      tar -xf mw_home_backup_092909.tar 
      
    3. If the domain directory does not reside in the Middleware home, recover the domain directory from backup:

      cd DOMAIN_HOME
      tar -xf domain_backup_092909.tar 
      
    4. Start the Administration Server. You can use WLST or the following script:

      DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
          -Dweblogic.management.password=password
          -Dweblogic.system.StoreBootIdentity=true
      
    5. Start the Node Manager:

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

Now you can start and stop the Managed Server on Host B using the Administration Console running on Host A.

17.3.1.2 Recovering the Administration 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 A has failed for some reason and the Administration Server needs to be moved to Host C.

  1. Recover the Middleware home to Host C (the new Host where the Administration Server will be recovered).

    cd MW_HOME
    tar -xf mw_home_backup_092909.tar 
    
  2. If the domain directory does not reside in the Middleware home, recover the domain directory from backup:

    cd DOMAIN_HOME
    tar -xf domain_backup_092909.tar 
    
  3. Start the Node Manager on Host C if it was configured on the original host:

    java weblogic.WLST
    wls:/offline> startNodeManager()
    
  4. Start the Administration Server. You can use WLST or the following script:

    DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=username
     -Dweblogic.management.password=password
     -Dweblogic.system.StoreBootIdentity=true
    
  5. Ensure that additional application artifacts are available. For example, if the deployment mode is no-stage or external stage, applications may reside in directories outside of the domain directory. Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.

    If the application is staged, the Administration Server copies the application bits to the staged directories on the Managed Server hosts.

  6. Update Oracle Inventory, as described in Section 17.3.4.4.

  7. Edit the targets.xml file for Fusion Middleware Control, as described in Section 17.3.4.2.

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

    1. 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/
      
    2. Shut down and restart the EM Agent process:

      cd $ORACLE_INSTANCE/EMAGENT/emagent_dir
      ./emctl stop agent
      ./emctl start agent
      ./emctl status agent
       
      

      The status command will show the REPOSITORY_URL pointing to the new host.

Now you can start and stop the Managed Server on Host B using the Administration Console running on Host C.

If you are recovering the Administration Server for a Web Tier installation, see Section 17.3.4 for information about additional actions you must take.

17.3.2 Recovering After Loss of Managed Server Host

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:

17.3.2.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 needs to be recovered to Host B.

  1. Start the Node Manager on Host B:

    java weblogic.WLST
    wls:/offline> startNodeManager()
    
  2. Start the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
    

    If the Managed Server starts, it connects to the Administration Server and updates its configuration changes. You do not need to take any further steps.

  3. If the Managed Server fails to start or if the file system is lost, take the following steps:

    1. Stop the Node Manager:

       java weblogic.WLST
      wls:/offline> stopNodeManager()
      
    2. Recover the Middleware home to Host B from the backup, if required:

      tar -xf mw_home_backup_092909.tar 
      
    3. If the Managed Server contains Oracle Portal, Oracle Reports, Oracle Forms Services, or Oracle Business Intelligence Discoverer, and the Managed Server domain directories reside outside of the Middleware home, restore the domain, in addition to the Middleware home. For example:

      cd Domain_Home
      tar -xf domain_home_backup_092909.tar 
      

      Go to Step e.

    4. 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
        
    5. 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 no-stage or external stage mode, copy the application artifacts from 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.

    6. If the Node Manager is not started, start it:

      java weblogic.WLST
      wls:/offline> startNodeManager()
      
    7. Start the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
      

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

17.3.2.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 needs to be recovered to Host C.

Important:

Recover the Middleware home to the same location as the original.

Take the following steps:

  1. Recover the MW_HOME for the Managed Server to Host C.

    tar -xf mw_home_backup_092909.tar 
    
  2. If the Managed Server contains Oracle Portal, Oracle Reports, Oracle Forms Services, or Oracle Business Intelligence Discoverer, and the Managed Server domain directories reside outside of the Middleware home, restore the domain, in addition to the Middleware home. For example:

    cd Domain_Home
    tar -xf domain_home_backup_092909.tar 
    

    Go to Step 4.

  3. If the Managed Server does not contain the components listed in Step 2, take the following steps:

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

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

  4. 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 no-stage or external stage mode, copy the application artifacts from 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.

  5. Start the Node Manager on Host C, if it is not started:

    java weblogic.WLST
    wls:/offline> startNodeManager()
    
  6. 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')
    
  7. Change the Managed Server configuration to point to the new host:

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

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

  8. Start the Managed Server. You can use the Oracle WebLogic Server Administration Console, WLST, or the following script:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
              admin_url 
    

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

  9. Update Oracle Inventory, as described in Section 17.3.4.4.

  10. Edit the targets.xml file for Fusion Middleware Control, as described in Section 17.3.4.2.

Now you can start and stop the Managed Server on Host C using the Administration Server running on Host A.

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

You use the following steps when you are restoring to the same host or a different host:

  1. Restore the Managed Server from backup:

    cd ManagedServer_Home
    tar -xf managed_server_backup_092909.tar 
    
  2. Restart the Managed Server:

    DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url 
    

17.3.3 Recovering After Loss of Component

If you lose a host that contains a component (and its Managed Server, if applicable), you can recover it to the same host or a different host, as described in the following topics:

17.3.3.1 Recovering a Java Component to the Same Host

To recover a Java component, such as Oracle SOA Suite:

  1. Recover the Managed Server, as described in Section 17.2.5.1.

However, note that some components require additional steps, which are described in subsequent sections.

17.3.3.2 Recovering a Java Component to a Different Host

To recover a Java component, such as Oracle SOA Suite:

  1. Recover the Managed Server, as described in Section 17.3.2.2.

  2. Edit the targets.xml file for Fusion Middleware Control, as described in Section 17.3.4.2.

However, note that some components require additional steps, which are described in subsequent sections.

17.3.3.3 Recovering a System Component to the Same Host

To recover a system component, such as Oracle HTTP Server, you take the following general steps. However, note that some components require additional steps.

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

  2. Recover the component-specific files from backup. Section 15.5 lists the directories and files needed for each component. For example, to recover Oracle HTTP Server files, you recover the following directories:

    ORACLE_INSTANCE/config/OHS/component_name
    ORACLE_INSTANCE/diagnostics/logs/OHS/component_name
    
  3. 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.

  4. Start all relevant processes, as described in Section 4.3.

17.3.3.4 Recovering a System Component to a Different Host

To recover a system component, such as Oracle HTTP Server, you take the following general steps. However, note that most components require additional steps, which are described in separate sections.

  1. Recover the Middleware home, as described in Section 17.2.1.

  2. Start all relevant processes. Section 4.3 explains how to start components.

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

  4. 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
     
    
  5. Edit the targets.xml file for Fusion Middleware Control, as described in Section 17.3.4.2.

Depending on the components, you may need to take additional actions. See the subsequent sections for more information.

17.3.3.5 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 17.3.2.3. Otherwise, follow the steps in this section.

To recover the Oracle SOA Suite Managed Server to the same host after loss of host:

  1. Recover the Managed Server, as described in Section 17.3.2.1.

To recover the Oracle SOA Suite Managed Server to a different host after loss of host:

  1. Before you recover, update the WSDL file to point to the new host name and port.

  2. Recover the Managed Server, as described in Section 17.3.2.2.

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

      1. In Fusion Middleware Control, navigate to the Managed Server.

      2. From the WebLogic Server menu, choose System MBean Browser.

      3. Expand Application Defined MBeans, then oracle.as.soainfra.config, then Server: server_name and then SoaInfraConfig. Select soa-infra.

      4. In the Attributes tab, click ServerURL. If the ServerURL attribute contains a value, change the host name to the new host name.

      5. Click Apply.

    • Redeploy all applications which have the WSDL files updated to the new host name.

Note:

If there is no Load Balancer configured with the environment and Oracle SOA Suite needs to be recovered to a different host, then in-flight instances that are pending a response from task flow and asynchronous responses are not recovered. Oracle recommends that you use a Load Balancer to ensure that you can recover to a different host.

If a Load Balancer is configured with the environment, follow steps in Section 17.3.2.2. Then, take the following additional steps:

  1. Log in to the Oracle WebLogic Server Administration Server.

  2. In Domain Structure, navigate to Servers. For each Managed Server, select the Protocol tab, then the HTTP tab.

  3. For Frontend Host, enter the new host name.

  4. For Frontend HTTP Port and Frontend HTTPs Port, if applicable, enter the new port number.

  5. Restart each Managed Server.

17.3.3.6 Recovering Oracle Business Activity Monitoring to a Different Host

To recover Oracle Business Activity Monitoring to a different host:

  1. Recover the Managed Server, as described in Section 17.3.2.2.

17.3.3.7 Recovering Oracle WebCenter to a Different Host

To recover Oracle WebCenter to a different host:

  1. Recover the Managed Server, as described in Section 17.3.2.2.

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

17.3.3.8.1 Recovering Oracle HTTP Server to a Different Host

To recover Oracle HTTP Server to a different host:

  1. Recover the component as described in Section 17.3.3.4.

  2. Recover Oracle Management Agent, as described in Section 17.3.4.3.

  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
    
17.3.3.8.2 Recovering Oracle Web Cache to a Different Host

To recover Oracle Web Cache to a different host:

  1. Recover the component as described in Section 17.3.3.4.

  2. Recover Oracle Management Agent, as described in Section 17.3.4.3.

  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
    

17.3.3.9 Recovering Identity Management Components to a Different Host

For most Identity Management components, you recover the Managed Server, as described in Section 17.3.2.2.

Some components require additional steps to recover the components to a different host, as described in the following topics:

17.3.3.9.1 Recovering Oracle Internet Directory to a Different Host

To recover Oracle Internet Directory to a different host:

  1. Recover the component as described in Section 17.3.3.4.

  2. On UNIX and Linux systems, before you attempt to start Oracle Internet Directory, set the following to have root permission:

    ORACLE_HOME/bin/oidldapd
    

    For example:

    chown root oidldapd
    chmod 4710 oidldapd
    
  3. Recover Oracle Management Agent, as described in Section 17.3.4.3.

  4. If the Managed Server on which Oracle Directory Services Manager is deployed is moved to different host and if SSL is enabled, you must delete the following file on the new host:

    DOMAIN_HOME/servers/wls_ods1/tmp/_WL_user/odsm_11.1.1.1.0/randomid/war/conf/odsm.cer
    

    Oracle Directory Services Manager uses this file as its key store and trust store and the password is stored in JKS. However, when Oracle Directory Services Manager is copied to another host and is started, it generates a different password than odsm.cer. If you delete the file, Oracle Directory Services Manager creates a new file when it starts.

17.3.3.9.2 Recovering Oracle Virtual Directory to a Different Host

To recover Oracle Virtual Directory to a different host:

  1. Recover the component as described in Section 17.3.3.4.

  2. Recover Oracle Management Agent, as described in Section 17.3.4.3.

17.3.3.9.3 Recovering Oracle Directory Integration Platform to a Different Host

To recover Oracle Directory Integration Platform to a different host:

  1. Recover the Managed Server, as described in Section 17.3.2.2.

  2. Before starting the Managed Server, restore the files in the following directory:

    DOMAIN_HOME/servers/wls_ods1/stage/DIP/11.1.1.1.0/
    
  3. Start the Managed Servers and Oracle instances.

  4. 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 
    
  5. 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 
    
17.3.3.9.4 Recovering Oracle Directory Services Manager to a Different Host

To recover Oracle Directory Services Manager to a different host:

  1. Recover the component as described in Section 17.3.3.4.

17.3.3.9.5 Recovering 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 will cause production delays that are unacceptable. Oracle strongly recommends that you do not change the host name of a standalone Oracle Identity Federation server.

If a load balancer is part of the environment and the host where Oracle Identity Federation is being recovered is in the list of VIPs, then no host name changes are required.

In the case of a standalone installation of Oracle Identity Federation, Oracle recommends using a new host with the same name to minimize the impact. However, if, for whatever reason, you need to use a different host name for recovering Oracle Identity Federation, then the host name needs to be updated manually for Oracle Identity Federation and remote partners.

To recover Oracle Identity Federation to a different host:

  1. Recover the Managed Server, as described in Section 17.3.2.2.

  2. Recover Oracle Management Agent, as described in Section 17.3.4.3.

  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 
    
  4. Provide the updated data to remote partners.

  5. Modify the host name using Fusion Middleware Control:

    1. In the navigation pane, expand the farm and then Identity and Access.

    2. Select the Oracle Identity Federation instance.

    3. From the Oracle Identity Federation menu, choose Administration, then Server Properties.

      The Server Properties page is displayed.

    4. For Host, replace the old host name with the new host name.

    5. For Port, replace the port number if it has changed.

    6. For SOAP Port, replace the port number if it has changed.

    7. Click Apply.

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

      DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name 
                admin_url 
      
  6. 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.

17.3.3.10 Recovering Oracle Portal, Oracle Reports, Oracle Forms Services, and Oracle Business Intelligence Discoverer to a Different Host

The following topics describe how to recover these components to a different host:

17.3.3.10.1 Recovering Oracle Portal to a Different Host

To recover Oracle Portal to a different host:

  1. Restore the Middleware home, domain directory, and the Oracle instance directory to the new host. See Section 17.3.2.2 for more information.

  2. Recover Oracle Management Agent, as described in Section 17.3.4.3.

  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 
    
  4. 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
    
  5. 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
    
  6. Copy the file from the previous step to the new host.

  7. 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
    
  8. 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
      
  9. If the published host used to access Oracle Portal is changing, take the following steps. This could happen if you have a single node install which contains both Oracle Web Cache and WLS_PORTAL, and those processes need to move to a different host. Another scenario is when you have Oracle Web Cache running on a node remotely from WLS_PORTAL, and Oracle Web Cache needs to move to a different host. In both these cases, take the following steps to update the Published Host information within Oracle Portal. (Note: If you have a load balancer or reverse proxy configuration, the steps are not needed.)

    1. Recursively delete all content from the following directory, but do not delete the directory itself:

      ORACLE_INSTANCE/portal/cache
      
    2. Log in to Fusion Middleware Control. Expand the farm and right-click Portal. Then, choose Settings, then Wire Configuration.

    3. In the Portal Midtier section, update Published Host with the new host name.

    4. In the Oracle Web Cache section, update Host with the new host name.

  10. Restart the WLS_PORTAL instance.

17.3.3.10.2 Recovering Oracle Business Intelligence Discoverer to a Different Host

To recover Oracle Business Intelligence Discoverer to a different host:

  1. Recover the Managed Server as described in Section 17.3.2.2.

  2. Recover Oracle Management Agent, as described in Section 17.3.4.3.

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

  5. 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
    
  6. Copy the file from the previous step to the new host.

  7. 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
    
17.3.3.10.3 Recovering Oracle Reports to a Different Host

To recover Oracle Reports to a different host:

  1. Recover the Managed Server as described in Section 17.3.2.2.

  2. Recover Oracle Management Agent, as described in Section 17.3.4.3.

  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 
    
  4. Edit the following files, replacing the previous host name with the new host name:

    • reports_install.properties. The file is located in:

      (UNIX) ORACLE_INSTANCE/reports
      (Windows) ORACLE_INSTANCE\reports
      

      Edit the parameters SERVER_NAME, OHS_HOST and REPORTS_MANAGED_WLS_HOST.

    • webcache.xml. This file is located in:

      (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name
      (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
      

      Replace all occurrences of the previous host name with the new host name.

    • instance.properties. The file is located in:

      (UNIX) ORACLE_INSTANCE/config/OPMN/opmn
      (Windows) ORACLE_INSTANCE\config\OPMN\opmn
      

      In the following line, replace the previous host name with the new host name if the Administration Server host name has changed.

      adminHost=host_name
      
    • reports_ohs.conf. The file is located in:

      (UNIX) ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf
      (Windows) ORACLE_INSTANCE\config\OHS\ohs_name\moduleconf
      
    • rwservlet.properties. The file is located in:

      (UNIX) MW_HOME/user_projects/domains/domain_name/servers/WLS_REPORTS/stage/reports/reports/configuration
      (Windows) MW_HOME\user_projects\domains\domain_name\servers/WLS_REPORTS\stage\reports\reports\configuration
      

      In the file, modify the <server> element to use the new host name.

  5. 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
    
  6. 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
    
  7. In the following directory, rename the subdirectory to have the new host name:

    (UNIX) ORACLE_INSTANCE/config/ReportsServer
    (Windows) ORACLE_INSTANCE\config\ReportsServer
    
  8. 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
    
  9. Copy the file from the previous step to the new host.

  10. 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
    
17.3.3.10.4 Recovering Oracle Forms Services to a Different Host

To recover Oracle Forms Services to a different host:

  1. Recover the Managed Server as described in Section 17.3.2.2.

  2. Recover Oracle Management Agent, as described in Section 17.3.4.3.

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

  5. 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>
    
  6. 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
    
  7. 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
    
  8. Copy the file from the previous step to the new host.

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

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

17.3.4.1 Recovering Fusion Middleware Control to a Different Host

To recover Fusion Middleware Control to a different host, take the following steps:

  1. Update the host name in the following file:

    MW_HOME/user_projects/domains/domain_name/servers/AdminServer/tmp/_WL_user/em/hsz5x1/META-INF/emoms.properties
    

    In the file, change the host name for the following properties:

    mas.conn.url
    oracle.sysman.emSDK.svlt.ConsoleServerHost 
    
  2. 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/ 
    

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

MW_HOME/user_projects/domains/domain_name/sysman/state/targets.xml

In the file, change the host name to the new host name for components that are recovered to a different host.

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

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

  1. 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"/>
    
  2. 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
    
  3. Start Oracle Management Agent, using the following command:

    opmnctl startproc ias-component=EMAGENT
    
  4. 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.

17.3.4.4 Updating Oracle Inventory

For many components, when you recover to a different host, as in the case of loss of host, you need to update the Oracle inventory. To do so, execute the following script:

ORACLE_HOME/oui/bin/attachHome.sh 

In addition, you must update beahomelist to edit the location of a Middleware home. Edit the following file to update the Middleware home information:

(UNIX) user_home/bea/beahomelist
(Windows) C:\bea\beahomelist

17.3.4.5 Recover the Windows Registry

When you recover any component to a different host on Windows, as in the case of loss of host, you need to recover the following Windows Registry key.

HKEY_LOCAL_MACHINE\Software\oracle

In addition, when you recover system components, such as Oracle Web Cache, you must recover the following Windows Registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

To import a key that you have previously exported, use the following command:

regedit  /I  <FileName>

For example:

regedit /I C:\oracleregistry.reg 

You can also use the Registry Editor to import the key. See the Registry Editor Help for more information.

17.3.5 Recovering After Loss of Host for a Database

If the host that contained your database is lost, you can recover it using RMAN. You can recover the database at the desired granularity, either a full recovery or a tablespace recovery.

For example:

rman> restore database;
rman> recover database;

For best results, recover the database to the most current state, using point-in-time recovery (if the database is configured in Archive Log Mode.) This ensures that the latest data is recovered. Note the following:

  • See Appendix D for the schemas used by each component.

  • For Oracle BPEL Process Manager, point-in-time recovery ensures that the latest process definitions and in-flight instances are restored. However, this may result in reexecution of the process steps. Oracle recommends that you strive for idempotent Oracle BPEL Process Manager processes. If the system contains processes that are not idempotent, you must clean them up from the dehydration store before starting Oracle Fusion Middleware. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for more information.

For detailed steps, see the Oracle Database Backup and Recovery User's Guide, which is available at:

http://www.oracle.com/technology/documentation/database.html