PL/SQL触发器无法捕获表空间配额超限事件，因其不响应QUOTA变更或空间增长；必须使用DBMS_SERVER_ALERT配合表空间量度机制实现可靠预警。
PL/SQL 触发器无法捕获表空间配额超限事件——因为表空间配额变更（如 ALTER USER ... QUOTA）和空间使用增长（如 INSERT 导致段扩展）不触发 DML 或 DDL 触发器，必须改用 Oracle 原生的表空间预警机制。
为什么不能用 BEFORE/AFTER INSERT 或 DDL 触发器监控配额
常见错误是试图在用户表或数据字典视图上建触发器，比如监听 dba_ts_quotas 变化。但问题在于：
-
dba_ts_quotas是只读视图，无法对其执行 INSERT/UPDATE，也就无法被 DML 触发器捕获 -
ALTER USER ... QUOTA属于 DDL 操作，Oracle 不支持针对用户配额变更的 DDL 触发器（CREATE TRIGGER ... ON DATABASE FOR ALTER_USER语法不存在） - INSERT 导致空间增长时，触发器运行在业务表上下文，此时配额是否超限已由 Oracle 内核判断并报错（
ORA-01536: space quota exceeded），触发器根本不会执行
Oracle 唯一可靠的配额预警路径：DBMS_SERVER_ALERT + 表空间量度
Oracle 自带基于量度（metric）的主动预警框架，无需自定义触发器，且能精确到百分比阈值。关键步骤如下：
- 启用表空间使用率量度：
EXEC DBMS_SERVER_ALERT.SET_THRESHOLD(DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL, '85', '95', NULL, NULL, 0, 'LOCAL', NULL) - 确保
STATISTICS_LEVEL至少为TYPICAL（默认满足），否则量度不采集 - 预警会写入
DBA_OUTSTANDING_ALERTS视图，并可配置通过 Enterprise Manager、Email Gateway 或自定义脚本轮询消费 - 注意：该机制检测的是「已分配空间占表空间总大小比例」，不是「配额占用户限额比例」；若需按配额预警，须额外建物化视图定期计算
SELECT tablespace_name, username, round((used_bytes/quota_bytes)*100) pct_used FROM dba_ts_quotas ...并设作业轮询
若坚持用 PL/SQL 模拟预警，只能靠定时作业+显式检查
这是退而求其次的方案，本质是绕过触发器，用数据库作业周期性扫描。风险点必须清楚：
- 不能用
DBMS_SCHEDULER.CREATE_JOB在触发器里调用——触发器内禁止提交事务，而作业创建隐式提交，直接报错ORA-14552 - 检查逻辑必须用
SELECT ... INTO配合异常处理，避免因用户无配额（quota_bytes = -1）导致除零错误 - 示例安全检查片段（需封装进存储过程，再由作业调用）：
DECLARE v_used_pct NUMBER; BEGIN SELECT ROUND((NVL(used_bytes,0)/NULLIF(quota_bytes,-1))*100) INTO v_used_pct FROM dba_ts_quotas WHERE username = 'APP_USER' AND tablespace_name = 'USERS'; IF v_used_pct > 90 THEN INSERT INTO quota_alert_log (username, ts_name, pct_used, alert_time) VALUES ('APP_USER', 'USERS', v_used_pct, SYSDATE); END IF; EXCEPTION WHEN NO_DATA_FOUND THEN NULL; -- 用户在该表空间无配额 END;
真正生效的配额预警永远依赖 Oracle 内置量度框架；任何试图用触发器“实时拦截”的做法，要么无效，要么掩盖了 Oracle 已经在底层完成的配额校验逻辑。运维侧要盯的是 DBA_OUTSTANDING_ALERTS 和告警历史，而不是写一堆不可靠的 PL/SQL 钩子。
