Similar to any application that uses Oracle Database as backend repository, Oracle Identity Manager runs several SQL statements. For every SQL statement execution in Oracle Database, certain area in the memory is allocated. Oracle PL/SQL allows you to name this area. This private SQL area is called context area or cursor. These cursors take up space in the shared pool, which is essential memory component of Oracle Database, specifically in the library cache. To keep a renegade session from filling up the library cache or clogging the CPU with millions of parse requests, the OPEN_CURSORS database parameter must be set to limit the cursors.
The OPEN_CURSORS parameter sets the maximum number of cursors that each session can have open, per session. For example, if the value of OPEN_CURSORS is set to 1000, then each session can have up to 1000 cursors open at one time.
Sometimes, the number of cursors in the database exceeds the maximum limit, and as a result, the following error is thrown:
java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1 ORA-01000: maximum open cursors exceeded ORA-00604: error occurred at recursive SQL level 1
To troubleshoot the open cursors issue:
Login to the SYS schema (or any schema with DBA privilege) of the database.
Find out the session that is causing the error by using the following SQL statement:
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' and s.username is not null;
The output displays the details of all sessions. You can see the maxed out session IDs.
To display which queries are causing maxing out of open cursors, run the following SQL statement:
select sid ,sql_text, count(*) as "OPEN CURSORS", USER_NAME from v$open_cursor where sid in ($SID);
The top queries that are opening maximum cursors and are not closing subsequent cursors gracefully are displayed.
If some code is running above SQL queries, then check that Java Statement, Resultset, or connection are closing properly or not if they have access to the code. If the code is not closing the connections, then close all the open connections properly so that you can save memory leaks in the code and save database memory.
To verify if you have set the value of the OPEN_CURSORS parameter high enough, monitor v$sesstat for the maximum opened cursors current, as shown:
SELECT max(a.value) as highest_open_cur, p.value as max_open_cur FROM v$sesstat a, v$statname b, v$parameter p WHERE a.statistic# = b.statistic# and b.name = 'opened cursors current' and p.name= 'open_cursors' group by p.value;
If your sessions are running close to the limit, then increase the value of the OPEN_CURSORS parameter.