This essay explains what parallel concurrent processing is, describes the environments it runs in, and explains how it works.
Parallel concurrent processing allows you to distribute concurrent managers across multiple nodes in a cluster, massively parallel, or networked environment. Instead of operating concurrent processing on a single node while other nodes are idle, you can spread concurrent processing across all available nodes, fully utilizing hardware resources.
Parallel concurrent processing provides Oracle E-Business Suite users with the following benefits:
High performance - the ability to run concurrent processes on multiple nodes to improve concurrent processing throughput.
Fault Tolerance - the ability to continue running concurrent processes on available nodes even when one or more nodes fails.
Adaptability - the ability to integrate with platform-specific batch queue and load-balancing systems to maximize concurrent processing performance on a particular platform.
Single Point of Control - the ability to administer concurrent managers running on multiple nodes from any node in a cluster, massively parallel, or networked environment.
Parallel concurrent processing runs in multi-node environments, such as cluster, massively parallel, and networked environments. In these environments, each node consists of one or more processors (CPUs) and their associated memory. Each node has its own memory that is not shared with other nodes And each node operates independently of other nodes, except when sharing a resource such as a disk.
With parallel concurrent processing, one or more concurrent managers run on one or more nodes in a multi-node environment. You decide where concurrent managers run when configuring your system.
You can define any set of concurrent manager specialization rules, and apply them across nodes in any way desired. For example, three "Oracle General Ledger" concurrent managers could be spread across three nodes. Or an "Oracle Payables" concurrent manager and an "Oracle General Ledger" concurrent manager could run simultaneously on the same node.
The following are examples of environments in which parallel concurrent processing can run:
In a cluster environment, multiple computers, each representing a single node, share a common pool of disks.
With parallel concurrent processing in a cluster environment, a single ORACLE database resides in the common disk pool, while multiple instances of Real Application Clusters (RAC) run simultaneously on multiple nodes in the cluster. Multiple concurrent managers are also distributed across the nodes in the cluster.
In a massively parallel environment, multiple nodes are housed in a single computer. All nodes share access to a common pool of disks. The IBM SP/2, for example, is a massively parallel computer.
With parallel concurrent processing in a massively parallel environment, separate RAC instances run simultaneously on multiple nodes, with multiple concurrent managers also distributed across nodes.
In networked environments, multiple computers of the same type are connected via a local area network (LAN) to a single database server, or alternatively, to a cluster of database servers.
For example, a simple networked environment could consist of multiple Sun SPARCstations connected via a LAN to a single Sequent server. In a more complex networked environment, multiple Sun SPARCstations could connect to a cluster of Sequent servers.
With parallel concurrent processing in a networked environment, concurrent managers run on multiple workstations. A single database server runs a single instance of ORACLE; or, a cluster of database servers runs multiple ORACLE instances using RAC.
With parallel concurrent processing, each node with concurrent managers may or may not be running an ORACLE instance. On a node that is not running ORACLE, the concurrent manager(s) connect via Net8 to a node that is running ORACLE.
Parallel concurrent processing is activated along with Generic Service Management (GSM); it can not be activated independently of GSM. With parallel concurrent processing implemented with GSM, the Internal Concurrent Manager (ICM) tries to assign valid nodes for concurrent managers and other service instances. Primary and secondary nodes need not be explicitly assigned. However, you can assign primary and secondary nodes for directed load and failover capabilities.
Note: In previous releases, you must have assigned a primary and secondary node to each concurrent manager.
Initially, a concurrent manager is started on its defined primary node, or if none exists, the node that the ICM assigns to it. In case of node or ORACLE instance failure, all concurrent managers on that node migrate to their respective secondary nodes if defined.
A concurrent manager on its secondary node migrates back to its primary node once that node becomes available. During migration, the processes of a single concurrent manager may be spread across its primary and secondary nodes.
The Internal Concurrent Manager can run on any node, and can activate and deactivate concurrent managers on all nodes. Since the Internal Concurrent Manager must be active at all times, it needs high fault tolerance. To provide this fault tolerance, parallel concurrent processing uses Internal Monitor Processes.
The sole job of an Internal Monitor Process is to monitor the Internal Concurrent Manager and to restart that manager should it fail. The first Internal Monitor Process to detect that the Internal Concurrent Manager has failed restarts that manager on its own node.
Only one Internal Monitor Process can be active on a single node. You decide which nodes have an Internal Monitor Process when you configure your system. You can also assign each Internal Monitor Process a primary and a secondary node to ensure failover protection.
Internal Monitor Processes, like concurrent managers, have assigned work shifts, and are activated and deactivated by the Internal Concurrent Manager.
You can optionally define a target node for a concurrent program. When a request for the program is submitted, only available managers running on the specified node will pick it up.
If no specification is made for the target node of a concurrent program, a request for it will be picked up by any manager available to run it. If a node specification is made for a concurrent program and the node is up, only available managers running on the specified node will pick up the request. However, if the target node is down, any available manager will pick up the request for processing and log an appropriate message in FND_LOG_MESSAGES.
If no specification is made for the target instance of a concurrent program, a request for it will be picked up by the first manager available to run it and will be run in the instance where the manager is already connected. If an instance specification is made for a concurrent program and the instance is up, it will be picked up by the first manager available to run it and the manager will run the request in the specified instance. However, if the target instance is down, the manager will run the request in the instance where it is already connected and log an appropriate message.
The concurrent log and output files from requests that run on any node are accessible online from any other node. Users need not log onto a node to view the log and output files from requests run on that node.
Some cluster or massively parallel systems have their own mechanisms for queuing batch processes; for example, IBM LoadLeveler. Because users may wish to manage all processing with these mechanisms (and not just Oracle E-Business Suite processing), parallel concurrent processing is designed to integrate with them. Thus, you can match your concurrent process management to the specific capabilities of your operating platform.
For more information on integrating with platform-specific queuing, refer to the installation documentation for your platform.