面试宝典:介绍下Oracle数据库动态性能视图 V$PING-优快云博客

在这里插入图片描述
好的，我们来对 Oracle 19C 数据库中的 V$PING 动态性能视图进行一次极其详细和准确的解析。这个视图是诊断 Oracle Real Application Clusters (RAC) 环境中缓存融合 (Cache Fusion) 性能问题的核心工具。

1. 作用与概述

V$PING 视图的主要作用是识别和量化在 Oracle RAC 环境中由于多个实例频繁争用相同的数据块而导致的"pinging"现象。

核心概念：Pinging (或 False Pinging)
在 RAC 中，一个数据块在同一时刻只能被一个实例以"当前"模式（例如，为了修改）持有。如果另一个实例也需要以独占模式访问同一个块，那么第一个实例必须先将该块的副本释放或"写回"磁盘（这被称为"ping"），然后第二个实例才能读取它。

True Pinging：是正常的缓存融合操作，即一个实例将块的当前版本直接发送给另一个实例。
False Pinging：是一种性能有害的情况，指一个实例被迫将其修改过的（脏）缓冲区写回磁盘，以便另一个实例可以读取它。这会产生额外的磁盘 I/O，严重破坏性能。V$PING 视图主要帮助识别的就是这种 False Pinging。

简而言之，V$PING 揭示了 RAC 环境中数据块在实例间"颠簸"的严重程度，是判断应用设计是否合理（数据是否在实例间有效分区）的关键指标。

2. 使用场景

RAC 性能问题诊断：
当 RAC 集群出现性能下降、全局缓存（GC）等待事件（如 gc buffer busy， gc cr block busy）激增时，使用此视图检查是否存在频繁的 pinging。
应用架构评审：
验证应用程序的设计是否适合 RAC 环境。高频率的 pinging 通常表明：
- 表设计不合理（缺乏分区或索引）。
- 应用逻辑没有利用"服务"或"连接池"将操作特定数据的用户连接到同一个实例（缺乏数据亲和性）。
容量规划与调优：
在实施新的应用模块前，通过测试环境的 V$PING 视图评估其对全局缓存的影响。
定位热点对象：
识别哪些特定的段（表、索引）是引起大量跨实例块争用的"元凶"。

3. 字段含义详解

以下是 V$PING 视图中各个字段的精确说明。

字段名	数据类型	含义说明
FILE_ID	NUMBER	发生 pinging 的数据块所在的数据文件标识符 (ID)。可与 `DBA_DATA_FILES.FILE_ID` 关联。
BLOCK_ID	NUMBER	发生 pinging 的数据块的编号。与 `FILE_ID` 共同唯一标识一个数据块。
DATA_OBJECT_ID	NUMBER	发生 pinging 的数据块所属段的数据对象标识符。可与 `DBA_OBJECTS.DATA_OBJECT_ID` 关联以找到具体对象。
FREQUENCY	NUMBER	该特定数据块 (`FILE_ID`, `BLOCK_ID`) 发生 pinging 的次数。此值越高，说明该块争用越严重。
XNC	NUMBER	该数据块发生"强制写盘" (Write Disk) 操作的次数。这是 False Pinging 的直接证据，是最需要关注的指标。高 `XNC` 值意味着大量的磁盘 I/O 和极差的性能。
CON_ID	NUMBER	包含此数据块的容器的 ID。在 CDB 环境中，指示该块属于哪个 PDB。

4. 相关视图与基表

