Requête de suppression qui reste bloquée [Résolu]

[lidybekham07]

* Bonjour, *

je travail sur oracle 10g
lors de la suppression des lignes (435 lignes) d'une table en exécutant la requête suivante

Code :

DELETE FROM table1 WHERE table1.cle1 IN (SELECT cle1 FROM TABLE 2)

sachant que cle1 est la clé primaire de la table 1
et la table 2 contient la liste des clé à supprimé
j'ai l'habitude d’exécuté ce type de requête et ça fonctionne mais cette fois ci
j'ai pas de réponse la requête prend beaucoup de temps plus d' 1h est aucune ligne supprimée.(m'affiche toujours patientez svp)
dans la console on à le message :

Code :

java.lang : repeating KEY value :1

j'ai vérifier dans mes deux tables j'ai pas de doublons .
j'ai arrêter les services et relancer mais toujours rien sachant que j'ai essayé de supprimé une ligne de la table 1 en indiquant une valeur mais la même chose "patientez svp"

* Merci *

[orafrance]

La table est peut-être verrouillée : http://oracle.developpez.com/faq/?page=3-1#lock

Sinon, faudrait voir la volumétrie.

[lidybekham07]

je vais vérifier si la table est verrouillée ou pas
pour ce qui concerne la volumétrie j'ai exécuter une instruction du même type sur une table de 50 millions de lignes j'ai pas eu de problème
alors que la table en question est moins volumineuse que celle ci

[laurentschneider]

tu peux consulter V$SESSION_LONGOPS where TIMEREMAINING>0 pour voir si un gros table scan est en cours, et sinon effectivement DBA_LOCKS ou ton outil graphique préférer pour voir qui bloque qui.

[lidybekham07]

j'ai vérifié la table n'est pas verrouille et y'av aucun scan sur cette table
alors j'ai essayer de supprimer une seule ligne s'à pris plus d'1 minutes mais celle ci à été supprimé
cependant en exécutant la requête cité auparavant j'attend mais rien plus de 1h de temps d'exécution mais rien est'il possible que le problème est lorsque j'utilise un in

[McM]

Utiliser un EXISTS serait mieux pour chopper des indexes.
Sinon, y aurait-il un trigger ON DELETE sur la table ?

[Waldar]

Ou dans le même esprit que le TRIGGER, des tables liées par des clefs étrangères ON DELETE à celle-ci ?

[McM]

Envoyé par Waldar

Ou dans le même esprit que le TRIGGER, des tables liées par des clefs étrangères ON DELETE à celle-ci ?

Voir aussi des tables filles avec clé étrangères non indexées.

[laurentschneider]

http://oracle.developpez.com/cours/#tuning

[jlm22]

Dans :

Code :

1
2
 
SELECT clef1 FROM TABLE 2

il représente quoi le 2 ? je ne connais pas ce type de requête
table2 je comprendrais mais table 2 je vois pas.

Cordialement

[orafrance]

C'est peut-être juste une faute de frappe, enfin, ce que j'en dis moi...

[jlm22]

mouai j'me disais aussi ... fin si il a fait la même chose dans son script ..

[lidybekham07]

alors pour l'instruction c'est juste une erreur de frappe c'est table2
la suppression de 400 lignes c'est exécuté au bout d'une journée je n'explique pas cette lenteur est du à quoi je cherche mais je trouve pas !!!
bon j'ai vérifier l'état de la table y'avait pas de problème certes y'a une clé étrangère dedans mais je l'utilise pas dans ma requête je travaille directe sur la clé primaire (la clé étrangère est indexé)
un exist ou un in n'aurait rien changé s'a aurai pris le mm temps d’exécution

[orafrance]

Si tu supprimes des enregistrements d'une table maitre, Oracle doit vérifier pour chaque PK supprimée s'il n'y a pas des dépendances via la FK, c'est surement ça qui est long... mais sans trace point de salut.

[lidybekham07]

possible que ces due à ça comment faire pour avoir des traces pas bien compris.
la table en question subit des insertions de milliers de lignes durant un intervalle de temps est il possible que c'est un problème d'index mm si son statut est valide et le re-compilé fera il l'affaire

[orafrance]

On va pas réexpliquer à chaque fois comment faire une trace

[iberserk]

Regardez votre plan d’exécution... ne serait-ce que pour une ligne...

Vérifiez le nombre d'index présent sur la table... ceux ci sont mis à jour à chaque DELETE/INSERT/UPDATE

Vérifiez vos triggers...
La table n'est elle pas massivement accédée en lecture au moment de l'execution...

etc.

[iberserk]

Ces lenteurs n'interviennent que sur cette table?

[lidybekham07]

je vais re-compilé les indexe car cette table est périodiquement mise à jour (insertion de plus de 1000lignes)
oui la lenteur intervient juste au niveau de cette table j'ai une autre plus volumineuse qui fait 4fois la taille de celle ci mais la suppression ne prend pas bcp de temps une affaire de secondes

[orafrance]

Envoyé par lidybekham07

je vais re-compilé les indexe car cette table est périodiquement mise à jour (insertion de plus de 1000lignes)

Voila qui est totalement inutile. L'index est mis à jour quand les données sont modifiés et les risques de dégradation de performance des indexes lors de l'insertion de ligne est mineur... si tant est qu'il existe