Criar processo para auditar sessão bco 10g e 11g

[José Laurindo ChiappaModerador]

Bom, imagino que o que vc quer é ativar o trace quando a sessão loga no banco, sim ?? Sendo isso Sim, a trigger de LOGON existe para automatizar tarefas que vc quer disparar quando uma sessão loga…. O exemplo mínimo seria lgo do tipo :

CREATE OR REPLACE TRIGGER SYS.TGR_ENABLE_TRACE
after logon on database
BEGIN
IF USER = ‘nomedousuárioquevcquermonitorar’ THEN
EXECUTE IMMEDIATE ‘alter session set TIMED_STATISTICS=TRUE’;
EXECUTE IMMEDIATE ‘alter session set STATISTICS_LEVEL=ALL’;
EXECUTE IMMEDIATE ‘alter session set max_dump_file_size=UNLIMITED’;
EXECUTE IMMEDIATE ‘ALTER SESSION SET EVENTS ”10046 TRACE NAME CONTEXT FOREVER, LEVEL 12”’;
END IF;
END;
/

==> Não é obrigatório vc ter os WAITs completos via TIMED_STATISTICS nem deixar o tamanho do dump file unlimited, nem Ativar nível completo de estatísticas de uso (até porque o objetivo é só ter os textos dos SQLs ao que entendi) mas taí o exemplo, pra ser alterado cfrme vc quiser/precisar…

FIQUE CIENTE porém que :

a) estou supondo aqui que vc **** NÃO **** usa nenhum tipo de POOL DE CONEXÃO, e portanto a cada vez que alguém vai conectar no banco um NOVO LOGIN é feito, E as sessões não ficam ‘eternamente’ penduradas…
OBVIAMENTE se houver pool de conexão, shared sessions/MTS ou equivalentes o software de POOLING ao startar já cria n sessões e as vai distribuindo entre os usuários , aí É CLARO que não vai haver logon no banco (as sessões já logaram antes e estão sendo compartilhadas – esse é o OBEJTIVO de um connection pool!!) e PORTANTO essa trigger NÂO FUNCIONARÁ!!! Num caso assim vc VAI ter que apelar pro end-to-end tracing via DBMS_MONITOR, https://www.toadworld.com/platforms/oracle/b/weblog/archive/2014/06/30/tracking-down-a-3-minute-weird-database-performance-issue-with-end-to-end-application-monitoring-tracking-approach e https://dioncho.wordpress.com/tag/end-to-end-tracing/ são exemplos…

b) isso *** VAI *** ter algum custo em termos de PERFORMANCE e de ESPAÇO EM DISCO : o nível exato de intereferência na performance e no gasto de espaço vai DEPENDER de qtdade de sessões e ‘comprimento’ das transações/tempo de duração das sessões entre n outros fatores, mas que VAI TER INTERFERÊNCIA é batata…
Inclusive, o parâmetro LEVEL do evento 10046 é crítico aqui : com ele vc pde indicar se quer wait events e valores de bind variables ou não : se vc quiser só o texto dos SQLs vc pode tentar um LEVEL 2…. Veja http://www.dba-oracle.com/t_10045_trace_events_level_2_4_8_12.htm como ref pros seus testes

c) DE FORMA ALGUMA trace é o melhor e a única maneira pra vc obter apenas a lista de operações que foram feitas no banco : o RDBMS Oracle fornece *** MUITÍSSIMAS OUTRAS *** opções de AUDITORIA, que é ao que entendi seu objetivo… Entre outras opções gratuitas/built-on no RDBMS (já que vc diz que não tem verba pra nada), *** AVALIE *** o comando AUDIT, o Fine-Grainded Audit (via DBMS_FGA) e (*** SE *** vc mantém os logs arquivados por tempo suficiente) a auditoria via mineração de redo logs com LOGMINER : http://www.nocoug.org/download/2008-05/LogMiner4.pdf é um artigo sobre LOGMINER e https://oracle-base.com/articles/10g/auditing-10gr2 mostra um pouco do FGA e do AUDIT…
As *** VANTAGENS *** desses caras é que em princípio devem intereferir MENOS na performance (já que são opções NATIVAS, compiladas em C dentro do RDBMS) e exigem MUITO MUITO MENOS programação por sua parte, e a DESVANTAGEM principal é que são opções FECHADAS, ie, registram e fazem só o mínimo que está Documentado : se vc quiser/precisar de logs a mais não tem como…

[]s

Chiappa