Discussion :

[Alexandre_P]

Bonjour à tous,

Je travaille sur un CRM dont les données sont stockées dans une base Oracle 10g.

Je dois mettre en place un programme d'archivage des anciens clients et de toutes leurs données rattachées (donc à partir d'une table mère et x tables filles).

Je dois aussi pouvoir restaurer les informations concernant un ancien client dont les données seraient archivées sur demande.

J'hésite sur la solution à appliquer.

Quelqu'un a déjà rencontré une situation similaire?

D'avance merci.

[Marc Musette]

et tu hésites entre quelles solutions ???

ce qui justifie la technique d'archivage , ce sont tes requirements : est-ce que les données doivent être accédées par l'appli ?

[Alexandre_P]

J'ai envisagé 2 solutions:

• un traitement avec export Oracle
  
  
  Le principal inconvénient, c'est que je devrais faire un dump par table puisque j'ai des critères de sélection donc beaucoup de fichiers au total.
  
  Evidemment, la restauration des données d'une personne serait un peu compliquée mais elle sera (en théorie) extrêmement rare.
• un traitement avec déplacement des données dans des tables bis
  
  Cette solution me paraît plus propre mais elle nécessite de recréer beaucoup de tables bis.
  

[Alexandre_P]

Et pour répondre à ta question:

OUI, les données restaurées devront être accessibles par l'appli

[Marc Musette]

si les données archivées doivent être accessibles via l'appli, je ne vois pas très bien comment la solution "export" ferait l'affaire

il me semble que tu n'as pas d'autres choix que de stocker les données archivées dans des tables

soit tu crées de nouvelles tables , soit tu ajoutes un flag aux tables existantes pour dire si la données est archivée ou pas et tu utilises des views pour accéder aux données "live" ou aux données archivées

une façon à envosager est également le partitionning

une autre façon est également de te demander si tu as vraiment besoin d'archiver ... d'ailleurs pourquoi te faut-il archiver ??? étant donné que ces données doivent toujours être accessibles via l'appli ...

[Alexandre_P]

Désolé, je n'ai pas été très clair.

Quand elles sont archivées, les données ne doivent pas être accessibles par l'appli.
Par contre, si je les restaure, elles doivent l'être.

A mon avis, les solutions "flags + vues" ou "tables partitionnées" ne sont pas possibles car l'apppli CRM est un progiciel et il n'est pas envisageable de modifier tous les accès aux tables.

Je me demande si je ne vais pas m'orienter tout simplement vers la conservation d'une archive complète de ma base vue que la fréquence de purge sera faible (sans doute annuelle).

[orafrance]

Moi je verrais bien des tables d'archivage rempli par un trigger ON_DELETE sur les tables d'origines

[Alexandre_P]

Oui, ça correspondrait à la solution que j'avais appelé "déplacement des données dans des tables bis".

Mais je lui trouve 2 inconvénients:

• beaucoup de tables d'archivage à créer
• la taille de la base ne diminue pas

[orafrance]

- quel est le problème ? Une boucle FOR avec EXECUTE IMMEDIATE et tu crées tes tables en une seule commande
- certes, mais tu peux les mettre dans un tablespace compressé... et un export consomme aussi du disque. Inconvénient de l'export, tu ne peux pas ajouter de lignes dans un fichier qui existe déjà

[Alexandre_P]

Je ne connais pas la boucle FOR avec EXECUTE IMMEDIATE mais ça a l'air très pratique, tu peux me donner un exemple?

[orafrance]

une recherche sur le forum et dans la FAQ devra suffire

[Zugg]

Salut,

pour éviter que la base n'augmente, tu peux toujours mettre les données archivées dans une autre instance et ceci directement par des commandes SQL.

1- création de l'instance d'archive
2- sur l'instance de production création d'un database link vers la base d'archive
3- transfert des données à archiver de la base de prod vers la base d'archive en utilisant le database link.

ainsi la base de prod ne contiendra que les données courantes et sa taille ne devrait pas augmenter énormément à cause des données archivées.
autre avantage : pouvoir sauvegarder/restaurer que les données de production ou celle d'archive.
possibilité de mettre les instances sur des serveurs distincts pour optimiser les performances et l'espace disque du serveur de production.

et pour la restauration des données archivées dans la base de prod, il suffit de faire un transfert en sens inverse des données via le database link.


enfin c'est juste une idée.

[orafrance]

et pour la restauration des données archivées dans la base de prod, il suffit de faire un transfert en sens inverse des données via le database link.

Il suffit même de faire un vue qui fait un UNION ALL de la table locale et de la table distante

[Zugg]

Il suffit même de faire un vue qui fait un UNION ALL de la table locale et de la table distante

oui en effet, mais si la table contient des LOB, je pense pas que la vue fonctionne et permette de les récupérer via un DBLink...

[Alexandre_P]

Cette solution me plait bien, elle répond à toutes mes contraintes.

Merci à tous pour vos réponses.