首页 Cursor正文

新手必看，搞懂Oracle的Cursor计数，从懵圈到明白

ChatGPT2026-04-28 10:22:0841

温馨提示：在 ChatGPT 官网（www.chatgpt.com）使用 GPT-5.5、ChatGPT-Image-2 等模型时，需要 ChatGPT Plus 或更高等级的会员权限。如需购买账号或充值会员，请扫码添加我们客服咨询。

Oracle中的Cursor（游标）分为**隐式游标**和**显式游标**，其计数规则是初学者最易混淆的点。**隐式游标**由Oracle自动管理，执行DML（INSERT/UPDATE/DELETE）或SELECT INTO后，可通过 SQL%ROWCOUNT 获取受影响的行数，若SQL未执行，SQL%ROWCOUNT 返回0；当查询无结果时，SELECT INTO 会报 NO_DATA_FOUND 异常，需用异常块处理。**显式游标**需手动声明、打开、获取并关闭，其%ROWCOUNT属性记录的是当前已从结果集中**提取（FETCH）**的行数，而不是总行数，若循环中FETCH了10次（即使结果集有100行），%ROWCOUNT也仅显示10，应避免在游标循环中依赖%ROWCOUNT作为终止条件，正确做法是判断%NOTFOUND或%FOUND，重点：**隐式游标反映DML影响行；显式游标反映已FETCH的行，非全量。**

本文目录导读：

  1. 第一步：你的游标上限是多少？
  2. 第二步：找出“偷游标”的程序
  3. 第三步：看看到底是哪些语句没关
  4. 小白最容易犯的错误（也是主要原因）
  5. 如何预防和处理？
  6. 真遇到了“ORA-01000”怎么办？
  7. 关于AI工具和深入学习的建议

大家好，欢迎来到我们今天的教程，很多刚接触Oracle数据库的朋友，最常遇到的一个问题就是“游标（Cursor）”，特别是当系统报错，说“游标不够用”的时候，心里就更慌了，今天我们就来把这个事情说清楚，我会用最简单的话，告诉你什么是Oracle的游标计数，为什么它会满,以及我们普通人遇到这个问题该怎么做。

我们要知道一个事情，Oracle数据库就像一个很大的图书馆，你每次去图书馆查书，都得先跟管理员要一个“借书证”，这个借书证，就是一个游标，你在数据库里执行的每一条SQL语句，不管是查一条数据，还是更新一堆数据,都需要有一个游标去处理它。

图书馆的管理员（也就是数据库）不是万能的，一个图书馆里能借出去的借书证数量是有限的，这个有限的数量，就是Oracle的参数在控制，这个参数，叫做OPEN_CURSORS，它规定了你的数据库会话（也就是你登录数据库的那个连接）最多能同时打开多少个游标。

这个计数是怎么来的呢？很简单，当你执行一个SQL语句，数据库就给你分配一个游标，这个游标的“使用次数”或者说“打开次数”就加1，当你处理完数据，把游标关闭了，这个计数就减1，如果程序写得好，游标开一个关一个，计数就很稳定，但如果程序写得不小心，开了游标，忘了关，或者关得慢了，那这个计数就会一直涨，直到涨到上限OPEN_CURSORS的值，这时候，新的SQL语句想要执行，就发现借书证都发完了，数据库就会报错：“ORA-01000：超出最大打开游标数”。

这个错误对新手来说特别头疼，因为你根本不知道哪个程序“偷”走了这么多游标，别急,我们一步步来解决。

第一步：你的游标上限是多少？

你要知道你所在的环境，到底能开多少个游标，这就像你知道图书馆最多能借出多少本书一样，查询这个数值很简单，用你的数据库管理工具（比如PL/SQL Developer，SQL Developer，或者命令行）,运行下面这条SQL语句：

SELECT name, value FROM v$parameter WHERE name = 'open_cursors';

