1. #1
    Futur Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2017
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2017
    Messages : 13
    Points : 8
    Points
    8

    Par défaut Historiser/archiver les données de plus de X années

    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" ?

  2. #2
    Rédacteur/Modérateur

    Avatar de Fabien Celaia
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    octobre 2002
    Messages
    4 130
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Service public

    Informations forums :
    Inscription : octobre 2002
    Messages : 4 130
    Points : 18 270
    Points
    18 270
    Billets dans le blog
    19

    Par défaut

    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
    Sr DBA Oracle / MS-SQL / MySQL / Postgresql / SAP-Sybase / Informix / DB2

    N'oublie pas de consulter mes articles, mon blog, les cours et les FAQ SGBD

    Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums !

  3. #3
    Futur Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2017
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2017
    Messages : 13
    Points : 8
    Points
    8

    Par défaut

    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.

Discussions similaires

  1. Comment archiver les données ?
    Par khadi8 dans le forum Administration
    Réponses: 2
    Dernier message: 08/03/2013, 16h26
  2. extraire les données de plus d'un an
    Par le nOoB dans le forum PHP & MySQL
    Réponses: 5
    Dernier message: 09/12/2011, 11h53
  3. Archiver les données d'une table dans une autre
    Par Decon dans le forum Oracle
    Réponses: 6
    Dernier message: 22/08/2011, 18h25
  4. Réponses: 12
    Dernier message: 14/02/2008, 04h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo