Previous | Table of Contents | Next

Page 665

owners of the lock can read the block(s) covered by the lock, and an EXCLUSIVE status enables the owner to make changes to block(s). For an instance to acquire a lock in EXCLUSIVE mode, all other instances must relinquish ownership of the lock.

FIG. 27.2
Version 7.3 Parallel
Server Interface to the
Distributed Lock
Manager.



FIG. 27.3
Oracle8 Parallel Server
interface to the Group
Membership Services
software layer.

Each instance starts one or more lock manager background processes, LCKn,where n is a single digit and the first lock process is LCK0. These processes are responsible for obtaining any PCM locks required by their instance and for managing the release of the locks. The LCKn processes are also responsible for knowing which locks they currently own and the status of those locks. They maintain this information in a shared lock area of the SGA.

Page 666

In addition to the LCKn processes, each node runs a Distributed Lock Manager (DLM) process or processes. The DLM is responsible for the global allocation of locks across all instances and manages requests for locks made by the various instances. The DLM can allocate unused locks or else recall locks from another instance to pass them on to a requesting instance. The DLM also maintains the current status of all locks, whether they are assigned to an instance or not.

Prior to Oracle8, the DLM code was provided by either the operating system vendor or by Oracle, depending on the platform. Consequently, the commands you would use to start and stop the DLM, and any files or parameters you would need to configure it, would differ from platform to platform. A sample DLM configuration file is shown in Listing 27.1.

Listing 27.1 Sample DLM Configuration File
#NODE NAME    IP ADDRESS       NODE ID  DOMAIN   SERVICE PORT NUMBER
apple         123.45.678.001   1        0        1544
orange        123.45.678.002   2        0        1544
pear          123.45.678.003   3        0        1544

As with other platform-specific tools and facilities, you need to reference the Oracle installation/configuration guide for your platform in order to determine the required steps to configure, start, and stop the DLM. In Oracle8, the DLM becomes part of each Oracle instance and requires no configuration information beyond the init.ora parameters used for Parallel Server. Two processes or threads are used by the Oracle8 DLM, identified with the names DLMD and DLMOD. DLMD manages the lock conversion activity while DLMOD monitors the status of the DLMD process and writes any error or warning messages to a log file.

Assignment of PCM locks to the database datafiles is a critical task for the administrator of a multi-instance database. Too many locks cause performance degradation due to the memory requirements of the shared lock area and the DLM structures. If you don't assign sufficient locks, you may incur substantial block pinging.

Block pinging occurs when one instance needs a PCM lock that is currently held by another instance in EXCLUSIVE mode. Before releasing the lock, the owning instance wakes up its DBWR process to inspect the blocks covered by the lock. DBWR looks for any of these blocks that contain changes not yet flushed to disk, known as dirty blocks, then writes them back to the database files. This process of writing dirty blocks as part of the down conversion of the PCM lock is known as pinging. As you increase the number of blocks covered by a single lock, you also increase the likelihood that another instance might want the lock and thus introduce the potential for more block pings.

At the other end of the ping is the instance that requested the lock. On receiving the lock, this instance must read any blocks it needs into its buffer cache. It cannot rely on images of these blocks already held in its cache because the other instance could have changed the block under its exclusive lock. If the receiving instance needs all the blocks that were pinged to disk, the

Page 667

pings are considered true pings. If, on the other hand, the receiving instance needed none, or only some of, the blocks pinged to disk, then the unneeded block writes are considered false pings. See Figure 27.4 for a diagram of how these different types of pings occur.

FIG. 27.4
How pinging occurs
between instances.

While true pings may be unavoidable if the instances need access to exactly the same blocks on a regular basis, false pings constitute unnecessary overhead and need to be detected and decreased. The amount of pinging and false pinging you experience depends on your database design and on the settings of the PCM lock parameters in your init.ora file.

NOTE
Pinging is not bad, but a necessary component of the Parallel Server architecture. Excessive pinging is a problem because it degrades performance. As you read this chapter, you will learn how to design a database that maintains an acceptable level of pinging.n

Using Parallel Cache Management Lock Parameters

You use a set of global cache management parameters to define the PCM lock environment for your instances. The global cache parameter names are prefixed with the string GC_. These parameters are slightly different between Version 7.3 and Oracle8. Table 27.1 shows the parameter name for each release and the purpose of the parameter.

Page 668

Table 27.1 PCM Lock Management Parameters
Version 7.3 Oracle8 Description
GC_LCK_PROCS same Number of LCKn processes to start.
GC_DB_LOCKS obsolete Number of hash PCM locks for data blocks.
GC_RELEASABLE_LOCKS revised Number of fine grain PCM locks for data blocks.
GC_FREELIST_GROUPS obsolete Number of hash locks for freelist group header blocks.
GC_ROLLBACK_LOCKS revised Number of hash locks for rollback segments header blocks.
GC_ROLLBACK_SEGMENTS obsolete Number of hash locks for rollback segment undo blocks.
GC_SAVE_ROLLBACK_LOCKS obsolete Number of hash locks for deferred rollback segment blocks.
GC_SEGMENTS obsolete Number of hash locks for non- rollback segment header blocks.
GC_TABLESPACES obsolete Number of hash locks for tablespace manipulation (concurrent ALTER...ONLINE or ALTER...OFFLINE commands).
GC_FILES_TO_LOCKS revised Describes the allocation of PCM locks to the datafiles.


NOTE
The parameters marked as obsolete in the Oracle8 column of Table 27.1 are discontinued in Oracle8. Those marked as revised are changed in function or syntax, and you will find the details of the differences in a later section of this chapter.n

You can leave many of these parameters at their default values unless, while monitoring the database, you see some contention that could be alleviated with additional locks. The three parameters on which you need to concentrate your efforts are GC_DB_LOCKS, GC_RELEASABLE_LOCKS, and GC_FILES_TO_LOCKS.

As you can see from Table 27.1, there are two types of PCM locks, hash locks and fine grain locks, also known as data block address (dba) locks or releasable locks. These two types of lock have one important difference. When a hash PCM lock is acquired by an instance, it is not released back to the DLM unless it is required by another instance. It is possible, therefore, for an instance to obtain a hash lock and never to release it until the instance shuts down. On the other hand, a fine grain lock is only held by the instance while it is using the block, or blocks,

Previous | Table of Contents | Next