Como detectar qualquer alteração em um banco de dados (DDL e DML)

Existem muitos bancos de dados no servidor SQL do meu cliente. Esses bancos de dados estão em desenvolvimento, para que os desenvolvedores possam projetar, refatorar, fazer modificações nos dados e assim por diante. Existem alguns bancos de dados que mudam raramente. Meu cliente precisa manter todos eles seguros (com backup) e gastar algum tempo gerenciando o ambiente. (Não há posição de administrador de banco de dados na empresa.) Após uma longa discussão, o cliente decidiu usar uma estratégia diária de backup completo, devido à facilidade de restauração.

Então, aqui está o resumo da situação:

• O número de bancos de dados pode variar todos os dias.
• Os bancos de dados que foram alterados (significando que dados e / ou estrutura foram alterados) devem ser copiados.
• Os bancos de dados que não foram alterados NÃO devem ser copiados.
• A solução não deve afetar a estrutura do banco de dados (não é um requisito restrito)
• Este "mecanismo de backup" deve funcionar automaticamente.

O principal problema: como detectar que um banco de dados foi alterado. A primeira parte do problema (alterações de DDL) pode ser resolvida usando gatilhos de DDL . Mas as alterações de dados (alterações de DML) são um problema. É impossível aplicar gatilhos DML a todas as tabelas de todos os bancos de dados para rastrear alterações (desempenho, gerenciamento de objetos estendidos ...). O mecanismo de backup deve rastrear todas as alterações para marcar cada banco de dados como pronto para o backup.

• O Change Data Capture é uma solução, mas parece muito pesada (também requer o SQL Server Enterprise Edition).

• Outra maneira é rastrear alterações no arquivo de banco de dados (tamanho ou hora da última alteração), mas não funciona corretamente: um banco de dados pode alterar seu tamanho quando exceder todo o espaço livre reservado e sp_spaceused não é uma solução.

• O rastreamento é uma solução, mas causa problemas de desempenho e requer gerenciamento adicional.

Existem soluções para calcular o tamanho real de uso do banco de dados sem afetar outros objetos de gerenciamento de banco de dados (como estatísticas ..)? Concedido que uma alteração nos dados de uma tabela que não altera o tamanho da tabela não seria acionada (eu acho), mas é melhor que nada. Realmente, estou procurando uma solução direta ou indireta para o SQL Server 2008.

Obrigado por quaisquer comentários, soluções e pensamentos.

ADICIONADO:

Aqui está a solução (graças 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%')
    )

Uma idéia seria fazer um instantâneo todos os dias e monitorar o tamanho do arquivo de instantâneo no disco usando um monitor de arquivo. O instantâneo está aumentando seu tamanho somente quando os dados são adicionados lá, portanto, seria uma idéia válida se você encontrasse uma ferramenta para monitorar o tamanho real (tamanho relatado).

Agora .. eu não usei isso, então não posso dar idéias técnicas :-).

Outra idéia seria verificar o log de transações de cada banco de dados (se você estiver usando o modo de recuperação total neles, é claro) com alguma função que eu já vi nos fóruns (db_fnlog .. ou algo assim) que lê operações do log e veja se você tem exclusões / inserções / atualizações.

Essas não são coisas fáceis de fazer .. mas espero que você as ache úteis.

PS: encontrou o artigo com a função de leitura de log (é fndblog, a propósito :-): leia o log de transações de Jens K. Suessmeyer .

• Para alterações de DDL, você pode ler o rastreamento padrão .
• Para modificações DML, uma vez que você considera o CDC um pouco pesado, você pode executar seu próprio rastreamento leve do lado do servidor que rastreia apenas os eventos relevantes

Para alterações DDL, você aciona DDL, mas alterações DML, você pode tentar usar 3 opções diferentes

1) Rastreamento de alterações 2) CDC (Captura de dados de alteração) 3) Recurso de auditoria

Para rastreamento de alterações ... você pode ver o link abaixo http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

esse rastreamento de alterações será usado apenas quando a tabela tiver sido alterada ou não ... mas é muito difícil encontrar quais dados foram alterados .. se você quiser encontrar quais dados foram alterados, poderá acessar o Chnage data Capture.

Para o Aduit no sqlserver. Você pode verificar o link abaixo http://blogs.msdn.com/b/manisblog/archive/2008/07/21/sql-server-2008-auditing.aspx

Para alterações no DML, você pode utilizar qualquer um dos seguintes recursos nativos de auditoria do SQL Server:

• Rastreamento de alterações do SQL Server
• Captura de dados alterados do SQL Server
• Auditoria do SQL Server

Cada um tem suas vantagens e desvantagens, mas a Auditoria é a mais recente introduzida pela Microsoft, portanto, seria uma boa ideia criar suas soluções atuais e futuras envolvidas.

Observe que apenas o recurso Auditoria fornece informações sobre quem / quando / como

Você pode detectar quaisquer alterações de ddl usando o arquivo de rastreamento. abaixo está o script para obter alterações.

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

Você pode detectar qualquer modificação na tabela e no procedimento armazenado usando 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')