none
Trigger - Auditoria / SysProcesses RRS feed

  • Pergunta

  • Olá a todos,

    Tenho a intenção de desenvolver uma trigger para auditar vários bancos em um instancia (SQLEXPRESS ou MSDE).
    Vi que a tabela sysprocesses mostra as operações que estão ocorrendo no banco. Porém, eu preciso demonstrar o comando completo executado. Não tenho visto outra opção senão fazer uma trigger para cada tabela de cada banco. Vocês tem alguma outra idéia?
    Agradeço a atenção de vocês.

    segunda-feira, 1 de setembro de 2008 14:36

Todas as Respostas

  • Bom Dia,

     

    Ainda que você crie uma trigger em cada banco de dados, ele não é capaz de capturar o comando completo. Ela dispõe dos dados afetados nas tabelas INSERTED e DELETED mas não dispõe do comando que as afetou.

     

    A Sysprocesses em conjunto com algumas funções é capaz de demonstrar o comando completo, mas isso não é garantido para 100% dos casos e de qualquer forma, você não conseguiria criar uma trigger na sysprocesses para que assim que surgisse um SPID você capturasse o comando.

     

    As alternativas para lhe atender são poucas e considerando que você está usando MSDE / SQL Server Express receio que possua uma forte restrição de custos o que já descarta a opção de adquirir uma ferramenta de terceiros (Log Explorer, Log Rescue, etc).

     

    Uso do SQL Profiler

    Você pode usar o Profiler para logar todos os comandos disparados no servidor e salvá-los em uma tabela. Além de diminuir sensivelmente o desempenho, você precisará de uma edição adicional do SQL Server a parte (Developer, Workgroup, etc). Se tiver restrições de custo, essa opção é descartada

     

    Ativar o Default Trace

    O SQL Server (qualquer edição) possui uma opção de trace padrão. É um arquivo TRC que pode ser lido pelo Profiler posteriormente. Em todo caso, o arquivo irá crescer e onerar o desempenho e você terá uma administração adicional sobre esse arquivo.

     

    Auditar na aplicação

    Em sua aplicação, antes de submeter o comando, grave-o em algum local.

     

    [ ]s,

     

    Gustavo

    segunda-feira, 1 de setembro de 2008 15:06
  • outra opcao e adquirir uma ferramenta de auditoria como o log explorer, ou outras da redgat, etc. veja + em:

     

     

     

    http://www.lumigent.com/products/log_explorer.html

     

    abs

    segunda-feira, 1 de setembro de 2008 16:29
  • Maia,

     

    Particularmente eu gosto de trabalhar com o Profiler, e em algumas aplicações aqui na empresa utilizamos alguns arquivos que ficam embutidos dentro da aplicação para armazenar todos as operações.

    segunda-feira, 1 de setembro de 2008 17:15
  • Oi Jr.

     

    Acho que essa implentação não é a melhor, mas dadas as limitações talvez seja a única possível. Haverá sempre o Overhead de gravar essas informações, mas há o benefício posterior de poder visualizá-las e auditá-las. Talvez o grande desafio mesmo seja definir o que coletar.

     

    [ ]s,

     

    Gustavo

     

    segunda-feira, 1 de setembro de 2008 17:36
  • Maia,

     

    Isso mesmo, talvez o grande desafio será definir uma forma para coletar estes dados!!!!

     

    segunda-feira, 1 de setembro de 2008 18:37
  • Gustavo, Junior e Maia.

    Primeiro gostaria de agradecer a colaboração de vocês.
    O grande problema é que minha intenção é gravar os comandos executados fora da aplicação. Ou seja, é uma forma de fornecer garantia para o cliente de que o banco continuaria integro se não houver logs na tabela de operacoes (tabela esta que seria criada).
    Portanto, acredito que o profiler poderia resolver, mas não seria muito simples de recuperá-lo e o custo de cada operação seria mais alto talvez que a trigger. Pelo que concluo ao lê-los é que será realmente criar uma trigger por tabela. O mais legal é que tenho aproximadamente 700 tabelas. Acho que o jeito é fazer um gerador de scripts.
    Mais alguma sugestão?
    Sou todo ouvidos.
    obrigado desde então.

    terça-feira, 2 de setembro de 2008 13:16
  • Olá Mauro,

     

    A idéia da trigger é interessante. Quanto a quantidade, isso não é um limitador visto que é possível automatizar sua criação. O problema é que a trigger não é capaz de gravar o comando. Você poderá ter a imagem antes e depois (INSERTED e DELETED) mas não poderá ter na trigger o comando que fez a alteração. Se o "antes" e o "depois" lhe for suficiente, então a trigger atende. Se a auditoria deseja chegar em nível de comando, máquina, usuário, etc receio que a trigger não seja factível.

     

    Até onde sei, o SQL Server 2008 dispõe de recursos de auditoria mais robustos e ele também possui a edição Express. Poderia ser o caso de estudar essa edição e os recursos de auditoria (se estiverem disponíveis) para um possível upgrade da sua solução.

     

    [ ]s,

     

    Gustavo

    terça-feira, 2 de setembro de 2008 13:32
  • Maia,

     

    No SQL Server 2008, foi implementado um novo conceito e objeto de auditoria chamado Audit!!!

     

    Que permite realizar todo processo de auditoria a nível de banco de dados, tables e até mesmo no servidor SQL Server.

     

    terça-feira, 2 de setembro de 2008 13:45