共用Weblogic连接池的Log4j2 JDBCAppender致Oracle TEMP表空间耗尽咨询

该TEMP表空间占用泄漏问题确实和当前的连接池配置、log4j2 JDBC Appender使用方式直接相关，核心诱因如下：

• log4j2 2.9.1版本JDBC Appender的事务管理缺陷：该版本的异步JDBC Appender使用容器托管的JNDI数据源时，不会主动提交纯写入操作的事务。你的配置中包含2个CLOB类型的日志字段，CLOB写入过程会占用大量Oracle临时段存储，只要会话关联的事务未提交，Oracle就不会释放该会话占用的TEMP空间。你观测到的INACTIVE会话持有TEMP空间的现象，本质是连接被放回连接池时，事务未被显式提交/回滚，事务长期挂起导致资源一直被占用。
• 共用连接池的配置缺陷：当前业务逻辑、log4j日志组件共用同一个数据源，业务侧本身可能存在的长事务、未正确提交事务的场景，会和日志写入的未提交事务叠加，放大TEMP空间泄漏的问题。且你当前的Weblogic连接池未开启「归还连接时自动清理未结束事务」的特性，INACTIVE连接被放回池子后，挂起的事务永远不会被处理，只有重启应用重置所有连接才能释放对应的TEMP空间，这也是你扩容TEMP空间无效的核心原因。
• Oracle CLOB写入的资源占用特性：CLOB字段写入时会优先使用TEMP段存储临时数据，请求量上涨后，日志写入并发升高、单条CLOB内容变大，每个挂起事务持有的TEMP段会快速累加，即使扩容TEMP空间，只要泄漏逻辑存在，最终还是会被占满。
• Weblogic连接池的资源清理逻辑缺失：当前配置未开启INACTIVE连接超时回收、废弃连接自动清理的特性，长期持有未提交事务的空闲连接不会被连接池主动销毁，导致泄漏的TEMP空间一直无法释放。

• 升级log4j2到最新稳定版本：2.9.1版本存在多个JDBC Appender的事务管理、资源泄漏bug，高版本已经修复了JNDI数据源场景下的事务自动提交逻辑。
• 为日志组件配置独立的数据源，不要和业务数据源共用，日志数据源可以开启自动提交属性，避免日志写入的事务和业务事务互相影响。
• 调整Weblogic连接池配置：
  • 开启Rollback On Return、Return Connection To Pool On Commit属性，连接被归还到池子里时自动回滚未提交的事务，避免事务挂起
  • 配置INACTIVE连接超时回收时间，超过设定时长的空闲连接会被连接池主动销毁，释放持有的数据库资源
  • 合理下调连接池最大容量，850的最大连接数对于绝大多数应用来说过高，过高的连接数会放大资源泄漏的影响范围
• 优化日志表存储逻辑：如果日志的CLOB字段不需要长期存储，可以考虑拆分大字段内容，或者开启Oracle SECUREFILE CLOB特性，降低CLOB写入时的TEMP空间占用。

内容的提问来源于stack exchange，提问作者Jacob