Skip Headers
Oracle® Fusion Middleware Disaster Recovery Guide
11g Release 1 (11.1.1)

Part Number E15250-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Recommendations for Oracle Fusion Middleware Components

This chapter describes the disaster protection requirements for Oracle Fusion Middleware components in different Oracle product suites and also provides recommendations for synchronizing these components. As mentioned previously, use storage replication to synchronize middle tier content, and use Oracle Data Guard to synchronize data in Oracle database repositories or custom application databases included in your Oracle Fusion Middleware Disaster Recovery topology.

This chapter includes the following sections:

Common Artifacts Across Oracle Product Suites

Certain artifacts like Oracle Inventory, the beahomelist file, the oratab file and oraInst.loc file are common across all Oracle product deployments. These artifacts change very rarely and need not be a part of the regular storage replication and synchronization activity. Oracle recommends placing Oracle Inventory, the beahomelist file, the oratab file, and the oraInst.loc file on the local disk of the machines. These artifacts should be manually updated upon creation, as well as upon applying patch updates. If required by your environment, these artifacts can also be on shared storage. For information about how to manage Oracle Inventory, see Appendix A.

2.1 Recommendations for Oracle WebLogic Server

Oracle WebLogic Server is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server. The Oracle WebLogic Server infrastructure supports the deployment of many types of distributed applications, and is an ideal foundation for building applications based on service-oriented architectures (SOA).

Common Artifacts and Considerations for Oracle WebLogic Server

The following artifacts and considerations apply to all the WebLogic Server components, along with the component-specific recommendations.

Artifacts on the File System

MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binary files.

Domain home: The domain home contains the configuration data and the applications for the WebLogic domain.

Network Artifacts

Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

If your environment requires whole server migration to be configured, then use the virtual host name as the listen address of the Managed Servers that are configured for whole server migration. To avoid manually updating the listen address after a Disaster Recovery operation, ensure that the host name can be resolved on both the primary and standby sites.

The load balancer virtual hosts used for accessing the WebLogic Server applications should be configured on both the production and standby sites.

The rest of this section describes Disaster Recovery recommendations for the following Oracle WebLogic Server components:

2.1.1 Recommendations for Oracle WebLogic Server Java Message Service (JMS) and Transaction Logs (T-Logs)

This section describes various Oracle WebLogic Server JMS and T-Log artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

File-based persistent stores: The file store location for the JMS and T-Log when using a file-based persistent store.

Artifacts in the Database

The schema containing the JMS messages, when using database-based persistent stores.The schema containing Logging Last Resource (LLR) transaction log records for WebLogic applications that leverage the JDBC LLR option.

When automatic whole server migration is configured, the required leasing table is in the database.

Special Considerations

  • Messages are lost if they were enqueued after the system restore point time but never processed. Message duplicates are generated for messages enqueued before the restore point time, but dequeued and acknowledged or committed (processed) after this time.

  • If the persistent store is a custom store that is dedicated to JMS use, then you can delete the entire store.

  • Restoring different parts of the system to different points in time can lead to inconsistent data. This can occur when the message store, transaction log, or application database are synchronized differently. For example, a message may reference a database row that does not exist, or the reverse. This may delete unprocessed messages in addition to duplicate messages.

  • If the store is not dedicated to JMS use, then use the Oracle WebLogic Server JMS message management administrative tooling. This tooling can perform import, export, move, and delete operations from the Administration Console, MBeans, and WebLogic Scripting Tools (WLST).

  • When applications use both queues and topics, ensure that you manipulate both the queue and topic subscriptions.

Synchronization Recommendations

  • If JMS data is critical, then synchronize transaction log data and JMS data in real time using synchronous replication. Using synchronous replication may have performance implications.

  • If data consistency between tiers is important, then ensure that the database and application tiers are replicated at the same time. This helps ensure that the different tiers recover to the same exact point in time.

  • Use Oracle Data Guard to replicate the primary site and standby site when using database-based persistent stores.

  • When using a storage device that does not support block-level snapshot capabilities, shut down the JMS server to create a consistent backup. This ensures that the persistence store is not being written to while the copy operation is being performed. In a clustered environment, shut down one server at a time, back it up, and restart it. You also can create a script to perform these operations using WLST.

Recovery Recommendations

Recover the database schemas containing the persistent store, to the most recent point in time, the Administration Server, and the Managed Servers in the WebLogic Server domain.

Also, use the following recovery recommendations to avoid duplicate messages.

Avoiding Duplicate Messages

Perform the following procedure before recovery to filter messages in the JMS queue after persistent-store recovery, to avoid processing duplicate messages:

Note:

Do not drain and discard messages without first being certain that the messages contain no data that must be preserved. The recovered messages may include unprocessed messages with important application data, in addition to duplicate messages that have already been processed.

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

  2. Before recovery, configure JMS server to pause Production, Insertion, and Consumption operations at Startup to ensure that no new messages are produced or inserted into the destination or consumed from the destination before you drain stale messages. To do this:

    1. Expand Services, then Messaging, and then JMS Servers.

    2. On the Summary of JMS Servers page, click the JMS server that you want to configure for message pausing.

    3. On the Configuration: General page, click Advanced to define the message pausing options. Select Insertion Paused At Startup, Production Paused At Startup, and Consumption Paused At Startup.

    4. Click Save.

    5. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

Use the following procedure after recovery:

  1. After recovering the persistent store, start the Managed Servers.

  2. Drain the stale messages from JMS destinations by following these steps:

    1. Expand Services, then Messaging, and then JMS Modules.

    2. Select a JMS module, and then select a destination.

    3. Select Monitoring, and then click Show Messages.

    4. Click Delete All.

Resume operations by following these steps:

  1. Expand Services, then Messaging, and then JMS Servers.

  2. On the Summary of JMS Servers page, click the JMS server that you want to configure for message pausing.

  3. On the Configuration: General page, click Advanced. Select Insertion Paused At Startup, Production Paused At Startup, and Consumption Paused At Startup.

  4. Click Save.

  5. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

2.1.2 Recommendations for Oracle Platform Security Services

This section describes various Oracle Platform Security Services artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Not applicable because Oracle Platform Security Services does not have any database dependencies.

Synchronization Recommendations

You must manually synchronize the application tier with the standby site after making configuration changes and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.

Recovery Recommendations

Recover the Administration Server and the Managed Servers in the WebLogic Server domain.

2.2 Recommendations for Oracle ADF

Oracle ADF is an end-to-end application framework that builds on Java Platform, Enterprise Edition (Java EE) standards and open-source technologies to simplify and accelerate implementing service-oriented applications. Oracle ADF is suitable for enterprise developers who want to create applications that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces.

This section describes various Oracle ADF artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binary files.

Oracle Common Home: This is Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Domain home: The domain home contains the configuration data and the applications for the Oracle ADF domain.

Custom Applications Directory: This is the stage location for various customer applications and their related libraries.

Network Artifacts

Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

The load balancer virtual hosts used for accessing the applications should be configured on both the production and standby sites.

Artifacts in the Database

Oracle ADF applications may use the Metadata Services (MDS) repository to persist the application state and configuration data. This data depends on how the application is coded.

Most Oracle ADF applications do not use the MDS repository to store application data, but instead use a separate data store (usually a database) to store application data.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying composites, and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that the you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Servers running the Oracle ADF or Oracle WebCenter applications.

2.3 Recommendations for Oracle WebCenter Portal

