Utilizzo di SQL Server Change Data Capture con uno schema che cambia frequentemente

Stiamo cercando di abilitare l'acquisizione dei dati di modifica del server SQL per un nuovo sottosistema che stiamo costruendo.

Non è proprio perché ne abbiamo bisogno, ma siamo spinti per avere una tracciabilità completa della storia e CDC risolverà bene questo requisito con il minimo sforzo da parte nostra.

Stiamo seguendo un processo di sviluppo agile, che in questo caso significa che apportiamo spesso modifiche allo schema del database, ad esempio aggiungendo nuove colonne, spostando i dati su altre colonne, ecc.

Abbiamo fatto un piccolo test in cui abbiamo creato una tabella, abilitato CDC per quella tabella e quindi aggiunto una nuova colonna alla tabella. Le modifiche alla nuova colonna non sono registrate nella tabella CDC.

Esiste un meccanismo per aggiornare la tabella CDC al nuovo schema e esistono buone pratiche su come gestire i dati acquisiti durante la migrazione dello schema del database?

Di recente abbiamo anche iniziato a guardare CDC. Non sono un esperto in materia, ma penso di avere delle risposte alle tue domande.

Per la maggior parte, CDC ti aiuterà a raggiungere il tuo obiettivo di una storia completamente tracciabile, ma non credo che ti porterà fino in fondo.

Prima di tutto:

facciamo spesso modifiche allo schema del database ... Esiste un meccanismo per aggiornare la tabella CDC al nuovo schema

Ed è qui che penso che CDC ti mancherà. La documentazione MSDN nella sezione "Informazioni generali sul rilevamento delle modifiche" è abbastanza chiara sul fatto che non terrà traccia delle modifiche dello schema per te. Ad esempio, con Alter Table Add Column:

Se viene aggiunta una nuova colonna alla tabella delle modifiche rilevate, l'aggiunta della colonna non viene rilevata. Vengono monitorati solo gli aggiornamenti e le modifiche apportati alla nuova colonna.

Drop Column è un po 'più complesso.

Tuttavia, dovresti utilizzare gli script DB per modificare lo schema in modo da non dover necessariamente fare affidamento su CDC qui. Ciò ti consente di avere coerenza tra il tuo QA e gli schemi di produzione. E le modifiche al QA dovrebbero essere eseguite dallo script in modo da poter applicare esattamente le stesse modifiche a Prod. Non dovrebbe essere troppo difficile estrarre le modifiche allo schema da quegli script. Ciò può significare che la dimensione "temporale" della cronologia è determinata dalla versione anziché dall'ora effettiva, ma il risultato finale sarà lo stesso.

Se non ne hai già uno, crea una tabella per tenere traccia della versione del tuo schema di database. Quindi posizionare la tabella della versione dello schema del database in CDC in modo da poter allineare le modifiche macroscopiche allo schema con le modifiche microscopiche all'interno di una tabella particolare.

Per quanto ne so, dovresti comunque vedere i dati aggiunti alle nuove colonne, indipendentemente dal fatto che CDC non mostri la modifica dello schema. E la migrazione dei dati da una tabella all'altra dovrebbe essere raccolta anche da CDC.

ci sono delle migliori pratiche su come gestire i dati acquisiti durante la migrazione dello schema del database?

Trattalo come se dovessi trattare un audit. Devi capire che cosa stai esaminando, perché lo stai esaminando e per quanto tempo devi conservare queste informazioni. Portata e ritenzione sono i due maggiori bugaboos quando si tratta di un'attività come questa.

Gli strumenti di reporting di CDC sono comprensibilmente austeri, quindi è necessario conoscere il contesto delle modifiche. È troppo facile dire "traccia tutto !" e finiscono per non usare nulla di conseguenza. Allo stesso modo, potresti raddoppiare le dimensioni del tuo database conservando una copia di ogni modifica. Su un tavolo alto con molti inserti ed eliminazioni, ti ritroverai con una crescita astronomica. Non è male in sé e per sé, ma è necessario un budget per quella crescita e avere un mezzo per esaminare tutti i dati generati.

Quindi questo ti riporta alla comprensione del motivo per cui sei stato spinto ad avere una tracciabilità completa. Vi sono certamente ragioni valide per tale requisito. Ma non sarai in grado di strutturare il tuo controllo efficace del database fino a quando non sai perché devi soddisfare tale requisito.

Puoi tenere traccia dell'aggiunta di colonne con i trigger DDL.

CREATE TRIGGER trigger_name
ON { ALL SERVER | DATABASE }
[ WITH <ddl_trigger_option> [ ,...n ] ]
{ FOR | AFTER } { event_type | event_group } [ ,...n ]
AS { sql_statement [ ; ] [ ,...n ] |
EXTERNAL NAME < method specifier > [ ; ] }

È possibile utilizzare il gruppo di eventi DDL_TABLE_EVENTS per generare per CREATE, DROP o ALTER di una tabella.

Tuttavia, è possibile dare un'occhiata a SQL Server Audit , se si utilizza enterprise> 2008, in quanto può "combinare tutte le funzionalità di controllo in una specifica di controllo". Questo collegamento msdn contiene un articolo dettagliato al riguardo: http://msdn.microsoft.com/en-us/library/dd392015(v=sql.100).aspx .

CREATE SERVER AUDIT audit_name
TO { [ FILE (<file_options> [, ...n]) ] |
APPLICATION_LOG | SECURITY_LOG }
[ WITH ( <audit_options> [, ...n] ) ] }[ ; ]

<file_options>::=
{FILEPATH = 'os_file_path'
[, MAXSIZE = { max_size { MB | GB | TB } | UNLIMITED } ]
[, MAX_ROLLOVER_FILES = integer ]
[, RESERVE_DISK_SPACE = { ON | OFF } ] }

<audit_options>::=
{ [ QUEUE_DELAY = integer ]
[, ON_FAILURE = { CONTINUE | SHUTDOWN } ]
[, AUDIT_GUID = uniqueidentifier ]}

Quindi si creano le specifiche del server o del database.

Simple-Talk ha un ottimo articolo sull'acquisizione dei dati di modifica e una guida molto dettagliata su CDC, così come la documentazione MSDN spiega i vari metodi a seconda dei requisiti. Ma entrambi possono aiutarti con le tue esigenze specifiche.