Iremos analisar cuidadosamente as suas explicações.
Obrigado...
Em Terça-feira, 11 de Novembro de 2014 10:03, "jlchia...@yahoo.com.br
[oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
Blz ?? Antes de responder, observo que ** justamente ** se o ambiente aí é
grande e complexo (no sentido de diversas equipes mexendo, n alterações
publicadas toda semana), é NESSE CASO que a Documentação TINHA que ser
considerada mais importante, saca ? Sei que por conta de desenvolvimento "ágil"
(entre aspas TOTAIS aqui) as primeiras coisas que neguim corta justamente são a
Documentação e a Homologação, aí os poucos minutos "poupados" nisso se
transformam em HORAS depois quando precisa de debug e/ou verificação ou
controladoria.... Corige isso senão vc vai ficar a vida inteira só apagando
incêndio....
Isso dito, a resposta : primeiro falando sobre AUDITORIA, realmente essa é a
única opção se vc quer ter SEGURANÇA, evitar falsos positivos e/ou perda de
dados, pois as outras opções que vamos comentar (como usar a contagem de
modificações da tabela, por exemplo) não são 100% garantidas... Bom, realmente
a AUDITORIA (seja via comando AUDIT, seja via triggers, seja via FGA) implica
em se fazer um pequeno INSERT numa tabela (ou uma pequena gravação, incluir uma
linha, num arquivo-texto) então CLARO que traz consigo algum overhead (óbvio, é
mais custoso fazer alguma coisa do que não fazer :) , mas é algo pequeno, ** EM
ESPECIAL ** se (como é o seu caso) vc só quer auditar os comandos (ie, vc só
quer saber quem/quando fez o SELECT/INSERT/UPDATE/DELETE, ao que entendo vc **
Não ** quer saber quais dados foram
consultados/alterados/inseridos/deletados).... ULULANTEMENTE óbvio que a medida
exata do overhead vc só pode medir no SEU
ambiente, com o SEU hardware, claro, mas tipicamente esse pequeno INSERT de
uma linha a mais devido à auditoria implica isso implica em coisa de um ou dois
segundos a mais para cada comando auditado : um banco que um INSERT único de
uma linha numa tabela pequena leva sensivelmente mais que isso pra mim tá BEM
doente, não tá legal não.... Caberia a vc confirmar se isso é algo passível de
se ter no seu ambiente (de repente o seu ambiente tem SLA/exigências de
performance tão sérias que nem isso é tolerado), e fazer um TESTE PRÁTICO no
ambiente, preferencialmente no ambiente HOMOLOGAÇÃO, que é bem parecido com
produção - vc TEM um ambiente Homologação, né :)
Sobre alternativas : antes de mais nada, para podermos indicar alternativas,
PLEASE nos diga : o que é "tabela não acessada" para vc ? É tabela que não
sofreu realmente NENHUM acesso (ie, nem por query) ou vc quer saber só tabelas
que não sofreram DMLs ? As tabelas foram criadas com a propriedade de
MONITORING ?? Quando vc coleta estatísticas pra elas ? Os SQLs das Aplicações
que acessam as tabelas estão gravados todos dentro do database (em stored
PL/SQLs, como packages ou procedures/functions) ou não ?? Se não estiverem no
database, os SQLs estão todos na Aplicação, ou o usuário pode cismar de fazer
SQLs ad-hoc, por fora ? Vc tem os FONTES da Aplicação, e eles são passíveis de
busca/pesquisa por tabelas ? O ambiente é movimentado (ie, a cada minuto novos
e múltiplos SQLs entram em cache) ou não ? O AWR/ASH está Ativo nesse database,
e vc tem Licença para consultar ?
===>> COM essas respostas, nós poderemos indicar alternativas às opções de
Auditoria, que girariam em torno de : busca por tabelas nos SQLs, utilização da
view DBA_TAB_MODIFICATIONS, contagem de colunas de metadados das tabelas (como
NUM_ROWS), acesso aos dados já coletados do AWR/ASH, e coisas do tipo...
[]s
Chiappa
