oracle 21c无内置表空间使用率自动告警，autoextend on仅为静默扩容机制；dbms_scheduler仅是执行引擎，需手动编写阈值判断、告警触发等完整逻辑，推荐使用cloud control或zabbix等外部监控方案。
autoextend on 不是自动监控任务，它只是静默扩容机制。oracle 21c 本身不提供“内置的表空间使用率自动告警任务”，所有监控和通知必须靠外部手段或手动配置。
为什么 DBMS_SCHEDULER 不能直接监控表空间使用率
Oracle 的 DBMS_SCHEDULER 可以运行任意 SQL 或 PL/SQL，但它不自带表空间阈值判断逻辑，也不主动触发告警事件。你得自己写脚本、封装判断、再决定是否发邮件或写日志。
-
DBMS_SCHEDULER是执行引擎，不是监控系统——它不会自动感知“USERS 表空间用了 92%”这种状态 - 如果你只建一个定时 job 执行
SELECT ... FROM dba_tablespace_usage_metrics，它查完就结束，不报警、不记录、不联动 - 真要靠 scheduler 实现监控，必须手写完整逻辑：查用量 → 判断是否超阈值 → 调用
UTL_MAIL.SEND或写入自定义日志表 → 再加失败重试和去重
真正可用的监控路径只有两条
一条走 Oracle 官方运维平台，一条走第三方工具链。别在 DBMS_SCHEDULER 上硬套“自动监控”这个概念。
-
Cloud Control（推荐）：启用
Tablespace Space Usage指标，设置 Warning=85%、Critical=92%，它会自动轮询DBA_TABLESPACE_USAGE_METRICS并触发 Email/SNMP 告警。前提是STATISTICS_LEVEL=TYPICAL且 Agent 权限正确（SELECT_CATALOG_ROLE） -
Zabbix / Prometheus + custom script：用 shell 调
sqlplus查dba_data_files和dba_free_space，输出 JSON 给 Zabbix 自动发现；告警规则里区分autoextensible='NO'和使用率 >95% 两种情况，避免误报
手动建监控 job 的最小可行示例（仅作应急）
如果你暂时没上 Cloud Control 或 Zabbix，又必须用 scheduler 临时顶一下，下面这个 job 只做一件事：当 USERS 表空间使用率 ≥90% 时，往 dba_alert_log 插一条记录（注意：不发邮件，不调外部服务）：
BEGIN
DBMS_SCHEDULER.CREATE_JOB(
job_name => 'check_users_tbs_usage',
job_type => 'PLSQL_BLOCK',
job_action => 'DECLARE
v_used_pct NUMBER;
BEGIN
SELECT ROUND((a.bytes - NVL(b.free_bytes,0))/a.bytes*100,2)
INTO v_used_pct
FROM (SELECT SUM(bytes) bytes FROM dba_data_files WHERE tablespace_name = ''USERS'') a,
(SELECT SUM(bytes) free_bytes FROM dba_free_space WHERE tablespace_name = ''USERS'') b;
IF v_used_pct >= 90 THEN
INSERT INTO alert_log (msg, ts) VALUES (''USERS tbs usage: '' || v_used_pct || ''%'', SYSDATE);
COMMIT;
END IF;
END;',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=DAILY; BYHOUR=9; BYMINUTE=0',
enabled => TRUE
);
END;
- 这个 job 不解决根本问题：它不告诉你磁盘还有多少空间、
maxbytes是否已到 OS 限制、increment_by是否太小导致频繁扩展 - 它依赖
dba_free_space，而该视图对大段（如分区表）可能不准；更稳的方式是用DBA_TABLESPACE_USAGE_METRICS（但该视图需 AWR 快照支持） - 别忘了定期清理
alert_log表，否则它自己会撑爆SYSTEM表空间
真正容易被忽略的是：AUTOEXTEND ON 和 “监控告警” 是两层完全独立的机制。开了自动扩展 ≠ 空间安全；收到告警 ≠ 可以不管——因为告警那一刻，可能文件系统只剩 2GB，而你的 increment_by 是 512MB，下一次扩展就会失败。
