Optimisation des performances de la réplication avec SQL Server Compact, problématique de la volumétrie : PARTIE 1/3 (Problématique & Precompute partitions)
Dans mes précédents articles sur la réplication SQL, il m’est souvent arrivé d’exposer quelques conseils quant à la mise en place d’un système de synchronisation avec des terminaux mobiles.
Aujourd’hui, l’article que je vous propose va plus loin.
Composé en 3 parties, il aborde les problématiques de performances et de volumétrie de données dans le cadre de gros projets qui mettent en action un grand parc de terminaux portables.
Cet article me permet surtout de réunir, et d’exposer, toutes les astuces que je connais au travers de mes expériences professionnelles, pour construire un système de réplication fiable, résistant à la charge et aux lourdes mises à jour de données.
Problématique :
La problématique abordée dans cet article est donc celle des gros projets qui mettent en action un grand parc de terminaux portables. En effet, la configuration d’un système de réplication fiable se complique lorsque le nombre de terminaux portables abonnés devient important.
Mettre en place un système de réplication performant devient surtout un casse-tête lorsque la base centrale est volumineuse et lorsque les mises à jour sont fréquentes sur cette dernière.
Il faut d’abord savoir que lorsqu’un terminal se connecte au serveur, une phase de calculs suit directement l’initialisation de la synchronisation. Cette phase de calculs, prise en charge par SQL Server et par l’agent de réplication, est nécessaire pour déterminer précisément quelles sont les données modifiées à distribuer sur le terminal connecté.
Ces calculs sont d’autant plus longs et complexes quand la volumétrie de la base est importante et quand le nombre de partitions, c'est-à-dire le nombre de terminaux abonnés, est conséquent.
De la même façon, la volumétrie de données brassées par les mises à jour sur la base publiée peut également alourdir considérablement cette phase de calculs.
Il faut garder dans l’esprit que plus les données sont modifiées, plus le processus de réplication mettra du temps pour lister l’ensemble des lignes qui doivent être descendues sur les différents terminaux. Un système de filtres complexe peut également avoir des effets négatifs lors de la synchronisation d’un terminal.
La complexité de cette phase de calculs est donc relative à plusieurs points :
-
La volumétrie de la base publiée
-
Le nombre d’abonnements associés à une publication
-
Le système de filtres implémenté sur les articles de la réplication
-
La fréquence des mises à jour sur la base publiée et la volumétrie de données brassées durant ces mises à jour
Dans ce genre de configuration, la synchronisation d’un terminal peut rester bloquée durant plusieurs longues minutes sur cette phase de calculs avant que le transfert des données modifiées s’effectue réellement. Pire encore, il est même possible que les calculs n’aboutissent pas et que le système de réplication tombe en “TimeOut”. Si ce cas se produit, il sera alors impossible de continuer à synchroniser les PDA ! Il faudra alors augmenter le délai du “TimeOut” par défaut ou effectuer des manipulations risquées dans les tables systèmes pour continuer à utiliser le système sans détruire les publications (solutions non acceptables).
Ce genre de problème peut être détecté sur l’écran de monitoring des synchronisations. Il se matérialise souvent par des messages d’erreur comme “Timeout expired” ou encore “The merge process failed to enumerate changes in articles…”.
A noter que cette problématique doit surtout être prise au sérieux lorsque la base de données centrale subit des mises à jour en masse suite à l’exécution de traitements de nuit par exemple.
Néanmoins, il existe des solutions pour que ce genre de problème n’apparaisse pas !
En effet, il sera nécessaire d’attacher plus d’importance à la manière dont nous configurons les publications et le système de réplication en général. Cette optimisation passe dans un premier temps par l’activation de l’option “Precompute partitions”…
Activation de l’option “Precompute partitions” :
Pour activer l’option “Precompute partitions” sur une publication, il est nécessaire de passer la valeur de l’option à “true” dans les écrans de paramètres de la publication (page “Subscription Options”) :
L’option “Precompute partitions” permet d’éviter les phases de calculs durant les processus de synchronisation. En effet, l’activation de cette option permet d’effectuer le filtrage et l’archivage des lignes directement lors des mises à jour sur les tables articles. L’activation de cette option permet donc de préparer au mieux les données à télécharger pour chacune des partitions, c’est à dire pour chacun des terminaux portables.
Concrètement, en activant cette option nous supprimons l’ensemble des calculs qui ont lieu lors de l’initialisation d’une synchronisation, mais nous rajoutons un traitement supplémentaire en amont, à chaque mise à jour de données.
Process :
-
Une requête (INSERT, UPDATE ou DELETE) est jouée sur une table article
-
Le système détermine alors quel terminal est affecté par cette modification (parcours du système de filtre et des différentes partitions)
-
Et ainsi de suite pour l’ensemble des requêtes exécutées lorsque l’option “Precompute partitions” est activée…
Lorsque le terminal se connecte pour effectuer une synchronisation, toutes les données le concernant sont déjà prêtes à être transmises. Le transfert de données peut donc avoir lieu immédiatement.
Attention :
L’activation de cette option n’est donc pas sans impact. En effet, une fois activée, les modifications de données sur les articles par des requêtes INSERT, UPDATE ou DELETE génèrent un calcul de filtres et mettent donc plus de temps à s’effectuer. Les temps d’exécution de ces requêtes doivent rester acceptables dans le cadre de mises à jour en masse par des traitements de nuit.
Avec l’option “Precompute partitions”, les temps d’exécution des requêtes sont liés au nombre de partitions déclarées, mais également au système de filtres implémenté. En effet, ces temps deviennent vite inacceptables si le système de filtres mis en place est trop complexe…
… A suivre….
Pi-R.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