Oracle WebCenter Portal combines the standards-based, declarative development of Java Server Faces (JSF), the flexibility and power of portals, and a set of integrated Web 2.0 services.

Common Artifacts and Considerations for Oracle WebCenter Portal

The following artifacts and considerations apply to all the Oracle WebCenter Portal products along with the product-specific considerations.

Artifacts on the File System

MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home containing the Oracle WebCenter Portal binary files.

Oracle Common Home: This is Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Domain home: The domain home contains the configuration data for the Oracle WebCenter Portal domain.

Artifacts in the Database

The Oracle WebCenter Portal metadata stores data for some of the Oracle WebCenter Portal services and is part of Oracle WebCenter Portal databases. The MDS repository stores WebCenter metadata and configuration information.

Network Artifacts

Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

The load balancer virtual hosts required for accessing the Oracle WebCenter Portal products should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for the Oracle database containing the Oracle WebCenter Portal schema and the metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.

Recovery Recommendations

The database containing the Oracle WebCenter Portal schemas must be recovered to the most recent point in time, along with the Managed Servers running the Oracle WebCenter Portal applications.

The rest of this section describes Disaster Recovery recommendations for Oracle WebCenter Portal:

2.3.1 Recommendations for Oracle WebCenter Portal: Spaces

Oracle WebCenter Portal: Spaces offers a single, integrated, web-based environment for social networking, communication, collaboration, and personal productivity through a robust set of services and applications.

This section describes various Spaces artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The WebCenter Portal schema stores data for some of the Oracle WebCenter Portal services. The MDS repository stores WebCenter Portal metadata and configuration information.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for the Oracle database containing the WebCenter Portal schema and the metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database containing the WebCenter Portal schemas and MDS repository must be recovered to the most recent point in time, along with the Oracle WebCenter Portal domain.

2.3.2 Recommendations for Oracle WebCenter Portal's Portlet Producers

Oracle WebCenter Portal supports deployment and execution of both standards-based portlets (JSR 168, WSRP 1.0 and 2.0), and traditional Oracle (Portlet Developer Kit) PDK-Java based portlets. Oracle WebCenter Portal provides several ready-to-use producers, such as OmniPortlet, Web Clipping, Rich Text Portlet, and WSRP Tools.

This section describes various Portlets Producer artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The PORTLET schema stores user customizations and is part of the Oracle WebCenter Portal schemas, and MDS repository stores portlet metadata and configuration information.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for the Oracle database containing the PORTLET schema and the metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database containing the PORTLET schema and MDS repository must be recovered to the most recent point in time, along with the Oracle WebCenter Portal domain.

2.3.3 Recommendations for Oracle WebCenter Portal's Discussion Server

Oracle WebCenter Portal's Discussion Server provides the ability to integrate discussion forums and announcements into your applications.

This section describes various Discussion Server artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The Discussion Server schema stores metadata and data and is part of the Oracle WebCenter Portal schemas.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for the Oracle database containing the Discussion Server schema and the metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database containing the Discussion Server schema must be recovered to the most recent point in time, along with the Oracle WebCenter Portal domain.

2.3.4 Recommendations for Oracle WebCenter Content Server

Oracle WebCenter Content Server provides the ability to integrate wikis and blogs into WebCenter Portal applications. It also supports features that enable application users to create their own wikis and blogs.

This section describes various Oracle WebCenter Wiki and Blog Server artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The Oracle Content Server (OCSERVER) schema stores metadata and data and is part of the Oracle WebCenter Portal schemas.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for the Oracle database containing the OCSERVER schema.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database containing the OCSERVER schema must be recovered to the most recent point in time, along with the Oracle WebCenter Portal domain.

2.3.5 Recommendations for Oracle Content Server

Oracle Content Server is the foundation for a variety of Oracle content management products. It provides a flexible, secure, centralized, web-based repository that manages all phases of the content life cycle: from creation and approval to publishing, searching, expiration, and archival or disposition.

This section describes various Oracle Content Server artifacts and provides recommendations for disaster recovery.

Note:

The Disaster Recovery solution for Oracle Fusion Middleware 11gR1 supports Oracle Content Server 10.1.3.4.1. The Disaster Recovery solution for Oracle Fusion Middleware release 11.1.1.2.0 supports Oracle Content Server 10.1.3.5.1.

Artifacts on the File System

Oracle Home: The Oracle home contains the Oracle Content Server binaries and configuration data.

Oracle_Common_home: The Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Config directory: This is user defined location for the content server's configuration data.

There are three critical directories that are required for the proper functioning of Oracle Content Server. By default, when Oracle Content Server is installed as part of Oracle WebCenter, these directories are located under the Oracle home directory:

  • instance directory: ORACLE_HOME/ucm

  • primary renditions directory: ORACLE_HOME/ucm/vault

  • web viewable renditions directory: ORACLE_HOME/ucm/weblayout

If Oracle Content Server is installed outside of Oracle WebCenter, the administrator can use the intradoc.cfg file to specify the locations of the primary renditions directory and the web viewable renditions directory.

Artifacts in the Database

All content, indexing services, users, and workflows are stored in the Content Server schema.

Network Artifacts

The load balancer virtual hosts for the content server must be available on the both the primary and standby sites.

Synchronization Recommendations

The web and application tier must be manually synchronized with the standby site after making configuration changes, and applying patches.

When using an Oracle database, Oracle Data Guard should be configured to synchronize Oracle Content Server repositories on the production and standby sites. Note that Oracle Content Server does not support Oracle Data Guard logical standby databases, so use Oracle Data Guard physical standby databases, instead. Please refer to your vendor documentation when using other supported databases.

It is a best practice recommendation that when the application tier synchronization is initiated on the storage, the standby database is also recovered to be up to the same point in time. This can happen by virtue of Oracle Data Guard being configured in Managed Recovery mode for the database or by explicit user initiation.

Recovery Recommendations

The content server database must be recovered to the most recent point in time, along with the Oracle home for Oracle Universal Content Management (the intradoc directory), and the Oracle Content Server Config directory, instance directory, primary renditions directory, and web viewable renditions directory.

2.3.6 Recommendations for Analytics Collector of Oracle WebCenter Portal

Analytics Collector of Oracle WebCenter Portal allows portal managers and business owners to track and analyze portal usage.

This section describes the Oracle WebCenter Portal's Analytics data that must be backed up and restored.

Configuration Files

Configuration information is stored in the Analytics schema, ACTIVITIES.

Database Repository Dependencies

ACTIVITIES and MDS schemas

Backup Recommendations

Back up the Oracle home, the domain home, and the database containing the ACTIVITIES and MDS schemas.

Recovery Recommendations

Recover the Oracle home and the domain home.

Recover the database to the most recent point in time, if needed.

2.3.7 Recommendations for Oracle WebCenter Portal Activity Graph Engine

Oracle WebCenter Portal Activity is a WebCenter Portal service that provides suggestions of people, items, and spaces that users may be interested in interacting with.The engine used by the Activity Graph service to provide a central repository for actions that are collected by enterprise applications.

The data stored in the activity graph is analyzed to calculate ranks for nodes, predict new actions, and make recommendations.

This section describes the Oracle WebCenter Portal Activity Graph data that must be backed up and restored.

Configuration Files

Configuration information is stored in the ACTIVITIES schema.

Database Repository Dependencies

ACTIVITIES schema

Backup Recommendations

Back up the Oracle home, the domain home, and the database containing the ACTIVITIES schema.

Recovery Recommendations

Recover the Oracle home and the domain home.

