Parallel Concurrent Processing

---

In 11i, Parallel Concurrent Processing is the means by which you can distribute your Concurrent Managers across multiple nodes in either a cluster, a massively parallel configuration, or in a homogenous networked environment. Often, heavy Concurrent Processing is occurring at times when other nodes in a configuration are idle. By taking advantage of Parallel Concurrent Processing, you can spread your Concurrent Processing across all available nodes, thereby better utilizing all hardware resources in your environment.

Distributing the Concurrent Processing in this manner has several benefits to the end users of the system.

• Utilizing the ability to run Concurrent Processes on multiple nodes in your configuration will allow for higher performance and improved Concurrent Processing throughput.

• Because the Concurrent Processing is distributed across all nodes, there is increased fault tolerance in the event that one of the nodes becomes unavailable or fails.

• The ability to integrate your Concurrent Processing with platform-specific batch queue and load balancing systems will allow for far greater adaptability and will help you maximize the Concurrent Processing performance on any given platform in your configuration.

• While distributing the processing over many nodes in your configuration, you maintain the ability to administer any Concurrent Manager from any node in the parallel configuration. This single point of control allows for ease of maintenance and monitoring in any of the clustered, massively parallel, or homogenous networked environments.

By definition, Parallel Concurrent Processing can only occur in multinode environments where each node consists of one or more processors and their associated memory, each node having its own processors and memory, and the only shared component being possibly shared disk resources. Each node operates independently of every other node. In a clustered environment, you have multiple computers, each its own separate node, sharing a common pool of disks. In this configuration, a single database instance would reside within the set of shared disks and the Concurrent Managers along with Oracle Parallel Server would be running simultaneously on each of the nodes in the cluster. A Massively Parallel Environment is one in which multiple nodes are all housed within a single computer. All of the nodes have shared access to the common pool of disks. Separate Oracle Parallel Server instances run simultaneously on the different nodes within the computer with multiple Concurrent Managers distributed among the nodes as well. In the final configuration — the Homogeneous Networked Environment — multiple computers of the same type are connected via the LAN to a single database server or to a RAC type environment. In this environment, the Concurrent Managers run on multiple workstations.

Managers, which are running on a node that does not have an Oracle Instance running on it, will connect via NET8 or OracleNet to a node that is running an instance. To each manager in the configuration, you would assign a primary and a secondary node, with the primary node being the one on which the manager is initially started. In case of a node failure of a manager's primary node, those managers assigned to that node as primary would migrate to their secondary nodes until such time that the primary again became available. Because the Internal Manager needs to be running at all times in these configurations, it needs to be extremely fault tolerant. To assist in this fault tolerance, Parallel Concurrent Processing provides the Internal Monitor Process whose sole job it is to monitor the Internal Manager and restart it if it should fail for any reason. Each node can have only one Internal Monitor Process running and you need to determine at configuration time if each node is to have its own Internal Monitor Process running.

While not typically considered when taking into account the Windows OS, Parallel Concurrent Processing is a viable option. It differs only slightly on Windows NT/2000 as opposed to a UNIX implementation.

The startup script for NT is not the default dcpstart.sh of the UNIX implementation. While running Oracle E-Business Suite, Windows does not use the ping, rsh, and kill commands of the UNIX implementation; rather, it uses TNS along with the Oracle Remote Connection (RCP) to provide similar functionality.

On NT/2000 there are two additional log files created when the Internal Manager is started. These files and their locations are defined in CCMSETUP.

While on UNIX, a node is considered to be alive when the Internal Manager is able to receive a good return from ping; on NT/2000 it is considered to be alive if TNS listener services are configured and reachable on the remote node.

---