游标泄漏是Oracle运维和开发中非常典型的一类问题，它的表象通常很统一：应用运行一段时间后抛出ORA-01000 maximum open cursors exceeded错误，重启应用后恢复，过段时间又复发。这类问题的根源在于会话打开的游标没有被及时释放，导致打开数持续累积直至触发OPEN_CURSORS参数上限。排查这类问题需要一套系统的方法，从确认泄漏现象开始，逐步缩小范围到具体会话、具体SQL，最终回到应用代码层面找到症结。
一、先弄清楚游标计数的来源
很多人一看到ORA-01000就想着直接调大OPEN_CURSORS参数，这其实是治标不治本。首先要理解v$open_cursor视图和会话游标统计口径的差异。v$open_cursor展示的是当前会话持有或缓存的游标信息，其中包含了会话游标缓存（session cursor cache）中的条目，所以这个数字往往会比实际打开的游标数偏大。
真正反映当前打开游标数量的指标，需要查询v$sesstat中statistic#对应的opened cursors current统计项。可以通过下面的SQL确认某个会话当前真实打开的游标数：
-- 查看各会话当前打开的游标数量，按降序排列
SELECT s.sid, s.serial#, s.username, s.machine, s.program,
st.value AS opened_cursors
FROM v$sesstat st, v$statname sn, v$session s
WHERE st.statistic# = sn.statistic#
AND sn.name = 'opened cursors current'
AND st.sid = s.sid
AND st.value > 0
ORDER BY st.value DESC;
如果某个会话的数值随时间持续增长且从不回落，基本可以判定为泄漏。而如果数字增长到某个水平后趋于稳定，只是恰好超过了OPEN_CURSORS的设置，那问题可能是参数配置过低或会话游标缓存设置过大，而不是真正的泄漏，这两种情况的处理方式完全不同。
另外要注意区分PL/SQL代码中的隐式游标。PL/SQL在FOR循环查询、隐式SELECT INTO等场景下会自动管理游标的打开和关闭，正常不会泄漏。但如果使用了显式的OPEN ... FETCH而没有对应的CLOSE，或者打开了REF CURSOR返回给调用方却没有在调用方关闭，就会造成泄漏。
二、定位泄漏的具体SQL语句
确认了泄漏会话之后，下一步是找出到底是哪些SQL占用了游标。v$open_cursor视图记录了会话打开或缓存的游标对应的SQL文本，按SQL_ID和SQL_TEXT聚合统计可以快速看出哪些语句被重复打开了大量次数：
-- 统计某个会话打开的游标对应的SQL及次数
SELECT oc.sql_id,
oc.sql_text,
COUNT(*) AS cursor_count
FROM v$open_cursor oc
WHERE oc.sid = :sid
GROUP BY oc.sql_id, oc.sql_text
ORDER BY cursor_count DESC;
如果发现同一条SQL_TEXT被打开了成百上千个游标，这就是最明显的泄漏特征。正常情况下，相同的SQL通过绑定变量共享执行计划，只需要一个子游标即可，重复大量打开说明应用端每次执行都创建新的语句对象且未释放。
进一步可以结合v$sqlarea的version_count字段观察。version_count过高通常指向子游标过多，原因可能是绑定变量类型或长度不一致导致的无法共享，这虽然不完全是泄漏，但同样会消耗大量共享池和游标资源，值得一并排查：
-- 查找子游标版本数异常多的SQL SELECT sql_id, sql_text, version_count, executions FROM v$sqlarea WHERE version_count > 50 ORDER BY version_count DESC;
还有一种情况是循环内执行动态拼接的SQL，每轮循环生成的SQL文本都不同，导致无法共享也无法复用，游标数量线性增长。这类问题在排查时表现为大量结构相似但字面值不同的SQL文本，特征非常明显。
三、常见泄漏成因与代码层面的修复
排查到最后，问题几乎都落在应用代码上。以下是几类高频成因，可以逐一对照检查。
第一类是JDBC应用中Statement或ResultSet未关闭。特别是PreparedStatement，如果在循环中反复创建却从不调用close方法，每个未关闭的语句都会占用一个游标。正确做法是把close放到finally块中，或者使用try-with-resources语法自动关闭：
// 错误写法：循环内创建PreparedStatement但未关闭
for (String name : names) {
PreparedStatement ps = conn.prepareStatement(
"SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();
// 未关闭ps和rs，游标持续累积
}
// 正确写法：try-with-resources自动释放资源
for (String name : names) {
String sql = "SELECT * FROM users WHERE name = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setString(1, name);
try (ResultSet rs = ps.executeQuery()) {
while (rs.next()) {
// 处理结果
}
}
} // ps和rs自动关闭，游标被释放
}
第二类是PL/SQL中显式游标或REF CURSOR未关闭。打开的显式游标在会话结束前一直持有，如果代码路径中存在异常分支跳过了CLOSE语句，泄漏就会发生。建议统一在异常处理块中关闭游标，或将逻辑改写为FOR循环游标由Oracle自动管理。
第三类是连接池配置不当。连接池中的连接长期不归还，长生命周期会话不断累积游标。此外，某些ORM框架的语句缓存（如Hibernate的查询缓存、MyBatis的语句配置）如果缓存数量设置得过大，配合长连接也会让游标数居高不下。这类情况需要结合框架配置评估合理的缓存大小。
第四类容易被忽略：应用抛出异常后资源未清理。例如执行查询时发生超时异常，连接被强制中断但语句对象仍挂在会话上。这种场景建议在异常捕获中显式关闭相关资源，并检查驱动版本是否存在已知的游标泄漏缺陷。
四、预防与监控建议
解决问题之后，还应该建立长期的监控机制避免复发。可以定期采集v$sesstat中opened cursors current的数值，与OPEN_CURSORS参数值做对比，设置阈值告警，比如达到参数值的百分之七十时提醒。
关于OPEN_CURSORS参数本身，可以适当调大作为缓冲，比如从默认值调到一千甚至更高，但前提是必须确认代码没有泄漏。如果带着泄漏去调参数，只是把爆发时间推迟而已。合理的做法是参数值留有余量，同时保证代码资源管理的规范性。
代码规范层面，团队应当约定所有数据库资源的使用必须遵循创建即关闭原则，通过代码评审检查循环内的语句创建逻辑，在持续集成中加入静态分析工具扫描未关闭的资源。这些措施组合起来，才能从根本上杜绝游标泄漏反复出现。
总结一下排查路径：先用v$sesstat确认泄漏会话，再用v$open_cursor按SQL聚合定位泄漏语句，最后回到应用代码检查资源关闭逻辑。沿着这条链路走，绝大多数ORA-01000问题都能在短时间内找到根因。
Oracle游标泄漏ORA-01000OPEN_CURSOR修改时间：2026-09-15 08:04:34