Comment fonctionne la réplication snapshot

comme un ensemble de fichiers
.bcp en exécutant l’utilitaire de
ligne de commande snapshot.exe. A
noter que dans SQL Server 2000, on
peut aussi définir un article d’après
une vue, une procédure cataloguée,
ou une UDF (user-defined function).

Dans la seconde phase, le Distribution Agent copie l’ensemble
de fichiers .bcp dans les bases de données
cible (les abonnés) en exécutant
l’utilitaire de ligne de distrib.exe. Les utilitaires snapshot.exe et distrib.exe
utilisent bcp pour copier les articles un
à  la fois. Le Snapshot Agent copie les
données à  partir des fichiers .bcp en
exécutant une simple instruction SELECT
pouvant contenir un filtre de colonne
et une clause WHERE (pour filtrer
des lignes). Ensuite, le Snapshot
Agent écrit le jeu de résultats dans des
fichiers .bcp. Quand le Distribution
Agent copie (insère) les fichiers .bcp
dans les tables de la base de données,
il doit supprimer les lignes existantes,
éventuellement journaliser les suppressions
et les insertions, et maintenir
les index des tables.

Avant d’entamer cette opération en
deux phases pour répliquer vos données,
vous devez établir un cadre à  cet
effet. Voyons les étapes par défaut pour
établir la réplication snapshot.

Définir et configurer les publications
et les abonnements. Vous pouvez
facilement définir et configurer la
réplication snapshot en utilisant
Enterprise Manager ou les procédures
cataloguées du système. En principe,
on crée une nouvelle publication en
sélectionnant d’abord les articles que
l’on veut inclure puis en définissant les
propriétés pour la publication et les articles.
Ensuite, on utilise Enterprise
Manager pour ajouter les abonnements,
un à  la fois, qui abonnent à  tous
les articles de la publication. On peut
aussi utiliser la procédure cataloguée
sp_addsubscription pour ne sélectionner
que les articles de publication auxquels
on veut s’abonner ou tous les
articles. On appelle la procédure en
définissant le paramètre @article pour
chaque nom d’article, un à  la fois, ou
en indiquant all pour tous les articles.
Dans une fenêtre Query Analyzer, par
exemple, on émet l’appel

EXEC sp_addsubscription @publication = N'pubs',
@article = N'authors', @subscriber = N'CGIS1',
@destination_db = N'pubs', @sync_type =
N'automatic', @update_mode = N'read only',
@offloadagent = à˜, @dts_package_location =
N'distributor',
GO

Attribuer les Snapshot et Distribution agents. Après avoir défini et configuré la publication et les abonnements, Create Publication Wizard d'Enterprise Manager attribue un Snapshot Agent à  chaque publication. De plus, par défaut, Create Push Subscription Wizard d'Enterprise Manager n'attribue qu'un Distribution Agent pour distribuer toutes les publications dans une base de données auxquelles un abonné souscrit. Par exemple, un abonné pourrait s'abonner à  la publication A et la publication B provenant toutes deux de la même base de données de publieurs et de publications. Par défaut, un seul Distribution Agent sert ces deux publications à  l'abonné. Si les Snapshot agents de ces publications fonctionnent en même temps, vous ne pouvez pas distribuer les deux snapshots dans des programmes différents. Pour rendre le programme de distribution plus souple pour chaque publication dans un environnement de réplication à  grande échelle, je préfère attribuer un Distribution Agent à  la publication A et un à  la publication B. Pour attribuer un Distribution Agent séparé pour chaque publication dans un abonnement, allez à  la fenêtre Properties de la publication, cliquez sur l'onglet Subscription Options puis sélectionnez l'option Use a Distribution Agent that is independent of other publications from this database, illustrée dans la figure 1. Pour chaque publication, vous pouvez examiner le résultat de cette configuration dans Enterprise Manager en suivant le chemin indiqué dans le panneau gauche de la figure 2. Le panneau droit montre un Snapshot Agent et deux Distribution agents (un pour chaque publication dans chaque abonnement) pour la publication pubs1 dans la base de données Pubs mise en évidence dans le panneau gauche.

