Composants internes de la réplication transactionnelle SQL Server

La réplication transactionnelle SQL Server est l'une des techniques de réplication les plus courantes utilisées pour partager, copier ou distribuer des données vers plusieurs destinations. Dans cet article, nous discuterons de la réplication, des différents types de réplication et accorderons une attention particulière au travail de réplication transactionnelle.

Qu'est-ce que la réplication transactionnelle SQL ?

La réplication est la technologie SQL Server permettant de copier ou de distribuer des données d'une base de données à une autre tout en maintenant la cohérence des données.

La réplication peut être utilisée pour transférer des données d'une base de données à une autre

sur la même instance ou sur une autre instance du même serveur ;
ou sur plusieurs serveurs à un ou plusieurs emplacements.

Tout d'abord, nous devons parcourir l'architecture de réplication et comprendre les terminologies de réplication.

Architecture et terminologie de la réplication SQL Server

L'éditeur est l'instance de la base de données source qui publie les modifications de données pouvant être distribuées à une autre base de données. Données d'un éditeur unique peut être envoyé à un abonné unique ou plusieurs Abonnés .
Abonné est l'instance de base de données de destination où nous distribuons les modifications de données capturées à partir de la base de données de l'éditeur. L'abonné peut être soit une instance d'éditeur, soit une autre instance du serveur d'éditeur/un autre serveur au même emplacement/emplacement distant. Avant que les modifications de données ne soient distribuées à l'instance de la base de données de l'abonné, ces données sont stockées dans le distributeur .
Le distributeur est une base de données qui stocke les journaux des modifications capturés à partir des bases de données de l'éditeur. Lorsqu'un serveur est activé en tant que distributeur, il crée une base de données système nommée base de données de distribution .

Selon l'emplacement des bases de données de distribution, ils peuvent être classés comme distributeurs locaux ou distants.

– Distributeur local est une base de données de distribution résidant sur l'instance de base de données Publisher.
– Distributeur à distance est une base de données de distribution résidant soit dans l'instance de base de données de l'abonné, soit dans toute autre instance SQL Server en dehors de l'instance de base de données de l'éditeur.

Le facteur décisif est l'endroit où placer la base de données de distribution sur l'instance Publisher (une autre instance). cela dépend des ressources du serveur disponibles pour gérer la charge de distribution de données.

Selon la manière dont les données seront envoyées de la base de données de distribution à l'instance de l'abonné, elles peuvent être classées soit en Push ou Pull Abonnements .

– Poussez l'abonnement signifie que la base de données de distribution prend la responsabilité de transmettre les données à l'instance de base de données de l'abonné.
– Pull Abonnement signifie que l'instance de base de données de l'abonné prend la responsabilité d'extraire les données disponibles de la base de données de distribution et de les appliquer à la base de données de l'abonné.

