不能直接查 dba_hist_tbspc_space_usage 获取日增长量，因该表每分钟可能存多条记录、rtime为字符串格式、同一日期存在多个snap_id，需按tablespace_id和日期取最大snap_id、适配多租户、过滤undo/temp、用lag计算增量。
直接查 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_gb
FROM dba_hist_tbspc_space_usage a
JOIN (
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_id
JOIN 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) - 30
ORDER 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 也跑不出数据。
