Sono passati poco più di due anni dal lancio di SQL Server 2005 (era il novembre 2005) ed è già tempo di restyling per il database server di Microsoft. Questa volta non si tratta di una rivoluzione come quella che c'è stata nel passaggio da SQL Server 2000 a SQL Server 2005, ma allora si trattava di colmare un salto generazionale non indifferente che, al di la dei cinque anni indicati dal calendario, avevano visto il panorama IT profondamente mutato.

Il "breve" intervallo che c'è stato tra SQL Server 2005 e la versione che sta per essere lanciata (le ultime notizie, al momento della pubblicazione di questo articolo, indicano la data di rilascio in "Q3 2008", ovvero tra luglio e settembre di quest'anno) avrebbe reso impossibile avere una lista di nuove funzionalità ricca come quella presente in Yukon (il nome in codice di SQL Server 2005), ma non per questo le novità introdotte in Katmai, aka SQL Server 2008, non possono dirsi sostanziose.

La compressione dei dati e dei backup, il resource query governor, il declarative management framework senza dimenticare i nuovi datatype date e time (finalmente separati fra loro), i dati di tipo location, spatial e filestream, l'introduzione dei table value parameters, dell'istruzione merge (tutti segni evidenti che il T-SQL non è morto come alcuni furono portati a pensare quando venne introdotto il CLR, prima, e lanciato LINQ poi), il change data capture (oggetto di questo articolo), oltre ai miglioramenti in tema di database mirroring, service broker e tanto altro ancora, fanno sì che anche questa volta la lista delle novità sia ricca sia da un punto di vista quantitativo che, soprattutto, qualitativo.

Ovviamente la lista delle novità non si esaurisce in queste righe. Già queste novità però sono sufficienti per valutare una migrazione in tempi rapidi sia che i nostri dati siano su SQL Server 2005 che, a maggior ragione, se utilizziamo ancora SQL Server 2000.

Che cosa è il Change Data Capture?

Una delle novità introdotte in SQL Server 2008 è il Change Data Capture (CDC). Si tratta di una funzionalità in grado di aiutarci nel gestire il "versioning" di una o più tabelle, sia per quanto riguarda le modifiche strutturali che quelle ai dati; questo rappresenta una valida alternativa agli strumenti a disposizione fino ad ora utilizzati quando l'esigenza è quella di mantenere allineate delle tabelle di riepilogo a seguito delle modifiche su una tabella analitica e/o per conservare, ad esempio, la cronologia con cui è stato modificato un listino prezzi.

Esigenze analoghe possono essere soddisfatte, nelle versioni precedenti di SQL Server, mediante la definizione di uno o più trigger che, al verificarsi di un evento di cancellazione, inserimento o aggiornamento dei dati, apportino le necessarie modifiche alle tabelle di "tracking" o a quelle riepilogative. Anche le modifiche alla struttura dati possono essere intercettate, a partire da SQL Server 2005, in maniera analoga; basta definire nel database un trigger di tipo DDL che venga scatenato dagli eventi create/alter/drop table e utilizzare il risultato della funzione EVENT_DATA() per mantenere, in una tabella di log, il tracciamento delle modifiche apportate.

Una soluzione basata su trigger mostra però i propri limiti in quegli scenari dove, stabilmente od occasionalmente, una elevata concorrenza sulle tabelle di tracking o di riepilogo penalizza i tempi di esecuzione complessivi. Infatti un trigger è per definizione sincrono e, per superare tali limiti, occorre trovare un'alternativa che apporti le modifiche alle tabelle "secondarie" in forma asincrona.

In SQL Server 2005 una soluzione può essere rappresentata dall'utilizzo del Service Broker: in questo modo siamo in grado di scindere l'invio della richiesta di aggiornamento della tabella "secondaria" dall'esecuzione vera e propria di tale aggiornamento che può avvenire "as soon as possible" (ma pur sempre in forma asincrona) o posticipata nei momenti di basso traffico per risparmiare preziose risorse di sistema nei momenti in cui maggiormente servono.