Recover the database to the most recent point in time, if needed.

2.4 Recommendations for Oracle SOA Suite

Oracle SOA Suite is a middleware component of Oracle Fusion Middleware. Oracle SOA Suite provides a complete set of service infrastructure components for designing, deploying, and managing SOA composite applications. Oracle SOA Suite enables services to be created, managed, and orchestrated into SOA composite applications that combine multiple technology component. SOA composite applications consist of:

Note:

In Oracle SOA Suite release 11g R1 (11.1.1.1), the soa-infra and service-engine configuration files were stored in local or shared storage files as part of the domain configuration.

Starting in Oracle SOA Suite 11gR1 (11.1.1.2), those files were moved into the metadata repository. Thus, soa-infra and service-engine configuration changes are now immediately propagated across a cluster.

In Oracle SOA Suite 11g R1 (11.1.1.3), you can deploy Oracle Business Process Management (BPM) Suite on top of an Oracle SOA Suite installation.

The Disaster Recovery recommendations for Oracle SOA Suite assume that you are using Oracle SOA Suite 11g R1 (11.1.1.2).

Oracle SOA Suite artifacts are stored on the local or shared file system as well as in the metadata repositories. Composite artifacts are stored in the metadata repository, and binary files and domain-related configuration files are stored on a local or shared file system.

Common Artifacts and Considerations for All Oracle SOA Suite Components

The following artifacts and considerations apply to all the Oracle SOA Suite components, along with the component-specific considerations.

Artifacts on the File System

MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home containing the Oracle SOA Suite binary files.

Oracle Common Home: This is Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Domain home: The domain home contains the configuration data and SOA composites for the SOA domain.

Network Artifacts

Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation. See the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for instructions for updating an IP address to a virtual host name.

The load balancer virtual hosts required for accessing the Oracle SOA Suite components should be configured on both the production and standby sites.

Artifacts in the Database

Oracle SOA Suite schemas, Service Infrastructure and Service Engine configurations, and composite definitions are stored in the Oracle SOA Suite database and metadata repository.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration, deploying composites, and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.

Recovery Recommendations

The database must be recovered to the most recent point in time to ensure that the latest composite definitions and in-flight instances are restored.

In-flight instances require the matching composite definition to continue processing. For this reason, the metadata repository (where composite definitions are stored) and Oracle SOA Suite database (where the process state is maintained) must be recovered to the same point in time.

In redeployed composites, a database recovery ensures consistency between the dehydrated in-flight processes and their corresponding definition because the process definition is stored in database repository where dehydrated instances are stored.

This section describes Disaster Recovery recommendations for the following Oracle SOA Suite components:

2.4.1 Recommendations for Oracle SOA Service Infrastructure

Oracle SOA Service Infrastructure is a Java EE application that provides the foundation services for running Oracle SOA Suite. This Java EE application is a runtime engine that is automatically deployed when Oracle SOA Suite is installed. You deploy composites (the basic artifacts in a Service Component Architecture) to the Oracle SOA Infrastructure and it provides the required services for the composites to run. Oracle SOA Infrastructure provides deployment, wiring, and thread management services for the composites. These services sustain the lifecycle and run-time operations of the composite.

This section describes various Oracle SOA Service Infrastructure artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Composite definition and configuration files are stored in the MDS repository. The composite instance state persistence is stored in the Oracle SOA Service Infrastructure database.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration, deploying composites, and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time to ensure that the latest composite definitions and in-flight instances are restored.

2.4.2 Recommendations for Oracle BPEL Process Manager

The Oracle BPEL Process engine is the service engine running in Oracle SOA Service Infrastructure that allows the execution of BPEL processes. A BPEL process provides the standard for assembling a set of discrete services into an end-to-end process flow, and developing synchronous and asynchronous services into end-to-end BPEL process flows. It provides process orchestration and storage of long-running, asynchronous processes.

This section describes various Oracle BPEL Process Manager artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Process definition and configuration files are stored in the MDS repository. The BPEL process state persistence is stored in the Oracle SOA Suite database.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making domain-related configuration changes and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time to ensure that the latest process definitions and in-flight instances are restored. Idempotent Oracle BPEL Process Manager processes are recommended, because no cleanup is required after performing a Disaster Recovery operation. If non-idempotent processes Oracle BPEL Process Manager processes are used, then processes must be cleaned up from the dehydration store after a Disaster Recovery operation is performed, especially when a process is in flight.

2.4.3 Recommendations for Oracle Mediator

Oracle Mediator is a service engine within the Oracle SOA Service Infrastructure. Oracle Mediator provides the framework to mediate between various providers and consumers of services and events. The Mediator service engine runs in place with the SOA Service Infrastructure Java EE application.

This section describes various Oracle Mediator artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The Mediator service engine stores messages in the database for asynchronous routing for parallel routing rules (note that sequential routing rules do not persist their messages into the database as part of the execution). The Mediator component instance state and audit details are also stored in the database.

The metadata repository stores the Mediator component definition as part of the composite definition.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Administration Server and the Managed Server running the soa-infra application.

2.4.4 Recommendations for Oracle Human Workflow

Oracle Human Workflow is a service engine running in the Oracle SOA Service Infrastructure that allows the execution of interactive human-driven processes. A human workflow provides the human interaction support such as approve, reject, and reassign actions within a process or outside of any process. The Human Workflow service consists of several services that handle various aspects of human interaction with a business process.

This section describes various Oracle Human Workflow artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Human workflow instance data and other worklist data such as vacation rules, group rules, flex field mappings, view definitions are stored in the database.

The metadata repository is used to store shared human workflow service definitions and schemas used by SOA composites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application. The Oracle Human Workflow engine uses Oracle User Messaging Service to send and receive notifications. See Section 2.4.7 for details about Oracle User Messaging Service.

2.4.5 Recommendations for Oracle B2B

Oracle B2B connects SOA composite applications to external services, applications, and technologies. Oracle B2B offers a multiprotocol gateway that supports industry-recognized business-to-business (B2B) standards. Oracle B2B extends Oracle SOA Suite with business protocol standards, such as electronic data interchange (EDI), ebXML, HL7, and RosettaNet. Oracle B2B is implemented as a binding component within the SOA Service Infrastructure.

This section describes various Oracle B2B artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

JMS Store: The volume containing the file-based JMS persistent store. Table 2-1 shows the JMS queues and topics used internally by Oracle B2B.

Table 2-1 JMS Queues and Topics Used by Oracle B2B

JMS Artifact Name Type JNDI Name

dist_B2BEventQueue_auto

Distributed queue

jms/b2b/B2BEventQueue

dist_B2B_IN_QUEUE_auto

Distributed queue

jms/b2b/B2B_IN_QUEUE

dist_B2B_OUT_QUEUE_auto

Distributed queue

jms/b2b/B2B_OUT_QUEUE

dist_B2BBroadcastTopic_auto

Distributed topic

jms/b2b/B2BBroadcastTopic


Artifacts in the Database

Oracle B2B message and message state persistence are stored in the Oracle SOA Suite database along with the partners, documents, and channels definitions. The metadata repository is used for storing Oracle B2B metadata.

Special Considerations

The external FTP servers and email servers should be available on the standby site if these adapters are used.

Synchronization Recommendations

For information about Oracle B2B JMS queue synchronization and recovery, see Section 2.1.1.

The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application. Oracle B2B stores state information within JMS queues and the SOA runtime database, so recovering the database and the Managed Server will ensure that the application runs normally.

