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

好的，我们来深入探讨 Oracle 19C 中一个极为重要的性能视图：V$UNDOSTAT。这个视图是监控和管理 Automatic Undo Management (AUM) 的核心工具，它提供了 UNDO 表空间使用情况和事务活动的历史统计信息。

📊 深入解析 Oracle 19C 的 V$UNDOSTAT 视图

1. 视图概述与核心作用

V$UNDOSTAT 是一个动态性能视图，它以每10分钟为一个间隔，记录过去 24 小时（共 144 个10分钟间隔）内 UNDO 表空间的详细使用统计信息。

• 核心作用：用于监控、诊断和优化 Automatic Undo Management (AUM)。它帮助 DBA 回答以下关键问题：
  • UNDO 表空间的使用趋势如何？是否面临空间压力？
  • 系统是否产生了“ORA-01555: snapshot too old”错误？为什么？
  • 当前设置的 UNDO_RETENTION 参数是否足够满足系统的读写一致性需求？
  • 哪些时间点是事务的高峰期，对 UNDO 空间消耗最大？

它本质上是 Oracle 自动工作负载仓库（AWR）在 UNDO 管理方面的一个精细化、实时化的缩影。

2. 核心字段详解

以下是该视图最关键的字段，其格式已严格调整以确保清晰易读。

字段名	数据类型	描述
BEGIN_TIME	DATE	时间间隔的开始时间。每个记录代表从 BEGIN_TIME 开始的一个10分钟统计周期。
END_TIME	DATE	时间间隔的结束时间。即 BEGIN_TIME + 10分钟。
UNDOTSN	NUMBER	活动 UNDO 表空间的时间戳编号。用于内部管理。
UNDOBLKS	NUMBER	在本时间间隔内，事务消耗的 UNDO 块总数。这是衡量 UNDO 生成速率的核心指标。SUM(UNDOBLKS) 可以估算总 UNDO 使用量。
TXNCOUNT	NUMBER	在本时间间隔内执行的事务总数。反映了数据库的事务负载。
MAXQUERYLEN	NUMBER	本时间间隔内，活动事务产生的最长查询的执行时间（秒）。这是诊断 ORA-01555 错误最关键的字段。如果这个值超过了 UNDO_RETENTION，则长时间查询很可能因 UNDO 被覆盖而失败。
MAXCONCURRENCY	NUMBER	本时间间隔内，最大的并发事务数。
UNXPSTEALCNT	NUMBER	为了满足新事务的空间请求，系统不得不“窃取”未过期（UNexpired）的 UNDO 扩展段的次数。非零值是一个警告信号，表明 UNDO 表空间可能存在空间压力，Oracle 正在强制重用未过期的 UNDO 空间。
UNXPBLKRELCNT	NUMBER	通过“窃取”未过期（UNexpired）的 UNDO 扩展段而释放的块数。与 UNXPSTEALCNT 相关。
UNXPBLKREUCNT	NUMBER	通过“重用”未过期（UNexpired）的 UNDO 扩展段而重用的块数。
EXPSTEALCNT	NUMBER	为了满足新事务的空间请求，系统“窃取”已过期（Expired）的 UNDO 扩展段的次数。这是一个正常且期望发生的行为，因为过期空间本就是用于重用的。
EXPBLKRELCNT	NUMBER	通过“窃取”已过期（Expired）的 UNDO 扩展段而释放的块数。
EXPBLKREUCNT	NUMBER	通过“重用”已过期（Expired）的 UNDO 扩展段而重用的块数。
SSOLDERRCNT	NUMBER	在本时间间隔内，发生的 ORA-01555 (Snapshot Too Old) 错误的数量。这是最直接的问题指示器，任何非零值都意味着需要调整 UNDO 配置（增大 UNDO_RETENTION 或 UNDO 表空间）。
NOSPACEERRCNT	NUMBER	在本时间间隔内，因无法在 UNDO 表空间中分配空间而发生的错误数量。非零值是一个严重警报，表明 UNDO 表空间严重不足，必须立即扩容或优化。
ACTIVEBLKS	NUMBER	本时间间隔内，活动事务对应的 UNDO 块数（尚未提交或回滚）。
UNEXPIREDBLKS	NUMBER	本时间间隔内，未过期的 UNDO 块数（事务已提交，但保留时间未超过 UNDO_RETENTION）。
EXPIREDBLKS	NUMBER	本时间间隔内，已过期的 UNDO 块数（事务已提交，且保留时间已超过 UNDO_RETENTION）。这些空间可以被新事务安全地覆盖。
TUNED_UNDORETENTION	NUMBER	Oracle 自动为系统调整出的 UNDO 保留时间（秒）。在 AUM 模式下，即使你设置了 UNDO_RETENTION，Oracle 也可能根据 UNDO 表空间大小和活动峰值自动调高此值以防止 ORA-01555 错误。

