10 Back Up and Recover Oracle Fusion Applications

A backup configuration must be created before performing a backup or restoring using Cloud Control. A backup configuration contains settings for database and file backups. Create the configuration using the Backup Configurations page. Multiple backup configurations can be created, using different settings. Then, the configurations can be used in subsequent backup and restore operations.

To create a new backup configuration using Cloud Control, perform the following steps:

For more information on the database backup settings in these pages, refer to the Oracle Cloud Oracle Database Backup and Recovery Reference Guide in the Oracle Database documentation library.

For information on the Oracle Secure Backup settings in these pages, refer to the obtool backup command options in the Oracle Secure Backup Reference Guide in the Oracle Database documentation library.

By default, Cloud Control backs up the core directories and databases that comprise an Oracle Fusion Applications installation. It can include additional files and databases in the backup. It is also possible to execute user-defined pre-backup and post-backup scripts.

Because Cloud Control uses Oracle Secure Backup to perform the backups, all backups are done to tape, which is the media supported by Oracle Secure Backup.

To back up an Oracle Fusion Applications environment using Cloud Control:

1. Ensure that the prerequisites have been met, as described in Prerequisites for Using Cloud Control to Back Up or Restore the Environment.

2. From the Targets menu, choose Fusion Applications.

   The Fusion Applications target home page is displayed.

3. Click the Fusion Instance that needs to be backed up.

   The Fusion Instance home page is displayed.

4. From the Fusion Instance menu, choose Control, then Schedule Backup.

   The Schedule Backup wizard is displayed, with the first step, Backup Scope, as shown in the following figure:

   Figure 10-5 Schedule Backup: Backup Scope Page

   
   

   
   Description of "Figure 10-5 Schedule Backup: Backup Scope Page"

   
   

5. In the Backup Scope step:

   1. Select the Oracle Secure Backup domain to use for the backup.

   2. Select the scope of the backup among the following list:

      • Software and Configuration Directories:

        Backs up all directories in the Oracle Fusion Applications installation, including the Applications Home directory (the root of the Oracle Fusion Applications installation) and any other directories (for example, Domain homes) that may be installed in a different location. Cloud Control will determine the distinct file systems that comprise the installation across all hosts in the environment, and will include the top-level directories needed to constitute a complete backup.

      • Configuration Directories:

        Backs up only the configuration-related directories, including the Domain home of the Administrative Server for each Oracle WebLogic Server domain. The following options can be selected:

        • All: Back up all configuration directories.

        • Custom: Narrow the scope of the backup by selecting specific Oracle Fusion Applications components. (On the next step, it is possible to select which of their associated directories to include in the backup.)

   Click Next.

6. In the Directories step, specify the Oracle Fusion Applications directories to include in the backup. By default, the directories that correspond to the backup scope choice (made on the Backup Scope page) are included. If the Custom option is chosen, the directories from the list can be removed. (The list of directories that correspond to the backup scope are automatically determined by Cloud Control. It is not possible to individually select or remove subdirectories from the backup.) Click Add to specify additional files or directories to include in the backup from outside the core Oracle Fusion Applications installation. Any directories or files that reside on a discovered Oracle Secure Backup client host can be included.

   Click Next.

7. In the Databases step, click Add to specify additional databases to add to the backup. By default, the Oracle Fusion Applications repository database is included in the backup.

   Click Next.

8. In the Configuration step, select the backup configuration to use for the backup. (See the Configure Cloud Control Backups for details on creating a backup configuration.)

   Click Next.

9. In the Options step:

   1. Select the backup type:

      • Full: A full backup of the databases and files will be performed. If the database portion of the backup is to be used as the base of an incremental backup strategy, select the Use as the base of an incremental backup strategy option.

      • Incremental: An incremental backup of the databases and files will be performed.

   2. Select the backup mode:

      • Online: The databases will remain running during the backup. Manually quiesce or shut down the Oracle Fusion Applications processes before submitting the backup, as this is not done automatically by Cloud Control.

      • Offline: The databases will be shutdown automatically before the backup. Manually shut down the Oracle Fusion Applications processes before submitting the backup, as this is not done automatically by Cloud Control.

      See Start and Stop an Oracle Fusion Applications Environment for information about stopping Oracle Fusion Applications processes. Alternatively, scripts can be specified to shutdown the processes in Step 10.

   Click Next.

10. In the Scripts step, specify the host name and path of scripts to be run before and after the backup. Post-backup scripts can be specified to run upon success or failure of the backup. The scripts can be run on any discovered host. The scripts must be executable files that exist on the specified hosts. Any type of executable file can be specified.

    Click Next.