2.4.6 Recommendations for Oracle Web Services Manager

Oracle Web Services Manager (Oracle WSM) provides a policy framework to manage and secure web services consistently across your organization. It provides capabilities to build, enforce, execute and monitor web services policies including security, Web Services Reliable Messaging (WSRM), Message Transmission Optimization Mechanism (MTOM) and addressing policies. Oracle Web Services Manager consists of the Policy Manager and the Agent.

The Policy Manager reads and writes security and management policies, including predefined and custom policies from the MDS repository. The Policy Manager is a stateless Java EE application. It exposes its capabilities through stateless session beans. Although the Policy Manager does not cache any data, the underlying MDS infrastructure does.

The Agent is responsible for policy enforcement, execution, gathering of runtime statistics. The agent is available on all Oracle Fusion Middleware Managed Servers and is configured on the same server as the application it protects. The agent consists of two pieces: the Policy Access Point (PAP) and the Policy Interceptor.

This section describes various Oracle Web Services Manager artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The MDS repository is used for storing the policies.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application. All policies are stored in the MDS repository, so recovering the database and the Managed Server will ensure that the application runs normally.

2.4.7 Recommendations for Oracle User Messaging Service

Oracle User Messaging Service (UMS) enables two-way communications between users and deployed applications. It has support for a variety of channels, such as email, IM, SMS, and text-to-voice messages. Oracle User Messaging Service is integrated with Oracle Fusion Middleware components such as Oracle BPEL Process Manager, Oracle Human Workflow, Oracle Business Activity Monitoring (BAM) and Oracle WebCenter Portal. It is typically deployed, along with Oracle SOA Service Infrastructure. Oracle User Messaging Service is made up of UMS Server, UMS Drivers, and UMS Client applications.

This section describes various Oracle User Messaging Service artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

JMS Store: The volume containing the file-based JMS persistent store. Table 2-2 shows the JMS resources used internally by Oracle User Messaging Service.

Table 2-2 JMS Resources Used by Oracle User Messaging Service

JMS Artifact Name Type JNDI Name

OraSDPMAppDefRcvQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMAppDefRcvQ1

OraSDPMDriverDefSndQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMDriverDefSndQ1

OraSDPMEngineCmdQ_auto

Distributed queue

OraSDPM/Queues/OraSDPMEngineCmdQ

OraSDPMEngineRcvQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMEngineRcvQ1

OraSDPMEngineSndQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMEngineSndQ1

OraSDPMWSRcvQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMWSRcvQ1


Artifacts in the Database

Oracle User Messaging Service depends on an external database repository to maintain the message and configuration state.

Special Considerations

Oracle User Messaging Service uses JMS to deliver messages among messaging applications. By default it is configured to use a file-based persistent JMS store; therefore, it depends on the storage device where those files are located.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying additional Oracle User Messaging Service drivers, and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the usermessagingserver application. Oracle User Messaging Service maintains the message and configuration state in an external database repository along with persisting messages in JMS queues, so recovering the database and the Managed Server ensures that the application functions without any issues. For recommendations on synchronizing JMS data, refer to the "Synchronization Recommendations" subsection in Section 2.1.1.

2.4.8 Recommendations for Oracle Java EE Connector Architecture (JCA) Adapters

Oracle JCA Adapters are JCA binding components that allow the Service Infrastructure to communicate to endpoints using different protocols. Oracle JCA Adapters are deployed as a JCA resource (RAR) and are not part of the Oracle SOA Service Infrastructure.

The broad categories of Oracle JCA Adapters are:

  • Oracle Technology Adapters

  • Legacy Adapters

  • Packaged-Application Adapters

  • Oracle Adapter for Oracle Applications

See the Oracle Fusion Middleware User's Guide for Technology Adapters for additional information about the types of Oracle JCA Adapters.

This section describes various Oracle JCA Adapter artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

Certain adapters by their nature use local or shared-storage files, for example:

  • JMS adapters utilizing WebLogic JMS with file-based persistence store: The persistence store must be synchronized with the standby site to resume processing after failover.

  • Inbound and outbound files from either File or FTP adapters: The relevant files must be synchronized with the standby site to resume processing after failover.

Adapter configuration is maintained in the weblogic-ra.xml deployment descriptor for the ear JCA resource (RAR). The location of each weblogic-ra.xml file is determined by the administrator when the file is created, and must be replicated to the standby site.

Artifacts in the Database

Adapter artifacts are generated at design time as part of the composite project. These artifacts are stored with the rest of the composite definition in the metadata repository.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration (that is, adapter configuration changes) and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the JCA Adapters and the Administration Server.

2.4.9 Recommendations for Oracle Business Activity Monitoring

Oracle Business Activity Monitoring (BAM) provides the tools for monitoring business services and processes in the enterprise. It allows correlation of market indicators to the actual business process and to changing business processes quickly or taking corrective actions if the business environment changes. Oracle BAM provides the necessary tools and runtime services for creating dashboards that display real-time data inflow and define rules to send alerts under specified conditions.

This section describes various Oracle BAM artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Oracle BAM data and report metadata is stored in the Oracle BAM database that contains Oracle BAM schemas.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making domain-related configuration changes and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database containing the Oracle BAM schemas and the metadata repository.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running Oracle BAM.

2.4.10 Recommendations for Oracle Business Process Management

The Oracle Business Process Management (BPM) Suite provides an integrated environment for developing, administering, and using business applications centered around business processes. It provides a seamless integration of all stages of the application development life cycle from design-time and implementation to runtime and application management.

The Oracle BPM Suite is layered on the Oracle SOA Suite and shares many of the same product components, including:

  • Oracle Business Rules

  • Oracle Human Workflow

  • Oracle adapter framework for integration

  • SOA Composite Architecture

This section describes various Oracle BPM artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

BPM JMS Persistent Store (BPMJMSFileStore_auto): The file-based JMS persistent store. The persistence store must be synchronized with the standby site to resume processing after failover.

Artifacts in the Database

Process definition, deployed applications, and configuration files are stored in the Oracle Metadata Services (MDS) repository. Oracle BPM also uses a separate MDS partition to share projects and project templates between process analysts and process developers.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.

Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, the standby database is also updated to the same point in time. This is recommended if a snapshot Standby database is used.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application.

2.5 Recommendations for Oracle Identity Management

The Oracle Identity Management products enable you to configure and manage the identities of users, devices, and services across diverse servers, to delegate administration of these identities, and to provide end users with self-service privileges. These products also enable you to configure single sign-on across applications and to process users' credentials to ensure that only users with valid credentials can log in to and access online resources.

Common Artifacts and Considerations for All Oracle Identity Management Components

The following artifacts and considerations apply to all the Oracle Identity Management components, along with the component-specific considerations.

Artifacts on the File System

MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home containing the Oracle Identity Management binary files.

Oracle Common Home: This is Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Domain home: The domain home contains the Administration Server and Managed Server configuration data and Oracle Identity Management applications for the domain.

Oracle instance: The Oracle instance contains the configuration data for non-J2EE Identity Management applications like Oracle Internet Directory and Oracle Virtual Directory. It also has Oracle Process Manager and Notification Server (OPMN) configuration and Enterprise Manager Agent configuration data.

Artifacts in the Database

The Identity Management schemas are in the Identity Management database.

Network Artifacts

Oracle recommends using the host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

The load balancer virtual hosts used to access the Oracle Identity Management components must be configured on both the production and standby sites.

Synchronization Recommendations

The directory tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.