Pur nella sua fattibilità e semplicità, l'implementazione di una soluzione simile facendo uso del Service Broker appare sovradimensionata per gli obiettivi che ci si prefigge, mentre SQL Server 2008 ci fornisce "chiavi in mano" una funzionalità nata e progettata per queste esigenze.

Scenario di applicazione del CDC

Immaginiamo l'esigenza di una qualunque società commerciale, la cui base dati vede la presenza di una classica tabella "Orders" in cui vengono immessi i dati relativi agli ordini ricevuti dai vari operatori. Parallelamente a questa vi sono due tabelle riepilogative ("OrdersByWeek" e "OrdersByCust") utilizzate a fini di reportistica e di supporto decisionale: i dati presenti nella tabella OrdersByWeek sono utilizzati sia per l'analisi delle vendite che per l'ufficio acquisti che deve tenere quotidianamente sotto controllo le giacenze di magazzino; i dati nella tabella OrdersByCust sono utilizzati, tra le altre cose, per determinare la scontistica da applicare a ciascun cliente.

Come si è detto, è possibile alimentare e mantenere allineate le tabelle riepilogative implementando dei trigger sulla tabella "Orders" affinchè ogni modifica apportata su questa tabella venga immediatamente propagata alle tabelle di sintesi. Tuttavia le numerose e pesanti attività che insistono su queste ultime tabelle potrebbero penalizzare anche le attività di inserimento di ogni singolo ordine o, in talune e non rare circostanze, a causa delle query onerose che vengono eseguite sulle tabelle di sintesi, possono verificarsi dei timeout a danno delle attività di data entry relative all'acquisizione e alla modifica degli ordini stessi.

Il CDC sembra essere la soluzione ideale per assicurare l'allineamento della tabella di riepilogo (pur introducendo un più o meno marcato ritardo), salvaguardando l'efficienza delle attività OLTP; queste ultime non risultano penalizzate in alcun modo come invece si verificherebbe nel caso di un allineamento sincrono delle tabelle di sintesi, mentre gli utilizzatori delle tabelle riepilogative traggono vantaggio dal non essere ostacolati dalle continue attività di aggiornamento delle tabelle di sintesi, anche se per questo devono rinunciare ad un allineamento "real-time". Questo aspetto non rappresenta un problema nella stragrande maggioranza dei casi dal momento che per questo tipo di attività sono solitamente ammessi e tollerati ritardi di pochi minuti se non addirittura di diverse ore o di qualche giorno.

Come funziona il CDC

L'implementazione del CDC aggiunge due job tra i processi schedulati di SQL Server Agent (pertanto è una condizione necessaria che questo servizio sia sempre in esecuzione). Uno di questi job ha il compito di monitorare il transaction log alla ricerca, a posteriori, di attività di modifica ai dati che hanno riguardato le tabelle sottoposte a monitoraggio; a questo punto le informazioni relative ai record che hanno subito modifiche vengono inserite in una delle tabelle aggiunte alla struttura dati (che chiameremo tabella di tracking) dall'implementazione stessa del CDC. Successivamente ad intervalli predefiniti le informazioni nella tabella di tracking possono essere prelevate, elaborate e consolidate secondo le proprie esigenze.

Il secondo dei due job ha invece il compito di pulire la tabella di tracking ad intervalli regolari, rimuovendo le informazioni più vecchie di un determinato periodo che è fissato in 72 ore per impostazione predefinita, ma che può essere aumentato o diminuito secondo le proprie esigenze. Entro questo lasso di tempo dobbiamo preoccuparci di prelevare l'informazione e consolidarla da qualche altra parte, ma potremmo semplicemente accontentarci di mantenerla nella tabella di tracking per il periodo prefissato (e nel frattempo viene salvata dalle normali operazioni di backup del database) prima della sua rimozione definitiva ad opera del job di cleanup.

Nella figura che segue, tratta dal Book On Line di SQL Server, è schematizzato il principio di funzionamento del CDC.

Figura 1 - Funzionamento di CDC