When there is contention for the same block by multiple instances, one instance has to write the block to disk so that the other instances can read or modify it. This process is referred to as pinging . The concept of pinging in OPS is best explained through an example. Let’s look at what happens in a two-instance OPS configuration in which instance 1 is updating row 1 of a table that resides in block 1. Let’s assume that block 1 is protected by PCM lock L1. Instance 1 acquires lock L1 in exclusive mode. Then instance 1 reads block 1 from the datafile on disk, places that block in its buffer cache, and modifies it. For the other instance, instance 2, the mode of lock L1 is NULL, indicating that it does not have access rights to block 1 at this time.

Now, if instance 2 needs to modify row 5, also in block 1, it needs to acquire lock L1 as well. Because instance 2 needs to modify the block, the lock must be acquired in exclusive mode. However, because instance 1 already holds lock L1 in exclusive mode, the request by instance 2 to acquire it will fail. Figure 8.1 illustrates this situation.

Figure 8-1. Instance 1 holds an exclusive lock on block 1

To allow instance 2 to acquire lock L1 in exclusive mode, instance 1 must write block 1 back to disk. That way, instance 2 sees the most current version of the block, and none of the changes are lost. Instance 1 then must downgrade its lock mode for lock L1 from X to NULL. After that, instance 2 can acquire lock L1 in exclusive mode (via a NULL-to-X conversion), read block 1 into its buffer cache, and modify it. Figure 8.2 shows the resulting situation.

Figure 8-2. Instance 2 has acquired an exclusive lock on block 1

This entire sequence of events is referred to as a ping. A ping occurs when a block has to be written to disk by one instance so that it can be read or modified by another instance. Pinging occurs when there is contention for the same data block by two or more instances. Like the Ping-Pong ball shown in Figure 8.3, database blocks are bounced back and forth between SGAs when multiple instances need to access the same blocks.

Figure 8-3. Blocks are sent back and forth like Ping-Pong balls

Because of the disk I/O and lock mode conversion involved, frequent pinging can hurt the performance of an OPS database.

When there is contention for the same lock by multiple instances, one instance may have to write blocks protected by that particular lock to disk so that another instance can acquire it. It may be that the acquiring instance does not even need the particular blocks that were written. This process is referred to as false pinging and can occur when one lock protects more than one data block. Let’s look at an example in which one PCM lock protects two data blocks, and let’s further assume that lock L1 protects blocks 1 and 8. This situation is shown in Figure 8.4.

Figure 8-4. One PCM lock protecting multiple databases blocks

Continuing with our example, let’s say that instance 1 is modifying block 1 and consequently acquires lock L1 in exclusive mode. Let’s also say that instance 2 needs to modify block 8. Block 8 also is protected by lock L1. Thus, instance 2 also needs to acquire lock L1 in exclusive mode. Even though both instances are modifying different blocks, there still is contention for lock L1. To resolve that conflict, instance 1 must release lock L1 (via a lock downgrade from X to NULL). To do that, it must write block 1 to disk. After block 1 has been written to disk and the lock has been released, instance 2 can acquire lock L1 in exclusive mode (via a lock upgrade from NULL to X ) and modify block 8. This is referred to as a false ping (as shown in Figure 8.5), because the block that was written was not actually the block required by the other instance.

Figure 8-5. A false ping occurs when a block is written only to enable a lock to be released

A false ping occurs when one or more blocks protected by a lock are written to disk by one instance because another instance needs to modify another block protected by the same lock. While pinging occurs due to block contention, false pinging occurs due to lock contention. As Figure 8.6 shows, if block 1 and block 8 had been protected by separate locks, then no false ping would have occurred.

Figure 8-6. No false pinging occurs when one lock protects one block

When two instances need to modify a data block, there is a writer/writer conflict. The lock mode in the holding instance is downgraded from X to NULL, while the lock mode in the requesting instance is upgraded from NULL to X.

When a reading instance needs data blocks that have been modified by another instance, there is a reader/writer conflict. In this case, the holding instance writes data to disk, and the lock mode in the holding instance is downgraded from X to S. Then, the lock mode in the requesting instance is converted from NULL to S. Table 8.3 shows lock mode conversion in the holding and requesting instances for different types of lock mode conflicts. This table also shows the cases in which a write to disk is needed, thus resulting in pings.

As you’ve seen, maintaining buffer cache coherency across multiple instances requires ping operations. A ping involves both lock conversion and disk I/O to write data blocks. The following steps are performed whenever a ping occurs:

These lock operations involve coordination between OPS instances through the IDLM. The IDLM overhead, coupled with the disk I/O required for pinging, can decrease the response time of an OPS database as compared to a standalone database.