Recovery Recommendations

The database containing the Oracle Identity Management schemas must be recovered to the most recent point in time, along with the Identity Management component in question.

The rest of this section describes Disaster Recovery recommendations for the following Oracle Identity Management components:

2.5.1 Recommendations for Oracle Internet Directory

Oracle Internet Directory is an LDAP Version 3-enabled service that enables fast retrieval and centralized management of information about dispersed users, network configuration, and other resources.

This section describes various Oracle Internet Directory artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The ODS and ODSSM schemas used by Oracle Internet Directory are part of the Identity Management database.

Special Considerations

The load balancer virtual hosts required for the Oracle Internet Directory should be configured on both the production and standby sites.

Synchronization Recommendations

The directory tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Oracle Internet Directory must be recovered with the ODS and ODSSM schemas to the most recent point in time.

2.5.2 Recommendations for Oracle Virtual Directory

Oracle Virtual Directory is an LDAP Version 3-enabled service that provides an abstracted view of one or more enterprise data sources. Oracle Virtual Directory consolidates multiple data sources into a single directory view, enabling you to integrate LDAP-aware applications with diverse directory server data stores.

This section describes various Oracle Virtual Directory artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Oracle Virtual Directory does not have any database dependencies.

Special Considerations

The load balancer virtual hosts required for Oracle Virtual Directory should be configured on both the production and standby sites.

Synchronization Recommendations

The directory tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Recovery Recommendations

Recover the Oracle Virtual Directory instance.

2.5.3 Recommendations for Oracle Directory Integration Platform

Oracle Directory Integration Platform is a Java 2 Platform, Enterprise Edition (J2EE) application that enables you to synchronize data between other directories or databases and Oracle Internet Directory. Oracle Directory Integration Platform includes services and interfaces that allow you to deploy synchronization solutions with other enterprise repositories. It can also be used to provide Oracle Internet Directory interoperability with third-party meta-directory solutions.

This section describes various Oracle Directory Integration Platform artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The ODS and ODSSM schemas are part of the Identity Management database. Quartz jobs are in the ODSSM schema.

Synchronization Recommendations

The application tier and data tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Recovery Recommendations

Oracle Internet Directory must be recovered with the ODS and ODSSM schemas to the most recent point in time, along with the Managed Server running the Oracle Directory Integration Platform application, and the associated Oracle Internet Directory instances.

2.5.4 Recommendations for Oracle Identity Federation

Oracle Identity Federation enables companies to provide services and share identities across their respective security domains, while providing protection from unauthorized access.

This section describes various Oracle Identity Federation artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Oracle Identity Federation uses the OIF schema, which is part of the Identity Management database. When an RDBMS user store, configuration store, Federation store, message data store, or session store is configured for Oracle Identity Federation, an external database contains those stores.

Special Considerations

Load balancer virtual hosts for Oracle Identity Federation should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The databases containing the Oracle Identity Federation schemas and the data stores must be recovered to the most recent point in time, along with the Managed Server running the Oracle Identity Federation application.

2.5.5 Recommendations for Oracle Directory Services Manager

Oracle Directory Services Manager is a unified graphical user interface (GUI) for Oracle Virtual Directory and Oracle Internet Directory. Oracle Directory Services Manager simplifies the administration and configuration of Oracle Virtual Directory and Oracle Internet Directory by allowing you to use web-based forms and templates.

This section describes various Oracle Directory Services Manager artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The Oracle Directory Services Manager application does not have any database dependencies.

Special Considerations

Load balancer virtual hosts for Oracle Directory Services Manager should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the Managed Servers running the Oracle Directory Services Manager application, along with the Administration Server.

2.5.6 Recommendations for Oracle Access Manager

Oracle Access Manager provides a full range of identity administration and security functions that include Web single sign-on, user self-service and self-registration, sophisticated workflow functionality, auditing and access reporting, policy management, dynamic group management, and delegated administration.

This section describes various Oracle Access Manager artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Oracle Access Manager uses the OAM, IAU (Audit Services) schemas, and the ODS schemas (for Oracle Internet Directory) that are part of the Oracle Identity Management database.

LDAP Store

Oracle Access Manager stores configuration and user information in the Oracle Internet Directory.

Special Considerations

The Oracle Access Manager Console is deployed to the Administration Server in the domain. Load balancer virtual hosts for Oracle Access Manager should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the Managed Server running the Oracle Access Manager application, the Administration Server, and the associated Oracle Internet Directory instances. The OAM, IAU, and the ODS schemas must be recovered to the most recent point in time.

2.5.7 Recommendations for Oracle Adaptive Access Manager

Oracle Adaptive Access Manager is the Oracle Identity Management solution for Web-access real-time fraud detection and multifactor online authentication security for the enterprise. Oracle Adaptive Access Manager is designed to support complex, heterogeneous enterprise environments.

This section describes various Oracle Adaptive Access Manager artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Oracle Adaptive Access Manager uses the OAAM, OAAM PARTN, MDS, IAU (Audit Services), and the ODS (Oracle Internet Directory) schemas that are part of the Oracle Identity Management database.

For Oracle Adaptive Access Manager with partition schema support, select the Identity Management - Oracle Adaptive Access Manager (Partition Supp...) schema. By default, the AS Common Schemas - Metadata Services schema is also selected.

LDAP Store

Oracle Adaptive Access Manager stores configuration and user information in the Oracle Internet Directory.

Special Considerations

Load balancer virtual hosts for Oracle Adaptive Access Manager should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the managed server running the Oracle Adaptive Access Manager application, and the associated Oracle Internet Directory instances. The OAAM, OAAM_PARTN, MDS, IAU, and the ODS schemas must be recovered to the most recent point in time.

2.5.8 Recommendations for Oracle Identity Manager

Oracle Identity Manager is a user provisioning and administration solution that automates the process of adding, updating, and deleting user accounts from applications and directories; and improves regulatory compliance by providing granular reports that identify which users have access to which applications. Oracle Identity Manager is available as a standalone product or as part of Oracle Identity and Access Management Suite.

Because Oracle Identity Manager uses Oracle SOA for workflow, you must also follow the Oracle SOA disaster recovery recommendations. For more information, see Section 2.4.

This section describes various Oracle Identity Manager artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

JMS Store: The volume containing the file-based JMS persistent store.

Artifacts in the Database

Oracle Identity Manager uses OIM, SOAINFRA, ORASPDM, and MDS schemas, which are part of the Oracle Identity Management database.

LDAP Store

Oracle Identity Manager does not have any dependency on an external LDAP store when used in the standalone mode. Oracle Identity Manager synchronizes users with an external LDAP store when LDAP Sync is enabled or when Oracle Identity Manager is integrated with Oracle Access Manager or Oracle Identity Federation.

Special Considerations

Load balancer virtual hosts for Oracle Identity Manager should be configured on both the production and standby sites.

The Oracle Identity Management and SOA Managed Servers are configured to listen on floating IP addresses; this is required for Server Migration. Ensure that the floating IP addresses are configured with the same virtual names on both the production and the standby sites.

The connectors in Oracle Identity Manager are file-based. They are used to provision or reconcile records from different enterprise applications. Ensure that the connectors are available for Oracle Identity Manager and the applications.

Oracle Identity Management is also dependent on the JMS persistence store. For more information, see Section 2.1.1.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making configuration changes and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

For JMS persistence store, see Section 2.1.1.

Recovery Recommendations