相关动态性能视图：
- GV$CACHE_TRANSFER / V$CACHE_TRANSFER：显示更详细的缓存传输信息，包括为什么以及如何在实例间传输块。V$PING 可以看作是它的一个摘要，聚焦于高频率传输的块。
- GV$SEGMENT_STATISTICS：可以按段查看"global cache"相关的统计信息（如 gc buffer busy），与 V$PING 结合可以定位到具体的热点段。
- GV$ACTIVE_SESSION_HISTORY / GV$SESSION：当发现热点块后，通过这些视图可以找到正在访问这些块的 SQL 语句和会话。
- GV$GES_BLOCKING_ENQUEUE：显示当前的全局锁存器（Enqueue）信息，用于诊断正在发生的块争用。
底层基表与原理：
V$PING 是一个动态性能视图，其数据不直接来源于普通的磁盘基表。
- 数据源：其数据由 全局缓存服务 (GCS) 和全局队列服务 (GES) 进程在管理缓存融合请求时动态收集和更新。这些信息存储在 SGA 的共享池或其它内部内存结构中。
- 持久化：Pinging 的统计信息是实例生命周期的，实例重启后会被重置。它们不会被持久化到 AWR 仓库中，这使得 V$PING 成为一个用于实时或近期问题诊断的视图。
- 底层结构：其底层来源于内部的 X$ 表（如 X$KCFIO），这些表在查询时被动态填充。

5. 详细原理与知识点

1. 缓存融合 (Cache Fusion) 工作流程：
这是理解 V$PING 的基础。当一个实例（请求者）需要一个块，而另一个实例（持有者）正以独占模式持有它时：

请求者向 GCS 发出请求。
GCS 通知持有者释放该块。
理想情况 (True Ping)：持有者通过互联网络直接将块的当前版本发送给请求者。没有磁盘 I/O。
非理想情况 (False Ping)：如果持有者的缓冲区需要被重用，或者由于某些内部原因，持有者必须先将脏块写回磁盘（生成 redo log），然后才能释放它。之后，请求者从磁盘读取该块。这个过程产生了额外的同步磁盘写和磁盘读，性能极差。XNC 字段统计的就是这种情况。

2. 为什么会产生 Pinging？
根本原因是应用设计未能实现数据在实例间的亲和性：

序列（Sequence）：使用没有设置 CACHE 选项的序列，导致多个实例频繁访问序列所在的块来生成下一个值。
小表或索引块：频繁修改的小型代码表、索引的根块或分支块，被所有实例频繁更新。
非分区表上的 DML：所有实例都对同一个大表进行随机更新，导致块在实例间频繁移动。

3. 解决方案：

应用分区：使用分区技术（如 Range, Hash），将数据物理分离，使不同实例处理不同分区的数据。
服务与连接路由：配置应用连接池和数据库服务，确保操作同一组数据的用户会话连接到同一个实例。
序列优化：使用 CACHE 足够大的序列，减少访问序列块的次数。
反向键索引：对于索引叶块的热点，可以考虑使用反向键索引来分散写入压力。

6. 常用查询SQL

1. 查询系统中pinging最严重的数据块（TOP N）

SELECT *
FROM (
    SELECT file_id,
           block_id,
           data_object_id,
           frequency,
           xnc,
           ROUND((xnc / frequency) * 100, 2) AS pct_disk_write
    FROM v$ping
    WHERE frequency > 0
    ORDER BY xnc DESC, frequency DESC
)
WHERE ROWNUM <= 10;

2. 关联DBA_OBJECTS，定位pinging对应的具体数据库对象（关键诊断步骤）

SELECT p.file_id,
       p.block_id,
       p.data_object_id,
       o.owner,
       o.object_name,
       o.object_type,
       p.frequency,
       p.xnc
FROM v$ping p
LEFT JOIN dba_objects o ON p.data_object_id = o.data_object_id
WHERE p.frequency > 100  -- 设置一个阈值，只看频繁ping的块
ORDER BY p.xnc DESC;

3. 监控特定对象的pinging情况（已知热点对象后）

SELECT p.file_id, p.block_id, p.frequency, p.xnc
FROM v$ping p
JOIN dba_objects o ON p.data_object_id = o.data_object_id
WHERE o.object_name = 'HOT_TABLE_NAME'
  AND o.owner = 'SCHEMA_OWNER'
ORDER BY p.frequency DESC;

4. 计算False Pinging的比例（XNC / FREQUENCY）
高的比例意味着缓存融合效率极低。

SELECT SUM(frequency) AS total_pings,
       SUM(xnc) AS total_disk_writes,
       ROUND((SUM(xnc) / SUM(frequency)) * 100, 2) AS overall_pct_disk_write
FROM v$ping;