Replication Base de données
Eric
-
teebo Messages postés 33570 Date d'inscription Statut Modérateur Dernière intervention -
teebo Messages postés 33570 Date d'inscription Statut Modérateur Dernière intervention -
Je cherche à faire une liste exhaustive des cas ou il est utile de proceder à la replication
d'une base de données, de maniere synchrone ou asynchrone.
Si vous avez déjà été confronté à ce probleme, pouvez vous me dire les raisons qui vous
ont poussé à le faire, les objectifs qui étaient à atteindre et si vous vous souvenez, la
solution que vous avez utilisé (type de BD, outils, etc...)
merci d'avance!
d'une base de données, de maniere synchrone ou asynchrone.
Si vous avez déjà été confronté à ce probleme, pouvez vous me dire les raisons qui vous
ont poussé à le faire, les objectifs qui étaient à atteindre et si vous vous souvenez, la
solution que vous avez utilisé (type de BD, outils, etc...)
merci d'avance!
A voir également:
- Replication Base de données
- Fuite données maif - Guide
- Base de registre - Guide
- Base de données vide tnt - Forum TNT / Satellite / Réception
- Tnt base de données vide - Forum TV & Vidéo
- Effacer les données de navigation sur android - Guide
4 réponses
j'ai eu un court contrat pour une personne pour qui je devais terminer un développement sous Access pour un organisme dont des permanences étaient réparties sur tout un département. N'étant pas en réseau, et même, ayant des moyens techniques assez rudimentaires, le client devait pouvoir saisir des enregistrements sans risque d'atteinte à l'intégrité référentielle au moment du regroupement des informations. Mon employeur avait choisi, à ma grande surprise, de développer lui même un module de création d'identifiant basé sur l'identifiant de la permanence & un identifiant unique, et le développement devait donc comprendre un module de synchronisation fait main. Les erreurs d'analyse ont provoqué un merdier incroyable dans la gestion des enregistrements de chaque table. C'était typiquement un cas où une réplication à partir d'une base de données unique, développée pour du local, sans tous les problèmes inhérents à la préservation a la mano de l'integrité référentielle, avec juste quelques lignes et feuilles pour faciliter à l'utilisateur la synchronisation, aurait largement mieux géré la problématique. A partir de la structure pour une utilisation locale, le soft aurait lui-même créé les champs, tables etc. nécessaires pour que la synchronisation soit faite proprement.
voilà...
kinder.surprise,
le maton du matou
voilà...
kinder.surprise,
le maton du matou
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).
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).
Dans le cadre de Data Mining, on etait oblige de pre-processer une base de donnees avec plusieurs Millions d'entrees, le processus durait une bonne dizaine d'heures, et la base etait modifie tous les jours, donc il etait imperatif de faire une replique asynchrone sous peine de ne pouvoir utiliser les donnees processes dans le logiciel d'aide a löa decision...
Le pire, c'est que c'etait en Access (certes 97) (la base de depart etait dans un vieux truc, mais moi je ne m'en occupait pas donc je sais plus...)
. .
\_/
Le pire, c'est que c'etait en Access (certes 97) (la base de depart etait dans un vieux truc, mais moi je ne m'en occupait pas donc je sais plus...)
. .
\_/