Recover the managed server running the Oracle Identity Manager application, and the associated Oracle Internet Directory instances. The OIM, SOAINFRA, ORASPDM, and MDS schemas must be recovered to the most recent point in time. Oracle Identity Management is dependent on the ODS schema when LDAP sync is enabled, in such cases ensure to recover the ODS to the most recent point in time as well

2.5.9 Recommendations for Oracle Identity Navigator

Oracle Identity Navigator is an administrative portal designed to act as an application console for all of the Oracle Identity Management products. It does not replace the individual product consoles. You access Oracle Identity Navigator through a browser and use it to access consoles for Oracle Access Manager, Oracle Adaptive Access Manager, Oracle Identity Manager, Directory Services (ODSM), and other Oracle Identity Management services. You configure Oracle Identity Navigator to connect to these consoles either by specifying the URLs directly, or by employing the product discovery feature. The Oracle Identity Management Navigator simplifies the management of all of the Oracle Identity consoles from one site.

This section describes various Oracle Identity Navigator artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Oracle Identity Navigator does not use any schema.

LDAP Store

Oracle Identity Navigator stores configuration information in an LDAP store.

Special Considerations

Load balancer virtual hosts for Oracle Identity Navigator should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the administration server running the Oracle Identity Navigator application.

2.6 Recommendations for Oracle Portal, Forms, Reports, and Discoverer

This section describes artifacts and Disaster Recovery recommendations for the following suite of Oracle components:

Common Artifacts and Considerations for Oracle Portal, Forms, Reports, and Discoverer

The artifacts and considerations in this section are common to Oracle Portal, Oracle Forms, Oracle Reports, and Discoverer.

Artifacts on the File System

MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home containing the binary files for Oracle Portal, Oracle Forms, Oracle Reports, and Discoverer.

Oracle Common Home: This is the Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Domain home: The domain home contains the Administration Server and Managed Server configuration data and the Oracle Portal, Oracle Forms, Oracle Reports, and Discoverer applications for the domain.

Oracle instance: The Oracle instance contains the configuration data for the Oracle Portal, Oracle Forms, Oracle Reports, and Discoverer components. It also contains configuration data for OPMN and the EMAgent.

Artifacts in the Database

The database metadata repositories contains the Oracle Portal, Oracle Reports, and Discoverer component schemas and any user-configured databases.

There is no Oracle Forms component schema in the database metadata repository (RCU), but there will likely be customer data in user-configured databases that are being accessed through Oracle Forms.

Network Artifacts

Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

The load balancer virtual hosts used to access Oracle Portal, Oracle Forms, Oracle Reports, and Discoverer must be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.

Recovery Recommendations

The databases containing the Oracle Portal, Oracle Reports, and Discoverer component schemas must be recovered to the most recent point in time. The Managed Servers running the Oracle Portal, Oracle Forms, Oracle Reports, and Discoverer component applications and the Oracle instances must be restored.

The rest of this section describes Disaster Recovery recommendations for the following components:

2.6.1 Recommendations for Oracle Portal

Oracle Portal offers a complete portal framework for building, deploying, and managing portals that are tightly integrated with Oracle Fusion Middleware. Oracle Portal provides a rich, declarative environment for creating a portal web interface and accessing dynamic data with an extensible framework for Java EE-based enterprise application access.

This section describes various Oracle Portal artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The Portal, Portal_Demo, Portal_App, Portal_Public, and Portal_Approval schemas are part of the Oracle Portal metadata repository.

Special Considerations

Load balancer virtual hosts for accessing the portal should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The databases containing the Oracle Portal schemas must be recovered to the most recent point in time. The Managed Server running the Oracle Portal application and the Oracle instance must be restored.

2.6.2 Recommendations for Oracle Forms

Oracle Forms is Oracle's long-established technology to design and build enterprise applications quickly and efficiently.

This section describes artifacts that are unique to Oracle Forms and provides recommendations for disaster recovery.

Artifacts in the Database

The artifacts in the database include any user-configured databases for the Oracle Forms applications.

Special Considerations

Load balancer virtual hosts for accessing Oracle Forms should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for the user-configured application databases.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The Managed Server running the Oracle Forms application and the Oracle instance must be restored. Any user-configured databases must be recovered to the most recent point in time.

2.6.3 Recommendations for Oracle Reports

Oracle Reports is the reports publishing component of Oracle Fusion Middleware. It is an enterprise reporting service for producing high-quality production reports that dynamically retrieve, format, and distribute any data, in any format, anywhere. You can use Oracle Reports to publish in both web-based and non-web-based environments.

This section describes various Oracle Reports artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

Reports home: This is a user-defined location that contains the Report definition files. This may also be under the Oracle instance or Oracle home.

Artifacts in the Database

Oracle Reports can be configured to store job-related information, such as scheduled job data, past job data, or job status data in a database. This is a user-configured database.

Special Considerations

Load balancer virtual hosts for accessing Oracle Reports should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

If the Oracle Reports Server is configured to store configuration or user information in other components like Oracle Portal and Oracle Internet Directory, ensure that you synchronize these components between the production and standby sites as well.

Oracle Data Guard should be configured for Oracle Reports databases.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The Managed Server running the Oracle Reports application and the Oracle instance must be restored. Any user-configured databases must be recovered to the most recent point in time. Also recover any associated Oracle Portal and Oracle Internet Directory instances.

2.6.4 Recommendations for Oracle Business Intelligence Discoverer

Oracle Business Intelligence Discoverer (Discoverer) is a business intelligence tool for analyzing data. It is a key component of Oracle Fusion Middleware. Discoverer provides an integrated business intelligence solution that comprises intuitive ad hoc query, reporting, analysis, and web publishing functionality. These tools enable nontechnical users to gain immediate access to information from data marts, data warehouses, multidimensional (OLAP) data sources, and online transaction processing systems. Discoverer integrates seamlessly with Oracle Portal and Oracle WebCenter Portal, enabling rapid deployment of Discoverer workbooks and worksheets to Web portals.

This section describes various Discoverer artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The DISCOVERER and DISCOVERER_PS schemas are part of the Discoverer metadata repository.

Special Considerations

Load balancer virtual hosts for accessing Discoverer should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database containing the Discoverer schemas must be restored to the most recent point in time.

The Managed Server running the Discoverer application and the Oracle instance must be restored.

2.7 Recommendations for Oracle Web Tier Components

The web tier of a J2EE application server is responsible for interacting with the end users, such as web browsers primarily in the form of HTTP requests and responses. It is the outermost tier in the HTTP stack, closest to the end user.

This section describes Disaster Recovery recommendations for the following Oracle Web Tier components:

2.7.1 Recommendations for Oracle HTTP Server

Oracle HTTP Server is the web server component for Oracle Fusion Middleware. It provides a listener for Oracle WebLogic Server and the framework for hosting static pages, dynamic pages, and applications over the Web.

Oracle HTTP Server is based on the Apache 2.2.x infrastructure, and includes modules developed specifically by Oracle. The features of single sign-on, clustered deployment, and high availability enhance the operation of Oracle HTTP Server.

This section describes various Oracle HTTP Server artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

Oracle home: The Oracle home consists of the Oracle HTTP Server binary files.

Oracle Common home: This is the Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Oracle instance: The Oracle instance contains the configuration and diagnostic data for Oracle HTTP Server. It also contains configuration data for OPMN and the Enterprise Manager Agent.

Static content volume: This volume contains the static HTML content served by the Oracle HTTP Server instance. This volume is optional; Oracle Fusion Middleware can operate normally without it.

Artifacts in the Database

