[10g][Best Practice] Partitionnement pour archivage

[nuke_y]

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.

[orafrance]

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

[nuke_y]

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.

[orafrance]

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