|
Cela se fait par l'appel d'une fonction. La fonction est différente selon le mode de fonctionnement : - cdc.fn_cdc_get_all_changes_<capture_instance> : tous les changements sont récupérés
- cdc.fn_cdc_get_net_changes_<capture_instance> : seuls les changements finaux sont récupérés
Ces fonctions sont des Table-valued fonctions, on les utilise donc dans la clause FROM. Elles prennent en paramètres l'intervalle sur lequel on souhaite récupérer les changements. Cette intervalle est matérialisé par ses 2 bornes, sous la forme de paramètres de type binary(10) appelés LSN. LSN signifie Logical Sequence Number et correspond à la transaction dans le journal de la base de données. En effet, les changements étant récupérés par la lecture du journal de la base via un LogReader, tout leur séquencement dans le temps se base sur l'unité du journal à savoir les LSN.
Select *
From cdc.fn_cdc_get_all_changes_Sales_SalesOrderHeader(
@from_LSN
,@to_LSN
‘all’)
Rassurons nous, des fonctions nous permettent de translater une date en LSN (et inversement). Les premières permettent de récupérer le LSN le plus ancien et le LSN le plus récent pour une instance de capture. A noter que le plus récent est commun à toutes les instances de capture d'une table puisque c'est la dernière modification de la table.
DECLARE @from_lsn binary(10), @to_lsn binary(10);
SET @from_lsn = sys.fn_cdc_get_min_lsn('Sales_SalesOrderHeader');
SET @to_lsn = sys.fn_cdc_get_max_lsn();
Le système d'écoute des modifications du CDC peut alors conserver le dernier LSN récupéré et aura juste à l'incrémenter pour obtenir la borne inférieure du prochain intervalle de requête :
SET @from_lsn = sys.fn_cdc_increment_lsn(@to_lsn);
On peut aussi travailler avec des dates et obtenir les LSN à partir de celles-ci. Pour cela, on utilisera les fonctions sys.fn_cdc_map_time_to_lsn qui nous retourne le LSN le plus proche (en précisant si on cherche l'inférieur ou le supérieur) d'une date.
SET @from_lsn = sys. fn_cdc_map_time_to_lsn (‘smaller greater than’, ‘2008-01-21 22:00’);
Dans les informations récupérées, on notera les suivantes : - __$operation : cette valeur indique le type de modification opérée sur la ligne (1 pour delete, 2 pour insert, etc.)
- LSN : les 2 valeurs __$start_lsn et __$eqval permettent d'ordonner les modifications. La première indique l'identifiant de transaction et le second indique l'ordre du traitement dans la transaction.
- Champs : on trouve dans le résultat la liste des champs dont on capture les modifications
- UpdateMask : ce masque de bits permet dans le cas d'une opération d'update de savoir quels champs ont été modifiés
La lecture des changements ne les « invalide » pas. C'est pour cela que c'est à l'application qui consomme les changements de garder le dernier LSN lu (ou de travailler avec des dates). Cela permet de mettre en place plusieurs consommateurs de CDC.
--on doit garder une référence sur les LSN déjà lus
DECLARE @from_lsn binary(10), @to_lsn binary(10);
--on utilise des fonctions pour obtenir les LSN min et max
SET @from_lsn = sys.fn_cdc_get_min_lsn('Sales_SalesOrderHeader'); --capture instance
SET @to_lsn = sys.fn_cdc_get_max_lsn();
Select @from_lsn as [From], @to_lsn as [To]
Select *
From cdc.fn_cdc_get_all_changes_Sales_SalesOrderHeader(
@from_lsn,
@to_lsn,
'all'); --'all update old' pour ajouter les anciennes valeurs (__$operation = 3)
update sales.salesorderheader
set duedate = '2008-01-02'
where salesorderid = 43670
--
--on incrémente les LSN min et max (ATTENTION, si @from_lsn > @to_lsn ==> error)
SET @from_lsn = sys.fn_cdc_increment_lsn(@to_lsn);
SET @to_lsn = sys.fn_cdc_get_max_lsn();
Select @from_lsn as [From], @to_lsn as [To]
if @from_lsn > @to_lsn
print 'Pas de changement (ou non encore reportés dans la CT)'
else
Select *
From cdc.fn_cdc_get_all_changes_Sales_SalesOrderHeader(
@from_lsn,
@to_lsn,
'all');
|
|
|
|
|