When a required data block is found in the buffer cache of an instance, disk access is avoided, and access time is quite fast as compared to the time required to read the block from disk. This is, of course, the reason that data blocks are buffered in the SGA of an Oracle instance. However, in an OPS environment, this buffering can be a liability. When data blocks are in the buffer cache of remote instances, ping operations are required. Because of this pinging, accessing data blocks from a remote instance’s buffer cache is even more expensive than accessing them from the disk. Figure 8.7 illustrates this. If an OPS environment is not properly tuned, too many pings will occur, and the resulting overhead can degrade the performance of an OPS database to a point at which it’s worse than that of a standalone database.

Figure 8-7. Performance overhead of pinging

You saw in Table 8.3 that when the mode of a lock in a holding instance is converted from exclusive (X) to null or from exclusive (X) to shared (S), the holding instance has to write the blocks covered by that lock to disk. The requesting instance then can acquire those locks in whatever mode is necessary. This situation describes pinging. However, in some situations, it is not necessary for the holding instance to write the blocks to disk because the blocks in question already have been written to disk as a result of the normal checkpoint operation of the instance. This may occur for true pings as well as for false pings. In such cases, neither true pinging nor false pinging involves any disk writes. Only the lock mode conversion takes place. Such a ping is referred to as a soft ping, or an I/O-less ping. The overhead of a soft ping obviously is less that it would be for other pings since it doesn’t involve any actual disk I/O.

Since false pinging is caused by lock contention, it can be reduced by allocating more PCM locks. However, true pings are caused by block contention and cannot be reduced by allocating even an infinite number of PCM locks. The only way to reduce true pinging is by proper application partitioning. Table 8.4 contrasts the causes and solutions for the two types of pinging.

The goal of application partitioning, which is performed when you first design your applications and your database, is to reduce pings. During your design process, you must perform an analysis of table access by your applications, and you must design your applications so that different nodes run different applications and access a disjoint set of tables. For example, one instance could be used for a payroll application, while another instance could be used for an inventory application. Since each of these applications is likely to access a completely different set of tables, any one block is not likely to end up in the buffer cache of more than one instance. As a consequence, pings are minimized. However, if one application (e.g., the payroll application) runs on more than one instance, then pings still could occur between those. Chapter 11, talks about this subject in more detail.

With Oracle8i, a new technique called cache fusion has been introduced to reduce the performance overhead of ping in OPS. With this new technique, data is transferred directly from the SGA of one instance to the SGA of another instance without the need to write the blocks to disk. Figure 8.8 illustrates this transfer.

Figure 8-8. Cache fusion allows blocks to be transferred directly from one instance to another

We have seen in Table 8.3 that pinging occurs when there is writer/writer and reader/writer conflict. Cache fusion has been implemented only for the subset of conflicts that results in pings and applies only to reader/writer conflicts. A cache fusion solution for writer/writer conflicts is planned for a future release of OPS. Writer/writer conflicts are currently handled through ping operations. Table 8.5 illustrates the scenarios in which cache fusion is applied and shows how cache coherency is maintained in other cases.

Oracle has introduced a new server process called the Block Server Process (BSP) to facilitate cache fusion. The Block Server Process is responsible for transferring the required blocks directly from the buffer cache of the holding instance to the buffer cache of the requesting instance. When there is a reader/writer conflict, the IDLM communicates the request to the BSP of the holding instance. If the requested buffer already has been written to disk in the holding instance, the requesting instance is permitted to read the blocks from the disk. Otherwise (if the modified block is in the buffer of the holding instance), the BSP on the holding instance prepares a consistent read (CR) image of the data block. The BSP uses rollback information if required to prepare that CR copy. It then sends a message with the CR copy of the block to the requesting node. The blocks are sent over a fast interconnect that doesn’t involve costly disk I/O.

Fast interconnects are communication links between OPS nodes. These links use Ethernet, FDDI, or other proprietary communication protocols. Communication links between OPS nodes are designed for reliability and for transparent recovery from hardware and software failures. High bandwidth and low latency also are highly desirable. The characteristics of a specific interconnect depend on the hardware platform being used.

Cache fusion is a much less expensive operation than pinging, because with cache fusion, expensive disk I/O and lock mode conversion is no longer necessary. With cache fusion, you’ll notice fewer X-to-S lock conversions than you would otherwise. Figure 8.9 illustrates the significant reduction in access time for blocks held in a remote cache when Oracle8i ’s cache fusion feature is used as opposed to the access time required in prior releases that do not support the feature. Oracle Corporation reports that the access time can be reduced by as much as a factor of 100.

Figure 8-9. Performance improvement with cache fusion

OPS implementation requires that applications be well partitioned when they are designed. With the introduction of cache fusion in Oracle8i, OPS can be implemented with some OLTP applications that already have been designed without application partitioning in mind (see Chapter 11 for details on application partitioning). If those applications have numerous reader/writer conflicts, cache fusion results in a substantial performance gain, thus making OPS implementation possible.