Discussion :

[bstevy]

Bonjour à tous,


Voilà, je suis à la recherche de la meilleur solution pour réaliser un update dans mon cas.
Nous souhaiterions mettre à jour environ 400 000 000 lignes dans une table de 1 000 000 000 lignes.


Nous hésitons sur plusieurs solutions, et je ne me rends pas trop compte de ce qui peut etre le plus efficace.

Moi, ma solution serait la suivante :

Solution 1 :
on crée une nouvelle table de structure identique
On alimente la nouvelle table avec un insert et en modifiant les valeurs au passage qui nous intéresse.
On echange les deux tables.

Mes collègues ont proposé d'autres solutions :

Solution 2 :
On crée une boucle for sur la table et on met à jour ligne par ligne avec un commit entre chaque.

Solution 3 :
On extrait les lignes dans une nouvelle table et on les modifie
On supprime les lignes dans la table d'origine et on les ré-insère modifiées

Sachant que d'un point de vue technique, nous avons quand même les contraintes suivantes :

1. La table recoit en permanence des nouveaux records
2. Des package font réference à la table
3. La table doit restée accessible

Je ne sais pas trop comment ces contraintes peuvent influencer l'alimentation et les mise à jour de la table.

Quelle solution me conseilleriez vous ? avez vous d'autres solutions à proposer ?

Merci d'avance.


Steven

[mnitu]

Testez par vous même et revenez nous faire part de vos conclusions.

[skuatamad]

Juste pour préciser, la solution 1 doit se faire en create table as select ou alors alimentation en mode append, l'objectif de cette solution étant de ne pas générer d'undo.
Et avant d'échanger les tables, il ne faut pas oublier de redonner les droits, reconstruire les index, les triggers...

La solution 2 n'est presque pas testable, 400 millions en ligne par ligne c'est super lent...
Avec un commit à chaque ligne, c'est encore plus lent et ça finira par un snapshot too old.

La solution 3 supprime et réinsere... ça génère plus d'undo que juste mettre à jour, quel serait l'intérêt ?

Sachant que d'un point de vue technique, nous avons quand même les contraintes suivantes :
...

Le package DBMS_REDEFINITION permet une implémentation à chaud de la solution 1.

[bstevy]

Merci beaucoup pour cette réponse.
C'est pile ce dont j'avais besoin

Je vais étudier ce package et voir ce que je peux en tirer.

Soit dit en passant, mes chefs sont plus pour implementer la solution 2