Quando utilizzare CDC per tenere traccia della cronologia?

26

SQL Server Change Data Capture è una funzionalità che legge i dati storici dai registri delle transazioni di SQL Server e li memorizza in una tabella speciale.

Tramite l'uso di speciali funzioni di valori di tabella (TVF) consente quindi all'utente di interrogare questi dati, rendendo possibile sia ottenere tutte le modifiche su una tabella specifica o solo le modifiche nette risultanti dalle modifiche entro un determinato tempo.

CDC ha alcuni vantaggi

Può essere configurato per tracciare solo determinate tabelle o colonne.
È in grado di gestire i cambiamenti del modello in una certa misura.
Non influisce sulle prestazioni tanto quanto i trigger perché funziona con i registri delle transazioni.
È facilmente abilitato / disabilitato e non richiede colonne aggiuntive sulla tabella che devono essere monitorate.

Ha anche alcuni svantaggi:

La quantità di dati storici può diventare enorme rapidamente.
Non è possibile tenere traccia di chi ha apportato le modifiche (almeno non per le eliminazioni).
I dati della cronologia richiedono un po 'di tempo per essere recuperati, poiché sono basati sui registri delle transazioni.
Dipende dall'agente SQL Server. Se l'agente non è in esecuzione o si arresta in modo anomalo, non viene rilevata alcuna cronologia.

Ho letto molto su CDC e anche se ora so come usarlo, non sono ancora sicuro che sia lo strumento giusto per me.

Per quali compiti / scenari CDC è lo strumento giusto? (ad es. consentire agli utenti di ripristinare un oggetto dati fino a un certo momento? Controllo? Visualizzazione della cronologia completa dei dati?)
Quando preferisci non utilizzare CDC, ma ricorrere a una soluzione personalizzata basata su trigger?
È possibile utilizzare CDC in un database operativo e utilizzare i dati CDC all'interno di un'applicazione operativa? (es. mostrandolo all'utente finale) O è chiaramente un uso improprio di questa funzione?

Ho sentito comunemente che CDC è uno strumento di controllo, ma non è quello che serve a SQL Server Audit ? Sono entrambi strumenti diversi per lo stesso compito? O CDC può essere utilizzato per altre cose?

Il mio scenario attuale è che mi viene chiesto di costruire un framework di dati affidabile che dovrebbe essere la base per molteplici applicazioni future. I requisiti esatti sono sfocati, ma uno è che dovrebbe essere in grado di tracciare la cronologia dei dati e ripristinare le voci più vecchie insieme a tutti i dati correlati da altre tabelle. Sto valutando CDC in questo momento come un'opzione, ma non sono sicuro che questa sia la strada da percorrere, perché non riesco davvero a trovare alcun caso d'uso raccomandato.

Mentre apprezzo i consigli per il mio scenario specifico, le risposte dovrebbero fornire consigli generali su quando o quando non utilizzare Change Data Capture.

sql-server change-data-capture data-versioning

— magnattic
fonte

1

Idealmente, un "quadro" non prenderebbe questo tipo di decisione; sarebbe lasciato a singoli progetti. Ma dal momento che ti viene chiesto di farlo, vorrei almeno sottolineare che chiunque ti sta dando questi requisiti: ci sono diversi modi per raggiungere questo obiettivo e la scelta migliore dipende fortemente dall'uso esatto e dalle esigenze. Chiedi se possono darti qualche chiarimento che possa aiutarti a decidere (ad esempio se le prestazioni o la flessibilità sono più importanti). Un'altra opzione da considerare è quella di sviluppare entrambe le opzioni come parte del "quadro" e lasciare che i progetti reali scelgano quale abilitare.

— jpmc26,

@ jpmc26, potrebbe essere necessario il framework per impedire a ciascun progetto di dedicare tempo a decidere questo tipo di domande.

— Ian Ringrose,

@IanRingrose Il mio punto è che cercare di prendere quella decisione senza considerare le esigenze specifiche di un progetto, a lungo andare, causerà più problemi di quanti ne risolva (e quindi effettivamente sia più costoso che passare quel tempo). Questa è una decisione che non può essere effettivamente presa in un caso generale. I dettagli del progetto devono essere considerati. Usando una decisione generale, il tempo sarà speso usando la soluzione scelta e formulando ipotesi attorno ad essa solo per far sì che quelle ipotesi vengano violate quando viene scoperto che non era una soluzione appropriata. Quindi il sistema dovrà essere riprogettato.

— jpmc26

1

@ jpmc26 Potrei effettivamente scegliere la soluzione che hai proposto, nel caso in cui trovassi un modo per realizzarla: sviluppo del tracciamento della cronologia basato su trigger e basato su CDC, commutabile e dietro un'interfaccia comune. Le applicazioni quindi possono scegliere l'una o l'altra, a seconda delle loro esigenze, ma non devono preoccuparsi di implementarle da sole. Certo, vorrei comunque ottenere una buona risposta alla mia domanda precedente, perché se il CDC non viene comunque eliminato per questo tipo di attività (ad es. Perché è utile solo per l'auditing), potrei salvare me stesso il problema e utilizzare sempre i trigger .

