我们的应用程序使用c3 p0 - 0.9.5.5.jar和ojdbc 8 - 12.2.0.1.jar来连接Oracle 19 C。
这是正在传递的旗帜com.mchange.v2.c3p0.PoolBackedDataSource@a07b9a4b [ connectionPoolDataSource ->com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@74b02295 [ acquireIncrement -> 1, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, contextClassLoaderSource -> caller, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, forceSynchronousCheckins -> false, identityToken -> 31qzq3ay1xf5c0jx94505|6f4d2294, idleConnectionTestPeriod -> 5, initialPoolSize -> 0, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 45, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 10, maxStatements -> 0, maxStatementsPerConnection -> 0, minPoolSize -> 0, nestedDataSource -> com.mchange.v2.c3p0.DriverManagerDataSource@d898aa34 [ description -> null, driverClass -> null, factoryClassLocation -> null, forceUseNamedDriverClass -> false, identityToken -> 31qzq3ay1xf5c0jx94505|6d9428f3, jdbcUrl -> jdbc:oracle:thin:@x.x.x.x:1521:orcl, properties -> {user=******, password=******} ], preferredTestQuery -> null, privilegeSpawnedThreads -> false, propertyCycle -> 0, statementCacheNumDeferredCloseThreads -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, extensions -> {}, factoryClassLocation -> null, identityToken -> 31qzq3ay1xf5c0jx94505|900649e, numHelperThreads -> 3 ]]
已执行以下查询：
select status，program，username，last_call_et from v$session WHERE STATUS = 'INACTIVE';
| 用户名|地位|程序|LAST_CALL_ET|
| --|--|--|--|
| EMPDB|非活动|JDBC瘦客户端| 1727905 |
| EMPDB|非活动|JDBC瘦客户端| 1727904 |
我看到在Oracle 19 c中创建了250多个非活动会话。
非活动会话是否会导致托管Oracle DB Server的CPU峰值？
如何找到创建非活动会话的根本原因？
有没有什么方法可以通过设置一些属性来减轻Application Server的这种情况？
我试图调查根本原因，但没有运气。
我正在寻找解决方案，以找到这些不活动会话的确切根源（从Oracle DB Server端和应用程序端）。
1条答案
按热度按时间u4dcyp6a1#
inactive状态仅意味着会话在您选中v$session的 * 确切 * 时刻没有执行任何操作。它处于空闲状态，等待下一个SQL命令。* 大多数 * 会话在任何给定时间都处于非活动状态，包括Oracle为执行内部数据库操作而生成的后台会话。这本身并不是一个资源问题或令人担忧的原因：这是大多数会话的正常预期行为。总共有几百个会话来支持后台进程和用户操作并不罕见，这取决于您的确切设置。对于大多数配置，每个会话都Map到DB服务器上具有保留内存的专用进程，因此，如果有任何原因需要关注资源，那就是内存使用。
如果您的应用程序正在生成更多的用户会话（对于
empdb？）而不是会话池参数中规定的，则可能存在某种会话“泄漏”，您需要从应用程序端排除根本原因。随着时间的推移监视应用程序会话的数量（而不是它们的状态），如果它继续未经检查地增长，这可能是您的问题。如果这个数字在一段时间内保持不变，那么你可能没问题，假设应用程序按预期工作。