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 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.
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 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
The artifacts and considerations below apply to all the Oracle WebCenter 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 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 domain.
The Oracle WebCenter schema stores data for some of the Oracle WebCenter services and is part of Oracle WebCenter 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 WebCenter 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 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. 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 schemas must be recovered to the most recent point in time, along with the Managed Servers running the WebCenter applications.
The rest of this section describes Disaster Recovery recommendations for the following Oracle WebCenter products:
Oracle WebCenter 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 Oracle WebCenter Spaces artifacts and provides recommendations for disaster recovery.
The WebCenter schema stores data for some of the Oracle WebCenter services and is part of the Oracle WebCenter schemas, and the MDS repository stores WebCenter 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 schema and MDS repository must be recovered to the most recent point in time, along with the Oracle WebCenter domain.
Oracle WebCenter Portlets 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 provides several out-of-the-box producers, such as OmniPortlet, Web Clipping, Rich Text Portlet, and WSRP Tools.
This section describes various Oracle WebCenter Portlets artifacts and provides recommendations for disaster recovery.
The Portlet schema stores user customizations and is part of the Oracle WebCenter 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 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 Portlet schema and MDS repository must be recovered to the most recent point in time, along with the Oracle WebCenter domain.
Oracle WebCenter Discussions Server provides the ability to integrate discussion forums and announcements into your applications.
This section describes various Oracle WebCenter Discussions Server artifacts and provides recommendations for disaster recovery.
The Discussions schema stores metadata and data and is part of the Oracle WebCenter 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 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 Discussions schema must be recovered to the most recent point in time, along with the Oracle WebCenter domain.
Oracle WebCenter Wiki and Blog server provides the ability to integrate wikis and blogs into your 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 Wiki schema stores metadata and data and is part of the Oracle WebCenter 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 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 Wiki schema must be recovered to the most recent point in time, along with the Oracle WebCenter domain.
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 |
|---|---|---|
|
dist_B2BEventQueue_auto |
Distributed queue |
jms/b2b/B2BEventQueue |
|
dist_B2B_IN_QUEUE_auto |
Distributed queue |
jms/b2b/B2B_IN_QUEUE |
|
dist_B2B_OUT_QUEUE_auto |
Distributed queue |
jms/b2b/B2B_OUT_QUEUE |
|
dist_B2BBroadcastTopic_auto |
Distributed topic |
jms/b2b/B2BBroadcastTopic |
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. 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 |
|---|---|---|
|
OraSDPMAppDefRcvQ1_auto |
Distributed queue |
OraSDPM/Queues/OraSDPMAppDefRcvQ1 |
|
OraSDPMDriverDefSndQ1_auto |
Distributed queue |
OraSDPM/Queues/OraSDPMDriverDefSndQ1 |
|
OraSDPMEngineCmdQ_auto |
Distributed queue |
OraSDPM/Queues/OraSDPMEngineCmdQ |
|
OraSDPMEngineRcvQ1_auto |
Distributed queue |
OraSDPM/Queues/OraSDPMEngineRcvQ1 |
|
OraSDPMEngineSndQ1_auto |
Distributed queue |
OraSDPM/Queues/OraSDPMEngineSndQ1 |
|
OraSDPMWSRcvQ1_auto |
Distributed queue |
OraSDPM/Queues/OraSDPMWSRcvQ1 |
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 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 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 install directory: The Oracle Access Manager installation directory contains both configuration data and product binaries for the Oracle Access Manager products. It includes the Oracle home for the Identity Server, Access Server, Policy Manager, and WebPass. The Policy Manager and WebPass share a home with the Oracle HTTP Server instance installed on the OAMADMINHOST.
Oracle HTTP Server Oracle Home: This is the Oracle home for the Oracle HTTP Server instance that front ends the Oracle Access Manager topology.
Oracle HTTP Server Oracle Instance: The Oracle HTTP Server Oracle instance contains the configuration data for the Oracle HTTP Server instance that front ends the Oracle Access Manager topology.
WebGate install directory: The WebGate install directory contains the binaries and configuration data for Oracle WebGate.
Oracle Access Manager uses the OAM and AU schemas, which are part of the Oracle Identity Management database.
Oracle Access Manager stores configuration information in an LDAP store.
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 Oracle Access Manager Identity Server, Access Server, Policy Manager, and WebPass servers, along with the associated Oracle HTTP Server instances.
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, 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 Enterprise Content Management Suite is an integrated suite of products designed for managing content. This Oracle Enterprise Content Management 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 Enterprise Content Management Components
The artifacts and considerations below apply to all the Oracle Enterprise Content 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 Enterprise Content 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 Oracle Enterprise Content Management applications for the domain.
Oracle Instance: The Oracle instance contains the configuration data for non-J2EE Oracle Enterprise Content Management applications like OPMN configuration and Enterprise Manager Agent configuration data.
The Oracle Enterprise Content Management Suite schemas are in the Oracle Enterprise Content Management Suite 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 Enterprise Content Management Suite 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 Universal Content Management provides a unified application for several different kinds of content management.
Oracle Universal Content Management 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 Universal Content Management 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 Universal Content Management artifacts and provides recommendations for disaster recovery.
Oracle Secure Files or File-based persistent stores.
The OCS schema is part of the Oracle Universal Content Management database.
The load balancer virtual hosts required for the Oracle Universal Content Management 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 Universal Content Management must be recovered with the OCS and MDS schemas to the most recent point in time.
Oracle 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 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 Inbound Refinery to convert content items stored in Oracle Content Server.
This section describes various Oracle Inbound Refinery artifacts and provides recommendations for disaster recovery.
Oracle Inbound Refinery does not have any database dependencies.
The load balancer virtual hosts required for Oracle 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 Inbound Refinery instance.
Oracle Imaging and Process Management provides organizations with a scalable solution upon which to develop process-oriented imaging applications and image-enablement solutions for enterprise applications. Oracle Imaging and Process Management 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 Imaging and Process Management, 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 Imaging and Process Management 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 Imaging and Process Management database. Oracle Imaging and Process Management also requires OCS schema, to use Oracle Universal Content Management as the Oracle Imaging and Process Management 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 Imaging and Process Management must be recovered with the IPM schema to the most recent point in time, along with the Managed Server running the Oracle Imaging and Process Management application, and the associated instances.
Oracle Information Rights Management distributes rights management between centralized servers and desktop agents.
Oracle Information Rights Management 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 Information Rights Management artifacts and provides recommendations for disaster recovery.
The ORAIRM schema is part of the Oracle Information Rights Management database. In addition to the database, when you install Oracle Information Rights Management 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 Information Rights Management schemas and the data stores must be recovered to the most recent point in time, along with the Managed Server running the Oracle Information Rights Management application.
Oracle Universal Records Management 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 Universal Records Management combines both record and retention management into one software system. You can use Oracle Universal Records Management to track and to preserve content as needed, or to dispose of content when it is no longer required.
This section describes various Oracle Universal Records Management artifacts and provides recommendations for disaster recovery.
The URMSERVER and MDS schemas are part of the Oracle Universal Records Management database.
Load balancer virtual hosts for Oracle Universal Records Management 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 Universal Records Management application, along with the Administration Server.