不能直接查 dba_hist_tbspc_space_usage 获取真实日增长量，因其每分钟可能存多条记录、rtime为字符串格式且同一日期存在多个snap_id，需快照对齐、去重聚合和租户隔离。
直接查 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 v$containers或con_id过滤，导致 CDB 和 PDB 数据混在一起
12c 必须用 CDB_HIST_TBSPC_SPACE_USAGE + con_id 对齐
12c 中应优先查 CDB_HIST_TBSPC_SPACE_USAGE，它已含 con_id 字段；若查 DBA_HIST_TBSPC_SPACE_USAGE，必须显式关联容器视图，否则 PDB 数据会被忽略或错位。
- 子查询中需包含
nb.con_id并参与GROUP BY，否则每个 PDB 的同名表空间会聚合到一起 -
JOIN cdb_tablespaces和v$containers才能正确映射con_id→pdbname - 过滤临时/UNDO 表空间时，要用
c.contents IN ('PERMANENT')，而不是简单NOT LIKE 'TEMP%'，因 12c 中contents字段更可靠
计算日增长量必须用 LAG() 而非简单减法
即使拿到每日最大快照，也不能靠两行 ts_used_mb 相减——因为不同日期的快照时间点未必对齐（比如 1 日是 23:59，2 日是 00:01），且中间可能缺采样。必须用窗口函数按日期排序后逐行计算差值。
- 先用
TO_CHAR(snap.END_INTERVAL_TIME, 'yyyy-mm-dd')截取日期（比解析rtime更准，因END_INTERVAL_TIME是DATE类型） - 用
LAG(used_GB, 1) OVER (PARTITION BY tablespace_name ORDER BY day)确保每个表空间独立计算增量 - 注意
LAG()返回NULL时需用COALESCE(..., 0)或条件判断，避免整列变空
容易被忽略的兼容性细节
12c 多租户环境下，block_size 来自 cdb_tablespaces，但该视图中 block_size 为 NULL（实际需从 dba_tablespaces 在对应 PDB 中查）；生产脚本中建议改用 dba_hist_snapshot 关联 dba_hist_tbspc_space_usage，再通过 DBID + SNAP_ID 关联，避免依赖 rtime 字符串解析。
-
rtime字段偶尔有格式异常（如空值、年份错写成 20260），必须加WHERE REGEXP_LIKE(rtime, '^\d{2}/\d{2}/\d{4} \d{2}:\d{2}:\d{2}$') - 日期范围过滤别用
SYSDATE - 30直接比字符串，应统一转为DATE：TO_DATE(rtime, 'mm/dd/yyyy hh24:mi:ss') >= TRUNC(SYSDATE) - 30 - 若需跨 CDB/PDB 统计，务必确认当前用户有
SELECT_CATALOG_ROLE，否则CDB_*视图查不到数据
