Oracle7 Parallel Server Concepts and Administrator's Guide

Library

Product

Contents

Index

Oracle Instance Architecture for the Parallel Server

• Overview
• Characteristics of OPS Multi-instance Architecture
• System Global Area
• Background Processes and LCKn
• Configuration Guidelines for OPS

• Overview

• Characteristics of OPS Multi-instance Architecture

• System Global Area

• Background Processes and LCKn

• Configuration Guidelines for OPS

Overview

• system global area (SGA)

• background processes

• ORACLE_SID

• set of redo logs

• the same set of data files

• the same set of control files

• an additional PCM lock area in its SGA to coordinate the use of shared resources (also known as lock elements)

• additional background processes LCKn to coordinate the locking of shared resources among the multiple instances in a parallel server

Figure 5 - 1. Basic Elements of Oracle Parallel Server

See Also: "Memory Structures and Processes" in Oracle7 Server Concepts.

Characteristics of OPS Multi-instance Architecture

• An Oracle instance can be started on one or more nodes in the network.

• Each instance has a separate System Global Area (SGA) and set of background processes.

• All instances share the same datafiles and control file.

• Each instance has its own set of redo log files.

• Archived logs are private, but must be accessible to all instances for media recovery.

• All instances can execute transactions concurrently against the same database, and each instance can have multiple users executing transactions.

• Row level locking is preserved.

Applications that access the database can run on the same nodes as instances of a parallel server or on separate nodes, using the client-server architecture. A parallel server can be part of a distributed database system. Distributed transactions access the data in a remote database in the same manner, regardless of whether the datafiles are owned by an Oracle Server (in exclusive mode) or a parallel server (in exclusive or shared mode).

Other non-Oracle processes can run on each node of the system, or you can dedicate the entire system or part of the system to Oracle. For example, a parallel server and its applications might occupy three nodes of a five-node configuration, while the other two nodes are used for non-Oracle applications.

System Global Area

• buffer cache for data blocks

• dictionary cache for data dictionary information

• redo log buffer for redo entries

• shared pool containing the shared SQL and shared PL/SQL areas

• distributed lock area (only in a parallel server)

A data block can be present in several SGAs at the same time. PCM locks ensure that the database buffer cache is kept consistent for all the instances. It thus ensures readability by one instance of changes made by other instances.

Each instance has a shared pool that can only be used by the user applications connected to that instance. If the same SQL statement is submitted by different applications using the same instance, it is parsed and stored once in that instance's SGA. If that same SQL statement is also submitted by an application on a different instance, then this different instance also parses and stores the statement.

See Also: "Parallel Cache Management Instance Locks" .

Background Processes and LCKn

The Lock process (LCKn) manages the locks used by an instance and coordinates requests for those locks by other instances. Additional lock processes, LCK1 through LCK9, are available for systems that require exceptionally high throughput of distributed lock requests. The single lock process per instance, LCK0, is usually sufficient for most systems.

All instances in a parallel server must have the same number of lock processes. Lock processes use the distributed lock manager to coordinate the buffer caches of the different SGAs in a parallel server.

When an instance fails in shared mode, another instance's SMON detects the failure and recovers for the failed instance. The lock processes of the instance doing the recovery clean up any outstanding PCM locks for the failed instance.

All the lock processes for one instance are functionally equivalent. Typically, one lock process is sufficient. Occasionally, more than one lock process may maximize throughput of locking requests. Although lock requests are asynchronous, each request is blocked until the lock process knows if the lock can be granted immediately. Since multiple lock processes are functionally equivalent, this manual refers only to the lock process.

See Also: "The LCKn Processes" .

"GC_LCK_PROCS" .

Configuration Guidelines for OPS

Configuration Issue	Guidelines
Version	Ensure that the same Oracle version exists on all the nodes.
Links	UNIX soft or hard inks ("aliases") to executables are not recommended for a parallel server. If the single node containing the executables fails, none of the nodes will be able to operate.
Initialization parameters	Keep in a single file the initialization parameters which should be identical across all instances in a parallel server. Include this file in the individual initialization files of the different instances using the IFILE option.
Control files	Must be accessible from all instances.
Data files	Must be accessible from all instances.
Log files	Must be located on the same set of disks as control files and data files. Although the redo log files are independent per instance, each of the log files must still be accessible by all the instances so that recovery is provided for.
NFS	You can use NFS to enable access to Oracle executables, but not access to database files or log files.
Archived redo log files	Must be accessible from all instances.

Table 5 - 1. Parallel Server Configuration Guidelines

Prev Next

Copyright © 1996 Oracle Corporation. All Rights Reserved.

Library

Product

Contents

Index