我们的数据库中存在大量非活动会话。
我们如何清理这些不活跃的会话？
数据库 - 带有 ASM 的 Oracle 10g R2
我不确定是否有问题。
如果会话在V$SESSION那个特定时刻没有执行 SQL 语句，则它的状态为“INACTIVE”。如果用户在客户端-服务器应用程序中打开一个专用会话并大量使用该应用程序，则该会话在 99% 的时间内处于“非活动状态”并不罕见，因为绝大多数时间都花在等待上供人类阅读和处理屏幕上的数据。会话“非活动”这一事实并不意味着它在几秒钟前不是“活动”，或者几秒钟后它不会再次“活动”。中的LAST_CALL_ET列V$SESSION如果会话当前处于“非活动”状态，则显示自会话上次处于“活动”状态以来经过的秒数。这可能会让您了解您是否正在处理已经活跃了一段时间的会话。
如果您有一个三层应用程序，您的中间层服务器通常会维护一个数据库连接池。中间层会打开许多连接，并使它们或多或少无限期地保持打开状态。当用户需要与数据库交互时，他们从池中获取连接，运行查询，并将连接返回到池中。在工作负载高峰时，连接池可以将大量应用程序用户集中到相对较少的数据库连接中，这意味着会话将花费更多时间处于“活动”状态。但是在低使用率期间，中间层可能会维护一堆“INACTIVE”会话。
在这两种情况中的任何一种情况下，拥有许多“非活动”会话都不是一件坏事。“清理”那些非活动会话将导致打开它们的应用程序出错。
如果由于客户端进程失败（即客户端应用程序崩溃并且数据库不知道该事实）而有大量非活动会话，则可以使用服务器的 sqlnet.ora 文件中的sqlnet.expire_time 参数定期发送一个探测数据包到客户端机器。这可能会对性能产生负面影响，但它将允许数据库更快地发现客户端进程已失败。
如果您有大量非活动会话，因为您的中间层服务器在它们的连接池中创建了太多到数据库的连接，您需要与中间层管理员交谈，要求他们减少在他们的连接中打开的连接数连接池。如果他们最近向中间层群添加了更多服务器，则他们可能需要减少每个服务器在其连接池中维护的连接数。
如果您的问题是分配给所有需要打开的专用服务器连接的 RAM 过多（如果您有很多客户端服务器应用程序，则尤其常见），您可以将 Oracle 配置为支持共享服务器连接，因为这会减少每个连接所需的内存量。