| Oracle® Application Server Disaster Recovery Guide 10g Release 3 (10.1.3.3.0) Part Number E12297-02 |
|
|
View PDF |
| Oracle® Application Server Disaster Recovery Guide 10g Release 3 (10.1.3.3.0) Part Number E12297-02 |
|
|
View PDF |
This chapter provides an introduction to the Oracle Application Server Disaster Recovery solution.
It contains the following topics:
This section provides an overview of Oracle Application Server Disaster Recovery.
It contains the following topics:
Providing Maximum Availability Architecture is one of the key requirements for any Oracle Application Server Enterprise Deployment. Oracle Application Server includes an extensive set of High Availability features such as: Process Death Detection and Restart, Server Clustering, Load Balancing, Failover, Backup and Recovery, Rolling Upgrades, Rolling Configuration Changes, and Dynamic Discovery, which protect an Enterprise Deployment from unplanned down time and minimize planned downtime.
Additionally, Enterprise Deployments need protection from unforeseen disasters and natural calamities. One protection solution involves setting up a standby site at a geographically different location than the production site. The standby site may have equal or fewer services and resources compared to the production site. Application data, metadata, configuration data, and security data are replicated to the standby site on a periodic basis. The standby site is normally in a passive mode; it is started when the production site is not available. This deployment model is sometimes referred to as an active/passive model. This model is normally adopted when the two sites are connected over a WAN and network latency does not allow clustering across the two sites.
A core strategy for and a key feature of Oracle Application Server is Hot-Pluggability. Built for the heterogeneous enterprise, Oracle Application Server consists of modular component software that runs on a range of popular platforms and interoperates with middleware technologies and business applications from other software vendors such as IBM, Microsoft, and SAP. For instance, Oracle Application Server products and technologies such as ADF, Oracle BPEL Process Manager, Oracle Enterprise Service Bus, Oracle Web Services Manager, Adapters, Oracle Access Manager, Oracle Identity Manager, Rules, Oracle TopLink, and Oracle Business Intelligence Publisher can run on non-Oracle containers such as BEA Weblogic, IBM Websphere and JBoss, in addition to running on Oracle's container (OC4J).
The Oracle Application Server Disaster Recovery solution uses disk replication technology for disaster protection of Oracle Application Server middle tier components. It supports Hot-Pluggable deployments, and it is compatible with third party vendor recommended solutions.
Disaster protection for Oracle databases that are included in your Oracle Application Server is provided through Oracle Data Guard.
This document describes how to deploy the Oracle Application Server Disaster Recovery solution for an enterprise deployment, making use of disk replication technology and Oracle Data Guard technology.
The solution described in this document is a symmetric Oracle Application Server Disaster Recovery topology, which can be set up for Linux and UNIX operating systems.
This section defines the following Disaster Recovery terminology:
Application Server host name: This guide differentiates between the terms Application Server host name and network host name.
The Application Server host name is the host name that Oracle Application Server uses for the host when Oracle Application Server is configured on the host. During installation, the installer automatically retrieves the Application Server host name from the current host and stores it in the Oracle Application Server configuration metadata on disk. A host can have only one Application Server host name.
See also the network host name definition later in this section.
asymmetric topology: A disaster recovery configuration that is different across tiers on the production site and standby site. In an asymmetric topology, the standby site can use less hardware (for example, the production site could include four hosts with four Application Server instances while the standby site includes two hosts with four Application Server instances. Or, in a different asymmetric topology, the standby site can use fewer Application Server instances (for example, the production site could include four Application Server instances while the standby site includes two Application Server instances). Another asymmetric topology might include a different configuration for a database (for example, using a Real Application Clusters database at the production site and a single instance database at the standby site). Appendix C, "Creating an Asymmetric Topology" describes asymmetric topologies.
Disaster Recovery: The ability to safeguard against natural or unplanned outages at a production site by having a recovery strategy for applications and data to a geographically separate standby site.
network host name: A host name assigned to an IP address that is resolved through DNS resolution. The network host name is the host name by which a particular host is known within the host's network. A host can have the same network host name and Application Server host name. A host can have only one Application Server host name, but it can have multiple network host names.
See also the Application Server host name definition later in this section.
production site setup: The process of creating the production site. To create the production site using the procedure described in this manual, you must plan and create Application Server host names and network host names, create mount points and links on the hosts to the Oracle home directories on the shared storage where the Oracle Application Server instances will be installed, install the binaries and instances, and deploy the applications.
site failover: The process of making the current standby site the new production site after the production site becomes unexpectedly unavailable (for example, due to a disaster at the production site). This book also uses the term "failover" to refer to a site failover.
site switchover: The process of reversing the roles of the production site and standby site. Switchovers are planned operations done for periodic validation or to perform planned maintenance on the current production site. During a switchover, the current standby site becomes the new production site, and the current production site becomes the new standby site. This book also uses the term "switchover" to refer to a site switchover.
site synchronization: The process of applying changes made to the production site at the standby site. For example, when a new application is deployed at the production site, you should perform a synchronization so that the same application will be deployed at the standby site, also.
standby site setup: The process of creating the standby site. To create the standby site using the procedure described in this manual, you must plan and create Application Server host names and network host names, perform a switchover operation (which replicates the Oracle home directories and installations from the production site shared storage to the standby site shared storage), and create mount points and links to the Oracle home directories on the standby shared storage.
symmetric topology: An Oracle Application Server Disaster Recovery configuration that is completely identical across tiers on the production site and standby site. In a symmetric topology, the production site and standby site have the identical number of hosts, load balancers, instances, and applications. The same ports are used for both sites. The systems are configured identically and the applications access the same data. This manual describes how to set up a symmetric Oracle Application Server Disaster Recovery topology for an enterprise configuration.
topology: The production site and standby site hardware and software components that comprise an Oracle Application Server Disaster Recovery solution.
This section provides an introduction to setting up Disaster Recovery for a common Oracle Application Server enterprise deployment.
It contains the following topics:
Oracle Application Server Disaster Recovery Architecture Overview
Disaster Recovery Recommendations for Oracle Application Server Components
This section describes the deployment architecture for Oracle Application Server components.
The product binaries and configuration for Oracle Application Server components and applications gets deployed in Oracle home directories on the middle tier. Additionally, most of the products also have metadata or run-time data stored in a database repository.
Therefore, the Oracle Application Server Disaster Recovery solution keeps middle tier file system data and middle tier data stored in databases at the production site synchronized with the standby site.
The Oracle Application Server Disaster Recovery solution supports these methods of providing data protection for Oracle Application Server data and database content:
Oracle Application Server product binaries, configuration, and metadata files
Use disk replication technologies.
Database content
Use Oracle Data Guard for Oracle databases (and vendor-recommended solutions for third party databases).
Figure 1-1 shows an overview of an Oracle Application Server Disaster Recovery topology:
Figure 1-1 Production and Standby Site for Oracle Application Server Disaster Recovery Topology
Some of the key aspects of the solution in Figure 1-1 are:
The solution has two sites. The current production site is running and active, while the second site is serving as a standby site and is in passive mode.
Hosts on each site have mount points defined for accessing the shared storage system for the site.
On both sites, the Oracle Application Server components are deployed on the site's shared storage system. This involves creating all the Oracle home directories, which include product binaries and configuration data for middleware components, in volumes on the production site's shared storage and then installing the components into the Oracle home directories on the shared storage. In Figure 1-1, a separate volume is created in the shared storage for each Oracle Application Server host cluster (note the Web, Application, and Security volumes created for the Web Cluster, Application Cluster, and Security Cluster in each site's shared storage system).
Mount points need to be created on the shared storage for the production site. The Oracle Application Server software for the production site will be installed into Oracle home directories using the mount points on the production site shared storage. Symbolic links also need to be set up on the production site hosts to the Oracle Application Server home directories on the shared storage at the production site.
Mount points need to be created on the shared storage for the standby site. Symbolic links also need to be set up on the standby site hosts to the Oracle Application Server home directories on the shared storage at the standby site. The mount points and symbolic links for the standby site hosts must be identical to those set up for the equivalent production site hosts.
Disk replication technology is used to copy the middle tier file systems and other data from the production site's shared storage to the standby site's shared storage.
After disk replication is enabled, application deployment, configuration, metadata, data, and product binary information is replicated from the production site to the standby site.
It is not necessary to perform any Oracle software installations at the standby site hosts. When the production site storage is replicated at the standby site storage, the equivalent Oracle home directories and data are written to the standby site storage.
Schedule incremental replications at a specified interval. The recommended interval is once a day for the production deployment, where the middle tier configuration does not change very often. Additionally, you should force a manual synchronization whenever you make a change to the middle tier configuration at the production site (for example, if you deploy a new application at the production site).
Before forcing a manual synchronization, you should take a snapshot of the site to capture its current state. This ensures that the snapshot gets replicated to the standby site storage and can be used to roll back the standby site to a previous synchronization state, if desired. Recovery to the point of the previously successful replication (for which a snapshot was created) is possible when a replication fails.
Oracle Data Guard is used to replicate all Oracle database repositories, including Oracle Application Server repositories and custom application databases. For information about using Oracle Data Guard to provide disaster protection for Oracle databases, see Section 2.2.1, "Database Considerations."
If your Oracle Application Server Disaster Recovery topology includes any third party databases, use the vendor-recommended solution for those databases.
User requests are initially routed to the production site.
When there is a failure or planned outage of the production site, you perform the following steps to enable the standby site to assume the production role in the topology:
Stop the replication from the production site to the standby site (when a failure occurs, replication may have already been stopped due to the failure).
Perform a failover or switchover of the Oracle databases using Oracle Data Guard.
Start the services and applications on the standby site.
Use a global load balancer to re-route user requests to the standby site. At this point, the standby site has assumed the production role.
The Oracle Application Server Disaster Recovery solution is supported for some Oracle Application Server components from these releases:
Oracle Application Server 10.1.3 release
Oracle Application Server 10.1.4.x Identity Management releases
Oracle Application Server 10.1.2.x releases
Table 1-1 shows the components and applications for Oracle Application Server releases 10.1.3, 10.1.4, and 10.1.2.x Identity Management that are supported by Oracle Application Server Disaster Recovery:
Table 1-1 Oracle Application Server Components and Applications Supported by Oracle Application Server Disaster Recovery
| Component/Application | Oracle Application Server 10.1.3 | Oracle Application Server 10.1.4.x | Oracle Application Server 10.1.2.x |
|---|---|---|---|
|
Oracle Web Cache |
N/A |
N/A |
Y |
|
Oracle HTTP Server |
Y |
Y |
Y |
|
Oracle Containers for J2EE (OC4J) |
Y |
Y |
Y |
|
Oracle BPEL Process Manager |
Y |
N/A |
N |
|
Oracle Enterprise Service Bus |
Y |
N/A |
N/A |
|
Oracle Web Services Manager |
Y |
N/A |
N/A |
|
Oracle B2B |
N/A |
N/A |
Y |
|
Oracle Business Activity Monitoring |
Y |
N/A |
N/A |
|
Oracle Business Intelligence |
N |
N/A |
N/A |
|
Oracle Identity Management (Oracle Internet Directory, Oracle Single Sign-On) |
N/A |
Y |
N |
|
Oracle Access ManagerFoot 1 |
N/A |
Y |
N/A |
|
Oracle Virtual Directory, Oracle Identity Manager |
N/A |
N |
N |
|
Oracle Discoverer, Oracle Forms, Oracle Reports, Oracle Wireless |
N/A |
N/A |
Y |
|
Oracle Portal |
N/A |
Y |
Y |
Footnote 1 Oracle Access Manager ships as part of Oracle Identity Management releases instead of with Oracle Application Server releases.
The following sections describe the disaster protection requirements for different Oracle Application Server components and provides recommendations for synchronizing these components. As mentioned previously, use disk replication to synchronize middle tier content stored in Oracle home directories, and use Oracle Data Guard to synchronize data in Oracle database repositories or custom application databases included in your Oracle Application Server Disaster Recovery topology.
This section describes the Oracle Web Cache data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Web Cache server includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Web Cache is patched or upgraded.
Product configuration
This includes items such as internal.xml, webcache.xml, custom error pages, log files (which can be logged by Oracle Enterprise Manager for end user performance monitoring), and SSL wallets, which are updated when administrative operations (such as creating a new site definition, creating new origin servers, changing port numbers, configuring SSL, and so on) are performed.
Database Repository Dependencies
Oracle Web Cache does not store any configuration information in a database repository. There is no associated database repository.
Recommendations
For Oracle Application Server Disaster Recovery, a middle tier synchronization should be manually forced whenever a change is made to the Oracle Web Cache middle tier file system through operations such as patching, upgrades, and configuration changes.
This section describes the Oracle HTTP Server data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle HTTP Server includes the following in the middle tier file system:
Product binaries
These typically change when Oracle HTTP Server is patched or upgraded.
Product configuration
This includes files such as httpd.conf, ssl.conf, and mod_oc4j.conf, which are updated when administrative operations (such as changing port numbers, changing the number of clients, creating virtual hosts, registering Oracle Single Sign-On, configuring SSL, and so on) are performed.
If you are using Oracle Single Sign-On or Oracle Internet Directory with Oracle HTTP Server, read the recommendations for those components in Section 1.2.3.10, "Disaster Recovery Recommendations for Oracle Single Sign-On" and Section 1.2.3.9, "Disaster Recovery Recommendations for Oracle Internet Directory."
Static HTML pages
This content is deployed by administrators and is typically maintained outside the Oracle home directories. Make sure that the static HTML files are stored on the same shared storage as the Oracle HTTP Server installation so that it can be replicated from the production site to the standby site.
Database Repository Dependencies
Oracle HTTP Server has the following database dependencies:
For 10.1.3 releases, all of Oracle HTTP Server's configuration is stored in the Oracle home on the middle tier files system. There is no associated database repository.
For 10.1.2.x releases, Oracle HTTP Server is additionally maintained in the DCM repository in the Metadata Repository database. Thus, changes in this repository need to be replicated to the standby site's repository.
Recommendations
For Oracle Application Server Disaster Recovery, a middle tier synchronization should be manually forced whenever a change is made to the Oracle HTTP Server middle tier configuration at the production site.
Additionally, for 10.1.2.x releases, Oracle Data Guard should be configured for Oracle database Metadata Repositories (as described later in Section 2.2.1, "Database Considerations"). Also for 10.1.2.x releases, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle Containers for J2EE (OC4J) data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
OC4J includes the following in the middle tier file system:
Product binaries
These typically change when OC4J is patched or upgraded.
Container configuration
This includes parameters such as JVM heap size, number of processes, replication configuration, creation of new web sites, port changes, and SSL configuration.
Resource binding
This includes container level configuration parameters such as data-source configuration, resource adapter configuration, and creation of JMS queues.
Deployed applications
This includes the binaries of the deployed applications and their related artifacts.
Database Repository Dependencies
OC4J has the following database dependencies:
For 10.1.3 releases, all of the OC4J configuration is stored in the middle tier. There is no associated database repository.
For 10.1.2.x releases, OC4J configuration is also maintained in the DCM repository in the Metadata Repository database. Thus, changes in this repository need to be replicated to the standby site's repository.
Recommendations
For OC4J, a middle tier synchronization should be manually forced whenever a change is made to the OC4J middle tier file system. Changes to the OC4J middle tier file system include events such as configuration changes, resource binding changes, and application deployments.
For 10.1.2.x releases, Oracle Data Guard should be configured for Oracle database Metadata Repositories (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle BPEL Process Manager data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle BPEL Process Manager includes the following in the middle tier file system:
Product binaries
These typically change when Oracle BPEL Process Manager is patched or upgraded.
Process definitions
For 10.1.2.x releases only, the process definitions in deployable BPEL suitcases are maintained on middle tier file systems and copied to an Oracle database repository. Thus, when a new process is deployed, the middle tier file system is updated.
For 10.1.3 and later releases, when a suitcase is deployed to a BPEL Process Manager instance, the engine picks up the suitcase.jar file, writes it to the ORABPEL schema in the dehydration store database, and 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 consequence. All successfully loaded processes are copied to the dehydration store and removed from the middle tier file system. During engine startup, the deployed suitcases are downloaded from the dehydration store and unzipped on the middle tier file system.
Configuration data
This includes JGroup configuration, resource adapter configuration, data source configuration, adapter configuration, and global fault policies.
Database Repository Dependencies
Oracle BPEL Process Manager stores the following metadata in the Oracle database dehydration store:
Process definition
The process definition changes when a new process is deployed.
Process dehydrated state
This is the run-time data generated when a process is dehydrated.
For 10.1.2.x releases, OC4J configuration is also maintained in the DCM repository in the Oracle database Metadata Repository.
Changes in these repositories need to be replicated to the standby site's repositories.
Recommendations
For Oracle BPEL Process Manager, a middle tier synchronization should be manually forced whenever a change is made to the Oracle BPEL Process Manager middle tier file system. Changes to the Oracle BPEL Process Manager middle tier file system occur when you apply patches, deploy suitcases, change container configuration, change resource bindings, and deploy applications.
Oracle Data Guard should be configured for Oracle database Metadata Repositories (as described later in Section 2.2.1, "Database Considerations").
For 10.1.2.x releases, after deploying a new process, you should manually force a middle tier synchronization. You should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
For 10.1.3 releases, if new process definitions are propagated in Oracle BPEL Process Manager, you do not need to manually force a middle tier synchronization. You only need to manually force a database synchronization using Oracle Data Guard.
This section describes the Oracle Enterprise Service Bus data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Enterprise Service Bus includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Enterprise Service Bus is patched or upgraded.
Oracle Enterprise Service Bus configuration data for OC4J
This includes configuration data such as data source configuration, adapter configuration, and resource adapter configuration. Oracle Enterprise Service Bus cluster information is obtained from information in the repository at run time.
Database Repository Dependencies
Oracle Enterprise Service Bus stores the following metadata in its repository (ORAESB schema):
Definitions such as system definitions, service definitions, and end point definitions. These get created or modified whenever a system, service, or end point is created or modified.
JMS messages for asynchronous Oracle Enterprise Service Bus calls. These messages get created or updated with every asynchronous service invocation.
In addition to storing JMS messages from asynchronous service invocations, database based JMS topics are used by Oracle Enterprise Service Bus to store error messages, retried messages, and instance tracking messages.
Changes in this repository need to be replicated to the standby site's repository.
Recommendations
For Oracle Enterprise Service Bus, a middle tier synchronization should be manually forced whenever a change is made to the Oracle Enterprise Service Bus middle tier configuration. Changes to the Oracle Enterprise Service Bus middle tier configuration include events such as applying patches, performing upgrades, configuration changes, and resource binding changes.
Oracle Data Guard should be configured for the Oracle database Metadata Repositories for Oracle Enterprise Service Bus (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle Web Services Manager (Oracle WSM) data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle WSM includes the following in the middle tier file system:
Product binaries
These typically change when Oracle WSM is patched or upgraded.
Configuration for gateways and agents
Protected applications which get deployed on OC4Js
Database Repository Dependencies
Oracle WSM stores the following metadata in an Oracle database Metadata Repository (ORAWSM schema):
Configuration data pertaining to deployed components, such as gateways and agents
Policies pertaining to deployed applications (Policy Manager)
Run-time metrics, which include metrics such as the number of requests processed, successful requests, and failed requests. These metrics are generated with every request.
Changes in this repository need to be replicated to the standby site's repository.
Recommendations
For Oracle WSM, a middle tier synchronization should be manually forced whenever a change is made to the Oracle WSM middle tier file system. Changes to the Oracle WSM middle tier file system occur when you apply patches, perform upgrades, change gateway or agent onfiguration, change container level configuration, deploy applications, and change resource bindings.
Oracle Data Guard should be configured for the Oracle database Metadata Repositories for Oracle WSM (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle B2B data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle B2B includes the following in the middle tier file system:
Product binaries
These typically change when Oracle B2B is patched or upgraded.
Configuration data
This includes tip.properties configuration for Oracle B2B.
Database Repository Dependencies
Oracle B2B stores the following metadata in the Oracle database store:
B2B metadata:
This includes the document, trading partner and agreement metadata.
B2B run-time data:
This is the run-time data generated when a message is processed through B2B.
Changes in the database store need to be replicated to the standby site's database store.
Recommendations
For Oracle B2B, a middle tier synchronization should be manually forced whenever a change is made to the Oracle B2B middle tier file system. Changes to the Oracle B2B middle tier file system occur when you apply patches, deploy suitcases, change container configuration, change resource bindings, and deploy applications.
Oracle Data Guard should be configured for the Oracle database store (as described later in Section 2.2.1, "Database Considerations").
This section describes the Oracle Business Activity Monitoring data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Business Activity Monitoring includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Business Activity Monitoring is patched or upgraded.
Configuration data
This includes configuration data such as logging configuration and database connection configuration.
In Oracle Application Server 10.1.x releases, all Oracle Business Activity Monitoring data is stored in database repositories, therefore Oracle Business Activity Monitoring data protection will not be performed using disk replication.
Because disk replication is not used for Oracle Business Activity Monitoring in 10.1.x releases, when you install Oracle Business Activity Monitoring at the production site, you must perform an identical Oracle Business Activity Monitoring installation at the standby site (by specifying the same Oracle home name, the same Oracle home directory and path name, and the same configuration options).
If you patch a Oracle Business Activity Monitoring installation on the production site, you must patch the peer Oracle Business Activity Monitoring installation on the standby site.
Database Repository Dependencies
The following Oracle Business Activity Monitoring data is stored in the Oracle database store:
Reports, alerts, users, roles, distribution lists, security filters, parameters, message source data, lookup data, alert history, and other data.
These definitions change when any modifications or new artifacts are created.
Recommendations
See Section B, "Setting Up Oracle Business Activity Monitoring" for the steps to follow to set up Oracle Business Activity Monitoring properly in an Oracle Application Server Disaster Recovery topology.
This section describes the Oracle Internet Directory data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Internet Directory includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Internet Directory is patched or upgraded.
Oracle Internet Directory configuration
This includes items such as the TNSNAMES.ORA file used for database access, the SQLNET.ORA file, and wallet configuration.
Database Repository Dependencies
Oracle Internet Directory stores the following in an Oracle database repository:
All of its user data
Configuration data (such as the different LDAP server instances to run and Directory Integration Platform configuration information)
Changes in this repository need to be replicated to the standby site's repository.
Recommendations
For Oracle Internet Directory, a middle tier synchronization should be manually forced whenever a change is made to the Oracle Internet Directory middle tier file system. Changes to the Oracle Internet Directory middle tier configuration occur when you apply patches, perform upgrades, and make configuration changes for Oracle Internet Directory.
Note:
If your deployment uses only Oracle Internet Directory and Single Sign-On Server and no other Oracle Application Server components or applications, then you can consider using multimaster replication as a Disaster Recovery solution. However, if your deployment includes other Oracle Application Server components or applications in addition to Oracle Internet Directory and Single Sign-On Server, then you should use disk replication for the Disaster Recovery solution. See the "Deploying Identity Management with Multimaster Replication" chapter in the Oracle Application Server High Availability Guide for Oracle Application Server 10.1.4.0.1 for more information about multimaster replication.Oracle Data Guard should be configured for the Oracle database repositories used by Oracle Internet Directory (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle Single Sign-On data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Single Sign-On includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Single Sign-On is patched or upgraded.
Oracle HTTP Server configuration
This includes items described in Section 1.2.3.2, "Disaster Recovery Recommendations for Oracle HTTP Server" such as mod_osso configuration files for partner application registration, SSL configuration (if SSL is enabled), and location of wallet files.
OC4J_Security configuration
This includes items described in Section 1.2.3.3, "Disaster Recovery Recommendations for Oracle Containers for J2EE" such as state replication for Delegated Administration Services, data source configuration, and changes made to iasconfig.xml.
Database Repository Dependencies
Oracle Single Sign-On stores the following in an Oracle database Metadata Repository:
Oracle Single Sign-On metadata
Metadata, which includes metadata for registered partner applications and external application configuration, is stored in the ORASSO schema in the Oracle Internet Directory Metadata Repository. See also the recommendations for Oracle Internet Directory in Section 1.2.3.9, "Disaster Recovery Recommendations for Oracle Internet Directory."
Oracle HTTP Server and OC4J configuration data is stored in the DCM repository in the Oracle database Metadata Repository.
Changes in these repositories need to be replicated to the standby site's repositories.
Recommendations
For Oracle Single Sign-On, a middle tier synchronization should be manually forced whenever a change is made to the Oracle Single Sign-On middle tier file system. Changes to the Oracle Single Sign-On middle tier configuration occur when you apply patches, perform upgrades, and make configuration changes for Oracle Single Sign-On.
Oracle Data Guard should be configured for Oracle database Metadata Repositories used by Oracle Internet Directory (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle Access Manager data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Access Manager includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Access Manager is patched or upgraded.
Oracle Access Manager configuration data
The Oracle Access Manager configuration data store is centralized in a LDAP server directory.
The Oracle Access Manager components read configuration data from .xml files automatically generated out of the configuration store.
These typically change whenever configurations changes are made through the Policy Manager or when it is necessary to edit the .xml files directly.
Oracle Access Manager policy data
This is located in an LDAP directory server which could be the same LDAP directory server as used for Oracle Access Manager configuration.
This changes when policy configuration changes are made through the Policy Manager.
Audit data is generated either into files or into the database
This is added to as users authenticate or access protected resources.
Recommendations
For Oracle Access Manager, a middle tier synchronization should be manually forced whenever a change is made to the Oracle Access Manager middle tier file system. Changes to the Oracle Access Manager middle tier configuration occur as a result of applying patches, performing upgrades, and making configuration changes for Oracle Access Manager.
Oracle Data Guard should be configured for the Oracle database repositories used by Oracle Access Manager directly (for audit data only), as described later in Section 2.2.1, "Database Considerations." Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle Discoverer data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Discoverer includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Discoverer is patched or upgraded.
Oracle HTTP Server configuration (if it is installed in the same Oracle home directory as Oracle Discoverer)
This includes items described in Section 1.2.3.2, "Disaster Recovery Recommendations for Oracle HTTP Server" such as mod_osso configuration files for partner application registration, SSL configuration (if SSL is enabled), and location of wallet files.
OC4J configuration
This includes items described in Section 1.2.3.3, "Disaster Recovery Recommendations for Oracle Containers for J2EE" and Oracle Discoverer product configuration which includes items such as End User Layer database configuration and the Oracle Discoverer preference store.
Database Repository Dependencies
Oracle Discoverer stores the following in an Oracle database repository:
Oracle Discoverer End User Layer
Configuration for components generated by Oracle Discoverer
The configuration for items such as database connections, workbooks, and worksheets is stored in the database.
Changes in this repository need to be replicated to the standby site's repository.
Recommendations
For Oracle Discoverer, a middle tier synchronization should be manually forced whenever a change is made to the Oracle Discoverer middle tier configuration. Changes to the Oracle Discoverer middle tier configuration occur when you apply patches, perform upgrades, and change the configuration for Oracle Discoverer components.
Oracle Data Guard should be configured for the Oracle database Metadata Repositories for Oracle Discoverer (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle Forms data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Forms includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Forms is patched or upgraded.
Oracle Forms server configuration
The Oracle Forms server configuration is stored in configuration files such as formsweb.cfg under the forms/server directory in the Oracle home. Oracle Forms configuration includes items such as servlet configuration, Oracle Single Sign-On configuration, and HTML templates to use.
If you are using Oracle Single Sign-On or Oracle Internet Directory with Oracle Forms, read the recommendations for those components in Section 1.2.3.9, "Disaster Recovery Recommendations for Oracle Internet Directory" and Section 1.2.3.10, "Disaster Recovery Recommendations for Oracle Single Sign-On."
Oracle Forms deployment artifacts
Oracle Forms can create special files such as .fmx and .fmb files outside the Oracle home directory. The location of these Oracle Forms files is typically configured on each middle tier using the FORMS_PATH variable. When you are using Oracle Forms as part of an Oracle Application Server Disaster Recovery topology, these special files and artifacts of Oracle Forms should be created in the Oracle home.
OC4J configuration
This includes files such as web.xml, orion-web.xml, and application.xml. Read the recommendations for OC4J in Section 1.2.3.3, "Disaster Recovery Recommendations for Oracle Containers for J2EE."
Oracle HTTP Server configuration
This includes files such as forms.conf. Read the recommendations for Oracle HTTP Server in Section 1.2.3.2, "Disaster Recovery Recommendations for Oracle HTTP Server."
Database Repository Dependencies
Oracle Forms server does not require a database repository. However, Oracle Forms server is typically used to query and modify customer data in customer databases, which should be properly protected.
Recommendations
For Oracle Forms server, a middle tier synchronization should be manually forced whenever a change is made to the Oracle Forms middle tier file system. Changes to the Oracle Forms middle tier file system occur when you apply patches, perform upgrades, and change the configuration for the Oracle Forms server component.
When you are using Oracle Reports with Oracle Forms, you should manually force a middle tier synchronization whenever a change is made to either the Oracle Forms or Oracle Reports configuration. Read the recommendations for Oracle Reports in Section 1.2.3.14, "Disaster Recovery Recommendations for Oracle Reports."
Oracle Data Guard should be configured for any application database used with an Oracle Forms application (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle Reports data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Reports includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Reports is patched or upgraded.
Oracle Reports server configuration
The Oracle Reports server configuration is stored in configuration files such as server_name.confg, rwnetwork.conf, and rwbuilder.conf under the reports/conf directory in the Oracle home. Oracle Reports configuration includes items such as initial settings for the Oracle Reports server cache, engine initialization, security, and cluster configuration.
Oracle Reports server job details for scheduled jobs, past jobs, and current jobs are stored in the <server-name>.dat file in the reports/server directory in the Oracle home.
If you are using Oracle Single Sign-On or Oracle Internet Directory with Oracle Reports, read the recommendations for those components in Section 1.2.3.9, "Disaster Recovery Recommendations for Oracle Internet Directory" and Section 1.2.3.10, "Disaster Recovery Recommendations for Oracle Single Sign-On."
Oracle Reports deployment artifacts
Oracle Reports can create special files such as .rdf files outside the Oracle home directory. The location of these Oracle Reports files is typically configured on each middle tier using the REPORTS_PATH variable. When you are using Oracle Reports as part of an Oracle Application Server Disaster Recovery topology, these special files of Oracle Reports should be created in the Oracle home.
OC4J configuration
The Oracle Reports servlet is deployed in the OC4J_BI_Forms container. Configuration pertaining to the Oracle Reports servlet is stored in the rwservlet.properties and cgicmd.dat files in the $ORACLE_HOME/reports/conf directory. These files should be protected. Also, if you have made any changes to OC4J-specific files for the OC4J_BI_Forms container (such as changes to web.xml, orion-web.xml, and application.xml), these files should also be protected. Read the recommendations for OC4J in Section 1.2.3.3, "Disaster Recovery Recommendations for Oracle Containers for J2EE."
Oracle HTTP Server configuration
This includes any configuration done specifically for the Oracle Reports application in addition to other Oracle HTTP Server-specific configuration. Read the recommendations for Oracle HTTP Server in Section 1.2.3.2, "Disaster Recovery Recommendations for Oracle HTTP Server."
Database Repository Dependencies
Oracle Reports server does not require a database repository. However, Oracle Reports custom applications can use a custom Oracle database repository. Data that Oracle Reports server uses for generating reports, as well as job status details, can be stored in the Oracle database repository.
Changes in this repository need to be replicated to the standby site's repository.
Recommendations
For Oracle Reports server, a middle tier synchronization should be manually forced whenever a change is made to the Oracle Reports middle tier file system. Changes to the Oracle Reports middle tier file system occur when you apply patches, perform upgrades, and make configuration changes for Oracle Reports server.
When you are using Oracle Forms with Oracle Reports, you should manually force a middle tier synchronization whenever a change is made to either the Oracle Reports or Oracle Forms configuration. Read the recommendations for Oracle Forms in Section 1.2.3.13, "Disaster Recovery Recommendations for Oracle Forms."
Oracle Data Guard should be configured for any application database used with an Oracle Reports application (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
This section describes the Oracle Portal data that must be protected as part of your Oracle Application Server Disaster Recovery solution.
Middle Tier Configuration
Oracle Portal includes the following in the middle tier file system:
Product binaries
These typically change when Oracle Portal is patched or upgraded.
Oracle Portal configuration
The Oracle Portal configuration is stored in configuration files such as dads.conf, plsql.conf, cache.conf, mod_oc4j.conf, cache.xml, portal.conf, portalReg.xml, portalconsoleConfigSNSegment.xml, and consoleConfigSNSegment.xml. Other configuration items such as the Oracle Internet Directory location are stored in other configuration files such as iasconfig.xml.
If you are using Oracle Single Sign-On or Oracle Internet Directory with Oracle Portal, read the recommendations for those components in Section 1.2.3.9, "Disaster Recovery Recommendations for Oracle Internet Directory" and Section 1.2.3.10, "Disaster Recovery Recommendations for Oracle Single Sign-On."
Oracle Portal provider registration configuration
The Oracle Portal provider registration configuration is stored in provider.xml files.
OC4J configuration
This includes files such as web.xml, orion-web.xml, and application.xml. Read the recommendations for OC4J in Section 1.2.3.3, "Disaster Recovery Recommendations for Oracle Containers for J2EE."
Oracle HTTP Server configuration
This includes security configuration for the Oracle Portal application in addition to other Oracle HTTP Server-specific configuration. Read the recommendations for Oracle HTTP Server in Section 1.2.3.2, "Disaster Recovery Recommendations for Oracle HTTP Server."
Oracle Web Cache configuration
This includes configuration items such as the site definition, site to server mapping, and origin servers. Read the recommendations for Oracle Web Cache in Section 1.2.3.1, "Disaster Recovery Recommendations for Oracle Web Cache."
Database Repository Dependencies
Oracle Portal stores all the page information, portlets, and content information in its Oracle database repository.
Changes in this repository need to be replicated to the standby site's repository.
Recommendations
A middle tier synchronization should be manually forced whenever a change is made to the Oracle Portal middle tier file system. Changes to the Oracle Portal middle tier file system occur when you apply patches, perform upgrades, and change configuration for the Oracle Portal component.
Oracle Data Guard should be configured for the Oracle database repository used by Oracle Portal (as described later in Section 2.2.1, "Database Considerations"). Also, you should manually force a database synchronization using Oracle Data Guard whenever a middle tier synchronization is manually forced.
|
 Copyright © 2008, Oracle. All rights reserved. Legal Notices |
|