11. In the Credentials step, if one or more databases is included in the backup, specify the database and host credentials that will be used to back up the databases.

    Click Next.

12. In the Schedule step, specify the procedure name, description, and scheduling information.

    Click Next.

13. In the Review step, verify all the input specified in the wizard. Make changes as needed and click Submit. A Cloud Control deployment procedure is submitted to perform the backup, and a confirmation page appears with a link to the deployment procedure status page.

For a description of the backup types, see the Oracle Database Backup and Recovery User's Guide in the Oracle database documentation library.

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

An Oracle instance must be registered with the domain. To recover an Oracle instance home that was deregistered from the domain:

To recover Oracle Fusion Customer Relationship Management:

For a complete case study for recovering Oracle Fusion Customer Relationship Management in different recovery scenarios, see A Case Study: Recover Oracle Fusion Customer Relationship Management.

To recover Oracle Fusion Procurement:

The Oracle Fusion Procurement is dependent on CUPS software, a portable printing layer for UNIX systems.

To recover Oracle HTTP Server, the Oracle instance that contains Oracle HTTP Server must be recovered, as described in Recover an Oracle Instance Home.

To recover Oracle WebCenter Content:

The database and the shared file system should be restored at the same time. If this cannot be done, the IDCAnalyse utility can be used to determine if there are any inconsistencies between the database and the shared file system. If there are, a manual recovery can be performed using IDCAnalyse.

To recover Oracle Enterprise Scheduler:

To recover Oracle Enterprise Crawl and Search Framework:

To recover Oracle E-Mail and Web Marketing:

The following topics describe how to recover Oracle BI EE:

• Recover Oracle BI Enterprise Edition in a Non-Clustered Environment

• Recover Oracle BI Enterprise Edition in a Clustered Environment

When recovering Oracle BI EE, the Oracle BI Presentation Catalog and the Oracle BI EE repository (RPD) must be restored to the same point in time, by using the same backup set.

To recover Oracle Business Intelligence Publisher:

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.

To recover Oracle Real-Time Decisions:

If backup artifacts are restored from a different time, the analytic models miss a period of learning, but their intelligence is unaffected.

To recover Oracle Essbase:

To recover Oracle Hyperion Calculation Manager:

To recover Oracle Hyperion Financial Reporting:

To recover Oracle Hyperion Smart View:

In this scenario, 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:

1. Recover the file system. For example, recover the domain containing the Administration Server, as described in Recover an Oracle WebLogic Server Domain.

2. Attempt to start the Administration Server, as described in Start and Stop an Oracle Fusion Applications Environment.

   If the Administration Server starts, any further steps need to be taken.

3. 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, such as the Administration Server and Managed Servers, as described in Start and Stop an Oracle Fusion Applications Environment.

   2. Recover the domain directory from the backup file:

      cd DOMAIN_HOME
      (UNIX) tar -xf domain_backup_030214.tar 
      

      This restores the Administration Server as well as the Managed Servers in the domain.

   3. Start the Administration Server and Managed Servers, as described in Start and Stop an Oracle Fusion Applications Environment.

   4. Start the Node Manager:

      ORACLE_COMMON_HOME/common/bin/wlst.sh
      wls:/offline> startNodeManager()
      

In this scenario, the Administration Server is running on Host A and the Managed Server is running on Host B. Host A has failed for some reason and the Administration Server must be moved to Host C.

This scenario assumes that the shared location containing the binary files and the Administration Server configuration is intact. If it is not, follow the steps in Recover a Middleware Home through Recover an Oracle Instance Home.

To recover the Administration Server to a different host:

1. Because a new host has been included, mount the file system to the new host, Host C.

2. If the Administration Server has a listen address, create a new machine with the new host name, as described in Create a New Machine for the New Host Name.

3. When moving.jks files to another host, warnings may be received from the host name verification. Those SSL certificates can be regenerated in the new host to set up SSL and configure a custom host name verifier.

   The .jks files are located in the following directory:

   (UNIX) APPLICATIONS_BASE/fusionapps/wlserver_10.3/server/lib 
   

4. Start the Node Manager on Host C if it was configured on the original host:

   ORACLE_COMMON_HOME/common/bin/wlst.sh
   wls:/offline> startNodeManager()
   

5. Start the Administration Server, as described in Start and Stop an Oracle Fusion Applications Environment.

6. If the Managed Servers are on the same failed host as the Administration Server, restore the Managed Servers, as described in Recover a Managed Server to a Different Host.

7. Start the Managed Servers, as described in Start and Stop an Oracle Fusion Applications Environment.

