ORACLE服务端CACHING CURSOR的功能，我们称为软关闭，即使你隐式关闭游标、或者close cursor也不会真正硬关闭这个游标，以便下次执行相同语句时，不需要重复打开。
对于临时游标，下次调用不同语句时就被硬关闭，但是对于存储对象中的游标（SQL），那么通常只有在OPEN CURSOR满才会去硬关闭。
这里的OPEN CURSOR满是什么意思？怎么才算满？ show parameter open_cursor，达到这个数就算满了。
下面这个SQL可以看出所有会话当前打开游标的数量：
select sid,value from v$sesstat a , v$statname b where a.statistic# = b.statistic# and name='opened cursors current' order by 2;
在一般人的眼里，游标使用后就关闭了，打开的游标的数量应该不会太多,实际上，大部分人对打开游标的概念一直存在误解，认为只有正在获取的游标是打开状态，而一旦获取结束，关闭游标后，游标就处于关闭状态了，因此一个会话中打开状态的游标数量应该很少。
现在我们都知道事实不是这样的，某些游标在程序中已经关闭了，但是oracle为了提高游标的性能，会对其进行缓冲(cache)，这些缓冲的游标在程序中的关闭只是一种软关闭，事实上在会话中并未关闭，而是存放在一个游标缓冲区中。
1）在9.2.0.5之前，open_cursors参数的作用是双重的，一方面是限制一个会话打开游标的总量，另外一方面，该参数也作为PL/SQL cursor的缓冲。
在PL/SQL中，如果某个游标关闭了，它不会马上硬关闭，而是首先保存在游标缓冲中。
如果这个会话打开的游标数量还没有达到open_cursors参数的值，那么就可以先保持打开状态。
如果当前打开的游标数量已经达到open_cursors参数的值，那么会首先关闭一个被缓冲的、实际当时并未打开的游标。
如果缓冲中的所有游标都是实际打开的，那么就会报ORA-1000错误：ORA-1000:maximum open cursors exceeded.
2）当然，在9.2.0.5之后，open_cursors参数不再承担PL/SQL的缓冲工作，PL/SQL中的SQL也可以使用session_cached_cursors的会话缓冲了。
这个参数就成了一个纯碎的限制。
但是，设置一个较大的open_cursors参数，可以避免出现ORA-1000错误，同时也可以让会话缓冲更多的游标，改善SQL解析的性能。
不过将这个参数设置得很大的话，会占用较多的PGA空间，消耗一定的物理内存。一般的OLTP系统中，800--3000就足够了,很少有超过3000的设置.
不过具体还是要看你的应用 为什么当前有这么多打开的游标数量。
增大游标的值：alter system set open_cursors = 加大的值;