正常情况下，出来的结果是这样的：name是open_cursors，value可能是一个数字，比如300，800，或者1000，这个数字就是系统允许最大值，先记住这个数字，如果你的报错是因为游标用完了，那这个数字通常在你的环境里是够用的（比如300或以上），问题不在于这个数字太小,而在于你的程序没有及时归还游标。

第二步：找出“偷游标”的程序

我们要找到是哪些SQL语句一直占用着游标不放，这有点像查违章，Oracle数据库里有两个很重要的视图，叫v$session（当前在线的会话）和v$open_cursor（当前打开的游标）。

我们先把“游标占用最高”的会话找出来,运行这句SQL：

SELECT ss.sid, ss.serial#, ss.username, ss.program, COUNT(*) AS cursor_count
FROM v$session ss
JOIN v$open_cursor oc ON ss.sid = oc.sid
GROUP BY ss.sid, ss.serial#, ss.username, ss.program
ORDER BY cursor_count DESC;

这个查询会列出所有连接的用户（比如你的网站程序、你的报表工具），以及它们各自打开了多少个游标，你看到结果后，重点关注那个cursor_count数字特别大的行，别人都是几十个，有一个程序显示有500个,那问题很可能就是它引起的。

第三步：看看到底是哪些语句没关

找到了这个“嫌疑程序”的会话ID（SID）后，我们接下来要精确地看看，它到底执行了什么SQL语句，运行以下SQL，把&sid替换成你刚才找到的那个SID数字。

SELECT sql_id, sql_text, count(*)
FROM v$open_cursor
WHERE sid = &sid
GROUP BY sql_id, sql_text
ORDER BY count(*) DESC;

这个查询结果会列出这个会话里，重复打开次数最多的那些SQL语句，通常你会发现，有些简单的SELECT语句，或者一些INSERT、UPDATE语句，被打开了成百上千次，但是都没有关闭,这就找到了元凶。

小白最容易犯的错误（也是主要原因）

根据我接触的案例，导致游标计数爆炸的原因，大部分都是下面这几种情况,你可以对号入座看看自己有没有：

  1. 在循环里直接拼SQL：很多新手喜欢在PL/SQL块里，比如FOR循环中，每次循环都直接写一句execute immediate 'select * from your_table where id = ' || i;，这样每循环一次，数据库就开一个新游标，如果循环10000次，而你的OPEN_CURSORS只有500，那跑到第501次的时候，程序就挂了，正确的做法是，在循环外面先定义游标，在循环里用变量绑定，或者使用批量处理（BULK COLLECT）。

  2. 在Java（或Python/C#）程序里，没有在finally里关闭：如果你是用编程语言连数据库，最常见的坑就是忘记关闭ResultSet、Statement或者Connection，比如Java代码里，你用了Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(“...”); 然后你只读了数据，但忘记在finally代码块里写rs.close(); stmt.close();，这种情况，就算你在代码里只执行了一次SQL，但是因为没关闭，这个游标在数据库端就一直被当成“打开”的状态，如果这个代码是频繁调用的,游标计数就会越积越多。

  3. 连接池配置问题：现在很多应用都用了数据库连接池（比如HiKariCP， DBCP， c3p0），连接池的本意是复用连接，提高性能，如果你的连接池配置不对，比如允许的“最大活跃连接数”太大，或者有连接泄露，那么你的应用看起来是正常的，实际上每个连接都在默默地开着几个游标，这就像虽然每个连接只开10个游标，但如果有100个这样的连接，总数就变成1000个了,照样会超。

如何预防和处理？

