DBA_TABLESPACE_USAGE_METRICS可查当前表空间使用率，但非实时（默认每小时刷新），需过滤临时表空间并结合DBA_DATA_FILES判断自动扩展上限，采集时应建自定义表存时间序列数据。
用 DBA_TABLESPACE_USAGE_METRICS 查当前表空间使用率
Oracle 12c 及以上版本自带这个视图，比轮询 DBA_TABLESPACES + DBA_DATA_FILES 更准，它直接暴露已用/总大小和增长速率（USED_SPACE_MB、TOTAL_SPACE_MB、USED_PERCENT）。注意：该视图默认每小时刷新一次，不是实时数据，但对趋势监控足够可靠。
常见错误是直接查 DBA_FREE_SPACE 算剩余空间——它不包含自动扩展文件的潜在容量，会低估可用空间。正确做法是优先用 DBA_TABLESPACE_USAGE_METRICS，再辅以 DBA_DATA_FILES 的 AUTOEXTENSIBLE 和 MAXBYTES 判断扩容上限。
- 执行前确认用户有
SELECT_CATALOG_ROLE或直接授予SELECT权限给该视图 - 过滤掉临时表空间：
WHERE TABLESPACE_NAME NOT IN (SELECT TABLESPACE_NAME FROM DBA_TABLESPACES WHERE CONTENTS = 'TEMPORARY') - 避免在高峰时段频繁查询，该视图底层依赖AWR快照，高并发轮询可能加重
SYSAUX压力
写存储过程定时记录历史增长数据
核心不是“实时告警”，而是“留下可比对的时间序列”。必须建一张自定义表存快照，比如 TS_GROWTH_LOG，字段至少含：LOG_TIME（DATE 或 TIMESTAMP）、TABLESPACE_NAME、USED_MB、TOTAL_MB、USED_PCT。
存储过程里别用 INSERT ... SELECT 直接灌数据——如果某次采集时表空间被锁或AWR未刷新，会导致整条记录为空或异常。应加 EXCEPTION 捕获 NO_DATA_FOUND 和 OTHERS，并记录到 DBMS_OUTPUT 或写入日志表。
- 每次插入前用
MERGE或先SELECT COUNT(*)防重复（按LOG_TIME+TABLESPACE_NAME唯一约束） -
LOG_TIME推荐用SYSTIMESTAMP而非SYSDATE，避免跨时区或夏令时偏差影响趋势计算 - 不要在存储过程中做复杂统计（如环比计算），留到查询层处理；存储过程只负责“采+存”
用 LAG() 计算表空间日增长率
真正判断“增长速度”的地方不在存储过程里，而在后续分析SQL中。用窗口函数 LAG(USED_MB) OVER (PARTITION BY TABLESPACE_NAME ORDER BY LOG_TIME) 拿前一条记录的值，再减当前值，就能得出增量。单位时间取“天”还是“小时”，取决于你的采集频率。
容易忽略的是空值处理：LAG() 对第一条记录返回 NULL，直接相减得 NULL，必须用 NVL() 或 COALESCE() 替换为 0，否则 WHERE GROWTH_MB > 100 这类条件会漏掉首条记录之后的所有有效行。
- 增长量建议用 MB 级别，避免用百分比——小表空间 5% 可能才几MB，大表空间 1% 就几百MB，数值不可比
- 计算日均增长时，分母用
(LOG_TIME - LAG(LOG_TIME)) * 24得小时差，再除以24得天数，比硬写1更准 - 若采集间隔不稳定（如因维护停了一天），需加条件
WHERE (LOG_TIME - LAG(LOG_TIME)) BETWEEN 0.9 AND 1.1过滤掉异常间隔
调度执行与权限隔离
用 DBMS_SCHEDULER 而不是 DBMS_JOB，后者在 Oracle 21c 已废弃。创建 job 时，job_action 必须写完整 schema 名，比如 'MYSCHEMA.MONITOR_TS_USAGE'，否则可能因当前 session schema 不同而执行失败。
最常踩的坑是权限链断裂：存储过程里查 DBA_* 视图，但调用者（scheduler job 默认以 owner 身份运行）没被显式授权。不能依赖 DEFINER'S RIGHTS 自动继承，必须用 GRANT SELECT ON DBA_TABLESPACE_USAGE_METRICS TO MYSCHEMA 显式赋权。
- job 的
start_date设为TRUNC(SYSDATE) + 1/24（即明天整点），避免刚建完就触发，干扰首次基线采集 - 设置
max_run_duration限制执行时间，防止因锁表或AWR延迟导致 job 卡死 - 别把告警逻辑塞进 job——job 只负责采集；告警用单独脚本查
TS_GROWTH_LOG表，按阈值发邮件
监控表空间增长的关键不在存储过程多复杂，而在数据采集的稳定性、时间戳的准确性，以及后续分析时对空值和时间间隔的严谨处理。越简单的采集逻辑，越容易长期跑下去。
