1. 从一次生产告警说起为什么这两个参数如此关键那天下午监控系统突然告警提示某个核心业务数据库的连接池出现大量“ORA-01000: maximum open cursors exceeded”错误。应用日志里这个错误像野火一样蔓延直接导致部分用户下单失败。团队紧急介入第一反应是检查数据库的open_cursors参数值。当时设置的是300对于这个日订单量几十万的系统来说显然不够。我们迅速将其调整到1000暂时压住了告警。但问题真的解决了吗一周后告警再次响起虽然频率低了但依然存在。这次我们深入进去发现另一个关键参数session_cached_cursors被忽略了它默认是50。大量重复执行的SQL比如“根据用户ID查询基本信息”并没有被会话缓存住每次执行都在“打开-解析-关闭”的循环中不仅消耗CPU还快速消耗着open_cursors的额度。调整session_cached_cursors后问题才真正根除。这次经历让我深刻体会到open_cursors和session_cached_cursors绝不是两个孤立的、可以随意设置的数字。它们共同管理着数据库会话中游标Cursor的生命周期和资源占用一个管“天花板”一个管“缓存效率”理解其背后的原理和联动关系是进行数据库性能调优和稳定性保障的基本功。很多DBA和开发者只知其然觉得不够就调大但这往往会掩盖更深层次的低效SQL或应用设计问题。今天我就结合多年踩坑经验把这俩参数掰开揉碎了讲清楚。2. 游标Cursor到底是什么数据库工作的核心单元在深入参数之前我们必须先统一认识什么是游标你可以把它想象成数据库服务器端为了执行和管理一条SQL语句或一个PL/SQL块而分配的一块私有内存区域。这块内存里存放了这条SQL的解析结果解析树、执行计划、绑定变量值、查询结果集的状态信息等。每当你的应用比如一个Java程序通过JDBC发送一条SELECT * FROM users WHERE id ?到数据库数据库服务器就会为这个请求创建一个游标。这个创建过程专业术语叫“打开游标”Open a Cursor。游标打开后会经历解析Parse、绑定Bind、执行Execute、获取Fetch等阶段。执行完毕后游标可以被关闭Close它占用的服务器端资源主要是PGA内存也随之释放。这里有一个关键点“打开游标”这个动作主要消耗的是数据库服务器端SGA和PGA的内存和CPU资源而不是你应用客户端的内存。一个会话能同时保持“打开”状态的游标数量是有限的这个限制就是open_cursors。为什么要有这个限制根本目的是防止单个有bug的会话比如循环打开游标却不关闭耗尽服务器内存导致数据库实例不稳定。在Oracle中游标主要分几类隐式游标对于单行的INSERT,UPDATE,DELETE,SELECT ... INTO语句Oracle会自动为其创建和管理游标你无需也无法显式控制。显式游标在PL/SQL中通过CURSOR c1 IS SELECT ...声明的游标需要开发者显式地OPEN,FETCH,CLOSE。引用游标REF CURSOR一种动态的游标变量更灵活。SQL游标对于应用层如JDBC发送的每一条独立的SQL语句Oracle都会为其分配一个游标。这是我们今天讨论的重点因为session_cached_cursors主要优化的就是这类游标。理解游标是资源消耗单元这个本质就能明白为什么open_cursors是一个重要的资源限制参数。3. OPEN_CURSORS会话游标数量的硬性天花板OPEN_CURSORS参数定义了单个数据库会话能够同时保持“打开”状态的游标数量的最大值。注意这个“同时打开”的状态。一个游标被“打开”后即使它已经执行完毕如果没有被显式关闭或因为某些原因被缓存它可能仍然计入这个限制。3.1 参数含义与默认值这是一个会话级Session-level的参数但它在实例级别Instance-level被定义。也就是说你通过ALTER SYSTEM SET open_cursors1000 SCOPEBOTH;修改的是所有新会话的默认上限每个会话都可以拥有最多1000个同时打开的游标。它的默认值在不同Oracle版本中有所变化早期可能是50或100在较新的版本如11g、12c、19c中默认值通常是300。对于任何稍有规模的在线事务处理OLTP系统300这个值都显得过于保守很容易成为瓶颈。3.2 如何查看与设置查看当前实例的设置和会话的使用情况-- 查看实例级参数设置 SHOW PARAMETER open_cursors; -- 查看当前会话已经打开了多少个游标 SELECT a.value AS cur_open, p.value AS max_open FROM v$sesstat a, v$statname b, v$parameter p WHERE a.statistic# b.statistic# AND b.name opened cursors current AND p.name open_cursors AND a.sid SYS_CONTEXT(USERENV, SID); -- 更详细的视图v$open_cursor可以查看具体是哪些SQL占用了游标 SELECT sid, sql_text, count(*) as cursor_count FROM v$open_cursor WHERE sid 你的SID GROUP BY sid, sql_text ORDER BY cursor_count DESC;设置参数通常需要DBA权限ALTER SYSTEM SET open_cursors1000 SCOPEBOTH;修改后只对新建立的会话生效。已有的会话仍然沿用其连接建立时的参数值。因此在调整此参数后通常需要重启应用或连接池来重建连接使新值生效。3.3 什么情况下会耗尽OPEN_CURSORS应用层游标泄漏这是最常见的原因。在使用JDBC、OCI等接口时没有正确地关闭Statement、PreparedStatement或ResultSet对象。每个未关闭的Statement都对应一个服务器端未关闭的游标。随着时间推移累积的游标数最终会突破上限。高并发且复杂的业务逻辑单个业务请求可能需要执行数十条甚至上百条不同的SQL语句。如果系统并发用户数很高比如上千即使每个会话只同时打开几十个游标乘以会话数对服务器内存的总压力也很大。但open_cursors限制的是单个会话所以这里的问题更可能是每个会话的负载都很重。SESSION_CACHED_CURSORS设置过小这是关键联动点如果应用大量重复执行相同的SQL例如根据主键查询理想情况是这些SQL被缓存在会话游标缓存中复用。如果缓存大小不够这些SQL就无法被缓存每次执行都可能被视为一个新的游标软解析从而快速消耗open_cursors额度。开发框架或ORM的默认行为一些ORM框架如早期Hibernate的某些配置可能不会高效地重用或关闭PreparedStatement导致游标在服务器端堆积。3.4 设置多少合适一个经验公式与监控方法盲目调大open_cursors比如直接设为10000是危险的这会增加每个会话潜在的内存开销PGA。一个合理的设置需要基于监控。首先监控峰值使用情况-- 过去一段时间内所有会话打开游标的峰值比例 SELECT max_usage, max_used_percent FROM ( SELECT sid, max(a.value) as max_usage FROM v$sesstat a, v$statname b WHERE a.statistic# b.statistic# AND b.name opened cursors current GROUP BY sid ) session_max, ( SELECT value as max_allowed FROM v$parameter WHERE name open_cursors ) param WHERE max_usage 0;一个常用的经验法则是将参数值设置为监控到的“单个会话游标同时打开数”的峰值再乘以1.5到2的安全系数。例如监控发现最耗游标的会话峰值是480那么可以设置为480 * 1.5 720向上取整到800或1000。更科学的方法是持续观察v$sesstat中的opened cursors current统计项确保在业务高峰时段没有会话的使用率持续超过80%。同时必须结合v$open_cursor视图分析那些游标数量多的SQL从源头上优化应用逻辑或引入缓存。注意调大open_cursors只是缓解症状如果游标数量持续增长即存在泄漏再大的值最终也会被耗尽。必须找到并修复游标未关闭的根本原因。4. SESSION_CACHED_CURSORS提升性能的会话级游标缓存如果说open_cursors是“防洪坝”那么session_cached_cursors就是“蓄水池”它的目标是减少重复解析SQL的软解析开销。4.1 软解析、硬解析与游标缓存当一条SQL首次执行时Oracle会进行“硬解析”Hard Parse检查语法语义、检查权限、生成执行计划等这是一个CPU密集型操作。之后如果相同的SQL文本完全一致包括空格、大小写再次执行Oracle会尝试进行“软解析”Soft Parse即跳过耗时的生成执行计划阶段复用已有的游标。session_cached_cursors参数更进一步。它允许Oracle在会话级别缓存已经关闭的游标。即使应用调用了close()方法Oracle也不会立即完全清理这个游标在服务器端的上下文而是将其放入一个会话私有的LRU最近最少使用缓存链表里。当相同的SQL需要再次执行时Oracle可以直接从缓存链表中取出这个游标将其状态“复活”这比软解析还要快因为连在共享池Library Cache中查找游标信息的开销都省了可以理解为一种“会话级的软软解析”。4.2 参数含义与工作机制SESSION_CACHED_CURSORS定义了每个会话可以缓存的已关闭游标的最大数量。默认值通常是50。它的工作流程简化如下会话执行一条SQLSQL_A进行解析可能是硬解析或软解析并执行。SQL_A执行完毕应用关闭游标。Oracle检查会话游标缓存。如果缓存未满则将SQL_A的游标信息放入缓存链表。稍后同一会话再次执行完全相同的SQL_A。Oracle首先检查自己的会话游标缓存。如果找到SQL_A的缓存游标则直接复用称为“会话游标缓存命中”这几乎没有任何解析开销。如果没找到再走正常的共享池查找流程软/硬解析。4.3 如何查看缓存效果与设置查看当前会话的游标缓存命中情况-- 查看当前会话的游标缓存统计 SELECT name, value FROM v$sesstat s, v$statname n WHERE s.statistic# n.statistic# AND s.sid SYS_CONTEXT(USERENV, SID) AND n.name IN (session cursor cache hits, parse count (total), parse count (hard)); -- 计算会话游标缓存命中率 SELECT a.value AS cache_hits, b.value AS total_parses, ROUND((a.value / b.value) * 100, 2) AS hit_ratio FROM v$sesstat a, v$sesstat b, v$statname na, v$statname nb WHERE a.sid SYS_CONTEXT(USERENV, SID) AND b.sid a.sid AND na.statistic# a.statistic# AND na.name session cursor cache hits AND nb.statistic# b.statistic# AND nb.name parse count (total);一个健康的、大量重复执行相同SQL的OLTP系统session cursor cache hits应该很高命中率最好能在90%以上。查看当前参数设置SHOW PARAMETER session_cached_cursors;设置参数ALTER SYSTEM SET session_cached_cursors200 SCOPEBOTH;同样此修改只对新会话生效。4.4 设置多少合适与OPEN_CURSORS的联动这个值的设置与open_cursors紧密相关也与应用模式有关。监控决定法查询v$sesstat找到session cursor cache count的峰值。这个值表示当前会话缓存了多少游标。将参数设置为该峰值的1.2-1.5倍。同时观察session cursor cache hits如果这个值增长缓慢而parse count (total)很高说明缓存大小可能不足。经验公式法常用一个经典的实践经验是将SESSION_CACHED_CURSORS设置为应用在单个会话中最频繁执行的、不同的SQL语句的数量。例如一个用户会话主要操作包括登录验证、查询个人信息、查询订单列表、提交订单。这大概对应4-5条核心SQL。但考虑到每个功能可能有多个变种分页查询等可以初步设置为50-100。对于使用复杂ORM如Hibernate或有很多动态查询的应用这个值需要更大比如200-300。联动考量增大SESSION_CACHED_CURSORS可以有效降低对OPEN_CURSORS的消耗。因为重复SQL的游标被缓存复用就不会频繁地“打开-关闭”从而减少了同一时刻“打开”状态的游标数量。在遇到ORA-01000错误时除了调大open_cursors一定要检查并考虑调大session_cached_cursors这往往是从根本上缓解问题的更优解。注意缓存游标同样会占用PGA内存。每个缓存的游标大约占用几百字节的内存。设置得过大比如几千会导致每个会话的PGA内存膨胀在连接数很多时可能引发PGA内存不足的问题。需要平衡性能和内存开销。5. 实战排查ORA-01000错误的完整诊断链路当“maximum open cursors exceeded”错误出现时按照以下链路进行排查可以系统性地定位问题。5.1 第一步紧急止血与信息收集首先立即增大open_cursors参数值为排查争取时间。同时收集现场信息-- 1. 找到报错的会话(SID, SERIAL#) SELECT sid, serial#, username, program, machine FROM v$session WHERE sid (SELECT sid FROM v$mystat WHERE rownum1); -- 如果是当前会话可以这样查 -- 更常见的是从应用日志或告警信息中获得SID -- 2. 查看该会话当前的游标使用情况 SELECT sid, sql_text, count(*) as open_cursor_count FROM v$open_cursor WHERE sid ERROR_SID GROUP BY sid, sql_text HAVING count(*) 5 -- 查看打开数量较多的SQL ORDER BY open_cursor_count DESC; -- 3. 查看该会话的游标相关统计信息 SELECT sn.name, ss.value FROM v$sesstat ss, v$statname sn WHERE ss.statistic# sn.statistic# AND ss.sid ERROR_SID AND sn.name IN (opened cursors cumulative, opened cursors current, session cursor cache hits, parse count (total), parse count (hard));opened cursors cumulative是从会话开始累计打开的游标总数如果这个值异常高说明存在大量游标的打开/关闭操作。opened cursors current是当前打开的游标数它应该接近但不超过open_cursors参数值。5.2 第二步分析V$OPEN_CURSOR定位问题SQLv$open_cursor视图是诊断的关键。关注那些open_cursor_count很高的SQL。如果大量游标指向相同的SQL文本这强烈表明应用在重复执行同一条SQL但没有有效利用游标缓存session_cached_cursors可能太小或者应用在循环中频繁创建和关闭PreparedStatement而没有复用。如果游标指向大量不同的SQL且每条SQL只有1-2个游标这可能表明应用存在游标泄漏Statement未关闭或者业务逻辑本身就会生成大量动态SQL如ORM框架生成的带不同条件的查询。5.3 第三步结合应用代码分析根因根据v$open_cursor的线索转向应用层。场景A重复SQL游标计数高。检查1应用是否使用了连接池如HikariCP, Druid连接池中的连接是长连接其会话游标缓存是有效的。确保应用代码中对于重复执行的SQL如根据ID查询使用的是PreparedStatement并且这个PreparedStatement对象在可能的情况下被复用比如放在方法局部变量外而不是每次执行都conn.prepareStatement(sql)。检查2检查数据库session_cached_cursors参数值。对于重复SQL多的应用建议设置为100-300。可以通过调整参数并观察session cursor cache hits是否上升来验证效果。场景B大量不同SQL游标累积。检查1这是典型的游标泄漏。检查代码中所有创建Statement,PreparedStatement,CallableStatement,ResultSet的地方是否都在finally块中或try-with-resources语句中确保了关闭。注意关闭顺序先关闭ResultSet再关闭Statement。检查2检查使用的框架。例如旧版本的MyBatis在某些场景下如果手动处理事务可能需要特别注意关闭SqlSession。Spring的JdbcTemplate通常能很好地管理资源但如果你直接获取了底层的Connection进行操作就需要自己负责关闭。检查3是否存在动态SQL拼接导致每条SQL在文本上都不同即使逻辑相同例如SELECT * FROM t WHERE id IN (1,2,3)和SELECT * FROM t WHERE id IN (4,5)在Oracle看来是两条不同的SQL无法共享游标。应考虑使用绑定变量WHERE id IN (:list)或批处理。5.4 第四步配置与优化建议参数配置对于大多数OLTP应用我推荐的起点值是OPEN_CURSORS: 1000SESSION_CACHED_CURSORS: 200 然后根据上述监控数据进行精细调整。应用层最佳实践强制使用绑定变量杜绝在应用代码中拼接SQL字符串。这不仅能避免SQL注入也是减少硬解析、提高游标共享率的生命线。使用PreparedStatement并复用在循环中执行相同SQL时在循环外创建一次PreparedStatement在循环内只进行参数绑定和执行。确保资源关闭使用try-with-resourcesJava 7语法让编译器自动帮你关闭资源。// 正确示例 String sql SELECT name FROM users WHERE id ?; try (Connection conn dataSource.getConnection(); PreparedStatement pstmt conn.prepareStatement(sql)) { pstmt.setInt(1, userId); try (ResultSet rs pstmt.executeQuery()) { // process result } } catch (SQLException e) { // handle exception }审查ORM框架配置例如在Hibernate中关注hibernate.jdbc.fetch_size和hibernate.jdbc.batch_size不合理的设置可能影响游标行为。确保了解你所用框架的会话/语句管理机制。6. 高级话题游标相关的其他参数与视图除了这两个核心参数还有一些相关的参数和视图有助于深入理解游标管理。6.1 OPEN_CURSORS与SESSION_CACHED_CURSORS的关联参数CURSOR_SPACE_FOR_TIME(已废弃)这个老参数曾用于在共享池中为游标固定空间以提升性能但在现代Oracle版本中已不再推荐使用默认且建议为FALSE。CURSOR_SHARING这个参数影响游标共享的粒度。默认值为EXACT要求SQL文本完全一致包括字面量才能共享。有时为了快速解决因未使用绑定变量导致的硬解析过多问题会临时设置为FORCE或SIMILAR后者在12c后已废弃让Oracle将字面量替换为绑定变量。但这是一种“治标”的应急手段会带来执行计划不稳定的风险根本解决之道还是在应用层使用绑定变量。SESSION_MAX_OPEN_FILES这个参数限制会话能打开的BFILE数量与游标无关不要混淆。6.2 有用的动态性能视图V$SQLAREA/V$SQL查看共享池中SQL的执行统计信息包括解析次数、执行次数、磁盘读等。通过对比PARSE_CALLS和EXECUTIONS可以找出解析频繁但执行可能不高效的SQL。V$SQLSTATS提供SQL执行的高级别统计性能开销比V$SQL低。V$SYSSTAT/V$SESSTAT系统级和会话级的统计信息我们之前用到的session cursor cache hits、parse count (total)等都来自这里。监控cursor authentications等统计项也有助于了解游标管理开销。V$RESOURCE_LIMIT查看各类资源包括max_open_cursors注意这里是全局的不是会话级的当前使用量和上限。CURRENT_UTILIZATION接近MAX_UTILIZATION时就需要警惕。理解这些视图可以让你从系统全局视角审视游标相关的性能与资源瓶颈。7. 总结与个人踩坑心得回顾这两个参数open_cursors是资源护栏防止失控的会话拖垮系统session_cached_cursors是性能加速器通过复用减少重复劳动。它们一个管“能不能”一个管“快不快”。我个人的几点深刻体会第一永远不要孤立地看待一个参数。当初我们只调open_cursors就像房间漏水只拼命用桶接却不去找漏水点。session_cached_cursors就是那个堵漏的点。调整后者往往能以更小的资源代价增加一点PGA内存获得更好的性能提升和更稳定的运行状态。第二监控比猜测更重要。凭感觉设置“1000”和“200”只是起点。必须建立对v$sesstat、v$open_cursor的常态化监控。我习惯在巡检脚本里加入对opened cursors current峰值与open_cursors比值、session cursor cache hit ratio的检查设定阈值告警。这能让你在用户报障之前就发现问题苗头。第三数据库参数优化治标应用代码优化治本。绝大多数游标相关问题根源都在应用层要么是资源泄漏没关闭Statement要么是模式低效不用绑定变量、不重用PreparedStatement。参数调整为你赢得了排查和修复应用代码的时间窗口但绝不能替代代码层面的优化。我曾遇到过将open_cursors调到5000仍然被耗尽的案例最后发现是一个后台任务在循环中错误地每次都创建新的PreparedStatement。修复那段代码后参数调回1000也稳如泰山。最后修改这些参数前尤其是在生产环境务必在测试环境验证。观察调整后数据库的PGA内存使用情况、软解析率soft parse ratio和会话游标缓存命中率的变化。确保性能提升的同时不会引入新的资源压力。数据库调优是一门平衡的艺术而理解open_cursors和session_cached_cursors的联动无疑是这门艺术中基础而重要的一笔。