Comment synchroniser manuellement des abonnements de réplication en utilisant la sauvegarde ou la restauration

IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que feraient une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique. Si vous relevez des erreurs graves et souhaitez contribuer à l’amélioration du système, vous pouvez compléter l’enquête à votre disposition dans le bas des articles.

La version anglaise de cet article est la suivante: 320499
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Résumé
Cet article explique comment synchroniser manuellement des abonnements d'envoi de réplication en utilisant la sauvegarde et la restauration.

Parfois vous ne pouvez pas totalement synchroniser les abonnements de réplication en utilisant la méthode par défaut pour les raisons éventuelles suivantes
  1. Vous devez transférer de grandes tables à l'abonné
  2. La bande passante réseau ne peut gérer que des modifications incrémentielles ; par conséquent les fichiers BCP volumineux peuvent dépasser les délais
  3. Le Publisher est un serveur de production; activité doit par conséquent nécessiter l'heure basse à être d'être réduit.
Vous pouvez ensuite utiliser des sauvegardes SQL Server pour créer des copies de la base de données publiée dans ces cas; tester l'utilisation de la réplication sans transmettre les données de schéma ou utilisateur sur le réseau; en restaurant les données sur l'abonné configurer la réplication et restaurer. Les sections suivantes répertorient les étapes et les considérations que vous devez utiliser pour assurer la réussite de votre synchronisation manuelle

back to the top

Réplication transactionnelle

Réplication transactionnelle stocke des transactions série et permet à l'abonné de transmettre. Il est essentiel que des modifications aux tables publiées sont remises à l'abonné dans l'ordre dans lequel ils ont été soumis.

Avec un nouvel abonnement la réplication transactionnelle marque chaque modification apportée à la table publiée (ou les tables) dans le journal des transactions La méthode de remise par défaut d'abonnement verrouille les tables, exporte les données en utilisant l'utilitaire , déverrouille les tables publiées et commence puis, à suivre des modifications à la base de données publiée. La fonctionnalité dans le SQL Server 2000, améliore le verrouillage Snapshot surcharge. SQL Server 2000 et SQL Server 7.0 peuvent transférer l'instantané en utilisant protocole FTP. Vous pouvez cependant utiliser la méthode de sauvegarde aux situations à lesquelles ces options ne sont pas acceptables.

En sauvegardant la base de données publiée et en la restaurant vers l'abonné vous pouvez réduire le temps du processus de création de capture instantanée au temps qu'il faut pour sauvegarder la base de données publiée La sauvegarde de la base de données inclut tous les objets qui ne sont pas transférés vers l'abonné par réplication ; vous n'avez pas à exécuter un transfert bcp des tables sur le réseau

Il existe deux méthodes à sauvegarder la base de données publiée. La première méthode utilise une sauvegarde complète de la base de données publiée. La méthode de sauvegarde intégrale fonctionne bien si la base de données est petite ou si la base de données n'est pas configurée pour le mode de récupération complète. La seconde méthode utilise une sauvegarde de journal des transactions et suppose que vous avez déjà capturé une sauvegarde complète de la base de données. La méthode de sauvegarde de journal des transactions réduit l'heure lequel la base de données doit être en mode mono-utilisateur. Sauvegardes de journal des transactions prennent le peu plus de temps que des sauvegardes complètes. Si vous envisagez d'utiliser la méthode de sauvegarde de journal des transactions, procédez comme suit :
  1. Si la base de données publiée ne s'exécute pas en mode de récupération complète, modifiez-le en mode de récupération complète.
  2. Sauvegardez la base de données publiée.
  3. Retour du fichier journal minimisation du temps de lequel il prend parcourir les étapes d'abonnement et procédez comme suit dans la procédure suivante.
