> Data > Ouvrez la voie à  la réplication snapshot à  grande échelle

Ouvrez la voie à  la réplication snapshot à  grande échelle

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Herts Chen - mis en ligne le 18/12/02
Si vous êtes développeur d'applications ou de bases de données, vous déplorez probablement le temps excessif que des utilitaires comme bcp (bulk copy program), DTS (Data Transformation Services) et la réplication snapshot mettent pour copier une quantité massive de données en plusieurs endroits ...Ainsi, un snapshot d'une base de données contenant 500 Mo de données définies avec des contraintes de clés et des index peut durer 2 heures pendant la journée de production ou 1 heure et demi la nuit, pour effectuer un transfert entre deux serveurs de bases de données haut de gamme, à  quatre voies, avec 1 Go de RAM et RAID 5. Cette performance est inacceptable dans une ferme de serveurs à  équilibrage de charge 24x7 ou dans un entrepôt de données d'entreprise distribué dont le temps disponible hors période de pointe est trop court pour tolérer le transfert de multiples ensembles de données massifs vers tous les serveurs. Mais alors, comment peut-on accélérer la distribution des données ?

Ouvrez la voie à  la réplication snapshot à  grande échelle

J’ai choisi d’optimiser la réplication
d’un grand snapshot de données. La réplication
snapshot copie un ensemble
de données à  partir d’un SQL Server
source au moment où la réplication est
invoquée, même pendant que d’autres
requêtes ou mises à  jour existent sur le
même ensemble de données. La
réplication snapshot copie ensuite cet
ensemble de données, immédiatement
ou plus tard, dans un ou plusieurs SQL
Server cible. Les serveurs cible voient les données comme elles existaient dans le
serveur source au moment de la copie
jusqu’à  ce que la réplication snapshot
suivante rafraîchisse tout l’ensemble de
données. DTS copie un ensemble de
données à  partir d’une source ODBC
(ou OLE DB) et dans une autre cible
ODBC (ou OLE DB) immédiatement. La
source et la cible peuvent être deux
fournisseurs de données ODBC complètement
différents. Bcp copie une
table ou vue de SQL Server vers un fichier
au format natif ou caractère, ou
bien il copie un fichier en format natif ou
caractère dans une table ou vue de SQL
Server.

La réplication snapshot utilise en
fait bcp et se déroule en deux phases.
La première phase copie (bcps out) un
snapshot d’une source de données sélectionnée
à  une heure programmée.
La seconde phase distribue (bcps in) le
snapshot vers un ou plusieurs serveurs
cible d’après des programmes séparés.
Bien que DTS utilise aussi bcp en supportant
la tâche BULK INSERT, DTS ne
peut pas programmer la copie sortante
et la copie entrante séparément, et il
lui manque l’efficacité de partager un
snapshot pour de multiples cibles. Un
job DTS ne peut copier que sur une
cible. Toutefois, bcp est un utilitaire de
ligne de commande brut. Il lui manque
une interface conviviale et la possibilité
de copier directement d’un SQL Server
sur un autre. Chaque exécution de bcp
ne peut copier qu’une table à  la fois. La
réplication snapshot et DTS sont des
habillages conviviaux et puissants de
l’utilitaire bcp. (Pour savoir pourquoi la
réplication snapshot serait plus appropriée
que la réplication transactionnelle
pour votre projet, voir l’encadré
intitulé « Pourquoi pas la réplication
transactionnelle ? ».)

Téléchargez cette ressource

Sécuriser votre système d’impression

Sécuriser votre système d’impression

Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.

Data - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT