Overview of Parallel Concurrent Processing (User, System Administrator, and Flexfields Help)


	Previous	Next		Contents	Index	Navigation	Glossary	Library

Overview of Parallel Concurrent Processing

This essay explains what parallel concurrent processing is, describes the environments it runs in, and explains how it works.

What is Parallel Concurrent Processing?

Parallel concurrent processing allows you to distribute concurrent managers across multiple nodes in a cluster, massively parallel, or homogeneous 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.

Benefits of Parallel Concurrent Processing

Parallel concurrent processing provides Oracle Applications 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 homogeneous networked environment.

Parallel Concurrent Processing Environments

Parallel concurrent processing runs in multi-node environments, such as cluster, massively parallel, and homogeneous 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:

Cluster Environments

In a cluster environment, multiple computers, each representing a single node, share a common pool of disks. Typical cluster environments include IBM HACMP, VAX Cluster, or a cluster of Sequent servers.

With parallel concurrent processing in a cluster environment, a single ORACLE database resides in the common disk pool, while multiple instances of Oracle Parallel Server run simultaneously on multiple nodes in the cluster. Multiple concurrent managers are also distributed across the nodes in the cluster.

Massively Parallel Environments

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 Oracle Parallel Server instances run simultaneously on multiple nodes, with multiple concurrent managers also distributed across nodes.

Homogeneous Networked Environments

In homogeneous 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 homogeneous 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 Oracle Parallel Server.

How Parallel Concurrent Processing Works

Concurrent Managers

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 SQL*Net to a node that is running ORACLE.

To each concurrent manager, you assign a primary and a secondary node. Initially, a concurrent manager is started on its primary node. In case of node or ORACLE instance failure, a concurrent manager migrates to its secondary node.

A concurrent manager 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.

Internal Concurrent Manager

The Internal Concurrent Manager can run on any node, and can activate and deactivate concurrent managers on the same or other 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.

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 fail over protection.

Internal Monitor Processes, like concurrent managers, can have assigned work shifts, and are activated and deactivated by the Internal Concurrent Manager.

Log and Output File Access

The concurrent log and output files from requests that run on any node are accessible on-line from any other node. Users need not log onto a node to view the log and output files from requests run on that node. See: Database Instances, Manager Location, and File Distribution.

This capability relies on setup steps taken at install time. For more information, refer to the installation documentation for your platform.

Integration with Platform-Specific Queuing and Load-Balancing Systems

Some cluster or massively parallel systems have their own mechanisms for queuing batch processes or distributing process loads--for example, VMS batch queues or IBM LoadLeveler. Because users may wish to manage all processing, not just Oracle Applications processing, using these mechanisms, 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 and load-balancing systems, refer to the installation documentation for your platform.