Stratégies de sauvegarde et de restauration de la réplication transactionnelle et de capture instantanée

  • Article

Lors de la conception d'une stratégie de sauvegarde et de restauration de la réplication transactionnelle et de capture instantanée, vous devez identifier :

  • les bases de données à sauvegarder ;
  • les paramètres de sauvegarde de la réplication transactionnelle ;
  • les étapes nécessaires à la restauration d'une base de données, en fonction du type de réplication et des options choisies.

Cette rubrique aborde chacun de ces points au cours des trois sections suivantes. Pour plus d'informations sur la sauvegarde et la restauration de la publication Oracle, consultez Sauvegarde et restauration des serveurs de publication Oracle.

Sauvegarde de bases de données

Pour la réplication transactionnelle et de capture instantanée, vous devez sauvegarder régulièrement les bases de données suivantes :

  • Base de données de publication sur le serveur de publication
  • Base de données de distribution sur le serveur de distribution
  • Base de données d'abonnement sur chaque Abonné
  • Bases de données système master et msdb sur le serveur de publication, sur le serveur de distribution et sur tous les Abonnés. Les bases de données doivent être sauvegardées toutes en même temps, de même que la base de données de réplication. Par exemple, sauvegardez les bases de données master et msdb sur le serveur de publication en même temps que vous sauvegardez la base de données de publication. Si la base de données de publication est restaurée, assurez-vous que les bases de données master et msdb sont cohérentes par rapport à la base de données de publication en termes de paramètres de configuration de la réplication.

Si vous effectuez régulièrement des sauvegardes de journaux, toute modification liée à la réplication doit figurer dans les sauvegardes des journaux. Si vous ne sauvegardez pas les journaux, procédez à une sauvegarde chaque fois qu'un paramètre lié à la réplication est modifié. Pour plus d'informations, consultez Actions courantes nécessitant une sauvegarde mise à jour.

Paramètres de sauvegarde de la réplication transactionnelle

La réplication transactionnelle inclut l'option sync with backup, qu'il est possible de définir sur la base de données de distribution et celle de publication :

  • Il est recommandé d'activer cette option sur la base de données de distribution dans tous les cas.
    De cette façon, vous êtes assuré que les transactions du journal de la base de données de publication ne seront pas tronquées tant qu'elles n'auront pas été sauvegardées dans la base de données de distribution. La base de données de distribution peut être restaurée à partir de la dernière sauvegarde. Toutes les transactions manquantes sont remises à la base de données de distribution par la base de données de publication et la réplication se poursuit normalement.
    L'activation de cette option sur la base de données de distribution n'a aucune incidence sur la latence de réplication. Toutefois, elle retarde la troncature du journal de la base de données de publication jusqu'à ce que les transactions correspondantes dans la base de données de distribution aient été sauvegardées (ce qui peut donner un journal des transactions plus volumineux dans la base de données de publication).
  • Il est recommandé de configurer cette option sur la base de données de publication si votre application peut accepter une latence supplémentaire.
    L'activation de cette option garantit que les transactions ne sont pas remises à la base de données de distribution tant qu'elles ne sont pas sauvegardées dans la base de données de publication. La dernière sauvegarde de la base de données de publication peut ensuite être restaurée sur le serveur de publication en étant assuré que la base de données de distribution ne détient pas des transactions qui n'auraient pas été transmises à la base de données de publication restaurée.
    La latence et le débit sont affectés car les transactions ne peuvent être transmises à la base de données de distribution avant d'avoir été sauvegardées sur le serveur de publication. Si, par exemple, le journal des transactions est sauvegardé toutes les cinq minutes, il existe une latence supplémentaire de cinq minutes entre la validation d'une transaction sur le serveur de publication et la remise de la transaction dans la base de données de distribution puis à l'Abonné.
    ms152560.note(fr-fr,SQL.90).gifRemarque :
    L'option sync with backup garantit la cohérence entre les bases de données de publication et de distribution mais elle ne vous protège pas d'éventuelles pertes de données. En cas de perte du journal des transactions par exemple, les transactions validées depuis la dernière sauvegarde du journal ne seront pas disponibles dans la base de données de publication ni celle de distribution. Ce comportement est identique à celui d'une base de données non répliquée.

Pour définir l'option sync with backup