Oracle HTTP Server does not have any database dependencies.

Special Considerations

These are the special considerations for Oracle HTTP Server:

  • Load balancer virtual hosts for accessing Oracle HTTP Server should be configured on both the production and standby sites.

  • This manual directs you to install Oracle Fusion Middleware 11g instances (including Oracle HTTP Server instances) on shared storage. When an Oracle instance for Oracle HTTP Server 11g is configured on shared storage (for example, NAS storage, NFS storage, or SAN storage) that does not provide reliable file locking, Oracle HTTP Server may experience performance problems.

    Some shared storage systems do not provide the reliable file locking that Oracle HTTP Server 11g requires. In these cases, the LockFile directive in the httpd.conf file must be changed to point to a local file system.

    See the Apache documentation at the following URL for more information about the LockFile directive:

    http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex
    

    If any Oracle HTTP Server 11g instance is installed on shared storage and is experiencing performance problems, then perform these steps for the Oracle HTTP Server instance to point the LockFile directive to a local file system:

    1. By default, the LockFile directive is in the following format, configured under both the prefork and worker MPM configuration blocks in the httpd.conf file:

      ${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME/http_lock
      
    2. Edit the $ORACLE_INSTANCE/config/OHS/ohs_name/httpd.conf file using the appropriate method.

    3. Change the LockFile directive under the correct MPM configuration to point to a local file system:

      LockFile /local_disk/path/http_lock
      
    4. Restart Oracle HTTP Server.

    After performing these steps, verify that the http_lock file exists in the directory specified by the LockFile directive.

Synchronization Recommendations

The Oracle HTTP Server instance must be manually synchronized with the standby site after making changes in the configuration.

Recovery Recommendations

Restore the Oracle HTTP Server instance and related configuration files on the standby site.

2.7.2 Recommendations for Oracle Web Cache

Oracle Web Cache is a content-aware server accelerator, or a reverse proxy, for the Web tier. It improves the performance, scalability, and availability of web sites that run on any web server or application server, such as Oracle HTTP Server and Oracle WebLogic Server.

Oracle Web Cache is the primary caching mechanism provided with Oracle Fusion Middleware. Caching improves the performance, scalability, and availability of web sites that run on Oracle Fusion Middleware by storing frequently accessed URLs in memory.

This section describes various Oracle Web Cache artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

Oracle home: The Oracle directory home consists of the Oracle Web Cache binary files.

Oracle Common home: This is the Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Oracle instance: The Oracle instance contains the configuration data for Oracle Web Cache. It also contains configuration data for OPMN and the Enterprise Manager Agent.

Artifacts in the Database

Oracle Web Cache does not have any database dependencies.

Special Considerations

Load balancer virtual hosts for accessing Oracle Web Cache should be configured on both the production and standby sites.

Synchronization Recommendations

The Oracle Web Cache instance must be manually synchronized with the standby site after making changes in the configuration.

Recovery Recommendations

Restore the Oracle Web Cache instance and related configuration files on the standby site.

2.8 Recommendations for Oracle WebCenter Content

Oracle WebCenter Content is an integrated suite of products designed for managing content. This Oracle WebCenter Content platform enables you to leverage industry-leading document management, web content management, digital asset management, and records management functionality to build your business applications. Building a strategic enterprise content management infrastructure for content and applications helps you to reduce costs; easily share content across the enterprise; minimize risk; automate expensive, time-intensive, and manual processes; and consolidate multiple web sites onto a single platform.

Common Artifacts and Considerations for all Oracle WebCenter Content Components

The following artifacts and considerations apply to all the Oracle WebCenter Content components along with the component-specific considerations.

Artifacts on the File System

MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home containing the Oracle WebCenter Content binary files.

Oracle Common home: The Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Domain home: The domain home contains the Administration Server and Managed Server configuration data and Oracle WebCenter Content applications for the domain.

Oracle instance: The Oracle instance contains the configuration data for non-J2EE Oracle WebCenter Content applications like OPMN configuration and Enterprise Manager Agent configuration data.

Artifacts in the Database

The Oracle WebCenter Content schemas are in the Oracle WebCenter Content database.

Network Artifacts

Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

The load balancer virtual hosts used to access the Oracle WebCenter Content components must be configured on both the production and standby sites.

Synchronization Recommendations

The directory tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.

Recovery Recommendations

The database containing the Oracle WebCenter Content schemas must be recovered to the most recent point in time, along with the Identity Management component in question.

The rest of this section describes Disaster Recovery recommendations for the following Oracle WebCenter Content components:

2.8.1 Recommendations for Oracle WebCenter Content

Oracle WebCenter Content provides a unified application for several different kinds of content management.

Oracle WebCenter Content is an enterprise content management platform that enables you to leverage document management, Web content management, digital asset management, and records retention functionality to build and complement your business applications. Building a strategic enterprise content management infrastructure for content and applications helps you to reduce costs; easily share content across the enterprise; minimize risk; automate expensive, time-intensive and manual processes; and consolidate multiple web sites onto a single platform for centralized management. Through user-friendly interfaces, roles-based authentication, and security models, Oracle WebCenter Content empowers users throughout the enterprise to view, collaborate on or retire content, ensuring that all accessible distributed or published information is secure, accurate, and up-to-date.

This section describes various Oracle WebCenter Content artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

Oracle Secure Files or file-based persistent stores.

Artifacts in the Database

The OCS schema is part of the Oracle WebCenter Content database.

Special Considerations

The load balancer virtual hosts required for the Oracle WebCenter Content should be configured on both the production and standby sites.

Synchronization Recommendations

The directory tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

You must synchronize file-based persistent stores on the standby site.

Recovery Recommendations

Oracle WebCenter Content must be recovered with the OCS and MDS schemas to the most recent point in time.

2.8.2 Recommendations for Oracle WebCenter Content: Inbound Refinery

Oracle WebCenter Content: Inbound Refinery is a conversion server that manages file conversions for electronic assets such as documents, digital images, and video. In addition to conversion, Oracle WebCenter Content: Inbound Refinery provides thumbnail functionality for documents and images, storyboarding for video, and the ability to extract and use EXIF data from digital images and XMP data from electronic files generated from programs such as Adobe Photoshop and Adobe Illustrator. You can use Oracle WebCenter Content: Inbound Refinery to convert content items stored in Oracle Content Server.

This section describes various Oracle WebCenter Content: Inbound Refinery artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Oracle WebCenter Content: Inbound Refinery does not have any database dependencies.

Special Considerations

The load balancer virtual hosts required for Oracle WebCenter Content: Inbound Refinery should be configured on both the production and standby sites.

Synchronization Recommendations

The directory tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Recovery Recommendations

Recover the Oracle WebCenter Content: Inbound Refinery instance.

2.8.3 Recommendations for Oracle WebCenter Content: Imaging

Oracle WebCenter Content: Imaging provides organizations with a scalable solution upon which to develop process-oriented imaging applications and image-enablement solutions for enterprise applications. Oracle WebCenter Content: Imaging enables image capture via Oracle WebCenter Capture and Oracle WebCenter Distributed Capture, annotation and markup of images, workflow support for routing and approval automation, and support for high-volume applications for millions of items. With Oracle WebCenter Content: Imaging, organizations can quickly integrate their content and processes directly with Oracle enterprise applications, such as Oracle E-Business Suite, PeopleSoft Enterprise, and JD Edwards EnterpriseOne. Users benefit by having a single source for all transaction-based content, eliminating the need for reentering the content.

This section describes various Oracle WebCenter Content: Imaging artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

The IPM Input Agent pulls files from a common file share. This IPM file share must be synchronized with the standby site.

Artifacts in the Database

The IPM schema is part of the Oracle WebCenter Content: Imaging database. Oracle WebCenter Content: Imaging also requires OCS schema to use Oracle WebCenter Content as the Oracle WebCenter Content: Imaging repository.

Synchronization Recommendations

The application tier and data tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

The IPMJMSServerStore, which is the JMS store, must be synchronized with a file-based persistent store. For more information, see Section 2.1.1.

Recovery Recommendations

Oracle WebCenter Content: Imaging must be recovered with the IPM schema to the most recent point in time, along with the Managed Server running the Oracle WebCenter Content: Imaging application, and the associated instances.

2.8.4 Recommendations for Oracle WebCenter Content: Information Rights

Oracle WebCenter Content: Information Rights distributes rights management between centralized servers and desktop agents.

Oracle WebCenter Content: Information Rights enables documents or emails to be automatically or manually sealed at any stage in their life cycle, using sealing tools integrated into the Microsoft Windows desktop, authoring applications, email clients, and content management and collaborative repositories. Sealing wraps documents and emails within a layer of strong encryption and digital signatures, together with indelible links back to network-hosted servers (operated by the organization to which the information belongs) that store the decryption keys and associated access rights.

Sealed documents and emails can be distributed by any existing means, including email, the web, and file sharing.

This section describes various Oracle WebCenter Content: Information Rights artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The ORAIRM schema is part of the Oracle WebCenter Content: Information Rights database. In addition to the database, when you install Oracle WebCenter Content: Information Rights, a keystore is created that is used by the Oracle IRM J2EE application. Oracle recommends that you locate the key store in a directory under the domain home, so that when the domain is restored, the keystore is automatically available. If the keystore is not stored under the domain, then you must manually copy the keystore to the replicated system.

Special Considerations

Load balancer virtual hosts for Oracle Identity Federation should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The databases containing the Oracle WebCenter Content: Information Rights schemas and the data stores must be recovered to the most recent point in time, along with the Managed Server running the Oracle WebCenter Content: Information Rights application.

2.8.5 Recommendations for Oracle WebCenter Content: Records

Oracle WebCenter Content: Records effectively manages content items on a retention schedule, which determines the life cycle of that content item.

The focus of records management tends to be the preservation of content for historical, legal, or archival purposes while also performing retention management functions. The focus of retention management tends to be the scheduled elimination of content in which the costs of retaining content outweighs the value of keeping it.

Oracle WebCenter Content: Records combines both record and retention management into one software system. You can use Oracle WebCenter Content: Records to track and to preserve content as needed, or to dispose of content when it is no longer required.

This section describes various Oracle WebCenter Content: Records artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The URMSERVER and MDS schemas are part of the Oracle WebCenter Content: Records database.

Special Considerations

Load balancer virtual hosts for Oracle WebCenter Content: Records should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making configuration changes and applying patches.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the Managed Servers running the Oracle WebCenter Content: Records application, along with the Administration Server.

2.9 Recommendations for Oracle Business Intelligence

Oracle Business Intelligence is a portfolio of technology and applications that provides the industry's first integrated, end-to-end Enterprise Performance Management System, including Oracle Business Intelligence foundation and tools as well as financial performance management applications, operational Oracle Business Intelligence applications, and data warehousing.

Common Artifacts and Considerations for all Oracle Business Intelligence Components

The following artifacts and considerations apply to all the Oracle Business Intelligence components, along with the component-specific considerations.

Artifacts on the File System

MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home containing the Oracle Business Intelligence binary files.

Oracle Common home: This is the Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Domain home: The domain home contains the Administration Server and Managed Server configuration data and Oracle Business Intelligence applications for the domain.

Oracle instance: The Oracle instance contains configuration files, log files, and temporary files for one or more Oracle system components (such as Oracle Business Intelligence Server, Oracle Business Intelligence Presentation Services and Oracle HTTP Server).

Artifacts in the Database

The Oracle Business Intelligence schemas are in the Oracle Business Intelligence database.

Network Artifacts

Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

The load balancer virtual hosts used to access the Oracle Business Intelligence components must be configured on both the production and standby sites.

Synchronization Recommendations

The directory tier must be manually synchronized with the standby site after making changes in the configuration, deploying applications, and applying patches.

Oracle Data Guard should be configured for Oracle database metadata repositories.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.

Recovery Recommendations

The database containing the Oracle Business Intelligence schemas must be recovered to the most recent point in time, along with the Identity Management component in question.

The rest of this section describes Disaster Recovery recommendations for the following Oracle Business Intelligence components:

2.9.1 Recommendations for Oracle Business Intelligence Enterprise Edition (EE)

Oracle Business Intelligence Enterprise Edition (Oracle BI EE) is a comprehensive set of enterprise business intelligence tools and infrastructure, including a scalable and efficient query and analysis server, an ad-hoc query and analysis tool, interactive dashboards, proactive intelligence and alerts, real-time predictive intelligence, and an enterprise reporting engine. Oracle Business Intelligence Enterprise Edition is designed to bring greater business visibility and insight to a wide variety of users.

Artifacts in the Database

BIPLATFORM schema is part of the Oracle Business Intelligence Enterprise Edition (EE) database.

Special Considerations

Load balancer virtual hosts for Oracle Business Intelligence Enterprise Edition (EE) should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the Middleware home, the domain, and the Oracle instance containing the Oracle Business Intelligence Enterprise Edition (EE) components. On Windows, import Oracle Business Intelligence Enterprise Edition (EE) Registry entries. Recover the database to the most recent point in time, if needed.

2.9.2 Recommendations for Oracle Business Intelligence Publisher

Oracle Business Intelligence Publisher (Business Intelligence Publisher, formerly XML Publisher) allows you to create highly formatted reports that are suitable for printing. Business Intelligence Publisher reports are built on top of Business Intelligence Publisher data models. An Oracle Business Intelligence Publisher data model can consist of data sets from a wide range of sources, such as subject areas from the Oracle Business Intelligence Server or analyses, SQL queries against relational data bases, MDX queries against Subbase or other OLAP sources, LDAP, web services, Microsoft Excel, HTTP feeds, or XML files. Oracle Business Intelligence Publisher supports a wide range of layout types, so you can create the full range of documents that your organization might need. Within Oracle Business Intelligence Enterprise Edition you can view, create, edit, and schedule Oracle Business Intelligence Publisher reports and then include them in dashboard pages.

Artifacts in the Database

BIPLATFORM schema is a part of the Oracle Business Intelligence Publisher database.

Special Considerations

Load balancer virtual hosts for Oracle Business Intelligence Publisher should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making changes in the configuration and applying patches.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the Managed Server containing the Oracle Business Intelligence Publisher component.

2.9.3 Recommendations for Oracle Real-Time Decisions

Oracle Real-Time Decisions (Oracle RTD) enables you to develop adaptive enterprise software solutions. These adaptive solutions continuously learn from business transactions while they execute, and automatically optimize each transaction, in real time, by close loop business rules and predictive models.

Artifacts in the Database

Analytic models and the RTD schema are part of the Oracle Real-Time Decisions database.

Special Considerations

Load balancer virtual hosts for Oracle Real-Time Decisions should be configured on both the production and standby sites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after making configuration changes and applying patches.

Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the Managed Server containing the Oracle Real-Time Decisions component.