Rechercher : dans
Par :

Replication Base de données

Dernière réponse le 13 mai 2002 à 15:16:02 Eric, le 13 mai 2002 à 11:15:36 
 Signaler ce message aux modérateurs

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!

Meilleures réponses pour « Replication Base de données » dans :
Connexion à une base Oracle en php Voir1. Périmètre Cet article est un exemple de connexion à une base Oracle par le biais d'un script php. Cet article ne traite pas la configuration de votre serveur Oracle, et de votre client Oracle. Nous partons du principe que vous pouvez accéder à...
Affichage des paramètres Oracle VoirEn complément du fichier init.ora, il est possible de consulter la base de données pour prendre connaissance d'autres paramètres tels que max_open_cursors defined, taille d'un bloc ... Il suffit de lancer la commande suivante : SELECT name,...
Access - Rétablir les menus par défaut VoirRétablir le démarrage d'une base de données Access Cette astuce vous permettra de retrouver les menus par défaut et la fenêtre de gestion de la base d'Access si ceux-ci ont été modifiés. Vous avez configuré le démarrage de votre base de données...
PHP - Bases de données VoirPhp permet un interfaçage très simple avec un grand nombre de bases de données. Lorsqu'une base de données n'est pas directement supportée par Php, il est possible d'utiliser un driver ODBC, pilote standard pour communiquer avec les bases de...
Bases de données - Introduction VoirQu'est-ce qu'une base de données ? Une base de données (son abréviation est BD, en anglais DB, database) est une entité dans laquelle il est possible de stocker des données de façon structurée et avec le moins de redondance possible. Ces données...
Connexion à la base de données avec JDBC VoirConnexion à la base de données L'API (Application Programming Interface) JDBC, c'est-à-dire la bibliothèque de classes JDBC, se charge de trois étapes indispensables à la connexion à une base de données : la création d'une connexion à la...

1

kinder.surprise, le 13 mai 2002 à 14:04:46

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

Répondre à kinder.surprise

2

kinder.surprise, le 13 mai 2002 à 14:05:08

Au fait, c'était sous cette grosse m... d'Access 2000

kinder.surprise,
le maton du matou

Répondre à kinder.surprise

3

sebsauvage, le 13 mai 2002 à 15:04:28

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).

Répondre à sebsauvage

4

 teebo, le 13 mai 2002 à 15:16:02

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...)
.  .
\_/

Répondre à teebo