Restauration des bases de données concernées par la réplication

Il est possible de restaurer toutes les bases de données d'une topologie de réplication s'il existe des sauvegardes récentes et si vous respectez la procédure indiquée. Les étapes de restauration de la base de données de publication dépendent du type de réplication et des options utilisées, ce qui n'est pas le cas pour toutes les autres bases de données.

La réplication prend en charge la restauration de bases de données répliquées sur le même serveur et dans la même base de données à partir desquels la sauvegarde a été créée. Si vous restaurez une sauvegarde d'une base de données répliquée sur un autre serveur ou dans une autre base de données, les paramètres de réplication ne peuvent pas être conservés. Dans ce cas, vous devez recréer tous les abonnements et les publications au terme de la restauration des sauvegardes.

Serveur de publication

Des procédures de restauration sont décrites pour les types de réplication suivants :

  • Réplication de capture instantanée
  • Réplication transactionnelle en lecture seule
  • Réplication transactionnelle avec des abonnements mis à jour
  • Réplication transactionnelle d'égal à égal

La restauration des bases de données msdb et master, également décrite dans cette section, est identique pour les quatre types.

Base de données de publication : réplication de capture instantanée

  1. Restaurez la dernière sauvegarde la base de données de publication. Passez à l'étape 2.
  2. Si la sauvegarde de la base de données de publication contient la dernière configuration de tous les abonnements et publications, la restauration est alors terminée. Sinon, passez à l'étape 3.
  3. Supprimez la configuration de la réplication sur le serveur de publication, le serveur de distribution et les Abonnés puis recréez la configuration. La restauration est terminée.
    Pour plus d'informations sur la suppression de la réplication, consultez Suppression de la réplication et sp_removedbreplication (Transact-SQL).

