Artigos Banco de Dados DDL Triggers

P>

Capa SQl 33

Clique aqui para ler todos os artigos desta edição

DDL Triggers

Saiba como usar este novo recurso do SQL Server 2005 para realizar auditoria nos objetos

 

     Sempre fui questionado por muitos analistas e desenvolvedores se no SQL Server 2000 existe a possibilidade de saber quem alterou a estrutura de uma tabela ou até mesmo a excluiu. Infelizmente no SQL Server 2000 as duas opções que temos para capturar esses eventos são utilizar ferramentas de terceiros, como, o Log Explorer

da Lumigent ou o ApexLog da ApexSQL Software, ou ainda deixar um profiler executando 24 horas por dia no servidor. O profiler é uma ferramenta gráfica do SQL

Server que permite aos administradores monitorar tudo que é executado em uma instância do SQL Server, podendo salvar os dados capturados em um arquivo ou tabela. A ferramenta pode ser encontrada no caminho Iniciar à Programas à Microsoft SQL Server à Profiler.

     A boa notícia é que no SQL Server 2005 essa auditoria pode ser realizada de forma simples e fácil, através da utilização de uma das mais interessantes features  adicionadas ao Transact-SQL do SQL Server 2005 – as DDL Triggers (triggers de linguagem de definição de dados). Uma descrição sobre triggers está apresentada na Nota 1.

     Ao longo deste artigo veremos quais são as principais características e diferenças relacionadas às triggers de DDL e as triggers de DML. Veremos também dois exemplos bem detalhados sobre como criar e utilizar as triggers de DDL para capturar qualquer evento que possa criar, alterar ou excluir um objeto seja no nível banco de dados ou servidor. Por exemplo, a exclusão de uma tabela ou um login.

 

Nota 1. Trigger

     Trigger é um tipo especial de stored procedure que é disparada automaticamente quando um evento de linguagem de manipulação de dados (DML) ocorre em uma tabela do banco de dados. A partir do SQL Server 2005, também temos as triggers de DDL, as quais são disparadas na ocorrência de um evento de linguagem de definição de dados (DDL).

 

Triggers de DML vs. Triggers de DDL

 

     Assim como as triggers de DML (triggers de linguagem de manipulação de dados), as triggers de DDL são disparadas em resposta a um evento. No entanto, diferente

das triggers de DML que são disparadas em resposta aos eventos de manipulação de dados INSERT, UPDATE e DELETE, as triggers de DDL são disparadas em resposta aos

eventos de definição de dados CREATE, ALTER e DROP, permitindo capturar qualquer evento que possa criar, alterar ou excluir um objeto tanto no nível banco de dados

quanto no nível servidor.

     Uma outra grande diferença é que enquanto nas triggers de DML temos as INSTEAD OF triggers – que são disparadas antes do evento ocorrer, as triggers de DDL somente são disparadas após a ocorrência do evento. Em resumo, as triggers de DDL permitem que você monitore eventos como DROP DATABASE, DROP TABLE, ALTER TABLE, ALTER LOGIN, DROP LOGIN e execute uma ação após o evento ocorrer, inclusive fazendo um rollback da transação que disparou o evento.

     As principais características relacionadas às triggers de DDL e DML são:

• Triggers de DML são disparadas na ocorrência de eventos de INSERT, UPDATE e DELETE;

• Triggers de DDL são disparadas na ocorrência de eventos de CREATE, ALTER e DROP;

• Como as triggers de DML, as triggers de DDL podem executar código gerenciado (assembly .NET carregado sobre o SQL Server);

• Como as triggers de DML, várias triggers de DDL podem ser criadas em uma mesma instrução Transact-SQL;

• Como as triggers de DML, as triggers de DDL podem ser aninhadas;

• Triggers de DDL somente são executadas após a ocorrência do evento;

• Triggers de DDL não criam as tabelas inserted e deleted. As informações sobre os eventos que disparam as triggers são capturadas utilizando uma função especial chamada EVENTDATA() (esta função será descrita ao longo do artigo);

• As triggers de DML e DDL podem ser ativadas e desativas usando os comandos Enable/Disable TRIGGER.

 

No geral, as triggers de DDL podem ser utilizadas nas seguintes situações:

• Você quer impedir alterações na estrutura das tabelas, views, funções ou stored procedures; ...

Quer ler esse conteúdo completo? Tenha acesso completo