直接查 dba_hist_tbspc_space_usage 能拿到每日增长量，但必须配合快照时间对齐、去重聚合和跨版本适配，否则结果会重复、错位或漏掉增量。
为什么不能直接 SELECT * FROM DBA_HIST_TBSPC_SPACE_USAGE
这张表每分钟可能存多条记录（尤其在高频率 AWR 采样下），rtime 字段是字符串格式（如 ’05/01/2026 03:45:22’），且同一日期内存在多个 snap_id 对应不同采样点。直接查会看到大量时间相近但数值微差的行，无法反映“日粒度增长”。
常见错误现象包括：
同一日期出现 10+ 行，ts_used_mb 每次只涨几 MB，误以为增长缓慢用 TRUNC(TO_DATE(rtime, ‘mm/dd/yyyy hh24:mi:ss’)) 分组后仍有多行，因未按 tablespace_id + 日期取当日最新快照在 12c 多租户环境里漏 join con_id，导致 CDB 和 PDB 数据混在一起
Oracle 11g 及以下：用子查询取每日最大 snap_id
核心思路是先按 tablespace_id 和日期截取（SUBSTR(rtime,1,10)）分组，取每个组合下最大的 snap_id，再关联主表获取该时刻的用量。
关键实操建议：
必须 join v$tablespace 和 dba_tablespaces 才能拿到 block_size 和表空间名，dba_hist_tbspc_space_usage 本身不存表空间名称TO_DATE(rtime, ‘mm/dd/yyyy hh24:mi:ss’) 必须加异常处理兜底（生产库偶尔有格式异常数据），建议先用 WHERE REGEXP_LIKE(rtime, ‘^\d{2}/\d{2}/\d{4} \d{2}:\d{2}:\d{2}$’) 过滤日期范围用 TO_DATE(rtime, …) >= TRUNC(SYSDATE) – 30，别用 SYSDATE – 30 直接比字符串，易隐式转换失败
最小可用片段：
SELECT c.tablespace_name, TO_CHAR(TO_DATE(a.rtime, ‘mm/dd/yyyy hh24:mi:ss’), ‘yyyy-mm-dd’) day, ROUND(a.tablespace_usedsize * c.block_size / 1024/1024/1024, 2) used_gbFROM dba_hist_tbspc_space_usage aJOIN ( SELECT tablespace_id, SUBSTR(rtime,1,10) rdate, MAX(snap_id) snap_id FROM dba_hist_tbspc_space_usage WHERE REGEXP_LIKE(rtime, ‘^\d{2}/\d{2}/\d{4} \d{2}:\d{2}:\d{2}$’) GROUP BY tablespace_id, SUBSTR(rtime,1,10)) b ON a.snap_id = b.snap_id AND a.tablespace_id = b.tablespace_idJOIN dba_tablespaces c ON a.tablespace_id = (SELECT ts# FROM v$tablespace WHERE name = c.tablespace_name)WHERE TO_DATE(a.rtime, ‘mm/dd/yyyy hh24:mi:ss’) >= TRUNC(SYSDATE) – 30ORDER BY c.tablespace_name, day;
Oracle 12c+ 多租户：必须显式处理 con_id
在 CDB 中，DBA_HIST_TBSPC_SPACE_USAGE 是视图，底层实际查的是 CDB_HIST_TBSPC_SPACE_USAGE，但历史脚本常误用 DBA_HIST_TBSPC_SPACE_USAGE —— 这会导致只返回 CDB$ROOT 的数据，PDB 全部丢失。
正确做法：
用 CDB_HIST_TBSPC_SPACE_USAGE 替代 DBA_HIST_TBSPC_SPACE_USAGE子查询中必须包含 nb.con_id 并参与 GROUP BY，否则 MAX(snap_id) 会跨容器取值join V$CONTAINERS 获取 PDB 名称，e.name 比 a.con_id 更易读排除临时表空间和 UNDO 表空间：在 WHERE 加 AND c.contents NOT IN (‘UNDO’,’TEMPORARY’)
容易被忽略的一点：CDB_HIST_TBSPC_SPACE_USAGE 的 con_id 为 0 表示 CDB$ROOT，1 表示 PDB$SEED，真实 PDB 从 2 开始 —— 如果没过滤，seed 库的“增长”数据会干扰判断。
计算真实日增长量：用 LAG() 窗口函数
上面查出的是每日快照用量，不是“增长量”。要得到每天新增多少 GB，必须按表空间+日期排序后，用 LAG(used_gb, 1) OVER (PARTITION BY tablespace_name ORDER BY day) 计算差值。
注意事项：
第一次出现的日期没有前一日值，LAG() 返回 NULL，需用 NVL(…, 0) 或 COALESCE() 处理如果某天无快照（如 AWR 关闭、采样失败），会导致后续所有差值偏大，建议加校验：仅当 day = LAG(day)+1 时才计算增量避免用 END_INTERVAL_TIME 代替 rtime：前者来自 DBA_HIST_SNAPSHOT，与 DBA_HIST_TBSPC_SPACE_USAGE 的采样时间不一定严格对齐
最终增长列可写成：
CASE WHEN LAG(used_gb, 1) OVER (PARTITION BY c.tablespace_name ORDER BY day) IS NULL THEN NULL ELSE used_gb – LAG(used_gb, 1) OVER (PARTITION BY c.tablespace_name ORDER BY day) END AS incr_gb
真正难的不是写 SQL，而是确认 AWR 保留策略是否覆盖你要查的时间范围、STATISTICS_LEVEL 是否为 TYPICAL 或 ALL（否则 DBA_HIST_* 表为空）、以及是否有权限访问 DBA_HIST_* 视图 —— 这些问题不解决，再准的 SQL 也跑不出数据。
评论(0)