Problème de SUBPARTITION

Hello,

PROBLEME:
J'ai une très grande table en Oracle 10.2 (+- 1.500.000.000 d'enregistrements) qui est partitionnée (PARTITION BY RANGE) sur base d'une colonne.
Je dois maintenant sous-partitionner chaque partition (SUBPARTITION BY LIST) sur base d'une autre colonne, ce qui est tout à fait possible pour une nouvelle table.

QUESTION:
Est-ce possible d'éclater des partitions en sous-partitions dans une table existante ou dois-je recréer la table (avec partitions et sous-partitions) et transferer les enregistrements de l'ancienne vers la nouvelle table ?

Merci d'avance.
Maïky.

je crains que tu sois obligé de recréer la table :(

Bonjour,

J'ai eu une problématique similaire à la tienne. En fait, c'était une table partitionnée par hashage (en 32 partitions), sur laquelle il fallait ajouter 3 colonnes, dont une obligatoire avec une valeur par défaut. La table faisait plus de 400 Go, avec 1,3 milliard de lignes.

Par expérience, je te conseille de recréer ta table. Avec un tel volume, inutile de te dire qu'il faut travailler en NOLOGGING, et en parallèle.

Une solution serait d'utiliser un CTAS (Create Table As Select). Malheureusement, il te faut dans ton(es) tablespace(s) un espace libre aussi important que la taille de ta table.

Une autre solution consiste à travailler partition par partition, ce qui réduit le besoin en espace libre, puisque tu n'as besoin en espace libre que la taille de la plus grande partition.

Exemple de script dont tu peux t'inspirer, en supposant que ta table s'appelle X. En premier, tu créées ta nouvelle table X_TMP en NOLOGGING, avec ses sous partitions :

Code:

---

1 2 3 4 5 6 7 8

ALTER SESSION ENABLE PARALLEL QUERY ; ALTER SESSION ENABLE PARALLEL DML ; ALTER SESSION ENABLE PARALLEL DDL ;   CREATE TABLE X_TMP (....) PARTITION BY RANGE (...) SUBPARTITION BY LIST (...) (........) NOLOGGING ;

---

Ensuite, pour chaque partition de ta table X, tu transfères les données, en parallèle et en mode APPEND, puis tu libères l'espace des données qui ont été transférées :

Code:

---

1 2 3 4 5 6

insert /*+ APPEND PARALLEL (X_TMP, 8) */ into X_TMP select /*+ PARALLEL (P, 8) */ * from X partition (NOM_PARTITION) P ;   commit ;   alter table X truncate partition NOM_PARTITION drop storage ;

---

A noter que tu peux mettre un DOP (Degree Of Parallelism) autre que 8.

Pour finir, il faut dropper la table X, renommer X_TMP en X, la remettre en LOGGING, gérer son dergé de parallélisme, et reconstruire dessus tous ses index, ses triggers (je ne pense pas que tu en ais), recréée les contraintes (genre PK) et remettre les grants.

Code:

---

1 2 3 4

Drop table X ;   rename X_TMP to X ; alter table X logging noparallel ;

---

A toi de t'inspirer de ce code. Bien entendu, comme tout se fait en NOLOGGING, je te conseille d'avoir une sauvegarde de ta base avant la réorganisation, et de refaire une sauvegarde une fois le travail terminé.

la compression des tablespaces ne permettrait-elle pas de gagner de la place pendant l'opération avec même un gain de perf possible ?

faut pas oublier de recréer les GRANT et indexes après aussi ;)

NON ! :alerte:

La seule solution facile et impactant peu l'exploitation est la redéfinition on-line : dbms_redefinition !

on n'oublie rien, et on fait ce qu'on veut sur les tables... 8-)

tu pourrais donner un exemple de syntaxe pour créer une sous-partition STP ?

Je n'exclue pas la solution par DBMS_REDEFINITION.

Je n'ai utilisé ce package qu'une seule fois, et il n'est pas toujours facile à saisir.

Maintenant, ce package peut-il travailler partition par partition ?
Cela m'étonnerait. Donc si tu as une table partitionnée de 400 Go, il te faut alors 400 Go de libre pour redéfinir la table !!!

Avec ma méthode, il ne me fallait que 13 Go de libre, parce qu'une partition faisait 400 / 32 = 13 Go.

Non, je l'ai trouvé assez simple à utiliser mais il ne travaille que globalement au niveau de la table, c'est vrai !
mais il est "on line" ! :)

après, le principe général est le suivant :

1. On créee la structure cible vide
2. On déclare les objets dépendants qui doivent être retravaillés
3. On commence la rédéfinition (il se sert de la structure vide pour créer un snapshot et garantir ainsi l'exploitatibilité de la table)
4. On synchronise le snapshots avec la vrai table
5. Fini

je l'ai jamais utilisé et la doc ne parait pas plétorique :(

Et la note 177407.1 ne t'éclaire pas d'avantage ? 8O

Pour FRED_D : au sujet de la compression, cela permet effectivement de gagner de la place. Il faut faire l'essai, car il n'est pas facile de prédire le taux de compression.

Il ne faut pas oublier que la compression de données se fait au niveau du bloc Oracle. Le taux de compression peut être grandement amélioré si l'on peut (ce qui n'est pas toujours facile) trier ses données avant de les injecter dans la table compressée.

Sinon la compression n'apporte jamais d'amélioration de performance. Juste comme on dit un léger overhead.

Pour finir, un exemple de table sous-partitionnée :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

CREATE TABLE essai ( TEMPS_MOIS_ID NUMBER NOT NULL, PRD_FAM_PP_ID NUMBER NOT NULL, .......... ) TABLESPACE TBS_DAT NOLOGGING PARTITION BY RANGE (TEMPS_MOIS_ID) SUBPARTITION BY LIST (STAT_ID) ( PARTITION SG2_DTM_AFA_200312_PAR VALUES LESS THAN (200401) TABLESPACE TBS_SG2_DTM_PAR_200312 ( SUBPARTITION SG2_DTM_AFA_200312_PAR_1 VALUES (1) TABLESPACE TBS_SG2_DTM_PAR_200312, SUBPARTITION SG2_DTM_AFA_200312_PAR_2 VALUES (5) TABLESPACE TBS_SG2_DTM_PAR_200312, SUBPARTITION SG2_DTM_AFA_200312_PAR_3 VALUES (3) TABLESPACE TBS_SG2_DTM_PAR_200312, SUBPARTITION SG2_DTM_AFA_200312_PAR_4 VALUES (4) TABLESPACE TBS_SG2_DTM_PAR_200312 ), PARTITION SG2_DTM_AFA_200401_PAR VALUES LESS THAN (200402) TABLESPACE TBS_SG2_DTM_PAR_200401 ( SUBPARTITION SG2_DTM_AFA_200401_PAR_1 VALUES (1) TABLESPACE TBS_SG2_DTM_PAR_200401, SUBPARTITION SG2_DTM_AFA_200401_PAR_2 VALUES (5) TABLESPACE TBS_SG2_DTM_PAR_200401, SUBPARTITION SG2_DTM_AFA_200401_PAR_3 VALUES (3) TABLESPACE TBS_SG2_DTM_PAR_200401, SUBPARTITION SG2_DTM_AFA_200401_PAR_4 VALUES (4) TABLESPACE TBS_SG2_DTM_PAR_200401 ), ............... ..............) ;

---

Citation:

---

Envoyé par rouardg

Sinon la compression n'apporte jamais d'amélioration de performance. Juste comme on dit un léger overhead.

---

Alors là, permet moi de t'affirmer le contraire... la compression peut bel et bien améliorer les perfs, je crois qu'Aline en a fait le témoignage ici même ;)

pour info : http://www.oracle.com/technology/pro...rmance_twp.pdf