Base de données de publication : réplication transactionnelle en lecture seule

  1. Restaurez la dernière sauvegarde la base de données de publication. Passez à l'étape 2.
  2. Si l'option sync with backup a été activée sur la base de données de publication avant la défaillance, passez à l'étape 3 ; sinon, passez à l'étape 5.
    Si l'option est activée, la requête SELECT DATABASEPROPERTYEX('<PublicationDatabaseName>', 'IsSyncWithBackup'); retourne la valeur 1.
  3. Si la sauvegarde restaurée est terminée et à jour et si elle contient la dernière configuration de tous les abonnements et publications, la restauration est alors terminée. Sinon, passez à l'étape 4.
  4. Comme les informations de configuration dans la base de données de publication restaurée ne sont pas à jour, vous devez vérifier que les Abonnés détiennent toutes les commandes non traitées dans la base de données de distribution avant de supprimer puis recréer la configuration de réplication :
    1. Exécutez l'Agent de distribution jusqu'à ce que tous les Abonnés soient synchronisés avec les commandes non traitées dans la base de données de distribution. Vérifiez que toutes les commandes ont été remises aux Abonnés via l'onglet Commandes non distribuées dans le moniteur de réplication ou en interrogeant la vue MSdistribution_status dans la base de données de distribution. Passez à l'étape b.
      Pour plus d'informations sur l'exécution de l'Agent de distribution, consultez Procédure : démarrer et arrêter un Agent de réplication (SQL Server Management Studio) et Programming Replication Agent Executables.
      Pour plus d'informations sur la vérification des commandes, consultez How to: View Replicated Commands and Other Information in the Distribution Database (Replication Transact-SQL Programming) etProcédure : afficher des informations et effectuer des tâches pour les agents associés à un abonnement (Moniteur de réplication).
    2. Supprimez la configuration de réplication sur le serveur de publication, le serveur de distribution et les Abonnés puis recréez la configuration. Lorsque vous recréez les abonnements, spécifiez que l'Abonné possède déjà les données. La restauration est terminée.
      Pour plus d'informations sur la suppression de la réplication, consultez Suppression de la réplication et sp_removedbreplication (Transact-SQL).
      Pour plus d'informations sur la procédure permettant de spécifier que l'Abonné possède déjà les données, consultez Procédure : initialiser manuellement un abonnement (SQL Server Management Studio) et How to: Initialize a Subscription Manually (Replication Transact-SQL Programming).
  5. Dans la mesure où l'option sync with backup n'a pas été définie sur la base de données de publication, les transactions qui n'ont pas été incluses dans la sauvegarde restaurée peuvent avoir été transmises au serveur de distribution et aux Abonnés. Vous devez à présent vérifier que les Abonnés possèdent toutes les commandes non traitées dans la base de données de distribution puis appliquer manuellement à la base de données de publication toutes les transactions non incluses dans la sauvegarde restaurée :
    ms152560.note(fr-fr,SQL.90).gifImportant :
    L'exécution de cette procédure peut se traduire par la restauration des tables publiées à un point dans le temps plus récent que celui des autres tables non publiées restaurées à partir de la sauvegarde.
    1. Exécutez l'Agent de distribution jusqu'à ce que tous les Abonnés soient synchronisés avec les commandes non traitées dans la base de données de distribution. Vérifiez que toutes les commandes sont remises aux Abonnés via l'onglet **Commandes non distribuées** dans le moniteur de réplication ou en interrogeant la vue **MSdistribution\_status** dans la base de données de distribution. Passez à l'étape b. Pour plus d'informations sur l'exécution de l'Agent de distribution, consultez [Procédure : démarrer et arrêter un Agent de réplication (SQL Server Management Studio)](ms151783\(v=sql.90\).md) et [Programming Replication Agent Executables](ms147886\(v=sql.90\).md). Pour plus d'informations sur la vérification des commandes, consultez [How to: View Replicated Commands and Other Information in the Distribution Database (Replication Transact-SQL Programming)](ms147306\(v=sql.90\).md) et[Procédure : afficher des informations et effectuer des tâches pour les agents associés à un abonnement (Moniteur de réplication)](ms152749\(v=sql.90\).md). 2. Utilisez l'[Utilitaire tablediff](ms162843\(v=sql.90\).md) ou un autre outil pour synchroniser manuellement le serveur de publication avec le serveur de distribution, ce qui permet de récupérer des données de la base de données d'abonnement qui n'étaient comprises dans la sauvegarde de la base de données d'abonnement. Passez à l'étape c. Pour plus d'informations sur l'utilitaire **tablediff**, consultez [How to: Compare Replicated Tables for Differences (Replication Programming)](ms147919\(v=sql.90\).md). 3. Si la sauvegarde restaurée est terminée et à jour et si elle contient la dernière configuration de tous les abonnements et publications, exécutez la procédure stockée [sp\_replrestart (Transact-SQL)](ms174390\(v=sql.90\).md) pour resynchroniser les métadonnées du serveur de publication avec les métadonnées du serveur de distribution. La restauration est terminée. Sinon, passez à l'étape d. 4. Supprimez la configuration de réplication sur le serveur de publication, le serveur de distribution et les Abonnés puis recréez la configuration. Lorsque vous recréez les abonnements, spécifiez que l'Abonné possède déjà les données. La restauration est terminée. Pour plus d'informations sur la suppression de la réplication, consultez [Suppression de la réplication](ms152757\(v=sql.90\).md) et [sp\_removedbreplication (Transact-SQL)](ms188734\(v=sql.90\).md). Pour plus d'informations sur la procédure permettant de spécifier que l'Abonné possède déjà les données, consultez [Procédure : initialiser manuellement un abonnement (SQL Server Management Studio)](ms151246\(v=sql.90\).md) et [How to: Initialize a Subscription Manually (Replication Transact-SQL Programming)](ms147897\(v=sql.90\).md).

