Come per rilevare eventuali modifiche a un database (DDL e DML)

dba.stackexchange https://dba.stackexchange.com/questions/985

  •  16-10-2019
  •  | 
  •  

Domanda

Ci sono un sacco di banche dati sul server di SQL del mio cliente. Questi database sono in fase di sviluppo, per cui gli sviluppatori possono progettare, refactoring, fare modifiche di dati e così via. Ci sono alcuni database che cambiano raramente. Il mio cliente deve tenere tutti al sicuro (backup) e trascorrere del tempo la gestione dell'ambiente. (Non v'è alcuna posizione di amministratore di DB in azienda). Dopo lunga discussione, il cliente ha deciso di utilizzare una strategia di backup completo al giorno, a causa della facilità di ripristino.

Così qui è la sintesi della situazione:

  • Numero di basi di dati può variare ogni giorno.
  • Banche dati che sono stati modificati (dati e / o la struttura che significano sono stati cambiati) viene eseguito il backup.
  • I database che non sono stati modificati non deve essere sostenuta.
  • Soluzione non dovrà impatto struttura del database (requisito non è limitato)
  • Questo "motore di backup" deve funzionare automaticamente.

Il problema principale:. Come rilevare che un database è stato modificato La prima parte del problema (DDL cambia) può essere risolto utilizzando DDL trigger . Ma le modifiche dei dati (modifiche DML) sono un problema. E 'impossibile applicare trigger DML a tutte le tabelle di tutti i database per tenere traccia delle modifiche (prestazioni, gestione di oggetti estesi ...). Il motore di backup deve tenere traccia di tutte le modifiche per marcare ogni database come pronti per il backup.

  • Change Data Capture è una soluzione, ma sembra troppo pesante (richiede SQL Server Enterprise Edition pure).

  • Un altro modo è quello di tenere traccia delle modifiche apportate ai file di database (di dimensione o l'ultima volta il cambiamento), ma non funziona correttamente: database di A può cambiare la sua dimensione quando si supera tutto lo spazio libero riservato e sp_spaceused non è una soluzione.

  • La traccia è una soluzione, ma che provoca problemi di prestazioni e richiede gestione aggiuntiva.

Ci sono soluzioni per calcolare la dimensione reale utilizzo del database, senza impatto su altri oggetti di gestione di database (come le statistiche ..)? Premesso che una modifica ai dati di una tabella che non cambia la dimensione del tavolo non sarebbe grilletto (credo), ma è meglio di niente. Davvero Sto cercando una soluzione diretta o indiretta per SQL Server 2008.

Grazie per eventuali commenti, soluzioni e pensieri.

AGGIUNTO:

Ecco la soluzione (grazie 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%')
    )
È stato utile?

Soluzione

Un'idea sarebbe quella di fare una fotografia ogni giorno e controllare la dimensione del file di snapshot sul disco utilizzando un monitor di file. L'istantanea sta aumentando la sua dimensione solo quando si aggiunge lì i dati, quindi sarebbe un'idea valida se si dovrebbe trovare uno strumento per monitorare la dimensione reale (dimensione segnalata).

Ora .. non ho usato questo, quindi non può dare spunti tecnici: -).

Un'altra idea sarebbe quella di verificare il log delle transazioni di ogni db (se si sta utilizzando modalità di recupero completo su di loro, ovviamente) con una qualche funzione che ho visto sul forum (db_fnlog .. o qualcosa del genere) che legge le operazioni di dal registro, e vedere se avete Elimina / inserti / aggiornamenti.

Quelli sono cose facili da fare .. ma spero che li troverai utili.

PS: trovato l'articolo con il registro funzioni (è fndblog leggere, a proposito :-): Read il log delle transazioni da Jens K. Suessmeyer .

Altri suggerimenti

  • Per DDL cambia si può leggere il predefinito Trace .
  • Per modifiche DML in quanto a trovare CDC di essere po 'pesante, è possibile eseguire il proprio traccia lato server leggero che ripercorre solo gli eventi rilevanti

Per DDL ti cambia DDL Trigger, Ma DML modifiche che è possibile provare a utilizzare 3 diverse opzioni

1) Il rilevamento delle modifiche 2) CDC (Change Data Capture) 3) Caratteristica di revisione

Per rilevamento delle modifiche .. si può vedere il collegamento sotto http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

questo cambiamento di inseguimento sarà utilizzato solo wheather tabella è cambiato o no ... ma è molto difficile trovare quali dati è cambiato .. se si vuole trovare quali dati è cambiato allora si può andare chnage i dati di cattura.

Per Aduit in SQLServer ..si può controllare il collegamento sotto http: //blogs.msdn .com / b / manisblog / archive / 2008/07/21 / sql-server-2008-auditing.aspx

Per DML modifiche che è possibile utilizzare uno qualsiasi dei followinh auditing nativo di SQL Server dispone di:

  • rilevamento delle modifiche di SQL Server
  • Change Data Capture SQL Server
  • SQL Server Auditing

ognuno ha i suoi vantaggi e svantaggi, ma la revisione è l'ultima introdotta da Microsoft, quindi sarebbe una buona idea per creare le soluzioni attuali e future avvolti con esso.

Si noti che solo la funzione di controllo fornisce informazioni su chi / quando / come

È in grado di rilevare eventuali modifiche DDL utilizzando file di traccia. di seguito è script per ottenere cambiamenti. 

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

È in grado di rilevare qualsiasi modifica sul tavolo e stored procedure utilizzando questo 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')
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a dba.stackexchange
scroll top