Articles sont l'unité fondamentale de la réplication. Il indique toutes les modifications de données sur cet objet de base de données ou cet article qui seront répliquées de l'éditeur vers l'abonné. L'article peut être une table, une vue, une vue indexée, une procédure stockée ou la fonction définie par l'utilisateur.
Publications sont une collection d'un ou plusieurs articles de la base de données dans Publisher.
Abonnement définit quelle publication sera reçue. En outre, il détermine à partir de quelle publication et selon quel calendrier les données sont répliquées. L'abonnement peut être Push ou Pull (de la publication à l'abonnement).
Agents de réplication sont des programmes autonomes responsables du suivi des modifications et de la distribution des données entre l'éditeur, le distributeur et l'abonné. Tous les Replication Agents s'exécutent en tant que Jobs sous SQL Server Agent. Ainsi, il peut être administré via SSMS sous SQL Server Agent Jobs ou Replication Monitor. Les types d'agents de réplication suivants sont disponibles :
Agent d'instantané – Utilisé par presque tous les types de réplication. L'Agent d'instantané s'exécute à partir du serveur contenant la base de données de distribution. Il prépare le schéma et les données initiales de tous les articles inclus dans une publication sur un éditeur. En outre, il crée les fichiers d'instantanés dans un dossier d'instantanés et enregistre les détails de synchronisation dans la base de données de distribution.
Agent de lecture du journal – Utilisé par la réplication transactionnelle. L'objectif est de lire les modifications de données des articles activés pour la réplication à partir des journaux de transactions de la base de données de l'éditeur et stockés dans la base de données de distribution. l'Agent de lecture du journal s'exécute à partir du serveur de distribution.
Agent de distribution – Utilisé par la réplication transactionnelle et d'instantané. Il applique les fichiers instantanés initiaux et les transactions en attente incrémentielles ou disponibles de la base de données de distribution à la base de données de l'abonné. L'agent de distribution s'exécute à partir du serveur de distribution pour les abonnements push et du serveur d'abonnés pour les abonnements pull.
Agent de fusion – Utilisé par la réplication de fusion uniquement. Il applique les fichiers instantanés initiaux et la réconciliation des modifications différentielles ou incrémentielles sur l'éditeur ou l'abonné. L'Agent de fusion s'exécute sur le serveur de distribution pour la réplication push et à partir du serveur de l'abonné pour les abonnements pull.
Agent de lecture de file d'attente – Queue Reader Agent est utilisé par la réplication transactionnelle avec l'option de mise à jour en file d'attente. Il déplace les modifications de l'abonné vers l'éditeur. L'agent de lecture de file d'attente s'exécute à partir du serveur de distribution.
Tâches de maintenance de réplication – Comme expliqué précédemment, tous les agents de réplication sont des programmes autonomes configurés lors de la configuration de la réplication. Ils s'exécutent en tant que travaux sous Travaux de l'Agent SQL Server. Les quelques tâches importantes à noter sont le nettoyage de la distribution :distribution, le nettoyage de l'historique des agents :distribution et le nettoyage des abonnements expirés.

Types de réplication dans SQL Server

Maintenant que nous connaissons la terminologie, plongeons dans les types de réplication.

