Reg Open Cursor Concept

Friends,
Please kindly help me to analyse this dump.
In BI end routine select * query has been written to fetch values from active dso . They are using non primary key in the where condition.
More than 2 crore 20 million records were avaialble in that DSo for that condtion. While executing this query its going to dump.
If i move ahead with Open cursor set Hold will this query work fine and using open cursor set hold can i fetch 2 crore 20 million records.
In dump its shwoing to check the parameters : ztta/roll_area ,ztta/roll_extension and abap/heap_area_total . Even i checked those parametrs in RZ11. The curent val is sufficient.
Please kindly advice me for this dump and will open cursor set hold avoid the dump for 2 crore 20 million records.
Thanks
Edited by: Suhas Saha on Sep 29, 2011 1:06 PM

I am not completely convinced: the difference depends on the task which has to be done with the records of a package.
If the records are processed and the result must be written to the database into another table, then it will be necessary to COMMIT the changes, otherwise the 20.000.000 records will cause an overflow in the redo-logs of the database.
=> Only the OPEN CURSOR WITH HOLD will survive the DB-Commit.
The SELECT ... PACKAGE SIZE is simpler and can be used, if the result is further processed and reduced in size, which makes it possible to keep all data in memory (no intermediate DB-COMMITs are necessary) .
I would assume that case is the less frequent use case.
Siegfried

Similar Messages

Maximum open cursors

Hi,
I have an application running on NT station versus Oracle 8.0.5 database on NT server.
I'm getting the ORA-01000 error while running a report. This error doesn't appear regulary while running the concerned report. it appears after calling the report several times (closing then opening).
After the error appear everytime I call the report this error appear until the user restart the PC. I did check the report and I'm closing the cursors I opened.
I had the open_cursors parameter in the INIT file set for 400 then I changed to 600 but this didn't change a thing (I restarted my database).
I'm using recursive functions but I'm always closing the cursors before calling the function recursively.
And I also want to notes that the recursive function depending on the data I have won't go more than 2 or 3 levels deeper.
Please confirm it is bug 492362: NT/95/3.1.1 - REPORTS DOES NOT RELEASE OPENED CURSORS. and how to fix it.
THANKS

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Ali DHAINI ([email protected]):
Hi,
I have an application running on NT station versus Oracle 8.0.5 database on NT server.
I'm getting the ORA-01000 error while running a report. This error doesn't appear regulary while running the concerned report. it appears after calling the report several times (closing then opening).
After the error appear everytime I call the report this error appear until the user restart the PC. I did check the report and I'm closing the cursors I opened.
I had the open_cursors parameter in the INIT file set for 400 then I changed to 600 but this didn't change a thing (I restarted my database).
I'm using recursive functions but I'm always closing the cursors before calling the function recursively.
And I also want to notes that the recursive function depending on the data I have won't go more than 2 or 3 levels deeper.
Please confirm it is bug 492362: NT/95/3.1.1 - REPORTS DOES NOT RELEASE OPENED CURSORS. and how to fix it.
THANKS<HR></BLOCKQUOTE>
Hi, i have the same problem. Have you solve this problem? Can you tell me how to fix it?
Thank yoy
null

Confused about Open Cursors :(

Hi all,
i need some clarification on this issue, i've read throught the documentation and i'm a bit confused.
I'm using 10.1.0.2
select sum(value)
from v$statname sn,
v$sesstat st,
v$session s
where sn.statistic# = st.statistic#
and st.sid = s.sid
and sn.name = 'session cursor cache count'
The result of the above query is 4926, meaning i have 4926 CLOSED cursors in the session cursor cache.
select count(1)
from v$open_cursor
The result of the above query is 16968, meaning i have 16968 cached cursors
So there are two distinct cursor Caches ?
now lets look at other statistic
select sum(value)
from v$statname sn,
v$sesstat st,
v$session s
where sn.statistic# = st.statistic#
and st.sid = s.sid
and sn.name = 'opened cursors current'
this one gives me 12212 , so i have 12212 opened cursors (NOT CACHED , REALLY OPENED CURSORS ...is this correct???)
I suspect that my applications are not closing resultsets (java build application, deployed in oracle application server, database connections in pooled connection) ... so i'm trying to help my developers to find the potencial bug in application.
How can i get the SQL from OPEN cursors ???
V$open_cursor gives me SQL from CLOSED cached cursors ...
Best Regards
Rui Madaleno

Hi,
>>this one gives me 12212 , so i have 12212 opened cursors (NOT CACHED , REALLY OPENED CURSORS ...is this correct???)
For your instance, yes because you use the sum(value) aggregate function. But I think that the best is get this value per session.
select count(1) from v$open_cursor
v$open_cursor shows cached cursors, not currently open cursors, by session. If you're wondering how many cursors a session has open, don't look in v$open_cursor. It shows the cursors in the session cursor cache for each session, not cursors that are actually open. To monitor open cursors, query v$sesstat where name='opened cursors current'. This will give the number of currently opened cursors, by session:
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';
>>I suspect that my applications are not closing resultsets (java build application, deployed in oracle application server, database connections in pooled connection)
In this case, you need to monitor you application. If want, you can use the OEM Database Console and go to [Top Sessions | Session Details] link, or to use this SQL above.
By the way, do you are getting ORA-1000 errors ?
If so, set the OPEN_CURSORS parameter high enough that you never get an ORA-1000 during normal operations.
Cheers

Oracle and "Maximum open cursors exceeded"

Hi,
I am using Weblogic 7.0sp2 with Oracle 9.2.0. Since we are using manual JTA
transactions and the 9.2 drivers are buggy in that respect, we are using the
9.0.1 thin drivers delivered with weblogic.
The problem I have is that after a while, we get the now classic "Maximum open
cursors exceeded" error on connections from our connection pool (used through
a
TX datasource). I have of course checked all our JDBC code and it is fine. We
do not leave any statement/connection open. In fact, I am certain that the
problem is not caused by our applicative code.
The reason I am so positive is that the numbers of open (cached) cursors is
growing, even though there is no activity on our application (I mean no
activity at all). The number of cursors is regurlarly increasing by one
every 5 minutes until it reaches the maximum allowed for a session.
I have listed the statements corresponding to the opened cursors (they
do not belong to our code, as you might have guessed):
SELECT sysdate, user from dual
select longdbcs from javasnm$ where short = :1
select longname from javasnm$ where short = :1
As you can see, there are only three different statements. You can get
the statements from the system view v$open_cursor for a given session
but it will only give one row per different statement. If you want to know
the # of opened cursors in your cursor, use v$sesstat with statistic# = 3
(opened cursor current).
I suspect something is wrong in the connection testing done by weblogic
for the pool (I have activated test on reserved connections and test table
name is "dual") that leaves a resultset/statement behind. What is weird
though is that the refresh period is still 0 (not 5 minutes as you would
expect from the cursor growth rate...).
I would not say that it is an Oracle bug (as stated in some BEA FAQ I read)
since our application JDBC code does not exhibit the same problem. The
problem appeared with recent version of WebLogic for which the session
cursor cache is enabled, I suppose for performance reasons - this
is set by isssuing "ALTER SESSION SET SESSION_CACHED_CURSORS = ...".
Talking about this, does anybody know to which value WebLogic sets this
parameter when intializing the connection (this is neither
documented/configurable)?
Up to now, I have come up with possibly two workarounds, neither of which
is satisfying:
- resetting the pool from time to time
- issuing "ALTER SESSION SET SESSION_CACHED_CURSORS = 0" when I get a
connection from the pool. I have not tested this one personally (read
in a newsgroup that someone else did successfully) but it is supposed
to reset the cursor cache that is causing the trouble.
Any help will be greatly appreciated,
Regards,
Thierry.