Pour configurer l'abonnement, procédez comme suit :
  1. Placez la base de données publiée en mode mono-utilisateur pour empêcher des modifications d'être apportées à la base de données en exécutant la procédure stockée suivante . Cela empêche des modifications d'être apportées à la base de données. Il s'agit d'une étape très importante ; vous vous assurez que l'éditeur reste synchronisé avec l'abonné Vous devez arrêter tous les agents de réplication qui sont reliés à la base de données avant de pouvoir exécuter la procédure stocké.
  2. Si vous utilisez la méthode de sauvegarde intégrale, sauvegardez la base de données publiée. Si vous utilisez la méthode de journal des transactions, sauvegardez le journal des transactions de la base de données publiée.
  3. Créez un nouvel abonnement à votre publication de sélection transmettre les données et le schéma.
  4. Pendant que vous définissez l'abonnement, recherchez l'écran Distribution Agent Schedule. Modifiez la tâche une seule fois (Cela empêche l'Agent de distribution de s'exécuter après la base de données [ et la sauvegarde de journal des transactions] avoir restauré à l'abonné).
  5. Supprimez la base de données au mode mono-utilisateur en utilisant l'appel suivant de procédure stockée . Parce que l'abonnement est configuré toutes les modifications sont transférées vers la base de données de distribution
  6. Restaurez la base de données à l'abonné Si vous utilisez la méthode de journal des transactions, restaurez la sauvegarde complète et la sauvegarde de journal des transactions. L'Agent de distribution ne doit pas être en cours d'exécution à ce moment-là S'il l'est il empêchera la restauration de la base de données La planification de l'Agent a été modifiée à l'étape 4
  7. Générez les procédures , et qui sont utilisées au cours de réplication. Vous pouvez générer les instructions CREATE PROCEDURE pour ces procédures (les procédures varient en fonction du type de réplication et la version de SQL Server) en exécutant une des procédures suivantes :
    1. Pour SQL Server 2000 :

      Exécutez sur le Publisher. Cette procédure génère du texte pour les procédures stockées qui sont requises à l'abonné Exécutez le script généré sur la base de données d'abonnement
    2. : pour la mise à jour immédiate et abonnés en file d'attente

      Remarque la mise à jour immédiate et abonnés en file d'attente sont une exception à l'étape 4. Vous devez exécuter l'Agent de distribution avant d'appliquer la sortie pour le sp script synctran commands à la base de données d'abonné parce que l'Agent de distribution génère une table de support qui est nommée MSsubscription agents. Après vous fonctionné avec l'Agent de distribution, appliquez le script qui est généré par sp script synctran commands à la base de données d'abonnés. Vous devez également exécuter la procédure sp scriptpublicationcustomprocs stocké sur le Publisher et le script généré sur la base de données d'abonnement pour des abonnés de mise à jour immédiats.

    3. Vous devez toutefois appliquer la sortie pour à la base de données d'abonné, pouvez ensuite appliquer la sortie générée lorsque vous exécutez et devez d'abord exécuter l'Agent de distribution pour générer une table de support nommée . Vous devez également exécuter sur le Publisher pour des abonnés de mise à jour immédiate. Exécutez le script généré sur la base de données d'abonnement
    4. Pour SQL Server 7.0 : , , ,

      Ces procédures génèrent des scripts pour les procédures qui sont requises à l'abonné Exécutez ces scripts sur la base de données d'abonnement
  8. Démarrez l'Agent de distribution Vous pouvez configurer l'Agent de distribution pour qu'il s'exécute en continu Pour ce faire, ajoutez à la ligne de commande d'Agent de distribution.
Pour plus d'informations cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft
299903 CORRIGER : sp_scriptpublicationcustomprocs génère des procédures de réplication stockée
back to the top

Réplication de fusion

Remarque les abonnements No-synch ne sont pas pris en charge d'abonnements extraits de fusion.

Si vous utilisez la sauvegarde ou la restauration pour configurer un abonnement à une publication de fusion avec l'option no-sync, suivez ces étapes :
  1. Publiez la base de données et ensuite exécutez l'Agent de capture instantanée. Si la base de données a été publiée, vous devez qu'exécuter l'Agent de capture instantanée.

    Toutes les modifications apportées dans l'éditeur sont maintenant enregistrées dans les tables systèmes de réplication de fusion.
  2. Sauvegardez la base de données publiée et le restaurez ensuite, sur l'abonné.
  3. Créez un nouvel abonnement et puis sélectionnez .
  4. Exécutez l'Agent de fusion

    Lorsque l'Agent de fusion est exécuté, il utilise d'abord l'instantané pour créer la fusion tables de réplication. Toutes les modifications apportées étant donné que la capture instantanée a été générée sont appliquées à l'abonné :
    • Si vous avez ajouté toutes les lignes entre l'étape 1 et l'étape 2 dans cette procédure, vous verrez les lignes nouvelles comme des mises à jour sur l'abonné. Les lignes existent déjà à cause de la restauration. Vous verrez par conséquent les lignes nouvelles sur l'abonné.
    • Si vous avez supprimé toutes les lignes entre l'étape 1 et l'étape 2 dans cette procédure, l'Agent de fusion signale qu'aucunes modifications ne doivent être apportées parce que les lignes n'existent pas sur l'abonné. La sauvegarde ou la restauration ont été effectuées une fois que les lignes ont été supprimées dans l'éditeur.
    • Si toutes les lignes ont été mises à jour entre l'étape 1 et l'étape 2 dans cette procédure, vous verrez cela en tant que mises à jour sur l'abonné.
back to the top
Plus d'informations
Pour plus d'informations comment sur initialiser un abonnement transactionnel à partir d'une sauvegarde dans SQL Server 2005, visitez le site Web Microsoft Developer Network ( MSDN ) suivant :Pour plus d'informations comment sur initialiser un abonnement de fusion à partir d'une sauvegarde dans SQL Server 2005, consultez le site Web MSDN suivant :

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 320499 - Dernière mise à jour : 12/07/2015 10:24:20 - Révision : 7.0

Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 Enterprise Edition, Microsoft SQL Server 2000 Developer Edition

  • kbnosurvey kbarchive kbhowtomaster KB320499 KbMtfr kbmt
Commentaires