Base de données de publication : réplication transactionnelle avec des abonnements mis à jour

  1. Restaurez la dernière sauvegarde la base de données de publication. Passez à l'étape 2.
  2. Exécutez l'Agent de distribution jusqu'à ce que tous les Abonnés soient synchronisés avec les commandes non traitées dans la base de données de distribution. Vérifiez que toutes les commandes sont remises aux Abonnés via l'onglet Commandes non distribuées dans le moniteur de réplication ou en interrogeant la vue MSdistribution_status dans la base de données de distribution. Passez à l'étape 3.
    Pour plus d'informations sur l'exécution de l'Agent de distribution, consultez Procédure : démarrer et arrêter un Agent de réplication (SQL Server Management Studio) et Programming Replication Agent Executables.
    Pour plus d'informations sur la vérification des commandes, consultez How to: View Replicated Commands and Other Information in the Distribution Database (Replication Transact-SQL Programming) etProcédure : afficher des informations et effectuer des tâches pour les agents associés à un abonnement (Moniteur de réplication).
  3. Si vous utilisez des abonnements mis à jour en attente, connectez-vous à chaque Abonné et supprimez toutes les lignes de la table MSreplication_queue dans la base de données d'abonnement. Passez à l'étape 4.
    ms152560.note(fr-fr,SQL.90).gifRemarque :
    Si vous utilisez des abonnements mis à jour en attente et qu'une table quelconque contient des colonnes d'identité, vous devez vérifier que les plages d'identité correctes sont affectées après une restauration. Pour plus d'informations, consultez Réplication de colonnes d'identité.
  4. Vous devez à présent vérifier que les Abonnés possèdent toutes les commandes non traitées dans la base de données de distribution puis appliquer manuellement à la base de données de publication toutes les transactions non incluses dans la sauvegarde restaurée :
    ms152560.note(fr-fr,SQL.90).gifImportant :
    L'exécution de cette procédure peut se traduire par une restauration des tables publiées à un point dans le temps plus récent que celui des autres tables non publiées restaurées à partir de la sauvegarde.
    1. Exécutez l'Agent de distribution jusqu'à ce que tous les Abonnés soient synchronisés avec les commandes non traitées dans la base de données de distribution. Vérifiez que toutes les commandes sont remises aux Abonnés dans le moniteur de réplication ou en interrogeant la vue **MSdistribution\_status** dans la base de données de distribution. Passez à l'étape b. 2. Utilisez l'[Utilitaire tablediff](ms162843\(v=sql.90\).md) ou un autre outil pour synchroniser manuellement le serveur de publication et le serveur de distribution, ce qui permet de récupérer des données de la base de données d'abonnement qui n'étaient comprises dans la sauvegarde de la base de données d'abonnement. Passez à l'étape c. Pour plus d'informations sur l'utilitaire **tablediff**, consultez [How to: Compare Replicated Tables for Differences (Replication Programming)](ms147919\(v=sql.90\).md). 3. Si la sauvegarde restaurée est terminée et à jour et si elle contient la dernière configuration de tous les abonnements et publications, exécutez la procédure stockée [sp\_replrestart (Transact-SQL)](ms174390\(v=sql.90\).md) pour resynchroniser les métadonnées du serveur de publication avec celles du serveur de distribution. La restauration est terminée. Sinon, passez à l'étape d. 4. Supprimez la configuration de la réplication sur le serveur de publication, le serveur de distribution et les Abonnés puis recréez la configuration. Lorsque vous recréez les abonnements, spécifiez que l'Abonné possède déjà les données. La restauration est terminée. Pour plus d'informations sur la suppression de la réplication, consultez [Suppression de la réplication](ms152757\(v=sql.90\).md) et [sp\_removedbreplication (Transact-SQL)](ms188734\(v=sql.90\).md). Pour plus d'informations sur la procédure permettant de spécifier que l'Abonné possède déjà les données, consultez [Procédure : initialiser manuellement un abonnement (SQL Server Management Studio)](ms151246\(v=sql.90\).md) et [How to: Initialize a Subscription Manually (Replication Transact-SQL Programming)](ms147897\(v=sql.90\).md).

Base de données de publication : réplication transactionnelle d'égal à égal

