Discussion :

[duple]

Bonjour,

Depuis aujourd'hui, je constate une grosse lenteur sur les UPDATE/DELETE d'une table de bases de données.
En effet, si je fais un simple SELECT c'est assez rapide dans les norme. Mais quand je fais un DELETE ou une UPDATE sur cette ligne que je viens de SELECTionner, l'execution de la requête est catastrophique (prend plusieures minutes). Je précise que la base en est cours de production. Et que d'après les constatations un INSERT est assez rapide aussi dans les norme. Pour remarque, cet incident n'arrive qu'à une table specifique. Sauriez-vous d'où peut provenir le problème ? Ce problème n'apparait qu'aujourd'hui.
Mais même si je fait un DELETE FROM table WHERE clé_primaire = "1_tuple" cela me fait toujours un temps considérable d'execution (plusieurs minutes).
Je crois que c'est peut être du au verrou poser sur la table ?? Puisque la base est en prod. Mais pourquoi auparavant n'apparaissait pas ce problème ?? Ou peut être un problème d'écriture sur disque ? Mais pourquoi, les opérations DE SELECT et INSERT ne sont pas inpactées ? Aviez-vous une explication concrète qui pourrait résoudre ceci ?
Par ailleurs, sauriez vous comment voir le statut d'une requête executée en live ? C'est à dire si elle est blockée ? Si oui par qui ? Comment fait on pour annuler la requête blocante ? Comment fait on pour déverouiller un objet, car je constate également que la compilation d'une procédure se rapportant à cette table specifique est verouillée jusqu'à liberation de ce verrou.

Esperons que vous pouvez apporter des réponses à ce sujet ?

[Waldar]

Sans ordre particulier :
Vérifiez que l'ensemble des colonnes sur lequel vous faites la mise à jour / suppression est correctement indexé : si vous faites un delete from where col1 = 'A' and col2 = 'B', le meilleur index est (col1, col2), pas un index sur col1 et un autre sur col2.
Regardez le nombre d'index que possède la table : si vous avez 25 index à mettre à jour pour une suppression, ça prend un peu de temps.
Regardez si votre table possède des déclencheurs : il peut y avoir des traitements qui se déclenchent, il faut regarder lesquels.
Vérifiez que vous n'avez pas de liste chaînées : cela devrait aussi impacter le select j'imagine, mais autant vous fournir le maximum de pistes, c'est toutefois la moins probable.

Analyser également vos plans d'exécutions réels, autotrace et trace complète.

Pour tout ce qui est monitoring, regardez du côté d'Oracle Enterprise Manager, mais la 8i n'étant plus supportée depuis très longtemps vous allez probablement souffrir à trouver les sources d'une version compatible.
Sinon il doit bien y avoir quelques options du côté de SQL Developer, avec les mêmes problématiques de version.

[mjdidi]

Surtout il faut chercher des indexes crées sur la table récemment .

[duple]

Non, j'ai pas créé d'index recemment.
C'est dingue car le phénomène n'apparaissait que ce lundi. J'ai testé lundi soir, et çà avait l'air de repartir. Maintenant les vitesses d'executions des update et delete redeviennent à la normale. Je soubçonne l'attente de verrous d'en être la cause, à votre avis ?
Dommage, j'ai pas de requête pour suivre ces attentes de verrou, afin de savoir qui bloque qui.
Merci de votre aide

[skuatamad]

Questions on Locking

[Ikebukuro]

Lors du DELETE, peut-être que des SELECT sont faits dans les tables ayant une Foreign Key sur la table délétée, non?
Idem pour l'update : si tu updates COL1 et qu'il y a des FK dessus, cet Update peut être refusé par Oracle mais pour ça il doit faire des SELECT dans les tables filles.

[mnitu]

Tracez (trace SQL étendue) l'exécution de la requête sous sqlplus puis analysez la trace pour comprendre ce qui se passe.