This chapter describes the disaster protection requirements for Oracle Fusion Middleware components in different Oracle product suites and also provides recommendations for synchronizing those 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 provides Disaster Recovery recommendations for components in the following Oracle product suites:
Common Artifacts Across Oracle Product Suites
Certain artifacts like the 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. It is recommended to have the 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.
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.
MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binaries.
Domain home: The domain home contains the configuration data and the applications for the WebLogic domain.
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 site, there is no need to update this value after a Disaster Recovery operation.
If your environment requires whole server migration to be configured, it is recommended to 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, make sure 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:
This section describes various Oracle WebLogic Server JMS and transaction log (T-log) artifacts and provides recommendations for disaster recovery.
File-based persistent stores: The file store location for the JMS/T-log when using a file based persistent store.
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.
Messages are lost if they were en-queued 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 vice-versa. This may delete unprocessed messages in addition to duplicate messages.
If the store is not dedicated to JMS use, 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 WLST.
When applications use both queues and topics, make sure to manipulate both the queue and topic subscriptions.
Synchronization Recommendations
If JMS data is critical, it is recommended to synchronize transaction log data and JMS data in real time using synchronous replication. Note that using synchronous replication may have performance implications.
If data consistency between tiers is important, 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 take a consistent backup. This is to ensure that the persistence store is not being written to while the copy operation is being performed. In a clustered environment, you can do so by shutting down one server at time, backing it up and restarting it. You also can create a script to perform these operations using WLST.
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, follow the recovery recommendations below for avoiding duplicate messages.
Use the following procedure before recovery to drain 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.
Log into the Oracle WebLogic Server Administration Console.
Before recovery, configure JMS server to pause Production, Insertion, and consumption operations at boot-time 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:
Expand Services, then Messaging, and then JMS Servers.
On the Summary of JMS Servers page, click the JMS server you want to configure for message pausing.
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.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Use the following procedure after recovery:
After recovering the persistent store, start the Managed Servers.
Drain the stale messages from JMS destinations by following these steps:
Expand Services, then Messaging, and then JMS Modules.
Select a JMS module, then select a destination.
Select Monitoring, then Show Messages.
Click Delete All.
Resume operations by following these steps:
Expand Services, then Messaging, and then JMS Servers.
On the Summary of JMS Servers page, click the JMS server you want to configure for message pausing.
On the Configuration: General page, click Advanced. Select Insertion Paused At Startup, Production Paused At Startup, and Consumption Paused At Startup.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
This section describes various Oracle Platform Security Services artifacts and provides recommendations for disaster recovery.
Not applicable because Oracle Platform Security Services does not have any database dependencies.
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.
It is recommended that the standby database be synchronized 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, "Manually Forcing Database Synchronization with Oracle Data Guard" and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.
Recover the Administration Server and the Managed Servers in the WebLogic Server domain.
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.
MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binaries.
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 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.
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 site, 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.
Oracle ADF applications may use the MDS repository to persist the application state and configuration data. Persisting 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 configuration changes, deploying composites, applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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, "Manually Forcing Database Synchronization with Oracle Data Guard" and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.
The database must be recovered to the most recent point in time, along with the Managed Servers running the ADF or WebCenter applications.
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 artifacts and considerations below apply to all the Oracle WebCenter Portal products along with the product-specific considerations.
MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binaries and an Oracle home containing the Oracle WebCenter Portal binaries.
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 configuration data for the Oracle WebCenter Portal domain.
The Oracle WebCenter Portal metadata stores data for some of the Oracle WebCenter Portal services and is part of Oracle WebCenter Portal databases, and the MDS repository stores WebCenter metadata and configuration information.
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 site, 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 configuration changes, 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.
It is recommended that the standby database be synchronized 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, "Manually Forcing Database Synchronization with Oracle Data Guard" and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.
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 the following Oracle WebCenter Portal products:
Recommendations for Oracle WebCenter Portal's Portlet Producers
Recommendations for Oracle WebCenter Portal's Discussion Server
Recommendations for Oracle WebCenter Portal's Analytics Collector Collector
Recommendations for Oracle WebCenter Portal Activity Graph Engines
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.
The WEBCENTER schema stores data for some of the Oracle WebCenter Portal services and 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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for the Oracle database containing the WEBCENTER schema and the metadata repository.
It is recommended that the standby database be synchronized 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.
The database containing the WebCenter Portal schema and MDS repository must be recovered to the most recent point in time, along with the Oracle WebCenter Portal domain.
Oracle WebCenter Portal supports deployment and execution of both standards-based portlets (JSR 168, WSRP 1.0 and 2.0), and traditional Oracle PDK-Java based portlets. Oracle WebCenter Portal provides several out-of-the-box 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.
The PORTLET schema stores user customizations and is part of the Oracle WebCenter Portal schemas, and the MDS repository stores portlet metadata and configuration information.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for the Oracle database containing the PORTLET schema and the metadata repository.
It is recommended that the standby database be synchronized 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.
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.
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.
The DISCUSSIONS 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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for the Oracle database containing the DISCUSSIONS schema and the metadata repository.
It is recommended that the standby database be synchronized 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.
The database containing the Discussion Server schema must be recovered to the most recent point in time, along with the Oracle WebCenter Portal domain.
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.
The 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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for the Oracle database containing the OCSERVER schema.
It is recommended that the standby database be synchronized 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.
The database containing the OCSERVER schema must be recovered to the most recent point in time, along with the Oracle WebCenter Portal domain.
Oracle WebCenter Portal's Analytics Collector allows portal managers and business owners to track and analyze portal usage.
This section describes the Oracle WebCenter Portal's Analytics Collector data that must be backed up and restored.
Configuration information is stored in the Analytics schema, ACTIVITIES.
Database Repository Dependencies
ACTIVITIES and MDS schema
Back up the Oracle home, the domain home, and the database containing the ACTIVITIES and MDS schemas.
Recover the Oracle home and the domain home.
Recover the database to the most recent point in time, if needed.
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 information is stored in the ACTIVITIES schema.
Database Repository Dependencies
ACTIVITIES schema
Back up the Oracle home, the domain home, and the database containing the ACTIVITIES schema.
Recover the Oracle home and the domain home.
Recover the database to the most recent point in time, if needed.
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. Composites enable you to easily assemble multiple technology components into one SOA composite application. SOA composite applications consist of:
Service components: Service components are the basic building blocks of SOA composite applications. Service components implement a part of the overall business logic of the SOA composite application. Oracle BPEL Process Manager, Oracle Mediator, Oracle Human Workflow and Business Rules are examples of service components.
Binding components: Binding components connect SOA composite applications to external services, applications, and technologies. Binding components are organized into two groups:
Services: Provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. The service bindings define how a SOA composite service can be invoked (for example, through SOAP).
References: Enable messages to be sent from the SOA composite application to external services (for example, the same functionality that partner links provide for BPEL processes, but at the higher SOA composite application level).
Note:
In Oracle SOA Suite release 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 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 11.1.1.3, you can deploy Oracle BPM Suite on top of a SOA Suite installation.
The Disaster Recovery recommendations for Oracle SOA Suite assume that you are using Oracle SOA Suite 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 binaries and domain-related configuration files are stored on a local or shared file system.
Common Artifacts and Considerations for All SOA Suite Components
The artifacts and considerations below apply to all the SOA Suite components, along with the component-specific considerations.
MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binaries and an Oracle home containing the Oracle SOA Suite binaries.
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 configuration data and SOA composites for the SOA domain.
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 site, there is no need to update this value after a Disaster Recovery operation. See Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for instructions updating an IP address to a virtual host name.
The load balancer virtual hosts required for accessing the SOA Suite components should be configured on both the production and standby sites.
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 domain-related configuration changes, deploying composites, and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
It is recommended that the standby database be synchronized 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, "Manually Forcing Database Synchronization with Oracle Data Guard" and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.
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 process state is maintained) must be recovered to the same point in time.
In case of redeployed composites, a database recovery ensures consistency between the dehydrated in-flight processes and their corresponding definition since 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:
Oracle SOA Service Infrastructure is a Java EE application that provides the foundation services for running Oracle Fusion Middleware SOA Suite. This Java EE application is a run-time engine that is automatically deployed when Oracle Fusion Middleware 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 composite's lifecycle and run-time operations.
This section describes various Oracle SOA Service Infrastructure artifacts and provides recommendations for disaster recovery.
Composite definition and configuration files are stored in the MDS repository. The composite instance state persistence is stored in the SOA Service Infrastructure database.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making domain-related configuration changes, deploying composites, and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
It is recommended that the standby database be synchronized 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.
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.
The Oracle BPEL Process engine is the service engine running in 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.
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.
It is recommended that the standby database be synchronized 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.
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, since 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.
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.
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 domain-related configuration changes and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
It is recommended that the standby database be synchronized 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.
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.
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.
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 domain-related configuration changes and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
It is recommended that the standby database be synchronized 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.
The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application. Oracle Human Workflow's engine uses Oracle User Messaging Service to send and receive notifications. See Section 2.4.7, "Recommendations for Oracle User Messaging Service" for details about Oracle User Messaging Service.
Oracle B2B connects SOA composite applications to external services, applications, and technologies. Oracle B2B offers a multi-protocol gateway that supports industry-recognized 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.
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 |
|---|---|---|
|
|
Distributed queue |
|
|
|
Distributed queue |
|
|
|
Distributed queue |
|
|
|
Distributed topic |
|
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.
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, refer to Section 2.1.1, "Recommendations for Oracle WebLogic Server JMS and T-Logs."
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.
It is recommended that the standby database be synchronized 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.
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 run-time database, so recovering the database and the Managed Server will ensure that the application runs normally.
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 Service policies including security, WSRM, MTOM and addressing policies. Oracle Web Services Manager is made up 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. 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 and gathering of run-time statistics. The agent is available on all Oracle Fusion Middleware Managed Servers and is configured on the same server as the application which 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.
The MDS repository is used for storing the policies.
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 Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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.
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.
Oracle User Messaging Service (Oracle 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 PM, Oracle Human Workflow, Oracle 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.
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 |
|---|---|---|
|
|
Distributed queue |
|
|
|
Distributed queue |
|
|
|
Distributed queue |
|
|
|
Distributed queue |
|
|
|
Distributed queue |
|
|
|
Distributed queue |
|
Oracle User Messaging Service depends on an external database repository to maintain message and configuration state.
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 configuration changes, deploying additional Oracle User Messaging Service drivers, and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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.
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 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, "Recommendations for Oracle WebLogic Server JMS and T-Logs."
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 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.
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 file location of each weblogic-ra.xml is determined by the administrator when the file is created, and must be replicated to the standby site.
Adapter artifacts are generated at design time as part of the composite project. These artifacts are stored along 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 domain-related configuration changes (that is, adapter configuration changes) and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
It is recommended that the standby database be synchronized 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.
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.
Oracle Business Activity Monitoring (BAM) provides the tools for monitoring business services and processes in the enterprise. It allows correlating 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 run-time 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.
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 BAM schema and the metadata repository.
It is recommended that the standby database be synchronized 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.
The database must be recovered to the most recent point in time, along with the Managed Server running Oracle BAM.
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
Human workflow
Oracle adapter framework for integration
SOA Composite Architecture
This section describes various Oracle BPM artifacts and provides recommendations for disaster recovery.
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.
Process definition, deployed applications, and configuration files are stored in the Metadata Service (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 domain-related configuration changes 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 be up to the same point in time. This is recommended if a snapshot Standby database is used.
The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application.
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 into and access online resources.
Common Artifacts and Considerations for all Oracle Identity Management Components
The artifacts and considerations below apply to all the Oracle Identity Management components along with the component-specific considerations.
MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binaries and an Oracle home containing the Oracle Identity Management binaries.
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 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 OPMN configuration and Enterprise Manager Agent configuration data.
The Identity Management schemas are in the Identity Management database.
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 site, there is no need to update this value after a Disaster Recovery operation.
The load balancer virtual hosts used to access the 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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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, "Manually Forcing Database Synchronization with Oracle Data Guard" and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.
The database containing the 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:
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.
The ODS and ODSSM schemas used by Oracle Internet Directory are part of the Identity Management database.
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 configuration changes and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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.
Oracle Internet Directory must be recovered with the ODS and ODSSM schemas to the most recent point in time.
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.
Oracle Virtual Directory does not have any database dependencies.
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 configuration changes and applying patches.
Recover the Oracle Virtual Directory instance.
Oracle Directory Integration Platform is a 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.
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 configuration changes and applying patches.
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.
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.
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.
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 configuration changes and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.
It is recommended that the standby database be synchronized 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.
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.
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.
Not applicable because the Oracle Directory Services Manager application does not have any database dependencies.
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 configuration changes and applying patches.
It is recommended that the standby database be synchronized 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.
Recover the Managed Servers running the Oracle Directory Services Manager application, along with the Administration Server.
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.
Oracle Access Manager uses the OAM, IAU (Audit Services) schemas, and the ODS schemas (for Oracle Internet Directory) which are part of the Oracle Identity Management database.
Oracle Access Manager stores configuration and user information in the Oracle Internet Directory.
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 configuration changes and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.
It is recommended that the standby database be synchronized 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.
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.
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.
Oracle Adaptive Access Manager uses the OAAM, OAAM PARTN, MDS, IAU (Audit Services), and the ODS (Oracle Internet Directory) schemas which 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.
Oracle Adaptive Access Manager stores configuration and user information in the Oracle Internet Directory.
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 configuration changes and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.
It is recommended that the standby database be synchronized 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.
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.
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 stand-alone product or as part of Oracle's Identity and Access Management Suite.
Oracle Identity Manager uses Oracle SOA for workflow, you must also follow the Oracle SOA disaster recovery recommendations. For more information, see Recommendations for Oracle SOA Suite.
This section describes various Oracle Identity Manager artifacts and provides recommendations for disaster recovery.
JMS Store: The volume containing the file-based JMS persistent store.
Oracle Identity Manager uses OIM, SOAINFRA, ORASPDM, and MDS schemas, which are part of the Oracle Identity Management database.
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 and external LDAP store when LDAP Sync is enabled or when integrated with Oracle Access Manager or Oracle Identity Federation.
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 a 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 Recommendations for Oracle WebLogic Server JMS and T-Logs.
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.
It is recommended that the standby database be synchronized 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 Recommendations for Oracle WebLogic Server JMS and T-Logs.
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 make sure to recover the ODS to the most recent point in time as well
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.
Oracle Identity Navigator does not use any schema.
Oracle Identity Navigator stores configuration information in an LDAP store.
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 configuration changes and applying patches.
It is recommended that the standby database be synchronized 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.
Recover the administration server running the Oracle Identity Navigator application.
This section describes artifacts and Disaster Recovery recommendations for the following suite of Oracle components:
Oracle Portal
Oracle Forms
Oracle Reports
Oracle Business Intelligence Discoverer (Discoverer)
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.
MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binaries and an Oracle home containing the binaries for Oracle Portal, Oracle Forms, Oracle Reports, and Discoverer.
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 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.
Database metadata repositories containing 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 is being accessed through Oracle Forms.
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 site, 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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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, "Manually Forcing Database Synchronization with Oracle Data Guard" and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.
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:
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.
The Portal, Portal_Demo, Portal_App, Portal_Public, and Portal_Approval schemas are part of the Oracle Portal metadata repository.
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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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.
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.
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.
Any user configured databases for the Oracle Forms applications.
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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for the user configured application databases.
It is recommended that the standby database be synchronized 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.
The Managed Server running the Oracle Forms application and the Oracle instance must be restored. If there are any user configured databases, they must be recovered to the most recent point in time.
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.
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.
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.
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 configuration changes and applying patches.
If the Reports Server is configured to store configuration or user information in other components like Oracle Portal and Oracle Internet Directory, make sure to synchronize these components between the production and standby sites as well.
Oracle Data Guard should be configured for Oracle Reports databases.
It is recommended that the standby database be synchronized 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.
The Managed Server running the Oracle Reports application and the Oracle instance must be restored. If there are any user configured databases, they must be recovered to the most recent point in time. Also recover any associated Oracle Portal and Oracle Internet Directory instances.
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 non-technical 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.
The DISCOVERER and DISCOVERER_PS schemas are part of the Discoverer metadata repository.
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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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.
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.
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:
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 the Oracle HTTP Server.
This section describes various Oracle HTTP Server artifacts and provides recommendations for disaster recovery.
Oracle Home: The Oracle home consists of the Oracle HTTP Server binaries.
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).
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 content served by the Oracle HTTP Server instance. This volume that contains static HTML content is optional; Oracle Fusion Middleware can operate normally without it.
Not applicable because Oracle HTTP Server does not have any database dependencies.
These are the special considerations for Oracle HTTP Server:
Load balancer virtual hosts for accessing the Oracle HTTP Server should be configured on both the production and standby sites.
This manual directs you to install 11g Oracle Fusion Middleware 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 11g Oracle HTTP Server requires. In these cases, the LockFile directive in the httpd.conf file must be changed to point at 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 11g Oracle HTTP Server instance is installed on shared storage and is experiencing performance problems, perform these steps for the Oracle HTTP Server instance to point the LockFile directive at a local file system:
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
Edit the $ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf file using the appropriate method.
Change the LockFile directive under the correct MPM configuration to point to a local file system:
LockFile /<local_disk>/<path>/http_lock
Restart the 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 configuration changes.
Restore the Oracle HTTP Server instance and related configuration files on the standby site.
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.
Oracle Home: The Oracle directory home consists of the Oracle Web Cache binaries.
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).
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.
Not applicable because Oracle Web Cache does not have any database dependencies.
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 configuration changes.
Restore the Oracle Web Cache instance and related configuration files on the standby site.
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 artifacts and considerations below apply to all the Oracle WebCenter Content components along with the component-specific considerations.
MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binaries and an Oracle home containing the Oracle WebCenter Content binaries.
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.
The Oracle WebCenter Content schemas are in the Oracle WebCenter Content database.
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 site, there is no need to update this value after a Disaster Recovery operation.
The load balancer virtual hosts used to access the Oracle Enterprise Content 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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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, "Manually Forcing Database Synchronization with Oracle Data Guard" and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.
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 Enterprise Content Management components:
Recommendations for Oracle WebCenter Content: Inbound Refinery
Recommendations for Oracle WebCenter Content: Information Rights
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.
Oracle Secure Files or File-based persistent stores.
The OCS schema is part of the Oracle WebCenter Content database.
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 configuration changes and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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 File-based persistent stores, you must synchronize the File-based persistent stores on the standby site.
Oracle WebCenter Content must be recovered with the OCS and MDS schemas to the most recent point in time.
Oracle WebCenter Content: Inbound Refinery is a conversion server that manages file conversions for electronic assets such as documents, digital images, and motion 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.
Oracle WebCenter Content: Inbound Refinery does not have any database dependencies.
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 configuration changes and applying patches.
Recover the Oracle WebCenter Content: Inbound Refinery instance.
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 Document Capture and Oracle Distributed Document 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 double entry.
This section describes various Oracle WebCenter Content: Imaging artifacts and provides recommendations for disaster recovery.
The IPM Input Agent pulls files from a common file share. This IPM file share must be synchronized with the standby site.
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 configuration changes 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, "Recommendations for Oracle WebLogic Server JMS and T-Logs".
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.
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 lifecycle, 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.
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 key store is created that is used by the Oracle IRM J2EE application. It is recommended that the key store is located in a directory under the domain home, so when the domain is restored the key store is automatically available. If the key store is not stored under the domain, then you must manually copy the key store to the replicated system.
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 configuration changes and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories and the data stores.
It is recommended that the standby database be synchronized 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.
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.
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.
The URMSERVER and MDS schemas are part of the Oracle WebCenter Content: Records database.
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.
It is recommended that the standby database be synchronized 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.
Recover the Managed Servers running the Oracle WebCenter Content: Records application, along with the Administration Server.
Oracle Business Intelligence (BI) is a portfolio of technology and applications that provides the industry's first integrated, end-to-end Enterprise Performance Management System, including BI foundation and tools as well as financial performance management applications, operational BI applications, and data warehousing.
Common Artifacts and Considerations for all Oracle Business Intelligence Components
The artifacts and considerations below apply to all the Oracle Business Intelligence components along with the component-specific considerations.
MW_HOME: The Middleware home consists of a WebLogic home that has the WebLogic Server binaries and an Oracle home containing the Oracle Business Intelligence binaries.
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 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 BI Server, Oracle BI Presentation Services, Oracle HTTP Server, and so on).
The Oracle Business Intelligence schemas are in the Oracle Business Intelligence database.
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 site, 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 configuration changes, deploying applications, and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
It is recommended that the standby database be synchronized 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, "Manually Forcing Database Synchronization with Oracle Data Guard" and "Applying Redo Data to Physical Standby Databases" in the Oracle Data Guard Concepts and Administration.
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:
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.
BIPLATFORM schema is part of the Oracle Business Intelligence Enterprise Edition (EE) database.
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 configuration changes and applying patches.
It is recommended that the standby database be synchronized 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.
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.
Oracle Business Intelligence Publisher (BI Publisher, formerly XML Publisher) allows you to create highly formatted reports that are suitable for printing. BI Publisher reports are built on top of BI Publisher data models. A BI Publisher data model can consist of data sets from a wide range of sources, such as subject areas from the BI 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. BI Publisher supports a wide range of layout types, so you can create the full range of documents that your organization might need. Within Oracle BI EE, you can view, create, edit, and schedule BI Publisher reports and then include them in dashboard pages.
BIPLATFORM schema is a part of the Oracle Business Intelligence Publisher database.
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 configuration changes and applying patches.
It is recommended that the standby database be synchronized 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.
Recover the Managed Server containing the Oracle Business Intelligence Publisher component.
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 way of close loop business rules and predictive models.
Analytic models and the RTD schema are part of the Oracle Real-Time Decisions database.
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.
It is recommended that the standby database be synchronized 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.
Recover the Managed Server containing the Oracle Real-Time Decisions component.