PCM locks are classified based on the following two criteria: lock granularity and a combination of lock acquisition and retention. Lock granularity refers to the number of data blocks protected by one PCM lock. Lock acquisition and retention refers to the method by which an instance acquires the locks. Locks may be acquired only once, at the time of instance startup, or they may be acquired and released as needed.
One PCM lock can protect one or more data blocks. The number of blocks covered by a PCM lock is referred to as the lock’s granularity . The greater the number of blocks covered by one lock, the coarser the granularity. The lesser the number of blocks covered by one lock, the finer the granularity. Based on granularity, PCM locking approaches may be classified as either hashed locking or fine-grained locking. With hashed locking, one PCM lock protects more than one block, whereas with fine-grained locking, one PCM lock protects only one block.
Coarse granularity in locking increases the likelihood of lock contention because each lock protects many blocks. For a large transaction that’s accessing many blocks, the lock overhead may be less with coarse granularity locking because fewer locks may need to be acquired or converted. With coarse granularity locking, a hash function is used to associate locks to blocks. Therefore, this type of locking is referred to as hashed locking .
As you will see later in this chapter, PCM locks are assigned on a per-datafile basis. When assigning locks to a datafile, you specify the number of PCM locks that protect the blocks in that datafile. Oracle uses a hash function to assign PCM locks to data blocks. The intent of using a hash function is to achieve a uniform distribution of data blocks to PCM locks. Along with specifying the number of locks for a datafile, you also can specify a blocking factor that determines the sequence of data blocks protected by a PCM lock.
For example, let’s assume that file 1 has 20 data blocks and is assigned 4 PCM locks. The number of data blocks protected by each lock is computed as follows:
20 data blocks / 4 locks = 5 blocks per lock
In this case, each lock will protect five data blocks in file 1. The data blocks protected by each lock may or may not be contiguous. The sequence of data blocks protected by a lock is determined by the blocking factor, which can be specified along with the number of locks for each file. If the blocking factor is not specified, the default value is taken as 1. The default blocking factor of 1 results in the mapping of locks to blocks shown in Figure 8.10.
In Figure 8.10, the squares in the second row represent data blocks, and the squares in the first row represent locks protecting those data blocks. The labels inside the squares in the first row are the lock numbers. Lock L1 protects data blocks 1, 5, 9, 13, and 17. Lock L2 protects data blocks 2, 6, 10, 14, and 18.
If a blocking factor other than 1 is specified for the locks assigned to file 1, the assignment of locks to data blocks will be different from that shown in Figure 8.10. Figure 8.11 represents the same lock assignment as shown in Figure 8.10, but with a blocking factor of 2. A blocking factor of 2 means that each lock will protect two contiguous data blocks. Thus, lock L1 protects data blocks 1, 2, 9, 10, 17, and 18. Lock L2 protects data blocks 3, 4, 11, 12, 19, and 20.
Note that with the blocking factor illustrated in Figure 8.11, the number of blocks protected by each lock is different. Locks L1 and L2 each protect six blocks, whereas locks L3 and L4 each protect four blocks. In this case, the number of data blocks protected by the various locks varies by 2, and that variation probably is not significant. However, in some situations this variation can be significant. If we use a blocking factor of 16 in this example, lock L1 will protect 16 blocks, lock L2 will protect 4 blocks, and locks L3 and L4 will protect none at all. Such an uneven distribution of data blocks to locks can harm performance. Therefore, you should choose your blocking factor carefully and with respect to the total number of locks and data blocks that you are dealing with. Try to keep the distribution as even as possible.
Tip
Refer to Section 8.6 later in this chapter for detailed information on the mechanics of assigning PCM locks to datafiles.
When one lock protects only one block, you are using what is referred to as fine-grained locking . With fine-grained locking, lock contention is eliminated completely. This is good. However, the use of fine-grained locking requires more system resources than hashed locking in order to maintain the increased number of locks. For a transaction accessing many blocks, the lock overhead is higher with fine-grained locking because more locks need to be acquired or converted.
Oracle provides two types of lock acquisition and retention mechanisms:
- Fixed locking
Fixed locking is a proactive method. Locks are acquired at instance startup time and retained throughout the life of the instance. Fixed locking reduces lock acquisition overhead but increases instance startup time.
- Releasable locking
Releasable locking represents an as-needed method. Locks are not acquired when an instance starts. Instead, locks are acquired and released as needed. Releasable locking reduces instance startup time but increases lock acquisition overhead while the instance is running.
Fixed locks are not released after a read or write operation on the protected blocks is complete. Once acquired in a specific mode, fixed locks continue in that mode until they are required by another instance in a conflicting mode. For example, if an instance is holding a lock in shared mode, it will continue to do so even after the read operation that initiated the acquisition of that mode is complete. The lock mode is preserved until another instance asks to acquire the same lock in a conflicting mode. Fixed locks continually use system memory and increase the size of the SGA.
Releasable locks are released when they are no longer required. If a read or write operation results in the acquisition of a releasable lock, that lock is held only for the duration of the operation that initiated its acquisition. Once that read or write operation is complete, the lock is released. Memory is released as well, so the use of releasable locks reduces overall memory consumption.
Table 8.6 compares the consequences of using the various types of PCM locks that we’ve discussed.
Table 8-6. Effects of Different Types of PCM Locks
|
Fixed Hashed Locks |
Fixed Fine-Grained Locks |
Releasable Hashed Locks |
Releasable Fine-Grained Locks |
|---|---|---|---|
|
Increased likelihood of lock contention. False pings may occur. |
No lock contention. False pings eliminated. |
Reduced likelihood of lock contention. False pings may occur. |
No lock contention. False pings are eliminated. |
|
Reduced lock acquisition overhead. |
Reduced lock acquisition overhead. |
Increased lock overhead for both acquisition and release. |
Increased lock overhead for both acquisition and release |
|
Increased instance startup time. |
Increased instance startup time. |
Reduced instance startup time. |
Reduced instance startup time. |
|
Lock mode preserved in a steady state. |
Lock mode preserved in a steady state. |
Lock mode not preserved. |
Lock mode not preserved. |
|
Reduced memory consumption as compared to fixed fine-grained locking. |
Increased memory consumption as compared to fixed hashed locks and releasable fine-grained locks. |
Reduced memory consumption as compared to fixed fine-grained locking. |
Reduced memory consumption as compared to fixed fine-grained locking. |
See the section later in this chapter titled “What Kind of Locks to Use?” for some tips on choosing the right lock types to use in your environment.
Tip
With the release of Oracle8i, Oracle has changed the nomenclature used to identify types of locks based on granularity. Hashed locks are renamed as 1:n locks, and fine-grained locks are renamed as 1:1 locks. 1:n represents one lock protecting multiple (n) blocks. 1:1 represents one lock protecting one block. Throughout this book, we have used the words “hashed” and “fine-grained.” All the discussion also applies to 1:n and 1:1 locks, respectively.