好的，我们来对 Oracle 19C 数据库中一个与性能优化密切相关的动态性能视图——V$BT_SCAN_CACHE——进行详细、准确的解析。
这个视图是 Big Table Caching 特性的核心组成部分，提供了比 V$BTS_STAT 更为细粒度的信息。它专注于显示当前被缓存的大表内容，而不是聚合的统计信息。
1. 视图概述与核心作用
V$BT_SCAN_CACHE 动态性能视图的作用是显示当前数据库实例的缓冲区缓存（Buffer Cache）中，通过“大表缓存”（Big Table Caching）机制缓存的具体数据块的信息。
V$BTS_STAT 告诉你“发生了多少次命中/未命中”，而 V$BT_SCAN_CACHE 告诉你“当前缓存里到底有什么”。它回答了以下问题：是哪些大表的哪些部分正被缓存？缓存了多少？是为哪个并行查询进程缓存的？
核心作用可以概括为：
- 实时缓存内容分析：提供一个实时清单，列出所有通过BTC机制缓存在Buffer Cache中的大表段（表、分区或子分区）。
- 缓存效率评估：查看每个被缓存对象已缓存的块数（
CACHED_BLOCKS）与其总被扫描的块数（SCANNED_BLOCKS）的比例，直观评估缓存的有效性。 - 资源消耗监控：监控BTC功能当前占用了多少Buffer Cache空间。
- 并发操作洞察：识别是哪些SQL操作（通过
XDOP进程）正在使用或已经填充了这些缓存。
2. 使用场景
-
验证缓存效果：
在将一个大表标记为CACHE并运行查询后，立即查询此视图，确认该表的块是否真的被缓存到了Buffer Cache中，以及缓存的范围有多大。 -
诊断缓存失效问题：
如果怀疑缓存没有生效或缓存的内容被过早淘汰，使用此视图检查CACHED_BLOCKS是否远小于SCANNED_BLOCKS，或者对象是否根本不在缓存列表中。 -
调查Buffer Cache使用情况：
当发现Buffer Cache使用率很高时，查询此视图可以判断其中有多少空间是被BTC特性用于缓存大表的，从而评估该特性对整体内存压力的影响。 -
关联并行查询：
通过与V$PX_PROCESS等视图关联，可以追踪到是哪个并行查询从属进程负责创建和管理哪部分缓存。
3. 字段详细含义
V$BT_SCAN_CACHE 视图的字段描述了被缓存对象的身份、大小和状态。
| 字段名 | 数据类型 | 含义说明 |
|---|---|---|
| OBJ# | NUMBER | 缓存对象的对象ID。这是数据字典对象ID，可与 DBA_OBJECTS.OBJECT_ID 关联，以确定是哪个表或索引。 |
| DATAOBJ# | NUMBER | 缓存对象的数据对象ID。对于分区表，这是分区级的ID，可与 DBA_OBJECTS.DATA_OBJECT_ID 关联。这是更精确的标识符，因为一个分区表的不同分区有不同的DATAOBJ#。 |
| BT_CACHE_BLKCNT | NUMBER | 此对象的目标缓存块数。Oracle内部为此对象设定的目标缓存块数。 |
| CACHED_BLOCKS | NUMBER | 当前为此对象实际缓存的块数。这是视图中最关键的字段之一，显示了此刻在Buffer Cache中的块数量。 |
| SCANNED_BLOCKS | NUMBER | 此对象被扫描的总块数。自实例启动以来，通过BTC机制扫描的该对象的块总数。 |
| PERCENT_CACHED | NUMBER | 缓存百分比。计算公式为 (CACHED_BLOCKS / SCANNED_BLOCKS) * 100。直观地显示了扫描的块中有多大比例还在缓存中。值越高，说明缓存效果越好。 |
| FORCE_CACHING | VARCHAR2(3) | 是否强制缓存。指示该对象是否通过 ALTER TABLE ... CACHE 命令被显式地设置为强制缓存。值为 YES 或 NO。 |
| XDOP | NUMBER | 并行执行服务器进程ID。标识是哪个并行查询从属进程（XDOＰ）负责填充和管理此缓存段。 |
| CON_ID | NUMBER | 所在容器的ID。在多租户环境（CDB）中，标识这些统计信息属于哪个可插拔数据库（PDB）。对于CDB$ROOT，此值为0。 |
4. 相关视图与基表
-
核心关联视图：
V$BTS_STAT：提供BTC操作的聚合统计信息（命中、未命中、回退次数）。V$BT_SCAN_CACHE显示当前内容，而V$BTS_STAT显示历史活动，两者结合能提供完整视图。DBA_OBJECTS：通过OBJ#或DATAOBJ#关联，这是将缓存条目映射到具体表、分区名称的关键视图。V$PX_PROCESS：通过XDOP字段可能可以关联到并行从属进程的详细信息。V$BH：理论上，V$BT_SCAN_CACHE中缓存的块最终都会体现在V$BH中。但V$BH是底层所有缓冲区的列表，而V$BT_SCAN_CACHE是其上层的、面向BTC的逻辑视图。
-
**底层基表（X表）∗∗：‘V表）**： `V表）∗∗：‘VBT_SCAN_CACHE
的数据来源于Oracle内部用于管理BTC缓存段的内存数据结构。其底层关联的 **X$表** 是**不公开**的，可能与XKCBTSC‘或类似名称的内部结构相关。∗∗重要警告∗∗：严禁直接查询XKCBTSC` 或类似名称的内部结构相关。 **重要警告**：严禁直接查询XKCBTSC‘或类似名称的内部结构相关。∗∗重要警告∗∗：严禁直接查询X表。
5. 相关底层详细原理
-
缓存段（Cache Segment）管理：
BTC不是简单地将块放入普通的Buffer Cache链表。它会为每个被缓存的大表（或分区）创建一个逻辑上的缓存段。V$BT_SCAN_CACHE中的每一条记录就代表一个这样的缓存段。 -
并行缓存填充：
当优化器决定使用BTC时，缓冲区缓存并行从属进程（BCP - Buffer Cache Parallel） 会被启用。这些进程并行地扫描表，并直接将块读入Buffer Cache中专门管理的区域。XDOP字段就指向了负责此任务的进程。 -
智能替换策略：
这些缓存段中的块遵循特定的替换算法。它们不像传统FTS块那样被放在LRU末端，但也不是像KEEP池那样永久保留。其目标是在内存中为大型工作负载（workload）创建一个临时、共享的高效工作区，在工作负载完成后，这些空间可以被其他更急需的块回收。 -
数据收集：
Oracle内核在管理这些缓存段时，会实时维护其元数据（如缓存了多少块，扫描了多少块）。V$BT_SCAN_CACHE视图就是这些内存元数据的对外只读接口。实例重启后，这些信息会丢失。
6. 相关知识点介绍
-
触发条件：BTC并非对所有大表自动生效。需要满足：
- 表足够大（通常远大于Buffer Cache的5%）。
- 表被显式设置为
CACHE(ALTER TABLE ... CACHE) 或通过DBMS_STATS设置了缓存偏好。 - 优化器成本模型认为使用BTC比直接路径读取（DPR）更高效。
- 系统有可用的并行从属进程资源。
-
与直接路径读取（DPR）的权衡：
DPR将数据读入PGA，是私有、非共享的，适用于一次性大数据扫描。BTC将数据读入Buffer Cache，是共享的，适用于可能被多次扫描的大表。优化器会基于成本动态选择。 -
与缓冲池（KEEP/RECYCLE）的区别：
KEEP池是静态的、手动管理的，目的是永久保留对象。BTC是动态的、自动管理的，旨在为特定的工作负载提供临时的、高性能的缓存，工作负载完成后缓存空间可以被回收，更加灵活。
7. 常用查询 SQL
1. 查看当前缓存中的所有大表及其缓存效率（核心查询）
SELECT o.owner, o.object_name, o.subobject_name AS partition_name,
c.cached_blocks, c.scanned_blocks, c.percent_cached,
c.force_caching, c.xdop
FROM v$bt_scan_cache c
JOIN dba_objects o ON (c.dataobj# = o.data_object_id)
ORDER BY c.cached_blocks DESC;
2. 检查缓存效果不佳的对象（诊断问题）
SELECT o.owner, o.object_name, o.subobject_name AS partition_name,
c.cached_blocks, c.scanned_blocks, c.percent_cached
FROM v$bt_scan_cache c
JOIN dba_objects o ON (c.dataobj# = o.data_object_id)
WHERE c.percent_cached < 50 -- 缓存比例低于50%，可能有问题
OR (c.scanned_blocks > 1000 AND c.cached_blocks = 0) -- 扫描了很多却什么都没缓存
ORDER BY c.percent_cached ASC;
3. 计算BTC功能占用的总Buffer Cache空间
SELECT SUM(cached_blocks) total_cached_blocks,
ROUND(SUM(cached_blocks) * 8 / 1024, 2) AS total_cached_mb -- 假设块大小8K
FROM v$bt_scan_cache;
4. 查找被强制缓存（FORCE_CACHING）的对象
SELECT o.owner, o.object_name, o.subobject_name AS partition_name,
c.cached_blocks, c.scanned_blocks, c.percent_cached
FROM v$bt_scan_cache c
JOIN dba_objects o ON (c.dataobj# = o.data_object_id)
WHERE c.force_caching = 'YES';
通过深入掌握 V$BT_SCAN_CACHE 视图，您可以超越聚合统计，直接洞察Big Table Caching功能的实时工作状态，精确评估其效益，并有效地诊断与之相关的性能问题，确保这一高级特性为您的数据库带来最大化的性能提升。
欢迎关注我的公众号《IT小Chen》
扫一扫
929
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
