Base Oracle embarquée sur un navire et synchronisation avec la BD à terre

[habasque]

Salut à tous,

je travaille actuellement sur une base de données Oracle 10g/Forms 6i qui concerne les données de pêcheries.
pour le moment, la base de données fonctionne à terre. dans les mois qui viennent, l'idée est de mettre en place un réseau avec un serveur Oracle sur un navire scientifique afin de permettre aux chercheurs de saisir leurs données en live.
maintenant, je ne vois pas comment mettre à jour/synchroniser la base qui est à terre et les données saisies au cours de la campagne scientifique ?
faut t-il vider la base embarquée (mise à part les données référentielles) avant chaque campagne en mer?
au retour de campagne comment intégrer les données à la base maître ?

si vous avez des idées de processus, je suis preneur...

merci d'avance

[orafrance]

avec des vues matérialisées par exemple

[habasque]

effectivement, ce pourrait être une solution.
par contre, quelles sont limites en terme de volumétrie ?
le fait de synchroniser les 2 bases après une durée de 25 jours de campagne en mer ne pose t-il pas problème ?

[remi4444]

Il faut que tu te pose effectivement plusieurs questions:
- quel est le volume de la base ?
- sur quel volume portent les modifications (le nombre de jour n'indique rien) ?
- une fois les données rapatriées à terre, sont elles modifiées ?
- la base à terre est-elle modifiée pendant la mission du bateau ?
- en cas de modifs parallèles, portent-elles sur les mêmes users, les meme tables ?
- la base à terre est elle exactement l'image de la base sur le bateau ?
- il y a-t-il une synchronisation dans l'autre sens de la base à terre vers la base du bateau ?

Il y a une foule de solutions plus ou moins lourdes et plus ou moins performantes :
- vues matérialisées
- réplication multi-maitres
- import/export
- transportable-tablespace
- clonage par copie de datafiles ou rman.
- standby
- procédures stockée spécifiques
(et j'en oublie sûrement)

toutes ces méthodes on des avantages et des inconvéniants en termes de souplesse/rapidité de mise en oeuvre/performances/automatisme on ne peut donc pas donner une solution à priori sans en savoir plus...

[habasque]

la base de données sera utilisée en permanence par le personnel à terre, donc également pendant les campagnes en mer. elle continue d'évoluer.

à terre, la base aura un volume de 50Go au départ mais arrivera rapidement à 200Go.

en mer, un faible volume de données sera saisi : de l'ordre de centaines de méga. il s'agira essentiellement d'ajout de données.

les modifications parallèles pourront portées sur les mêmes tables.

en fait, peut être que le principe le + simple serait de mettre uniquement les données référentielles sur la version embarquée. au retour de campagne, il suffirait alors de réinjecter dans la base à terre, les données saisies.
à part, cette idée de vidage de la base embarquée après chaque campagne, je ne vois pas de solution pour garder une cohérence dans la base maître.

[orafrance]

dans ce cas des vues matérialisées en FAST REFRESH paraissent pas mal non ?

[remi4444]

L'évolution parallèle des 2 bases (surtout sur les mêmes tables) élimine un bon nombre de solutions. Avant toute considération technique, je pense qu'il faut déja se poser de manière fonctionnelle le problème de la gestion des conflicts (ie que se passe-t-il si quelqu'un à terre modifie une donnée alors quelqu'un en mer a modifié la même donnée dans un sens différent, qui a raison ? est-ce que ce cas est impossible ? etc...)
J'ai l'impression que selon la nature des données la réplication ne dois pas se faire dans le meme sens:

. le référentiel se fait dans les sens : TERRE -> BATEAU et ces données ne sont pas modifiables sur le bateau, donc des vues matérialisées avec refresh différentiel (= FAST REFRESH) semble adapté (tables maitres sur la terre, vues esclaves sur le bateau)

. Pour ce qui est des données non référentielles, l'idéal serait de pouvoir les séparer dans différentes tables de manière à ce que chacune n'ait qu'un sens unique de réplication et pouvoir ainsi là aussi mettre en place des vues matériélisées dans un sens ou dans l'autre. Pour les tables a accès réellement concurent, je crois qu'il faut faire des fonctions spécifiques de copies à travers un dblink. L'idéal serait que ces données à traiter de manière spécifiques aient la bonne idée d'etre datée et/ou étiquetées afin de pouvoir ne répliquer facilement que le delta à chaque synchronisation. Sinon il va faloir mettre de la réplication multi-maitre sur ces tables, ce qui est une usine à gaz pénalisante pour les performances...

Tout ça dépend aussi d'un paramètre très important, à savoir si l'application est figée ou si elle est encore en construction ? car la problèmatique de rafraichissement croisé est toujours complexe, c'est donc quelque chose qu'il faut intégrer dans ses analyse dés la conception du logiciel. Sans ça, on est obliger de faire du bricolage plus ou moins heureux après coup...

[orafrance]

j'avais pas saisi que la Terre pouvait modifier les mêmes données que la mer

En effet, il faut d'abord définir les priorités

[habasque]

il faut savoir que sur le bateau, il s'agit essentiellement de récolter des données puis de les ajouter dans la base. peu de modifications auront lieu sur la base en mer.

le référentiel se fait dans les sens : TERRE -> BATEAU et ces données ne sont pas modifiables sur le bateau, donc des vues matérialisées avec refresh différentiel (= FAST REFRESH) semble adapté (tables maitres sur la terre, vues esclaves sur le bateau)

je serais assez d'accord sur ce point. le personnel embarqué n'est pas censé modifier les données du référentiel.

Pour ce qui est des données non référentielles, l'idéal serait de pouvoir les séparer dans différentes tables de manière à ce que chacune n'ait qu'un sens unique de réplication

tu veux dire qu'il faut par exemple deux tables pour les données océanographiques : table_oceano_maitre et table_oceano_mer ?

et pour information, l'application est en phase de test. ell devrait monter en production d'ici 3 mois.

[remi4444]

Envoyé par habasque

tu veux dire qu'il faut par exemple deux tables pour les données océanographiques : table_oceano_maitre et table_oceano_mer ?

Oui c'est mieux d'avoir cette architecture, comme ça tu controle tes flux de données facilement (vues matérialisées) et tu gères tes éventuels conflicts tranquillement. Cependant maintenant que ton applicatif est en test, est-ce que tu as encore la main dessus pour faire ce genre de modification ?