The Global Cache and Enqueue Services – Workload Characteristics section in the AWR report reflects how efficiently Oracle RAC nodes coordinate block access through the Global Cache Service (GCS) and Global Enqueue Service (GES). In other words, it tells us how fast blocks are transferred between nodes, and whether the interconnect and block management are healthy or suffering from contention.

Here’s a sample from a healthy AWR report:

Understanding Receive Time

The “Avg global cache cr block receive time” and “Avg global cache current block receive time” metrics measure the average duration for a RAC node to acquire consistent read (CR) blocks (used for SELECT queries) and current blocks (used for DML operations like INSERT/UPDATE), respectively, from another node’s cache.

In a single-instance database, these blocks would instead be fetched directly from local disk or memory, without inter-node communication. Therefore, if the time to fetch blocks from remote nodes in RAC is slower than reading them from disk, it suggests that using RAC may not be the right architectural choice for that workload.

Healthy values are typically under 1 ms. In the example, 0.6 ms for CR blocks and 0.4 ms for current blocks reflect excellent performance.

Calculating Average Receive Time

These averages derive from statistics in the “Key Instance Activity Stats” section of the same AWR report:

Note: The units for “gc cr block receive time” and “gc current block receive time” are centiseconds (1/100th of a second).

Oracle computes the averages as follows:

Avg CR block receive time (ms) = (gc cr block receive time per second / gc cr blocks received per second) × 10
= (2.81 / 50.08) × 10 ≈ 0.56 ms

Avg Current block receive time (ms) = (gc current block receive time per second / gc current blocks received per second) × 10
= (3.04 / 73.14) × 10 ≈ 0.41 ms 

These values align with the AWR report.

Block Transfer Breakdown

Block transfers in RAC occur in three phases on the serving node. These phases differ slightly by block type:

CR Block:

• gc cr block build time: Builds a read-consistent image of the block.
• gc cr block flush time: Flushes changes to the redo log if necessary.
• gc cr block send time: Sends the block over the interconnect.

Current block:

• gc current block pin time: Pins (locks) the block for exclusive transfer.
• gc current block flush time: Forces a redo log write for any dirty changes.
• gc current block send time: Sends the block to the requesting node.

The flush phase is often the slowest, but not every transfer requires it. Thus, the report includes flush ratios:

• Global cache log flushes for cr blocks served %
• Global cache log flushes for current blocks served %

Higher modification rates in the workload typically increase these percentages.

These phases occur on the serving node, so their times cannot be summed directly to derive the receive time on the requesting node. However, similar timing patterns may appear across nodes.

Note these three phases are going through on the serving node, so you can not sum the three phase to get the receive time in the receiving node. Althought the timing patterns can be similiar on the receiving node and the serving node.

Unthealthy Case Study

For contrast, consider this unhealthy example, where excessive flush times degrade performance:

Here, intolerably high flush times (266.7 ms for CR, 398.1 ms for current) are the primary culprits, inflating receive times and enqueue waits. This suggests redo log contention or I/O bottlenecks—common in write-heavy workloads.