Ah, um detalhe adicional : além de tudo q foi falado, cfrme http://www.oracle-home.ro/Oracle_Database/Tuning/Statspack_utility.html e a Documentação Oracle, na hora que vc coleta os snapshots pro statspack, vc ESCOLHE qual nível de estatísticas vc quer - Evidentemente, se vc usou um nível baixo, vc NÂO vai ter as infos de SQL, de row locks, latches, etc...
[]s Chiappa --- Em [email protected], "J. Laurindo Chiappa" <jlchiappa@...> escreveu > > Blz ? Acho que vale a pena colocar uns coments adicionais : > > => dentro do redo log **** NÃO *** temos o texto exato do SQl, portanto o que > vc obtém com o logminer *** NÃO É *** o texto do SQL exato que foi disparado, > e sim uma versão Equivalente : dependendo da necessidade (digamos, se vc quer > localizar o SQL emitido dentro do aplicativo, fazer Tuning, etc) isso pode > ser problema... Por exemplo : > > > SCN CSCN TIMESTAM COMMIT_T THREAD# LOG_ID XIDUSN > XIDSLT XIDSQN PXIDUSN PXIDSLT PXIDSQN RBA > ---------- ---------- -------- -------- ---------- ---------- ---------- > ---------- ---------- ---------- ---------- ---------- ------- > OPERATION OPERATION_CODE SQL_REDO > -------------------------------- -------------- > --------------------------------------------------------------------------------------- > SQL_UNDO > > --------------------------------------------------------------------------------------------------------------------------------------- > 1745395 28/05/12 1 87 5 > 40 638 5 40 638 > START 6 set transaction read write; > > > > 1745418 28/05/12 1 87 5 > 40 638 5 40 638 > INSERT 1 insert into > "SCOTT"."DEPT"("DEPTNO","DNAME","LOC") values ('12','depto 12',NULL); > delete from "SCOTT"."DEPT" where "DEPTNO" = '12' and "DNAME" = 'depto 12' and > "LOC" IS NULL and ROWID = 'AAANm5AAFAAAAAMAAF'; > > (ou seja, vc PERDE a informação de datatypes e bindings, que por vezes é > CRUCIAL para tuning, pra ver se estão sendo usados os Histogramas, para > localizar na Aplicação qual programa está emitindo o SQL, etc - então Tuning > em cima de informações do logminer não acho que vai ser algo preciso) > > => falando de planejamento de tendências e coisas do tipo, imagino que vc > poderia fazer alguma coisa básica, tipo identificar um histórico de quais > tabelas estão sendo mais inseridas/updateadas/deletadas,qtdade mas há outras > fontes e possibilidades para isso também > > => granularidade da Auditoria : o redo é gerado para todos os SQLs, > independente se é uma tabela "importante" ou não, enquanto o FGA permite que > vc audite apenas alguma(s) coluna(s) de tabela(s), ou mesmo uma condição , > tipo auditar apenas alterações no SALARIO aonde SALARIO > 10000, etc > > => awr/statspack *** não ** "fazem log", não Auditam nada : a questão com > eles é que eles capturam AMOSTRAS da V$SQL, V$SESSION e correlatas, que > funcionam como retratos dos caches (de dados, de SQL, etc) , então num banco > bem ativo é COMUM vc perder SQLs no awr/statspack porque eles já saíram do > cache durante o intervalo das amostras.... > > => finalmente, sobre o Statspack : é verdade que o Standard é restrito > (restrito é até eufemismo aqui, tem que ganhar muita coisa pra chegar a ser > considerado restrito), mas afaik o Statspack, como eu disse acima, faz coleta > das V$ 'comuns' e 'livres' do sistema, tal como V$SQL, V$SESSION, etc, o que > Absolutamente Não Demanda licença alguma, deveria funcionar normalmente : > então, se não está vindo a informação completa, acho muito mais provável que > tenha algum ponto faltante (como TIMED_STATISTICS, por exemplo), que o > usuário usado pro report de statspack não tinha privs corretos e/ou que se > esteja gerando ou os snapshots ou o report de statspack erradamente.... > > > []s > > > Chiappa > > --- Em [email protected], "ederson2001br" <ederson2001br@> escreveu > > > > Alô Wadson, > > > > Eu uso o Logminer desde a versão 9, sempre que preciso "auditar" algum > > procedimento "duvidoso" no banco, bem como avaliar os estragos causados por > > algum processo mau-comportado. > > > > O uso do Statspack com esta intenção, vc consegue retornar os sqls que o > > banco executou, juntamente com os planos de execução (dentro da janela do > > cache), mas não consegue retornar os valores bind. Atualmente, trabalho com > > bases 10g Standard com RAC em ASM. Usando o statspack, sempre analisamos os > > sqls rodados e seus planos de execução, sempre atuando na melhoria de > > performance quando surge um sql lento ou quando algum módulo foi modificado > > ou quando o custo/tempo de resposta se elevaram. > > > > Sobre os pontos levantados no seu email: > > 1 Localizar um corrupção lógica devido a erros de aplicação > > R-> Como o banco armazenou o histórico da execução no archive, vc terá o > > horário, o usuário, o terminal, o comando executado (redo) e até o sql que > > desfaz (undo), para operações de INSERT, UPDATE e DELETE. No Logminer, > > observe que não loga selects, daí a importância de usar o Statspack/Awr que > > faz o log também de select. Statspack não diz "quem" rodou, mas informa "o > > quê e quando". O Logminer diz "quem", "quando" e "de onde". > > > > 2 Determinar que ações devem ser tomadas para executarmos um recover > > granular da transação: > > R-> quando identificado o grupo de sqls de uma operação, pode-se usar a > > coluna UNDO para recuperar/desfazer aquela operação, uma recuperação > > granular de dados que "cirurgicamente" repara aquele dano sem a necessidade > > de voltar um backup e perder outras transações em nome da consistência de > > dados, basta desfazer a operação completa. Curiosidade: se uma transação > > faz um "delete sem cláusula where", no archive fica anotado o "delete" de > > cada linha com seu respectivo rowid, tantas vezes quantas forem as linhas > > atingidas pela operação, que registra mesmo PROCESS_ID, sendo possível > > identificar as linhas daquele delete em meio a outras operações que o banco > > rodou no mesmo período, além do comando insert com cada valor de cada > > atributo da linha deletada (para desfazer o delete). > > > > 3 Otimização de performance e plano de capacitação através da análise de > > tendencias. > > R-> Não entendi a intenção do autor da frase, mas para otimização de > > performance prefiro o statspack ou o bom e velho trace 10046 + tkprof > > > > 4 Pos auditoria. > > R-> Aqui o Logminer é campeão, pois vc terá registro da operação de DML, > > bastando o banco estar em archivelog. Não precisa triggers e nem feature > > paga, lembrando ainda que não "enche" tabela em nenhum schema, basta ter os > > archivelogs gravados em disco, podendo-se voltar um backup de archives a > > qualquer momento (e para qualquer diretório e sem a necessidade de recover > > de base) e analisar estes logs. Em conjunto com o demais logs (alert, > > sqlnet, etc), tem muito material para um "forense digital" ... > > > > > > > > Ederson Elias > > DBA Oracle > > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 > > > > > > --- Em [email protected], Wadson Ramon <wramon@> escreveu > > > > > > Olá pessoal achei muito interessante a resposta do colega Ederson, > > > principalmente sobre o comentário a respeito do LogMiner, Atualmente > > > trabalho com a Versão Standard do 11 que tem recursos limitados. > > > Pesquisando sobre o Logminer achei em um blog alguns > > > comentários interessantes sobre o LogMiner que postei abaixo da mensagem. > > > Sobre as afirmações do colega do blog o LogMiner consegue realmente > > > dar subsídios para as questões 1,2,3,4, postadas abaixo?. > > > E até que ponto o LogMiner se assemelha ao Statspack , tentei utilizar > > > o Statspack com Ora cle RAC Standart 11g e o relatório gerado saiu com a > > > maioria dos campos vazios e com pouca de informação. > > > > > > ---- > > > Log Miner | Muito além do FlashBack > > > Filed under: > > > Uncategorized<http://aguimaraes.wordpress.com/category/uncategorized/> > > > > > > agleite @ 5:20 pm > > > > > > O Oracle LogMiner é uma ferramenta que permite consultas a arquivos de > > > redo > > > log's online e archives através de SQL. Os arquivos de redo contém o > > > histórico da atividades em um banco de dados. > > > > > > Entre os beneficios do LogMiner temos: > > > > > > 1 Localizar um corrupção lógica devido a erros de aplicação > > > > > > 2 Determinar que ações devem ser tomadas para executarmos um recover > > > granular da transação > > > > > > 3 Otimização de performance e plano de capacitação através da análise de > > > tendencias. > > > > > > 4 Pos auditoria. > > > > > >