Thierry Rouget wrote:
Hi,
I am using Weblogic 7.0sp2 with Oracle 9.2.0. Since we are using manual JTA
transactions and the 9.2 drivers are buggy in that respect, we are using the
9.0.1 thin drivers delivered with weblogic.
The problem I have is that after a while, we get the now classic "Maximum open
cursors exceeded" error on connections from our connection pool (used through
a
TX datasource). I have of course checked all our JDBC code and it is fine. We
do not leave any statement/connection open. In fact, I am certain that the
problem is not caused by our applicative code.
The reason I am so positive is that the numbers of open (cached) cursors is
growing, even though there is no activity on our application (I mean no
activity at all). The number of cursors is regurlarly increasing by one
every 5 minutes until it reaches the maximum allowed for a session.
I have listed the statements corresponding to the opened cursors (they
do not belong to our code, as you might have guessed):
SELECT sysdate, user from dual
select longdbcs from javasnm$ where short = :1
select longname from javasnm$ where short = :1
As you can see, there are only three different statements. You can get
the statements from the system view v$open_cursor for a given session
but it will only give one row per different statement. If you want to know
the # of opened cursors in your cursor, use v$sesstat with statistic# = 3
(opened cursor current).
I suspect something is wrong in the connection testing done by weblogic
for the pool (I have activated test on reserved connections and test table
name is "dual") that leaves a resultset/statement behind. What is weird
though is that the refresh period is still 0 (not 5 minutes as you would
expect from the cursor growth rate...).
I would not say that it is an Oracle bug (as stated in some BEA FAQ I read)
since our application JDBC code does not exhibit the same problem. The
problem appeared with recent version of WebLogic for which the session
cursor cache is enabled, I suppose for performance reasons - this
is set by isssuing "ALTER SESSION SET SESSION_CACHED_CURSORS = ...".
Talking about this, does anybody know to which value WebLogic sets this
parameter when intializing the connection (this is neither
documented/configurable)?
Up to now, I have come up with possibly two workarounds, neither of which
is satisfying:
- resetting the pool from time to time
- issuing "ALTER SESSION SET SESSION_CACHED_CURSORS = 0" when I get a
connection from the pool. I have not tested this one personally (read
in a newsgroup that someone else did successfully) but it is supposed
to reset the cursor cache that is causing the trouble.
Any help will be greatly appreciated,
Regards,
Thierry.Hi. We don't make those queries either. I suspect they are internal to the
oracle driver. One thing you can try is to set the size of the pool's
statement cache to zero. Oracle will retain cursors for every statement we
cache. The alternative is also to tell the DBMS to allow a given session
more cursors.
Joe

Open cursors problem- j2ee + oracle 10g

