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

Similar Messages

How to get number of open cursors per connection?

I am trying to make sure my connection pool handles all
situations where I need to close and reopen a Connection
object.
The last criteria I am trying to check is, how many open cursors
are there on a connection that is supposedly no longer in use?
If my application tells my Connection pool class that a
Connection is not in use anymore, the Connection can be
reused unless there are too many open cursors. I'm closing all my
statments, but I want to make sure that I've got this check in
place.
TIA,
Mike
null

I am trying to make sure my connection pool handles all
situations where I need to close and reopen a Connection
object.
The last criteria I am trying to check is, how many open cursors
are there on a connection that is supposedly no longer in use?
If my application tells my Connection pool class that a
Connection is not in use anymore, the Connection can be
reused unless there are too many open cursors. I'm closing all my
statments, but I want to make sure that I've got this check in
place.
TIA,
Mike
null

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

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

Number of open cursors

I'm working on debugging some code and trying to monitor some of things that are happening at runtime. One of the things that would be useful is if I could monitor the number of open cursors on a connection.
I've done my searching and can't seem to find anything of the sort Connection.getOpenCursorCount().... is there such a method or anything related?

There's nothing generic like this, every possible approach that I know of is implementation-specific, either Java-side or DB-side.
The Java-side approach is to attempt to track ResultSets through their life-cycle, as a rough proxy for cursors; this usually relies on wrapped RSs or a vendor-specific driver feature, and is sometimes not a good solution for running down certain types of resource leaks.
On the DB side, some DBs have some visibility into open cursors through some sort of vendor-specific API.
For example, on Oracle, there is the system view V$OPEN_CURSOR that can be queried for some information related to open cursors, often in conjuction with info ftom V$SESSION and V$SQL, V$SQL_AREA or V$SQL_TEXT. IMPORTANT NOTE: this view is actually a view on internal Oracle memory structures. While you can query it like any normal view or table, it is changing constantly, with internal per-row consistancy guaranteed by latches (locks on memory). Complex queries against internal views (such as self-joins or complex aggregations) can interact with the latches very badly; the queries may take many hours to complete and consume massive amounts of CPU while doing so. If you need to perform a complex analysis, don't do it on the live view; create a snapshot of the view and use that, for example:
CREATE TABLE SNAP_OPEN_CURSORS as
SELECT * FROM V$OPEN_CURSORS(Note that in a RAC or OPS Oracle cluster, the V$ views only report on the instance you're connected to; there are analogous GV$ views that report on all available instances, and have an added INST_ID column identifying the source instance, when relevant).

How to get highest number of open cursors within the current calendar day

Hi all ,
i need to know how to get the highest number of open cursors within the current calendar day.
Thanks ,

823030 wrote:
the issue is my customer is getting the error ORA-01000: maximum open cursors exceeded and we need an sql statment that gets the following values :
-highest number of open cursors experienced in the current calendar day.
-current open cursors
-and maximum open cursorsThis error is rare. It happens when
a) the value of the open cursor parameter is set extremly low (default is something like 1000). Low would be something like 10.
b) <strike>you have many concurrent users(=sessions) and </strike>the application does not use bind values
In this case each select will open a new cursor, instead of reusing it.
c) you have a select that opens a cursor for each line. This can happen with a statement where you have the CURSOR keyword somewhere in the select or where clause. Those cursors will be closed when the select is finished. But during the run time of the select, all cursors stay open.
To track the number of "open cursors" during the day you would need to implement some monitoring. Maybe based on the view that was already mentioned.
Edited by: Sven W. on May 16, 2011 2:30 PM - since the parameter is on session level, other open cursors should not influence it much.

Increased maximum number of open cursors

I'm using JDBC with oracle. And I need to send many transactions to database.
I use Statement.executeQuery("INSERT INTO ..............") and so on!
But after 300 transaction Oracle send me an error that "increased maximum number of open cursors." How to increase the max number of that cursors or how to close them??
Thanks in advance!

1. Use, PreparedStatement instead of Statement.
2. Use addBatch() and executeBatch() methods.
3. Don't create statement objects in a loop, just create one object outside the while (or for) loop and use the same object again and again. Most probably the problem may be due to creating excessive object in a llop.
Hope this helps.
Sudha

'number of open cursors exceeded' exception - 10.3.1

Hi All,
We have may DynamicSQL statements fired from our processes due to which we are getting 'number of open cursors exceeded' exception. We don't want to increase the limit of the maximum open cursors. Is there any way to close the cursors explicitly in 10.3.1?
I am aware that when the iterator fetches the last result the cursor gets closed (in the case of any select query) but we have faced the same issue once/twice in the insert query also, is it because we have fired one insert after the other immediately? How much time does a cursor takes to close (implicitly) in the case of insertion of data?
Thanks in advance..
Edited by: GBP on Jan 5, 2011 4:07 AM

