Discussion :

[Naturalforme.fr]

Bonjour,

J'ai synchronisé deux bases SQL distantes en "liant" deux serveurs". Les mises à jour s'effectuent correctement mais bloquent l'application (site web en back et front office) pendant la MAJ. La coupure est très courte (moins d'une minute) mais reste problématique surtout depuis le front.

J'ai utilisé une requète similaire à celle ci, elle se lance toutes les heures :

UPDATE NOM_SERVEURLIE.base_de_donnees.dbo.table
SET CHAMP_distant = CHAMP_local
FROM MABASE_locale.dbo.table
WHERE CHAMP_A_COMPARE_DISTANT = CHAMP_A_COMPARE_DISTANT
COLLATE LATIN1_GENERAL_BIN

J'ai d'abord cru que le Collate était le problème j'ai donc utiliser le jeu de caractères de la base distante, le problème est le même.

Si vous avez des idées, je suis preneur !

Merci d'avance.

[ylarvor]

Ca peut être un problème de taille de la mise à jour. Combien de lignes sont impactées ? quel volume de données ?

Vous ne pouvez pas travailler la nuit ? vous êtes 24/24 ?

[Naturalforme.fr]

Bonjour,

Au moins 1500 lignes (rapidemment 2000). Je voudrais faire un update toutes les heures.

Fred

[ylarvor]

Vous pouvez essayer de placer une trace sur le serveur de destination avec le profiler pour mesurer la trace duration de la requete de update. si la requête 60 sec. vous saurez mieux d'où vient le problème!

Il s'agit pratiquement d'un traitement par lot ( 2000 lignes ), vous devez faire attention au fichier de log de la base de destination qui risque de gonfler...

Vous pouvez essayer de supprimer les index avant le traitement et de les recreer apres le traitement, ca ameliore parfois les performances pour les lots!

J'avoue que j'ai pas d'experience dans les traitement par lot. Vous pouvez peut être essayez de tronquer votre mise à jour à l'aide d'un table de paramètrage pour faire 6 mises à jour par heure partielle au lieu d'une seule complete.

La seule explication que je vois, c'est que la table soit lockée pendant la mise à jour mais de là à bloquer tout le site, je ne suis pas sûr!

Quelqu'un aura peut etre votre solution.

[ylarvor]

votre démarche de mise à jour n'est pas conventionnelle. Peut etre qu'une réplication unidirectionnelle, qui n'est pas trés difficile à mettre en place, gererait mieux le traffic de la base. A tester!

[Naturalforme.fr]

Je ne sais à priori pas mettre en place une réplication unidirectionnelle. si vous avez des ressources en ligne je suis preneur.

[ylarvor]

Par ordre de complexité, vous avez deux réplications possibles :

- la réplication de capture instantanée s'applique pour un volume de donnée faible. Il s'agit d'une opération planifiée de réécriture chez les abonnés de la publication. Comme il y a écrasement de la publication par la nouvelle version, on utilisera cette réplication pour un sous ensemble réduit de la base de données. On peut comparer la réplication de capture instantanée à une opération de sauvegarde/restauration sur la seule publication.
- la réplication transactionnelle s'applique en cas de mise à jour fréquente des données de l'éditeur ( source ). La réplication transactionnelle effectue une première mise à jour complète des données suivie d'opérations de transfert des seuls données modifiées entre la source et la cible. La réplication transactionnelle utilise pour ce faire le journal des transactions. La réplication transactionnelle est à sens unique, elle reporte les modifications de la source vers la cible. Pour mettre en place une remontée des modifications de la cible vers la source, il est nécessaire de mettre en place un processus indépendant de la réplication transactionnelle.

La première, la réplication de capture instantannée, je l'ai mise en oeuvre à titre de test. ce n'est pas bien compliqué à première vue quoique pour maintenir, cela cache peut etre des surprises que je n'ai pas vu.

http://msdn2.microsoft.com/fr-fr/library/ms151734.aspx
chercher réplication de capture instantannée sql serveur, il y a des ressources.

Le but de la réplication, c'est d'écraser la table et non de l'updater, c'est clair pour vous. il n'aura pas de soucis ? sinon, vous devez créer une table tampon ( publication ) dans laquel vous viendriez chercher l'information pour updater votre table si celle ci est mise à jour par ailleurs.

j'espère que cette fois sera la bonne...

PS : sur une discussion similaire, sql pro recommande la transactionnelle qui est plus performante que la capture instantannée.