1. Java 应用连 Oracle 报 ORA-01000 到底卡在哪ORA-01000: maximum open cursors exceeded直译就是「打开的游标数超过上限」。它不是一个数据库崩了的信号而是 Oracle 在提醒你某个会话里同时打开的游标数量已经顶到了open_cursors参数设定的天花板。对 Java 应用来说这个报错几乎总是出现在连接池 JDBC 的组合里因为连接池会把物理连接长期复用游标一旦泄漏就会在同一个会话里越堆越多直到某次查询直接抛异常。先说清楚游标是什么。你可以把游标理解成 Oracle 为一条 SQL 语句准备的「执行上下文」解析结果、执行计划、绑定变量、结果集指针都挂在它上面。每次PreparedStatement执行、每个ResultSet打开背后都对应一个游标。正常用完会关闭并释放但如果代码里漏了close()或者连接池归还连接时没有清理会话状态游标就会一直挂在那个会话上。open_cursors默认常见值是 300一个高并发应用如果每个请求泄漏一两个游标几分钟就能把 300 撑满。这个报错适合谁看适合正在用 Spring Boot / MyBatis / 原生 JDBC 连 Oracle且已经看到ORA-01000堆栈的 Java 开发者也适合 DBA 想搞清楚到底是哪个会话、哪段代码在漏游标。排查思路是自顶向下先确认当前游标水位和参数值再定位到具体会话然后回到代码和连接池配置找泄漏点最后调整open_cursors并验证回收。下面按这个顺序一步步来命令和 SQL 都能直接复制。需要提前说明一点调大open_cursors只是缓解不是根治。如果代码在漏游标你把 300 调到 3000只是把报错时间往后推。真正的解法是「定位泄漏 合理配置 适度调参」三件事一起做。2. 排查前先用 TaoToken 把 SQL 和配置理清楚排查 ORA-01000 的过程里会反复写三类东西查游标水位的 SQL、连接池的 YAML/JSON 配置、以及各种报错日志的解读。这些内容如果每次都靠记忆拼很容易写错字段名。我习惯用一个模型对话入口来辅助把当前报错堆栈贴进去让它帮我列出「下一步该查哪张视图、哪个参数」再自己到数据库里验证。TaoToken 在这里的角色是一个统一的模型调用入口官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。它本身不碰你的数据库也不做任何数据中转只是帮你把「这段报错对应哪些排查动作」这类问题问清楚。比如你可以直接问v$sesstat和v$statname怎么关联才能查出每个会话的当前游标数它会给你一段可执行的 SQL 骨架你再拿去数据库跑。具体怎么用起来先到模型对话页面 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 试问几个排查问题确认回答质量然后到控制台 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建项目再到 API Keys 页面 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 生成密钥。如果你打算把「排查助手」做成一个长期跑的编码/Agent 工具可以看 Coding Plan https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 接入细节在文档 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。这里要强调TaoToken 是辅助你理解和生成排查脚本的工具数据库连接、游标查询、参数调整全部在你自己的 Oracle 环境里完成。它不会替你连库也不会读取你的业务数据。把「问清楚」和「动手查」分开排查效率会高很多。3. 可复制的 open_cursors 查询与连接池配置这一节是核心操作区。先查参数和水位再改参数最后配连接池。第一步确认当前open_cursors的值。用 SQL*Plus 或任意客户端执行show parameter open_cursors;输出里VALUE就是上限常见是 300。接着查「当前所有会话里单个会话打开游标的最大值」和上限做对比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说明确实顶到上限了。再往下钻找出是哪个会话在撑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 AND s.username IS NOT NULL ORDER BY a.value DESC;VALUE最大的那几行就是嫌疑会话。拿到SID和SERIAL#后可以进一步查它正在执行什么 SQLSELECT sql_text FROM v$open_cursor WHERE sid sid;这一步能直接看到该会话挂着哪些游标如果发现同一条 SQL 反复出现几十次基本可以确定是没关闭的PreparedStatement或ResultSet。确认要调参后用ALTER SYSTEM动态调整不需要重启实例ALTER SYSTEM SET open_cursors 1000 SCOPE BOTH;SCOPE BOTH表示同时改内存和 spfile重启后依然生效。改完再跑一次上面的水位查询确认MAX_OPEN_CUR变成 1000。接下来是连接池配置。以 HikariCP 为例Spring Boot 的application.yml里关键项如下spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 connection-test-query: SELECT 1 FROM DUAL这里没有直接控制游标的参数但maximum-pool-size决定了并发会话数间接影响游标总量。真正要关注的是「连接归还时是否清理会话状态」。Oracle JDBC 驱动提供了一个隐式语句缓存配置不当会缓存大量游标spring: datasource: url: jdbc:oracle:thin://host:1521/ORCLPDB1 hikari: >spring: datasource: druid: max-active: 20 remove-abandoned: true remove-abandoned-timeout: 300 pool-prepared-statements: falsepool-prepared-statements: false很关键Druid 开启 PSCache 后会在每个连接上缓存PreparedStatement高并发下极易触发 ORA-01000。关掉它让游标随用随关。4. 验证游标是否真的回收了改完参数和配置不能只看「不报错了」就完事要验证游标确实在回收。方法是在应用跑一轮压测或正常业务后观察会话游标数的变化趋势。先记录基线SELECT s.sid, s.serial#, a.value AS open_cursors 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 s.username YOUR_APP_USER ORDER BY a.value DESC;然后让应用执行一批查询再跑一次同样的 SQL。如果open_cursors在业务结束后回落到接近 0 或个位数说明回收正常如果持续上涨不下降说明还有泄漏点。更直观的办法是查「会话累计打开的游标数」和「当前打开数」的差值SELECT s.sid, s.serial#, SUM(CASE WHEN b.name opened cursors cumulative THEN a.value END) AS cumulative, SUM(CASE WHEN b.name opened cursors current THEN a.value END) AS current_open FROM v$sesstat a, v$statname b, v$session s WHERE a.statistic# b.statistic# AND s.sid a.sid AND s.username YOUR_APP_USER GROUP BY s.sid, s.serial#;cumulative一直涨是正常的业务在跑但current_open应该保持在一个稳定的小范围内波动。如果current_open单调递增就是泄漏。代码层面检查所有PreparedStatement和ResultSet是否在finally块里关闭或者用 try-with-resourcestry (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(SELECT * FROM orders WHERE id ?)) { ps.setLong(1, orderId); try (ResultSet rs ps.executeQuery()) { while (rs.next()) { // 处理结果 } } }try-with-resources 会自动关闭ResultSet和PreparedStatement这是最省心的写法。如果用的是 MyBatis检查SqlSession是否在finally里close()或者交给 Spring 的SqlSessionTemplate管理。5. 常见报错对照与排查清单排查过程中会遇到几个典型报错这里逐个对照。ORA-01000 本身maximum open cursors exceeded。含义是当前会话游标数超过open_cursors。处理顺序先查水位确认再定位会话再查v$open_cursor看具体 SQL最后改参数 修代码。ORA-00604 / ORA-01000 组合有时会先抛ORA-00604: error occurred at recursive SQL level再跟ORA-01000。这通常说明连递归 SQL比如触发器、审计都开不出游标了情况更紧急优先调大open_cursors争取时间同时立刻排查泄漏。401 Unauthorized如果你在用某个 API 网关或模型服务辅助排查遇到 401 一般是密钥没带对或过期。检查请求头里的Authorization: Bearer key确认 key 是从控制台生成的、没有多余空格。这跟数据库无关但排查时容易混淆。local proxy failed本地代理类工具报这个通常是本地端口没起来或配置指向了不存在的地址。检查本地服务是否监听、端口是否被占用。注意这类问题只影响你的辅助工具不影响 Oracle 连接。reading choices 报错调用模型接口时如果返回体里choices字段解析失败多半是返回了错误结构比如限流或参数错误。先打印原始响应体确认是业务错误还是格式问题再决定重试还是改参数。OAuth 相关报错如果辅助工具走 OAuth 授权token 过期会报invalid_grant或token expired。重新走一次授权流程即可跟数据库游标无关。排查清单可以记成一句话先看水位v$sesstat再看会话v$session再看 SQLv$open_cursor最后改参数ALTER SYSTEM和改代码try-with-resources 关 PSCache。6. 把排查流程固化成可复用的接入方式ORA-01000 的排查链路比较长每次从零开始查视图、拼 SQL 很费时间。我的做法是把常用查询和配置模板整理成一套「排查助手」用统一的模型入口来生成和校验这些脚本。这样下次再遇到直接问「给我一段查当前会话游标数的 SQL」几秒就能拿到可执行版本。如果你也想搭一套类似的辅助流程可以从模型对话开始试https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。确认好用后到控制台建项目 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 再到 API Keys 生成密钥 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。接入方式看文档 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 长期编码或 Agent 场景可以看 Coding Plan https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后留一个实操建议调完open_cursors和连接池后别急着关掉监控。连续观察 24 小时里current_open的峰值如果峰值稳定在open_cursors的 60% 以下说明配置合理如果还在往上爬说明泄漏点没找全回到第 3 节的v$open_cursor继续查。参数是缓冲代码才是根因。
ORA-01000: maximum open cursors exceeded 排查与 open_cursors 调优实战
1. Java 应用连 Oracle 报 ORA-01000 到底卡在哪ORA-01000: maximum open cursors exceeded直译就是「打开的游标数超过上限」。它不是一个数据库崩了的信号而是 Oracle 在提醒你某个会话里同时打开的游标数量已经顶到了open_cursors参数设定的天花板。对 Java 应用来说这个报错几乎总是出现在连接池 JDBC 的组合里因为连接池会把物理连接长期复用游标一旦泄漏就会在同一个会话里越堆越多直到某次查询直接抛异常。先说清楚游标是什么。你可以把游标理解成 Oracle 为一条 SQL 语句准备的「执行上下文」解析结果、执行计划、绑定变量、结果集指针都挂在它上面。每次PreparedStatement执行、每个ResultSet打开背后都对应一个游标。正常用完会关闭并释放但如果代码里漏了close()或者连接池归还连接时没有清理会话状态游标就会一直挂在那个会话上。open_cursors默认常见值是 300一个高并发应用如果每个请求泄漏一两个游标几分钟就能把 300 撑满。这个报错适合谁看适合正在用 Spring Boot / MyBatis / 原生 JDBC 连 Oracle且已经看到ORA-01000堆栈的 Java 开发者也适合 DBA 想搞清楚到底是哪个会话、哪段代码在漏游标。排查思路是自顶向下先确认当前游标水位和参数值再定位到具体会话然后回到代码和连接池配置找泄漏点最后调整open_cursors并验证回收。下面按这个顺序一步步来命令和 SQL 都能直接复制。需要提前说明一点调大open_cursors只是缓解不是根治。如果代码在漏游标你把 300 调到 3000只是把报错时间往后推。真正的解法是「定位泄漏 合理配置 适度调参」三件事一起做。2. 排查前先用 TaoToken 把 SQL 和配置理清楚排查 ORA-01000 的过程里会反复写三类东西查游标水位的 SQL、连接池的 YAML/JSON 配置、以及各种报错日志的解读。这些内容如果每次都靠记忆拼很容易写错字段名。我习惯用一个模型对话入口来辅助把当前报错堆栈贴进去让它帮我列出「下一步该查哪张视图、哪个参数」再自己到数据库里验证。TaoToken 在这里的角色是一个统一的模型调用入口官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。它本身不碰你的数据库也不做任何数据中转只是帮你把「这段报错对应哪些排查动作」这类问题问清楚。比如你可以直接问v$sesstat和v$statname怎么关联才能查出每个会话的当前游标数它会给你一段可执行的 SQL 骨架你再拿去数据库跑。具体怎么用起来先到模型对话页面 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 试问几个排查问题确认回答质量然后到控制台 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建项目再到 API Keys 页面 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 生成密钥。如果你打算把「排查助手」做成一个长期跑的编码/Agent 工具可以看 Coding Plan https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 接入细节在文档 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。这里要强调TaoToken 是辅助你理解和生成排查脚本的工具数据库连接、游标查询、参数调整全部在你自己的 Oracle 环境里完成。它不会替你连库也不会读取你的业务数据。把「问清楚」和「动手查」分开排查效率会高很多。3. 可复制的 open_cursors 查询与连接池配置这一节是核心操作区。先查参数和水位再改参数最后配连接池。第一步确认当前open_cursors的值。用 SQL*Plus 或任意客户端执行show parameter open_cursors;输出里VALUE就是上限常见是 300。接着查「当前所有会话里单个会话打开游标的最大值」和上限做对比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说明确实顶到上限了。再往下钻找出是哪个会话在撑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 AND s.username IS NOT NULL ORDER BY a.value DESC;VALUE最大的那几行就是嫌疑会话。拿到SID和SERIAL#后可以进一步查它正在执行什么 SQLSELECT sql_text FROM v$open_cursor WHERE sid sid;这一步能直接看到该会话挂着哪些游标如果发现同一条 SQL 反复出现几十次基本可以确定是没关闭的PreparedStatement或ResultSet。确认要调参后用ALTER SYSTEM动态调整不需要重启实例ALTER SYSTEM SET open_cursors 1000 SCOPE BOTH;SCOPE BOTH表示同时改内存和 spfile重启后依然生效。改完再跑一次上面的水位查询确认MAX_OPEN_CUR变成 1000。接下来是连接池配置。以 HikariCP 为例Spring Boot 的application.yml里关键项如下spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 connection-test-query: SELECT 1 FROM DUAL这里没有直接控制游标的参数但maximum-pool-size决定了并发会话数间接影响游标总量。真正要关注的是「连接归还时是否清理会话状态」。Oracle JDBC 驱动提供了一个隐式语句缓存配置不当会缓存大量游标spring: datasource: url: jdbc:oracle:thin://host:1521/ORCLPDB1 hikari: >spring: datasource: druid: max-active: 20 remove-abandoned: true remove-abandoned-timeout: 300 pool-prepared-statements: falsepool-prepared-statements: false很关键Druid 开启 PSCache 后会在每个连接上缓存PreparedStatement高并发下极易触发 ORA-01000。关掉它让游标随用随关。4. 验证游标是否真的回收了改完参数和配置不能只看「不报错了」就完事要验证游标确实在回收。方法是在应用跑一轮压测或正常业务后观察会话游标数的变化趋势。先记录基线SELECT s.sid, s.serial#, a.value AS open_cursors 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 s.username YOUR_APP_USER ORDER BY a.value DESC;然后让应用执行一批查询再跑一次同样的 SQL。如果open_cursors在业务结束后回落到接近 0 或个位数说明回收正常如果持续上涨不下降说明还有泄漏点。更直观的办法是查「会话累计打开的游标数」和「当前打开数」的差值SELECT s.sid, s.serial#, SUM(CASE WHEN b.name opened cursors cumulative THEN a.value END) AS cumulative, SUM(CASE WHEN b.name opened cursors current THEN a.value END) AS current_open FROM v$sesstat a, v$statname b, v$session s WHERE a.statistic# b.statistic# AND s.sid a.sid AND s.username YOUR_APP_USER GROUP BY s.sid, s.serial#;cumulative一直涨是正常的业务在跑但current_open应该保持在一个稳定的小范围内波动。如果current_open单调递增就是泄漏。代码层面检查所有PreparedStatement和ResultSet是否在finally块里关闭或者用 try-with-resourcestry (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(SELECT * FROM orders WHERE id ?)) { ps.setLong(1, orderId); try (ResultSet rs ps.executeQuery()) { while (rs.next()) { // 处理结果 } } }try-with-resources 会自动关闭ResultSet和PreparedStatement这是最省心的写法。如果用的是 MyBatis检查SqlSession是否在finally里close()或者交给 Spring 的SqlSessionTemplate管理。5. 常见报错对照与排查清单排查过程中会遇到几个典型报错这里逐个对照。ORA-01000 本身maximum open cursors exceeded。含义是当前会话游标数超过open_cursors。处理顺序先查水位确认再定位会话再查v$open_cursor看具体 SQL最后改参数 修代码。ORA-00604 / ORA-01000 组合有时会先抛ORA-00604: error occurred at recursive SQL level再跟ORA-01000。这通常说明连递归 SQL比如触发器、审计都开不出游标了情况更紧急优先调大open_cursors争取时间同时立刻排查泄漏。401 Unauthorized如果你在用某个 API 网关或模型服务辅助排查遇到 401 一般是密钥没带对或过期。检查请求头里的Authorization: Bearer key确认 key 是从控制台生成的、没有多余空格。这跟数据库无关但排查时容易混淆。local proxy failed本地代理类工具报这个通常是本地端口没起来或配置指向了不存在的地址。检查本地服务是否监听、端口是否被占用。注意这类问题只影响你的辅助工具不影响 Oracle 连接。reading choices 报错调用模型接口时如果返回体里choices字段解析失败多半是返回了错误结构比如限流或参数错误。先打印原始响应体确认是业务错误还是格式问题再决定重试还是改参数。OAuth 相关报错如果辅助工具走 OAuth 授权token 过期会报invalid_grant或token expired。重新走一次授权流程即可跟数据库游标无关。排查清单可以记成一句话先看水位v$sesstat再看会话v$session再看 SQLv$open_cursor最后改参数ALTER SYSTEM和改代码try-with-resources 关 PSCache。6. 把排查流程固化成可复用的接入方式ORA-01000 的排查链路比较长每次从零开始查视图、拼 SQL 很费时间。我的做法是把常用查询和配置模板整理成一套「排查助手」用统一的模型入口来生成和校验这些脚本。这样下次再遇到直接问「给我一段查当前会话游标数的 SQL」几秒就能拿到可执行版本。如果你也想搭一套类似的辅助流程可以从模型对话开始试https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。确认好用后到控制台建项目 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 再到 API Keys 生成密钥 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。接入方式看文档 https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 长期编码或 Agent 场景可以看 Coding Plan https://taotoken.net/api?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后留一个实操建议调完open_cursors和连接池后别急着关掉监控。连续观察 24 小时里current_open的峰值如果峰值稳定在open_cursors的 60% 以下说明配置合理如果还在往上爬说明泄漏点没找全回到第 3 节的v$open_cursor继续查。参数是缓冲代码才是根因。