Hello,
 
Je possede une base de donnée avec 20 tables. Une de ces tables me sers à stocker des utilisateurs qui doivent ètre effacés des autres tables, cette table appellée USER_DELETE comporte 600 000 lignes et dans les autres tables la taille est comprise entre 500 000 et 3 000 000 de ligne.
 
J'ai créé un package appellant deux procédure stockées:
 
- la premiere procédure place un curseur sur la table USER_DELETE et appelle la seconde procédure avec en paramétre l'élément du curseur (je recupere un id appellé d_id avec le curseur).
 
- la deuxieme procédure effectue un delete sur 15 tables de la maniere suivante "delete CLIENT_PRESTATION t where d_id = t.id;" et sur 4 tables de la maniere suivante "delete INSTANT_STAT t where exists (select 1 from INSTANT_SESSION ins
          where ins.instant_session_id = t.instant_session_id and d_id = ins.user_id);"
 
Les tables possede des index sur les champs id.
 
Mon temps d'execution est de 0.6 sec par utilisateur, il me faudrait donc au moins 100 heures pour effectuer tout mes delete. Pensez vous que ce temps d'execution est honnete ? peut il etre amélioré ? Si oui comment ?
 
Merci d'avance ...

ce serait pas plus simple de faire une PK sur USER_DELETE et des FK avec DELETE CASCADE sur les autres tables ?

FK cad foreign key ? tu voudrais que je mette des foreign key sur mon id sur les différentes tables ? mais une foreign key vers quel table ? car ma table USER_DELETE ne comprend pas l'ensemble des utilisateurs, juste ceux qui doivent etre delete.
 
Qu'entend tu pas PK ?

oui foreign key (FK) qui s'appuie sur la primary key (PK) de USER_DELETE. Tu peux créer la FK avec l'option NOVALIDATE ce qui évite les erreurs en cas d'absence d'enregistrement père
 
Bien sûr, il sera probablement intéressant de créer un index sur les ID des tables liées

Je ressors ce vieux sujet parce qu'il arrive en premier sur google quand on cherche "sql optimisation delete"    
 
Donc voilà, j'ai beaucoup cherché et difficilement trouvé

Après plusieurs test dans le topic qui se trouve dans ma signature, je suis arrivé malgré mes convictions à la conclusion que le IN est plus rapide que le EXISTS (et c'est plutôt flagrant).
 
Donc première optimisation, tu peux utiliser IN.
 
Ensuite, plutôt que de faire un curseur qui va exécuter 600 000 * 20 requêtes DELETE à la suite, je ferais plutôt un truc du genre :
 
DELETE maTable where USER_ID in (select id from delete_user);
 
En espérant que ça fait pas sauter le rollback segment.
 
L'intérêt du truc, c'est que tu ne va lancer que 20 requêtes, ce qui devrait être bien plus rapide.
 
Pour le coup du CASCADE, je suis assez froid, par expérience, c'est :
- source de rollback segment fault (parceque là tu va shooter tout le monde dans les 20 tables à la fois, ce qui multiplie un peu le nombre d'éléments supprimés dans la transaction)
- source de patatage++, genre t'oublie une condition dans ton delete, et tu te retrouves au bout de 4 heures avec une base vide
 
 
 
GRMPF ! Mais c'est quoi ce déterrage, et moi qui répond comme un con
 
(me disait bien aussi que j'avais pas vu orafrance depuis un bout de temps )

Ouais désolé pour le déterrage, mon message a été tronqué. Je le remets, nos "réponses" peuvent être utiles  
Donc je disais :
 
Je ress

Arg ! je suis encore tronqué ! Bon je vais à l'essentiel, voilà ce que j'ai trouvé de mieux, avec forçage d'index :
delete Table1 from Table1 (index N) where Table1.number in (select Table2.number from Table2)