最初由 ZALBB 发布
[B]环境:
查看v$open_cursor,发现该SESSION 确实有 800 至多。
alter system flush shared_pool 之后,也连接不上,最后只能重新启动 IIS。
但通过观察得知,平时里其实很多SQL语句都在发布后不久,
就被清除出共享池(v$open_cursor里一开始有,之后不久就不看到)
现想知道:在什么情况下,数据库会释放 CURSOR,如何解决该问题。 [/B]
您的.net 程序对cursor 处理的有问题,open 的要close .(当然,这对ZALBB 来说可能是废话)
如果没close ,里面有个循环的话,很快就ORA-01000 了
alter system flush shared_pool不能解决cursor 泄漏问题的,因为该Session打开的Cursor 可能在 UGA/PGA 里 there is a shared SQL area in the SGA, an instantiation in the PGA, and a statement handle in the client environment. Each of these is called a "cursor" in various contexts. Your close call is closing one of the statement handles in your client environment (PL/SQL) but the corresponding instantiation in the PGA remains cached, which is what statistic# 3 is counting. If you were to set close_cached_open_cursors = TRUE and commit after the close call
BTW:ZALBB你老兄的问题总是值得看