8. 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 the application files available to the new Administration Server by copying them from backups or by using a shared disk. The 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.

9. If the environment contains Oracle HTTP Server, modify the FusionVirtualHost_x.conf file, as described in Modify the FusionVirtualHost_x.conf File.

10. Update Oracle Inventory, as described in Update Oracle Inventory.

11. Edit the targets.xml file for Fusion Middleware Control, as described in Change the Host Name in the targets.xml File for Fusion Middleware Control.

12. Oracle Management Service, which is part of Fusion Middleware Control, is on the original host and is recovered to the new host when the Administration Server is restored. Oracle Management Agent connects to Oracle Management Service to monitor certain components. If the 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, the following steps must be taken 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. These steps must be taken 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.

       For example, on UNIX:

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

       For example, on Windows:

       cd ORACLE_INSTANCE\EMAGENT\emagent_dir
       emctl stop agent
       emctl start agent
       emctl status agent
       

       The status command shows the REPOSITORY_URL pointing to the new host.

For information about configuring a custom host name verifier, see section Configure a Custom Host Name Verifier in the Oracle WebLogic Server Administration Console Help.

For information about regenerating SSL certificates, see section Configuring SSL in Administering Security for Oracle WebLogic Server 12c (12.2.1) in the Oracle Fusion Middleware Documentation library.

For descriptions of different ways to restart Managed Servers, depending on how they were configured, see section Restarting a Failed Administration Server in the Administering Server Startup and Shutdown for Oracle WebLogic Server n the Oracle Fusion Middleware d=Documentation library.

In this scenario, 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.

1. Start the Node Manager on Host B:

   ORACLE_COMMON_HOME/common/bin/wlst.sh
   wls:/offline> startNodeManager()
   

2. Start the Managed Server, as described in Start and Stop an Oracle Fusion Applications Environment.

   If the Managed Server starts, it connects to the Administration Server and updates its configuration changes. Any further steps need to be taken.

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

   1. Stop the Node Manager:

      ORACLE_COMMON_HOME/common/bin/wlst.sh
      wls:/offline> stopNodeManager()
      

   2. Recover the Middleware home to Host B from the backup file, if required:

      cd MW_HOME
      (UNIX) tar -xf mw_home_backup_030214.tar 
      

   3. Create a domain template jar file for the Administration Server running in Host A, using the pack utility.

      For example, on UNIX:

      pack.sh -domain=APPLICATIONS_CONFIG/instance/domains/domain_name
         -template=/scratch/temp.jar -template_name=domain1
         -template_author=myname -log=/scratch/logs/my.log -managed=true
      

      Specifying the -managed=true option packs up only the Managed Servers. If the entire domain is packed, omit this option.

   4. Unpack the domain template jar file in Host B, using the unpack utility.

      For example, on UNIX:

      unpack.sh -template=/scratch/temp.jar
         -domain=APPLICATIONS_CONFIG/instance/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.

      • For applications that are deployed in nostage or external-stage mode, copy the application artifacts from the Administration Server host directory.

      • For applications that are deployed in stage mode, the Administration Server copies the application bits to the staged directories on the Managed Server hosts.

      If the Node Manager is not started, start it:

      ORACLE_COMMON_HOME/common/bin/wlst.sh
      wls:/offline> startNodeManager()
      

   6. Start the Managed Server, as described in Start and Stop an Oracle Fusion Applications Environment.

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

In this scenario, the Administration Server is running on Host A and the Managed Server is running on Host B. Host B failed for some reason and the Managed Server must be recovered to Host C.

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

To recover a Managed Server to a different host:

1. If the Managed Server configuration files are local to the host (that is, they are not on a shared file system):

   1. Recover the Middleware home for the Managed Server to Host C.

      cd MW_HOME
      (UNIX) tar -xf mw_home_backup_030214.tar 
      

      Note that when the Middleware home is restored, all of the domains are being restored because they are on a shared file system.

   2. Create a domain template jar file from the Administration Server running in Host A, using the pack utility.

      For example, on UNIX:

      pack.sh -domain=APPLICATIONS_CONFIG/instance/domains/domain_name
         -template=/scratch/temp.jar -template_name=domain1
         -template_author=myname -log=/scratch/logs/my.log -managed=true
      

      Specifying the -managed=true option packs up only the Managed Servers. If the entire domain is packed, omit this option.

   3. Unpack the domain template jar file on Host C, using the unpack utility.

      For example, on UNIX:

      unpack.sh -template=/scratch/temp.jar
         -domain=APPLICATIONS_CONFIG/instance/domains/domain_name
         -log=/scratch/logs/new.log -log_priority=info
      

      When recovering to a different domain home, use the -app_dir switch in the unpack command.

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

   • For applications that are deployed in nostage or external-stage mode, copy the application artifacts from the Administration Server host directory.

   • For applications that are deployed in stage mode, the Administration Server copies the application bits to the staged directories on the Managed Server hosts.

