Oracle表空间监控需关联DBA_TABLESPACES、DBA_DATA_FILES与DBA_FREE_SPACE计算使用率，临时表空间单独查v$temp_space_header；JDBC用HikariCP配置keepaliveTime、maxLifetime和connectionTestQuery防静默断连；告警需按表空间类型分级阈值、去重收敛并带关键字段。
Oracle表空间监控SQL怎么写才准？
直接查 dba_tablespaces 和 dba_data_files 不够，容易漏掉临时表空间或自动扩展被禁用的场景。关键得把使用率、是否自动扩展、剩余空间三者联动判断。
- 必须用
dba_tablespaces关联dba_data_files+dba_free_space（注意：dba_free_space对空文件不返回记录，得用SUM(bytes)算已用空间） - 临时表空间要单独查
v$temp_space_header，它不走dba_free_space - 别信
maxbytes字段——如果autoextensible = 'NO'，那maxbytes就是假上限，真实可用空间就是bytes - 示例片段：
SELECT t.tablespace_name,<br> ROUND((d.bytes - NVL(f.free_bytes, 0)) / d.bytes * 100, 2) AS used_pct,<br> d.autoextensible,<br> NVL(f.free_bytes / 1024 / 1024, 0) AS free_mb<br>FROM dba_tablespaces t<br>JOIN (SELECT tablespace_name, SUM(bytes) bytes, MAX(autoextensible) autoextensible FROM dba_data_files GROUP BY tablespace_name) d<br> ON t.tablespace_name = d.tablespace_name<br>LEFT JOIN (SELECT tablespace_name, SUM(bytes) free_bytes FROM dba_free_space GROUP BY tablespace_name) f<br> ON t.tablespace_name = f.tablespace_name<br>WHERE t.contents != 'UNDO' AND t.status = 'ONLINE';
JDBC定时执行时连接池怎么配才稳？
Oracle巡检不是高并发操作，但得扛住长时间运行+网络抖动。用 HikariCP 是最省心的选择，但默认配置会踩坑。
-
connectionTimeout别设太短（比如 3000），Oracle TNS 超时可能在 5~10 秒，设太短会导致频繁重连失败 - 必须开
keepaliveTime（建议 300000），否则 Oracle 的防火墙/中间设备可能静默断连，下次查询直接抛IO Error: Connection reset -
maxLifetime建议设为比 Oraclesqlnet.expire_time小 60 秒；如果 DBA 没配这个参数，默认是 0（不探测），那就设成 1800000（30 分钟）较安全 - 别用
DriverManager.getConnection()手动建连接——没连接复用，每次都是新 TCP 握手，巡检频率一高就触发ORA-12519
Java里怎么判断该报警而不是只打日志？
阈值不能硬编码在 if 里。巡检的核心是“可配置、可收敛、可追溯”，否则运维半夜收到 20 条重复告警就废了。
- 用 Map 存每张表空间的当前使用率，和上一次结果比对；只有「首次超限」或「连续超限 N 次」才触发推送（避免瞬时毛刺）
- 阈值按表空间类型分：普通数据表空间用 85%，SYSTEM 用 75%，TEMP 用 90%——SYSTEM 太高会卡死 DDL，TEMP 高只是影响排序性能
- 报警内容必须带
tablespace_name、used_pct、free_mb、autoextensible四个字段，缺一个排查时间翻倍 - 推送前加个本地锁（比如
synchronized(this)或ReentrantLock），防止同一轮巡检中多个线程重复发告警
为什么定时任务总在凌晨挂，但日志没报错？
大概率是 Oracle 的维护窗口或归档模式切换导致连接被静默 kill，而 JDBC 默认不主动探测连接有效性。
- 别依赖
isClosed()——它只看本地状态，连都断了还返回 false - HikariCP 必须配
connectionTestQuery=SELECT 1 FROM DUAL，且validationTimeout≥ 3000 - Spring Boot 用户注意：
@Scheduled(fixedDelay = 60000)如果上一轮执行卡住（比如 SQL 被锁），下一轮不会跳过，会堆积线程，最终 OOM。改用fixedDelayString = "${check.interval:60000}"+ThreadPoolTaskScheduler控制并发数为 1 - 加个兜底检查：每次执行前跑
SELECT SYSDATE FROM DUAL，失败就强制 refresh DataSource
表空间监控真正难的不是查数据，而是把 Oracle 那套“连接半死不活、会话突然消失、归档阻塞写入”的隐性故障，翻译成 Java 里可感知、可恢复的动作。很多问题不是代码写错了，是没把 Oracle 当成一个会呼吸的系统来对待。
立即学习“Java免费学习笔记（深入）”；
