Druid比Micrometer更适合监控Oracle活跃连接数——Micrometer仅能获取JDBC通用指标，而Druid通过OracleStat适配器直接查询V$SESSION等视图获取真实会话、硬解析、PGA内存等Oracle特有指标。
druid比micrometer更适合监控oracle活跃连接数——micrometer本身不解析oracle特有视图，只能拿到jdbc标准层的通用指标（如hikaricp.connections.active），而oracle的真实活跃会话、硬解析、pga内存等关键数据，必须靠druid的oraclestat适配器从v$session和v$sqlarea里捞。
为什么Micrometer对Oracle连接池监控“力不从心”
Micrometer是通用指标抽象层，它依赖底层数据源暴露的JMX或API。HikariCP作为Spring Boot默认数据源，只提供activeCount、idleCount这类池级计数，不感知Oracle会话状态：
- 它无法区分“连接池里活跃的连接”和“Oracle数据库里真正执行SQL的会话”——后者可能因长事务、锁等待、PL/SQL阻塞而卡住，但Hikari仍认为连接“可用”
- ORA-00060死锁、
enq: TX - row lock contention等待事件、绑定变量实际值，Micrometer完全拿不到 - 所有Oracle特有指标（如
hardParseCountPerSecond、pgaMemoryMax）在Micrometer的DataSourcePoolMetrics中根本不存在字段
Druid的OracleStat才是Oracle监控刚需
要拿到Oracle真实活跃会话数，必须用Druid + 正确配置，且版本需≥1.2.16（Spring Boot 2.7+兼容）：
-
spring.datasource.driver-class-name必须设为oracle.jdbc.OracleDriver（不是过时的oracle.jdbc.driver.OracleDriver），否则getOracleStat()返回null - 调用
DruidDataSource.getOracleStat().getActiveSessionCount()才对应OracleV$SESSION中STATUS='ACTIVE'的行数 - 该值≠
DruidDataSource.getActiveCount()——后者只是池内被借出的连接数，前者才是真正占用Oracle服务进程的会话 - 必须确保
druid.filter.stat.log-slow-sql: true和druid.filter.stat.slow-sql-millis: 1000同时开启，否则StatFilter不会初始化OracleStat上下文
如果非要走Micrometer路线，只能妥协取“近似值”
你可以在Druid之上再套一层Micrometer导出，但注意：这仍是Druid在干活，Micrometer只是搬运工：
- 先用
@Bean注册DruidDataSource，并确保上述5个关键配置（stat-view-servlet.enabled等）全开 - 手动注册
DataSourcePoolMetrics时，传入的是DruidDataSource实例，而非Hikari - 导出的
hikaricp.connections.active指标名会被保留，但背后数据源已是Druid——这是Micrometer的命名惯性，别被名字骗了 - Oracle专属指标仍需单独暴露：例如写一个
@Endpoint，返回druidDataSource.getOracleStat().getActiveSessionCount()，再由Micrometer的CustomMeterRegistry注册为Gauge
容易被忽略的致命细节
很多人配完Druid，访问/actuator/metrics看到hikaricp.connections.active有数值，就以为监控到位了。其实：
- 这个数值来自HikariCP的自动装配残留——Spring Boot在检测到
DruidDataSource时，仍可能把Hikari的DataSourcePoolMetrics注册进去，造成数据源错位 -
getOracleStat()返回null时，日志里没有任何报错，只会静默跳过，必须主动判空并打日志 - Oracle JDBC驱动版本必须≥19c，旧版驱动（如12.1.0.2）不支持
V$SQLAREA.SQL_TEXT完整字段，导致慢SQL捕获失败
