Colega, antes de sair fazendo, imho vc ** tem ** que saber Exatamente a necessidade, para que será usado, enfim... Se é para Auditoria, eu recomendaria fortemente que vc usasse as opções built-in de Auditoria e simplesmente IGNORASSE as gambis com trigger, pois entre outros fatores :
- via de regra triggers interferem mais FORTEMENTE em performance do que a Auditoria nativa - nós NÂO temos uma trigger de DML (insert/update/delete) a nível de database, aí vc TERÁ que ter uma trigger para cada tabela de cada schema que vc quer "auditar" - afaik provavelmente vc precisará dar GRANTs de consultas em tabelas internas (principalmente V$SESSION e V$SQL), já que há casos em que as built-ins de captura de eventos de sistema e similares (como a ORA_SQL_TEXT, que seria a de seu interesse no caso) não são populadas e/ou não podem ser usadas em triggers de DML : http://topdataway.blogspot.com.br/2008/11/get-sql-using-orasqltxt-via-trigger.html nos fala sobre isso... E há um ponto importante : se o database for 11g (R2,afaik), em a Auditoria nativa sendo setada para 'DB' o texto e os binds já são Automaticamente capturados na AUD$, o que elimina qquer necessidade de manipulação via trigger.... Se o seu database for 10g ou superior, sempre há também a possibilidade de usar FGA (Fine-Grainde Audit), essa built-in já captura o texto do SQL, já que seu db é 11g : http://mportes.blogspot.com.br/2005/05/audit-trail-fga-fine-grained-audit-10g.html é um exemplo antigo mas ainda funcional .... E claro, se a Audit for temporária, vc sempre tem a chance de Ativar um trace de SQL, via logon trigger ou quetais... => Então a sua resposta é : Entenda a necessidade, Analise se é possível/viável usar as rotinas built-in (POUPANDO tempo/esforço e muito provavelmente intereferindo menos com performance), E se não for só então, muito de má-vontade, vc parte pras triggers, testando se no seu caso as built-ins de captura de eventos atendem, experimente pegar o SQL_ID numa trigger BEFORE statement, é por aí que vão ser as gambis.... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Marcos de Moura Gonçalves <mgmarcos@...> escreveu > > Olá Srs, > > Me solicitaram a criação de uma trigger disparada por eventos DML que > grave o SQL que ocasionou o disparo da trigger. Já tinha feito algo > parecido no Oracle 10g, e lembrava que bastava fazer o join entre > v$session e v$sql na coluna sql_id para encontrar o SQL realizado. > Entretanto essa demanda é para um banco 11g, e pelo que reparei houve > uma mudança na informação gravada na v$session: ele guarda o sql_id > do próprio SELECT realizado na v$session... Experimentei também a > junção através da coluna prev_sql_id, mas me traz outro SQL que não o > que disparou a trigger. Outra alternativa que tentei foi utilizar a > função ORA_SQL_TXT, muito utilizada normalmente em exemplos de quem > quer fazer auditoria de comandos DDL. Entretanto, pelo menos nas > minhas tentativas em triggers de UPDATE, essa função não trouxe nada > (li em algum forum que essa função estaria funcionando no 11g apenas > para triggers de eventos de sistema, e não DML). Estou pesquisando > alternativas ainda sem sucesso. Alguém tem alguma idéia? > > Obrigado, > > Marcos de Moura Gonçalves >
