好的，我们来对 Oracle 19C 数据库中一个相对晦涩但功能特定的动态性能视图——V$BTS_STAT——进行详细的解析。
这个视图的名称 BTS 是 Big Table Caching Statistics 的缩写。它是 Oracle 12c 引入的 Big Table Caching 特性的重要组成部分，用于监控和统计该特性的使用情况和效果。
1. 视图概述与核心作用
V$BTS_STAT 动态性能视图的作用是提供关于数据库中"大表缓存"（Big Table Caching）操作的统计信息和性能指标。
Big Table Caching (BTC) 是 Oracle 的一项优化功能，旨在改善对大型表的全表扫描（Full Table Scans, FTS）性能。传统上，全表扫描的块会放置在 Buffer Cache 的 LRU 列表的末端，很快就会被淘汰。BTC 允许将指定的大表的全表扫描块更智能地缓存在 Buffer Cache 中，甚至可以将其并行直接缓存到多个缓冲区池从属进程（BCP - Buffer Cache Parallel）中，从而显著提升大规模扫描操作的性能。
核心作用可以概括为：
- 性能监控：跟踪和衡量 Big Table Caching 特性的效果，例如缓存命中次数、未命中次数、直接路径读取fallback次数等。
- 优化验证：验证通过
ALTER TABLE ... CACHE或DBMS_STATS.SET_TABLE_PREFS将表标记为CACHE后，是否真的带来了性能收益。 - 问题诊断：当基于大表的查询性能未达预期时，通过此视图判断 BTC 功能是否正常生效，或者是否发生了回退到传统直接路径读取的情况。
2. 使用场景
-
数据仓库查询调优：
在 DSS（决策支持系统）或数据仓库环境中，经常需要对大型事实表进行全表扫描。DBA 在启用大表缓存后，使用此视图来确认扫描是否利用了缓存，并评估性能提升幅度。 -
ETL 过程优化：
在ETL（提取、转换、加载）过程中，如果存在对大表的全扫描操作，启用BTC并监控此视图，可以减少I/O压力，加速ETL流程。 -
容量规划与行为分析：
通过统计信息，了解系统中有多少大表扫描活动可以从BTC中受益，从而为Buffer Cache的大小规划提供数据支持。 -
故障排除：
如果一个被标记为CACHE的大表查询仍然很慢，查询此视图可以检查FALLBACK_COUNT等字段，判断是否由于内存不足等原因导致优化器放弃了缓存策略，转而使用直接路径读取。
3. 字段详细含义
V$BTS_STAT 视图的字段直接反映了 BTC 操作的计数和状态。
| 字段名 | 数据类型 | 含义说明 |
|---|---|---|
| HIT_COUNT | NUMBER | 缓存命中次数。表示全表扫描请求的块已经在Buffer Cache中找到的次数。这是BTC成功运作的主要指标，高的命中率意味着显著的性能提升。 |
| MISS_COUNT | NUMBER | 缓存未命中次数。表示全表扫描需要读取块，但该块不在Buffer Cache中的次数。 |
| SKIP_COUNT | NUMBER | 跳过次数。表示由于各种原因（如内存压力、并发限制），Big Table Caching 功能被跳过，直接使用传统方式（直接路径读取或常规缓存）执行扫描的次数。 |
| FALLBACK_COUNT | NUMBER | 回退次数。这是一个重要的诊断指标。表示优化器最初决定使用BTC，但在执行过程中由于条件不满足（如无法获取并行从属进程）而不得不回退到直接路径读取的次数。高回退次数表明环境配置可能有问题。 |
| FULL_SCAN_COUNT | NUMBER | 全表扫描次数。尝试使用Big Table Caching功能进行全表扫描的总次数。 |
| BUCKET_COUNT_1 … BUCKET_COUNT_10 | NUMBER | 直方图桶计数。这些字段将扫描的表按其大小（或另一个维度）分成10个桶，并记录落入每个桶内的表的数量。用于分析哪种大小的表最常使用此特性。 |
| CON_ID | NUMBER | 所在容器的ID。在多租户环境（CDB）中，标识这些统计信息属于哪个可插拔数据库（PDB）。对于CDB$ROOT，此值为0。 |
4. 相关视图与基表
-
相关动态性能视图：
V$BTSC_CACHE_STAT：提供更细粒度的、当前正在被缓存的具体大表的信息，如表名、缓存的块数等。V$BTS_STAT显示的是聚合统计，而V$BTSC_CACHE_STAT显示的是当前缓存的内容。V$SQL/V$SQLAREA：通过这些视图可以找到正在执行全表扫描的SQL语句（DISK_READS,BUFFER_GETS,IO_CELL_OFFLOAD_ELIGIBLE_BYTES），并与BTC统计信息关联分析。DBA_TABLES：用于查看哪些表的CACHE属性被设置为YES，即哪些表是BTC的候选对象。
-
**底层基表（X表）∗∗：‘V表）**： `V表）∗∗：‘VBTS_STAT
的数据来源于Oracle内部用于跟踪BTC活动的内存数据结构。其底层关联的 **X$表** 通常是**不公开**的，可能与XKCBBTS‘或类似名称的内部结构相关。∗∗重要警告∗∗：严禁直接查询XKCBBTS` 或类似名称的内部结构相关。 **重要警告**：严禁直接查询XKCBBTS‘或类似名称的内部结构相关。∗∗重要警告∗∗：严禁直接查询X表。
5. 相关底层详细原理
-
传统全表扫描的问题：
传统上，全表扫描的块被放入Buffer Cache的LRU列表的末端（冷端），很容易被快速淘汰。这对于小型查询不是问题，但对于扫描GB级别的大表，这会“污染”整个Buffer Cache，挤掉所有热点工作集（Working Set），而且自己也没能有效缓存。 -
Big Table Caching 的工作机制：
- 识别：优化器识别出查询要对一个被标记为
CACHE的大表进行全表扫描。 - 并行缓存：与传统方式不同，BTC可以启动缓冲区缓存并行从属进程（BCP），并行地将表块直接读入Buffer Cache的中间（暖端），而不是末端。
- 智能放置：这些块被更智能地管理，它们不会不公平地占用缓存，但会比传统FTS的块停留更久，从而为后续的扫描操作服务。
- 决策：优化器会根据表的大小、并发程度、内存压力等因素动态决定是使用BTC还是回退到直接路径读取。
- 识别：优化器识别出查询要对一个被标记为
-
V$BTS_STAT的填充：
每次数据库考虑或使用BTC机制时，都会在SGA中更新相应的计数器。V$BTS_STAT视图就是对这组内存计数器的直接映射。实例重启后，这些计数器会被重置。
6. 相关知识点介绍
-
启用Big Table Caching：
有两种主要方式告诉Oracle一个表应被考虑用于BTC：-- 方法1: 使用ALTER TABLE (持久化) ALTER TABLE my_large_table CACHE; -- 方法2: 使用DBMS_STATS (设置统计信息偏好) BEGIN DBMS_STATS.SET_TABLE_PREFS('MY_SCHEMA', 'MY_LARGE_TABLE', 'INCREMENTAL', 'TRUE'); DBMS_STATS.SET_TABLE_PREFS('MY_SCHEMA', 'MY_LARGE_TABLE', 'TABLE_CACHED_BLOCKS', <block_count>); END; /TABLE_CACHED_BLOCKS指示应缓存多少块，通常设置为一个很大的值。 -
与直接路径读取的关系：
直接路径读取（DPR）是另一种优化，它绕过Buffer Cache直接将数据读入PGA，适用于非常大的扫描。BTC和DPR是两种竞争策略。优化器会基于成本决定使用哪种。BTC的目标是在内存中创建一个共享的、可重用的缓存，而DPR是为了一次性使用的私有读取。 -
与缓冲池（KEEP/RECYCLE）的区别：
KEEP池是手动管理的，目的是永久保留对象。BTC是自动和动态的，它基于最近使用情况，旨在为大型扫描提供临时、高效的缓存，不会长期独占内存。
7. 常用查询 SQL
1. 查看Big Table Caching的总体效果（核心查询）
SELECT hit_count, miss_count, skip_count, fallback_count, full_scan_count,
-- 计算缓存命中率，这是最重要的效率指标
ROUND(DECODE((hit_count + miss_count), 0, 0,
hit_count / (hit_count + miss_count) * 100), 2) AS hit_ratio_pct
FROM v$bts_stat;
HIT_RATIO_PCT 越高，说明BTC效果越好。如果很低，说明表可能不适合缓存，或者内存压力太大。
2. 检查回退情况（诊断问题）
SELECT fallback_count, full_scan_count,
ROUND(DECODE(full_scan_count, 0, 0,
fallback_count / full_scan_count * 100), 2) AS fallback_ratio_pct
FROM v$bts_stat;
如果 FALLBACK_RATIO_PCT 很高，说明系统经常无法满足BTC的条件（如并行从属进程不足），需要调查系统配置。
3. 结合 V$BTSC_CACHE_STAT 查看当前缓存了哪些大表
SELECT s.owner, s.name, s.partition_name, s.cached_blocks, s.scanned_blocks,
s.percent_cached, s.force_caching
FROM v$btsc_cache_stat s;
4. 查找系统中哪些表被设置为使用CACHE属性（候选表）
SELECT owner, table_name, blocks, cache
FROM dba_tables
WHERE cache = 'YES'
AND blocks > 10000 -- 只查询较大的表
ORDER BY blocks DESC;
通过深入理解 V$BTS_STAT 视图，您可以有效地监控和优化针对大型表的全表扫描操作，确保您的系统能够智能地利用 Buffer Cache 来提升大规模数据查询的性能，特别是在数据仓库和BI环境中，这项功能的价值尤为突出。
欢迎关注我的公众号《IT小Chen》
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
