I was going to increase the max open cursors as a last resort, but I wanted to eliminate any other cause first.
I'm running this on a test database, where I am the only user.
Main Topics
Browse All TopicsThe attached code is part of a stored procedure, which is where I'm getting the eeror.
Max cursors is set at 1024 and I just can't see how I'm going anywhere near that.
thanks for your help.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
See if this thread is of any help.
http://asktom.oracle.com/p
R.
Below is the description of the OPEN_CURSORS parameter from the Oracle documentation. It is a session level parameter, not a database level parameter. You must be exceeding 1024 cursors in your session, not database wide.
Also, it may not be just one query that is causing the problem. That is where the problem manifests itself. Quite commonly I have seen processes explicitly open cursors and not close them assuming the database will do it when the process diconnects. A bad practice, but some people do it.
side note:
* replace UNION by UNION ALL whenever possible (UNION performs a implicit DISTINCT ...)
* use JOIN / LEFT JOIN syntax instead of the "old" (+) method
* try to create a (materialized) view on the (remote) server, running/returning some data pre-worked, to reduce the network traffic between the 2
I did not see any function call in the sql, which might open a hidden cursor...
Your code also can do this.
Your program has to have EXCEPTION section and by error to close the opened cursors and release all resources. Possibly not onlythe code you paste, but also others units running under the same account.
To investigate
set trimspool on
set linesize 1000
break on report
comp sum of curs on report
select SUBSTR(User_Name,1,20) User_Name, SID, count(*) Curs from v$open_cursor group by User_Name,
SID order by User_Name, SID;
I have answered such question and this is the summary of my answers:
You have a JDBC application which runs for several hours. It then returns the following error:
ORA-1000 Maximum open cursors exceeded
The open_cursors parameter in init.ora is currently set to a number in excess of the maximum number of cursors you expect your application to have open at any one time. Increasing open_cursors extends the period of time before failure, but does not resolve the issue.
Solution Description
--------------------
Typically, in Java, when an object goes out of scope, it is automatically garbage collected, but the Java specification does not place any specific requirements on the JVM regarding when (or even if) this will occur for any
particular object. Therefore, do not rely on finalizers to close your cursors.
Explicity close all cursors ResultSet.close() and Statement.close() when you no longer need the cursor. This ensures that the corresponding server-side cursors are closed, preventing the ORA-1000 error.
You can query the SQL_TEXT column in V$OPEN_CURSOR view from the schema to determine which cursors are not being closed. For example:
select sql_text from v$open_cursor;
Reference
---------
"Oracle8i JDBC Developer's Guide and Reference", Chapter 3 'Basic Features',
Section 'First Steps in JDBC'
1. You should not use the finally block to reliably close cursors.
2. You should design your code to ensure that the resultSet/cursor and staements go out of scope after the close() method is invoked. This is necessary in order to execute garbage collection and reclaim the memory allocated for cursors
The problem arises often and appear to only have open cursors when using stored procedures and functions.
Try two stragies to resolve the problem:
1) Increase the value for open_cursors in our init.ora file from the default of 50 to 200
2) Have a thread running in our connectionpool class which looks for idle connections older than XX minutes, and then closes them and replaces them by new connections.
The effect of 2) should be to reduce the number of cursors open concurrently. By staggering the open and close we shouldn't put a significant overhead on Oracle or our web splication.
-----------
I think Connection.close() will close the resultset of the connection and will help to clear the memory as in the example below
public class JDBCLeak
{
static
{
new oracle.jdbc.driver.OracleD
}
public static void main(String args[])
{
while (true)
{
// replace url, uid, and pwd with valid data.
Connection dbConnection =
DriverManager.getConnectio
url, uid, pwd);
dbConnection.close();
System.gc();
}
}
}
The following code snippet is always a good coding pattern to follow when using Statement, PreparedStatement and ResultSet.
--------------
Connection conn = getConnection();
PreparedStatement ps = null;
ResultSet rs = null;
try {
ps = conn.prepareStatement(...)
rs = ps.execute...
}
catch (SQLException sqe) {
/* should I handle it? */
}
finally {
if (rs != null) try { rs.close(); } catch (SQLException) { /* should I handle it? */ }
if (ps != null) try { ps.close(); } catch (SQLException) { /* should I handle it? */ }
}
Thus, regardless of what happens, you will always correctly close the ResultSet and PreparedStatement. This of course only works if you don't need to pass the ResultSet back and can do all your work within the try {} block.
If you use Oracle 8.1.7:
Some colleagues solve this problem in 8.1.7 setting the init<sid>.ora parameter TIMED_STATICS = TRUE. Also try to use the latest version of 8.1.7 and patchset
Sincerely
Schwertner
I read somewhere that cursors are allocated 64 at a time up to OPEN_CURSORS, so I would set it to at least 64. There is no harm in setting a high value other than a little more memory being used for each session.
I confess I'm not exactly sure how cursors are allocated for remote connections, but based on your problem it obviously isn't done very effeciently!!! If it isn't too much trouble then you should increase the open_cursors init.ora parameter on the remote database as I don't think you'll be able to change this value at the session level as you don't have control over the remote session setting. Can't remember if this is a dynamic setting, so you may have to bounce the database for it to take effect.
seems your procedure has not Exception section.
You run and run and run the procedure and
it fails, fails , fails ...
As Milleniumaire mentioned there are cursors to remote DB, to local DB
and possibly the stay opened.
If you catch the error and gracefully close the procedure I hope
the cursors will be closed.
Business Accounts
Answer for Membership
by: angelIIIPosted on 2008-06-13 at 08:14:50ID: 21779828
the problem is eventually not your code (alone), but all the users/applications using (ie opening) cursors with not closing them...
this is one of the "problematic" situations where your code might not be the culprit, but for example some legacy application.
you might try to increase the setting to allow more open cursors, but if there is a leak in some legacy application, only correcting the actual source of the problem will help ultimately.