|Oracle® Fusion Applications Administrator's Guide
11g Release 6 Refresh 4 (11.1.6)
Part Number E14496-14
|PDF · Mobi · ePub|
This chapter describes how to configure and manage a highly available Oracle Enterprise Scheduler environment.
This appendix includes the following topics:
A highly available cluster of Oracle Enterprise Scheduler servers is recommended for optimal job performance. This is especially useful for running asynchronous jobs remotely, which may require returning a status message upon completion.
For example, suppose an asynchronous Oracle ADF Business Components job runs remotely. Oracle Enterprise Scheduler expects the job to send a status upon completion using a web services callback. If Oracle Enterprise Scheduler runs on only one node, if that node is down, the callback message does not arrive and the status of the job is unknown. The job would then require manual intervention to mark its status as complete.
A two node cluster, however, allows all callbacks to process and arrive at their destination even if one server is down. A clustered Oracle Enterprise Scheduler environment allows callbacks to be delivered as required, and jobs to complete with the correct status automatically assigned by the system.
The main steps required for configuring a highly available Oracle Enterprise Scheduler environment are as follows:
Use the Oracle Fusion Applications Install and Configuration Wizard to set up a domain and configure a cluster.
Add nodes to the cluster as required in order to enhance scalability, allowing more processing power for jobs.
When a cluster node is added, the new node's processor configuration might have to be adjusted to assign appropriate work assignments.
For more information, see the Oracle WebLogic Server documentation.
Configure the load balancer. For more information, see the Oracle HTTP Server documentation.
For information about troubleshooting an Oracle Enterprise Scheduler cluster, see the following chapters:
In order to configure an Oracle Enterprise Scheduler environment, it helps to understand concepts such as the architecture of Oracle Enterprise Scheduler, its components and life cycle.
For more information about Oracle Enterprise Scheduler architecture, components, life cycle and life cycle tools, see the section "Oracle Enterprise Scheduler Concepts" in the chapter "High Availability for Oracle Enterprise Scheduler" in Oracle Fusion Middleware Administrator's Guide for Oracle Enterprise Scheduler.
In order to enable a highly available environment, it is recommended to run Oracle Enterprise Scheduler in a cluster of at least two nodes.
This section includes the following topics:
For more information about cluster architecture, failover requirements, scalability, and load balancing for Oracle Enterprise Scheduler, see the section "Configuring High Availability for Oracle Enterprise Scheduler" in the chapter "High Availability for Oracle Enterprise Scheduler" in Oracle Fusion Middleware Administrator's Guide for Oracle Enterprise Scheduler.
Configuration files are as follows:
ess.xml: This file is part of the Oracle Enterprise Scheduler EAR file deployed to the Oracle Enterprise Scheduler cluster.
connections.xml: This file is part of the Oracle Enterprise Scheduler EAR file deployed to the Oracle Enterprise Scheduler cluster. This file is used only with Oracle Enterprise Scheduler deployments running in an Oracle Fusion Applications environment.
MDS repository: The Oracle Metadata repository stores Oracle Enterprise Scheduler job metadata. Oracle Enterprise Scheduler supports both database and file-based MDS repositories.
Deployment artifacts are as follows:
J2EE application for core runtime and hosting applications.
Job metadata within Oracle MDS for core runtime and jobs loaded at startup.
The Oracle WebLogic Server deployment is non-staged.
Use standard Oracle WebLogic Server logging for an Oracle Enterprise Scheduler cluster. Use logs in Oracle WebCenter Content to examine Oracle Enterprise Scheduler behavior. Oracle Enterprise Scheduler logging is configured by default in Oracle WebLogic Server.
The default location for log files for Oracle Enterprise Scheduler spawned jobs on UNIX servers is
/tmp/ess/requestFileDirectory. Oracle Enterprise Scheduler operational log files can be found under
-diagnostic.log on Windows.
Following are the backup and recovery guidelines for various components:
Components stored on the file system: Product binaries, deployed application EAR files and standard Oracle WebLogic Server files in the domain root.
Changes to the file system: The file system artifacts change when new EAR files are deployed or when the product is patched.
Data stored in the database: The database stores all metadata and runtime data.
Changes to database artifacts: Metadata changes when metadata is created and deployed from Oracle JDeveloper or Fusion Applications Control. Run time data changes when jobs are submitted, undergo state changes, and so on.
There is no consistency requirement between the artifacts stored on the file system and those in database. The file system stores EAR files and temporarily stores scheduled job output and log files. Job output and log files are saved to Oracle WebCenter Content upon job completion. Only one database is used, and two phase commit is not used in an Oracle Fusion Applications environment.
Managing an Oracle Enterprise Scheduler cluster involves starting the cluster, propagating configuration changes throughout the cluster, deploying applications and handling unexpected behavior.
For more information about managing an Oracle Enterprise Scheduler cluster, see the section "Managing an Oracle Enterprise Scheduler Cluster" in the chapter "High Availability for Oracle Enterprise Scheduler" in Oracle Fusion Middleware Administrator's Guide for Oracle Enterprise Scheduler.
Regarding failures in Oracle Java Transaction API migration and Oracle Java Message Service (JMS), Oracle JTA migration is unnecessary. When a node fails, there is no need to failover the node on another machine. Oracle Fusion Applications uses Oracle Enterprise Scheduler in a way does not require JTA recovery.
Oracle Enterprise Scheduler does not use Oracle Java Message Service (JMS) such that JMS recovery is not needed.