Discussion:
ora-01000 and dbms_session.set_edition_deferred(:1);
Chris Stephens
2018-09-07 16:10:54 UTC
Permalink
Oracle 12.2.01 running on Oracle Linux 7.5.

open_cursors = 700

5 node RAC system but we only have a single instance running at the moment.

Client program makes use of cx_Oracle v5. v6 complains about their code not
closing cursors. That's obviously the root of the issue and will need to be
fixed.

However, for every session i have observed hitting the 700 open cursor
limit, the only SQL_ID bound to all of the open cursors is
"dbms_session.set_edition_deferred(:1);". There is nothing in the code that
explicitly runs that statement.

I'm not even sure what question(s) to ask other than has anyone else seen
similar issues related to code that doesn't properly manage session
cursors? We know what the long(ish)-term solution is but are there any
suggestions on how to deal with the problem while we work to actually fix
it? I'm hesitant to increase open_cursors to buy more time but I can't
really think of anything else at the moment.

chris
Chris Stephens
2018-09-07 17:25:09 UTC
Permalink
i should also mention that these session are all connecting to same db
resident connection pool. when i look at what each session w/ large number
of open cursors is currently doing, event is "pool server timer". still
trying to find exactly what that means.
Post by Chris Stephens
Oracle 12.2.01 running on Oracle Linux 7.5.
open_cursors = 700
5 node RAC system but we only have a single instance running at the moment.
Client program makes use of cx_Oracle v5. v6 complains about their code
not closing cursors. That's obviously the root of the issue and will need
to be fixed.
However, for every session i have observed hitting the 700 open cursor
limit, the only SQL_ID bound to all of the open cursors is
"dbms_session.set_edition_deferred(:1);". There is nothing in the code that
explicitly runs that statement.
I'm not even sure what question(s) to ask other than has anyone else seen
similar issues related to code that doesn't properly manage session
cursors? We know what the long(ish)-term solution is but are there any
suggestions on how to deal with the problem while we work to actually fix
it? I'm hesitant to increase open_cursors to buy more time but I can't
really think of anything else at the moment.
chris
Loading...