Scénarios d’utilisation de la réplication forcée

propagées à l’abonné. Pour synchroniser les données, il suffit d’exécuter sur l’éditeur une commande UPDATE sur l’une des colonnes clé primaire et de remplacer la valeur de colonne par une valeur identique. La commande UPDATE va alors supprimer et réinsérer les enregistrements sans les dupliquer ou insérera les enregistrements manquants dans les tables correspondantes de l’abonné. Vous pouvez employer une clause WHERE pour restreindre le volume des données affectées. Par exemple, comme le montre la figure 3, vous pouvez mettre à jour uniquement les enregistrements antérieurs au 3 janvier 2004 (f3 < ’01/03/2004′).

Dans de rares cas, vous pouvez avoir plus de données sur un ou plusieurs abonnés que sur l’éditeur. Par exemple, si un utilisateur exécute une commande INSERT malveillante au niveau d’un abonné ou si une commande DELETE sur l’éditeur n’a pas été propagée aux abonnés, il sera nécessaire de supprimer les données inutiles de ces derniers. Pour gérer ce type de situation, j’ai ajouté une colonne datetime supplémentaire, intitulée repl_time, à chaque article sur chaque abonné. Cette méthode peut sembler nécessiter de nombreux ajouts, mais vous l’utiliserez dans de rares cas. Juste une fois avant de configurer la réplication, vous exécutez le script du bloc A du listing 4, lequel ajoute la colonne datetime supplémentaire à chaque table image (la table qui fait partie de la réplication) sur l’abonné. Vous n’avez pas besoin d’ajouter la colonne aux propres tables de l’abonné. Chaque fois qu’un enregistrement est inséré ou mis à jour sur l’abonné, la procédure stockée personnalisée appropriée (pour l’insertion ou la mise à jour) remplacera la valeur dans la colonne repl_time par la valeur par défaut, à savoir getdate(). Le code du bloc B du listing 4 présente les procédures stockées sp_MSins_Table1 et sp_MSupd_Table1, qui s’exécutent sur l’abonné et modifient la valeur de repl_time. (Notez que les procédures stockées d’insertion et de mise à jour du listing 4 et du listing 3 diffèrent, mais la procédure stockée sp_MSDel_ Table1 ne change pas.)

Lorsque vous exécutez sur l’éditeur des instructions UPDATE qui remplacent une valeur par la même valeur, comme l’instruction UPDATE précédente qui définit la valeur pour la colonne f1, tous les enregistrements d’abonné qui ont des enregistrements correspondants sur l’éditeur auront de nouvelles valeurs dans leurs colonnes repl_time. Les enregistrements d’abonné qui ne correspondent à aucun enregistrement sur l’éditeur conservent les anciennes valeurs dans ce champ. Pour supprimer tout enregistrement supplémentaire de l’abonné, vous pouvez exécuter une commande DELETE qui inclut la colonne repl_ time dans une clause WHERE. Par exemple, si vous exécutez la réplication forcée à 11 h 00 du matin le 27 août 2004, la commande suivante :

DELETE Table1 WHERE repl_time < ‘2004-08-27 11:00:00’

supprimera de l’abonné les enregistrements dont les valeurs repl_time sont antérieures à 11 h 00 du matin, le 27 août 2004.

Notez que vous pouvez aussi créer la colonne repl_time sur l’éditeur et insérer des valeurs NULL par défaut dans cette colonne au cours du chargement des données. Pendant la réplication, les données dans la colonne repl_time changeront uniquement sur les abonnés. Cette technique conservera des structures de tables identiques sur tous les serveurs. Pour plus d’informations sur la préservation de l’intégrité des données lorsque les tables sont liées par des contraintes de clé étrangère, consultez l’encadré « Gestion de l’intégrité référentielle ».