Não posso dizer o que está causando o problema de cursores abertos máximos, mas digo como encontrar a causa identificando as sessões relacionadas e a instrução SQL usando
GV$OPEN_CURSOR . Se você tiver sorte, poderá encontrar o problema imediatamente com uma consulta simples que conta o número de cursores abertos por sessão. Há muitas colunas na consulta abaixo, use um IDE para que você possa navegar facilmente por todos os dados. Na minha experiência, apenas olhar para colunas como USER_NAME e SQL_TEXT é suficiente para identificar o culpado.
select count(*) over (partition by inst_id, sid) cursors_per_session, gv$open_cursor.*
from gv$open_cursor
order by cursors_per_session desc, inst_id, sid;
Lembre-se de que haverá muitas consultas estranhas nessa visualização que podem tornar as contagens maiores do que o previsto. Com todas as consultas recursivas e em cache, não é incomum que uma sessão "chata" use 50 cursores. Você está procurando sessões com centenas de cursores abertos. (A menos que alguém tolamente baixou o valor do parâmetro abaixo do padrão.)
Infelizmente,
GV$OPEN_CURSOR não contém dados históricos, e esses problemas podem começar e parar rapidamente se houver uma exceção dentro de um loop apertado que abre rapidamente muitos cursores. O bloco PL/SQL abaixo é executado até encontrar uma sessão com um grande número de cursores abertos, armazenar os dados e sair. Este bloco PL/SQL é caro e vai usar uma sessão inteira de processamento esperando o momento certo, então use-o apenas uma vez para encontrar o problema. --Create table to hold the results.
create table too_many_cursors as
select 1 cursors_per_session, gv$open_cursor.*
from gv$open_cursor
where 1 = 0;
--Write the open cursor data when a session gets more than N open cursors.
declare
v_open_cursor_threshold number := 50;
v_count number;
begin
--Loop forever until the problem is found.
loop
--Count the largest numbe of open cursors.
select max(the_count)
into v_count
from
(
select count(*) the_count
from gv$open_cursor
group by inst_id, sid
);
--If the threshold is reached, write the data, commit it, and quit the program.
if v_count >= v_open_cursor_threshold then
insert into too_many_cursors
select *
from
(
select count(*) over (partition by inst_id, sid) cursors_per_session, gv$open_cursor.*
from gv$open_cursor
)
where cursors_per_session >= v_open_cursor_threshold;
commit;
exit;
end if;
end loop;
end;
/
--Your problem should now be in this table:
select * from too_many_cursors;
Se você quiser testar o monitoramento, você pode usar o bloco PL/SQL abaixo para abrir um grande número de cursores.
--Open a large number of cursors in and wait for 20 seconds.
--(Done by creating a dynamic PL/SQL block with many "open" commands with a "sleep" at the end.
declare
v_number_of_open_cursors number := 200;
v_declarations clob;
v_opens clob;
v_sql clob;
begin
for i in 1 .. v_number_of_open_cursors loop
v_declarations := v_declarations || 'v_cursor'|| i ||' sys_refcursor;' || chr(10);
v_opens := v_opens || 'open v_cursor' || i || ' for select * from dual;';
end loop;
v_sql :=
'declare '||chr(10)||v_declarations||chr(10)||
'begin'||chr(10)||v_opens||chr(10)||
'dbms_lock.sleep(20);'||chr(10)||'end;';
--Print for debugging.
--dbms_output.put_line(v_sql);
execute immediate v_sql;
end;
/