预防比处理简单得多，记住下面这几点，基本可以避免99%的问题：

  • 用完就关，无论是在数据库里写的PL/SQL，还是在代码里，养成习惯：你在哪里打开游标，就要在附近把它关闭，在PL/SQL里，显式游标要用CLOSE cursor_name;，在Java里，一定要在try块结束后，在finally块里关闭所有数据库资源。

  • 用绑定变量，前面说过，不要用字符串拼接SQL，用绑定变量（:1, :2, 或者?），这样数据库可以重用同一个游标，不用每次都新开,这是从源头减少游标个数的最好办法。

  • 限制查询范围，不要写SELECT * FROM huge_table;这种没加WHERE条件的查询，这种查询会打开一个很大的游标，长时间占用资源，如果你的程序需要全表扫描，考虑用分批的方式,或者用存储过程来处理。

  • 查看监控，如果你的数据库有第三方监控（比如Oracle Enterprise Manager，或开源的Nagios，Zabbix），关注“游标数”这个指标，设置一个预警值，比如当某个会话的游标数超过200时就报警,这样你可以在变成致命错误之前就发现并处理。

真遇到了“ORA-01000”怎么办？

如果你现在已经遇到了这个报错，别慌,这是救命操作。

  1. 立即联系DBA（数据库管理员）：这是最安全的方法，他们有权限调整参数OPEN_CURSORS，或者杀掉有问题的会话，不要自己乱改参数,除非你非常清楚你的应用和服务器的负载。

  2. 如果你有管理员权限，并且只是临时抢救：

    • 先通过前面的方法找到占用最多的那个会话SID。
    • 使用ALTER SYSTEM KILL SESSION 'sid,serial#';命令杀掉这个会话，注意，sid和serial#是在第一步查询时获取的，这会强制中断那个程序占用的所有游标，这只是治标,让系统先恢复运行。
    • 之后，分析那个被杀掉的程序，找到它游标泄露的真正原因,并修复代码。

  3. 最后的办法：重启应用：在某些极端情况下，如果杀不掉特定会话，或者问题出在整个连接池上，重启你的应用服务器（Tomcat，Weblogic，或者你的Java程序）也可以释放所有连接，自然就把所有游标都释放了，但这会导致业务中断,是下下策。

关于AI工具和深入学习的建议

说到处理数据库问题，很多人觉得枯燥，现在有一些AI工具，比如ChatGPT、Claude，或者Cursor这样的AI编程助手，其实能帮上大忙，你可以把上面我们查出来的那个占用游标最多的SQL语句，直接复制到ChatGPT里，问它：“这段SQL为什么会导致游标泄露？我应该怎么优化它？”它能给你非常具体的分析,甚至帮你重写代码。

你还可以利用这些AI工具做“模拟面试”，比如你问：“一个Java程序在for循环里执行SQL，为什么会导致ORA-01000错误？请用简单的话解释。”它很快就能帮你理清逻辑。

如果你想系统学习Oracle的性能优化，或者想了解怎么用AI工具来帮你写更安全的数据库代码，可以看看我们网站上的其他教程，我们不仅讲理论,更注重实际落地方案。

Oracle的游标计数，说白了就是一个资源管理问题，它就像你手里的办公用品，用完了就得还回去，不还，就会不够用，对于小白来说，只要记住“打开就一定要关闭”这个原则，在写代码时多用绑定变量、少用循环内拼接SQL，基本就能规避掉99%的游标溢出问题。

如果你的环境里已经出现了频繁的游标报警，不要自己瞎改配置，先从我们讲的方法入手，定位到具体的会话和SQL语句，分析清楚是程序逻辑问题，还是连接池问题，再结合AI工具来辅助分析,事情就没那么复杂了。

遇到任何数据库疑难杂症，或者想获取最新的AI工具使用技巧，别忘了扫描页底的二维码,我们随时在你身边。

温馨提示：在 ChatGPT 官网（www.chatgpt.com）使用 GPT-5.5、ChatGPT-Image-2 等模型时，需要 ChatGPT Plus 或更高等级的会员权限。如需购买账号或充值会员，请扫码添加我们客服咨询。

本文链接：https://www.lexitong.com/ai/562.html

隐式游标显式游标Oracle cursor计数

相关文章

网友评论