3. If the Managed Server is not co-located with the Administration Server, take the following steps. (These steps are not needed if the Managed Server is co-located with the Administration Server.)

   1. Edit the nodemanager.domains file, specifying the domain names and domain directories. Use the following format:

      domain_name=domain_directory
      

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

      ORACLE_COMMON_HOME/common/bin/wlst.sh
      wls:/offline> startNodeManager()
      

   3. 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','host:port')
      nmEnroll('APPLICATIONS_CONFIG/instance/domains/domain_name',
        'MW_HOME/wlserver_n/common/nodemanager/instance_name')
      

   4. Change the Managed Server configuration to point to the new host:

      • In the WebLogic Server Administration Console, create a machine, which is a logical representation of the computer that hosts one or more WebLogic Servers, and point it to the new host. (From the Home page, select Machines. Then, click New.) Follow the directions in the Administration Console help.

        If the listen address is identified by using an IP address, the host name verification must be disabled on the Administration Servers that access Node Manager. For more information, see section Using Host Name Verification in Administering Security for Oracle WebLogic Server 12c (12.2.1).

      • 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 the server is assigned.)

        Change Listen Address to the new host. (If the listen address was set to blank, it does not need to be changed.)

      These steps only need to be taken once for all Managed Servers on the same host.

4. When moving .jks files to another host, warnings may be received from the host name verification. Those SSL certificates can be regenerated in the new host to set up SSL and configure a custom host name verifier. See section Configure a Custom Host Name Verifier in the Oracle WebLogic Server Administration Console Help. Also, see section Configuring SSL in Administering Security for Oracle WebLogic Server 12c (12.2.1).

   The .jks files are located in the following directory:

   (UNIX) APPLICATIONS_BASE/fusionapps/wlserver_10.3/server/lib 
   

5. Start the Managed Server, as described in Start and Stop an Oracle Fusion Applications Environment.

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

6. If the environment contains Oracle HTTP Server, modify the FusionVirtualHost_x.conf file, as described in Modify the FusionVirtualHost_x.conf File.

7. Edit the targets.xml file for Fusion Middleware Control, as described in Change the Host Name in the targets.xml File for Fusion Middleware Control.

Now the Managed Server can be started and stopped on Host C using the Administration Server running on Host A.

When recovering a component to a different host, the targets.xml file for Fusion Middleware Control must be updated. The file is located at:

(UNIX) APPLICATIONS_CONFIG/instance/domains/hostname/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. The following shows an example of the targets.xml file:

<Targets>
<Target TYPE="oracle_ias_farm" NAME="Farm_CRMDomain" DISPLAY_NAME="Farm_CRMDomain">
     <Property NAME="MachineName" VALUE="example.domain.com"/>
     <Property NAME="Port" VALUE="13001"/>
     <Property NAME="isLocal" VALUE="true"/>
     <Property NAME="Protocol" VALUE="t3"/>
     <Property NAME="serviceURL" VALUE="service:jmx:t3://example.domain.com:13001/jndi/weblogic.management.mbeanservers.domainruntime"/>
     <Property NAME="WebLogicHome" VALUE="/scratch//appsbase/fusionapps/wlserver_10.3"/>
      <Property NAME="DomainHome" VALUE="/scratch//appsbase/instance/domains/example.domain.com/CRMDomain"/>
</Target>

When an Administration Server or a Managed Server is recovered to a different host and the environment includes Oracle HTTP Server, the FusionVirtualHost_x.conf file must be modified on the new host. There is a separate file for each domain, for example FusionVirtualHost_fin.conf. The files are located in:

(UNIX) APPLICATIONS_CONFIG/instance/CommonDomain_webtier/config/OHS/ohs_name/moduleconf/FusionVirtualHost_x.conf

Modify all of the instances of the host name and clusters (elements such as WebLogicHost and WebLogicCluster) entries in that file. For example:

<Location /console>
    SetHandler weblogic-handler
    WebLogicHost Admin_Host
    WeblogicPort Admin_Port
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
 .
 .
 .
<Location /soa-infra>
   SetHandler weblogic-handler
   WebLogicCluster SOAHOST1:8001,*SOAHOST2*:*8001*
   WLProxySSL ON
   WLProxySSLPassThrough ON
</Location> 

