Dans mon cas, on a de multiples flux de données entrants et sortants sur plusieurs bases inter-dépendants (je vous raconte pas le bordel).
Quelques exemples de "réplications":
- ENTREE : modification du catalogue (1 à 2 chargement par semaine) : réception des fichiers de chez SAP --> programme EXE qui charge dans une base SQL --> la base est copiée vers la production par backup/ftp/restore (manuel), puis switch des DSN qui pointent vers les bases catalogue.
- ENTREE : import de données clients de SAP vers notre base SQL toutes les 24 heures (MQ Series pour le transport des données --> programme EXE --> base SQL). Mise à jour et ajout de données dans notre base.
- SORTIE : export d'une partie d'une de nos bases vers les USA : toutes les 24 heures, un programme extrait des données de la base au format texte, fait un DIFF par rapport à l'extraction précédente et n'envoie que la différence (zippage puis envoi par FTP).
- SORTIE : export d'une partie de la base au format CSV pour traitements compémentaires sous Excel et vérifications. Fait avec un package DTS SQL Server. Lancé uniquement à la demande.
On a supprimé toutes les réplication synchrones, pour la simple raison que les mécanismes existants dans SQL Server sont foireux
(reprise impossible après dé-synchronisation : il faut détruire et reconfigurer la réplication à chaque fois ; et je ne me vois pas poser des trigger partout pour palier à ça).
Nos réplications ansychrone sont toujours partielles (jamais une base complète), la plupart du temps pas en différentiel, et le plus souvent faites par des logiciels maison.
Aucun des outils qu'on a pu trouver ne fait le boulot correctement.
On développement pratiquement toujours des applications maison.
C'était majoritairement du MQ Series d'IBM pour le transport des données et un EXE pour les transférer depuis/vers la base SQL.
Mais on a de plus en plus tendance à utiliser des solutions plus simples, rapides, facilement adaptables et plus éprouvées : des scripts (shell/awk/diff/...) et du FTP pour le transport des fichiers.
C'est plus rapide à développer, plus facilement à maintenir, et plus facile de reprendre la main dessus en cas de problème.
Voilà... je n'ai parlé que d'une partie de nos réplications, pas des transactions (il y a également un paquet de flux de données entre systèmes).
