| Oracle SOA Suite 10g Release 3 (10.1.3.x) Backup and Recovery Recommendations [ID 557994.1] | |||||
| Modified 22-FEB-2011 Type BULLETIN Status PUBLISHED | |||||
In this Document
Purpose
Scope and Application
Oracle SOA Suite 10g Release 3 (10.1.3.x) Backup and Recovery Recommendations
References
Applies to:
Oracle Fusion Middleware - Version: 10.1.3.1.0 to 10.1.3.5.0 - Release: AS10gR3 to AS10gR3Information in this document applies to any platform.
Oracle Application Server 10g Enterprise Edition - Version: 10.1.3.1.0 to 10.1.3.5.0
Checked for relevance on 30-Jun-2009
Purpose
This document provides Backup and Recovery recommendations for Oracle SOA Suite 10g Release 3 (10.1.3.1+) deployments. This includes components like BPEL, ESB and OWSM. The recommendations are provided for both Middle Tier Backup/Recovery and database repository Backup/Recovery.Scope and Application
This document is targeted at system administrators responsible for the planning and implementation of backup and recovery solutions for architectures, which include Oracle SOA Suite 10g Release 3 (10.1.3.1+)Oracle SOA Suite 10g Release 3 (10.1.3.x) Backup and Recovery Recommendations
SOA Backup and Recovery
Oracle SOA Suite 10g Release 3 (10.1.3.1+) components like BPEL, ESB and OWSM have configuration data elements in middle-tier ORACLE_HOME. They also have associated metadata in the database-based repository. It is important to understand the consistency requirements between the middle-tier configuration data and metadata (in metadata repositories) for different components.It is recommended to configure Database hosting the SOA component repository schemas in Archive Log mode to allow for online DB backups and database point-in-time recovery.
Middle-tier backups are recommended after any patching or upgrade. If the patching/upgrade process also involves update to metadata repositories, then a consistent middle-tier and repository database backup is recommended. This can be achieved by taking both the backups in the same time frame.
1. BPEL Backup and Recovery
BPEL has the following Data elements of interest from the Backup and Recovery perspective:
1.1. Middle-tier configuration
BPEL stores the following configuration in middle-tier file system inside ORACLE_HOME on an Application Server Instance:
- Product binaries (which typically change with patching/upgrade)
- Process definitions: For 10.1.2 releases ONLY, the process definitions in deployed BPEL suitcases is maintained on middle-tier file system as well as is copied in to DB repository (dehydration store) . Hence, when a new process is deployed, the middle-tier file system gets updated. From 10.1.3 onwards, process definitions are maintained only in DB repository (dehydration store). When a new BPEL suitcase is deployed to a BPEL Process Manager instance, the BPEL PM engine picks up the suitcase.jar and writes it to dehydration store. It subsequently removes the suitcase jar file from the middle-tier file system. Temporary scratch files are generated during suitcase deployment but these can be removed without any consequence. All successfully loaded processes are copied to database repository and removed from the middle-tier file system. During engine startup, the deployed suitcases are downloaded from database repository and unzipped on the middle tier file system. This implies that deployed processes do not need any files in the mid tier file system to be in sync with the dehydration sore (see backup and recovery recommendations bellow)
- Configuration data, pertaining to things like JGroup Configuration, Resource Adapter configuration, Datasource Configuration, Adapter configuration, global fault policies, etc.
1.2. Metadata
BPEL stores the following metadata in a DB-based Metadata Repository (aka dehydration store, ORABPEL Schema)
- Process definition. This changes when a new process (packaged as BPEL Suitcase) is deployed.
- Process dehydrated state. This is the run time data generated when a process gets dehydrated.
1.3. BPEL Backup Recommendation
- After any configuration change to middle-tier (including changes to global fault policies, callback classes for workflows and resource bundles that can potentially be outside the suitcase) or ORACLE_HOME, take a middle-tier online backup.
- After deploying a new process or redeploying a proccess, for 10.1.2 release, take middle-tier backup as well as database repository backup at the same time. For 10.1.3 deployment taking database backup after new process deployment or redeployment is sufficient. Take periodic scheduled backup for DB Repositories.
1.4. BPEL Recovery Recommendation
Always ensure that metadata repository state is at a same or later point in time than middle-tier state.
- Database Repository Recovery: Always try to recover database to the most current state, using point-in-time recovery (if DB configured in Archive Log Mode). This will typically be a time right before the DB failure occurred. This ensures that latest process definitions and in flight instances are restored back. Please note that this may result in potential re-execution of process steps, based on the state to which the processes get recovered. It is recommended to strive for idempotent BPEL processes. If the system contains processes that are not idempotent these would need to be cleaned up from the dehydration store before starting the middle tiers post recovery. This is required to prevent their re-execution. Refer to BPEL PM Documentation for information on process’ clean up post recovery.
- Middle-tier Recovery: Recover to a time at or after last configuration change was performed. Some considerations to keep in mind:
New Processes:
- For 10.1.2 systems, new deployed processes need to be in sync in the DB and file system restore. This forces the midtier restore to be performed to any point in time that is posterior to the deployment of any new process that appears in the database restore. Possible data loss derived from (as it would be the case of forcing the database restore to a previous point in time to the last midtier backup available) can be minimized by applying the backup methodology recommended above.
- For 10.1.3 systems, middle tiers can be restored to any point containing configuration changes that are not process deployment since instances obtain the process definition and artifacts entirely from the database.
Re-deployed processes:
- For 10.1.2 systems if recovered middle-tier process definition for some reason is older than that in the database repository, then the in-flight instances of the newer processes, which got dehydrated in the database repository, will not execute after recovery. They will have to be manually removed.
- For 10.1.3 systems a DB recovery will ensure consistency between the dehydrated in-flight processes and their corresponding definition since the process definition is stored in DB repository where dehydrated instances get stored as well. A
2. ESB Backup and Recovery
ESB has following data elements from Backup and Recovery perspective:
2.1. Middle-tier configuration
ESB stores following configuration in middle-tier file system inside ORACLE_HOME on an Application Server Instance.
- Product binaries (which typically change with patching/upgrade)
- ESB Configuration data for OC4Js (Datasource configuration, Adapter configuration, Resource Adapter configuration etc. Specially, OH/integration/esb/config/ and OH/j2ee\home\application-deployments\esb-rt\esb-jca-rt\oc4j-ra.xml as they contain relevant ESB information.
2.2. Metadata
Following metadata gets stored in ESB repository (ORAESB Schema):
- Cluster definitions: ESB RT reads cluster name from esb_config.ini and then uses that value to query database to get systems for that cluster.
- System definitions, Service Definitions, End Point Definitions etc. This gets created/changed whenever a new system/service/end point etc. is created or modified.
- JMS messages for Asynchronous ESB Calls. This gets created/changed with every asynchronous service invocation.
2.3. ESB Backup Recommendation
- After any configuration change to middle-tier ORACLE_HOME, take a middle-tier backup.
- After deploying a new system, creating a cluster, creating an end point etc, take a database repository backup and midtier backup, specially esb_config.ini Take periodic scheduled backup for DB Repositories.
2.4. ESB Recovery Recommendation
- DB Recovery : Always try to recover database to the most current state, using point-in-time recovery (if DB configured in Archive Log Mode). This will typically be a time right before the DB failure occurred.
- Middle-tier recovery : Recover to a time at or after last configuration change was performed.
3. OWSM Backup and Recovery
OWSM has following data elements from Backup and Recovery perspective
3.1. Middle-tier configuration
OWSM stores following configuration in middle-tier file system inside ORACLE_HOME on an Application Server Instance.
- Product binaries (which typically change with patching/upgrade)
- Configuration for Gateways, Agents etc.
- Protected applications which get deployed on OC4Js
OWSM stores following metadata in a DB based Metadata Repository (ORAWSM Schema):
- Configuration data pertaining to deployed components like Gateways, Agents etc.
- Policies pertaining to deployed applications (Policy Manager). This data
- Runtime metric (monitor, like requests processed, how many success, how many failure etc. This data gets generated with every request)
3.3. OWSM Backup Recommendation
- After any configuration change to middle-tier ORACLE_HOME, take a middle-tier online backup. At the same time take DB Repository backup.
- Take periodic scheduled backup for DB Repositories.
3.4. OWSM Recovery Recommendation
Always ensure that metadata repository state is at a same or later point in time than middle-tier state.
- DB Recovery : Recover database to the most current state, using point-in-time recovery (if DB configured in Archive Log Mode). This will typically be a time right before the DB failure occurred.
- Middle-tier recovery : Recover to a time at or after last configuration change was performed.
Backup and Recovery Tools
Middle-tier backups can be performed using Oracle Fusion Middleware Backup and Recovery tool. Please refer to Admin Guide in product documentation for more information.
Oracle Fusion Middleware BR Tool also supports DB backups. Optionally, RMAN can be used for Database backups as well. Please refer to Oracle Database documents for further details on RMAN.
Oracle Fusion Middleware backups for both middle-tier and database can be performed in online mode. Offline Backup mode can be considered if there are any custom application requirements.
No comments:
Post a Comment