Hi,
Please see my post: Re: Cursor closing using DynamicSQL.executeQuery
Hope this helps,
Ariel

[SOLVED] Number of open windows per application

I'm trying to write a script that will count how many open windows a specific application has, for example palemoon. I already tried
ps -aux | grep palemoon
While I have two fresh palemoon windows (only one tab per window), the above command shows only one instance of /usr/bin/palemoon running:
ps -aux | grep palemoon
george 31403 13.6 12.6 573188 260000 ? Sl 18:27 2:56 /usr/bin/palemoon
george 32335 0.0 0.1 4900 2188 pts/3 S+ 18:49 0:00 grep palemoon <--- this line is ignored
How can I get as a result the real number of open windows for palemoon (which in the above example is obviously 2)?
Last edited by helix (2015-06-12 17:02:38)

It sure does provide a lot of info, but parsing it seems tricky.
I don't even know how to count how many tabs one instance of firefox has open.
@OP
Why do you need this information?
Edit: Does
xwininfo -root -tree | grep -ci moon
work too?
Last edited by karol (2015-06-12 17:06:23)

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

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.

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

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

Too many open cursors

Could someone help me understand this problem, and how to remedy it? We're getting warnings as the number of open cursors nears 1200. I've located the V$OPEN_CURSOR view, and after investigating it, this is what I think:
Currently:
SQL> select count(*)
2 from v$open_cursor;
COUNT(*)
535
1) I have one session open in the database, and 40 records in this view. Does that mean my cursors are still in the cursor cache?
2) Many of these cursors are associated with our analysts, and it looks like they are likely queries TOAD runs in order to gather meta-data for the interface. Can I overcome this?
3) I thought that the optimizer only opened a new cursor when a query that didn't match one in the cache was executed. When I run the following, I get 105 SQL statements with the same hash_value and sql_id, of which, they total 314 of the 535 open cursors (60% of the open cursors):
SQL> ed
Wrote file afiedt.buf
1 SELECT COUNT(*), SUM(cnt)
2 FROM (SELECT hash_value,
3 sql_id,
4 COUNT(*) as cnt
5 FROM v$open_cursor
6 GROUP BY hash_value, sql_id
7* HAVING COUNT(*) > 1)
SQL> /
COUNT(*) SUM(CNT)
104 314
4) Most of our connections in production will use Oracle Forms. Is there something we need to do in order to get Forms to use bind variables, or will it do so by default?
Thanks for helping me out with this.
-Chuck

CURSOR_SHARING=EXACT
OPEN_CURSORS=500
CURSOR_SHARING
From what I've read, cursor sharing is always in effect, although we have the most conservative method set. So I'm not sure how this affects things. Several identical queries are being submitted in several separate cursors.
OPEN_CURSORS
This value corresponds with the maximum number of cursors allowed for a single session. We're using shared servers, so I'm exactly sure if this is still 'per session' or 'per shared server', but 500 should be more than enough.
It sounds like you're suggesting that a warning is being triggered based upon our init params. If that's the case, then what are people seeing as a limit for cursors on a 2-CPU Linux box with 2G of memory?
-Chuck

TROUBLES WITH OPEN CURSORS

Hi, we have an application running on 8.1.6 with 20 000 open cursors is this a really resources problem for database. Ive tried with this parameter CLOSECACHED_OPEN_CURSORS = TRUE in INIT.ORA but it doesnt work with PLSQL.
I found problem resolves if we close session 'cause it frees all resources but i'm seeking for another option.
Does anyone have an advice about it I appreciate it!!

Its java application, Not surprising at all...
cursors are close by java How sure are you? Does the Java side correctly and properly close the cursors on the Oracle side? 20,000 opened cursors should mean something along the lines of 20,000 Oracle sessions. Is this the case? The norm is a single open cursor at a time per session.
Thus it very likely means you have cursor leakage. The cursors objects in Java are closed/freed, but this is not correctly calling Oracle and telling the Oracle session that it too can close the cursor.
Increasing the number of opened cursors will only move the brick wall a few metres, allowing you to run faster into it.
Remember that Oracle owns the cursor. It allocates resources for that cursor. It delivers a cursor pointer (aka ref cursor) to the client to use. The client cannot free that cursor - it must request the Oracle session to do so. All the client can do it release its resources for that cursor pointer it created client side.
I have seen numerous times how Java code is written that leaks cursors badly. So this is not something unusual - unfortunately. Fortunately though, it is fixable. On the Java side as it is not an Oracle problem, but rather Oracle-being-abused problem.

Avg number of open cursors per session

Similar Messages

Maybe you are looking for