3. 工作原理与底层机制

3.1 Automatic Undo Management (AUM) 简介

Oracle 的 AUM 机制自动管理 UNDO 表空间，DBA 只需设置 UNDO_RETENTION 参数和目标 UNDO 表空间。Oracle 后台进程 SMON 和 DBWn 等负责：

1. 为活动事务分配 UNDO 段。
2. 在事务提交后，根据 UNDO_RETENTION 和当前系统负载，标记 UNDO 空间为 EXPIRED（可重用）或 UNEXPIRED（应保留）。
3. 当需要空间时，优先重用 EXPIRED 空间。如果 EXPIRED 空间不足，则会尝试重用 UNEXPIRED 空间（UNXPSTEALCNT 增加），这可能威胁到一致性读。

3.2 V$UNDOSTAT 的底层原理

V$UNDOSTAT\ast \ast 的数据来源于SGA中关于UNDO段和事务活动的实时统计信息。其底层与\ast \ast X$KTUXE（事务条目）、**X$KTCXB\ast \ast （事务上下文）等X$ 表密切相关。

• 采样机制：Oracle 内核持续监控所有 UNDO 段的状态。MMON 等管理进程每10分钟将这些统计数据快照一次，并写入 V$UNDOSTAT 视图所对应的内存结构中。
• 数据生命周期：由于是内存结构，它只保留最近 24小时（144条） 的数据。更长期的历史数据需要通过 DBA_HIST_UNDOSTAT 视图从 AWR 仓库中查询。
• TUNED_UNDORETENTION：这是 AUM 的一个智能特性。当系统检测到存在长时间运行的查询（MAXQUERYLEN 很高）时，为了避免 ORA-01555，它会自动忽略UNDO_RETENTION 的参数设置，而是根据 MAXQUERYLEN 和当前 UNDO 表空间大小动态计算并维持一个更长的保留时间，此值就记录在 TUNED_UNDORETENTION 中。

4. 主要应用场景

4.1 诊断和预防 ORA-01555 (Snapshot Too Old) 错误

这是 V$UNDOSTAT 最经典的应用。

-- 检查历史上是否发生过 ORA-01555 错误
SELECT
    TO_CHAR(begin_time, 'YYYY-MM-DD HH24:MI') AS begin_time,
    TO_CHAR(end_time, 'YYYY-MM-DD HH24:MI') AS end_time,
    maxquerylen,
    tuned_undoretention,
    ssolderrcnt
FROM
    v$undostat
WHERE
    ssolderrcnt > 0
ORDER BY
    begin_time DESC;

-- 分析为什么会发生：比较最大查询长度和UNDO保留时间
SELECT
    begin_time,
    end_time,
    maxquerylen AS "Longest Query (sec)",
    tuned_undoretention AS "Tuned Retention (sec)",
    CASE WHEN maxquerylen > tuned_undoretention THEN 'YES' ELSE 'NO' END AS "5555 Risk?"
FROM
    v$undostat
ORDER BY
    begin_time DESC;

4.2 评估 UNDO 表空间大小是否合适

评估 UNDO 表空间是否足够，或者为新的生产系统规划 UNDO 表空间大小。

-- 计算最近24小时内，每个10分钟间隔生成的最大UNDO数据量（MB）
-- 这有助于确定UNDO表空间的最小合理大小
SELECT
    ROUND(MAX(undoblks * (SELECT value FROM v$parameter WHERE name = 'db_block_size') / 1024 / 1024), 2) AS max_undo_size_mb_per_10min
