Cómo detectar cualquier cambio en una base de datos (DDL y DML)

Hay muchas bases de datos en el servidor SQL de mi cliente. Estas bases de datos están en desarrollo, por lo que los desarrolladores pueden diseñar, refactorizar, realizar modificaciones de datos, etc. Hay algunas bases de datos que cambian raramente. Mi cliente tiene que mantenerlos a todos seguros (respaldados) y pasar algún tiempo administrando el medio ambiente. (No hay un puesto de administrador de base de datos en la empresa). Después de una larga discusión, el cliente ha decidido utilizar una estrategia de copia de seguridad completa diaria, debido a la facilidad de restauración.

Así que aquí está el resumen de la situación:

• El número de bases de datos puede variar todos los días.
• Las bases de datos que fueron cambiadas (lo que significa que los datos y / o la estructura han sido cambiados) serán respaldados.
• Las bases de datos que no fueron modificadas NO deberán ser respaldadas.
• La solución no afectará la estructura de la base de datos (no es un requisito restringido)
• Este "motor de respaldo" funcionará automáticamente.

El principal problema: cómo detectar que se ha cambiado una base de datos. La primera parte del problema (cambios DDL) puede resolverse mediante el uso de desencadenadores DDL . Pero los cambios de datos (cambios de DML) son un problema. Es imposible aplicar disparadores DML a todas las tablas de todas las bases de datos para realizar un seguimiento de los cambios (rendimiento, gestión de objetos extendidos ...). El motor de respaldo tiene que rastrear todos los cambios para marcar cada base de datos como lista para respaldar.

• Change Data Capture es una solución, pero parece demasiado pesada (también requiere SQL Server Enterprise Edition).

• Otra forma es rastrear los cambios en el archivo de la base de datos (tamaño o tiempo de último cambio), pero no funciona correctamente: una base de datos puede cambiar su tamaño cuando excede todo el espacio libre reservado y sp_spaceused no es una solución.

• El seguimiento es una solución, pero causa problemas de rendimiento y requiere una administración adicional.

¿Hay alguna solución para calcular el tamaño real de uso de la base de datos sin afectar otros objetos de administración de la base de datos (como estadísticas ...)? Concedido que un cambio en los datos de una tabla que no cambia el tamaño de la tabla no se disparará (creo), pero es mejor que nada. Realmente estoy buscando una solución directa o indirecta para SQL Server 2008.

Gracias por cualquier comentario, solución y opinión.

ADICIONAL:

Aquí está la solución (gracias a Marian ):

Select
    NextLSN = MAX(fn.[Current LSN])
    ,Databasename = DB_NAME()
 from fn_dblog(NULL,    NULL) fn
     LEFT JOIN sys.allocation_units au
         ON fn.AllocUnitId = au.allocation_unit_id
     LEFT  JOIN sys.partitions p
         ON p.partition_id = au.container_id
     LEFT  JOIN sys.objects so
         ON so.object_id = p.object_id  
    WHERE 
    (
        (Operation IN 
       ('LOP_INSERT_ROWS','LOP_MODIFY_ROW',
            'LOP_DELETE_ROWS','LOP_BEGIN_XACT','LOP_COMMIT_XACT') 
            AND so.is_ms_shipped = 0)
        OR 
        ([Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%')
    )

Una idea sería hacer una instantánea todos los días y monitorear el tamaño del archivo de instantánea en el disco usando un monitor de archivo. La instantánea aumenta su tamaño solo cuando se agregan datos allí, por lo que sería una idea válida si encontrara una herramienta para monitorear el tamaño real (tamaño informado).

Ahora ... no usé esto, así que no puedo darle información técnica :-).

Otra idea sería verificar el registro de transacciones de cada db (si está usando el modo de recuperación completa en ellos, por supuesto) con alguna función que he visto en los foros (db_fnlog ... o algo así) que lee las operaciones del registro , y vea si tiene alguna eliminación / inserción / actualización.

Esas no son cosas fáciles de hacer ... pero espero que les sean útiles.

PD: encontré el artículo con la función de lectura de registro (es fndblog, por cierto :-): Lea el registro de transacciones de Jens K. Suessmeyer .

• Para los cambios de DDL, puede leer el Rastreo predeterminado .
• Para las modificaciones de DML, ya que considera que los CDC son un poco pesados, puede ejecutar su propio rastreo ligero del lado del servidor que rastrea solo los eventos relevantes

Para los cambios de DDL, los activadores de DDL, pero los cambios de DML, puede intentar usar 3 opciones diferentes

1) Cambiar seguimiento 2) CDC (Cambiar captura de datos) 3) Función de auditoría

Para el seguimiento de cambios ... puede ver el siguiente enlace http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

este seguimiento de cambios solo se usará si la tabla ha cambiado o no ... pero es muy difícil encontrar qué datos han cambiado ... si desea encontrar qué datos han cambiado, puede ir a Captura de datos de Chnage.

Para Aduit en sqlserver ... puede consultar el siguiente enlace http://blogs.msdn.com/b/manisblog/archive/2008/07/21/sql-server-2008-auditing.aspx

Para los cambios de DML, puede utilizar cualquiera de las siguientes funciones de auditoría nativas de SQL Server:

• Seguimiento de cambios de SQL Server
• Captura de datos de cambio de SQL Server
• Auditoría de SQL Server

Cada uno tiene sus ventajas y desventajas, pero la Auditoría es la última presentada por Microsoft, por lo que sería una buena idea construir sus soluciones actuales y futuras envueltas en ella.

Tenga en cuenta que solo la función de Auditoría proporciona información sobre Quién / Cuándo / Cómo

Puede detectar cualquier cambio de ddl utilizando el archivo de seguimiento. a continuación se muestra el script para obtener cambios.

SELECT 
    te.name AS eventtype
    ,t.loginname
    ,t.spid
    ,t.starttime
    ,t.objectname
    ,t.databasename
    ,t.hostname
    ,t.ntusername
    ,t.ntdomainname
    ,t.clientprocessid
    ,t.applicationname  
FROM sys.fn_trace_gettable
(
    CONVERT
    (VARCHAR(150)
    ,(
        SELECT TOP 1 
            value
        FROM sys.fn_trace_getinfo(NULL)  
        WHERE property = 2
    )),DEFAULT
) T 
INNER JOIN sys.trace_events as te 
    ON t.eventclass = te.trace_event_id 
WHERE eventclass=164

Puede detectar cualquier modificación en la tabla y el procedimiento almacenado utilizando este script:

SELECT 
    SO.Name
    ,SS.name 
    ,SO.type_desc 
    ,SO.create_date
    ,SO.modify_date 
 FROM sys.objects AS SO
INNER JOIN sys.schemas AS SS 
    ON SS.schema_id = SO.schema_id 
WHERE DATEDIFF(D,modify_date, GETDATE()) < 50
AND TYPE IN ('P','U')