Discussion :

[serge0934]

Bonjour a tous,

J'ai une table d'infos avec plus de 1,5 milliard de lignes
une primary key dessus
je dois supprimer toutes les lignes dont la PK est inférieure a une valeur

pour pas péter le tablespace je procède par bloc de 1 000 000 de lignes avec un commit par bloc => 1mn par bloc => 16 heures au global

ma question:
existe une commande (ou ruse) qui permet de supprimer les 1 milliard de lignes d'un coup

merci de vos suggestions

[McM]

Tu dois supprimer quel % de ta table ?
Si c'est plus de 50 %, c'est peut être mieux de recréer une autre table avec les données à garder.

[LeoAnderson]

la table est-elle partitionnée ?
comptez-vous vider complètement une ou plusieurs partitions ?

[serge0934]

merci de vos réponses mais

1° plusieurs partitions pas obligatoirement totalement vidées
2° recréer avec les données restantes (500 000 000 lignes) prendrait le même temps je pense

[LeoAnderson]

si des partitions devaient être vidées, le truncate aurait pu être envisagé mais là, c'est mort...

[rouardg]

Bonsoir,

J'ai déjà fait une manipulation similaire. J'avais une table partitionnée par hashage, avec 32 partitions. La table faisait 520 Go au total, avec 1,5 milliard de lignes. Cette table avait aussi un index unique de PK, lui aussi partitionné (index local).

Pour ma part, je ne devais pas supprimer des enregistrements, mais ajouter 3 colonnes à cette table, dont une colonne avec une valeur par défaut. J'avais aussi 2 index locaux à rajouter.

Je te conseille donc de recréer ta table. Tu aurais pu faire un CTAS (Create Table As Select), mais comme tu as l'air d'avoir peu de place dans ton tablespace, je te conseille de transférer les données partition par partition, en utilisant le Hint APPEND (ce qui minimise l'UNDO) et le parallélisme.

Comme cela, à chaque fois que tu as traité une partition, tu peux faire un truncate de cette partition sur la table source, histoire de récupérer de la place.

De plus, tu peux faire ces manipulations en mode NOLOGGING (pour minimiser les REDO). Dans ce cas, mieux vaut planifier une sauvegarde de la base après.

Au final, sache que ce genre de manipulation est très long. Dans mon cas, la recréation de la table, son chargement partition par partition, la recréation de l'index de PK, la création des 2 nouveaux index, et la génération des statistiques à 10 %, le tout en mode NOLOGGING, +APPEND et avec un DOP (degré de parallélisme) de 4 sur l'insertion sur la partition cible, et un DOP de 4 sur la lecture de la partition source, m'a demandé 6 heures en production.