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

Similar Messages

  • Something about  open cursor .

    Guys ,  I need an advice, I'm doing the following code, but I´n not sure  if it can work or could be very slow , the thing is that que ti_referenc could have more than 1 million entries , what else is possible to do ?
          LOOP AT ti_referenc.
            OPEN CURSOR WITH HOLD cursor1 FOR
             SELECT * FROM zpf_cob_doc_ext
              WHERE referencia = ti_referenc-ref.
            FETCH next cursor cursor1
            APPENDING CORRESPONDING FIELDS OF TABLE it_zpf_cob_doc_ext
            PACKAGE SIZE p_commit.
            CLOSE CURSOR cursor1.
          ENDLOOP.
    thank you  a lot.

    hi,
    You can even add additional code as below ..
    OPEN CURSOR WITH HOLD cursor1 FOR
    SELECT * FROM zpf_cob_doc_ext
    WHERE referencia = ti_referenc-ref.
    DO.
    FETCH next cursor cursor1
    APPENDING CORRESPONDING FIELDS OF TABLE it_zpf_cob_doc_ext
    PACKAGE SIZE p_commit.
    IF sy-subrc <> 0.
    CLOSE CURSOR cursor1.
    EXIT.
    ENDIF.
    ENDDO.

  • Question about trigger to check the number of open cursors

    Hello.
    I wonder if it is possible to create a trigger that fires when the number of open cursors in a database becomes larger than a certain number. What kind of trigger and how would it be?
    If it were possible the trigger would write traces with the timestamp of the event.
    I would also like some pl/sql tester that would increase the number of open cursors so that I could check the trigger.
    Thanks in advance.

    Satish Kandi wrote:
    OPEN_CURSORS is a value per session and not for the entire database. So if your cron job is looking for a global cumulative value of open cursors to occur in a single session, it won't find any such sessions.
    Is it the case?Yes, I am afraid it is.
    I am sorry but I don't unsertand what you are telling me: doesn't "select count(*) from v$open_cursor" count the number of open cursor for all sid columns in the view?
    The cron launches a scripts that connects to the database via sqlplus whereas there is a java application (several threads without connection pooling) that connects to the database via jdbc and that causes the problem once in 5 months (to say something).
    Thanks again.
    Edited by: fsanchezherrero on Jul 3, 2009 12:28 PM
    Edited by: fsanchezherrero on Jul 3, 2009 12:36 PM

  • 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 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.

  • 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.

  • 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)

  • 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.

  • Maximum open cursors exceeded - after update to 1.1.1.25

    While browsing around a database I keep getting "Maximum open cursors exceeded". The only cure is to disconnect and reconnect. This doesn't happen in the prior version (1.0.0.15).

    Dear Product Development
    I posted a thread about this and a previous version but I am now getting it more and more often in the new version.
    When it happens I get a JAVA log window popping up with the following information in it.
    Level X
    Sequence     130
    Elapsed     0
    Source oracle.dbdev.oviewer.table.DataEditor
    Message      _getTableData
    Is this any help to the product development team in diagnosing the issue.
    Cheers
    Chris

  • Maximum Open Cursors Exceeded problem in XSQL

    Hi,
    We are processing an XSQL page by calling XSQLRequest.process() programatically within our application. Within the XSQL page there are several queries which involve multiple nested CURSOR expressions... when the query returns enough rows we are running into the error "ORA-00604: error occurred at recursive SQL level 1 ORA-01000: maximum open cursors exceeded".
    When searching this forum I have seen many (old) postings regarding this error and a bug in the XDK... seems like it was some time ago, but while we set about improving the structure of our XSQL page (or increasing the max open cursor init parameter currently at 500 or both) can anyone confirm that this bug no longer exists?
    Also, any general suggestions on working around this limit rather than increasing it? We have considered splitting up our queries into smaller queries (and merging the results via XSLT) and closing cursors during the session explicitly by issuing commits within the XSQL page... but any better ideas?
    Thanks,
    Bob

    I have found this max open cursors problem to be related to Statement object not being closed. This presents a problem for the use of PreparedStatements, because they are only useful if you can keep them open and resuse them. However, in doing so, each iteration through the PreparedStatement creates another open cursor in the databse rather than reusing the previous one. A work around I discovered by reading about REF CURSORS and I use in JDBC is as follows:
    Assuming a previously prepared PreparedStatement pstmt and a ResultSet rset-
    while (rset.next()) {
    rset.close();
    // This line closes the cursor in the database
    // but does not require you to re-prepare the
    // PreparedStatement. Don't ask me why--ask the
    // Oracle API guys.
    rset.getStatement().close();
    // make ready for GC
    rset = null;

  • Oracle - maximum open cursors exceeded

    Hi! I'm constatly getting the error I pasted below, when this line is executed:
    PreparedStatement stmt = connection.prepareStatement(sqlStatement);
    'connection' is of course an instance of oracle.jdbc.driver.OracleConnection, and 'sqlStatement' is a normal INSERT statement.
    Now, why I'm getting an error that involves cursos if the statement is an insert? One more thing, this error is happening in some enviroments so I think it could be an orcacle server problem (like installation or configuration problem), or it could be the driver, or... I dont know :)
    Well, I hope anyone can give me a tipo about this... Thanks in advance.
    Dario
    ORA-01000: maximum open cursors exceeded
    java.sql.SQLException: ORA-01000: maximum open cursors exceeded
    at oracle.jdbc.dbaccess.DBError.throwSqlExceptionDBError.java:180)
    at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
    at oracle.jdbc.ttc7.Oopen.receive(Oopen.java:118)
    at oracle.jdbc.ttc7.TTC7Protocol.open(TTC7Protocol.java:472)
    at oracle.jdbc.driver.OracleStatement.<init>OracleStatement.java:499)
    at oracle.jdbc.driver.OracleStatement.<init>OracleStatement.java:518)
    at oracle.jdbc.driver.OraclePreparedStatement.<init>OraclePreparedStatement.java:210)
    at oracle.jdbc.driver.OraclePreparedStatement.<init>OraclePreparedStatement.java:193)
    at oracle.jdbc.driver.OracleConnection.privatePrepareStatementOracleConnection.java:869)
    at oracle.jdbc.driver.OracleConnection.prepareStatementOracleConnection.java:704)
    ------------------------------------------

    Thanks a lot for all the answers...
    After some tests a made, I found out that in the enviroment I developed the application, the value of the parameter OPEN_CURSORS is 300. I don't know yet which is the value in the test enviroment (where the errors are happening) but I'm pretty sure it is smaller, since I could force the same error in the development enviroment increasing the concurrency of the application (ie, I force the application too many create prepare statements, even much more than the real values the application should accept).
    Well, I have to thank you all again...
    Dario

  • Monitroing maximum open cursors

    Hei experts!
    How can I get the information about the all the curently opened connections and cursors? We have this 'maximum open cursor exceeded' problem very often.
    Although I know I can raise the open cursor amount in init.ora, still I want to trace who is connecting to database and how many curcors caused by that connection.
    By the way, the query
    select a.value, b.name from v$mystat a, v$statname b
    where a.statistic# = b.statistic# and a.statistic#= 3;
    doesn't really show me the actua opened cursors(because it always show only 1 open cursor which is caused just by this select statement).
    Any information is appreciated,
    Thanks in advance,
    Chen Zhao

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Koshal Patibandla ([email protected]):
    Set the paramater open_cursor to as high as possible. There is absolutely no performance overhead.
    <HR></BLOCKQUOTE>
    Yea, of course if you have enough memory

  • Maximum Open Cursors with the CachedRowSet

    Hi all,
    I have a simple task that is cause significant headaches. I'm using the CachedRowSet to process records from an Oracle 8.1.6 database. The code simply populates the row set with records, makes changes to 2 or 3 fields in each record, then calls the acceptChanges().
    When I process about 200 records, everything works fine. If I try to process 300 records, I get the error
    "ORA-01000: maximum open cursors exceded".
    Right before the acceptChanges is called, there is only 1 cursor opened ( I'm checking this via the V$OPEN_CURSOR table). After the acceptChanges is called, it throws the error. Inside my catch block, I put a loop in to print the open cursors. All but two of them is from my app and showing the exact same SQL, update table set name ....
    I have tried populating it directly and through a ResultSet, neither work. When I do a similar process using a ResultSet by itself, it is fine.
    If anyone could please suggest what I might be overlooking I would appreciate it. Also, I would also like to know if there is someway to examine the specific SQL that is being sent to the database if possible.

    we've had similar problems with Oracle creating and not destroying its own cursors("under the covers"). There is relevant info at the following link:
    http://forums.java.sun.com/thread.jsp?forum=48&thread=135291
    quick checklist:
    1. close all statements/preparedstatements/resultsets explicitly and immediately after you are finished with them
    2. increase your number of open_cursors in init.ora file
    -->we had to increase ours to over 700 at one point.
    3. commit/rollback explicitly when finished transactions.
    hope this helps
    Jamie

Maybe you are looking for