Dans les étapes suivantes, les bases de données de publication A, B et C font partie d'une topologie de réplication transactionnelle d'égal à égal. Les bases de données A et C sont en ligne et fonctionnent correctement tandis que la base de données B doit être restaurée.

  1. Exécutez les Agents de distribution pour synchroniser les abonnements dans les bases de données A et C. Passez à l'étape 2.
    Pour plus d'informations sur l'exécution de l'Agent de distribution, consultez Procédure : démarrer et arrêter un Agent de réplication (SQL Server Management Studio) et Programming Replication Agent Executables.
  2. Si la base de données de distribution utilisée par B est toujours accessible, exécutez les Agents de distribution pour synchroniser les abonnements entre les bases de données B et A et les bases de données B et C. Passez à l'étape 3.
  3. Supprimez les métadonnées de la base de données de distribution utilisée par B en exécutant sp_removedistpublisherdbreplication (Transact-SQL) sur la base de données de distribution de B. Passez à l'étape 4.
  4. Dans les bases de données A et C, supprimez les abonnements à la publication hébergée dans la base de données B. Passez à l'étape 5.
    Pour plus d'informations sur la suppression d'abonnements, consultez Abonnement à des publications.
  5. Effectuez une sauvegarde des journaux ou une sauvegarde complète de la base de données A. Passez à l'étape 6.
  6. Restaurez la sauvegarde de la base de données A dans la base de données B. Cette dernière possède désormais les données de la base de données A mais pas la configuration de réplication. Lorsque vous restaurez une sauvegarde sur un autre serveur, la réplication est supprimée. La réplication a donc été supprimée de la base de données B. Passez à l'étape 7.
  7. Recréez la publication dans la base de données B puis recréez les abonnements entre les bases de données A et B (les abonnements qui concernent la base de données C sont gérés ultérieurement) :
    1. Recréez la publication dans la base de données B. Passez à l'étape b.
    2. Recréez l'abonnement de la base de données B à la publication de la base de données A, en spécifiant que l'abonnement doit être initialisé avec une sauvegarde (valeur initialize with backup pour le paramètre @sync_type de sp_addsubscription (Transact-SQL)). Passez à l'étape c.
    3. Recréez l'abonnement de la base de données A à la publication de la base de données B, en spécifiant que l'abonnement possède déjà les données (valeur replication support only pour le paramètre @sync_type de sp_addsubscription (Transact-SQL)). Passez à l'étape 8.
      Le moyen le plus simple et rapide pour effectuer les étapes a à c consiste à utiliser l'Assistant Configurer la topologie d'égal à égal. Pour plus d'informations, consultez Procédure : configurer la réplication transactionnelle d'égal à égal (SQL Server Management Studio). Vous pouvez également utiliser des procédures stockées ; pour plus d'informations, consultez How to: Configure Peer-to-Peer Transactional Replication (Replication Transact-SQL Programming).
  8. Exécutez les Agents de distribution pour synchroniser les abonnements des bases de données A et B. Si des tables publiées comportent des colonnes d'identité, passez à l'étape 9. Sinon; passez à l'étape 10.
  9. Après la restauration, la plage d'identité que vous avez attribuée à chaque table dans la base de données A sera également utilisée dans la base de données B. Vérifiez que la base de données B restaurée a reçu toutes les modifications de la base de données B défaillante qui ont été propagées aux bases de données A et C puis réattribuez une valeur de départ à la plage d'identité de chaque table.
    1. Exécutez sp_requestpeerresponse (Transact-SQL) sur la base de données B et récupérez le paramètre de sortie @request_id. Passez à l'étape b.
    2. Par défaut, l'Agent de distribution est configuré pour s'exécuter en continu, par conséquent des jetons doivent normalement être envoyés automatiquement à tous les nœuds. Si l'Agent de distribution ne s'exécute pas en mode continu, exécutez l'Agent. Pour plus d'informations, consultez Programming Replication Agent Executables ou Procédure : démarrer et arrêter un Agent de réplication (SQL Server Management Studio). Passez à l'étape c.
    3. Exécutez sp_helppeerresponses (Transact-SQL), en fournissant la valeur de @request_id extraite à l'étape b. Attendez que tous les nœuds signalent la réception de la demande de l'homologue. Passez à l'étape d.
    4. Utilisez DBCC CHECKIDENT pour réattribuer une valeur de départ à chaque table de la base de données B et vérifier qu'une plage appropriée est utilisée. Passez à l'étape 10.
      Pour plus d'informations sur la gestion des plages d'identité, consultez la section « Affectation de plages pour la gestion de plages d'identité manuelle » de Réplication de colonnes d'identité.
  10. À ce stade, les bases de données B et C ne sont pas directement connectées mais elles reçoivent les modifications via la base de données A. Pour connecter les bases de données B et C, effectuez les étapes 11 à 13.
  11. Suspendez le système. Suspendre un système revient à interrompre toute activité sur les tables publiées de tous les nœuds et à vérifier que chaque nœud a reçu toutes les modifications des autres nœuds :
    1. Arrêtez toute activité sur les tables publiées dans la topologie d'égal à égal. Passez à l'étape b.
    2. Exécutez sp_requestpeerresponse (Transact-SQL) sur la base de données B et récupérez le paramètre de sortie @request_id. Passez à l'étape c.
    3. Par défaut, l'Agent de distribution est configuré pour s'exécuter en continu, par conséquent des jetons doivent normalement être envoyés automatiquement à tous les nœuds. Si l'Agent de distribution ne s'exécute pas en mode continu, exécutez l'Agent. Passez à l'étape d.
    4. Exécutez sp_helppeerresponses (Transact-SQL), en fournissant la valeur de @request_id extraite à l'étape b. Attendez que tous les nœuds signalent la réception de la demande de l'homologue. Passez à l'étape 12.
  12. Recréez l'abonnement entre les bases de données B et C :
    1. Recréez l'abonnement de la base de données B à la publication de la base de données C, en spécifiant que l'abonnement doit être initialisé à partir d'une sauvegarde. Passez à l'étape b.
    2. Recréez l'abonnement de la base de données C à la publication de la base de données B, en spécifiant que l'Abonné possède déjà les données. Passez à l'étape 13.
  13. Exécutez les Agents de distribution pour synchroniser les abonnements dans les bases de données B et C. La restauration est alors terminée.