If the Administration Server has a listen address, a new machine must be created with the new host name and set the listen address, before starting the Administration Server. A machine is a logical representation of the computer that hosts one or more WebLogic Servers.

To create a new machine:

For many components, when recovering to a different host, as in the case of loss of host, the Oracle Inventory must be updated on UNIX. To do so, execute the following script:

ORACLE_COMMON_HOME/oui/bin/attachHome.sh 

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

(UNIX) user_home/bea/beahomelist

If a host that contains Oracle Fusion Supply Chain Management is lost, it can be recovered to the same host or a different host.

To recover Oracle Fusion Supply Chain Management to the same host, recover the Managed Server to which the application is deployed, as described in Recover After Loss of Managed Server Host.

To recover Oracle Fusion Supply Chain Management to a different host:

If a host that contains Oracle Fusion Procurement is lost, it can be recovered to the same host or a different host.

To recover Oracle Fusion Procurement to the same host, recover the Managed Server to which the application is deployed, as described in Recover After Loss of Managed Server Host.

To recover Oracle Fusion Procurement to a different host:

To recover Oracle HTTP Server to the same host, recover the Oracle instance, as described in Recover an Oracle Instance Home.

To recover Oracle HTTP Server to a different host:

To recover Oracle WebCenter Content to a different host:

The database and the shared file system should be restored at the same time. If this cannot be done, the IDCAnalyse utility can be used to determine if there are any inconsistencies between the database and the shared file system. If there are, a manual recovery can be performed using IDCAnalyse.

To recover Oracle Enterprise Crawl and Search Framework to a different host, follow the procedure in Recover Oracle Enterprise Crawl and Search Framework.

To recover Oracle E-Mail and Web Marketing, follow the procedure in Recover Oracle E-Mail and Web Marketing.

To recover after loss of host, the entire Middleware home, a domain, a server, an Oracle home, or an Oracle instance, must be recovered depending on the extent of the failure.

However, if the failed node contained Oracle Essbase and was clustered, secondary instances of Oracle Essbase Agent must be configured so that they are distributed for high availability. For more information, see Configuring and Validating Oracle Essbase Clustering in the Oracle Fusion Applications Installation Guide.

To recover Oracle Business Intelligence Publisher to a different host:

1. Recover the Managed Server containing the Oracle Business Intelligence Publisher component, as described in Recover After Loss of Managed Server Host.

2. Restore the database containing the Oracle Business Intelligence Publisher schemas, if necessary. See Recover the Databases After Loss of Host.

3. Modify the server value for Oracle BI Presentation Services:

   1. Open the BI Publisher application at http://hostname:port/xmlpserver and log in.

   2. Click Administration, then Integration, then Oracle BI Presentation Services.

   3. Change Server to the new host name.

   4. Click Apply.

4. To transform Oracle BI Publisher to work in a Cold Failover Cluster environment, the BI Scheduler 's JMS configuration must be changed:

   1. In the BI Publisher application, click Administration.

   2. In the System Administration section, click Scheduler Configuration.

   3. Change Weblogic JNDI URL to the new host URL. For example, t3://hostname:port.

   4. Click Apply.

5. If a Cold Failover Cluster is being used, configure the Managed Server to listen on the virtual IP address. See section Transforming Oracle WebLogic Managed Servers in the High Availability Guide. Then restart the Managed Server using the Administration Console or the WLST command line.

6. In BI Publisher, data sources that refer to this BI Enterprise Edition instance should change or be created (if new using the new virtual host). To change the data sources:

   1. In the BI Publisher application:

   2. Click JDBC Connection under Data Sources.

   3. Edit any data source for BI Enterprise Edition for this instance to reflect the values for the new host.

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.

To recover Oracle Real-Time Decisions to a different host:

Note that if backup artifacts are restored from different time, the analytic models miss a period of learning, but their intelligence is unaffected.

To recover Oracle Hyperion Calculation Manager after loss of host, follow the procedure in Recover Oracle Hyperion Calculation Manager.

If the database must be restored, restore the database and import Calculation Manager rules and rule sets from the exported file.

In Calculation Manager, select File, and then Import.

If a host that contains Oracle Hyperion Financial Reporting is lost, it can be recovered to the same host or a different host. To recover Oracle Hyperion Financial Reporting, recover the Oracle home, as described in Recover an Oracle Home and the Oracle instance, as described in Recover an Oracle Instance Home.

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

Epmsys_registry updateproperty financial_reporting_product/@host new_host
Epmsys_registry updateproperty financial_reporting_product/logical_web_app/@host new_host
Epmsys_registry updateproperty financial_reporting_product/logical_web_app/financial_reporting_web_app@host new_host