Oracle 10g: OPEN_CURSORS y SHARED_OPEN_CURSORS

Pasos que sigue Oracle para procesar una consulta:
1) Validación Sintáctica
2) Validación Semántica
3) Optimización
4) Generación del QEP (Query Execution Plan)
5) Ejecución del QEP (Query Execution Plan)
En algunos entornos nos podemos encontrar con aplicaciones que realizan ciertas consultas (y digo consultas) de forma muy reetiva de forma continua. Cuando el catálogo es muy amplio, continuo e inevitable debemos tener en cuenta dos parámetros de inicialización de la base de datos: open_cursors y session_cached_cursors.
Open_cursors nos permite establecer el límite de cursores por sesión y su seteo es muy directo. Si se necesitan 1000 y no hay nada que optimizar pues 1000 pondremos. En cambio Session_cached_cursors es algo más complejo y requiere analizarse en base al número máximo de cursores (open_cursors) y la cantidad actual de cursores que se mantienen en "cache" actualmente.
Consulta:
select
'session_cached_cursors'  parameter,
lpad(value, 5)  value,
decode(value, 0, '  n/a', to_char(100 * used / value, '990') || '%')  usage
from
( select
    max(s.value)  used
  from
    sys.v_$statname  n,
    sys.v_$sesstat  s
  where
    n.name = 'session cursor cache count' and
    s.statistic# = n.statistic#
),
( select
    value
  from
    sys.v_$parameter
  where
    name = 'session_cached_cursors'
)
union all
select
'open_cursors',
lpad(value, 5),
to_char(100 * used / value,  '990') || '%'
from
( select
    max(sum(s.value))  used
  from
    sys.v_$statname  n,
    sys.v_$sesstat  s
  where
    n.name in ('opened cursors current', 'session cursor cache count') and
    s.statistic# = n.statistic#
  group by
    s.sid
),
( select
    value
  from
    sys.v_$parameter
  where
    name = 'open_cursors'
) ;

Ejemplo:
PARAMETER              VALUE           USAGE
---------------------- --------------- -----
session_cached_cursors   100            100%
open_cursors             300             57%
Si con el valor actual observamos que el uso es del 100% podemos incrementar de forma moderada el parámetro session_cached_cursors y observar el resultado. Siempre que este por debajo estamos reutilizando todos los que son posibles y estamos optimizando al evitar el "hard parse" de la consulta reduciendo el uso de cpu. Pero cuidado, tampoco vale igualar este parámetro al número máximo de cursores ya que no es oro todo lo que reluce y cuanto más grande sea este valor mayor memoria estamos consumiendo y en servidores cortitos de harware puede pasar factura por otro sitio.