Maximum cursors exceeded

Question

We are having a problem where we get the ORA-01000 error after a while
on our servers. We are using wl7.0 sp1 and Oracle 9.2.0.1 with the thin
driver. We are connecting to the db with the weblogic.jdbc.pool.Driver
class.
I've looked in this group and on support but can't find the specific
answer to our problem.
The number of cursors open gradually increases while our application is
running, until we hit the max (700 per session.)
The FAQ on askbea.com says to just increase the number of cursors, but
we already did this and the number keeps growing and growing as the
application runs.
We are closing all resultsets and statements in finally blocks. I have
tested to see which SQL statements are contained within the open cursors
and traced those statements back to code where I was able to verify
beyond doubt that they were being closed correctly.
I have also tried, on our staging server, to use the very latest driver
from oracle for our db version to no avail.
Does anyone know what is going on here? does the weblogic pool keep
these things open itself because of caching? If it does, is there some
number that determines how many open restultsets / statements will be
kept open. Is there a setting I can change, or a fix for this issue?
Thanks for the help,
-evan

Answer 1

Joseph Weinstein wrote:
>
furriskey wrote:
Hi,
I tried adding that to the classpath, and it doesn't seem to fix the
problem. However there do seem to be fewer open cursors this time around.
Previously after running one specific request, I got the following
number of cursors for.. user_name, sid ,count(*) num_curs:
STAGE_261 209 7
STAGE_261 184 6
STAGE_261 58 1
STAGE_261 153 1
With that patch, I get the following:
STAGE_261 22 6
STAGE_261 12 1
STAGE_261 60 1
I don't know how much merit these numbers should be given though. The
SQL calls involved seem to be the same as before.Ok, so again, what are the SQLs associated with the open cursors now?
This is looking more and more like and Oracle issue... We may have to duplicate
it with a non-weblogic standalone program. And you're sure the server has the
latest appropriate thin driver in it's classpath ahead of the weblogic.jar? When
the server boots, it prints out it's effective classpath. Make sure it lists the
driver first.
JoeI didn't realise that the oracle driver was embedded in weblogic.jar, I
thought wl read the list of jars in $WL_SERVER_HOME/lib and added them
to the classpath. So I replaced the classes12.zip in that directory with
the latest one. I have tried adding it to the beginning of the
classpath, and verified that to be the case, but still get the issue.
This is the classpath that is starts with:
/export/home/beahome/weblogic700/../user_projects/Staging/70sp1testcon_w_rs.jar:/export/home/beahome/weblogic700/../user_projects/Staging/classes12.zip:/export/home/beahome/jdk131_03/lib/tools.jar:/export/home/beahome/weblogic700/server:/export/home/beahome/weblogic700/server/lib/weblogic_sp.jar:/export/home/beahome/weblogic700/server/lib/weblogic.jar:/export/home/beahome/jdk131_03/lib/tools.jar:/export/home/beahome/weblogic700/server:/export/home/beahome/weblogic700/server/lib/weblogic_sp.jar:/export/home/beahome/weblogic700/server/lib/weblogic.jar:/export/home/beahome/weblogic700/../user_projects/Staging/tslib/startup.jar
Below are the SQL calls that have open cursors. They are a mixture of
calls from our code, and other calls not from our code (the ones against
the dual table.)
SELECT count(u.user_id) , count(a.user_account_id)
SELECT count(u.user_id) , count(a.user_account_id)
SELECT count(u.user_id) , count(a.user_account_id)
SELECT count(u.user_id) , count(a.user_account_id)
SELECT NVL(tu.time_zone_name, ts.time_zone_name) from users u, user_
SELECT NVL(tu.time_zone_name, ts.time_zone_name) from users u, user_
INSERT into sessions (http_session, user_account_id, session_start_dt
SELECT 2 from dual where exists (select 1 from sessions
UPDATE sessions set session_end_dt = GLOBALS.get_time_by_account (use
SELECT 2 from dual where exists (select 1 from sessions
INSERT into sessions (http_session, user_account_id, session_start_dt
SELECT NEXT_DAY('31-MAR-' || TO_CHAR (SYSDATE, 'YYYY'),'SUNDAY' ) + 1
SELECT NEXT_DAY('31-OCT-' || TO_CHAR (SYSDATE, 'YYYY'),'SUNDAY') -7 +
SELECT nvl(:b1,sysdate) from dual      SELECT nvl(:b1,sysdate) from
SELECT NEXT_DAY('31-MAR-' || TO_CHAR (SYSDATE, 'YYYY'),'SUNDAY' ) + 1
SELECT NEXT_DAY('31-OCT-' || TO_CHAR (SYSDATE, 'YYYY'),'SUNDAY') -7 +
SELECT nvl(:b1,sysdate) from dual      SELECT nvl(:b1,sysdate) from
-evan.
>
>
>>
Thanks,
-evan
Joseph Weinstein wrote:
Hi.
Assuming you are running vanilla 70sp1, with no patches, please try this
jar, ahead of all official weblogic stuff in the server's classpath, and let me know
if it solves the problem.
Joe
furriskey wrote:
Thanks Mitesh,
I looked at that bug in metalink, and although that issue certainly
similar to ours it is not in fact the same. We do not see any SQL
strings like:
SELECT count (*) FROM SYS.DBA_PENDING_TRANSACTIONS
in our open cursors list.
The SQL calls in our code that have open cursors are partly from our own
code (and some generic keepalive ones it looks like: "SELECT
nvl(:b1,sysdate) from dual ".) As I said, I checked specific code blocks
in our code and found that while the code explicitly closes the
resultsets/statements/connections in finally blocks, there are still
open cursors with these calls on the system.
I also checked our prepared statement cache size, and it is set to 0.
This is how the admin console reports it anyway, there is no entry in
config.xml for it and the docs on the wl site say the default is 5. I am
assuming that the latter is a typo on their site.
Thanks again,
-evan.
Mitesh Patel wrote:
Hi furriskey!
I found out from oracle metalink that this is oracle thin/oci driver bug.
The bug id is: 3151681 and i believe oracle is looking at it.
Thanks,
Mitesh
furriskey wrote:
We are having a problem where we get the ORA-01000 error after a while
on our servers. We are using wl7.0 sp1 and Oracle 9.2.0.1 with the thin
driver. We are connecting to the db with the weblogic.jdbc.pool.Driver
class.
I've looked in this group and on support but can't find the specific
answer to our problem.
The number of cursors open gradually increases while our application is
running, until we hit the max (700 per session.)
The FAQ on askbea.com says to just increase the number of cursors, but
we already did this and the number keeps growing and growing as the
application runs.
We are closing all resultsets and statements in finally blocks. I have
tested to see which SQL statements are contained within the open cursors
and traced those statements back to code where I was able to verify
beyond doubt that they were being closed correctly.
I have also tried, on our staging server, to use the very latest driver
from oracle for our db version to no avail.
Does anyone know what is going on here? does the weblogic pool keep
these things open itself because of caching? If it does, is there some
number that determines how many open restultsets / statements will be
kept open. Is there a setting I can change, or a fix for this issue?
Thanks for the help,
-evan