Obrigado a todos pelas respostas.Sim, ainda existem clientes que são
permissivos com seus ambientes produtivos, em pleno 2018, por razões
várias.Como a maioria dos DBAs, concordo com um antigo colega que dizia que
"produção é vaca sagrada", que não deveríamos nem logar, só se precisássemos,
Roland,
alter system set max_dump_file_size=10;
Ou qualquer outro numero pequeno.
Atc,
Luis Freitas
On Friday, March 9, 2018 1:57 PM, "jlchia...@yahoo.com.br [oracle_br]"
wrote:
Óbvio número dois : esse trace NÃO É ativado sozinho : ALGUÉM
Óbvio número dois : esse trace NÃO É ativado sozinho : ALGUÉM criou uma trigger
de logon, um shell script (disparado por cron ou não), alguém alterou a
aplicação, alguém alterou o parâmetro SQL_TRACE no banco, enfim ALGUÉM ativou
isso - além de identificar QUAIS sessões estão com isso ativo, vc
Veja só : historicamente, o trace de SQL primeiro foi disponibilidado através
do evento 10046, e apenas Depois disso a Oracle oficializou uma API PL/SQL para
ativar o trace de SQL, sendo que essa API atuava como um front-end pro
evento... LOGICAMENTE, só fica registrado na V$SESSIOn e
Abra o trace. No cabeçalho informa dados da sessão.
att
Vitor Jr.
https://www.linkedin.com/in/vitorjr
Em 9 de mar de 2018 12:25, "Roland Martins dadim...@yahoo.com.br
[oracle_br]" escreveu:
>
>
> O problema: O cliente, por algum motivo, ligou trace em1, 2 ou
O problema: O cliente, por algum motivo, ligou trace em1, 2 ou mais sessões no
banco Oracle, e os filesystems estão explodindo.A pergunta: Como identificar
quais das mais de 3000 conexões por nó, tem TRACE ligado ?
Obs.: Na v$session (portanto na gv$session) existe uma coluna chamada
SQL_TRACE,