Discussion :

[grouhan]

Bonjour,

lors d'un traitement qui utilise une table pour stocker des données de façon temporaire (insert/delete) des row lock contentions TX - Row lock contention apparaissent lorsque l'application est mise en charge (12 utilisateurs virtuels) simulant l'accès à la fonctionnalité (recherche d'informations client à partir de son id)

Le test est effectué avec des users différents et utilise un id client différent (l'id de session et l'id client étant utilisés dans les données stockées dans la table) donc aucune raison d'avoir des contentions.

A défaut de comprendre les raisons de ces contentions, l'utilisation d'une table temporaire permettrait-il d'améliorer cette fonctionnalité ?

L'insert/delete à haute fréquence a t'il un impact sur le volume de stockage de la table en question ?

Merci par avance pour vos retours

[McM]

Est-ce que tu n'aurais pas des contraintes référentielles vers la table que tu DELETE, contraintes non indexées ?

[grouhan]

Bonjour,

non pas de contrainte référentielle sur ma table que je delete ligne par ligne, c'est juste une table de travail qui sert à stocker des données avant de les afficher

[pachot]

Si les sessions différentes n'ont pas à partager leurs données alors, oui, global temporary table est fait pour.
Normalement "TX - Row lock contention" est vraiement un verrou ligne. A vérivfier que c'est bien un lock exclusif (mode 6). Il pourrait y avoir contention au niveau block (ITL) ou index.

[grouhan]

Bonjour,

Il s'agit bien d'un lock exclusif.

Pour complément de contexte, la base est en mode RAC.

En pièce jointe le rapport AWR. Les contentions sont sur la table ZAUTED30

[pachot]

En pièce jointe le rapport AWR. Les contentions sont sur la table ZAUTED30

Ok, première remarque, les enq: TX ne représentent que 6% du temps
Deuxième remarque: SQL*Net break/reset to client veut dire qu'il y a beaucoup de requêtes en erreur
Il semble effectivement que plusieurs sessions cherchent parfois à supprimer les même enregistrements