Discussion :

[MonsieurTruite]

Bonjour à tous,

Nous avons une base de données Oracle de plusieurs Téraoctets (+/-600 tables), avec des données de plus de quinze ans, et nous souhaiterions historiser une partie de la base (probablement les données qui ont plus de trois ans).
Nous hésitons entre deux options :

1. Créer une nouvelle base totalement indépendante de la première où nous insérerions les données historiques
2. Créer un schéma parallèle au schéma de prod actuelle (nous ne voulons copier uniquement qu'un seul schéma) dans lequel nous mettrions les données historiques

Je ne sais pas s'il est intéressant de préciser :

• que chacune de nos tables est rattachée à un TABLESPACE historique lorsque il s'agit de données périodiques (DATA_2010, DATA_2011...), et à un TABLESPACE "de taille" (LARGE, VERY_LARGE...) pour les index.
• que si jamais l'option du schéma était la bonne, nous ne savons pas si nous devons créer un seul schéma (ce qui veut dire modifier les tables historiques, à chaque ADD COLUMN du schéma de prod) ou un par année.

Je n'ai pas vraiment de question précise en dehors du choix de ces deux options, j'aurais simplement souhaité entendre les avis éclairés des professionnels de longue date (après tout, je ne suis qu'un pauvre vingtenaire...) quant à "que faire, que pas faire".
En vous remerciant d'avance pour votre lecture bienveillante et vos conseils avisés.

PS : Je ne suis pas décisionnaire dans cette entreprise, et je n'ai donc pas de réponse à apporter quant à "est-il vraiment nécessaire d'historiser cette BDD" ?

[Fabien Celaia]

Il y a plusieurs options... souvent nécessitant de nouvelles et coûteuses licences...

La plus transparente pour vous est le partitionnement... mais peut-être l'utilisez-vous déjà puisque vous nous parlez de tablespaces différents.

Le schéma parallèle ne changera rien... il complexifiera juste vos développements.

Ce qui est impactant, c'est la fréquence à laquelle vous accédez à ces données d'historique... et de savoir ce que vous voulez vraiment garder (données brutes ou agrégées) et pourquoi vous voulez le garder...

Si vous partitionnez selon les dates, vous pourriez par exemple

• garder les données historiques sur des partitions en lecture seule,
• compresser des tables / partitions,
• ne sauvegarder que les partitions actives périodiquement,
• avoir des requêtes qui utilisent des indexes partitionnés, donc qui impactent moins de ligne (un tablescan se limitant par exemple aux données de l'année en cours),
• etc...

Database VLDB and Partitioning Guide

[MonsieurTruite]

Bonjour Fabien, et merci pour votre réponse.

Dans l'esprit des décideurs, le but de cet archivage est de gagner du temps lors du traitement des requêtes sur des tables "importantes" de plusieurs centaines de millions de lignes. Mais si vous m'assurez que séparer nos données de "prod" de nos données "historiques" dans des schémas distincts ne servira à rien... On s'embourbe dans une sacrée perte de temps.

Comme vous l'avez remarqué, nous utilisons déjà le partitionnement. Toutes nos tables problématiques, de par leur taille, sont périodisées ; 201701,201702... Et à chaque année sa partition.
Les données historisées ne seraient que très peu consultées, quelques fois par année, pour sortir des stats exceptionnelles. La plupart du temps, nous ne travaillons que sur la période en cours, et au maximum, sur douze mois tournants.
Si je ne m'abuse, on peut parler aussi bien de données brutes (NO_FACTURE,MONTANT,QUANTITÉ...) que de données agrégées (NO_CLIENT,CA_MOYEN_PAR_MOIS...), mais je parle sous votre contrôle.

Encore merci à vous.