How to Monitor and Tune Open and Cached Cursors in Oracle with TaoToken

1. 从一次 ORA-01000 说起：Open Cursors 到底是什么

线上告警突然弹出来，应用日志里刷屏ORA-01000: maximum open cursors exceeded，业务侧开始报错。你登上数据库一查，某个会话的opened cursors current已经顶到了open_cursors的上限。这个场景对 DBA 和后端工程师来说并不陌生，而它背后牵扯的正是 Oracle 里两个容易被混淆的参数：OPEN_CURSORS和SESSION_CACHED_CURSORS。

先说清楚概念。游标（cursor）本质上是会话里指向私有 SQL 区的一个句柄，每执行一条 SQL，Oracle 就会为它分配一个游标。OPEN_CURSORS限制的是单个会话同一时刻最多能同时打开多少个游标，默认值 50，Oracle 官方建议大多数应用至少设到 500。一旦某个会话打开的游标数达到这个上限，再想开新的就会直接抛 ORA-01000。

而SESSION_CACHED_CURSORS管的是另一件事：它设置每个会话游标缓存（session cursor cache）里最多能缓存多少个已关闭的游标，默认 50。注意关键词是"已关闭"——被缓存的游标并不处于打开状态，所以它和OPEN_CURSORS之间没有数量上的约束关系，你完全可以把SESSION_CACHED_CURSORS设得比OPEN_CURSORS还大。它的作用是：当应用反复解析同一条 SQL 时，如果这条 SQL 的游标还在会话缓存里，Oracle 就不用再去 library cache 里重新查找和解析，直接复用，从而减少硬解析、降低 latch 争用。

这两个参数一个防"打开太多"，一个防"反复解析"，方向完全不同。很多团队出问题就出在把它们当成一回事，要么只调OPEN_CURSORS不管缓存命中，要么盲目加大缓存却没解决游标泄漏。这篇内容我会把监控脚本、调优步骤、验证方法完整走一遍，所有 SQL 都能直接复制到 SQL*Plus 或 SQL Developer 里跑。

适合谁看：正在处理 ORA-01000 的 DBA、做 Oracle 后端开发需要排查连接池游标配置的工程师，以及想把数据库参数调优做成标准化流程的运维同学。下面从监控开始，一步步来。

2. 监控 Open Cursors 与 Session Cached Cursors 的完整脚本

调优的前提是先把现状看清楚。这里有个特别容易踩的坑：很多人以为v$open_cursor能看到当前打开的游标，其实不是。v$open_cursor展示的是每个会话的会话游标缓存（session cursor cache）里的游标，也就是那些已经关闭但被缓存起来的游标，它并不等于"当前正在打开的游标"。如果你想知道一个会话真正打开了多少游标，必须去查v$sesstat里名为opened cursors current的统计项。

先看按会话统计当前打开游标数的脚本：

-- 当前打开游标总数，按会话列出 select a.value, s.username, s.sid, s.serial# from v$sesstat a, v$statname b, v$session s where a.statistic# = b.statistic# and s.sid = a.sid and b.name = 'opened cursors current' order by a.value desc;

跑出来你会看到每个会话当前打开的游标数，按数量从高到低排。如果某个会话的值明显偏高，它就是重点怀疑对象。

如果是多台 Web 服务器组成的 N 层架构，按用户名和机器名聚合会更有价值，能快速定位是哪台应用服务器、哪个账号在制造游标压力：

-- 按用户名和机器名统计打开游标 select sum(a.value) total_cur, avg(a.value) avg_cur, max(a.value) max_cur, s.username, s.machine from v$sesstat a, v$statname b, v$session s where a.statistic# = b.statistic# and s.sid = a.sid and b.name = 'opened cursors current' group by s.username, s.machine order by 1 desc;

接下来判断OPEN_CURSORS设得够不够。核心思路是拿"历史峰值打开游标数"和"参数上限"做对比：

-- 对比历史峰值与参数上限 select max(a.value) as highest_open_cur, p.value as max_open_cur 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' group by p.value;

如果highest_open_cur已经逼近max_open_cur，说明参数该往上调了。反过来，如果峰值离上限还很远却仍然报 ORA-01000，那大概率是游标泄漏，而不是参数问题——这个区分很关键，后面排障章节会展开。

再看会话游标缓存的监控。先查每个会话当前缓存了多少游标：

-- 每个会话的会话游标缓存数量 select a.value, s.username, s.sid, s.serial# from v$sesstat a, v$statname b, v$session s where a.statistic# = b.statistic# and s.sid = a.sid and b.name = 'session cursor cache count';

想知道缓存里具体是哪些 SQL，可以关联v$open_cursor和v$sql，把 SQL 文本和 sql_id 一起拉出来：

-- 查看会话游标缓存中的具体 SQL select c.user_name, c.sid, sql.sql_text from v$open_cursor c, v$sql sql where c.sql_id = sql.sql_id and c.sid = &sid;

注意 9i 及更早版本没有sql_id，需要用c.address = sql.address关联，现在主流版本直接用sql_id即可。

最后是评估缓存命中效果的关键脚本。session cursor cache hits表示解析请求在会话缓存里命中的次数，把它和parse count (total)对比，就能算出命中率：

-- 会话游标缓存命中率 select cach.value cache_hits, prs.value all_parses, round((cach.value / prs.value) * 100, 2) as "pct_found_in_cache" from v$sesstat cach, v$sesstat prs, v$statname nm1, v$statname nm2 where cach.statistic# = nm1.statistic# and nm1.name = 'session cursor cache hits' and prs.statistic# = nm2.statistic# and nm2.name = 'parse count (total)' and cach.sid = &sid and prs.sid = cach.sid;

这套脚本组合起来，就能同时掌握"打开游标压力"和"缓存复用效率"两个维度。建议把峰值查询做成定时任务，每小时采一次样，积累几天数据后再决定怎么调参，比拍脑袋设值靠谱得多。

3. 参数调整：OPEN_CURSORS 与 SESSION_CACHED_CURSORS 怎么设

监控数据拿到手，接下来是动手调参。这两个参数都可以在线修改，不需要重启实例，这一点对生产环境很友好。

先看OPEN_CURSORS的调整。原则很简单：设得足够高，保证正常业务下永远不触发 ORA-01000。注意设高不代表每个会话都会用满，游标是按需打开的，参数只是一个上限护栏。修改命令：

-- 查看当前值 show parameter open_cursors; -- 在线调整为 1000（根据你的峰值数据决定） alter system set open_cursors = 1000 scope = both;

scope = both表示同时修改内存和 spfile，重启后依然生效。如果你只想临时改内存、不写 spfile，用scope = memory；只想改 spfile、下次重启生效，用scope = spfile。生产环境一般用both。

再看SESSION_CACHED_CURSORS。什么时候该调大？满足这几个条件时值得考虑：会话游标缓存数量已经接近上限、缓存命中率相对总解析次数偏低、应用确实在反复解析相同的查询。修改方式：

-- 查看当前值 show parameter session_cached_cursors; -- 在线调整 alter system set session_cached_cursors = 100 scope = both;

这里要特别提醒一个反直觉的点：如果应用本身没有反复提交相同 SQL 去解析，那么调大这个参数毫无意义。比如应用大量使用不可共享的 SQL（拼接字符串、字面量不绑定变量），缓存命中率天然就低，缓存数量也可能顶格，但加大缓存并不会带来任何性能提升。这种情况下该做的是推动开发改用绑定变量，而不是调参数。

为了把参数配置固化下来、方便版本管理和团队协作，我习惯把关键参数整理成一份配置清单。下面这份 JSON 可以直接作为参数基线存档，字段和 Oracle 实际参数名保持一致：

{ "oracle_cursor_tuning": { "open_cursors": 1000, "session_cached_cursors": 100, "scope": "both", "notes": "open_cursors 依据历史峰值 highest_open_cur 上浮 30% 设定；session_cached_cursors 在缓存命中率低于 20% 且缓存数量顶格时上调" } }

如果你用 Ansible 或 Shell 脚本批量管理多套库，也可以把参数写成 TOML 便于解析：

[oracle.cursor] open_cursors = 1000 session_cached_cursors = 100 scope = "both" [oracle.cursor.threshold] # 峰值超过上限 80% 时告警 peak_warn_ratio = 0.8 # 缓存命中率低于 20% 时考虑调大 session_cached_cursors cache_hit_warn_ratio = 0.2

调参不是一锤子买卖。改完之后要观察一段时间，确认峰值没有继续攀升、缓存命中率有改善，再决定是否继续微调。如果发现某个会话的opened cursors current总是稳步增长、一路追着OPEN_CURSORS上限跑，那基本可以判定是游标泄漏，参数调多大都没用，得回到应用代码去查。

在管理这些调优脚本、监控工具和凭证时，如果团队同时维护多套数据库和多个监控平台，凭证散落各处很容易乱。我一般会用 TaoToken 作为统一的 Key/API 通道来集中管理这类工具调用凭证，官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，需要接入时 API 地址是 https://taotoken.net/api 。这样监控脚本、告警机器人、自动化运维工具的凭证都走一个入口，轮换和审计都省事。

4. 验证调整效果：对比峰值与缓存命中率

参数改完不能就这么算了，必须用数据验证效果。验证分两条线：一条看打开游标峰值有没有被压住，另一条看会话缓存命中率有没有提升。

先做调整前的基线采样。在业务高峰期跑几次峰值查询，把结果记下来：

-- 基线采样：记录当前峰值 select max(a.value) as highest_open_cur, p.value as max_open_cur 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' group by p.value;

假设调整前你看到的是highest_open_cur = 1953、max_open_cur = 2500，峰值已经用掉了上限的 78%，确实偏紧。把open_cursors调到 3000 之后，隔一段时间再采样，理想情况下峰值占比会降到 60% 以下，留出足够的安全余量。

再看缓存命中率的前后对比。调整前先记录某个重点会话的命中率：

-- 调整前：会话 35 的缓存命中率 select cach.value cache_hits, prs.value all_parses, round((cach.value / prs.value) * 100, 2) as "pct_found_in_cache" from v$sesstat cach, v$sesstat prs, v$statname nm1, v$statname nm2 where cach.statistic# = nm1.statistic# and nm1.name = 'session cursor cache hits' and prs.statistic# = nm2.statistic# and nm2.name = 'parse count (total)' and cach.sid = 35 and prs.sid = cach.sid;

假设调整前是cache_hits = 34、all_parses = 700、命中率 4.57%，同时该会话的session cursor cache count是 49、上限 50，缓存已经顶格。这就是典型的"缓存不够用"信号。把session_cached_cursors从 50 调到 100 后，等业务跑一段时间再采样，命中率应该会有明显上升。

为了把前后对比做得更直观，我习惯用一张对照表记录：

验证时有个细节要注意：session cursor cache hits和parse count (total)都是累计统计值，从实例启动开始累加。所以对比时要么看调整后新增的增量，要么在调整前后各记录一次快照做差值。直接看累计值会被历史数据稀释，看不出真实变化。

另外，验证周期建议至少覆盖一个完整的业务高峰。有些应用的游标压力只在特定时段（比如批量任务、报表生成）才显现，采样时间太短会得出错误结论。如果调整后峰值占比依然很高，或者缓存命中率没改善，就要回到监控脚本重新分析，而不是继续盲目加参数。

5. 常见报错排查：ORA-01000、401 与缓存命中率异常

调优过程中会遇到几类典型问题，这里逐个拆解。

ORA-01000: maximum open cursors exceeded。这是最直接的报错。排查第一步是确认到底是参数太小还是游标泄漏。跑峰值对比脚本，如果highest_open_cur离max_open_cur还有很大距离却报错，那几乎可以确定是泄漏——某个会话打开了游标却不关闭。定位方法：

-- 找出打开游标数异常高的会话 select a.value, s.username, s.sid, s.serial#, s.program from v$sesstat a, v$statname b, v$session s where a.statistic# = b.statistic# and s.sid = a.sid and b.name = 'opened cursors current' and a.value > 100 order by a.value desc;

