Oracle: Cursores abiertos

En más de una ocasión nos hemos encontrado con alguna aplicación con errores o fallos en el código que no cierran adecuadamente los cursores abiertos contra la BBDD, para determinar tanto el número como las sesiones y máquinas causantes de este problema que puede "tirarnos" la BBDD tenemos la  siguiente nota extraída de Oracle que reproducimos al final.

Es altamente recomendable monitorizar con Zabbix estos valores de forma sencilla para determinar problemas antes de que ocurran, sobre todo en las fases iniciales de producción de los proyectos.


A partir de la nota podemos obtener queries útiles como las siguientes:

Query Genérica para ver los cursores abiertos por sesión, aplicación, máquina y cuenta

select  a. USER_NAME , a.sid , a. sql_text, p.PROGRAM, s. MODULE, s.MACHINE, count( *) as "OPEN CURSORS"

from v$open_cursor a,

     v$session s,

     v$process p

where s.SID = a.SID

  and s.paddr = p.addr

Group by a. user_name, a.sid, p.PROGRAM, s. MODULE, a. sql_text,s. MACHINE

Queries y cursores abiertos por query

select sid , sql_text, count( *) as "OPEN CURSORS" , USER_NAME

from v$open_cursor

Group by sid, sql_text, user_name

Sesiones con cursores abiertos

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;

Cursores abiertos y máximo definido en parámetro de BBDD

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;

Troubleshooting Open Cursor Issues

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:

1. Login to the SYS schema (or any schema with DBA privilege) of the database.
2. 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;
   
   ct 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.
3. 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 ($);
   

   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.
4. 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.