Dump open cursors in sessions that execute a given sql_id

Hi,
Is there a way to dump open cursors of whichever session that execute a given sql_id?
I've been playing with "alter system set events..." like explained in [Tanel Poder ORADEBUG DOC|http://tech.e2sn.com/oracle/troubleshooting/oradebug-doc] without sucess.
Any clue?
Thanks in advance.
Joaquín González.

Am I now thinking too simple... or not understanding your question, but how about:
select sid, user_name, address, hash_value, sql_id, sql_text from v$open_cursor;It will output something like:
SID USER_NAME ADDRESS                          HASH_VALUE SQL_ID        SQL_TEXT
144 SYSMAN     000007FF25D82640                 1740505306 9ugwm6xmvw06u SELECT LAST_LOAD_TIME FROM MGMT_TARGETS WHERE TARGET_GUID=:B
144 SYSMAN     000007FF25D7A270                 1476264175 bdfrydpbzw07g SELECT BLACKOUT_GUID, START_TIME, END_TIME, STATUS FROM MGMT
131 SYS        000007FF2E0841D8                 4194829828 g6gu1n3x0h1h4 select streams_pool_size_for_estimate s,           streams_p
139 SYS        000007FF287877E0                  673844243 9g485acn2n30m select col#,intcol#,reftyp,stabid,expctoid from refcon$ wher
137 SYS        000007FF287877E0                  673844243 9g485acn2n30m select col#,intcol#,reftyp,stabid,expctoid from refcon$ wher
136 SYS        000007FF287877E0                  673844243 9g485acn2n30m select col#,intcol#,reftyp,stabid,expctoid from refcon$ wher
138 SYS        000007FF27794BB8                  971902547 8g45y2nwyw3km Select owner from sys.dba_objects where object_name = 'QU_VE
144 SYSMAN     000007FF274DC2F8                 2141064957 9ur12dtztw3rx SELECT TARGET_GUID, DELETE_REQUEST_TIME, DELETE_COMPLETE_TIM
138 SYS        000007FF28672410                 2195068792 asvzxj61dc5vs select timestamp, flags from fixed_obj$ where obj#=:1 Maybe join with v$sql_text to get the full statement
Regards,
FJFranken

Similar Messages

Avg number of open cursors per session

We've been noticing a large number of open cursors open per session in our database, these users being Oracle Forms users. There are quite a few 'bells & whistles' in this vendor-supplied application with many round trips to the database. The warning we were receiving was induced by an alert that we had set up within OEM.
It got me wondering then, what a large number of cursors per process really was. We're seeing between 10-80 open cursors. The init parm OPEN_CURSORS has a default value of 50 upon installation (which is per session), so the max of 80 doesn't seem too much higher.
Are we really experiencing a large # of open cursors per session? Does someone have a means of estimating the max # of cursors that one would expect based upon CPU & memory resources? I can't find anything in the documentation.
Thanks,
Chuck

There is an OPEN_CURSORS parameter in the init.ora file,
I want to know the impact of number of open cursors on performance
(ie., how many open cursors would be appropriate for an instance)There shouldn't be a performance issue here. The value needs to be set based on how many open cursors you want to allow simultaneously. If you set the value too low, applications will get the "too many cursors open" error when they try to open a new cursor. If you're not having problems, or if you don't know how many open cursors you're likely to have, I wouldn't change this parameter.
Justin

Ever since I installed IOS7, my Iphone 5 has always opened with a message that I have given an incorrect voicemail password. I have never put in a voicemail password, so I cannot get into the site to correct this. Any suggestions?

Ever since I installed IOS7, my Iphone 5 (10 months old) has always opened with a message that my voicemail password is incorrect. But I've never at any time put in a voicemail password, so I can't get into the site to put this right, and it didn't happen before I installed IOS7. The message goes away as soon as I cancel it, but it's very irritating. Any suggestions?

Call your carrier & have them reset your voicemail, then set things up again. Most carriers require a password for voicemail.

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

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.

Maximum open cursors exceeded problem

