> Tech > Affichage du travail

Affichage du travail

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

On peut visualiser les résultats du travail des assistants de réplication à  partir d'Enterprise Manager. Pour commencer, remarquez dans la figure 10 que la base de données Northwind est désormais disponible dans l'arborescence Replication Monitor, Publishers, TANYA. Si on étend le classeur de la base de données Northwind et qu'on

Affichage du travail

observe les procédures cataloguées,
on trouve sp_MSsync_ins_customers_1, sp_MSsync_upd_customers_1, et sp_MSsync_del_customers_1.
Ces procédures propagent les transactions confirmées de TANYA vers REBA. Observons
à  présent les procédures cataloguées de la base de données Test de REBA. On
trouve des procédures semblables, appelées sp_MSins_customers, sp_MSupd_customers,
et sp_MSdel_customers, qui propagent les transactions confirmées de REBA vers
TANYA.

Si on analyse les tables sur REBA, on constate que le processus
de réplication a ajouté la table Customers ainsi que les tables systèmes MSreplication_objects,
MSreplication_subscriptions, et MSsubscription_properties à  REBA. Ces tables
suivent l’éditeur et l’abonné, ainsi que les informations sur le type et la
fréquence de la réplication.

Sur TANYA, le répertoire SQL Server Agents indique que le processus
de réplication a ajouté plusieurs travaux de réplication. Les procédures cataloguées
étendues et système gèrent ces travaux de réplication, mais comment est-ce que
SQL Server identifie les paramètres à  passer aux procédures cataloguées ? Remarquez
dans la figure 10 que TANYA possède à  présent une base de données de distribution.
Lorsque nous avons configuré TANYA comme Distributeur, l’assistant de réplication
ajouté à  sa base de données de distribution 21 tables spécifiques à  la réplication
(à  côté des autres tables systèmes présentes dans chaque base de données par
défaut). Ces tables contiennent toutes les informations requises par les agents
de réplication et les procédures cataloguées spécifiques à  la réplication.

Pour vérifier si ce processus de réplication fonctionne, exécutez
la demande suivante sur le serveur TANYA :

Use NORTHWIND

update customers set contactname = « maria anderson »

where customer_id = ‘alfki’

Cette requête modifie le premier enregistrement de la table
Customers. A partir d’Enterprise Manager, on peut alors analyser le classeur
Log Reader Agents de TANYA pour constater que 1 transaction avec 1 commande
a été délivrée. L’état est Running. Si on vérifie le premier enregistrement
de la base de données Test de REBA, on constate que le processus de réplication
a placé la valeur de ContactName à  « maria anderson ».

Pour examiner les travaux de nettoyage que les assistants de
réplication ont créés sur TANYA, ouvrez le classeur Miscellaneous Agents. Les
travaux de nettoyage suppriment les transactions répliquées des tables appropriées
dans la base de données de distribution.

Comment est-ce que SQL Server implémente ce processus de réplication
? Premièrement, SQL Server génère les fichiers contenant les tables de schéma
(.sch) que le système de gestion de bases de données utilise pour créer les
tables. SQL Server génère également les fichiers de création d’index de tables
(.idx) qu’il utilise pour créer les index sur les abonnés, et les fichiers bcp
pour toutes les tables répliquées. Le système de gestion des bases de données
génère alors des procédures cataloguées pour chaque action d’insertion, de mise
à  jour et de suppression sur l’éditeur. SQL Server applique les fichiers de
schéma sur chaque abonné et applique les fichiers d’index appropriés aux tables
sur chaque abonné. SQL Server utilise alors bcp pour copier les données dans
les tables de l’abonné. Pour terminer, SQL Server crée des procédures cataloguées
pour les actions d’insertion, de mise à  jour et de suppression uniquement sur
les abonnements avec mise à  jour immédiate.

Si SQL Server génère automatiquement ces tâches de réplication,
quel est l’intérêt de s’intéresser à  ce qui se passe dans les coulisses ? Même
si SQL Server 7.0 améliore et simplifie considérablement l’installation et la
mise en oeuvre de la réplication, il n’est pas exclu que des problèmes puissent
se poser. Les causes peuvent ne pas être liées directement à  SQL Server. Par
exemple, un DBA peu expérimenté n’a peut-être pas répondu correctement à  une
des questions de l’assistant ou n’a pas utilisé les paramètres de sécurité adéquats.
Quelle que soit la cause, lorsque l’on essaye de résoudre les problèmes liés
à  la réplication, toute information que l’on peut apporter à  l’enquête est précieuse.

Sans aucun doute, la réplication est une fonction avancée qui
offre des possibilités attrayantes (plus particulièrement si l’entreprise a
besoin de synchroniser des données sur plusieurs serveurs différents). Les nouvelles
fonctionnalités de SQL Server 7.0 rendent la réplication plus puissante et souple,
et ses assistants font de la mise en oeuvre de la réplication un simple jeu de
questions-réponses (assurez-vous simplement de fournir les bonnes réponses).

Baya Pavliashvili, Consultant chez G.A. Sullivan
est spécialiste du développement et de l’administration des bases de données.
Il est MCSE, MCSD et MCDBA.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010