Partitionner des tables existantes

Bonjour,

Je me documente actuellement sur le partitionnement, que j'envisage à moyen terme sur certaines grosses tables de notre base de production (9i).
Il ne semble pas exister une commande ALTER TABLE permettant de partitionner une table non encore partitionnée. :?

Pour l'instant, j'ai l'impression que pour fractionner ma table TOTO, je devrai :
1) Créer une table TOTO_TEMP, copie de TOTO
2) Supprimer ma table TOTO, et la recréer avec les clauses de partionnement
3) Réinsérer dans TOTO les données de TOTO_TEMP

Existe-t-il un moyen plus rapide et plus simple ?

Merci. :wink:

Tu peux créer un index partitionné qui fonctionne tout aussi bien et qui ne t'oblige pas à recréer ta table ;)

C'est-à-dire partionner uniquement l'index sur le champ en fonction duquel j'aurais partitionné la table , et laisser la table elle-même comme elle est ?

Pas tout à fait, tu ne partitionnes pas un index, mais tu recrées l'index en spécifiant plusieurs partitions ;)

Oui, je le comprenais bien comme ça :wink:
Mais dans la doc Oracle, ils ne parlent quasiment que des tables :?
Comment crées-tu un index en spécifiant plusieurs partitions ? :oops:

Code:

---

1 2 3 4 5 6 7

CREATE INDEX matable_part ON matable(colonne) GLOBAL PARTITION BY RANGE (colonne) ( PARTITION part_1 VALUES LESS THAN (100000), PARTITION part_2 VALUES LESS THAN (2000000), PARTITION part_max VALUES LESS THAN (MAXVALUE) )

---

Merci beaucoup :) je vais tester ça !!
Je voudrais essayer aussi la méthode BY HASH.

:!: c'est l'inconvénient du partitionnement par index et non sur la table... le BY HASH est impossible :(

mais quand la table est pleine (et a priori a bcp de lignes pour nécessiter un partitionnement) c'est assez compliqué de la copier :?

oui mais si le champ prévu pour partitionner la table n' est pas indexée
et figure pourtant dans les clauses where des requêtes
il est bien préférable de partitionner la table non ?
(surtout si on peut mettre les partitions dans des tablespaces différents)

Ah :( Voilà pourquoi je ne trouvais pas d'exemples :?

Donc, autrement dit, il vaut mieux prévoir dès la conception le partitionnement des tables :roll: Pas toujours évident :?

Finalement, mes tables n'ont peut-être pas tant besoin que ça d'être partitionnées :lol: Les plus grosses font 1 à 2 Go et plusieurs millions de lignes :roll: Est-ce qu'elles sont candidates pour le partitionnement ?

Oui ducho, je m'étais posé exactement la même question ! :roll:
Le partitionnement de la table semble dans certains cas être la seule solution...

Citation:

---

Envoyé par zestrellita

Finalement, mes tables n'ont peut-être pas tant besoin que ça d'être partitionnées :lol: Les plus grosses font 1 à 2 Go et plusieurs millions de lignes :roll: Est-ce qu'elles sont candidates pour le partitionnement ?

---

A mon avis ça peut effectivement être une solution mais pour moins le partitionnement reste la solution de la dernière chance ;)

Citation:

---

Envoyé par ducho

oui mais si le champ prévu pour partitionner la table n' est pas indexée
et figure pourtant dans les clauses where des requêtes
il est bien préférable de partitionner la table non ?
(surtout si on peut mettre les partitions dans des tablespaces différents)

---

Bah c'est tout l'intérêt de l'index partitionné... Sur les tables volumineuses un index classique peut ne pas être intéressant mais çà n'empêche pas d'indexer sur la colonne... dans ce cas on fait un index partitionné qui sera toujours plus performant qu'une table partitionné sans index ;)

Citation:

---

Envoyé par orafrance

A mon avis ça peut effectivement être une solution mais pour moins le partitionnement reste la solution de la dernière chance ;)

---

D'accord orafrance, cela me confirme dans le fait que ma base n'a pas de problèmes de performances au point de nécessiter un partitionnement.

Merci encore pour tous ces éclaircissements. :wink: