对比两份AWR报告中open_cursor、session、process参数异常问题咨询

1. open_cursor值偏高的判定及排查方法 #

判定是否偏高 #

不能仅看参数绝对值，要结合实际使用情况和报错：

• 查看是否出现*ORA-01000: maximum open cursors exceeded*错误，出现则说明当前设置不足以支撑业务需求。
• 对比AWR报告中Cursor Usage模块的Pct of Cursor Cache Used，若该值持续超过90%，说明游标缓存使用率过高。
• 查询动态视图v$sesstat，对比opened cursors current（当前打开游标数）与*open_cursors*参数值，若前者接近或超过后者，判定为偏高。

排查原因的方法及相关表/视图 #

• 查询当前打开的游标分布：通过v$open_cursor定位占用游标最多的用户和SQL语句：

SELECT user_name, sql_id, COUNT(*) AS cursor_count
FROM v$open_cursor
GROUP BY user_name, sql_id
ORDER BY cursor_count DESC;

• 分析会话游标使用情况：通过v$sesstat查看单会话的游标累积和当前打开数：

SELECT s.sid, s.username, t.name, s.value
FROM v$sesstat s
JOIN v$statname t ON s.statistic# = t.statistic#
WHERE t.name IN ('opened cursors current', 'opened cursors cumulative')
ORDER BY s.value DESC;

• 检查SQL解析情况：查看AWR中SQL Statistics模块的Parse Calls与Executions比值，若比值接近1，说明硬解析频繁，会导致游标数激增（未使用绑定变量是常见原因）。
• 排查应用代码：检查是否存在未关闭游标的情况（如Java未关闭Statement、PL/SQL未关闭REF CURSOR），这类代码会导致游标泄漏，持续占用游标资源。

2. processes参数值的含义及偏高影响 #

参数含义 #

*processes*是Oracle数据库允许的最大操作系统服务器进程数，AWR中显示的20000和1500通常为两个库的*processes*参数设置值；若为实际运行数值，则代表对应时段内数据库使用的服务器进程数。

偏高的影响 #

• SGA层面：若使用共享服务器模式，每个进程的UGA（用户全局区）会占用SGA内存，大量进程会导致SGA内存占用飙升，可能引发内存不足、系统分页频繁，进而拖慢数据库性能。
• I/O层面：过多进程会引发磁盘I/O竞争，多个进程同时读写数据文件、重做日志文件，会导致I/O队列长度增加，磁盘响应时间变长，出现db file sequential read、log file sync等等待事件激增。
• 系统资源层面：操作系统CPU、内存消耗剧增，进程上下文切换频率大幅上升，导致系统整体吞吐量下降，甚至出现操作系统级别的资源耗尽。
• 数据库层面：可能触发*ORA-00020: maximum number of processes exceeded*错误，新的数据库连接无法建立；同时会加剧锁资源竞争，引发enqueue类等待事件增加。

3. 会话数量偏高的判定、与并行会话的关系及排查 #

与并行会话的关联 #

会话数量偏高可能与并行会话有关，但并非直接关联：并行查询会启动多个并行从属服务器进程（属于*processes*范畴），若大量并行查询运行，会占用过多进程资源，间接导致新用户会话无法及时创建；但会话数偏高更多源于用户连接数过多、会话未及时释放等问题。

判定是否偏高 #

• 对比*SESSIONS*参数（默认值为processes*1.1+5），查询v$session中的用户会话数，若接近或超过该参数值，判定为偏高。
• 查看AWR中Session Statistics模块的Logons Current指标，若该值持续处于高位或增长过快，说明会话资源占用异常。
• 观察等待事件：若connection management call、latch: shared pool等等待事件占比过高，可能与会话数量偏高相关。

排查成因 #

• 检查并行会话情况：通过v$px_session查看并行执行的从属进程数，判断是否存在大量并行查询：

SELECT qcsid, COUNT(*) AS parallel_slaves
FROM v$px_session
GROUP BY qcsid
ORDER BY parallel_slaves DESC;

若并行进程过多，需检查表的并行度设置、会话级并行强制配置是否合理。

• 分析会话状态分布：通过v$session统计不同状态、不同用户的会话数，定位异常会话来源：

SELECT status, username, COUNT(*) AS session_count
FROM v$session
WHERE type = 'USER'
GROUP BY status, username
ORDER BY session_count DESC;

若存在大量INACTIVE会话未释放，需排查连接池配置（如最小连接数过高、超时设置不合理）或应用连接泄漏问题。

• 检查连接池配置：确认应用连接池的最大连接数、超时回收机制是否合理，是否存在连接未及时归还的情况。

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