La auditoría de una instancia de SQL Server o de una base de datos de SQL Server implica el seguimiento y registro de los eventos que se producen en el sistema. En SQL Server puedes utilizar varios métodos de auditoría, como se describe en Auditoría (motor de base de datos) -> http://msdn.microsoft.com/es-es/library/cc280526.aspx. A partir de SQL Server 2008 Enterprise, también puedes configurar la auditoría automática mediante SQL Server Audit.

 
Paso a comentar un par de formas fáciles y personalizadas, para que podáis crear vuestras propias auditorias. Ayudarte de procedimientos almacenados que te permitan capturar información adicional del usuario que realiza el cambio, si se puedes (que en ocasiones no se puede), encapsular las modificaciones en procedimientos almacenados y en esos mismos procedimientos incluir el registro en tablas de auditoría. Esta solución mediante procedimientos almacenados es buena pues te da mucha flexibilidad en cuanto a grabar datos de la aplicación que no están accesibles mediantes triggers.
 
De cualquier forma...la auditoría con triggers tiene una ventaja respecto a hacerlo mediante un stored procedure y es que a través de triggers quedan auditados todos los cambios de datos, no solo los que se hacen a través de tu aplicación sino también los que se hacen por fuera (por ejemplo cambios hechos con el managment studio a través de un update/delete/insert).
 
Programar triggers de auditoría..no es nada sencillo, más bien es una tarea tediosa.
 
Ya desde SQL Server 2005 tenemos los DDL Triggers. Son triggers que se ejecutan cuando se produce la ejecución de instrucciones DDL (create, alter, drop, ...). Hasta este momento esto no era posible, sólo podíamos crear triggers para instrucciones DML (insert, update, delete). Con esta nueva funcionalidad ya podemos, por ejemplo auditar las creaciones, modificaciones y borrados de objetos en nuestra base de datos, e incluso, no permitir que se realicen estas acciones.
 
La sintaxis de DDL triggers, es:... Continuar leyendo