oracle 19c不内置表空间阈值自动邮件告警功能，须依赖外部脚本+linux邮件工具实现；核心难点在于邮件链路验证、真实使用率手动计算（需联查dba_data_files与dba_free_space并过滤online/permanent表空间）、防误报阈值逻辑及crontab环境变量配置。
Oracle 19c 本身不内置表空间阈值自动告警邮件功能，必须靠外部脚本+系统级邮件工具（如 mail 或 sendmail）组合实现。核心难点不在 Oracle 端，而在 Linux 邮件链路是否通、脚本能否稳定提取真实使用率、以及阈值判断逻辑是否防误报。
确认 Oracle 19c 能否直接查出准确表空间使用率
Oracle 19c 的 dba_tablespace_usage_metrics 视图只对自动段管理（ASSM）的永久表空间有效，且数据有延迟（默认每小时刷新一次），不能用于实时预警。必须用传统 SQL 手动计算：
-
dba_data_files获取总分配字节数（注意autoextensible和maxbytes） -
dba_free_space获取当前空闲字节数 - 两者相减再除以总量，才是真实占用率
常见错误是忽略临时表空间、UNDO 表空间或只读表空间，导致脚本报错或结果失真。建议在 SQL 中加 WHERE status = 'ONLINE' AND contents = 'PERMANENT' 过滤。
Linux 邮件发送链路必须提前验证通
很多脚本失败不是 SQL 写错，而是 mail 命令根本发不出去。关键检查点：
- 执行
which mail确认命令存在；若无，需yum install mailx（RHEL/CentOS）或apt install mailutils（Ubuntu/Debian） -
/etc/mail.rc中的 SMTP 配置必须匹配邮箱服务商要求：QQ 邮箱必须用smtp=smtp.qq.com:587（非 25 端口），且smtp-auth-password是「授权码」而非登录密码 - 测试命令必须带
-v参数看详细日志：echo "test" | mail -v -s "test" your@email.com
如果提示 535 Error: authentication failed，基本是授权码过期或未开启 SMTP 服务；若卡住无响应，大概率是防火墙或 DNS 解析问题。
脚本中阈值判断和防抖逻辑不能省
单纯“一超就发”会导致告警风暴。实际脚本里至少要加两层控制：
- 只对占用率 > 85% 的表空间输出到告警文件，避免把 99% 和 86% 混在一起发
- 用
find+grep -q检查上一次告警是否已发过：比如生成一个last_alert_$TABLESPACE.log，内容存上次触发时间，两次间隔小于 2 小时则跳过 - SQL 查询末尾加
HAVING 100-ROUND((NVL(b.bytes_free,0)/a.bytes_alloc)*100,2) > 85，让数据库端过滤，减少传输数据量
示例片段：
sqlplus -s "/ as sysdba" 85; SPOOL OFF EXIT EOF
crontab 权限和环境变量最容易被忽略
Oracle 用户的定时任务常因环境缺失失败：
-
crontab -e编辑时，必须先su - oracle，不能只su oracle，否则.bash_profile不加载，sqlplus找不到 - crontab 里每行命令前加
source /home/oracle/.bash_profile &&更稳妥 - 避免在脚本里写死
ORACLE_SID，改用export ORACLE_SID=$(ps -ef | grep pmon | grep -v grep | awk '{print $8}' | cut -d_ -f3)动态获取
真正上线前，务必手动运行一次完整脚本，再检查 mail 是否收到、附件内容是否可读、SQL 输出是否有乱码——这些细节一旦漏掉，告警等于没配。