Attribuer les jobs Snapshot et Distribution Agent. Enterprise Manager définit un job SQL Server pour chaque Snapshot Agent et chaque Distribution Agent. Les agents effectuent la réplication en exécutant des étapes dans leurs jobs. Par défaut, le job d'un Snapshot Agent comprend trois étapes - Log agent startup message, Run agent, et Detect nonlogged agent shutdown. La figure 3 montre ces trois étapes sur l'onglet Steps dans la fenêtre CGIS1-EGH-address-28 Properties-CGIS1. La figure 4 montre la commande qui s'exécute pendant l'étape Run agent - qui exécute snapshot. exe. La syntaxe complète de la commande est la suivante :

snapshot -Publisher [CGIS1] -PublisherDB
[EGH] -
Distributor [CGIS1] -Publication [address]
-DistributorSecurityMode 1

Snapshot.exe copie les schémas,
les index et les enregistrements des articles
publiés, du publieur vers le distributeur.
Ensuite, dans le dossier
Snapshot du distributeur, snapshot.
exe sauvegarde les schémas d'articles
dans des fichiers script T-SQL .sch
(comme le montre le petit fragment de
code de la figure 5) et sauvegarde les
index dans des fichiers .idx (comme le
montre la figure 6). Enfin, les enregistrements
sont stockés dans des fichiers
.bcp. Chaque article a un ensemble de
fichiers .sch, .idx et .bcp.

Toujours par défaut, le job d'un
Distribution Agent comporte les trois
mêmes étapes que celles d'un
Snapshot Agent. Toutefois, son étape
Run agent exécute distrib.exe, que
montre le code de la figure 7. La syntaxe
complète de distrib.exe est la suivante
:

distrib -Subscriber [HERTSCHEN3] -

SubscriberDB [sde]

-Publisher [CGIS1] -Distributor CGIS1

-DistributorSecurityMode 1 -PublisherDB

[EGH]

Premièrement, distrib.exe applique les
schémas de tous les fichiers .sch à  une
base de données d'abonnement (par
commodité, je l'appelle l'étape sch).
Ensuite, il utilise bcp pour copier les enregistrements de tous les fichiers
.bcp dans les tables cible que l'étape
sch crée (l'étape bcp). Enfin, il applique
les index de tous les fichiers .idx
aux tables cible copiées (l'étape idx).

Snapshot.exe génère chaque ensemble
de fichiers .sch et .idx d'après
les propriétés d'articles que vous avez
définies dans l'onglet Snapshot de la
boîte de dialogue Properties de l'article
respectif, comme le montre la figure
8. Par exemple, le fait de sélectionner
l'option Delete data in the
existing table that matches the row
filter statement dans la boîte de dialogue
ADDRESS Properties de la
figure 8 ajoute l'instruction DELETE
FROM [ADDRESS] au fichier .sch que
la figure 5 montre pour l'article ADDRESS.
En revanche, si vous sélectionnez
l'option Delete all data in the existing
table (using TRUNCATE) dans la
figure 8, il en résulte une instruction
TRUNCATE TABLE [ADDRESS]. En
outre, le fait de sélectionner les options
Copy … indexes dans la figure 8
ajoute les instructions CREATE INDEX
au fichier .idx que montre la figure 6
pour l'article ADDRESS. A l'inverse, le
fait d'effacer toutes les options Copy
… indexes vide le fichier .idx. A noter
que dans SQL Server 2000, les index
sont toujours sauvegardés dans le fichier
.idx même si vous les effacez
dans Enterprise Manager. Pour forcer un fichier .idx vide, utilisez les procédures
sp_addarticle ou sp_changearticle
avec schema_option = '0x01',
comme le montre l'exemple suivant :

sp_changearticle 'pubs', 'authors',

'schema_option',

'∆x∆1', 1, 1

sp_addarticle @publication = N'pubs', @article

=

N'auhtors', @schema_option =

à˜xà˜à˜à˜à˜à˜à˜à˜à˜à˜à˜à˜à˜à˜à˜à˜1,