我们的应用程序使用 c3p0-0.9.5.5.jar 和 ojdbc8-12.2.0.1.jar 来连接 Oracle 19C。
这是正在传递的标志
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 ]]
执行以下查询:
选择状态、程序、用户名、last_call_et 来自 v$session WHERE STATUS = 'INACTIVE';
用户名 | 状态 | 节目 | LAST_CALL_ET |
---|---|---|---|
EMDB | 不活跃 | JDBC 瘦客户端 | 1727905 |
EMDB | 不活跃 | JDBC 瘦客户端 | 1727904 |
我看到 Oracle 19c 中创建了超过 250 个非活动会话。
非活动会话是否会导致托管 Oracle DB Server 的 CPU 峰值?
如何找到创建非活动会话的根本原因?
我们有什么方法可以通过设置一些属性来减轻应用程序服务器的这种情况吗?
我尝试调查根本原因,但没有成功。
我正在寻找解决方案来找到这些不活动会话的确切根本原因(来自 Oracle 数据库服务器端和应用程序端)。
inactive
状态仅意味着会话在您检查v$session
的确切时刻没有执行任何操作。它处于空闲状态,等待下一个 SQL 命令。 大多数会话在任何给定时间都是不活动的,包括 Oracle 生成的用于执行内部数据库操作的后台会话。这本身并不是资源问题或引起关注:对于大多数会话来说,这是正常的预期行为。
支持后台进程和用户操作的总共数百个会话并不罕见,具体取决于您的具体设置。对于大多数配置,每个会话都映射到数据库服务器上保留内存的专用进程,因此如果有任何原因担心资源,那就是内存使用。
如果您的应用程序生成的用户会话(对于
empdb
?)多于会话池参数中规定的数量,则可能会出现某种会话“泄漏”,您需要从应用程序端排除根本原因。随着时间的推移监控应用程序会话的数量(而不是其状态),如果它继续不受控制地增长,这可能是您的问题。如果该数字随着时间的推移保持不变,那么您可能没问题,假设应用程序按预期工作。