找到会话后，用v$open_cursor看它缓存了哪些 SQL，再结合应用代码排查是否有ResultSet、Statement没关闭的情况。Java 应用里最常见的就是连接池借出的连接没归还、或者try-with-resources没写对。

连接工具报 401 或 local proxy failed。这类错误通常出现在你用脚本或监控工具去调用数据库管理 API 时。401 表示凭证无效或过期，local proxy failed 表示本地代理配置有问题。排查顺序是：先确认 API Key 是否有效、有没有过期，再检查 Base URL 是否写对。如果你用 TaoToken 统一管理凭证，接入时三件套要配全——Base URL 填https://taotoken.net/api，Key 用控制台生成的密钥，Model ID 按实际调用的模型填。缺任何一项都会导致鉴权失败。凭证可以在 https://taotoken.net/api-keys 生成和管理。

reading choices 报错。这个错误一般出现在调用模型接口返回结构解析时，说明返回体格式和预期不符。常见原因是请求参数不完整或模型 ID 写错，导致服务端返回了错误结构。检查请求体里的 model 字段和实际可用模型是否一致，必要时到模型对话页面 https://taotoken.net/chat 手动验证一次请求，确认参数正确后再写进脚本。

OAuth 相关报错。如果你用 Claude Code 之类的工具接入，遇到 OAuth 报错通常是授权流程没走完或 token 失效。重新走一遍授权，确认回调地址配置正确。长期做编码和 Agent 任务的团队，可以考虑用 Coding Plan 来统一管理这类工具的额度与凭证，入口在 https://taotoken.net/coding-plan 。

缓存命中率始终很低。前面提过，如果应用大量使用不可共享 SQL，命中率天然就低，调参数没用。判断方法：查v$sql里相同逻辑的 SQL 是否有大量不同sql_id（说明字面量没绑定变量）。如果是，推动开发改用绑定变量才是正解。另外，如果session cursor cache count长期顶格但命中率低，也要先确认应用是否真的在重复解析相同查询，而不是无脑加大参数。

排查这类问题的通用思路是：先用监控脚本定位现象，再区分是参数问题、配置问题还是应用代码问题，最后针对性处理。把每次排查的结论记下来，慢慢就能形成自己团队的排查手册。

6. 把游标调优接入统一凭证管理

游标调优本身是数据库层面的工作，但围绕它的监控、告警、自动化脚本往往涉及多个工具和平台。当团队规模上来之后，凭证管理会变成一个隐形成本：监控脚本一套 Key、告警机器人一套 Key、自动化运维工具又一套 Key，散落在各个配置文件里，轮换时容易漏、审计时说不清。

我的做法是把这类工具调用凭证收敛到一个统一通道。TaoToken 提供统一的 Key/API 入口，监控脚本、告警服务、自动化任务都通过它来鉴权，凭证集中生成、集中轮换。接入文档在 https://taotoken.net/doc ，里面有各语言和各工具的接入示例，照着配就行。

具体到游标调优这个场景，你可以把前面那些监控 SQL 封装成定时任务，任务执行完把峰值和命中率推送到告警平台。告警平台的凭证、数据库连接凭证、推送服务的凭证，都可以走统一通道管理。这样一套流程下来，参数基线、监控脚本、凭证配置三者都能版本化，团队协作时不会因为某个人本地配置不同而出现"我这能跑你那报错"的情况。

回到游标本身，最后再强调一个实践要点：调参之前先积累至少一周的监控数据。Oracle 的游标行为和应用负载强相关，工作日和周末、白天和夜间可能完全不同。拿一周的峰值分布去定OPEN_CURSORS，比看某一时刻的瞬时值靠谱得多。SESSION_CACHED_CURSORS同理，命中率要在完整业务周期里观察才有意义。

如果你还在处理 ORA-01000，建议按这个顺序走一遍：先用v$sesstat确认当前打开游标峰值，用v$open_cursor看缓存内容，用命中率脚本判断缓存是否够用，然后决定是调OPEN_CURSORS还是SESSION_CACHED_CURSORS，改完再采样验证。每一步都有对应的脚本，照着跑就行。真正难的不是调参数，而是判断该调哪个、以及什么时候该停下来去查应用代码。