Hi,
I am using EJB on sunOne application server 8.1., Oracle 10g DB.
EJB container connects to Oracle DB through a set of connection pools.
BMP for all entity beans.
I have about 160 PL/SQL functions that make up the business logic of the online application. everytime the application runs, I get an increasing number of open cursors, including some of the ones that are explicitly closed within PL/SQL (inspection with sys.v_$open_cursor).
I made sure all CallableStatements, PreparedStatements, RecordSets within the beans are closed and set to NULL. All PL/SQL functions use explicit cursors, so every select statement is managed within a cursor which is explicitly closed when the function finishes with it.
From v$open_cursor, I identified the sessions with the cursors still open, and issued (ALTER SYSTEM KILL SESSION �sid, #serial�) for each of the sessions (this is done via a PL/SQL function for all inactive sessions).
These sessions have state INACTIVE, and wait_class IDLE. This has Killed all sessions, but I was not able to use the application anymore. I suspect by killing those sessions we have also caused the connections between EJB container and the Oracle DB. The only way to use the application now is to stop and restart the sunONE domain � this is very inconvenient.
Has anyone encountered a similar problem? any suggestions to reduce or eliminate the open cursors number? Please help.
Thank you all

Maybe you can try to have a smaller steady-pool-size and idle-timeout-in-millis for your connection pools.
Also, if that's at all possible, have smaller number of connection pools being shared by more apps.
Just my 2c.
thanks.

Open cursors are NOT closed only by closing the ResultSet or Statement

I've realised that the open cursors are only closed by closing the connection.
In my example code I have for-loop with a vector of table-names. For every table-name I start a query to retrieve metainformation (row-size, column-names). Although I close the ResultSet (which automatically closes the PreparedStatement/Statement) I reached after the 150th loop a max-cursor-exception (ora-01000) ?!
It seems that there is only the workaround to close and re-open the connection at the end of the for-loop. Which is performance-side pretty bad :-(.
Is there really no other solution?
Besides: does anyone know WHY the statement.close() also closes the ResultSet?? I think this is a bad design (hence to tight dependency between both classes). What if the garbage collector closes the statement (and hence to the JDOC the statement.close()-method also closes the ResultSet)? For example if a method uses a local Statement and returns a ResultSet (and the Statement-garbage is collected), then the ResultSet would cause an exception?!
Thanks for the help in advance
Tai

I've realised that the open cursors are only closed by
closing the connection.Or by closing the Statement!
In my example code I have for-loop with a vector of
table-names. For every table-name I start a query to
retrieve metainformation (row-size, column-names).
Although I close the ResultSet (which automatically
closes the PreparedStatement/Statement) I reached
after the 150th loop a max-cursor-exception
(ora-01000) ?!Closing the ResutSet does not automatically close the PreparedStatement/Statement.
>
It seems that there is only the workaround to close
and re-open the connection at the end of the for-loop.
Which is performance-side pretty bad :-(.
Is there really no other solution?
Just explicitly close the PreparedStatement/Statement!
Besides: does anyone know WHY the statement.close()
also closes the ResultSet?? You need to think of a resultset as a live connection to the database.
Consider SELECT * FROM ABIGTABLE, it would be inefficient to populate the Resultset with all of the rows (could even eat up all memory) so the first n rows are returned ( n = Statement.getFetchSize() ) and the next n rows are returned as needed.
I think this is a bad
design (hence to tight dependency between both
classes). What if the garbage collector closes the
statement (and hence to the JDOC the
statement.close()-method also closes the ResultSet)?
For example if a method uses a local Statement and
returns a ResultSet (and the Statement-garbage is
collected), then the ResultSet would cause an
exception?!You should use a statment and resultset, read all your data into a collection or a CachedRowSet (http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html) then close the statment as soon as possible. Never return a resultset form your data tier: that is tight coupling between the tiers of your application!

Open cursors and shared cached cursors

Hi
In addm report i found below recommendation, before any change in parameter i want to know about those parameters, is there any thumb rule for this parameters,
is there any drawback if i increase those parameters.
FINDING 7: 2.1% impact (10693 seconds)
Soft parsing of SQL statements was consuming significant database time.
RECOMMENDATION 1: Application Analysis, 2.1% benefit (10693 seconds)
ACTION: Investigate application logic to keep open the frequently used
cursors. Note that cursors are closed by both cursor close calls
and
session disconnects.
RECOMMENDATION 2: DB Configuration, 2.1% benefit (10693 seconds)
ACTION: Consider increasing the maximum number of open cursors a
session
can have by increasing the value of parameter "open_cursors".
ACTION: Consider increasing the session cursor cache size by
increasing
the value of parameter "session_cached_cursors".
RATIONALE: The value of parameter "open_cursors" was "300" during the
analysis period.
RATIONALE: The value of parameter "session_cached_cursors" was "20"
during the analysis period.
Thanks and Regards
Jafar

Jaffy
Your system suffers from soft parsing (according to ADDM), therefore:
- Increasing the value of open_cursors has no impact on soft parsing (only up to 9.2.0.4 open_cursors had a direct impact on that for PL/SQL programs).
- Increasing the value of session_cached_cursors might help reducing soft parsing. If it helps or not is really dependent from the application.
ADDM is probably advising to increase open_cursors as well, because the database engine will keep cursors open even if the application closes them.
HTH
Chris
PS: cursor_sharing might be helpful to reduce hard parses. It has no impact on soft parses... So, forget the hint about it.

Opening two cursors using open cursor with bulk collect on colections ..

Is it possible to have the implementatiion of using bulk collect with collections using two open cursors ..
first c1
second c2
open c1
loop
open c2
loop
end loop
close c2
end loop;
close c1
what i found is for every outer loop of cursor c1 , cursor c2 is open and closed for every record.
is this willl imporove the performace .?
EXAMPLE:-
NOTE: The relatoin between finc and minc is one to many ..finc is parent and minc is child
function chk_notnull_blank ( colname IN number ) return number is
BEGIN
if ( colname is NOT NULL and colname not in ( -8E14, -7E14, -6E14, -5E14, -4E14, -3E14, -2E14, -1E14, -1E9 )) then
RETURN colname ;
else
RETURN 0;
end if;
END chk_notnull_blank;
procedure Proc_AnnualFmlyTotIncSummary is
CURSOR c_cur_finc IS SELECT FAMID FROM FINC ;
CURSOR c_cur_minc IS SELECT FAMID, MEMBNO , ANFEDTX, ANGOVRTX, ANPRVPNX, ANRRDEDX, ANSLTX, SALARYX, SALARYBX, NONFARMX, NONFRMBX , FARMINCX, FRMINCBX, RRRETIRX, RRRETRBX, SOCRRX, INDRETX, JSSDEDX, SSIX, SSIBX from MINC minc WHERE FAMID IN ( SELECT FAMID FROM FINC finc WHERE minc.FAMID = finc.FAMID );
v_tot_fsalaryx number := 0;
v_tot_fnonfrmx number := 0;
v_tot_ffrmincx number := 0;
v_tot_frretirx number := 0;
v_tot_findretx number := 0;
v_tot_fjssdedx number := 0;
v_tot_fssix number := 0;
v_temp_sum_fsalaryx number := 0;
v_temp_sum_fnonfrmx number := 0;
v_temp_sum_ffrmincx number := 0;
v_temp_sum_frretirx number := 0;
v_temp_sum_findretx number := 0;
v_temp_sum_fjssdedx number := 0;
v_temp_sum_fssix number := 0;
TYPE minc_rec IS RECORD (FAMID MINC.FAMID%TYPE, MEMBNO MINC.MEMBNO%TYPE , ANFEDTX MINC.ANFEDTX%TYPE, ANGOVRTX MINC.ANGOVRTX%TYPE , ANPRVPNX MINC.ANPRVPNX%TYPE , ANRRDEDX MINC.ANRRDEDX%TYPE , ANSLTX MINC.ANSLTX%TYPE, SALARYX MINC.SALARYX%TYPE , SALARYBX MINC.SALARYBX%TYPE , NONFARMX MINC.NONFARMX%TYPE , NONFRMBX MINC.NONFRMBX%TYPE, FARMINCX MINC.FARMINCX%TYPE , FRMINCBX MINC.FRMINCBX%TYPE , RRRETIRX MINC.RRRETIRX%TYPE , RRRETRBX MINC.RRRETRBX%TYPE, SOCRRX MINC.SOCRRX%TYPE , INDRETX MINC.INDRETX%TYPE , JSSDEDX MINC.JSSDEDX%TYPE , SSIX MINC.SSIX%TYPE , SSIBX MINC.SSIBX%TYPE );
v_flag_boolean boolean := false;
v_famid number ;
v_stmt varchar2(3200) ;
v_limit number := 50;
v_temp_FAMTFEDX number := 0 ;
v_temp_FGOVRETX number := 0 ;
v_temp_FPRIVPENX number := 0 ;
v_temp_FRRDEDX number := 0 ;
v_temp_FSLTAXX number := 0 ;
v_temp_FSALARYX number := 0 ;
v_temp_FNONFRMX number := 0 ;
v_temp_FFRMINCX number := 0 ;
v_temp_FRRETIRX number := 0 ;
v_temp_FINDRETX number := 0 ;
v_temp_FJSSDEDX number := 0 ;
v_temp_FSSIX number := 0 ;
BEGIN
OPEN c_cur_finc ;
LOOP
     FETCH c_cur_finc BULK COLLECT INTO famid_type_tbl LIMIT v_limit;
     EXIT WHEN famid_type_tbl.COUNT = 0;
     FOR i in famid_type_tbl.FIRST..famid_type_tbl.LAST
     LOOP
     OPEN c_cur_minc ;
     LOOP
     FETCH c_cur_minc BULK COLLECT INTO minc_rec_type_tbl LIMIT v_limit;
     EXIT WHEN minc_rec_type_tbl.COUNT = 0;
          FOR j IN minc_rec_type_tbl.FIRST..minc_rec_type_tbl.LAST
          LOOP
          if ( famid_type_tbl(i) = minc_rec_type_tbl(j).FAMID ) THEN
          v_temp_FAMTFEDX := v_temp_FAMTFEDX + chk_notnull_blank(minc_rec_type_tbl(j).ANFEDTX );
          v_temp_FGOVRETX := v_temp_FGOVRETX + chk_notnull_blank(minc_rec_type_tbl(j).ANGOVRTX);
          v_temp_FPRIPENX := v_temp_FPRIPENX + chk_notnull_blank(minc_rec_type_tbl(j).ANPRVPNX);
          v_temp_FRRDEDX := v_temp_FRRDEDX + chk_notnull_blank(minc_rec_type_tbl(j).ANRRDEDX);
          v_temp_FSLTAXX := v_temp_FSLTAXX + chk_notnull_blank(minc_rec_type_tbl(j).ANSLTX );
          v_temp_FSALARYX := v_temp_FSALARYX + chk_notnull_blank(minc_rec_type_tbl(j).SALARYX ) + chk_notnull_blank(minc_rec_type_tbl(j).SALARYBX);
          v_temp_FNONFRMX := v_temp_FNONFRMX + chk_notnull_blank(minc_rec_type_tbl(j).NONFARMX) + chk_notnull_blank(minc_rec_type_tbl(j).NONFRMBX);
          v_temp_FFRMINCX := v_temp_FFRMINCX + chk_notnull_blank(minc_rec_type_tbl(j).FARMINCX) + chk_notnull_blank(minc_rec_type_tbl(j).FRMINCBX );
          v_temp_FRRETIRX := v_temp_FRRETIRX + chk_notnull_blank(minc_rec_type_tbl(j).RRRETIRX) + chk_notnull_blank(minc_rec_type_tbl(j).RRRETRBX ) + chk_notnull_blank(minc_rec_type_tbl(j).SOCRRX);
          v_temp_FINDREXT := v_temp_FINDRETX + chk_notnull_blank(minc_rec_type_tbl(j).INDRETX);
          v_temp_FJSSDEDX := v_temp_FJSSDEDX + chk_notnull_blank(minc_rec_type_tbl(j).JSSDEDX);
          v_temp_FSSIX := v_temp_FSSIX + chk_notnull_blank(minc_rec_type_tbl(j).SSIX ) + chk_notnull_blank(minc_rec_type_tbl(j).SSIBX);
          END IF;
          END LOOP;
     END LOOP ;
     CLOSE c_cur_minc;
     UPDATE FINC SET FAMTFEDX = v_temp_FAMTFEDX WHERE FAMID = famid_type_tbl(i);
     END LOOP;
END LOOP;
CLOSE c_cur_finc;
END;
EXCEPTION
WHEN OTHERS THEN
raise_application_error(-20001,'An error was encountered - '||SQLCODE||' -ERROR- '||SQLERRM);
v_err_code := SQLCODE;
v_err_msg := substr(SQLERRM, 1, 200);
INSERT INTO audit_table (error_number, error_message) VALUES (v_err_code, v_err_msg);
error_logging(p_error_code => substr(sqlerrm,1,9), p_error_message => substr(sqlerrm,12), p_package =>'PKG_FCI_APP',p_procedure => 'Proc_Annual_Deductions_FromPay ' , p_location => v_location);
end Proc_AnnualFmlyTotIncSummary ;
Is the proga efficient and free from compilation errors ..?
thanks/kumar
Edited by: kumar73 on Sep 22, 2010 12:48 PM

function chk_notnull_blank ( colname IN number ) return number is Maybe this function should have its own forum:
how to use case in this program
Re: how to declare a formal parameter in a function of type record and access ?
Re: how to define a function with table type parameter
Re: creation of db trigger with error ..
Re: How to write a trigger for the below scenario
how to improve the code using advanced methods
yours advice in improving the coding ..
How to use bulk in multiple cursors !!
;-)

Open cursors exceeded - common problem, different scenario

I searched both the web and the java forums and found the "maximum open cursors exceeded" to be a very common problem, one in which I have, but I can't seem to solve it and I was wondering if the way I am doing certain things are causing it.
Here is my program. I have a java server running that is acting as a midway between a java applet and an Oracle database. Since many users will most likely be using the applet, and since the applet has the ability to alter data in the database, I wanted to Synchronize my database connections.
So because of this, my server has a static class with all the database calls, including a connection call that connects to the database when it is first started up. Also, I return ResultSets to the server, but I never close either my ResultSet or my Statement. I do this because I only have one global of each of them. Otherwise I would have to close them from the server, and this worries me as far synchronization goes. Thus, with a global statement, I am just reinstantiating it every time. This may very well be my problem.
Should I?
1. Not have a single connection to the database but instead create a new connection every time a database call is made?
2. Do not make the resultset and statement global. (And if this is yes, how would I go about closing them after I return the result set to the server).
3. Leave the resultset and statement global but go ahead and try to close them from the server.
4. Or any combination of the above.
Thanks. I appreciate any help advance. This problem has been driving me insane the last couple of days. If it would help to post my database connections code then I will gladly do so.

Hmmm. I have worked on it all day and still have nothing. If anyone has even a shred of help, that would be greatl appreciated. I am going to just go ahead and post my code just in case that helps anyone.
import java.net.*;
import java.sql.*;
import java.io.*;
import oracle.jdbc.driver.*;
class DBOracleCon
     final static String          DBHostName = "hostname",
                         DBPortNumber = "12345",
                         DBId ="myid";
     final static String          UserName = "user",
                         Password = "password";
     private static Connection con;
     private static Statement stmt;
     private static ResultSet rs;
     static protected void dbConnection ()
          try
               DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
                    String dbConnectString =
                    "(DESCRIPTION=(ADDRESS=(HOST=" + DBHostName + ")"+
                    "(PROTOCOL=tcp)(PORT="+ DBPortNumber + "))"+
                    "(CONNECT_DATA=(SID="+ DBId + ")))";
               con = DriverManager.getConnection(
                        "jdbc:oracle:thin:@"+dbConnectString,
                        UserName, Password);
                      con.setAutoCommit(false);
          catch (Exception e)
               System.out.println ("Connection Error:" + e);
     static public synchronized Connection returnConnection ()
          return con;
     static protected synchronized ResultSet executeQuery (String query)
          try
               stmt = con.createStatement();
               //System.out.println ("QUERY: " + query);
               rs = stmt.executeQuery (query);
               return rs;
          catch (Exception e)
               System.out.println (e);
               e.printStackTrace();
               return null;
     static protected synchronized ResultSet executeQuery (PreparedStatement ps)
          try
               rs = ps.executeQuery();
               return rs;
          catch (Exception e)
               System.out.println (e);
               e.printStackTrace();
               return null;
     static protected synchronized void executeUpdate (String query)
          try
               stmt = con.createStatement();
               System.out.println ("UPDATE: " + query);
               stmt.execute (query);
               commit();
          catch (Exception e)
               System.out.println (e);
               e.printStackTrace();
     static protected void executeUpdate (PreparedStatement ps)
          try
               ps.executeUpdate();
               commit();
          catch (Exception e)
               System.out.println (e);
               e.printStackTrace();
     static private void commit ()
          try
               stmt = con.createStatement();
               stmt.execute ("commit");
          catch (Exception e)
               System.out.println (e);
}Thanks.

OracleDataReader.Close() needed to release Open Cursors

I noticed that if I follow the idiom for using OracleDataReader as given in the examples that accompany ODP, it is not good enough for cleaning up.
For example, all the examples provided use something like this:
try
con.Open();
rdr = cmd.ExecuteReader();
...do stuff with rdr
finally
cmd.Dispose();
con.Close();
con.Dispose();
But that's not good enough. If I do this 20 times, I get 20 identical open cursors.
If, however, the finally block is coded like this,
finally
rdr.Close();
rdr.Dispose();
cmd.Dispose();
con.Close();
con.Dispose();
Then there are NO open cursors after this is all over with.
For Oracle people: Is this the intended behavior?
For everyone else: Where you aware you needed to do this to clean up?
I didn't know to do this since none of the examples do this.
If it turns out this is best practice for ODP, I recommend the examples be updated to do this.
If I'm misunderstanding something, then someone please educate me.
Thanks,
David Kreth Allen
Carlson School of Management
University of Minnesota

I tend to explicitly call Dispose() but certainly using a "using" block is another option. Well, OK, sometimes for a quick and dirty example I may not do it, but in general I consider it a good practice. I don't want objects to hang around in the finalization queue waiting to be GC'ed for example...
For more discussion around Dispose() as well as Close() there is this thread:
Why call .Close() and .Dispose() on a connection.
- Mark

Closing or Disposing the Connection Does Not Release Open Cursors

Hi,
I have an architecture like this:
Web Service ---> Business COM+ Component ---> Data COM+ Component
I found that doing a SetAbort() plus explicitly close and dispose the OracleConnection object in my COM+ component does not necessarily close the open cursor.
The way I tested was I would call the same same service multiple times and do a "select * from v$open_cursor where user_name = 'xxx'", I would see a bunch of open cursors with exactly the same SQL_TEXT. The only way to close those open cursors seems to be killing the aspnet_wp.exe process in the Task Manager.
Someone here suggested it might be .NET's problem but I don't think so since I had the same problem with OraMTS 9i.
Can someone from Oracle help? Thanks.
-Linus

Neeraj,
Thank you for your reply. I'd like to let you know that my company submitted a TSR ticket last year (around Oct.?) on this issue and it's still not fixed, yet. This problem prevents us from using COM+ to handle any transactions, which is not acceptable to us. Please try to raise the issue again to your development team if you can, we are depending on the fix.

Cannot figure out why "ORA-01000 Maximum open cursors" is shown...

Hello there ...
I am programming a PL/SQL Code that is throwing 0RA-01000 Maximum Open Cursors Exceeded.
Having already read quite a lot about ORA-01000 errors, I know I should be closing cursors, and have already tried setting OPEN_CURSORS parameter to a high number (1000).
I declared a lot of procedures in my pl/sql, each of which uses one cursor since i am working with a non-Oracle table linked by ODBC ... and each procedure sometimes does thousands of inserts -- but all WITHIN the explicit cursors. The explicit cursors are not declared within each loop.
I already checked the code many times, and made sure all open cursors are closed. In addition, I also verified the numberopen cursors generated by the PL/SQL by running the following SQL after every procedure i run... and outputting it... and it appears the value just keeps on increasing, even though I had explicitly closed all the cursors in all the earlier procedures.
What is funny is that the most number of cursors reported by the code below only hits 150+ cursors. Nowhere near the 1000 open_cursors limit per session.
select a.value into strtxt --, b.name
        from v$mystat a, v$statname b
        where a.statistic# = b.statistic#
        and a.statistic#= 3;When I run the procedures separately though, all the procedures run smoothly (even when I had not yet updated the open_cursors parameter).
I was thinking of the following, but maybe you have some other ideas?
Does this have anything to do with my procedures not being stored procedures?
Or should i be committing records within my procedures instead of out of it?
I really have run into a wall and would really appreciate any tips or helps on this. Thanks in advance!
My basic pl/sql code looks like below. I did not give the actual details cause it will be too long (up to 5000 lines).
DECLARE
PROCEDURE proc1
IS
    CURSOR cur_hca
       is
           select ...from..where;
   TYPE cur_hca_fetch
        Is TABLE OF cur_hca%ROWTYPE
            INDEX BY PLS_INTEGER;
    temp_collect cur_hca_fetch;
BEGIN
   open cur_hca;         --cur_hca is the cursor name.
                                  --i use exactly the same cursor name in the other procedures
      loop
         fetch cur_hca bulk collect into temp_collect LIMIT 1000;
         exit when temp_collect.count=0
         for indx in 1 .. temp_collect.count
            loop
              ...run some sql
            end loop;
      end loop;
close cur_hca;
END proc1;
PROCEDURE proc2   --almost the same as above the only changes are the query for the
                             -- cursor and the sql that happens for each record
IS
BEGIN
   open cur_hca;         --cur_hca is my cursor name
      loop
      end loop;
close cur_hca;
END proc2;
... up to 40 other very similar procedures
BEGIN
   proc1;
   commit;
   select a.value into strtxt
        from v$mystat a, v$statname b
        where a.statistic# = b.statistic#
        and a.statistic#= 3;
DBMS_OUTPUT.PUT_LINE('Number of Cursors After STATUSproc1: ' || strtxt);
   proc2;
   commit;
   select a.value into strtxt
        from v$mystat a, v$statname b
        where a.statistic# = b.statistic#
        and a.statistic#= 3;
   DBMS_OUTPUT.PUT_LINE('Number of Cursors After STATUSproc2: ' || strtxt);
   ... 40 other procedures
END;Edited by: user4872285 on May 6, 2013 6:49 PM
Edited by: user4872285 on May 6, 2013 7:01 PM
Edited by: user4872285 on May 6, 2013 8:02 PM
Edited by: user4872285 on May 6, 2013 8:03 PM

PL/SQL code usually leaks reference cursors and DBMS_SQL cursors - as the ref cursor/DBMS_SQL interface used has a global (session static) scope.
PL/SQL has an intelligent garbage collector that will close local implicit and explicit cursors, when the cursor variable goes out of scope.
If you define an explicit cursor globally (package interface), then it can only be opened once. The 2nd attempt results in a ORA-06511: PL/SQL: cursor already open exception. So code cannot leak explicit cursors as code cannot reopen an existing opened explicit cursor.
I have never seen Oracle leaking cursors internally. So I would be hesitant to call what you are seeing, a bug. If your code is using explicit cursors (even static/global ones), your code cannot leak these cursors, even if your code does not close them. Worse case - the cursor remains open, however new copies cannot be created while it is open.
So I think your are looking at the wrong thing - explicit cursors. These are not the cursors that are leaking in my view (simply because code cannot reuse and open an already opened explicit cursor). Here is an example:
SQL> show parameter cursors
NAME                                 TYPE        VALUE
open_cursors                         integer     300
session_cached_cursors               integer     50
// procedure that seems to "leak" an explicit cursor handle
// as it does not explicitly closes the handle
SQL> create or replace procedure CursorUse is
2          cursor c is select e.* from emp e;
3          empRow emp%RowType;
4 begin
5          open c;
6          fetch c into empRow;
7          --// not closing explicit cursor handle
8          --// and going out-of-scope
9 end;
10 /
Procedure created.
// current session stats
SQL> select b.name, a.value from v$mystat a, v$statname b where a.statistic# = b.statistic# and b.name like '%open%cursor%';
NAME                                  VALUE
opened cursors cumulative                91
opened cursors current                    2
// execute proc that "leaks" a cursor, 10000 times
SQL> begin
2          for i in 1..10000 loop
3                  CursorUse;
4          end loop;
5 end;
6 /
PL/SQL procedure successfully completed.
// no errors due to cursor leakage
// session stats: no cursor leakage occurred as
// PL/SQL's garbage collector cleaned (and closed)
// cursor handles when these became out-of-scope
SQL> select b.name, a.value from v$mystat a, v$statname b where a.statistic# = b.statistic# and b.name like '%open%cursor%';
NAME                                  VALUE
opened cursors cumulative            10,095
opened cursors current                    2
SQL> So the cursor leakage you are seeing is caused by something else... so what else is part of the code, or the session, that you have not yet mentioned?

More on "maximum open cursors exceeded"

It seems a lot of people have been seeing this error message, but reading through the posts on the topic hasn't given me any new insight on the problem. Here's an account of my particular situation:
I am using the XSQL servlet, v.1.0.0.0 with the thin jdbc driver v.1.x. The servlet is running within an Apache server (1.3.12) on a Linux box, and the Oracle database (8.1.5) is located on a Solaris 2.6 machine.
The servlet accepts HTTP connections, performs the corresponding SQL queries and returns the output from the database to the HTTP client. Here's a simple example:
(Sorry about potential bad line breaks.)
client request:
% telnet xsql-host.some.domain 80
Trying xxx.xxx.xxx.xxx
Connected to xsql-host.some.domain.
GET /xsql/test/listall.xsql
<server response here>
listall.xsql:
<?xml version="1.0"?>
<page connection="boss" xmlns:xsql="urn:oracle-xsql">
<accounts>
<xsql:query tag-case="lower" rowset-element="" row-element="accountinfo">
select * from test
</xsql:query>
</accounts>
</page>
Very simple stuff indeed. Now, this has worked perfectly for 3 weeks or so. During this period, the xsql servlet has been stopped and restarted numerous times and the machine hosting the database has been rebooted at least three times. Then, for no apparent reason (as nothing had changed in the setup described above), I started getting "maximum open cursors exceeded" on every request. Since then, I have been unable to get the system working as it had up until now. I haven't restarted the database and I would like to avoid doing so, because that would not be a valid solution for us if the problem reappeared in production. The maximum open cursors setting in Oracle should be correct, since things were running smoothly before.
From what I can see, the problem could be with the servlet not closing its cursors. One post mentioned that it did, but I would appreciate it if this could be double-checked. Considering the database is the only portion of the system which has been kept running for extended periods of time, it seems to me that this might indeed be the problem.
Confirmation, workarounds, suggestions, patches, or a consolation box of chocolates would all be appreciated.
Thanks,
- Fad
([email protected])
null

Check which process is making all the cursors on which database. If it is your procedure, try explicitly closing the cursors. I think the cursors are only implicitely closed after the transaction is ended. If you loop and open a cursor within the loop, that might be the problem.
I also had this problem with Java working over a JDBC connection some time ago on a 815 database. If I recall correctly, that was caused by the JDBC driver and fixed by replacing it with a JDBC driver of 9i.
The following script is what I used previously in a program that can draw a graph from the results. It is ugly, but does the job.
Hope this helps,
L.
select
'max cursors',
to_number(value)
from
v$parameter
where
name = 'open_cursors'
union
select
substr(lower(username),1,10)||'('||substr(to_char(ses.sid)||','
||to_char(serial#),1,9)||')',
s.value
from
v$sesstat s,
v$statname n,
v$session ses
where
s.statistic#=n.statistic#
and ses.sid=s.sid
and n.name like '%cursor%'
and n.name like '%current%'
and not (ses.sid between 1 and 6)

ORA-01000: maximum open cursors exceeded

I ran into this Too many Open Cursors Issue
My environment is
WebLogic 6.1 SP2
Oracle 8.1.7.3.0
JDBC Thin Driver
WebLogic Connection Pools
Tried all the solutions given in the news group for issues, none seemed to work,
so deviced a work around.
just wanted to know if there is a better solution that works.
or else we will go ahead with the workaround...
Explanation follows...
When we work with the weblogic connection pool
Using the WebLogic Pool Driver, we ask for a connection from Weblogic connection
pool.
WebLogic connection pool uses the Oracle Driver to connect to the Oracle Database.
creates a connection and provides it to us.
as we work with this connection, we create prepared statements, execute them etc.
etc. and this will create cursors in the oracle database.
now when we close the connection from our program, what gets closed is the connection
created between our program and the WebLogic Connection Pool
but the connection between the WebLogic Connection Pool and the Oracle database still
remains open, well, there is nothing wrong in that after all that is how connection
pool has to work.
but the issue here is the open cursors that are cached in oracle when we created
statements are not closed even after we close the statements and the connections,
since according to oracle, the connection is still active becuase WebLogic connection
pool is still maintaining the connection. and oracle will clear that only when the
connection is closed with it.
WebLogic pool driver is supposed to clear up the open cursor cache. but i guess it
is not doing it.
I did some R&D and tried out the following solutions and they dont seem to solve
the issue. (Most of them were picked up from the News groups)
1. Include the latest Oracle type 4 driver in class path before the other classes
2. Put a Connection.rollback before closing connection
3. Use the Oracle Driver directly bypassing the Connection Pool. (This works... but
we cant do that becuase we are using connection pools to handle connection.)
So I came up with the following work around.
Whenever a connection is created from oracle, internally the driver creates a session
with oracle.
when weblogic pool driver creates a session it uses an ORACLE session parameter SESSION_CACHED_CURSORS
I guess WebLogic sets it to a high number. But there has to be a parameter which
we can configure to control this when we create out connection pool. the closest
parameter was found to be "Prepared Statement Cache Size" but even after making it
0 it doesnt seem to improve the situation.
so, to override the SESSION_CACHED_CURSORS in our connection. every time we get a
connection we have to execute a query to alter the session paramater SESSION_CACHED_CURSORS
as follows
woConn = java.sql.DriverManager.getConnection(DCConstants.DC_JDBC_URL);
try
Statement woTmpStmt = woConn.createStatement();
woTmpStmt.execute("ALTER SESSION SET SESSION_CACHED_CURSORS = 0");
woTmpStmt.close();
catch(SQLException woSQLEx)
DCDebug.logInfo("DCDataFactory","Unable to alter session");
regards
Gulam

Hi. If you'e turned off our statement cache (by setting it's size to zero),
then it's a DBMS-side issue only. When you return a connection to the
pool (by closing it), we will close any statements and result sets you
had created but not closed, so we do all we can. In fact if you left
the connection in an autoCommit(false) mode, we do the rollback for you
too. Besides setting that DBMS-side option you do with SQL, the only
other option I see is to configure your DBMS/session info for Oracle,
to allow more open cursors per connection than you currently allow.
Joe Weinstein at B.E.A.
Gulam Dasthagir wrote:
I ran into this Too many Open Cursors Issue
My environment is
WebLogic 6.1 SP2
Oracle 8.1.7.3.0
JDBC Thin Driver
WebLogic Connection Pools
Tried all the solutions given in the news group for issues, none seemed to work,
so deviced a work around.
just wanted to know if there is a better solution that works.
or else we will go ahead with the workaround...
Explanation follows...
When we work with the weblogic connection pool
Using the WebLogic Pool Driver, we ask for a connection from Weblogic connection
pool.
WebLogic connection pool uses the Oracle Driver to connect to the Oracle Database.
creates a connection and provides it to us.
as we work with this connection, we create prepared statements, execute them etc.
etc. and this will create cursors in the oracle database.
now when we close the connection from our program, what gets closed is the connection
created between our program and the WebLogic Connection Pool
but the connection between the WebLogic Connection Pool and the Oracle database still
remains open, well, there is nothing wrong in that after all that is how connection
pool has to work.
but the issue here is the open cursors that are cached in oracle when we created
statements are not closed even after we close the statements and the connections,
since according to oracle, the connection is still active becuase WebLogic connection
pool is still maintaining the connection. and oracle will clear that only when the
connection is closed with it.
WebLogic pool driver is supposed to clear up the open cursor cache. but i guess it
is not doing it.
I did some R&D and tried out the following solutions and they dont seem to solve
the issue. (Most of them were picked up from the News groups)
1. Include the latest Oracle type 4 driver in class path before the other classes
2. Put a Connection.rollback before closing connection
3. Use the Oracle Driver directly bypassing the Connection Pool. (This works... but
we cant do that becuase we are using connection pools to handle connection.)
So I came up with the following work around.
Whenever a connection is created from oracle, internally the driver creates a session
with oracle.
when weblogic pool driver creates a session it uses an ORACLE session parameter SESSION_CACHED_CURSORS
I guess WebLogic sets it to a high number. But there has to be a parameter which
we can configure to control this when we create out connection pool. the closest
parameter was found to be "Prepared Statement Cache Size" but even after making it
0 it doesnt seem to improve the situation.
so, to override the SESSION_CACHED_CURSORS in our connection. every time we get a
connection we have to execute a query to alter the session paramater SESSION_CACHED_CURSORS
as follows
woConn = java.sql.DriverManager.getConnection(DCConstants.DC_JDBC_URL);
try
Statement woTmpStmt = woConn.createStatement();
woTmpStmt.execute("ALTER SESSION SET SESSION_CACHED_CURSORS = 0");
woTmpStmt.close();
catch(SQLException woSQLEx)
DCDebug.logInfo("DCDataFactory","Unable to alter session");
regards
Gulam

Viewer leaving open cursors in Oracle

We are using the JRC to display reports in our software. We are running jboss-4.2.0 as our application server. The backend could be either SQL Server or Oracle. For Oracle we are using the oracle.jdbc.driver.OracleDriver driver. The reports are set up using a JDBC (JNDI) connection. Generally we have it working ok but in Oracle the JRC is leaving open cursors leading to ORA-01000: MAXIMUM OPEN CURSORS EXCEEDED. I have found that a new cursor is opened when the data source is changed in the following code snippet
Iterator tableIT = tableNames.iterator();
while (tableIT.hasNext()) {
ITable oldTable = (ITable)tableIT.next();
ITable table = (ITable) ((IClone)oldTable).clone(true);
table.setQualifiedName(table.getName());
clientDoc.getDatabaseController().setTableLocation(oldTable, table);
When we hit the last line in this loop, a new cursor is opened in Oracle so if a report has 10 tables, I get 10 cursors opened. I know that I need to close the cursors somehow but nothing I do seems to make a difference. After my processHttpRequest call to the viewer I added:
crystalReportPageViewer.getReportSource().dispose();
clientDoc.getReportSource().dispose();
The code definately executes but the the number of open cursors in Oracle does not change. I am at a loss.

A couple more things to think about then.
1. When you go through your loop to set your table location, you are using the clone method to create a new table and then pass that table to the report. Cloning tables is no longer necessary with the JRC. We do know that a fix was provided for the JRC SDK, however this fix would probably not have been applied to the clone method since it has been deprecated.
I have attached a sample that shows the new methodology for setting table location; very similar, just not using clone anymore.
2. When you want to destroy any connections that the ReportClientDocument has made, you will need to call .close() on this object. This can be done in conjunction with the viewer.dispose(). One thing to note is that if you call the .close() method, it will need to be done as the user is closing the browser, or you will not have access to your report object when you have it open in the HTML Viewer.

Reg Open Cursor Concept

Similar Messages

Maybe you are looking for