理解您想深入了解 Oracle 19C 数据库中 V$SYS_TIME_MODEL 动态性能视图。作为数据库管理员或性能调优专家，掌握这个视图对于从宏观时间维度把握数据库实例的整体负荷和性能瓶颈至关重要。我会结合多个可靠的信息来源，为您详细梳理这个视图的各个方面。
📊 Oracle 19C V$SYS_TIME_MODEL 详解
1. 视图概述与核心作用
V$SYS_TIME_MODEL 是 Oracle 数据库中的一个关键动态性能视图，它提供了自实例启动以来，各种数据库操作所花费时间的统计信息，所有时间值以微秒（microseconds）为单位。它回答了“数据库时间都花在哪里了”这个核心问题。
与传统的计数型统计信息（如逻辑读、物理读次数）不同，时间模型统计信息以时间为统一的度量尺度，使得不同组件的耗时具有可比性，为性能优化提供了更高层次的、更具指导意义的视角。
其最核心的作用是：
- 量化数据库时间消耗：精确衡量各类操作（如SQL执行、解析、PL/SQL运行）的时间占比。
- 识别系统级性能瓶颈：快速定位消耗时间最多的数据库活动，确定优化方向。
- 评估优化效果：通过比较优化前后各时间项的变化，量化调优成效。
- 计算负载指标：最重要的指标
DB time是评估实例整体负载的关键。
2. 字段详解
V$SYS_TIME_MODEL 视图包含以下字段，每个字段的含义如下表所示：
| 字段名称 (Field Name) | 数据类型 | 描述 |
|---|---|---|
| STAT_ID | NUMBER | 统计项的唯一数字标识符。 |
| STAT_NAME | VARCHAR2(64) | 统计项的名称（例如：DB time, DB CPU, sql execute elapsed time）。这是查询时最关键的字段。 |
| VALUE | NUMBER | 自实例启动以来，该统计项所累积的时间值（单位：微秒）。这是最核心的数值字段。 |
| CON_ID | NUMBER | 容器ID（Container ID）。在多租户环境（CDB）中，标识该统计信息属于哪个容器（PDB）。值为 0 表示属于 CDB$ROOT（根容器）。 |
主要统计项（STAT_NAME）解读：
| 统计项名称 (STAT_NAME) | 描述 |
|---|---|
| DB time | 数据库时间的总和。这是所有非空闲用户会话在数据库调用上花费的总时间（CPU时间 + 非空闲等待时间）的累积。这是最宏观的指标。其值可能远大于实例启动后的实际时间（例如，一个有4个活跃会话的实例运行30分钟，DB time可能约为120分钟）。 |
| DB CPU | 数据库用户调用消耗的CPU时间总和（不包括后台进程CPU时间）。 |
| background elapsed time | 数据库后台进程消耗的总时间。 |
| background cpu time | 数据库后台进程消耗的CPU时间总和。 |
| sql execute elapsed time | SQL语句执行所花费的总时间。对于SELECT语句，此时间也包括获取（Fetch）结果集的时间。 |
| parse time elapsed | 解析SQL语句花费的总时间（包括软解析和硬解析）。 |
| hard parse elapsed time | 硬解析SQL语句花费的总时间。 |
| hard parse (sharing criteria) elapsed time | 由于无法共享现有游标（如SQL文本不匹配）而进行硬解析所花费的时间。 |
| hard parse (bind mismatch) elapsed time | 由于绑定变量类型或长度不匹配而导致硬解析所花费的时间。 |
| PL/SQL execution elapsed time | 执行PL/SQL解释器所花费的总时间（不包括其中递归执行的SQL或Java时间）。 |
| PL/SQL compilation elapsed time | 编译PL/SQL对象所花费的总时间。 |
| connection management call elapsed time | 处理会话连接（Connect）和断开（Disconnect）调用所花费的时间。 |
| sequence load elapsed time | 从数据字典获取下一个序列值（Sequence）所花费的时间。对于缓存（Cached）序列，此时间主要在缓存耗尽后补充缓存时产生。 |
| failed parse elapsed time | 最终失败的SQL解析所花费的时间（例如，由于语法错误）。 |
关键统计项关系：
DB time是调优的总体目标，优化旨在降低DB time。sql execute elapsed time通常是DB time的主要组成部分。parse time elapsed是sql execute elapsed time的一部分。高昂的解析时间，特别是hard parse elapsed time，往往是性能问题的根源。DB CPU是DB time的一部分，另一部分是非空闲等待时间。
3. 底层原理与相关对象
3.1 底层原理
- 统一时间度量：Oracle 引入时间模型是为了解决传统统计信息（如次数、字节数）难以直接比较和量化影响的问题。时间提供了一个统一的尺度，使得评估各种操作对整体性能的影响变得更加直观和科学。
- 数据收集与累积：
V$SYS_TIME_MODEL中的数据来源于系统全局区（SGA）中的内部内存结构。数据库内核在执行各种操作时，会实时地、累积地更新对应统计项的时间计数器。这些数据从实例启动开始累积，实例关闭后重置。 DB Time的计算：DB Time是一个派生指标，它通过累加所有非空闲用户会话的 CPU 时间和非空闲等待时间计算得出。正因为是累积值，所以其数值可能远大于实例的实际运行时间。- 基表：同其他
V$视图一样，V$SYS_TIME_MODEL基于一系列内部的X$表（具体表名未公开），这些是 Oracle 在内存中维护的虚拟表，不建议直接查询。
3.2 相关视图
| 视图名称 | 描述 |
|---|---|
V$SESS_TIME_MODEL | 会话级别（Session）的时间模型统计。其字段与 V$SYS_TIME_MODEL 类似，但多了一个 SID 字段来标识会话。用于诊断特定会话的性能问题。 |
V$CON_SYS_TIME_MODEL | 在多租户环境中，显示容器（Container）级别的系统时间模型统计。 |
V$ACTIVE_SESSION_HISTORY | 活跃会话历史（ASH）。提供更细粒度的、基于采样的事务等待信息，常与时间模型结合进行深度性能诊断。 |
DBA_HIST_SYS_TIME_MODEL | AWR历史快照中保存的 V$SYS_TIME_MODEL 的历史数据。用于长期性能趋势分析和历史数据对比。 |
4. 主要使用场景
- 系统级性能瓶颈快速定位：这是最核心的用途。通过查询各统计项的时间占比，能迅速判断数据库的时间主要消耗在何处（是SQL执行？是解析？还是PL/SQL？），从而确定调优的大方向。
- 解析问题诊断：
parse time elapsed和hard parse elapsed time是诊断硬解析问题和绑定变量滥用的关键指标。如果它们的值及其在DB time中的占比过高，通常意味着应用设计或实现存在问题。 - 量化优化效果：在进行任何重大优化（如增加索引、修改SQL、调整参数）前后，分别查询相关统计项的值。通过对比优化前后的时间差异，可以精确量化优化措施带来的收益。
- 容量规划与负载评估：
DB time是衡量数据库实例负载强度的黄金指标。一个持续高企的DB time表明实例负载很重，可能需要更多的硬件资源或更深入的性能优化。 - AWR/Statspack报告的基础：AWR和Statspack性能报告中的"Time Model Statistics"部分，其数据就来源于此视图或其历史快照。
5. 常用SQL查询示例
5.1 查看所有时间模型统计信息（按耗时降序排列）
这是最常用的查询，用于宏观把握时间消耗分布。
SELECT stat_name,
ROUND(value / 1000000, 2) AS time_seconds, -- 将微秒转换为秒
ROUND(RATIO_TO_REPORT(value) OVER () * 100, 2) AS pct_total_time
FROM v$sys_time_model
WHERE value > 0
ORDER BY value DESC;
5.2 计算主要操作在DB Time中的占比
此查询帮助你理解时间都花在了哪些关键活动上。
SELECT stat_name,
ROUND(value / 1000000, 2) AS time_seconds,
ROUND(value * 100 / (SELECT value
FROM v$sys_time_model
WHERE stat_name = 'DB time'), 2) AS pct_of_db_time
FROM v$sys_time_model
WHERE stat_name IN ('DB CPU',
'sql execute elapsed time',
'parse time elapsed',
'hard parse elapsed time',
'PL/SQL execution elapsed time',
'connection management call elapsed time')
ORDER BY value DESC;
5.3 诊断解析问题
专门用于分析解析是否成为性能瓶颈。
SELECT stat_name,
ROUND(value / 1000000, 2) AS time_seconds,
ROUND(value * 100 / (SELECT value
FROM v$sys_time_model
WHERE stat_name = 'parse time elapsed'), 2) AS pct_of_parse_time
FROM v$sys_time_model
WHERE stat_name LIKE '%parse%elapsed%' -- 查询所有与解析时间相关的统计项
ORDER BY value DESC;
5.4 比较两个时间点的差异（用于衡量优化效果）
需要先创建一个快照，一段时间后再进行比较。
-- 第一步：创建临时表或变量保存当前值（例如，只保存解析相关的时间）
CREATE GLOBAL TEMPORARY TABLE time_model_snapshot AS
SELECT stat_name, value
FROM v$sys_time_model
WHERE stat_name LIKE '%parse%elapsed%';
-- 第二步：等待一段时间或执行优化操作后，计算差异
SELECT curr.stat_name,
ROUND((curr.value - snap.value) / 1000000, 2) AS delta_time_seconds
FROM v$sys_time_model curr,
time_model_snapshot snap
WHERE curr.stat_name = snap.stat_name
AND (curr.value - snap.value) > 0
ORDER BY delta_time_seconds DESC;
-- 第三步：清理临时表
DROP TABLE time_model_snapshot;
6. 重要知识点与原理延伸
DB Time是关键：DB Time是性能调优的终极目标。所有优化的最终目的都是为了减少用户操作所花费的DB Time。如果DB Time的增长速度远快于实际时间，说明并发负载很高。- 解析是“头号公敌”：高昂的解析时间，特别是硬解析时间，是Oracle数据库中最常见的性能问题根源之一。硬解析不仅消耗CPU资源，还会引发共享池中的闩锁（Latch）争用。使用绑定变量是减少硬解析的最有效方法。
- 时间可能重叠：时间模型统计项之间可能存在重叠。例如，
sql execute elapsed time包含了执行过程中消耗的DB CPU和用户I/O等待等时间。parse time elapsed也是sql execute elapsed time的一部分。因此，各统计项百分比之和可能超过100%。 - 结合其他视图深入分析：
V$SYS_TIME_MODEL提供了宏观方向，但要定位到具体问题（如哪个SQL解析慢），需要结合其他视图：- 定位高解析时间：结合
V$SQL查看PARSE_CALLS、PARSING_USER_ID等。 - 定位高执行时间：结合
V$SQLAREA查看ELAPSED_TIME、EXECUTIONS等。 - 查看详细等待事件：结合
V$SYSTEM_EVENT。
- 定位高解析时间：结合
- 多租户环境：在CDB环境中，在根容器（CDBROOT）中查询‘VROOT）中查询 `VROOT）中查询‘VSYS_TIME_MODEL
显示的是整个CDB的统计信息。要查看特定PDB的统计信息，需要切换到该PDB中查询，或使用CON_ID` 字段进行过滤。
掌握 V$SYS_TIME_MODEL 视图的使用，是您从“凭感觉”调优走向“基于数据驱动”的精准调优的关键一步。它让您能站在一个更高的维度，快速洞察数据库实例的整体健康状态和性能瓶颈所在。
欢迎关注我的公众号《IT小Chen》
扫一扫
3090
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
