** COMO ** não pode, porque ??? O que te impede de ativar a Auditoria via 
AUDIT e/ou via FGA para TODOS os usuários exceto os internos do banco, assim 
NECESSARIAMENTE PEGANDO de um jeito ou de outro ?? E como eu disse em outra 
msg, a FGA não apenas diz o usuário de banco MAs também diz o usu´pario DE REDE 
que fez a Operação, que é o que se usa via de regra para identificar usuário 
final em ambiente aonde os usuários finais NÃO TEM cada um o seu user de 
banco...

 []s

   Chiappa

--- Em [email protected], Welvis Moretto <welvis_douglas@...> 
escreveu
>
> 
> 
> Claro, Carlos. Ainda bem que a SAP tem isso..
> 
> Entretanto, não posso por uma FGA, ou um AUDIT para rodar em uma tabela SAP, 
> pois não vou saber qual usuário faz tal opração.
> 
> Isso que quis dizer. 
> 
> att,
> 
> 
> ________________________________
>  De: Carlos Alfredo M. Menezes <carlos.menezes@...>
> Para: "[email protected]" <[email protected]> 
> Enviadas: Sexta-feira, 15 de Fevereiro de 2013 17:34
> Assunto: RES: [oracle_br] Re: recuperar todos os Sql de uma Sessão
>  
> 
>   
> Boa tarde, 
> 
> Concordo com os colegas que existem sistemas que não passaram por nenhuma 
> análise de DBA, eu só retiraria o SAP desta listagem, visto que o mesmo é bem 
> completo, tem como rastrear tudo, chegando até o detalhe de mostrar a linha 
> do código fonte que está a instrução SQL, lembrando que o mesmo é um genuíno 
> sistema de três camadas, o usuário nunca irá conectar diretamente na base de 
> dados, quem faz isso são os processos do kernel do SAP. Mais informações obre 
> SAP+Oracle visite: http://scn.sap.com/community/oracle 
> 
> Abraços, 
> 
> Carlos Alfredo 
> 
> De: [email protected] [mailto:[email protected]] Em 
> nome de Welvis Moretto 
> Enviada em: sexta-feira, 15 de fevereiro de 2013 16:02 
> Para: [email protected] 
> Assunto: Re: [oracle_br] Re: recuperar todos os Sql de uma Sessão 
> 
>   
> 
> 
> Sistemazinho! rsrsrs. Chiappa, nem sempre a pessoa que define a arquitetura 
> da aplicação conhece e/ou pede ajuda para um DBA. Isso acontece e muito, pelo 
> menos em sistemas como GEMCO, MasterSAF. SAP (apesar de ter logs de tudo 
> (podendo ser configurado), não tem como fazer uma audit ou habilitar uma FGA, 
> até onde eu estudei o produto que foi bem pouco). E também o sistema que dou 
> suporte conhecido em Curitiba como Projeto PFAT. Enfim, filosofias a parte.  
> 
> Eu já havia tentando desta forma. E o retorno do Sql com o " PREV_SQL_ID" foi 
> o seguinte: 
> 
> begin :id := sys.dbms_transaction.local_transaction_id; end; 
> 
> att, 
> Welvis Douglas 
> 
> ________________________________ 
> De: J. Laurindo Chiappa jlchiappa@...> 
> Para: [email protected] 
> Enviadas: Sexta-feira, 15 de Fevereiro de 2013 16:47 
> Assunto: [oracle_br] Re: recuperar todos os Sql de uma Sessão 
> 
> 
>   
> Continuando um pouco o assunto, SE realmente o teu sistema é tipo aqueles 
> sistemazinhos que (via de regra sem a MENOR JUSTIFICATIVA) usa o mesmo schema 
> pra todos os usuário finais (não seguindo a boa prática de se ter UM usuário 
> de banco para CADA usuário final do sistema, se esses usuários são FINITOS e 
> CONHECIDOS)e portanto vc precisa do usuário de rede para identificar o 
> usuário final, AINDA ASSIM vc pode usar a FGA, veja que na 
> dba_fga_audit_trail nós TEMOS sim o os user ... 
> Apenas CASO por qquer motivo nebuloso ainda assim vc precise de informação 
> extra que o FGA não te dê (talvez as informações de performance do SQL que só 
> ficam na V$SQL, ou coisa do tipo) , eu Sugiro que vc na trigger : identifique 
> a linha correspondente na V$SESSION, que lá vc vai achar duas colunas, a 
> SQL_ID e a PREV_SQL_ID - tenta fazer o JOIN com a V$SQL com um desses 
> valores, um deles deve representar o SQL do DML que acabou de ser 
> Executado... 
> 
> []s 
> 
> Chiappa 
> 
> --- Em [email protected], "J. Laurindo Chiappa" escreveu 
> > 
> > Então : a versão 10g já nos deu a DBMS_FGA (que já nos dá o TEXTO COMPLETO 
> > dos DMLs auditados) JUSTAMENTE para que não tenhamos que acessar a V$SQL, 
> > que não tem (e nunca teve) Integridade alguma, NEM é garantida a ordem de 
> > gravação nela... Pra mim o que vc deve estar vendo aí é a V$SQL sendo 
> > atualizada antes da trigger no 11g, em mudamça ao 10g : se vc quiser pode 
> > tentar abrir um Chamado no Suporte, mas DUVIDO que vão aceitar como BUG, já 
> > que essa ordem ABSOLUTAMENTE não é garantida.... 
> > 
> > []s 
> > 
> > Chiappa 
> > 
> > --- Em [email protected], Welvis Moretto escreveu 
> > > 
> > > 
> > > 
> > > Olá Chiappa, tudo bem? 
> > > 
> > > É uma trigger "FOR EACH ROW". Ela armazena todos os comandos disparados 
> > > pela aplicação em uma tabela. Sendo assim, todos os insert/update/delete 
> > > em um determinada tabela são armazenadas em uma tabela de log. No Oracle 
> > > 10g, ela fazia isso muito bem. Entretanto, no Oracle 11g não faz mais. 
> > > 
> > > Eu não uso a autitoria do Oracle, pois os usuários não são autenticados. 
> > > 
> > > Depois do upgrade, a trigger sempre pega o último comando, no caso o 
> > > proprio sql, conforme apresentado em seu teste. 
> > > 
> > > att, 
> > > Welvis Douglas 
> > > http://br.linkedin.com/pub/welvis-douglas/1a/a69/786 
> > > 
> > > 
> > > 
> > > 
> > > ________________________________ 
> > > De: J. Laurindo Chiappa 
> > > Para: [email protected] 
> > > Enviadas: Sexta-feira, 15 de Fevereiro de 2013 14:33 
> > > Assunto: [oracle_br] Re: recuperar todos os Sql de uma Sessão 
> > > 
> > > 
> > >   
> > > Colega, eu estou aqui com 10g (EE 10.2.0.5 na verdade) e *** NÃO ** 
> > > cheguei nesse seu resultado de "mostrar todos os SQLs da sessão", de ** 
> > > jeito nenhum ** : 
> > > 
> > > 
> > > C:\Windows\system32>sqlplus system/oracle 
> > > 
> > > SQL*Plus: Release 10.2.0.5.0 - Production on Sex Fev 15 13:21:58 2013 
> > > 
> > > Copyright (c) 1982, 2010, Oracle. All Rights Reserved. 
> > > 
> > > Conectado a: 
> > > Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production 
> > > With the Partitioning, Oracle Label Security, OLAP, Data Mining Scoring 
> > > Engine 
> > > and Real Application Testing options 
> > > 
> > > => rodo alguns SQLs ... 
> > > 
> > > system@o10gr2:SQL> select * from dual; 
> > > 
> > > D 
> > > - 
> > > X 
> > > 
> > > system@o10gr2:SQL> select sysdate from dual; 
> > > 
> > > SYSDATE 
> > > -------- 
> > > 15/02/13 
> > > 
> > > system@o10gr2:SQL> SELECT a.sid, a.serial#,A.username, A.OSUSER, 
> > > 2 SUBSTR(A.MACHINE,INSTR(A.MACHINE,'\')+1 ,LENGTH(A.MACHINE)) MAQUINA, 
> > > 3 A.PROGRAM, 
> > > 4 A.TERMINAL, 
> > > 5 B.SQL_FULLTEXT 
> > > 6 FROM V$SESSION A, 
> > > 7 V$SQL B 
> > > 8 WHERE A.SQL_ADDRESS = B.ADDRESS 
> > > 9 and a.sql_hash_value = b.hash_value 
> > > 10 / 
> > > 
> > > SID SERIAL# USERNAME OSUSER MAQUINA 
> > > PROGRAM TERMINAL 
> > > ---------- ---------- ------------------------------ 
> > > ------------------------------ 
> > > ------------------------------------------------- 
> > > --------------- 
> > > ---------------------------------------------------------- 
> > > ---------------- 
> > > SQL_FULLTEXT 
> > > ---------------------------------------------------------- 
> > > 143 60 SYSTEM Win7_Casa\jlchiappa WIN7_CASA 
> > > sqlplus.exe WIN7_CASA 
> > > SELECT a.sid, a.serial#,A.username, A.OSUSER, 
> > > SUBSTR(A.MACHINE,INSTR(A.MACHINE,'\')+1 ,LENGTH(A.MACHINE)) MAQUINA, 
> > > A.PROGRAM, 
> > > A.TERMINAL, 
> > > B.SQL_FULLTEXT 
> > > FROM V$SESSION A, 
> > > V$SQL B 
> > > WHERE A.SQL_ADDRESS = B.ADDRESS 
> > > and a.sql_hash_value = b.hash_value 
> > > 
> > > system@o10gr2:SQL> 
> > > 
> > > Veja que eu NEM SEQUER filteri por SID, yes ?? Siiiiiimmm ???? imho a 
> > > resposta está na Documentação (nosso amigo "Oracle® Database Reference" 
> > > que na entrada da V$SESSION nos indica Claramente : 
> > > 
> > > "... 
> > > SQL_ADDRESS RAW(4 | 8) Used with SQL_HASH_VALUE to identify the SQL 
> > > statement that is currently being executed 
> > > ..." 
> > > 
> > > OU SEJA, essa coluna identifica o SQL ** sendo EXECUTADO **, o cursor que 
> > > está aberto, ok ? Então está se comportando CERTINHO, o SQL que a minha 
> > > sessão estava executando era esse aí da consulta à v$sql... okdoc ? Não 
> > > sei então como vc consegui ver TODOS os SQLs executados na sessão pela 
> > > consulta acima, isso não faz sentido ... 
> > > Não sei se o fato de vc ter numa "trigger" (que pra variar vc não diz 
> > > qual é, como foi criada, nadica) pode interferir ou não, mas Não deveria, 
> > > pela Documentação... 
> > > 
> > > []s 
> > > 
> > > Chiappa 
> > > 
> > > 
> > > --- Em [email protected], Welvis Moretto escreveu 
> > > > 
> > > > Olá pessoal, tudo bem? 
> > > > 
> > > > 
> > > > Eu tinha o seguinte sql rodando em oracle 10g; 
> > > > 
> > > > SELECT    A.OSUSER, 
> > > >            SUBSTR(A.MACHINE,INSTR(A.MACHINE,'\')+1 ,LENGTH(A.MACHINE)) 
> > > > MAQUINA, 
> > > >            A.PROGRAM, 
> > > >            A.TERMINAL, 
> > > >            B.SQL_FULLTEXT 
> > > >          FROM V$SESSION A, 
> > > > 
> > > >               V$SQL B 
> > > >          WHERE A.SQL_ADDRESS = B.ADDRESS 
> > > >            and a.sql_hash_value = b.hash_value 
> > > >           AND  A.SID = (SELECT SID FROM V$SESSION WHERE AUDSID = 
> > > > USERENV('SESSIONID')); 
> > > > 
> > > > Esta query pegava todos os comandos sql executado naquele sessão. 
> > > > insert, updates e deletes.  Entretanto, na versão 11g r2 ele e traz o 
> > > > proprio sql. 
> > > > 
> > > > Já tentei pegar estas informações na view v$open_cursor, v$session e 
> > > > v$sql. Hora traz a informação correta, e hora não tras. Alguém já 
> > > > passou por isso? 
> > > > 
> > > > Este sql está dentro de uma trigger para gravação de Log. 
> > > > 
> > > > Obrigado pela atenção. 
> > > > 
> > > > att, 
> > > > Welvis Douglas 
> > > > http://br.linkedin.com/pub/welvis-douglas/1a/a69/786 
> > > > 
> > > > [As partes desta mensagem que não continham texto foram removidas] 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > [As partes desta mensagem que não continham texto foram removidas] 
> > > 
> > 
> 
> [As partes desta mensagem que não continham texto foram removidas] 
> 
> 
>  
> 
> [As partes desta mensagem que não continham texto foram removidas]
>


Responder a