Réplication transactionnelle . Comme son nom l'indique, chaque transaction ou changement de données dans la portée transactionnelle sur l'éditeur sera envoyé à l'abonné en temps quasi réel avec des retards mineurs en fonction de la bande passante du réseau et des ressources du serveur. La réplication transactionnelle utilise l'agent de lecture du journal pour lire les modifications de données à partir des journaux transactionnels de la base de données de l'éditeur. Il utilise également l'Agent de distribution pour appliquer les modifications à l'Abonné. Occasionnellement, il peut utiliser l'Agent d'instantané pour prendre les données d'instantané initiales de tous les articles répliqués. La publication de réplication transactionnelle peut appartenir aux catégories ci-dessous :
- Réplication transactionnelle standard – L'abonné est une base de données en lecture seule du point de vue de la réplication transactionnelle. Toute modification effectuée par quiconque sur la base de données des abonnés ne sera pas suivie et mise à jour dans la base de données des éditeurs. La réplication transactionnelle standard est souvent appelée réplication transactionnelle.
- Réplication transactionnelle avec abonnements pouvant être mis à jour est une amélioration de la réplication transactionnelle standard qui suit les modifications de données qui ont lieu sur les abonnements. Chaque fois que des modifications de données sont initiées sur un abonnement pouvant être mis à jour, elles sont d'abord propagées à l'éditeur, puis aux autres abonnés.
- Réplication poste à poste est une amélioration de la réplication transactionnelle standard. Il propage des modifications cohérentes sur le plan transactionnel en temps quasi réel sur plusieurs instances de serveur.
- Réplication bidirectionnelle est une amélioration de la réplication transactionnelle standard qui permet à deux serveurs (limités à seulement 2 serveurs et donc nommés bidirectionnels) d'échanger les modifications de données entre eux avec n'importe quel serveur agissant en tant qu'éditeur (pour envoyer les modifications à un autre serveur) ou en tant qu'abonné (pour recevoir les modifications d'un autre serveur).
Fusionner la réplication – Prend en charge la capture des modifications de données qui ont lieu à la fois sur l'éditeur et l'abonné et les distribue à l'autre serveur. La réplication de fusion nécessite le ROWGUID colonne de la table Articles impliqués dans la réplication de fusion. Il utilise des déclencheurs pour capturer les modifications de données entre l'éditeur et l'abonné. En outre, il fournit les modifications sur les serveurs lorsque l'éditeur et l'abonné sont connectés au réseau. La réplication de fusion utilise l'agent de fusion pour répliquer les modifications de données sur l'éditeur et l'abonné.
Réplication d'instantanés – Comme son nom l'indique, Snapshot Replication ne s'appuie ni sur les journaux transactionnels ni sur les déclencheurs pour capturer les modifications. Il prend un instantané des articles impliqués dans la publication et l'applique à l'abonné avec les enregistrements disponibles au moment de l'instantané. La réplication d'instantané utilise l'agent d'instantané pour prendre un instantané de l'éditeur et utilise l'agent de distribution pour appliquer ces enregistrements à l'abonné.

Réplication transactionnelle SQL Server

La réplication transactionnelle est généralement préférée dans les scénarios où la base de données de l'éditeur OLTP comporte de nombreuses activités d'INSERT/UPDATE et/ou de DELETE de données.

Étant donné que l'instance du serveur Publisher a d'énormes E/S DISQUES, la génération de rapports peut entraîner de graves blocages. Cela peut également avoir un impact sur les performances du serveur. Par conséquent, un autre serveur avec des données en temps quasi réel est bon pour décharger les exigences de création de rapports.

L'une des exigences fondamentales de la réplication transactionnelle est que les tables répliquées doivent disposer d'une clé primaire.

Nous pouvons résumer le fonctionnement de la réplication transactionnelle. Jetez un œil au diagramme d'architecture de réplication transactionnelle ci-dessous tiré de la documentation officielle de Microsoft.

La Publication est créée sur la base de données de l'éditeur qui comprend la liste des articles à répliquer dans la base de données de l'abonné.

La réplication transactionnelle sera généralement initialisée de l'éditeur au distributeur via l'agent de capture instantanée ou des sauvegardes complètes. L'Agent de capture instantanée est pris en charge via l'assistant de configuration de la réplication. La sauvegarde complète est prise en charge via des instructions TSQL pour initialiser la réplication transactionnelle.

L'agent de lecture du journal analyse le journal des transactions de la base de données de l'éditeur à la recherche d'articles suivis. Ensuite, il copie les modifications de données du journal des transactions vers la base de données de distribution.

La base de données de distribution peut être dans Publisher ou Subscriber ; il peut également s'agir d'une autre instance SQL Server indépendante.

Notez également les éléments suivants :

L'agent de lecture du journal s'exécute en continu à partir du serveur de distribution pour rechercher de nouvelles commandes marquées pour la réplication. Toutefois, si vous ne souhaitez pas exécuter en continu et que vous souhaitez plutôt exécuter un programme, nous pouvons modifier le travail SQL de l'agent de lecture du journal qui sera créé.
L'agent de lecture du journal récupère tous les enregistrements marqués pour la réplication à partir du journal transactionnel par lots et les envoie à la base de données de distribution.
L'agent de lecture du journal récupère uniquement les transactions validées dans le journal des transactions de la base de données de l'éditeur. Ainsi, toute requête de longue durée sur la base de données de l'éditeur peut avoir un impact direct sur la réplication car elle attend la fin de la transaction active.

L'agent de distribution récupère toutes les nouvelles commandes non distribuées de la base de données de distribution et les applique à la base de données d'abonnement via le mécanisme Push ou Pull. Comme mentionné précédemment, si le distributeur d'abonnement Push s'approprie l'application des modifications de la base de données de distribution à l'abonné, tandis que dans l'abonnement pull, la base de données de l'abonné s'approprie la récupération des modifications de la base de données de distribution à l'abonné.

Une fois que les enregistrements sont distribués avec succès à partir de la base de données de distribution à l'abonné, ils seront marqués comme distribués et marqués pour suppression de la base de données de distribution. L'une des tâches de maintenance de la réplication de clé nommée Distribution Clean Up :la tâche de distribution s'exécute une fois toutes les 10 minutes pour supprimer les enregistrements distribués de la base de données de distribution afin de maintenir la taille de la base de données de distribution sous contrôle.

Avec l'explication détaillée des concepts de réplication et de réplication transactionnelle, nous pouvons mettre la main dessus en configurant la réplication pour AdventureWorks base de données et vérification de la réplication pour chaque composant discuté théoriquement.

Configuration de la réplication transactionnelle étape par étape (via l'interface graphique SSMS)

La configuration de la réplication transactionnelle implique 3 étapes majeures :

Configuration de la base de données de distribution
Création de publications
Création d'abonnement

Avant d'essayer de configurer la réplication, assurez-vous que les composants de réplication sont installés dans le cadre de l'installation de SQL Server ou utilisez le support SQL Server pour installer les composants de réplication, car ils sont nécessaires pour la tâche.

Dans SSMS, connectez-vous à l'instance de base de données de l'éditeur et faites un clic droit sur Réplication :

La distribution n'est pas configurée pour le moment. Par conséquent, nous avons l'option Configurer la distribution. Nous pouvons soit configurer la base de données de distribution à l'aide de l'assistant de configuration de la distribution, soit via l'assistant de création de publication.

Pour configurer la base de données de distribution et la publication, suivez les étapes ci-dessous :

Développer Réplication et faites un clic droit sur Nouvelle publication .

Assistant Nouvelle publication Va lancer. Cliquez sur Suivant pour voir le Distributeur options de configuration.

Par défaut, il choisit le serveur Publisher pour contenir la base de données de distribution. Si vous souhaitez utiliser une base de données de distribution à distance, choisissez la deuxième option. Cliquez sur Suivant .

L'option suivante consiste à configurer le dossier d'instantanés . Changez-le dans le dossier requis. Sinon, il sera créé sur le chemin du dossier d'installation de SQL Server par défaut. Cliquez sur Suivant .

Sélectionnez la base de données de publication (ici c'est AdventureWorks ) et cliquez sur Suivant .

Choisissez le type de publication – Réplication transactionnelle . Cliquez sur Suivant .

Choisissez Articles pour cette parution. À des fins de test, sélectionnez tous les tableaux et Vues :

Avant de cliquer sur Suivant , développez à nouveau les tableaux pour vérifier certains problèmes.

Certains tableaux sont signalés par des icônes rouges. Lorsque nous cliquons sur ces tables, nous voyons l'avertissement indiquant qu'une table ne peut pas être répliquée car elle n'a pas de clé primaire, l'une des exigences cruciales pour la réplication transactionnelle. Nous reviendrons plus tard plus en détail. Maintenant, cliquez sur Suivant .

Une page avec Problèmes d'article liés aux dépendances apparaîtront. Cliquez sur Suivant .

L'option suivante consiste à Filtrer les lignes du tableau – puisque nous testons la réplication de base, nous pouvons l'ignorer. Cliquez sur Suivant .

Configurer l'agent d'instantané – ignorez et cliquez sur Suivant .

Agent Paramètres – cliquez sur Paramètres de sécurité pour configurer le compte afin d'exécuter l'agent Snapshot et l'agent de lecture du journal sous celui-ci.

Ensuite, modifiez le processus de l'agent d'instantané pour s'exécuter sous le compte de service de l'agent SQL Server.

Définir l'agent de lecture du journal pour se connecter à l'éditeur > en usurpant l'identité du compte de processus . Cliquez sur OK .

La sécurité de l'agent sera mise à jour.

Ainsi, nous avons configuré le distributeur et tous les éléments de la Publication comme Articles , Agent d'instantanés , Agent de lecture du journal , et Agent des valeurs mobilières . Nous avons presque terminé la création de la publication via l'assistant.

Si vous avez besoin d'étudier plus en détail les scripts TSQL utilisés pour créer la publication, nous pouvons cocher la case Générer un fichier de script pour créer la publication option. Sinon, cliquez sur Suivant .

Puisque j'ai choisi d'enregistrer le fichier, l'assistant me permet de définir le chemin du fichier de script et nom . Fournissez ces détails et cliquez sur Suivant .

L'assistant demande enfin le Nom de la publication , je l'ai nommé AdventureWorks_pub avec le nom de la base de données et des mots-clés pour l'indiquer comme publication pour une identification plus facile.

Vérifiez toutes les données fournies sur le résumé page et cliquez sur Terminer .

L'assistant affichera la progression dans Création de la publication . Une fois terminé, nous verrons la confirmation. Cliquez sur Fermer .

Pour vérifier la création réussie du Distributeur (Base de données de distribution), développez les bases de données système :

Pour vérifier la création réussie de Publication , développez Publication locale :

Nous avons configuré la base de données de distribution et créé la base de données de publication sur la base de données AdventureWorks avec succès. Nous pouvons maintenant procéder à l'abonnement création

Faites un clic droit sur la nouvelle Publication nous venons de créer et de sélectionner Nouveaux abonnements :

L'assistant de nouveaux abonnements apparaîtra. Pour démarrer le processus, cliquez sur Suivant .

La publication page demande de s'assurer que la Publication et Éditeur bases de données sont sélectionnés. Cliquez sur Suivant .

Définir l'agent de distribution soit Pousser ou Tirer Abonnement. Nous allons utiliser le serveur de l'éditeur en tant qu'abonné, et ce type n'aura aucun impact. Par conséquent, nous laissons la valeur par défaut Push Abonnement. Cliquez sur Suivant .

Sélectionnez les abonnés (base de données). Je sélectionne AdventureWorks_REPL restauré à partir de la même sauvegarde de la base de données AdventureWorks. Cliquez sur Suivant .

Définir la sécurité de l'agent :

Comme je vais tout faire sur un seul serveur, j'utilise le compte de service d'agent .

La fenêtre suivante présente la sécurité de l'agent de distribution valeurs déjà configurées. Cliquez sur Suivant .

Calendrier de synchronisation – laissez-le par défaut. Cliquez sur Suivant .

Initialiser les abonnements – laissez-le avec les valeurs par défaut. Cliquez sur Suivant .

Après avoir fourni tous les détails nécessaires, vous pourrez terminer le processus de création de l'abonnement. Vérifiez le Générer le fichier de script… option pour étudier les scripts plus tard et cliquez sur Suivant .

Indiquez le chemin pour enregistrer les fichiers, cliquez sur Suivant .

Consultez le résumé et vérifiez toutes les valeurs configurées. Une fois vérifié, cliquez sur Terminer .

La création de l'abonnement est terminée. Cliquez sur Fermer .

Nous pouvons maintenant voir l'abonnement affiché sous notre Publication .

Configurer l'agent d'instantané

Notre prochaine étape consiste à travailler sur l'instantané Agent pour envoyer les données initiales de l'éditeur à Abonné .

Avant d'y entrer, nous devons remarquer le Moniteur de réplication . Cet outil essentiel est disponible dans SSMS pour afficher l'état de la réplication à différents niveaux, au niveau du serveur, au niveau de la base de données de l'éditeur, au niveau de l'abonnement et au niveau des agents de réplication.

Faites un clic droit sur Réplication /Publication locale /Abonnement local /Publication ou l'abonnement nous avons créé pour lancer le Moniteur de réplication comme indiqué ci-dessous :

Dans le moniteur de réplication , développez Publisher Server (RRJ) > Publication ([AdventureWorks] :AdventureWorks_pub) pour afficher les détails de l'abonnement. Faites un clic droit sur Abonnement et sélectionnez Afficher les détails .

Comme nous pouvons le voir, les informations sur l'instantané initial pour notre publication AdventureWorks_pub n'est pas encore disponible. Nous devrons exécuter le travail de l'agent Snapshot pour envoyer les données initiales à la base de données des abonnés .

Gardez cette fenêtre ouverte pour voir la progression de l'instantané après le démarrage de la tâche de l'agent d'instantané .

Faites un clic droit sur Publication > Afficher l'état de l'agent d'instantané :

L'agent n'a jamais été exécuté message indique que nous n'avons jamais exécuté l'Agent d'instantané. Cliquez sur Démarrer .

Pendant l'exécution de l'Agent d'instantané, vous pouvez suivre la progression :

Lorsque tous les instantanés sont créés, il produira le message de confirmation :

Nous pouvons voir les fichiers Snapshot créés récemment dans le dossier Snapshot pour lequel nous avons fourni le chemin plus tôt.

Une fois que tous les instantanés ont été appliqués par l'agent de distribution à la base de données des abonnés , il affichera l'état ci-dessous dans le moniteur de réplication ouvert fenêtre :

Bravo! Nous avons configuré avec succès la réplication transactionnelle à l'aide de Snapshot Agent.

Remarque :si nous avons une énorme base de données d'éditeurs, la création d'un instantané peut prendre beaucoup de temps. Ainsi, il est recommandé d'utiliser la sauvegarde complète de la base de données de l'éditeur au lieu d'exécuter l'agent d'instantané - nous aborderons ce problème dans les articles suivants.

Vérification des composants de réplication

Chaque composant de réplication peut être vérifié par les requêtes SSMS GUI et TSQL. Nous en discuterons dans d'autres articles, et ici nous expliquerons rapidement comment afficher les propriétés des composants ci-dessous.

Éditeur

Dans SSMS, cliquez avec le bouton droit sur Réplication > Propriétés de l'éditeur > Bases de données des publications :

Pour afficher les détails sur l'éditeur , exécutez les requêtes ci-dessous sur la base de données de distribution.

USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO

Abonné

Les informations sur l'abonné peuvent être obtenues avec la requête ci-dessous dans SSMS.

USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info

Distributeur

Dans SSMS, cliquez avec le bouton droit sur Réplication > Distributeur Propriétés :

Cliquez sur Éditeurs pour afficher la liste de tous les éditeurs utilisant cette base de données de diffusion.

Dans SSMS, nous pouvons exécuter la requête ci-dessous pour obtenir les mêmes détails.

USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO

Articles

Faites un clic droit sur Publication > Propriétés de la publication > Articles . Vous verrez la liste de tous les articles disponibles. Les propriétés des articles individuels peuvent être modifiées en cliquant sur Propriétés de l'article aussi.

USE AdventureWorks
GO
-- To View all articles available under a Publication
exec sp_helparticle @publication = 'Adventureworks_pub'
GO
-- To View all article columns for a particular article available under a Publication
exec sp_helparticlecolumns @publication = 'Adventureworks_pub', @article = 'Address'
GO
USE distribution
GO
SELECT * from MSArticles

Publications

Faites un clic droit sur Publication > Propriétés :

Dans SSMS, nous pouvons exécuter la requête ci-dessous pour afficher les propriétés de la publication :

USE AdventureWorks
GO
exec sp_helppublication
GO
USE distribution
GO
SELECT * FROM MSPublications

Abonnement

Faites un clic droit sur Abonnement > Propriétés d'abonnement :

Dans SSMS, nous pouvons exécuter le script ci-dessous pour obtenir les informations d'abonnement :

USE AdventureWorks
GO
exec sp_helpsubscription
GO
USE distribution
GO
SELECT * FROM MSsubscriptions
GO

Agents de réplication

Sous Tâches de l'Agent SQL Server , nous pouvons trouver les emplois spécifiques créé pour tous les agents de réplication :

Dans SSMS, nous pouvons exécuter la requête pour savoir quelle tâche est la tâche d'agent de lecture de journal nécessaire , Tâche d'agent d'instantané , et Emplois d'agent de distribution . En outre, nous pouvons voir la tâche de nettoyage de l'agent de distribution et plusieurs autres tâches liées à la réplication créées pendant que nous définissions la publication et les abonnements en interne.

Fonctionnement de l'agent de lecture du journal

L'Agent de lecture du journal lit toutes les données validées à partir des journaux transactionnels de la base de données de l'éditeur et les transmet à la base de données du distributeur. Même si Microsoft ne fournit pas de moyen officiel de lire les journaux transactionnels, il existe peu de fonctions non documentées comme fn_dblog() et fn_dump_dblog() qui peut lire les données des fichiers journaux. Cependant, ces fonctions ne sont pas documentées et ne sont pas couvertes par le support Microsoft. Ainsi, nous ne les explorerons pas plus avant.

Comment l'agent de distribution fournit les modifications de données à la base de données d'abonnés

Une fois les données écrites dans la base de données de distribution, nous pouvons lire comment ces données sont stockées dans les tables de distribution. Pour cela, nous appliquons le sp_browsereplcmds procédure - il récupère les enregistrements à travers les MSrepl_commands et MSrepl_transactions tableaux.

À des fins d'apprentissage, prenons un tableau à 3 colonnes nommé Person.ContactType :

L'abonnement créé créera 3 procédures pour chaque article faisant partie de la publication dans la base de données de l'abonné avec les conventions de dénomination ci-dessous :

dbo.sp_MSins_
dbo.sp_MSupd_
dbo.sp_MSdel_

Pour l'article Person.ContactType Table, nous pouvons voir les procédures ci-dessous créées dans la base de données des abonnés :

dbo.sp_MSins_PersonContactType – INSÉRER nouveaux enregistrements capturés à partir de la base de données des journaux de transactions de l'éditeur, puis propagés à la base de données de distribution.
dbo.sp_MSupd_PersonContactType – MISE À JOUR modifications capturées à partir de la base de données des journaux de transactions de l'éditeur, puis propagées à la base de données de distribution.
dbo.sp_MSdel_PersonContactType – SUPPRIMER records captured from Transaction Logs of Publisher database and then propagated to the distribution database.

Script of the dbo.sp_MSins_PersonContactType Procedure

As you can see, it’s a straightforward INSERT statement that comes out of the distribution database:

ALTER procedure [dbo].[sp_MSins_PersonContactType]
    @c1 int,
    @c2 nvarchar(50),
    @c3 datetime
as
begin  
	insert into [Person].[ContactType] (
		[ContactTypeID],
		[Name],
		[ModifiedDate]
	) values (
		@c1,
		@c2,
		@c3	) 
end  
GO

Script of the dbo.sp_MSupd_PersonContactType Procedure

The script relies on the Primary Key values to identify the unique record for updating:

ALTER procedure [dbo].[sp_MSupd_PersonContactType]
		@c1 int = NULL,
		@c2 nvarchar(50) = NULL,
		@c3 datetime = NULL,
		@pkc1 int = NULL,
		@bitmap binary(1)
as
begin  
	declare @primarykey_text nvarchar(100) = ''
update [Person].[ContactType] set
		[Name] = case substring(@bitmap,1,1) & 2 when 2 then @c2 else [Name] end,
		[ModifiedDate] = case substring(@bitmap,1,1) & 4 when 4 then @c3 else [ModifiedDate] end
	where [ContactTypeID] = @pkc1
if @@rowcount = 0
    if @@microsoftversion>0x07320000
		Begin
			if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
			Begin
				
				set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
				exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13233 
			End
			Else
				exec sp_MSreplraiserror @errorid=20598
		End
end 
GO

Script of the dbo.sp_MSdel_PersonContactType Procedure

This script relies on the Primary Key values to identify a unique record for deleting records from the Subscriber :

ALTER procedure [dbo].[sp_MSdel_PersonContactType]
		@pkc1 int
as
begin  
	declare @primarykey_text nvarchar(100) = ''
	delete [Person].[ContactType] 
	where [ContactTypeID] = @pkc1
if @@rowcount = 0
    if @@microsoftversion>0x07320000
		Begin
			if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
			Begin
				
				set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
				exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13234 
			End
			Else
				exec sp_MSreplraiserror @errorid=20598
		End
end  
GO

This clearly explains why Transactional Replication enforces the Primary Key as a key requirement for tables to be added as part of Replication .

Now, let’s see the Transactional Replication in action. Let’s change some data in the Publisher database. For simplicity, I’ll take the same Person.ContactType tableau.

Executing the SELECT statement on the table yields 20 records:

Next, I INSERTed a sample record into the Person.ContactType tableau :

And, I UPDATE the newly inserted record:

DELETE the newly inserted record from the table:

We need to verify these transactions in Replication using sp_browsereplcmds

Changes from Person.ContactType were captured from the Transactional Logs of Publisher Database (AdventureWorks ) and sent to the Distribution database in the same order. Later, it was propagated to the Subscriber Database (AdventureWorks_REPL ).

Conclusion

Thanks for reading this long power-packed article! We have gone through a variety of topics, such as:

Replication Architecture and Terminologies
SQL Server Replication Types
SQL Server Transactional Replication in Detail
SQL Server Transactional Replication Configuration (Default approach)
SQL Server Transactional Replication Verification
SQL Server Transactional Replication in action

I hope that you’ve found lots of helpful information in this article. In subsequent parts, we’ll explore troubleshooting various issues that are frequently encountered in Replication, and learn how to handle them more efficiently.