Requête de suppression qui reste bloquée

**lidybekham07** · 26/05/2011, 18h57

* 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 :

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

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 :

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

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** · 27/05/2011, 08h52

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

Sinon, faudrait voir la volumétrie.

**lidybekham07** · 27/05/2011, 11h16

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** · 27/05/2011, 15h41

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** · 29/05/2011, 11h14

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** · 29/05/2011, 20h58

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

**Waldar** · 30/05/2011, 11h17

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

**McM** · 30/05/2011, 13h28

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** · 30/05/2011, 15h02

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

**jlm22** · 31/05/2011, 08h52

Dans :

Code :

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

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** · 31/05/2011, 09h10

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

**jlm22** · 31/05/2011, 09h37

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

**lidybekham07** · 01/06/2011, 10h01

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** · 01/06/2011, 10h09

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** · 01/06/2011, 11h58

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** · 01/06/2011, 15h08

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

**iberserk** · 02/06/2011, 18h54

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** · 02/06/2011, 18h55

Ces lenteurs n'interviennent que sur cette table?

**lidybekham07** · 02/06/2011, 19h45

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** · 06/06/2011, 11h59

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

Requête de suppression qui reste bloquée

Oracle

Discussions similaires

Partager

Partager