Discussion :

[neo.51]

Bonjour,

Je travaille sur oracle 8i sous windows 2003 server.
A titre indicatif cette machinne est un xeon 3,2Ghz avec 1Go de RAM DDR2 et 2 disque dur SATA2 en raid 0.

j'ai une relation en 1,N entre 2 tables

Code :

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

1
2
3
4
5
6
TableA
-CLETABLEA
 
TABLEB
-CLETABLEB
-CLETABLEA

Ces 3 champs sont indéxés

Suite à un soucis avec le logiciel attaquant cette base, je dois supprimer toutes le données de la TableB qui n'ont aucun enregistrement liés à un enregistrement de la table A donc la requete est :

Code :

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

1
2
DELETE TABLEB WHERE TABLEB.CLETABLEA NOT IN(SELECT CLETABLEA FROM TABLEA);
commit;

Mais, chaque table fait environ 1 900 000 enregistrement.

J'ai lancé cette requête vendredi et ce matin l'instance manager me dit que le temps écoulé et de 69H et que le temps restant estimé est de 269H

Vous comprendrez que ça fait un peu trop long pour moi.

Je cherche donc à optimiser le temps de traitement sur cette requete.

La première chose étrange est que sur mon serveur seulement 15/20% du cpu est utilisé... comment faire pour utiliser 100% du cpu ? Pareil pour la mémoire alors que cette machine est dédié à la réparation de la base...
Je n'ai pourtant mis aucune limitation sur l'utilisation des ressources système de mes profils(tout a été laissé par défaut).

La deuxième chose est que sqlplus utilise systèmatiquement une transaction lorsqu'on veut éxécuter une requete. Je pense que ça ralentit beaucoup les performances, comment ne pas utiliser le mode transactionnel dans une requete sous sqlplus ?


Voilà, j'attends vos conseils avisés

[orafrance]

En général NOT EXISTS est plus performant :

Code :

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

1
2
3
4
DELETE TABLEB WHERE NOT EXISTS
(SELECT 1 
FROM TABLEA 
WHERE TABLEB.CLETABLEA = TABLEA.CLETABLEA);

Evidemment, il faudra un index sur TABLEB.CLETABLEA pour retrouver la ligne plus rapidement dans le NOT EXISTS et un index sur TABLEA.CLETABLEA pour retrouver la ligne à supprimer plus rapidement. Eventuellement, regarde du coté des indexes partitionnées.

[bilalove]

Dans ta requete, le traitement doit verifier pour chaque ligne de TABLEA les 1900000 lignes de TABLEB. Ce qui veut dire qlq chose comme 1900000 * 1900000 lignes en total. C'est énorme.

Essayez la requete suivante pour profiter des indexes :

Code :

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

1
2
3
4
5
6
 
DELETE TABLEB B WHERE not exists 
                                         (Select  null
                                          From    TABLEA A
                                          Where  A.CLETABLEA= B.CLETABLEA);
commit;

[neo.51]

ok,

exécution de la requete quasi instantannée

J'ai par contre du mal à saisir toutes les subtilitées de la requête.

En gros on fait une jointure directement entre les 2 tables pour éviter de faire N*N et de reparcourir les 1 900 000 CLETACHE à chaque fois.

Mais j'ai du mal sur le SELECT NULL, ça retourne quoi ?


en tous cas beaucoup

[orafrance]

SELECT NULL est déconseillé mais bon... le principe est simple. Au lieu de rechercher pour chacune des lignes de tableA, si une correspondance existe parmis tours les des lignes de tableB, on supprime toutes les lignes de tableA pour lesquelles la correspondance n'existe pas. Donc dans la clause WHERE tu limites ENORMEMENT le nombre de lignes sélectionné et donc tu accélères le traitement.

SELECT NULL ne sert à rien, tu pourrais autant sélectionné CLETABLE ou 1... ce qui t'intéresse c'est que la ligne existe et pas la valeur qu'elle retourne

[neo.51]

ok, merci pour tout

[bilalove]

La sub_query :

Code :

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

1
2
 
where not exists(select xxxx from .... where ....)

retourne VRAI si NO ROWS SELECTED et FALSE dans le cas contraire.
et c'est le plus important : verifier l'existence quelque soit ce qu'on selectionne dans XXXX.

[orafrance]

Plus exactement, NOT EXISTS est vérifié lorsque NO_DATA_FOUND est déclenché dans la sous requête

NO ROW SELECTED c'est juste un message de SQL*Plus

[bilalove]

Exact ORAFRANCE

Par contre, je m'excuse pour les reponses doublo, car ça se fait apparemment en parallèle.

[orafrance]

ce sont les aléas causés par des réponses un peu longue

Ca permet de confirmer