Bonjour,

j'ai récupéré une application qui se base sur une réplication en fusion entre un serveur SQL central où les tables sont publiées et 4 autres serveurs qui répliquent par fusion. Il y a un filtre au niveau de chaque abonné pour que seules les données le concernant lui soient envoyées. Les réplications sont lancées par des jobs dans l'agent SQL qui tournent toutes les 6 minutes. On force, en plus de ça, un snapshot tous les dimanches soirs.

Nous parlons ici d'une table centrale de 1,2 millions de lignes et de bases abonnées de 700000 lignes environ.

Bien évidemment nous avons des problèmes de performances où il y a des lenteurs lorsque la réplication tourne (en fait il y a des locks qui s'empilent sur le serveur) ... J'ai repéré la première piste d'amélioration qui était sur le filtre en lui même (qui contenait un WHERE colonne like '%valeur%') et ça c'est en cours de correction pour modification de la requête en utilisant des indexs appropriés ...
Par contre, je vois aussi qu'il y a une rétention de 168 heures au niveau de la réplication.
Ma question est donc la suivante:
Est-ce que cela se justifie-t'il d'avoir une valeur aussi élevée vu que nous répliquons toutes les 6 minutes? A quoi sert exactement cette valeur?
Je comprendrais une telle valeur si nous avions des abonnés qui ne se connectent que ponctuellement. Mais dans notre cas, ne serait-il pas plus judicieux de descendre cette valeur à 72 heures, voire 48? est-ce que cela réduirait le nombre de lignes dans les tables systèmes de la répli (notemment les tables MSmerge_contents et MSmerge_history, MSmerge_genhistory )

Merci de votre aide

Est-ce que vous auriez d'autres idées de pistes que je devrais voir/vérifier?

Y.