面试宝典: Oracle数据库latch: cache buffers chains 等待事件处理过程

原创于 2025-08-06 12:51:52 发布 · 1k 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #面试 #oracle

AI辅助_面试宝典专栏收录该内容

584 篇文章

订阅专栏

在这里插入图片描述
好的，我们来深入解析 Oracle 数据库中 latch: cache buffers chains 等待事件。这个事件是 Oracle 内核性能调优的核心，直接关系到 Buffer Cache 的管理效率，是 OLTP 系统中最常见、最重要的等待事件之一。

1. 什么是 `latch: cache buffers chains` 等待事件？

本质： 它表示一个会话正在尝试获取保护 Buffer Cache 中特定 Hash Bucket 的链 (Chain) 的 Cache Buffers Chains (CBC) 闩锁 (Latch)，但该闩锁当前已被其他会话持有。闩锁是为了保护内存数据结构完整性而设计的低级、轻量级、短时间持有的锁。
名字解析：
- latch:：表示这是一个闩锁等待事件。
- cache buffers chains：闩锁的名称，明确指向保护 Buffer Cache 中 Hash Chain 的闩锁。
核心概念：
- Buffer Cache： SGA 的核心组件，缓存从数据文件读取的数据块（buffer）。
- Hash Bucket 和 Chain： Oracle 使用 Hash 表管理 Buffer Cache。每个数据块的唯一标识 DBA (Data Block Address: file# + block#) 通过 Hash 函数计算后，映射到一个 Hash Bucket。每个 Bucket 对应一个双向链表 (Chain)，链表中挂着所有映射到该 Bucket 的 Buffer Headers (BH)。BH 是内存结构，描述对应 Buffer 的状态、位置、内容等信息。
- CBC 闩锁： 每个 Hash Bucket Chain 都有一个专门的 Cache Buffers Chains 闩锁 保护它。任何需要访问或修改某个 Chain 上 BH 的操作（如查找、读取、修改 BH 状态），都必须先获取该 Chain 对应的 CBC 闩锁。
- 闩锁特性：
  - 轻量级： 比 Enqueue 更轻量，设计用于保护非常短的操作。
  - 排他性： 大部分操作需要以独占模式 (Exclusive) 获取 CBC 闩锁（尤其是修改 BH 状态的操作，如 pin 一个 Buffer）。一次只能有一个会话持有某个 CBC 闩锁。
  - 自旋 (Spin)： 会话尝试获取闩锁时，如果失败，会先进行短暂的自旋 (Spin) - 在 CPU 上循环检查闩锁是否可用（消耗 CPU）。如果自旋多次后仍未获得，则进入睡眠 (sleep) 状态（记录为 latch free 或特定闩锁等待），等待被唤醒。latch: cache buffers chains 通常指进入睡眠后的等待。
  - 持有时间短： 理想情况下，CBC 闩锁应在微秒级别内被获取、操作、释放。长时间持有会导致严重争用。
为什么重要： 几乎所有访问 Buffer Cache 的操作（逻辑读 db block gets, consistent gets）都需要获取 CBC 闩锁。高并发访问或访问模式不当会使其成为瓶颈。
等待参数：
- P1：闩锁地址 (Address)。标识具体的 CBC 闩锁实例（因为 CBC 有多个子闩锁）。
- P2：闩锁编号 (Number)。对于 CBC，这个编号通常对应 Hash Bucket 的 ID。
- P3：尝试次数 (Tries)。会话在进入睡眠前尝试获取（包括自旋）的次数。

2. 产生的过程

当一个会话需要访问 Buffer Cache 中的数据块时（以逻辑读为例）：

计算 DBA 和 Hash： 会话确定要访问的数据块 DBA (file#, block#)，并通过 Hash 函数计算出对应的 Hash Bucket ID。
定位 Hash Chain： 根据 Bucket ID 找到对应的 Hash Chain。
请求 CBC 闩锁： 会话尝试以独占模式 (X) 获取保护该 Hash Chain 的 CBC 闩锁。
检查闩锁可用性：
- 可用： 如果该 CBC 闩锁当前没有被任何其他会话持有，会话立即成功获取闩锁。
- 不可用（争用）： 如果另一个会话正持有该 CBC 闩锁（在操作同一个 Chain 上的 Buffer Header），当前会话无法立即获取。
自旋 (Spin)： 会话在 CPU 上循环（自旋）多次（次数由隐含参数 _spin_count 决定），不断检查闩锁是否被释放。自旋期间消耗 CPU 周期，但不记录为等待事件。
自旋失败，进入睡眠： 如果自旋指定次数后仍未获得闩锁，会话停止自旋，进入睡眠 (sleep) 状态。
记录等待事件： 此时，会话记录 latch: cache buffers chains 等待事件，参数 P1, P2 (Bucket ID), P3 (尝试次数) 被设置。会话让出 CPU，等待被唤醒。
持有者释放闩锁： 持有该 CBC 闩锁的会话完成对 Hash Chain 的操作（如找到并 pin 住一个 Buffer Header）后，立即释放 CBC 闩锁。
唤醒等待者： 操作系统唤醒正在睡眠等待该 CBC 闩锁的会话。
再次尝试： 被唤醒的会话再次尝试获取 CBC 闩锁（可能再次经历自旋）。
成功获取： 一旦成功获取 CBC 闩锁，会话：
- 遍历 Hash Chain，查找目标 Buffer Header (BH)。
- 如果找到，检查 Buffer 状态（是否可用、是否需要构造 CR 块等）。
- Pin 住该 Buffer Header（增加 pin 计数，防止被移出 Cache），并标记为正在使用。
- 释放 CBC 闩锁！ (关键：操作完成后立即释放)
访问 Buffer： 会话现在可以安全地访问 Buffer 中的数据（在 pin 的保护下），进行逻辑读操作。Pin 的操作由其他机制（如 buffer pin 等待）保护，但与 CBC 闩锁无关。
释放 Buffer： 使用完 Buffer 后，会话 unpin 它（减少 pin 计数）。unpin 操作通常也需要获取 CBC 闩锁来修改 BH 状态。
提交/回滚： 逻辑读本身不涉及事务，无需提交。如果是修改（current 读），修改在 Buffer 中进行，事务提交时由 DBWn 写盘，但 CBC 闩锁早已释放。

3. 哪些场景会触发 `latch: cache buffers chains` 等待

主要发生在高并发访问 Buffer Cache，并且访问集中在少数几个“热”的 Hash Chain（即“热”数据块）上时：

高并发读取/修改热点块：
- 多个会话同时频繁读取或修改同一个数据块。常见例子：
  - 小表（整个表被缓存在少数几个块中）被高频访问。
  - 索引的根块 (Root Block) 或分支块 (Branch Block)（B-Tree 结构顶部块，访问路径必经）。
  - 频繁更新的行集中在少数几个块中（如序列生成的 PK 索引叶块 - "右增长"热点）。
  - 高频访问的静态数据（如配置表、代码表）。
低效 SQL 导致过多逻辑读：
- SQL 语句执行计划差（如全表扫描、索引效率低），需要访问大量数据块。
- 即使每个块访问次数不多，但总的逻辑读 (buffer gets) 极其巨大，导致访问大量不同的 Hash Chain，增加了碰到任何 CBC 闩锁冲突的概率。
硬解析 (Hard Parse) 风暴：
- 大量并发会话执行不同的 SQL 语句且无法共享游标（未绑定变量、cursor_sharing 设置等），导致频繁硬解析。
- 硬解析需要访问数据字典基表（如 tab$, col$, ind$, user$），这些表通常很小且缓存，它们的块成为热点，访问它们的 Hash Chain 的 CBC 闩锁争用加剧。
Buffer Cache 过大且 _db_block_hash_latches 不足：
- 随着 Buffer Cache (db_cache_size) 增大，Hash Bucket 的数量会增加（以保持平均 Chain 长度合理）。
- 但 CBC 闩锁的数量（子闩锁数）由隐含参数 _db_block_hash_latches 控制，默认值可能跟不上 Cache 的增长。
- 如果 CBC 闩锁数量太少，多个 Hash Bucket Chain 会共享同一个 CBC 子闩锁（一个闩锁保护多个 Chain），大大增加该闩锁的争用概率。
热点链扫描：
- 即使单个块不热，但如果一个 Hash Chain 很长（包含很多 Buffer Header），扫描这个长链本身需要持有 CBC 闩锁的时间变长，增加了其他会话等待该闩锁的时间。
- 长链通常由 _db_block_hash_buckets 设置不合理或 Hash 分布不均导致，但较少见。

4. 可能的原因

latch: cache buffers chains 争用的根源是 CBC 闩锁被持有时间过长或请求频率过高：

A. 真正的热点块 (最常见且影响最大)：
- 索引结构热点： 索引根块、分支块、使用序列生成的右增长索引叶块。
- 小表/高频访问表： 整个表数据集中在少量块中，被所有会话反复访问。
- 数据分布热点： DML 操作（INSERT/UPDATE/DELETE）集中在少数几个块（如按时间戳分区不当时，当前分区的块）。
B. 低效 SQL / 过多逻辑读：
- 全表扫描大表： 导致访问大量块，增加接触 CBC 闩锁的机会。
- 高 BUFFER_GETS 的 SQL： SQL 执行计划差（错误索引、嵌套循环驱动不当、笛卡尔积等），导致单次执行或总执行产生海量逻辑读。
- 未使用绑定变量 (硬解析 + 共享游标失效)： 不仅增加硬解析负担，访问字典基表热点块，还可能导致相同的 SQL 执行计划被反复硬解析和执行，逻辑读总量剧增。
C. 硬解析风暴：
- 应用未使用绑定变量： 导致大量不同文本的 SQL 进行硬解析。
- 频繁执行 DDL： 使依赖的 SQL 游标失效，触发重新解析。
- cursor_sharing = EXACT (默认) 且未绑定变量： 无法自动替换字面量。
- 共享池 (shared_pool_size) 不足或碎片化： 导致游标老化，需要重新硬解析。
D. CBC 闩锁数量不足：
- Buffer Cache (db_cache_size) 过大： 导致 Hash Bucket 增多，但 CBC 子闩锁数 (_db_block_hash_latches) 未相应增加，多个 Bucket 共享一个闩锁。
- _db_block_hash_latches 设置过低： 默认值（通常为 CPU 数量的 2 倍或 Cache 大小函数）在极端高并发或超大 Cache 下可能不足。
E. CPU 资源饱和：
- 虽然自旋本身消耗 CPU，但 CPU 饱和会导致自旋的会话持有 CPU 时间片更长，变相延长了它持有 CBC 闩锁的时间（如果它正持有），加剧其他会话的等待。这是一个相互影响的恶性循环。

5. 详细排查过程

排查的核心是：定位热点块 -> 分析热点块来源（对象、SQL）-> 针对性优化。

步骤 1: 确认问题与范围

识别 Top Wait Event: 查看 AWR/ASH 报告 (awrrpt.sql, ashtop.sql)。确认 latch: cache buffers chains 是否在系统级别是主要等待事件。记录其 Total Wait Time (s) 和 Avg Wait (ms)。注意闩锁等待通常看 Wait Time (s) 和 Wait Count。
查看 Latch 统计 (AWR)：
- 在 AWR 报告的 “Latch Statistics” 部分找到 cache buffers chains。
- 关注：
  - Get Requests: 总请求次数 (极高)
  - Pct Get Miss: 未立即获取的比例 (理想 < 1-2%)
  - Avg Slps/Miss: 每次 Miss 的平均睡眠次数 (理想接近 0)
  - Avg Sleeps: 平均睡眠次数 (高说明争用严重)
  - Wait Time (s): 总等待时间
关联负载： 查看 “Load Profile” 的 Logical reads (blocks / recursive calls), Executions, Parse (hard, total) 是否异常高。

步骤 2: 定位热点 CBC 闩锁和热点块 (关键)

目标：找到最繁忙（争用最严重）的 CBC 子闩锁，进而找到它保护的 Hash Chain 上的热点块。

查询当前持有/等待 CBC 闩锁的会话 (实时):

SELECT s.sid, s.serial#, s.username, s.sql_id, s.event, s.p1, s.p2, s.p3,
       s.blocking_session, s.blocking_session_serial#,
       (SELECT object_name FROM dba_objects WHERE object_id = bh.objd) AS object_name, -- 可能不准
       bh.dbarfil, bh.dbablk, bh.tch, bh.class, bh.state, bh.mode_held, bh.forced_reads, bh.forced_writes
FROM v$session s
LEFT JOIN v$latchholder lh ON (s.sid = lh.sid AND lh.name = 'cache buffers chains')
LEFT JOIN x$bh bh ON ( -- 关联当前会话正在访问的块 (可能)
      bh.hladdr = LPAD(TRIM(TO_CHAR(s.p1, 'XXXXXXXX')), 8, '0') -- 将 P1 (地址) 转换为 8 位 16 进制串
      AND bh.dbarfil = s.row_wait_file# -- 通常不准确，不如用 P1/P2 定位闩锁
      AND bh.dbablk = s.row_wait_block#
)
WHERE s.event = 'latch: cache buffers chains'
   OR (lh.sid IS NOT NULL); -- 或正在持有 CBC 闩锁的会话

分析 s.p2：这是 Hash Bucket ID。记录高频出现的 p2 值，它们对应热门的 Bucket。
bh.tch： Touch Count，表示该 Buffer 被访问的次数（近似热度）。如果关联成功，高 tch 值指示热点块。
bh.dbarfil, bh.dbablk：数据块地址 (file#, block#)。
s.sql_id：导致等待的 SQL。

查询最繁忙的 CBC 子闩锁 (历史/实时)：

-- 查询 v$latch_children (实时)
SELECT child#, addr, gets, misses, sleeps, spin_gets, wait_time, latch_hit_ratio
FROM v$latch_children
WHERE name = 'cache buffers chains'
ORDER BY sleeps DESC, misses DESC, gets DESC; -- 按 Sleeps (睡眠次数) 或 Misses (未命中次数) 排序找最热
-- 或查询 dba_hist_latch (AWR 历史)
SELECT snap_id, instance_number, latch_name, child#, sleeps_delta, misses_delta, gets_delta
FROM dba_hist_latch
WHERE latch_name = 'cache buffers chains'
  AND snap_id BETWEEN &start_snap_id AND &end_snap_id
ORDER BY sleeps_delta DESC;

找到 sleeps 或 misses 最高的 child#。这个 child# 对应的子闩锁保护着多个 Hash Bucket Chain。
记录 child# 和 addr (地址，对应会话等待的 P1)。

定位热点块 (最热门的 Buffer Header)： 使用步骤 2 中找到的热门子闩锁地址 (addr)。

SELECT bh.dbarfil AS file#, bh.dbablk AS block#,
       bh.tch, -- Touch Count (热度)
       bh.obj AS objd, -- Data Object ID
       bh.class, bh.state, bh.mode_held,
       o.owner, o.object_name, o.object_type, o.subobject_name AS partition_name,
       COUNT(*) AS buffers_in_chain -- 该 Chain 上的 Buffer 数量 (链长)
FROM x$bh bh
LEFT JOIN dba_objects o ON (bh.obj = o.data_object_id) -- 关联对象 (data_object_id)
WHERE bh.hladdr = LPAD(TRIM(TO_CHAR(&hot_latch_addr, 'XXXXXXXX')), 8, '0') -- 替换为热门子闩锁地址 (16进制)
GROUP BY bh.dbarfil, bh.dbablk, bh.tch, bh.obj, bh.class, bh.state, bh.mode_held,
         o.owner, o.object_name, o.object_type, o.subobject_name
ORDER BY bh.tch DESC, buffers_in_chain DESC; -- 按 Touch Count 降序排列

核心输出： file#, block# (热点块地址)，tch (触摸次数，越高越热)，owner, object_name, object_type, partition_name (热点块所属对象)。
buffers_in_chain：如果很高，表明该 Chain 很长，扫描它需要更长时间持有 CBC 闩锁。
如果 o.object_name 是 NULL，可能是数据字典基表（tab$, col$ 等，表明硬解析问题）或撤销块/段头等特殊块。

关联热点块到具体对象和段： 使用 file# 和 block#。

SELECT e.owner, e.segment_name, e.segment_type, e.partition_name, e.tablespace_name
FROM dba_extents e
WHERE &target_file_id BETWEEN e.file_id AND e.file_id + e.blocks - 1 -- 文件号范围
  AND &target_block_id BETWEEN e.block_id AND e.block_id + e.blocks - 1; -- 块号范围
-- 替换 &target_file_id 和 &target_block_id 为步骤 3 中的 file# 和 block#

确认热点块属于哪个段（表、索引、分区）。

步骤 3: 分析热点块来源和 SQL

分析热点对象：
- 索引根/分支块： 如果热点块属于索引（segment_type = 'INDEX' 或 index 开头），且 block# 很小（如 1, 2, 3），很可能是根块或分支块。
- 右增长索引叶块： 如果索引使用序列生成主键，热点块通常是索引最右边的叶块 (leaf block)。
- 小表： 查询 dba_segments 看对象大小 (bytes, blocks)。如果很小（几 MB 甚至 KB），整个表可能就是热点。
- 数据字典基表 (objd 高且 object_name 空)： 表明硬解析问题。

查找访问热点对象的 SQL： 结合 ASH 数据。

SELECT ash.sql_id, s.sql_text, ash.sql_plan_operation, ash.sql_plan_options,
       COUNT(*) AS buffer_access_samples, -- 近似访问次数
       SUM(ash.tm_delta_db_time) AS db_time_used
FROM dba_hist_active_sess_history ash
JOIN dba_hist_sqltext s ON (ash.sql_id = s.sql_id AND ash.dbid = s.dbid)
WHERE ash.event = 'latch: cache buffers chains'
  AND ash.sample_time BETWEEN ... AND ...
  AND ash.current_obj# IN ( -- 替换为热点对象的 object_id (从 dba_objects 查)
      SELECT object_id FROM dba_objects
      WHERE owner = '&hot_owner' AND object_name = '&hot_object')
GROUP BY ash.sql_id, s.sql_text, ash.sql_plan_operation, ash.sql_plan_options
ORDER BY buffer_access_samples DESC, db_time_used DESC;

找到最频繁访问热点对象的 SQL。

分析 SQL 执行计划：
- 获取步骤 2 中找到的 SQL 的执行计划 (EXPLAIN PLAN, DBMS_XPLAN.DISPLAY_CURSOR, AWR SQL 报告)。
- 关键检查：
  - 访问路径： 是否使用了预期索引？是否走了全表扫描？索引扫描范围是否过大？
  - 嵌套循环： 如果使用 Nested Loops Join，驱动表返回行数 (Rows) 是否过多？被驱动表访问次数是否巨大？
  - 逻辑读 (Buffers)： 执行计划中的 Buffers 或实际执行的 buffer_gets (AWR) 是否非常高？
  - 绑定变量： SQL 文本是否使用了绑定变量 (:1)？还是大量字面量？查看 AWR “SQL ordered by Gets” 是否有大量相似 SQL（不同字面量）。
检查硬解析情况 (AWR)：
- “Load Profile”: 高 Hard Parses/s。
- “Instance Efficiency Percentages”: 低 Parse CPU to Parse Elapsd % (<95%) 表示解析花费时间在等待上（可能包括 CBC 争用）。
- “SQL Statistics” -> “SQL ordered by Parse Calls”: 高频解析的 SQL。
- “Shared Pool Statistics”: 高 Reloads, Invalidations。

步骤 4: 检查 CBC 闩锁配置和 CPU

检查 CBC 相关参数：
```
SHOW PARAMETER db_cache_size
SHOW PARAMETER db_block_size
-- 隐含参数 (需谨慎查询，通常不建议修改)
SELECT x.ksppinm name, y.ksppstvl value
FROM x$ksppi x, x$ksppcv y
WHERE x.indx = y.indx
  AND x.ksppinm IN ('_db_block_hash_buckets', '_db_block_hash_latches', '_spin_count');
```
- 计算 _db_block_hash_latches 值。默认通常是 2 * CPU_COUNT 或 power(2, trunc(log(2, db_cache_size / _db_block_buffers)) * 2) 之类。如果 db_cache_size 很大 (如 > 100GB) 而 _db_block_hash_latches 很小 (如 8192)，可能不足。
- 计算平均每个子闩锁保护的 Bucket 数： _db_block_hash_buckets / _db_block_hash_latches。如果远大于 1 (如 > 100)，说明闩锁覆盖范围过大。
检查 CPU 使用率 (AWR/OS)：
- AWR “Operating System Statistics”: 高 BUSY_TIME, 低 IDLE_TIME。
- AWR “Host CPU”: 高 %User, %System。
- OS 工具 (top, vmstat, mpstat): CPU 利用率是否饱和 (接近 100%)？us (用户态) 和 sy (内核态) 是否高？

步骤 5: 综合分析与解决方案

根据根本原因采取针对性措施：

1. 解决真正的热点块：
- 反转键索引 (Reverse Key Index)： 对序列主键索引使用反转键，将右增长的热点打散到不同的索引叶块。
```
CREATE INDEX ... ON ... (id) REVERSE; -- 重建现有索引
```
  - 代价： 牺牲范围扫描 (WHERE id BETWEEN ...) 性能。仅适用于纯插入/等值查询场景。
- 分区 (Partitioning)： 对大表/热表进行分区（如 Range, Hash）。将插入/更新负载分散到多个分区段（每个分区有自己的索引结构），减少单个索引或数据块的热度。最有效的通用方案之一。
- 增加序列缓存 (SEQUENCE CACHE)： 确保主键序列设置了足够大的 CACHE (如 CACHE 1000)，减少获取序列值时对序列 rowcache 和底层块的争用（虽然序列本身不是 CBC 热点，但相关索引块是）。
```
CREATE SEQUENCE ... CACHE 1000;
ALTER SEQUENCE ... CACHE 1000;
```
- 优化数据分布： 如果更新集中在少数行，尝试调整应用逻辑或分区键分散更新。
- 避免小表全扫： 对小表进行全表扫描也会访问其所有块（热点），确保相关查询走索引（如果存在且高效）。
2. 优化 SQL，减少逻辑读：
- 优化执行计划：
  - 收集最新准确的统计信息 (DBMS_STATS)。
  - 创建缺失的、高选择性的索引。
  - 优化连接顺序和方法（避免笛卡尔积，优化 Nested Loops 驱动表）。
  - 使用 SQL Plan Baseline / SQL Profile 固定好的计划。
  - 重写低效 SQL。
- 减少执行次数： 优化应用逻辑，避免不必要的 SQL 执行或循环内执行 SQL。
- 绑定变量： 强制使用绑定变量！ 这是解决硬解析和共享游标问题的关键。
  - 修改应用代码使用绑定变量 (PreparedStatement in Java, bind in PL/SQL)。
  - 评估设置 cursor_sharing = FORCE (谨慎，测试影响)。但这只是治标，修改应用是根本。
3. 解决硬解析风暴：
- 绑定变量： 同上，最根本的解决方案。
- 优化共享池：
  - 确保 shared_pool_size 足够大（参考 AWR 建议）。
  - 考虑使用 shared_pool_reserved_size。
  - 对于大型 OLTP，可考虑使用 AMM/ASMM 或手动管理确保共享池充足。
  - 避免频繁执行 DDL。
- 使用游标共享 (cursor_sharing)： 仅在无法修改应用时考虑 FORCE 或 SIMILAR (已废弃)，并充分测试。
4. 调整 CBC 闩锁数量 (谨慎！)： 仅在其他优化后仍有争用，且确认闩锁数量是瓶颈时考虑。
- 计算建议值（非精确）：通常建议 _db_block_hash_latches 是 power(2, ceil(log(2, _db_block_hash_buckets / (small_number like 16 or 32))))。更安全的方法是参考 MOS 文档或逐步增加观察。
- 在测试环境进行！
- 逐步增加： 每次增加一定量（如 25%），监控 latch free 和 CPU 变化。
- 设置隐含参数：
```
ALTER SYSTEM SET "_db_block_hash_latches" = <new_value> SCOPE=SPFILE; -- 需要重启
```
- 代价： 增加闩锁数量会消耗少量额外内存，并可能略微增加获取闩锁的平均开销（遍历闩锁数组）。过多闩锁也可能导致 CPU 开销上升。平衡是关键。
5. 增加 CPU / 优化 CPU 使用：
- 升级硬件（更多/更快 CPU）。
- 优化其他消耗 CPU 的等待事件（如 latch free 其他类型、log file sync、高逻辑读 SQL）。
- 确保操作系统和 BIOS 设置优化（CPU 电源管理、中断平衡）。

关键诊断视图与脚本总结

Latch 统计： V$LATCH, V$LATCH_CHILDREN (核心), DBA_HIST_LATCH
Buffer Header： X$BH (核心，定位热点块), V$BH (有限)
会话与等待： V$SESSION, V$SESSION_WAIT, V$ACTIVE_SESSION_HISTORY (核心), DBA_HIST_ACTIVE_SESS_HISTORY
对象与段： DBA_OBJECTS (连接 X$BH.obj), DBA_EXTENTS (定位块所属段)
SQL： V$SQL, V$SQLTEXT, DBA_HIST_SQLTEXT, DBA_HIST_SQLSTAT
参数： V$PARAMETER, V$SYSTEM_PARAMETER, X$KSPPI, X$KSPPCV