Discussion :

[freud]

Bonjour,

Dans mon entreprise et dans la cadre d'un projet informatique, on envisage d'opter pour la réplication MS SQL pour 250 postes qui doivent s'abonner à un serveur. Mais, le choix de l'architecture me donne des doutes quant au bon fonctionnement du projet et sa réussite. Je m'explique :

les 250 postes client abonnés à la publication et répartie géographiquement, auront comme accés VPN vers le site serveur avec un débit de 256 KO de type ADSL

Le serveur, lui, a 1 MO de débit ADSL.

La réplication devrait se faire dans les deux sens :

client vers serveur et serveur vers client et pour chaque poste (250)

Alors je me demande bien si cela peut se faire avec ce nombre de poste et avec un tel débit. Enfin, si quelqu'un à vu ça oû entendu parler.
Parce qu'un fois un simple select un champ entre deux machines à travers ADSL ca n'a pas marché avec 1 MO de chaque côté.

Merci pour vos réponses

[mikedavem]

Bonsoir,

Tout dépend ce que vous répliquez, le volume de transaction que vous aurez mais il est vrai que ça risque de poser certains souci avec ces débits.

Il faudra peut être et même sûrement penser à modifier les paramètes concernant l'agent de fusion pour un réseau à faible débit (paramètres DownloadGenerationsPerBatch et -UploadGenerationsPerBatch, -SrcThreads et -DestThreads.)

++

[freud]

Merci,

E ce moment je ne peux pas savoir le volume approximative de transfert qui, normalement, devrait se faire quotidiennement et sans planification côté serveur donc une fois le serveur libre ca doit s'opérer sur négociation entre agents SQL. Mais j'ai jeter un rapide coup d'oeil dans la BD et localiser quelques tables sujettes à la réplication. En fait il y a deux dont la taille est de 1600 octet pour la 1ere et 1800 octet pour la seconde qui feront l'objet de la réplication. Et de quelque 80 record pour la 1ere et de 10 record pour la 2eme.

Pour être plus précis, le sens de la réplication serveur vers client devrait transferer toutes les données que le serveur aura récolté depuis les 249 autres postes et c'est là le hic !

[SQLpro]

Si aucune mise à jour ne doit être apporté aux données cible à part la source, alors une solution consiste à définir une réplication transactionnelle mono directionnelle sur des tables partitionnées par vues.

En gros au lieu d'avoir une table des commandes, on fait n tables des commandes (à raison d'une table par poste) et on créé une vue d'agrégation.
Pour faciliter l'auto incrément on peut utiliser un clef à modulo.
Ainsi avec 250 postes, la première à pour incrément IDENTITY(0, 250), la suivante : (1, 250), puis (2, 250), etc...

A +

[freud]

Bonjour,

Seule la source est mise à jour et l'embetant c'est qu'il n'y a pas d'autoincrement à la place, il y a une clé de type char (14) dans la table qui est sujette au transfert parce que les autres tables ce sont des tables permanentes genre code postaux, pays etc...
Pour les tables partionnées par vues je ne pense que cela va se faire car la BD est déjà prête pour l'exploitation.