面试宝典:介绍下Oracle数据库动态性能视图 V$CACHE

在这里插入图片描述
好的，我们来对 Oracle 19C 数据库中的 V$CACHE_TRANSFER 动态性能视图进行一次全面、深入的解析。

这个视图是 Oracle Real Application Clusters (RAC) 环境中独有的，是深入理解 缓存融合 (Cache Fusion) 操作和诊断相关性能问题的关键工具。

1. 作用与简介

核心作用：
V$CACHE_TRANSFER 动态性能视图用于统计和显示由于缓存融合 (Cache Fusion) 操作而在实例之间传输的数据块信息。它记录了哪些数据块被频繁地在实例间传递，是识别"热点块"和诊断全局缓存（GC）等待事件的重要依据。

背景知识：

缓存融合 (Cache Fusion)： RAC 的核心技术。它允许一个实例直接通过高速互连网络将数据块传输给另一个实例，避免了昂贵的磁盘 I/O，从而实现了可扩展性。
块传输类型：
- 一致性读 (CR) 块传输：一个实例为满足另一个实例的查询请求，构造并发送一个读一致性的块版本。
- 当前块传输：一个实例将块的当前版本（通常是独占模式下的最新版本）发送给另一个实例，通常是为了让接收者能够修改它。
全局缓存服务 (GCS)：协调所有缓存融合操作。

V$CACHE_TRANSFER 提供了这些块传输操作的量化历史记录。

2. 使用场景

诊断全局缓存争用 (Global Cache Contention)：
- 当 RAC 数据库出现 gc buffer busy acquire, gc buffer busy release, gc cr block busy, gc current block busy 等等待事件时，此视图是首要的调查点。它可以定位到具体是哪个文件、哪个块（FILE#, BLOCK#）正在被频繁地在实例间传输，从而成为"热点块"。
识别热点对象 (Hot Objects)：
- 通过聚合 V$CACHE_TRANSFER 的数据，可以找出哪些表或索引的段包含大量的热点块。这为后续的优化措施（如分区、使用反向键索引、调整应用逻辑等）提供明确的目标。
评估缓存融合效率：
- 监控块传输的频率和类型，可以帮助评估 RAC 集群的工作负载分布。如果大量块传输集中在少数几个块上，表明应用可能存在并发访问瓶颈。
容量规划与性能基准：
- 定期采集该视图的数据，可以建立性能基线，了解正常的缓存融合流量。流量激增可以帮助及时发现新的性能问题或应用变更带来的影响。

3. 字段含义详解

V$CACHE_TRANSFER 视图中的每一行代表一个曾被传输过的数据块及其传输统计。统计值从实例启动开始累积。

4. 相关视图与基表

相关动态性能视图：
- GV$CACHE_TRANSFER： V$CACHE_TRANSFER 的全局版本，显示所有活动实例的缓存传输统计。诊断RAC问题时必须使用此视图，因为热点块会影响整个集群。
- V$CACHE / V$BH：显示缓冲区缓存中块本身的当前状态信息（如XCUR, CR）。通过 FILE# 和 BLOCK# 与 V$CACHE_TRANSFER 关联，可以同时看到块的实时状态和历史传输情况。
- V$CACHE_LOCK：显示当前持有的PCM锁，用于理解当前对块的访问控制，而 V$CACHE_TRANSFER 记录了历史的传输活动。
- DBA_EXTENTS： 最重要的关联视图。通过 FILE_ID 和 BLOCK_ID 关联，可以将热点块映射到具体的表、索引等段对象，这是诊断和优化的最终目的。
- V$SEGMENT_STATISTICS / V$SEGSTAT：提供段级的统计信息，可以验证从 V$CACHE_TRANSFER 和 DBA_EXTENTS 关联后找出的热点段是否也有高的逻辑I/O。
基表 (Underlying Table)：
- V$CACHE_TRANSFER 是一个动态性能视图，其数据来源于 SGA 中 GCS 维护的统计信息计数器。
- 每当一个实例参与完成一次缓存融合块传输（无论是作为发送方还是接收方），对应的计数器（如 CR_SERVED, CURRENT_SERVED）就会递增。
- 该视图通过查询底层未公开的 X$ 表（如 X$KJCT）来获取这些计数器的值。严禁直接查询X$表。

