background success stories

Quel est le lien entre l’attente « enq: TS – contention » et un problème de verrou avec le processus SMON ?

Après une première recherche sur Internet, nous pouvons constater que l’attente « enq: TS – contention » fait directement référence aux segments temporaires (Temporary Segment). Il s’agit en fait d’une contention au niveau de la structure mémoire qui gère les accès aux segments temporaires.

Le processus SMON (System MONitor) est chargé de vérifier la cohérence du système et de la rétablir suite à un incident au démarrage de la base suivant. Ainsi, si l’instance n’a pas été stoppée correctement, le processus analyse les informations stockées dans les rollbacks segments puis annule toutes les informations en attente mais pour lesquelles aucune validation n’a été enregistrées. Ainsi SMON a un rôle de libération des ressources utilisées inutilement par le système.

Mais le processus SMON surveille également les espaces libres des fichiers de la base de données. Il fusionne notamment les extents adjacents libres. Ainsi lors qu’il y a de nombreux segments temporaires utilisés, nous pouvons constater des attentes au niveaux des sessions utilisateurs alors que le niveau d’attente de type « enq: TS – contention » peut être relativement faible.

Exemple:

Sid                              Unix                    Date                Last
Session       Instance   Serial# Proc. Id  Utilis.       Connexion      Etat Call       Programme                                          TAG
------------- ---------- ------- --------- ------------- -------------- ---- ---------- -------------------------------------------------- --------
1086          xxxxx2           1 127193    Internal      03-07-17 09:11 ACTI 1250:13:14 oracle@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.com (SMON)   #LOCK#
   873        xxxxx1       10013 110162    USER1         24-08-17 09:22 ACTI 1:54:9     xxxxxxxxxxx@xxxxx (TNS V1-V3)                      #LOCK#

Après avoir vérifier l’impact réel sur l’instance, il y a alors plusieurs possibilités (à adapter selon l’impact) :

  • Identifier et supprimer les sessions qui utilisent le plus d’espace temporaire
  • Vérifier la configuration de la PGA et éventuellement l’augmenter
  • Optimiser les requêtes utilisant l’espace temporaire
  • . . .

Attention, le problème semble se produire surtout 10g et 11g. Il y a de nombreux dysfonctionnements et notes relatives à ces attentes :

  • Bug 12552386 – Unnecessary « enq: TS – contention » waits 5 seconds in parallel operation (Doc ID 12552386.8)
  • Bug 9216806 – Hight « enq: TS – Contention » for temporary segment from direct path load (Doc ID 9216806.8)
  • Bug 12865902 – NOWAIT lock request could hang (like Parallel Queries may hang « enq: TS – contention ») in RAC (Doc ID 12865902.8)
  • . . .