hi,
I am connecting to Oracle 8i (8.1.6 ) using JDBC2.0. I have a
block of code which does the following:
Open connection to database, create a Statement object say stat
and a Prepared Statement object say pStat
pStat.execute()
while(condition)
stat.executeUpdate(string);
pStat.close();
stat.close()
Close connection
Multiple execution of the block gives ORA-01000 error. I use
select user_name, count(*) num from sys.v_$open_cursor group by
user_name;
to check for open cursors and find that no open cursors result
from block. The maximum # of open cursors is set to 100.
Please help!
Regards,
Pratibha

If that were true, then connection pooling would never work. I
think the problem is:
while(condition){
stat.executeUpdate(string);
Oracle is creating a new process (cursor) for each call to
executeUpdate, which is never being released throught the whole
looping process. What would be better is:
while(condition){
stat = conn.createStatement();
int result = stat.executeUpdate(string);
stat.close();
conn.commit();
You have to destroy the connection, not just close it.
rgds, APC

How to analyse the number of open cursors being used by each program?

Hi,
I am getting an error "ORA:1000 Maximum Open Cursors Exceeded" in my
application. I want to analyse and monitor that how many cursors are
being used by each program running in a particular session. I have
already set the Open Cursors Count double of the recommended for my
application, yet I am getting this error.
Is there any tool to analyse and monitor the number of cursors being
used by each DB call?
I have installed SAP NW 7.0 and Using Oracle 10g as DB.
Your immediate help will be greatly appreciated.
Best Regards,
Smriti.

You can list the open cursors per session and check which one uses the most with sqlplus:
SQL> 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';
Values over 300 are unusual.
It is quite possible, that you see several workprocesses using a lot, because workprocesses are kind of shared sessions.
Cheers Michael
Edit: ah, our posts crossed, obviously there is no workprocess in the java world

Understanding Open Cursor

Hi All, I am confused on this open cursor as I would like to understand further if I am hitting my limit. Currently I do not see the error that my open cursor exceeded.
If I add up the a.value on the second sql, I am getting more than 10k, but my open cursor is only set to 5000. I must be calculating this wrongly here.
open cursor = 5000
session_cached_cursors 200
select max(a.value), a.sid, b.program
from v$sesstat a, v$session b, v$statname c
where a.sid = b.sid
and a.statistic# = c.statistic#
and c.name = 'opened cursors current'
group by a.sid, b.program
order by 1 desc
MAX(A.VALUE) SID PROGRAM
2201 596
516 514 abc@server1 (TNS V1-V3)
401 720 abc@server1 (TNS V1-V3)
602 670 abc@server1 (TNS V1-V3)
578 445 abc@server1 (TNS V1-V3)
129 rows selected.
Would like to know what is the current open cursor count?
If I get the sid like above, can I know what SQL is holding it up?

What total do you get if you use the query from this article? See 'Monitoring open cursors'. Note that it includes serial#
http://www.orafaq.com/node/758
--total cursors open, 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';
If I sum up the a.value it is again more than 10k but the highest a.value is only 2000+
OPEN_CURSORS specifies the maximum number of open cursors (handles to private SQL areas) a session can have at once. Since it is saying open cursor by a single session. I would suppose my max value now is 2000+ while my max_cursor set is 5000. Am I right?

ORA-33273: Analytic workspace FPA.FPAPJP has open cursors ... error?

Gurus,
When we try to detach analytic workspace, I get the following error
## Detail 0 ## java.sql.SQLException: ORA-33273: Analytic workspace FPA.FPAPJP has open cursors and cannot be detached.
ORA-06512: at "APPS.FPA_UTILITIES_PVT", line 129 ORA-06512: at "APPS.FPA_PROCESS_PVT", line 4685
ORA-34684: All of your attached analytic workspaces are read-only. Therefore, the UPDATE command will not save changes. ORA-06512: at line 1
The workspace " FPA.FPAPJP" has been opened in read-write mode and no explicit cursors are present in the code.
Any inputs are truly appreciate.
Thanks - Srujan

This is a new error to me. For what it is worth, here is a dba query to list open cursors by session.
select
vses.username||':'||vsst.sid username,
vstt.name,
max(vsst.value) value
from
v$sesstat vsst,
v$statname vstt,
v$session vses
where
vstt.statistic# = vsst.statistic# and
vsst.sid = vses.sid and
vstt.name in
('opened cursors current',
   'opened cursors cumulative') and
vses.username is not null
group by
vsst.sid,
vses.username,
vstt.name
order by
vsst.sid,
vses.username,
vstt.name
/Here is a query to list all attach aws.
set pages 500 lines 110
col usn format a23 heading "USER (SID,SERIAL#,SVR)"
col aw format a22 heading "OLAP AW (ATTACHED)"
col generation format 99999 heading "Genrtn"
select username||' ('||sid||','||serial#||','|| decode(server,
'DEDICATED','D',
'SHARED', 'S', 'U')||')' usn,
gvawo.inst_id,
owner||'.'||daws.aw_name||' ('||
decode(attach_mode,
   'READ WRITE', 'RW',
   'READ ONLY', 'RO',
   'MULTIWRITE', 'MW',
   'EXCLUSIVE', 'XW', attach_mode)||')' aw,
generation
from
dba_aws daws,
gv$aw_olap gvawo,
gv$aw_calc gvawc,
gv$session gvses
where
daws.aw_number = gvawo.aw_number and
sid = gvawo.session_id and
gvawc.session_id = sid and
gvawo.inst_id = gvawc.inst_id and
gvses.inst_id = gvawc.inst_id
order by
username,
sid,
daws.aw_nameWas this a one off event or is it happening repeatedly? If it is a one-off, then closing the session or stopping and starting the database instance should resolve the problem.

My tabs will not restore after starting Firefox -- even with the option to restore my tabs and windows is checked in the "options" window. I'm losing tabs from previous sessions that I need to keep open every time I need to restart. Thanks for any advice!

Is there something else I need to tweak to get rid of this annoyance instead of simply clicking the check box? I'm losing tabs from previous sessions that I need to keep open every time I need to restart. Thanks for any advice!

Make sure that you do not use Clear Recent History to clear the <i>Browsing History</i> when you close Firefox.
*https://support.mozilla.com/kb/Clear+Recent+History
It is possible that there is a problem with the files sessionstore.js and sessionstore.bak in the Firefox Profile Folder.
Delete the sessionstore.js [2] file and possible sessionstore-##.js [3] files with a number and sessionstore.bak in the Firefox Profile Folder.
* Help > Troubleshooting Information > Profile Directory: Open Containing Folder
* http://kb.mozillazine.org/Profile_folder_-_Firefox
Deleting sessionstore.js will cause App Tabs and Tab Groups and open and closed (undo) tabs to get lost, so you will have to create them again (make a note or bookmark them).
See also:
* [1] http://kb.mozillazine.org/Session_Restore
* [2] http://kb.mozillazine.org/sessionstore.js
* [3] http://kb.mozillazine.org/Multiple_profile_files_created

Is there any way to do a manual session restore if Firefox doesn't open your previous session - and doesn't give you that option?

I've got Firefox configured correctly and it always opens my last session. However, sometimes when the computer crashes and a second Firefox window is open (this time it was either a pop-up window or the Firefox update window), Firefox only recognizes that window as the "last session," and it loses the most recent multi-tab session. (Hmm, maybe what I need is "re-open recent sessionS" or "last multi-tab session" ?!)
Anyway ... is there any way I can retrieve yesterday's open tabs without picking through my history and finding them one-by-one?

The presence of a sessionstore file with a number (sessionstore-1.js) indicates that at one time there has been a problem with accessing sessionstore.js and that Firefox wasn't able to rename sessionstore-1.js to sessionstore.js
You can see by the file date of sessionstore-1.js when that has happened and if it an old file then you can remove it or you can try to copy that file to sessionstore.js to see which session it brings back.
Make a backup copy of all sessionstore.* files elsewhere to be sure that you do not lose a session before doing that.

What do i when i intent to open in moodle session a pdf file link? It doesn't download in window that open when i active the link icon

I can't open a pdf file that linked with a emergent window in moodle sistem.

I seem to have solved my own problem. When I disabled the add-on "Tab Renamizer" everything started working fine.

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

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?

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

Dump open cursors in sessions that execute a given sql_id

Similar Messages

Maybe you are looking for