Deixe-me adicionar umas coisas aqui fyi : 1. o mais importante de tudo primeiro : nós discutiremos aqui logons NO BANCO, ie, a Auditoria acontecerá ** se ** o usuário final é que loga no banco : há Diversas situações (por exemplo, um POOL DE CONEXÃO, comum em apps web) aonde Não É o usuário que conecta no banco, e sim um dado software/middleware que mantém sempre N conexões de banco ativa e transfere o usuário pra uma delas - Óbvio que nesse caso vc não vai conseguir Auditar pelo banco, no ponto de vista do banc quem está conectado é o middleware
2. não sei se vc sabe mas para usar a auditoria nativa do banco Não basta vc setar o parâmetro audit_trail , vc TEM que especificar o nível de Auditoria , no seu caso com o comando audit connect whenever not successful 3. supondo sempre que 1. não acontece, os usuários conectam Diretamente no banco sim, tanto com AUDIT (a auditoria nativa do banco) quanto com trigger before logon vc poderia obter os logons falhados todos 4. veja nas docs/refs que o parâmetro audit_trail ** aceita ** outras opções, inclusive opções para gerar os registros de audit FORA do banco, o que (em tese) pode poupar espaço no banco E deixar a Auditoria um pouco mais "à prova"de DBAs, dificultando ao DBA (se ele não é sysadmin) alterar/apagar/mexer nos registros de audit 5. se vc optar por ter tabela de auditorias dentro do banco (seja com AUDIT_TRAIL apontando para banco, seja com trigger), Evidentemente vc vai ter que ter um job/rotina programada para compactar/arquivar/remover linhas dessa tabela periodicamente, e/ou quando ela atingir um tamanho x : pode ser um job de banco, um job agendado no SO, uma rotina manual, não importa. Só lembro que vc Não É Obrigado a ter trigger e tabela customizada sua para poder fazer limpeza em regs de audit no banco, a AUD$ ** pode ** sim ser limpa, pode ser criada numa tablespace particular sua... Pesquisa no metalink que vc acha refs sobre isso. Em cima disso : quando ela atende a minha Preferência é por Auditoria nativa (principalmente para que não tenha que 're-inventar a roda'), mas não é o caso aonde seja impossível de auditar via trigger, de forma alguma... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiuru...@...> escreveu > > Boa tarde colegas, > > Estou com uma dúvida quanto a criação de auditoria de logons no meu banco > Oracle de produção.. > > Andei lendo alguma coisa do parametro AUDIT_TRAIL que é nativo do banco de > dados mas fiquei na dúvida se esta seria a melhor forma de armazenar todos os > logons (bem ou mal sucedidos) do banco de dados pelo crescimento da área > sys.aud$ ou se a melhor política seria a criação de uma trigger que insira em > uma tabela as informações dde logon dos usuários. > > O que acham ? > > Se eu habilitar o alter system set audit_trail=db scope spfile, consigo a > gravação de todos os logons, inclusive os que falharam ? Tenho em torno de > 700 acessos diarios.... >