Base de données msdb (serveur de publication)

  1. Restaurez la dernière sauvegarde de la base de données msdb.
  2. Si la sauvegarde restaurée est terminée et à jour et si elle contient la dernière configuration de tous les abonnements et publications, la récupération est terminée. Sinon, passez à l'étape 3.
  3. Recréez le travail de nettoyage de l'abonnement à partir de vos scripts de réplication. La récupération est terminée.

Base de données master (serveur de publication)

  1. Restaurez la dernière sauvegarde de la base de données master.
  2. Vérifiez que les paramètres et la configuration de réplication de la base de données et ceux de la base de données de publication sont cohérents.

Bases de données du serveur de distribution

Base de données de distribution

  1. Restaurez la dernière sauvegarde de la base de données de distribution.
  2. Si l'option sync with backup a été activée sur la base de données de distribution avant la défaillance, passez à l'étape 3 ; sinon passez à l'étape 4.
    Si l'option est activée, la requête SELECT DATABASEPROPERTYEX('<DistributionDatabaseName>', 'IsSyncWithBackup'); retourne la valeur 1.
  3. Si la sauvegarde restaurée est terminée et à jour et si elle contient la dernière configuration de tous les abonnements et publications, la récupération est terminée. Sinon, passez à l'étape 4.
  4. Les informations de configuration dans la base de données de distribution restaurée ne sont pas à jour ou l'option sync with backup n'a pas été activée sur la base de données de distribution (après la restauration, il se peut que la base de données de distribution ne possède pas certaines transactions validées sur le serveur de publication mais pas encore transmises aux Abonnés). Supprimez et recréez la réplication puis exécutez la validation :
    1. Supprimez la configuration de la réplication sur le serveur de publication, le serveur de distribution et les Abonnés puis recréez la configuration. Lorsque vous recréez les abonnements, spécifiez que l'Abonné possède déjà les données. Passez à l'étape b.
      Pour plus d'informations sur la suppression de la réplication, consultez Suppression de la réplication et sp_removedbreplication (Transact-SQL).
      Pour plus d'informations sur la procédure permettant de spécifier que l'Abonné possède déjà les données, consultez Procédure : initialiser manuellement un abonnement (SQL Server Management Studio) et How to: Initialize a Subscription Manually (Replication Transact-SQL Programming).
    2. Marquez toutes les publications pour validation. Réinitialisez tous les abonnements qui n'ont pas pu être validés. La récupération est terminée.
      Pour plus d'informations sur la validation, consultez Validation des données répliquées.
      Pour plus d'informations sur la réinitialisation, consultez Réinitialisation d'un abonnement.

