> First check your app for code that opens cursors but doesn't close them.
I can't find any yet, though it is very complex. I will keep searching...
> If you can't find any, it could be that open_cursors is set too low for your workload. Assuming the app closes cursors correctly, there's no overhead to setting this to a high value.
But why would cursors stack up like this to breach the limit? There is only PL/SQL in use. I have done a scan for 'OPEN' and one for 'DBMS_SQL.OPEN_CURSOR' and examined the situations, but nothing appears awry. I don't see how 51 cursors can possibly be left open at once. (50 being our value for max_open_cursors).
If PL/SQL always manages implicit
cursors correctly, and automatically closes explicitly
opened cursors (once out of scope of their definition), how is it even possible to breach the limit?
If all cursors are implicit, then surely the number open at any one moment in time is at most 1 ? (Unless they employ functions to return values into columns using separate SQL inside the functions, but even then it's only ever going be three, four, five or six).
With explicitly opened cursors, I appreciate they can become nested.
> Either way, checking v$open_cursor will help you identify what your open cursors are.
WHERE CURSOR_TYPE = 'OPEN'
AND SID = sys_context('USERENV','SID');
There's 6 different cursor types returned,
PL/SQL CURSOR CACHED
SESSION CURSOR CACHED
DICTIONARY LOOKUP CURSOR CACHED
BUNDLE DICTIONARY LOOKUP CACHED
Am I only interested in 'OPEN' ?
February 19, 2021 - 2:11 pm UTC
Every SQL statement has a cursor. If you have SQL inside a trigger, the parent statement is still active until the trigger completes. So you're going to have (at least) 2 open cursors:
- The triggering statement
- The SQL statement inside the trigger
There may also be various internal (OPEN-RECURSIVE) statements - those the database runs on your behalf to parse SQL, run background tasks such as auditing, etc.
You're interested all cursors with an OPEN type: OPEN, OPEN PLSQL, & OPEN-RECURSIVE.