Sauvegarde et restauration d'une base de données
Une base de données qui intervient dans la synchronisation doit être sauvegardée régulièrement, comme n'importe quelle autre base de données de production. Si vous êtes amené à restaurer une base de données à partir d'une sauvegarde, vous devez tenir compte de deux éléments :
Les modifications qui ont été apportées dans la base de données après la restauration n'ont peut-être pas été propagées aux clients ou autres homologues. Ceci est dû aux valeurs timestamp qui sont utilisées lors de la sélection des modifications dans une base de données.
Par exemple, lors de la synchronisation client et serveur, Sync Framework récupère une nouvelle valeur d'ancre de la base de données serveur et la stocke dans la base de données client. Cette valeur est utilisée comme limite supérieure de l'ensemble de modifications actif faisant l'objet d'une synchronisation. Pour plus d'informations, consultez Suivi des modifications dans la base de données serveur. Une fois la base de données serveur restaurée, la valeur qui est stockée dans la base de données client peut être logiquement supérieure à la valeur retournée par la base de données serveur.
Dans des scénarios de synchronisation par téléchargement ascendant et bidirectionnelle, les clients ou autres homologues peuvent comporter des modifications que la base de données récemment restaurée ne comporte pas.
Les exemples de cette rubrique utilisent la synchronisation client et serveur comme un exemple. Les mêmes principes s'appliquent à la synchronisation d'égal à égal et les considérations d'égal à égal sont décrites. La base de données serveur est l'homologue distant. La base de données client est l'homologue local. Pour plus d'informations sur la sauvegarde et la restauration des bases de données SQL Server synchronisées à l'aide de SqlSyncProvider, consultez Procédure : sauvegarder et restaurer une base de données (SQL Server).
Base de données serveur
Pour comprendre la façon dont la base de données client peut figurer logiquement avant la base de données serveur, examinez comment les mises à jour sont suivies dans la table Sales.Customer de l'exemple de base de données Sync Framework. La colonne UpdateTimestamp stocke une valeur timestamp, et la nouvelle commande d'ancre retourne une valeur à partir de la fonction MIN_ACTIVE_ROWVERSION SQL Server. Par souci de clarté, des entiers sont utilisés à la place des valeurs hexadécimales dans l'exemple :
Avant la restauration de la base de données, la fonction MIN_ACTIVE_ROWVERSION retourne la valeur 31. Cette valeur était stockée dans la base de données client comme dernière ancre reçue.
Après la restauration de la base de données, la fonction MIN_ACTIVE_ROWVERSION retourne la valeur 19.
Des mises à jour sont effectuées afin que la valeur timestamp dans la colonne UpdateTimestamp atteigne 32.
La synchronisation intervient et la fonction MIN_ACTIVE_ROWVERSION retourne la valeur 32. La dernière mise à jour de la table Sales.Customer est téléchargée car la valeur 32 est supérieure à la dernière valeur d'ancre reçue, 31. Les mises à jour comprises entre 19 et 31 ne sont pas reconnues comme des modifications.
Tout système de suivi qui utilise une horloge logique telle qu'un horodatage peut être confronté à ce problème de modifications non reconnues. Les systèmes de suivi qui utilisent un type de données reposant sur une date et heure ne rencontrent pas ce problème car l'horloge avance indépendamment de l'état de la base de données. Dans la synchronisation d'égal à égal, un horodatage est requis pour le suivi des modifications.
Pour gérer le problème que pose l'horodatage, utilisez l'une des méthodes suivantes :
Réinitialisez l'horodatage du serveur au stade où il se trouvait avant l'opération de restauration. Dans l'exemple précédent, vous pouvez effectuer des mises à jour factices sur une table distincte jusqu'à ce que la fonction MIN_ACTIVE_ROWVERSION retourne 31.
Il s'agit de l'approche recommandée pour la synchronisation d'égal à égal.
Stockez l'ancre pour chaque client sur le serveur. Dans l'exemple précédent, la dernière ancre reçue de la sauvegarde était 19. Par conséquent, les mises à jour ultérieures seront reconnues, et toutes les modifications comprises entre 19 et 32 seront téléchargées. Sync Framework n'offre pas de prise en charge intégrée de cette fonction, mais vous pouvez créer un système sur le serveur en procédant comme suit :
Créez une table dans la base de données serveur qui comporte une ligne pour chaque client. La table doit inclure une colonne dotée de l'ID que Sync Framework génère pour chaque client, ainsi qu'une colonne avec l'ancre de ce client. Au cours de la synchronisation, l'application met à jour cette colonne avec une nouvelle valeur d'ancre.
Modifiez les commandes de synchronisation pour sélectionner la valeur d'ancre la plus faible pour le client qui se synchronise. Il peut s'agir de la valeur qui est stockée dans la base de données client, ou de la valeur qui est stockée dans la base de données serveur. Après une opération de restauration base de données, la valeur dans la base de données du serveur doit être plus faible. S'il se produit un échec après que vous avez écrit une valeur dans la table serveur mais avant l'application des modifications au client, la valeur dans la base de données client doit être plus faible. Si la synchronisation se produit comme prévu, les valeurs doivent être égales. Une commande d'insertion peut être écrite comme suit :
SELECT CustomerId, CustomerName, SalesPerson, CustomerType FROM Sales.Customer WHERE (InsertTimestamp > (SELECT AnchorValue from ServerAnchorTable WHERE ClientId = @sync_client_id) OR InsertTimestamp > @sync_last_received_anchor) AND InsertTimestamp <= @sync_new_received_anchor AND InsertId <> @sync_client_id
Bases de données client
Une fois la base de données serveur restaurée au point actuel en termes de métadonnées de synchronisation, il est possible qu'elle ne comprenne toujours pas les modifications effectuées sur les clients depuis la sauvegarde du serveur. Pour qu'un client donne la réponse adéquate, il doit savoir que la base de données serveur a été restaurée. Vous pouvez utiliser une table de suivi côté serveur qui indique si une restauration a eu lieu depuis la dernière synchronisation d'un client particulier. Lors de chaque session de synchronisation, l'application cliente examine d'abord cette table pour déterminer si elle peut être synchronisée manuellement ou si elle doit exécuter un code spécial pour utiliser la base de données restaurée.
Lorsqu'une application cliente sait que la base de données serveur a été restaurée, elle peut faire converger les bases de données client et serveur. Il existe plusieurs façons d'accomplir cette tâche, y compris les approches suivantes :
Réinitialisation de la base de données client en supprimant toutes les tables, puis en effectuant une synchronisation avec le serveur. Il s'agit de l'approche la plus simple, mais toutes les modifications apportées au niveau du client sont perdues.
La réinitialisation est l'approche recommandée pour la synchronisation d'égal à égal. Pour plus d'informations sur l'initialisation des bases de données d'homologues, consultez « Initialisation d'une base de données serveur » dans Procédure : configurer et exécuter la synchronisation collaborative (non-SQL Server).
Réinitialisation de la base de données client après avoir créé une copie des tables du client. Une application peut procéder de la manière suivante :
identifier que la base de données serveur a été restaurée ;
effectuer une copie de toutes les tables de la base de données client, puis supprimer les tables d'origine ;
effectuer une synchronisation avec le serveur pour télécharger de nouveaux schéma et données ;
comparer les lignes des nouvelles tables aux copies effectuées ;
identifier les différences entre les deux ensembles de tables et appliquer les modifications requises aux nouvelles tables ;
effectuer une nouvelle synchronisation pour télécharger les modifications appliquées aux nouvelles tables.
Voir aussi
Autres ressources
Considérations sur la conception et le déploiement d'applications