FROM
    v$undostat;

-- 查看UNDO空间压力历史
SELECT
    TO_CHAR(begin_time, 'MM-DD HH24:MI') AS time,
    unxpstealcnt,
    expstealcnt,
    ssolderrcnt,
    nospaceerrcnt
FROM
    v$undostat
ORDER BY
    begin_time DESC;

4.3 确定合理的 UNDO_RETENTION 参数

根据系统实际负载来设置 UNDO_RETENTION，而不是盲目猜测。

-- 建议将UNDO_RETENTION设置为至少等于过去24小时内的最大查询时间
SELECT
    ROUND(MAX(maxquerylen) * 1.2) AS suggested_undoretention_sec -- 增加20%的安全缓冲
FROM
    v$undostat;

5. 相关视图与关联查询

视图名称	描述	关联关系
DBA_HIST_UNDOSTAT	AWR 中存储的 V$UNDOSTAT 历史数据。用于长期性能趋势分析。	字段与 V$UNDOSTAT 几乎完全相同。
V$UNDOSTAT	当前实例的最近24小时 UNDO 统计信息。	-
V$ROLLSTAT	显示当前所有 UNDO 段（回滚段）的实时性能统计信息。	提供更细粒度的、实时的段级信息。
V$TRANSACTION	显示当前所有活动事务的信息。	**V$UNDOSTAT\ast \ast 中的‘ACTIVEBLKS‘是\ast \ast V$TRANSACTION中所有事务的USED_UBLK` 的总和。
DBA_TABLESPACES	表空间信息，用于确认 UNDO 表空间是否处于 AUTOMATIC 管理模式。	CONTENTS = 'UNDO' 且 RETENTION = 'GUARANTEE'/NOGUARANTEE

常用综合查询：UNDO 健康检查报告

COLUMN begin_time FORMAT A20
COLUMN end_time FORMAT A20
COLUMN "Undo MB" FORMAT 999999.99
COLUMN "Active Blks" FORMAT 99999999
COLUMN "Longest Query" FORMAT 999999
COLUMN "Tuned Retention" FORMAT 999999
COLUMN "5555 Errors" FORMAT 999

SELECT
    TO_CHAR(begin_time, 'MM-DD HH24:MI') AS begin_time,
    TO_CHAR(end_time, 'HH24:MI') AS end_time,
    ROUND(undoblks * (SELECT value FROM v$parameter WHERE name = 'db_block_size') / 1024 / 1024, 2) AS "Undo MB",
    activeblks AS "Active Blks",
    maxquerylen AS "Longest Query",
    tuned_undoretention AS "Tuned Retention",
    ssolderrcnt AS "5555 Errors",
    unxpstealcnt AS "Unxp Steals"
FROM
    v$undostat
WHERE
    begin_time > SYSDATE - 1 / 24 -- 查看最近1小时的数据
ORDER BY
    begin_time DESC;

6. 关键知识点总结

1. 监控核心：V$UNDOSTAT 是 Oracle AUM 的核心监控视图，任何与 UNDO 相关的性能调优和故障诊断都应从此视图开始。
2. 三个关键计数：
   • SSOLDERRCNT：直接告诉你是否发生了问题。
   • UNXPSTEALCNT：提前警告你空间可能不足。
   • NOSPACEERRCNT：告诉你已经发生了严重问题。
3. 一个关键长度：MAXQUERYLEN 是决定 UNDO_RETENTION 和诊断 ORA-01555 的最重要依据。
4. 自动调优：Oracle 的 TUNED_UNDORETENTION 机制意味着你设置的 UNDO_RETENTION 可能只是一个下限值。Oracle 会根据需要自动延长它。
5. 历史分析：对于长期趋势分析，务必使用 DBA_HIST_UNDOSTAT 视图。
6. 空间规划：使用 UNDOBLKS 的历史最大值来合理规划 UNDO 表空间的大小，确保其能容纳业务高峰时产生的 UNDO 数据。

通过熟练掌握 V$UNDOSTAT，你可以有效地确保数据库的读一致性和稳定性，避免因 UNDO 空间管理不当而导致的严重故障。

欢迎关注我的公众号《IT小Chen》