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 oracle_br@yahoogrupos.com.br, 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. >
