Discussion :

[Maïky]

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.

[orafrance]

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

[rouardg]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é.

[orafrance]

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 ?

[orafrance]

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

[LeoAnderson]

NON !

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...