Discussion :

[vincent.alyotech]

Bonjour à tous,

Dans le cadre du développement d'une nouvelle application, notre client nous demande d'intégrer un module d'archivage qui permettra
- d'archiver des données en fonction d'une recherche sur différents critères
- de consulter les données archivées
- de restaurer des données archivées
- de supprimer définitivement des données archivées (purge)

l'administrateur devra pouvoir effectuer ces opérations par le biais d'une interface type web.

La solution envisagée actuellement est de créer une seconde base de données d'archive sur le même modèle de données que la base opérationnelle, de cette manière les actions sur cette base de données pourront utiliser les fonctions mis en place pour la base opérationnelle (consulter les données archivées, ...), il faudra juste pointer sur la base de données d'archive.

il nous reste la problématique du déplacement des données d'une base de données à l'autre et nous recherchons une solution parmi des outils oracle existants. Les fonctions d'import/export ne sont pas adaptées puisqu'elles permettent de faire des copies de données.
A priori cette opération sera réalisé en mode asynchrone par le biais de batch lancé la nuit.

Ma question est la suivante, est ce que la nouvelle version d'oracle 10G permet ce déplacement de données d'une base de données à une autre ?
Si c'est le cas, quels sont les préconisations d'oracle pour ce type d'action
Je n'ai pas trouvé de détails sur ce type de fonctionnalités mais j'ai lu que cette nouvelle version d'oracle permettrait de faire du déplacement de données sans plus de détails.

J'ai consulté les discussions sur le sujet de l'archivage de données mais je n'ai pas retrouvé cette problématique de déplacement de données, les solutions envisagées dans ces derniers ne me paraissent donc pas adaptées.

merci d'avance pour les idées, conseils que vous pourrez me donner sur le sujet.

cordialement,

quelques précisions :
- nous n'avons pas encore une vue très précise du modèle de données qui sera mis en place
- le volume de données contenues dans les tables ne nous a pas été fourni mais a priori il s'agit de gros volume

[orafrance]

avec export ou datapump tu peux utiliser le paramètre QUERY pour n'extraire qu'un sous ensemble.

Mais tu as aussi la possibilité de mettre un trigger ON DELETE sur toutes les tables à archiver qui va déclencher un INSERT dans la base distante via DBLink.

Le DBLink sera de toute façon nécessaire pour visualiser les données archiver sans avoir à changer de connexion.

Sinon, il existe des solutions sur le marché comme princeton, solix ou applimation

[vincent.alyotech]

merci pour ta réponse.

j'avais effectivement pensé à la fonction d'export ou datapump utilisable avec le paramètre QUERY pour n'extraire qu'un sous ensemble. Mais cette solution nécessite aussi de supprimer les données exportées si leur import dans la nouvelle base est effectif.

La deuxième solution que tu proposes, si j'ai bien compris, permet d'effectuer cette opération en une seule. Je supprime les données dans une table (paramétré avec le trigger ON DELETE) de ma base principale et elles sont automatiquement insérées dans ma base de données d'archive via DBLink.
C'est bien ça ?
Je vais pousser mes recherches dans cette voie, ca me parait une bonne solution.

La dernière solution d'utiliser un outil disponible sur le marché n'est pas envisagée pour le moment. J'ai cru comprendre dans d'autres discussions, dans lesquelles tu faisais déjà référence à ces outils, qu'ils étatient relativement cher

merci encore pour ces éclairages.

[orafrance]

c'est bien ça, tu déplaces les lignes d'une base à l'autre finalement

Oui, c'est cher et la méthode employée est celle que j'ai expliquée : purge/archivage via trigger

[pifor]

On peut aussi imaginer d'utiliser le partionnement des tables et les tablespaces transportables: si les critères d'accès sont assez simples pour le partionnement, on peut créer des partitions pour les données à archiver dans des tablespaces spécifiques. Archiver les données peut alors consister à déplacer les tablespaces d'une base à l'autre et à supprimer ou à vider les partitions dans la base source.

Ceci dit, l'option Oracle de partionnement des tables (partitioning) est facturée séparément (mais les tablespaces tranportables sont compris dans la version Entreprise sans supplémént).

Voir dans le Concepts Guide: partitioning et transportable tablespaces.