Developpez.com - SQL-Server
X

Choisissez d'abord la catégorieensuite la rubrique :


Les réplications avec Microsoft SQL Server

Avancé

Date de publication : 14.9.2007 , Date de mise à jour : 6.10.2008

Par fadace (Fabien Celaia)
 

Mise en place des différents types de réplication, plus particulièrement avec Microsoft SQL Server

               Version PDF (Miroir)   Version hors-ligne (Miroir)

I. Introduction
II. Réplications basiques
II-A. Par codage client
II-B. Par procédures stockées
II-C. Par déclencheurs
II-D. Par Workflow
III. Réplications évoluées
III-A. Activation de la réplication
III-B. Réplication transactionnelle
III-C. Réplication par fusion (merge)
III-D. Réplication par capture instantanée (snapshot)


I. Introduction

La synchronisation des données a toujours été un problème dans l'histoire de l'informatique en général, et des SGBDR en particulier. La normalisation des modèles a apporté une solution en l'évitant au maximum, l'information ne devant se trouver qu'à un seul endroit.

Mais il y a théorie et pratique : souvent, il est nécessaire de répliquer de l'information. Les bonnes raisons pour le faire sont nombreuses.

Ce petit document à pour but de vous faire appréhender la notion de réplication dans son sens large.

Il est basé sur le moteur Microsoft SQL Server 2005, car celui-ci offre plusieurs types de réplication et permet de les activer aisément.

Le dernier chapitre traitera des réplications sur d'autres types de SGBDR.


II. Réplications basiques


II-A. Par codage client

Avantages
Inconvénient
sqlcmd -E -S MSQLD1
1> begin tran
2> insert into DBSource1..MaTable (id, nom) values(1, "Repli Test 1")
3> insert into MSQLD2.DBCible1.dbo.MaTable (id, nom) values(1, "Repli Test 1")
4> go 

II-B. Par procédures stockées

Similaire sur le fond au codage client, cela permet de déplacer la problématique des connexions de l'applicatif à SQL Server.

Avantages
Inconvénient
sqlcmd -E -S MSQLD1
1> create procedure DBSource1..MaTable_ins (@i int, @v varchar(30))
2> as
3> BEGIN
4> declare @ret1 int
5> Begin tran
6> insert into DBSource1..MaTable (id, nom) values(@i, @v)
7> select @ret1 = @@error
8> insert into MSQLD2.DBCible1.dbo.MaTable (id, nom) values(@i, @v)
9> select @ret1 = @ret1 + @@error
10> if @ret1 > 0
11> rollback tran
12> else
13> commit 
14> END
15> GO

1> exec MaTable_ins (1, "Repli Test 1")
2> go 

II-C. Par déclencheurs

Avantages
Inconvénient
sqlcmd -E -S MSQLD1 -D DBSource1
1> CREATE TRIGGER MaTable_ins_trig
2> ON MaTable FOR INSERT
3> AS
4> BEGIN
5> INSERT INTO MSQLD2.DBCible1.dbo.MaTable (id, nom) 
6>			SELECT id, nom FROM inserted
7> END
8> GO

1> CREATE TRIGGER MaTable_del_trig
2> ON MaTable FOR DELETE
3> AS
4> BEGIN
5> DELETE MSQLD2.DBCible1..MaTable WHERE id IN (SELECT id FROM deleted)
6> END
7> GO

1> CREATE TRIGGER MaTable_upd_trig
2> ON MaTable FOR UPDATE
3> AS
4> BEGIN
5> UPDATE MSQLD2.DBCible1..MaTable
6> SET T1.nom = T2.nom
7> FROM  MSQLD2.DBCible1..MaTable T1 INNER JOIN inserted T2 ON T1.id = T2.id
8> END
9> GO

1> update MaTable set nom = "Test2" where id < 100 
2> go 

II-D. Par Workflow


III. Réplications évoluées

A la réplication est toujours associé le terme de latence (latency) : il qualifie le temps qu'il faut pour qu'une information soit répliquée d'une source à sa cible.

Afin de pouvoir déterminer ce temps, nous allons, dans les exemples suivants, tenter de répliquer une table que nous nommerons repli_latence et qui aura les spécificités suivantes:
CREATE TABLE repli_latence (
ID int identity primary key
lastcommit datetime)
GO
insert into repli_latence values(1, getdate())
GO
Cette table ne comportera qu'une seule ligne par réplication.

Cette ligne sera updatée de manière régulière à la date et l'heure courante.

La comparaison entre les 2 champs datetime dans les base source et cible nous donnera donc la latence.


III-A. Activation de la réplication

La fr documentation Microsoft vous apportera tout complément nécessaire au choix de réplication à mettre en place.

Quel que soit le type de réplication Microsoft que nous allons mettre en place, elle se base de toute manière sur une source de données. Chez Microsoft SQL Server, cette source est nommée une "Distribution".

Dans Microsoft SQL Server Manager Studio, choisissons l'instance qui nous servira de source.

Directement sous le niveau de l'instance, un sous-répertoire "Réplication" est accessible.

Dans son menu contextuel, choisissons "Configure Distribution".

Distributeur
Nous choisissons donc la première option puisque nous sommes parti de l'instance source.

SQL Server va devoir créer un répertoire pour snapshot. Ce répertoire doit se situer sur la partie locale des disques de l'instance.

Snapshot folder
Microsoft SQL Server va alors créer la base de donnée système pour la réplication nommée "Distribution".

Distribution DB
Un dernier coup d'oeil à nos choix avant que l'assistant ne démarre la phase d'installation de la base...

Résumé

III-B. Réplication transactionnelle

La réplication transactionnelle, appelée aussi à flux tendu est le modèle le plus aboutit et répandu dans le monde du SGBDR, surtout pour la raison qu'elle est transactionnelle, et donc qu'elle maintient une intégrité transactionnelle au sein de la réplication.

Puisque chaque transaction répliquée passe en tant que transaction SQL, elle s'ouvre aux réplications hétérogènes car il suffit alors de "transformer" la transaction pour qu'elle soit compatible avec les spécificités d'autres SGBDR.

La capture des modification est alors faite au sein du journal des transactions.

Au moment où une transaction modifie une table marquée comme répliquée (publiée), elle est envoyée à la réplication qui s'occupera alors de l'exécuter sur les cibles "abonnées" (subscriber) à cette publication.

Exemple chez Microsoft et ses concurrents

III-C. Réplication par fusion (merge)

Les changements de la table sources sont relevés par triggers.

C'est une réplication idéale lorsque les souscripteurs sont nombreux et leurs connexions asynchrones.

Les demandes pouvant être asynchrones, cette réplication nécessite donc une gestion des conflits éventuels.

Si plusieurs modifications ont été apportées entre 2 réplications, seul le dernier état va être appliqué.

Exemple chez Microsoft et ses concurrents

III-D. Réplication par capture instantanée (snapshot)

Il s'agit-là basiquement d'une réplication par copies chroniques.

A utiliser lorsque la latence entre source et cible peut être élevée.

Cette réplication inflence peu en terme de performance la base source, même si les changements sont extrêmement fréquents. Il convient cependant de choisir le temps de latence intelligement afin de ne pas péjorer les accès disques.



               Version PDF (Miroir)   Version hors-ligne (Miroir)

Valid XHTML 1.0 TransitionalValid CSS!

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2007 Fadace. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Contacter le responsable de la rubrique SQL-Server