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 [email protected]> 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]
