Présentation de la réplication forcée

à jour. Cette technique est rapide et ne perturbe pas l’accès des utilisateurs aux données. Pour employer cette méthode après un sinistre, je vérifie d’abord que l’éditeur et l’abonné sont de nouveau disponibles et que la configuration de réplication du système est restaurée. Par exemple, en cas de défaillance d’un distributeur, je m’assurerai qu’il est de nouveau en ligne. Ensuite, à un moment qui ne gênera pas l’activité de l’entreprise, j’exécute les commandes qui renvoient les parties des données qui ont changé depuis la dernière synchronisation. Ces commandes insèrent les données manquantes ou remplacent les données existantes sans les dupliquer.

La technique de réplication forcée repose sur le comportement de réplication par défaut de SQL Server. Ce dernier réplique les mises à jour qui sont lancées sur n’importe quelle colonne de la clé primaire de la table (sauf une colonne IDENTITY) sous forme de combinaison d’instructions DELETE et INSERT. SQL Server réplique les mises à jour sur les autres colonnes de table simplement par des commandes UPDATE. Examinons plus en détail le processus.

Supposons que la table Pubs contienne une publication appelée Test, laquelle comporte un seul article, Table1. Le listing 1 présente le code servant à créer l’article Table1, lequel a une clé primaire définie sur la colonne integer f1, la colonne varchar f2 et la colonne datetime f3. Vous souhaitez synchroniser les données de Table1 sur l’éditeur et tous les abonnés. (Le code du listing 2 crée la publication Test, l’article Table1 et un abonnement.) Nous supposons que le distributeur, l’éditeur et les abonnés sont déjà configurés. Les abonnés peuvent avoir différents nombres d’enregistrements ou différentes données dans certaines colonnes car ils ne sont pas encore synchronisés.

Si vous exécutez sur l’éditeur la commande UPDATE suivante UPDATE Table1 SET f1=f1 WHERE f3 < ’01/03/2004′ SQL Server ne change pas les données existantes sur l’éditeur, mais envoie la commande aux abonnés sous forme de deux nouveaux appels de procédures stockées pour DELETE et INSERT :

{CALL sp_MSdel_Table1 (1)}
{CALL sp_MSins_Table1 (1, ‘AA’, ’01/03/2004′)}

Le listing 3 illustre le code servant à créer ces procédures stockées, lesquelles sont similaires à celles que SQL Server 2000 génère automatiquement si vous employez un assistant de création de publication au lieu d’exécuter les scripts du listing 2 pour configurer la publication Test.

Si un enregistrement répliqué existe déjà sur l’abonné, les procédures stockées suppriment et remplacent immédiatement l’enregistrement en question. S’il manque un enregistrement, les procédures stockées l’insèrent au bon emplacement dans Table1. Notez dans le listing 3 que la procédure stockée personnalisée sp_MSdel_Table1 ne génère pas de message d’erreur si elle ne trouve pas d’enregistrement correspondant sur l’éditeur (comme SQL Server le fait par défaut) ; j’ai supprimé cette partie du code de la procédure stockée générée par le système afin d’éviter la création d’un message d’erreur qui arrêterait l’agent de distribution (Distribution Agent). Ce changement constitue la seule différence entre les procédures stockées générées par le système et les procédures personnalisées que j’utilise pour la réplication forcée.

Pour voir comment le distributeur remet les commandes sur l’abonné, arrêtez l’agent de distribution au niveau du moniteur de réplication (Replication Monitor), comme le montre la figure 2. Ensuite, exécutez de nouveau la commande UPDATE précédente sur l’article Table1, puis, sur le distributeur, exécutez la commande suivante dans l’Analyseur de requêtes (Query Analyzer) :

EXEC distribution.dbo.
sp_browsereplcmds

Comme le montre la figure 3, SQL Server transforme la commande UPDATE sur l’éditeur en deux commandes CALL, une pour une suppression et une autre pour une insertion, sur le distributeur.