Le premier site francophone dédié au développement Pocket PC

SQL Serveur CE – Réplication de fusion entre deux Serveurs SQL Server 2000

Auteur Nicolas Vesperini Date 9 septembre 2002

Vous trouverez dans cet article comment créer une réplication de fusion entre 2 SQL Server 2000.

Quelques rappels et présentation du cas pratique

Avant toute chose, il nous faut nous constituer une base de données de référence. Hébergée sur un serveur LAN, elle sera répliquée sur un serveur placé en DMZ que nous pourrons alors utiliser comme référence pour notre PDA. L’idée étant d’éviter toute communication direct entre le LAN et l’extérieur, ce qui nous permet ainsi de réaliser un cas de figure tordu mais techniquement intéressant…

Une base de données SQL Server 2000 est composée de 2 types de fichiers distincts :

fichier de données (*.MDF) – Comme son nom l’indique, il contient les données des tables et des index. L’espace physique qui lui est réservé est réalisé par paquets de 64 Ko que l’on appelle des « Extensions ». Chaque extension se décompose en 8 pages de 8 Ko chacune. Les données y sont stockées par ligne et leur ordre est fonction de la présence et / ou de la nature de l’index.

fichier journal des transactions (*.LDF) – Il contient des enregistrements du journal plutôt que des pages allouées à partir des extensions.

Dans la saga Maurice fait son sport, nous allons créer la base de données « CodePpcApp » composée de 5 tables :

En travaillant sur cette référence, fixons-nous pour objectif de redescendre à Maurice ses informations personnelles (table CLIENT filtrée sur l’identifiant Maurice), les journaux (table JOURNAL) filtrés sur son ou ses sports favoris (tables CLISPO & SPORT). La table AUTEUR étant considérée comme non nécessaire à Maurice elle ne lui sera pas envoyée.

Réplication SQL SERVER 2000 Vs SQL Server 2000 : La Publication

Dans l’Entreprise Manager, cliquez droit sur votre base CodePpcApp pour sélectionner « Nouveau » puis « Publication » afin d’arriver à l’écran ci-dessous :

Cliquez sur suivant afin de choisir la base de données à publier. Ici, nous choisirons « CodePpcApp » puis cliquez sur suivant.

Ici, vous devrez choisir le type de réplication. Ce qui nous interesse pour notre cas est la « Merge réplication » (Cf SQL Server CE – Pourquoi et comment utiliser IIS pour les différentes réplications).

L’écran suivant permet de cibler le type de l’abonné. Cette réplication concernant 2 SQL Server 2000, cochez donc cette option

Il nous faut choisir désormais les articles à répliquer. Nous souhaitons toutes les tables excepté celle appelée « AUTEUR » d’où :

SQL Server 2000 vous propose d’opter entre une réplication massive ou une réplication incluant des filtres. Il existe 2 types de filtres. Le premier dit « verticale » est appliqué aux colonnes de vos articles. Logiquement, le second est appelé « Horizontale » et concerne les lignes d’enregistrements elles-mêmes.

Soucieux de n’envoyer à Maurice que ce qui lui est utile, au même titre que la table « AUTEUR » n’est pas présente, nous ne descendrons pas non plus le champs « SPO_NAME » de la table « SPORT ». En revanche, Maurice n’étant pas le seul intéressé, il nous faut mettre toutes les données à disposition parmi les articles filtrés verticalement. Le filtre horizontal sera, quant à lui, utilisé dans la réplication entre le serveur DMZ et le PDA lui même (Article prochain).

puis décochez le champs AUT_ID de la table JOURNAL

SQL Server 2000 se préoccupe maintenant de savoir si l’abonné sera de type anonyme ou non. Dans cette réplication, les 2 serveurs pouvant être identifiés, nous pouvons restreindre l’accès abonné à un serveur déterminé, d’où :

Ultime étape (ouf !), planifier le traitement de l’agent qui aura la charge du Snapshot. Laissez par défaut pour notre exemple. Zou, cliquez sur Finish et la réplication est terminée et vous devez obtenir quelques chose dans ce style :

Réplication SQL SERVER 2000 Vs SQL Server 2000 : La Subscription

Une petite precision avant de démarrer le paramètrage de notre abonné. Il existe en effet 2 types d’abonnements :

L’abonnement poussé : L’initiative d’envoyer les données, donc de répliquer, est à la charge de l’éditeur (Publisher).

L’abonnement tiré : C’est l’abonné qui ira solliciter l’éditeur afin de recevoir les données.

Vous comprenez donc qu’entre 2 SQL Server 2000, un abonnement tiré ou poussé est indifférent. En revanche, si l’abonné est un PDA, le seul abonnement possible sera tiré. Pour notre exmple, nous réaliserons donc un abonnement poussé sur cette première réplication afin d’étudier tous les cas de figures possibles sur le projet dans son ensemble.

Commencez par réaliser un clique droit sur la publication PUBèCodePpcApp_TO_CodePpcDMZ afin de sélectionner « Push New Subscription ». L’assistant se met en route…

Sélectionnez maintenant votre serveur SQL DMZ qui sera l’abonné (Précisons que 2 SQL Server 2000 peuvent cohabiter sur le même serveur physique…).

SQL Server 2000 vous propose de sélectionner votre base cible ou la créer. Créez la base CodePpcDmz et sélectionnez la.

Précisez par la suite qui est le « distributeur ». Dans un souci de facilité de paramétrage, mon Editeur fait aussi office de Distributeur ce qui m’évite une gestion de comptes utilisateurs NT inutile à expliquer ici.

Lors d’une réplication, la gestion des conflits, nous l’avons déjà évoqué est du type Maitre / Esclave. Ile st possible d’aller bien plus en détail en appliquant des règles SQL complexes selon la nature des données, d’une date, d’un abonné particulier ou que sais-je. Afin de marquer notre serveur LAN hébergeant CodePpcApp comme maître alimentez l’écran comme ceci :

Le prochain article abordera la seconde réplication impliquant le serveur DMZ (CodePpcDmz) et le PDA.

Des questions sur cet article ? N'hésitez pas à me contacter en inscrivant dans l'objet du message : Assistance SQL Server 2000 - PPC.