Discussion :

[Cereal123]

Bonjour,

Un de mes clients me demande de garder des infos en base de données pendant une dizaine d'années afin de pouvoir y accéder en cas de nécessité. Vu la quantité de données stockée par an (plusieurs millions de lignes), j'ai peur que cela plombe inutilement mes temps de réponse.Je suis donc à la recherche d'une solution permettant de gérer ce cas de figure élégamment, c'est à dire sans imposer à mon client (ou à mois même d'ailleurs) des manipulations tordues.

Une des solutions que je vois, c'est de créer un tablepace par an et de mettre OFFLINE les tablespaces qui ont plus de 2 ans d'âge (par exemple). Si jamais mon client veut faire une requete sur des données datant de 5 ans, il devrait suffir de remettre ONLINE le tablespace concerné ? Cela peut-il se faire à chaud ? Que pensez-vous de cette solution ?

Merci de vos lumières sur le sujet,

C.

[orafrance]

Une autre solution consiste à partitionner les tables en créant une partition par an. Sinon, les outils d'archivage stockent l'archive dans une instance à part et par des mécanismes de vues et DB Link ils permettent un accés au données ainsi archivées.

Enfin, comme je viens de le dire, des éditeurs proposent des solutions complétes : Solix, Princeton ou Applimation par exemple

[heffer69]

Bonjour,

Un de mes clients me demande de garder des infos en base de données pendant une dizaine d'années afin de pouvoir y accéder en cas de nécessité. Vu la quantité de données stockée par an (plusieurs millions de lignes), j'ai peur que cela plombe inutilement mes temps de réponse.Je suis donc à la recherche d'une solution permettant de gérer ce cas de figure élégamment, c'est à dire sans imposer à mon client (ou à mois même d'ailleurs) des manipulations tordues.

Une des solutions que je vois, c'est de créer un tablepace par an et de mettre OFFLINE les tablespaces qui ont plus de 2 ans d'âge (par exemple). Si jamais mon client veut faire une requete sur des données datant de 5 ans, il devrait suffir de remettre ONLINE le tablespace concerné ? Cela peut-il se faire à chaud ? Que pensez-vous de cette solution ?

Merci de vos lumières sur le sujet,

C.

J'ai l'impression que ce que demande le client ressemble fortement à un Datawarehouse... La solution de mettre un tablespace ONLINE avant de faire une requête ne me paraît pas vraiment possible puisque le client peut à tout moment avoir besoin des données datant de n'importe quelle année.

[nuke_y]

Je ne suis pas d'accord avec le fait que le client demande un datawarehouse. Si effectivement le client veut pouvoir à tout moment et sans délais accéder à des données historiques, on peut imaginer une organisation en datawarehouse mais sinon je pense que les tables partitionnées sont effectivement la solution.

[Cereal123]

Je vais jetter un oeil aux outils que vous citez. Le prix sera évidemment un critère déterminant

C'est vrai que sur certains aspects, cela s'apparente à un Datawarehouse. L'idée de garder les données de l'année en cours sur une instance de production et de déplacer les données des années précédentes sur une instance séparée me parait intéressante.

Concernant les tables partitionnées, je connais leur existance mais je ne les ai jamais utilisées. Introduisent-elles des contraintes particulières dans l'écriture des requetes ?

[orafrance]

Je vais jetter un oeil aux outils que vous citez. Le prix sera évidemment un critère déterminant

Je t'avertis tout de suite... c'est pas donné

Mais ça peut être intéressant de les faire venir pour une présentation... histoire de repomper les idées

C'est vrai que sur certains aspects, cela s'apparente à un Datawarehouse. L'idée de garder les données de l'année en cours sur une instance de production et de déplacer les données des années précédentes sur une instance séparée me parait intéressante.

Explique bien au client ce que ça coute en disque, (surtout si il y a de la haute dispo), en exploitation et en performance et assure toi que les données doivent bien être en ligne sans délai... peut-être qu'une base d'archive suffirait et dans ce cas c'est bien plus simple (une méthode consiste par exemple à faire des scripts de purge et des triggers ON-DELETE qui vont archiver les lignes supprimées dans la base distante )

Concernant les tables partitionnées, je connais leur existance mais je ne les ai jamais utilisées. Introduisent-elles des contraintes particulières dans l'écriture des requetes ?

Absolument aucune contrainte et aucun refactoring. Eventuellement un tablespace par partition mais c'est même pas obligatoire

[Jaouad]

Oracle peut à partir de la 10g créer des tables à partir de .dump, ca marche comme des tables externes mais c'est pas des fichiers plats mais des fichiers DUMPS qui sont compresses ( ca c'est gratuit ) , il suffit de restaurer le fichier puis de creer la table et voila que tu accédes à tes données.

Ensuite sache que l'option partitioning est trés cher, tu peux egalement compressées tes tables et index améliorant ainsi les perfs en diminiuant l'espace consommée. Il te faudrat bien sur des CPU qui tiennent la route.

[Cereal123]

Merci de vos réponses. Je vais creuser les différentes pistes.
Bonne journée.
C.