This chapter describes the disaster protection requirements for Oracle Fusion Middleware components in different Oracle product suites and also provides recommendations for synchronizing these components. As mentioned previously, use storage replication to synchronize middle tier content, and use Oracle Data Guard to synchronize data in Oracle database repositories or custom application databases included in your Oracle Fusion Middleware Disaster Recovery topology.
This chapter includes the following sections:
Note:
Certain artifacts like Oracle Inventory, the beahomelist file, the oratab file and oraInst.loc file are common across all Oracle product deployments. These artifacts change very rarely and need not be part of the regular storage replication and synchronization activity. Oracle recommends placing Oracle Inventory, the beahomelist file, the oratab file, and the oraInst.loc file on the local disk of the machines. These artifacts should be manually updated upon creation, as well as upon applying patch updates. If required by your environment, these artifacts can also be on shared storage. For information about how to manage Oracle Inventory, see Appendix A.
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.
Oracle home: The Oracle home consists of a WebLogic home that has the WebLogic Server binary files.
Domain home: The domain home contains the configuration data and the applications for the WebLogic domain.
Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.
If your environment requires whole server migration to be configured, then use the virtual host name as the listen address of the Managed Servers that are configured for whole server migration. To avoid manually updating the listen address after a Disaster Recovery operation, ensure that the host name can be resolved on both the primary and standby sites.
The load balancer virtual hosts used for accessing the WebLogic Server applications should be configured on both the production and standby sites.
The rest of this section describes Disaster Recovery recommendations for the following Oracle WebLogic Server components:
This section describes various Oracle WebLogic Server JMS and T-Log artifacts and provides recommendations for disaster recovery.
File-based persistent stores: The file store location for the JMS and 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 enqueued after the system restore point time but never processed. Message duplicates are generated for messages enqueued before the restore point time, but dequeued and acknowledged or committed (processed) after this time.
If the persistent store is a custom store that is dedicated to JMS use, then you can delete the entire store.
Restoring different parts of the system to different points in time can lead to inconsistent data. This can occur when the message store, transaction log, or application database are synchronized differently. For example, a message may reference a database row that does not exist, or the reverse. This may delete unprocessed messages in addition to duplicate messages.
If the store is not dedicated to JMS use, then use the Oracle WebLogic Server JMS message management administrative tooling. This tooling can perform import, export, move, and delete operations from the Administration Console, MBeans, and WebLogic Scripting Tools (WLST).
When applications use both queues and topics, ensure that you manipulate both the queue and topic subscriptions.
Synchronization Recommendations
If JMS data is critical, then synchronize transaction log data and JMS data in real time using synchronous replication. Using synchronous replication may have performance implications.
If data consistency between tiers is important, then ensure that the database and application tiers are replicated at the same time. This helps ensure that the different tiers recover to the same exact point in time.
Use Oracle Data Guard to replicate the primary site and standby site when using database-based persistent stores.
When using a storage device that does not support block-level snapshot capabilities, shut down the JMS server to create a consistent backup. This ensures that the persistence store is not being written to while the copy operation is being performed. In a clustered environment, shut down one server at a time, back it up, and restart it. You also can create a script to perform these operations using WLST.
Recover the database schemas containing the persistent stores for the Administration Server and the Managed Servers in the WLS domain to the most recent point in time.
Also, use the following recovery recommendations to avoid duplicate messages.
Perform the following procedure before recovery to filter messages in the JMS queue after persistent-store recovery, to avoid processing duplicate messages:
Note:
Do not drain and discard messages without 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 in to the Oracle WebLogic Server Administration Console.
Before recovery, configure JMS server to pause Production, Insertion, and Consumption operations at Startup. This ensures 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 that 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, and then select a destination.
Select Monitoring, and then click Show Messages.
Click Delete All.
Resume operations by following the instructions listed in step 2.
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
You must manually synchronize the application tier with the standby site after making configuration changes and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.
Recover the Administration Server and the Managed Servers in the WebLogic Server 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 that combine multiple technology components.
SOA composite applications consist of:
Service components: Service components are the basic building blocks of SOA composite applications. Service components implement 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 12c (12.1.3), the soa-infra and service-engine configuration files were stored in local or shared storage files as part of the domain configuration.
Starting in Oracle SOA Suite 11gR1 (11.1.1.2), those files were moved into the metadata repository. Thus, soa-infra and service-engine configuration changes are now immediately propagated across a cluster.
In Oracle SOA Suite 11g R1 (11.1.1.3), you can deploy Oracle Business Process Management (BPM) Suite on top of an Oracle SOA Suite installation.
The Disaster Recovery recommendations for Oracle SOA Suite assume that you are using Oracle SOA Suite 12c R1 (12.1.3).
Oracle SOA Suite artifacts are stored on the local or shared file system as well as in the metadata repositories. Composite artifacts are stored in the metadata repository, and binary files and domain-related configuration files are stored on a local or shared file system.
Common Artifacts and Considerations for All Oracle SOA Suite Components
The following artifacts and considerations apply to all the Oracle SOA Suite components, along with the component-specific considerations.
Oracle home: The Oracle home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home containing the Oracle SOA Suite binary files.
Oracle Common Home: This is Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).
Domain home: The domain home contains the configuration data and SOA composites for the SOA domain.
Oracle recommends using the virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation. See the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for instructions for updating an IP address to a virtual host name.
The load balancer virtual hosts required for accessing the Oracle SOA Suite components should be configured on both the production and standby sites.
Oracle SOA Suite schemas, Service Infrastructure and Service Engine configurations, and composite definitions are stored in the Oracle SOA Suite database and metadata repository.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration, deploying composites, and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. For more information, see Section 3.3.2 and "Applying Redo Data to Physical Standby Databases" in Oracle Data Guard Concepts and Administration.
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 matching the composite definition to continue processing. For this reason, the metadata repository (where composite definitions are stored) and Oracle SOA Suite database (where the process state is maintained) must be recovered to the same point in time.
In redeployed composites, a database recovery ensures consistency between the dehydrated in-flight processes and their corresponding definition because the process definition is stored in database repository where dehydrated instances are stored.
This section describes Disaster Recovery recommendations for the following Oracle SOA Suite components:
Oracle SOA Service Infrastructure is a Java EE application that provides the foundation services for running Oracle SOA Suite. This Java EE application is a runtime engine that is automatically deployed when Oracle SOA Suite is installed. You deploy composites (the basic artifacts in a Service Component Architecture) to the Oracle SOA Infrastructure and it provides the required services for the composites to run. Oracle SOA Infrastructure provides deployment, wiring, and thread management services for the composites. These services sustain the lifecycle and run-time operations of the composite.
This section describes various Oracle SOA Service Infrastructure artifacts and provides recommendations for disaster recovery.
Composite definition and configuration files are stored in the MDS repository. The composite instance state persistence is stored in the Oracle SOA Service Infrastructure database.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration, deploying composites, and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.
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 Oracle SOA Service Infrastructure that allows the execution of BPEL processes. A BPEL process provides the standard for assembling a set of discrete services into an end-to-end process flow, and developing synchronous and asynchronous services into end-to-end BPEL process flows. It provides process orchestration and storage of long-running, asynchronous processes.
This section describes various Oracle BPEL Process Manager artifacts and provides recommendations for disaster recovery.
Process definition and configuration files are stored in the MDS repository. The BPEL process state persistence is stored in the Oracle SOA Suite database.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making domain-related configuration changes and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.
The database must be recovered to the most recent point in time to ensure that the latest process definitions and in-flight instances are restored. Idempotent Oracle BPEL Process Manager processes are recommended, because no cleanup is required after performing a Disaster Recovery operation. If non-idempotent 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. 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.
Note:
Sequential routing rules do not persist their messages into the database as part of the execution.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.
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 changes in the domain-related configuration and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.
The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application. The Oracle Human Workflow engine uses Oracle User Messaging Service to send and receive notifications. See Section 2.2.7 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 business-to-business (B2B) standards. Oracle B2B extends Oracle SOA Suite with business protocol standards, such as electronic data interchange (EDI), ebXML, HL7, and RosettaNet. Oracle B2B is implemented as a binding component within the SOA Service Infrastructure.
This section describes various Oracle B2B artifacts and provides recommendations for disaster recovery.
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 e-mail servers should be available on the standby site if these adapters are used.
Synchronization Recommendations
For information about Oracle B2B JMS queue synchronization and recovery, see Section 2.1.1.
The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.
The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application. Oracle B2B stores state information within JMS queues and the SOA runtime database, so recovering the database and the Managed Server will ensure that the application runs normally.
Oracle Web Services Manager (Oracle WSM) provides a policy framework to manage and secure web services consistently across your organization. It provides capabilities to build, enforce, execute and monitor web services policies including security, Web Services Reliable Messaging (WSRM), Message Transmission Optimization Mechanism (MTOM) and addressing policies. Oracle Web Services Manager consists of the Policy Manager and the Agent.
The Policy Manager reads and writes security and management policies, including predefined and custom policies from the MDS repository. The Policy Manager is a stateless Java EE application. It exposes its capabilities through stateless session beans. Although the Policy Manager does not cache any data, the underlying MDS infrastructure does.
The Agent is responsible for policy enforcement, execution, gathering of runtime statistics. The agent is available on all Oracle Fusion Middleware Managed Servers and is configured on the same server as the application it protects. The agent consists of two pieces: the Policy Access Point (PAP) and the Policy Interceptor.
This section describes various Oracle Web Services Manager artifacts and provides recommendations for disaster recovery.
The MDS repository is used for storing the policies.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then manually synchronize the standby database.
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 (UMS) enables two-way communication between users and deployed applications. It has support for a variety of channels, such as e-mail, IM, SMS, and text-to-voice messages. Oracle User Messaging Service is integrated with Oracle Fusion Middleware components such as Oracle BPEL Process Manager, Oracle Human Workflow, Oracle Business Activity Monitoring (BAM) and Oracle WebCenter Portal. It is typically deployed with Oracle User, 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 the 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 changes in the configuration, deploying additional Oracle User Messaging Service drivers, and applying patches.
Oracle Data Guard should be configured for Oracle database metadata repositories.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.
The database must be recovered to the most recent point in time, along with the Managed Server running the usermessagingserver application. Oracle User Messaging Service maintains the message and configuration state in an external database repository along with persisting messages in JMS queues, so recovering the database and the Managed Server ensures that the application functions without any issues. For recommendations on synchronizing JMS data, refer to the "Synchronization Recommendations" subsection in Section 2.1.1.
Oracle JCA Adapters are JCA binding components that allow the Service Infrastructure to communicate to endpoints using different protocols. Oracle JCA Adapters are deployed as a JCA resource (RAR) and are not part of the Oracle SOA Service Infrastructure.
The broad categories of Oracle JCA Adapters are:
Oracle Technology Adapters
Legacy Adapters
Packaged-Application Adapters
Oracle Adapter for Oracle Applications
See the Oracle Fusion Middleware User's Guide for Technology Adapters for additional information about the types of Oracle JCA Adapters.
This section describes various Oracle JCA Adapter artifacts and provides recommendations for disaster recovery.
Certain adapters use local or shared-storage files, for example:
JMS adapters utilizing WebLogic JMS with file-based persistence store: The persistence store must be synchronized with the standby site to resume processing after failover.
Inbound and outbound files from either File or FTP adapters: The relevant files must be synchronized with the standby site to resume processing after failover.
Adapter configuration is maintained in the weblogic-ra.xml deployment descriptor for the ear JCA resource (RAR). The location of each weblogic-ra.xml file is determined by the administrator when the file is created, and must be replicated to the standby site.
Adapter artifacts are generated at design time as part of the composite project. These artifacts are stored with the rest of the composite definition in the metadata repository.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration (that is, adapter configuration changes) and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then manually synchronize the standby database.
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 correlation of market indicators to the actual business process and to changing business processes quickly or taking corrective actions if the business environment changes. Oracle BAM provides the necessary tools and runtime services for creating dashboards that display real-time data inflow and define rules to send alerts under specified conditions.
This section describes various Oracle BAM artifacts and provides recommendations for disaster recovery.
Oracle BAM data and report metadata is stored in the Oracle BAM database that contains Oracle BAM schemas.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making domain-related configuration changes and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database containing the Oracle BAM schemas and the metadata repository.
Oracle recommends that you synchronize the standby database when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.
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
Oracle 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 Oracle Metadata Services (MDS) repository. Oracle BPM also uses a separate MDS partition to share projects and project templates between process analysts and process developers.
Synchronization Recommendations
The application tier must be manually synchronized with the standby site after making changes in the domain-related configuration and applying patches.
Oracle Data Guard should be configured for the Oracle SOA Suite database and metadata repository.
When the application tier synchronization is initiated on the storage, the standby database is also updated to the same point in time. This is recommended if a snapshot Standby database is used.
The database must be recovered to the most recent point in time, along with the Managed Server running the soa-infra application.