5. 底层详细原理

缓存融合操作与计数器更新：
- 场景一：CR 块请求：实例A需要块B的一个读一致性版本用于查询。如果实例B持有该块的当前版本（XCUR），GCS会指令实例B为实例A构造并发送一个CR副本。在此过程中，实例B上的 CR_MASTER_CREATED 和 CR_SERVED 计数器会增加。
- 场景二：当前块请求：实例A需要以独占模式修改块B。如果实例C正以独占模式持有块B，GCS会指令实例C将块的当前版本发送给实例A。在此过程中，实例C上的 CURRENT_MASTER_CREATED 和 CURRENT_SERVED 计数器会增加。
热点块的形成：
- 如果一个数据块被集群中的多个实例频繁地读取或修改，它就会导致上述缓存融合操作被反复触发。
- V$CACHE_TRANSFER 中该块对应的 CR_SERVED 和/或 CURRENT_SERVED 值会异常高。
- 大量的传输操作会占用昂贵的互联网络资源，并在实例间引入协调等待，从而表现为 gc 相关的等待事件，影响系统性能和可扩展性。
视图数据查询：
- 查询 V$CACHE_TRANSFER 时，Oracle 会遍历一个内部哈希表，该表以<FILE#, BLOCK#>为键，存储了每个块的传输统计计数器。然后返回这些计数器的当前值。

6. 常用查询SQL示例

1. 识别集群中传输最频繁的热点块（核心诊断查询）

SELECT inst_id, file#, block#,
       (cr_served + current_served) AS total_transfers,
       cr_served,
       current_served
FROM gv$cache_transfer
WHERE (cr_served + current_served) > 100 -- 根据实际情况调整阈值
ORDER BY total_transfers DESC;

2. 将热点块映射到数据库对象（定位问题根源）

SELECT ct.inst_id, ct.file#, ct.block#, 
       (ct.cr_served + ct.current_served) AS total_transfers,
       e.owner, e.segment_name, e.segment_type, e.partition_name
FROM gv$cache_transfer ct
JOIN dba_extents e ON (ct.file# = e.file_id AND ct.block# BETWEEN e.block_id AND e.block_id + e.blocks - 1)
WHERE (ct.cr_served + ct.current_served) > 100
ORDER BY total_transfers DESC;

3. 按数据文件统计缓存传输 activity

SELECT file#, 
       SUM(cr_served) AS total_cr_served,
       SUM(current_served) AS total_current_served,
       SUM(cr_served + current_served) AS total_transfers
FROM gv$cache_transfer
GROUP BY file#
ORDER BY total_transfers DESC;

4. 查找特定段上的所有热点块

SELECT ct.file#, ct.block#, ct.cr_served, ct.current_served
FROM v$cache_transfer ct
JOIN dba_extents e ON (ct.file# = e.file_id AND ct.block# BETWEEN e.block_id AND e.block_id + e.blocks - 1)
WHERE e.segment_name = '&YOUR_TABLE_NAME'
AND e.owner = '&OWNER'
ORDER BY (ct.cr_served + ct.current_served) DESC;

5. 比较实例间的块传输负载

SELECT inst_id, 
       SUM(cr_served) AS instance_cr_served,
       SUM(current_served) AS instance_current_served
FROM gv$cache_transfer
GROUP BY inst_id
ORDER BY inst_id;

总结

V$CACHE_TRANSFER 是 Oracle RAC 环境中诊断缓存融合相关性能问题的核心视图。

核心价值：它将抽象的 gc 等待事件量化并定位到具体的文件、块，进而通过关联可以定位到具体的数据库对象（表、索引），为性能优化提供极其精确的目标。
监控重点：
- CR_SERVED 和 CURRENT_SERVED：高值表明该块是热点块。
- FILE# 和 BLOCK#：定位热点资源。
使用哲学：
1. 总是使用 GV$CACHE_TRANSFER 以获得集群全局视图。
2. 必须与 DBA_EXTENTS 关联，将"块"转化为"表"或"索引"。不知道是哪个对象导致的争用，诊断就只完成了一半。
3. 结合 V$SYSTEM_EVENT 视图，确认高传输率是否确实导致了显著的全局缓存等待时间。
4. 理解其数据显示的是历史累积值，用于趋势和热点分析，而非实时状态。