IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Oracle Discussion :

[10g][Best Practice] Partitionnement pour archivage


Sujet :

Oracle

  1. #1
    Membre émérite Avatar de nuke_y
    Profil pro
    Indépendant en analyse de données
    Inscrit en
    Mai 2004
    Messages
    2 076
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Indépendant en analyse de données

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 076
    Points : 2 328
    Points
    2 328
    Par défaut [10g][Best Practice] Partitionnement pour archivage
    Bonjour à tous.

    Mon client a un datawarehouse qui commence à avoir un peu d'historique (depuis 2004).

    Nous souhaitons profiter de la mise à disposition d'un nouveau serveur plus costaud pour mettre en place certaines pratiques, particulièrement l'archivage des données.

    2 tables de faits (disons TABLE1 et TABLE2) ont un historique depuis 2004 et représentent 20 Go (environ 6 go par année).

    La clé principale de ces 2 tables est une date (disons TABLE1.DATE_REF et TABLE2.DATE_REF), donc la solution d'archiver chaque année séparement en se basant sur le critère de cette date paraît logique.

    Le but de cet archivage est double :
    - ranger un peu et mettre en place des pratiques propres,
    - alléger les tables pour alléger aussi les requêtes.

    Cependant en rédigeant le document de spécification et en relisant certains sujets en rapport au partitionnement, je me pose des questions.

    1) Le partitionnement est-il la meilleure solution (simplicité, coûts) pour archiver des vieilles données qui doivent rester disponibles (ou semi-disponibles, disons pas avec une disponibilité haute) ?
    La réponse semble être oui dans ce lien.

    2) Est-ce que le partitionnement joue sur la lourdeur des requêtes à partir du moment où il n'y a pas de scan sur toute la table mais accés aux données seulement via des index ?

    3) Ne vaudrait-il mieux pas d'abord passer sur le nouveau serveur, puis étudier les requêtes pour voir si un partitionnement est bien nécessaire ?
    Mais qu'est-ce qui motive le passage à un partitionnement ? Pour des raisons de perfs sur des requêtes indexées, ne vaudrait-il mieux pas partitionner les index plutôt que les tables ?

    4) Est-ce que des tables partitionnées accélèrent ou ralentissent le calcul des statistiques ? Est-ce qu'on peut recalculer les stats seulement sur la dernière partition (si les autres sont considérées comme figées) ?

    5) Est-ce qu'on peut considérer que partitionner les tables à gros historique sur la date de référence pour "ranger un peu" ne posera pas (plus) de problème de perfs et qu'on peut le faire de toutes façons, quitte à partitionner aussi les index derrière ou toute autre opération de tuning ?



    Vous comprendrez qu'on a fait le raisonnement suivant :
    - on a de grosses tables
    - ouaih et on a des perfs qui trainent la patte
    - bah les grosses tables y a des années qui servent à rien
    - on a qu'à les archiver en partitionnant !!
    - ouaih bonne idée, comme ça ça sera bien rangé
    - et puis ça sera mieux pour les requêtes.

    On a un peu mélangé le côté archive et le côté tuning et ça donne un peu n'importe quoi.


    Merci de vos idées / conseils / menaces.
    Il vaut mieux monopoliser son intelligence sur des bêtises que sa bêtise sur des choses intelligentes.

  2. #2
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 073
    Points
    19 073
    Par défaut
    1) ça me parait le mieux, avec une compression des datas tu économises du disque en plus... par contre, un GROS bémol, l'option est onéreuse voir très cher

    2) non, sauf si tu veux vraiment affiner tes requêtes en ne sélectionnant qu'une liste de partitions

    3) le partitionnement sera forcément nécessaire à un moment ou un autre

    4) bah normalement c'est pareil... on peut en effet calculer les stats que sur une seule partition, cf la doc (partname)

    5) à part changer le plan d'exécution tu risques pas grand chose

    Conclusion : il faut évidemment tester avant de livrer en production, mais j'ai rarement eu de problème

  3. #3
    Membre émérite Avatar de nuke_y
    Profil pro
    Indépendant en analyse de données
    Inscrit en
    Mai 2004
    Messages
    2 076
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Indépendant en analyse de données

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 076
    Points : 2 328
    Points
    2 328
    Par défaut
    Ah oui tiens, cette histoire de prix de l'option m'était sortie de la tête. Je vais pousser là dessus aussi...

    Pour la question 3), je me suis posé la question en relisant ce sujet là où tu semblais expliquer qu'il existe tout un tas d'autres solutions meilleures que le partitionnement pour résoudre des problèmatiques de perfs liées à des tables à gros volumes.
    Il vaut mieux monopoliser son intelligence sur des bêtises que sa bêtise sur des choses intelligentes.

  4. #4
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 073
    Points
    19 073
    Par défaut
    c'est pas parce qu'il y a d'autres solutions que le partitionnement en est une mauvaise

    Et dans le sujet, je faisais remarquer qu'il faut faire un minimum d'analyse pour s'assurer qu'il n'y a pas des choses à faire avant et non qu'il fallait se passer de partitionner

Discussions similaires

  1. [Flex] Recherche de Best Practice pour l'alignement
    Par eXiaNazaire dans le forum Flex
    Réponses: 5
    Dernier message: 11/02/2008, 17h14
  2. Best practice pour un insérer/remplacer
    Par Antoun dans le forum SQL
    Réponses: 2
    Dernier message: 09/01/2008, 14h10
  3. Réponses: 4
    Dernier message: 17/11/2006, 11h46
  4. Réponses: 11
    Dernier message: 16/06/2006, 14h46
  5. Réponses: 4
    Dernier message: 23/05/2006, 15h22

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