— magnattico

"Se l'agente non è in esecuzione o si arresta in modo anomalo, non viene tracciata alcuna cronologia" - ma se fosse riavviato, nessuna modifica andrebbe persa, giusto?

— Andy Joiner,

12

In primo luogo,

L'acquisizione dei dati di modifica è disponibile solo nelle versioni Enterprise, Developer e Evaluation di SQL Server.

In modo che possa decidere per te se qualcuno dei tuoi clienti non avrà le edizioni enterprise, o non sai ancora che utilizzerai le edizioni enterprise. (Dato che le specifiche includono "più applicazioni future", questo potrebbe essere un vero problema per te)

A differenza dei trigger, non è in tempo reale, questo è sia un vantaggio che uno svantaggio. L'uso dei trigger rallenta sempre un aggiornamento.

Ho lavorato su un sistema quando abbiamo utilizzato i trigger (generati da CodeSmith), oltre a tenere traccia di tutte le modifiche ai record, abbiamo anche collegato le modifiche a una tabella "cronologia" che includeva il modulo dell'applicazione che ha apportato la modifica, e l'oggetto dell'interfaccia utente che l'utente ha utilizzato per apportare la modifica.

Tuttavia, è possibile risolverlo al meglio a livello di applicazione, scrivendo tutti gli aggiornamenti in una coda di messaggi che viene quindi riprodotta per creare un database in un determinato momento, vedere Pattern temporali sul blog di Martin Flowler per una buona panoramica delle opzioni.

— Ian Ringrose
fonte

Il link è una lettura molto interessante, grazie per quello. Tuttavia, risolverlo a livello di applicazione non è un'opzione nel mio caso. Il framework che sto costruendo dovrebbe svolgere gran parte del lavoro, incluso il tracciamento della cronologia, per le applicazioni basate su di esso. Le applicazioni stanno quindi lavorando con un'interfaccia comune per archiviare / recuperare i dati, in modo che non debbano preoccuparsi di come i dati vengono archiviati. Sono consapevole che questo compito è tutt'altro che banale.

— magnattico

Inoltre, attualmente non sto prendendo in considerazione l'Enterprise Edition o non essere un fattore decisivo nel nostro caso. Le future applicazioni di cui sto parlando saranno probabilmente costruite e ospitate da noi.

— magnattico

@atticae, il tuo framework non deve essere limitato al database, può includere codice che viene eseguito al di fuori del database.

— Ian Ringrose,

Ovviamente non è limitato al database. (In questo caso non lo definirei un framework.) Capisco cosa intendi ora per "livello di applicazione" e attualmente sto effettivamente utilizzando una variante del modello di Proprietà temporale di cui parla il tuo link. Il framework che costruisco fornisce questa interfaccia alle applicazioni che la utilizzano. Tuttavia, fa parte del lato dell'interfaccia, e nulla di tutto ciò risponde veramente alle mie domande descritte sopra.

— magnattico

Grazie ancora per la tua risposta. Questo è probabilmente il fattore decisivo per la maggior parte delle persone, quindi penso che sia una buona risposta e probabilmente aiuti i futuri visitatori a decidere di non usare il CDC. Tuttavia, ritengo che non risponda davvero alla maggior parte delle mie domande, quindi dovrò dare la grazia a stacylaray che era l'unico che cercava di rispondere a tutte le domande che avevo. (Anche se speravo in una risposta un po 'più elaborata.)

— Magnattico

12

Ecco una serie di 9 parti molto ben scritta che esamina i diversi modi di controllare le modifiche ai dati di SQL Server. Le parti 3, 4 e 5 si concentrano su CDC. Vale la pena leggere tutti gli articoli perché questo risponderà alle tue domande, come i diversi scenari in cui le funzionalità sarebbero appropriate e generali. http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server

— Brynn
fonte

1

Dopo aver sfogliato l'articolo, non sono ancora molto più intelligente. Poiché la maggior parte degli articoli illustra in dettaglio come utilizzare CDC e come si confronta con il rilevamento delle modifiche. Questo non risponde davvero alle mie domande precedenti.

— magnattico

9

Per quali compiti / scenari CDC è lo strumento giusto? (ad es. consentire agli utenti di ripristinare un oggetto dati a un determinato momento?

Forse dipende.

Revisione?

Sì.

Mostra la cronologia completa dei dati?)

Sì.

Quando preferisci non utilizzare CDC, ma ricorrere a una soluzione personalizzata basata su trigger?

Quando i dati nella tabella delle modifiche non soddisfano le tue esigenze.

È possibile utilizzare CDC in un database operativo e utilizzare i dati CDC all'interno di un'applicazione operativa? (es. mostrandolo all'utente finale)

Sì.

O è chiaramente un uso improprio di questa funzione?

No, non è un uso improprio di questa funzione.

Ho sentito comunemente che CDC è uno strumento di controllo, ma non è quello a che serve SQL Server Audit?

Sì.

Sono entrambi strumenti diversi per lo stesso compito?

No.

O CDC può essere utilizzato per altre cose?

CDC può essere utilizzato per altre cose.

C'è il rilevamento delle modifiche e c'è l'acquisizione dei dati delle modifiche. Entrambi hanno le loro radici nella replica.

Il rilevamento delle modifiche fornisce un modo per fornire le modifiche nette a una tabella. Un esempio di utilizzo potrebbe essere la sincronizzazione del dispositivo portatile.

CDC, d'altra parte, tiene traccia di ogni piccolo cambiamento, una storia. Si può usare quella cronologia per aggiornare un data warehouse invece di copiarlo in massa nei dati, oppure si può usare quella cronologia come dati stessi e generare report da esso. La tabella delle modifiche non è nascosta né presenta schemi o qualcosa di strano. Puoi interrogarlo e usare i dati come preferisci. Tieni a mente ... non è tempo reale, come ha detto Ian. I dati provengono dal registro delle transazioni, quindi prenditi cura di te come faresti con la replica, il mirroring o il log shipping. In generale, sarà più veloce dei trigger. Dovrai utilizzare Snapshot Isolation, che ha un sovraccarico, e dovrai pensare a Disaster Recovery.

— stacylaray
fonte

2

Un punto di correzione. Un tempo, la modifica dell'acquisizione dei dati era disponibile solo nelle versioni sopra elencate. Tuttavia, l'acquisizione dei dati di modifica è diventata disponibile nell'edizione standard a partire dalla SP1 2016. Pertanto, molti articoli scritti prima del 2016 SP1 fanno sembrare che CDC sia fuori portata per quelli di noi che usano l'edizione Standard. Questo non è più il caso. Il documento Microsoft che delinea la disponibilità di CDC si trova nel seguente link.

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017#DW

— Robert Sievers
fonte