Base de données msdb (serveur de distribution)

  1. Restaurez la dernière sauvegarde de la base de données msdb.
  2. Si la sauvegarde restaurée est terminée et à jour et si elle contient la dernière configuration de tous les abonnements et publications, la récupération est terminée. Sinon, passez à l'étape 3.
  3. Supprimez la configuration de la réplication sur le serveur de publication, le serveur de distribution et les Abonnés puis recréez la configuration. Lorsque vous recréez les abonnements, spécifiez que l'Abonné possède déjà les données. Passez à l'étape 4.
    Pour plus d'informations sur la suppression de la réplication, consultez Suppression de la réplication et sp_removedbreplication (Transact-SQL).
    Pour plus d'informations sur la procédure permettant de spécifier que l'Abonné possède déjà les données, consultez Procédure : initialiser manuellement un abonnement (SQL Server Management Studio) et How to: Initialize a Subscription Manually (Replication Transact-SQL Programming).
  4. Marquez toutes les publications pour validation. Réinitialisez tous les abonnements qui n'ont pas pu être validés. La récupération est terminée.
    Pour plus d'informations sur la validation, consultez Validation des données répliquées.
    Pour plus d'informations sur la réinitialisation, consultez Réinitialisation d'un abonnement.

Base de données master (serveur de distribution)

  1. Restaurez la dernière sauvegarde de la base de données master.
  2. Vérifiez que les paramètres et la configuration de réplication de la base de données et ceux de la base de données de publication sont cohérents.

Bases de données de l'Abonné

Base de données d'abonnement

  1. Si la dernière sauvegarde de la base de données d'abonnement est plus récente que le paramètre de rétention maximale de la distribution dans la base de données de distribution (cela détermine si le serveur de distribution possède toujours toutes les commandes nécessaires à la mise à jour de l'Abonné), passez à l'étape 2. Sinon, réinitialisez l'abonnement ; la récupération est terminée.
    Pour déterminer le paramètre de rétention maximale de la distribution, exécutez sp_helpdistributiondb (Transact-SQL) et récupérez la valeur de la colonne max_distretention (exprimée en heures).
    Pour plus d'informations sur la réinitialisation d'un abonnement, consultez Procédure : réinitialiser un abonnement (SQL Server Management Studio) et How to: Reinitialize a Subscription (Replication Transact-SQL Programming).
  2. Restaurez la dernière sauvegarde de la base de données d'abonnement. Passez à l'étape 3.
  3. Si la base de données d'abonnement contient uniquement des abonnements envoyés, passez à l'étape 4. Si la base de données d'abonnements contient des abonnements extraits, que les informations d'abonnements sont à jour et qu'elle inclut toutes les tables et les options définies au moment de la défaillance, passez à l'étape 4. Sinon, réinitialisez l'abonnement ; la récupération est terminée.
  4. Exécutez l'Agent de distribution pour synchroniser l'abonné. La récupération est terminée.
    Pour plus d'informations sur l'exécution de l'Agent de distribution, consultez Procédure : démarrer et arrêter un Agent de réplication (SQL Server Management Studio) et Programming Replication Agent Executables.

Base de données msdb (Abonné)

  1. Restaurez la dernière sauvegarde de la base de données msdb. Si cet Abonné ne contient pas d'abonnements extraits, la restauration est terminée. S'il en contient, passez à l'étape 2.
  2. Si la sauvegarde restaurée est terminée et à jour et si elle contient la dernière configuration de tous les abonnements et publications, la récupération est terminée. Sinon, passez à l'étape 3.
  3. Supprimez et recréez des abonnements extraits. Lorsque vous recréez les abonnements, spécifiez que l'Abonné possède déjà les données. La restauration est terminée.
    Pour plus d'informations sur la suppression d'abonnements , consultez Abonnement à des publications.
    Pour plus d'informations sur la procédure permettant de spécifier que l'Abonné possède déjà les données, consultez Procédure : initialiser manuellement un abonnement (SQL Server Management Studio) et How to: Initialize a Subscription Manually (Replication Transact-SQL Programming).

Base de données master (Abonné)

  1. Restaurez la dernière sauvegarde de la base de données master.
  2. Vérifiez que les paramètres et la configuration de réplication de la base de données et ceux de la base de données de publication sont cohérents.

Voir aussi

Concepts

Sauvegarde et restauration de bases de données répliquées
Configuration de la distribution
Publication de données et d'objets de base de données
Abonnement à des publications
Initialisation d'un abonnement
Synchronisation des données

Autres ressources

Sauvegarde et restauration de bases de données dans SQL Server

Aide et Informations

Assistance sur SQL Server 2005