Le Blog de Rajat DBA

Ceci est une copie de la Note de référence 22908.1 de Metalink, pour ceux qui n’y ont pas accès.

1. Qu’est-ce qu’un loquet?
   Les loquets sont des mécanismes de sérialisation de bas niveau utilisés pour protéger les structures de données partagées dans le SGA. La mise en œuvre des verrous dépend du système d’exploitation, en particulier en ce qui concerne si un processus attendra un verrou et pendant combien de temps.

Un verrou est un type de verrou qui peut être très rapidement acquis et libéré. Les verrous sont généralement utilisés pour empêcher plus d’un processus d’exécuter le même morceau de code à un moment donné. Chaque verrou est associé à une procédure de nettoyage qui sera appelée si un processus meurt en maintenant le verrou. Les verrous ont un niveau associé qui est utilisé pour éviter les blocages. Une fois qu’un processus acquiert un verrou à un certain niveau, il ne peut plus acquérir ensuite un verrou à un niveau égal ou inférieur à ce niveau (à moins qu’il ne l’acquiert maintenant).

2.Les verrous par rapport aux files d’attente

Les files d’attente sont un autre type de mécanisme de verrouillage utilisé dans Oracle.
Une file d’attente est un mécanisme plus sophistiqué qui permet à plusieurs processus simultanés d’avoir un degré variable de partage des ressources ” connues”. Tout objet pouvant être utilisé simultanément peut être protégé par des files d’attente. Un bon exemple est celui des serrures sur les tables. Nous autorisons différents niveaux de partage sur les tables, par exemple deux processus peuvent verrouiller une table en mode partage ou en mode mise à jour de partage, etc. Une différence est que la file d’attente est obtenue à l’aide d’un mécanisme de verrouillage spécifique au système d’exploitation. Une file d’attente permet à l’utilisateur de stocker une valeur dans le verrou, c’est-à-dire le mode dans lequel nous la demandons. Le gestionnaire de verrouillage du système d’exploitation garde une trace des ressources verrouillées. Si un processus ne peut pas obtenir le verrou car il est incompatible avec le mode demandé et que le verrou est demandé avec wait, le système d’exploitation place le processus demandeur dans une file d’attente qui est entretenue dans FIFO.

Une autre différence entre les loquets et les files d’attente est que dans les loquets, il n’y a pas de file d’attente ordonnée de serveurs comme dans les files d’attente. Les serveurs Latch peuvent utiliser des minuteries pour se réveiller et réessayer ou tourner (uniquement dans les multiprocesseurs). Étant donné que tous les serveurs réessayent simultanément (selon le planificateur), n’importe qui peut obtenir le loquet et le premier à essayer pourrait être le dernier à obtenir.

1. Quand devons-nous obtenir un loquet?

Un processus acquiert un verrou lorsqu’il travaille avec une structure dans le SGA (System Global Area). Il continue de maintenir le loquet pendant la période pendant laquelle il travaille avec la structure. Le verrou est lâché lorsque le processus est terminé avec la structure. Chaque verrou protège un ensemble de données différent, identifié par le nom du verrou.

Oracle utilise des instructions atomiques telles que “test and set” pour fonctionner sur des verrous. Les processus en attente d’exécuter une partie de code pour laquelle un verrou a déjà été obtenu par un autre processus attendront que le verrou soit relâché. Des exemples sont les verrous d’allocation de restauration, les verrous de copie, les verrous de contrôle d’archive, etc. L’idée de base est de bloquer l’accès simultané aux structures de données partagées. Puisque les instructions pour définir et libérer les verrous sont atomiques, le système d’exploitation garantit qu’un seul processus l’obtient. Comme ce n’est qu’une seule instruction, c’est assez rapide. Les loquets sont maintenus pendant de courtes périodes et fournissent un mécanisme de nettoyage au cas où un support mourrait anormalement en le maintenant. Ce nettoyage est effectué en utilisant les services de PMON.

1. Modes de demande de verrous?

La demande de verrouillage peut être effectuée en deux modes: “prêt à attendre” ou “pas d’attente”. Normalement, les verrous seront demandés en mode “prêt à attendre”. Une requête en mode “prêt à attendre”
boucle, attend et demande à nouveau jusqu’à ce que le verrou soit obtenu. En mode “sans attente”, le processus demande le verrou. Si l’un n’est pas disponible, au lieu d’attendre, un autre est demandé. Ce n’est que lorsque tout échoue que le processus du serveur doit attendre.

Des exemples de loquets “prêts à attendre” sont : loquets de cache de pool partagé et de bibliothèque
Un exemple de loquets “sans attente” est le loquet redo copy.

5. Qu’est-ce qui cause la contention du verrou ?Si un verrou requis est occupé, le processus qui le demande tourne, tente à nouveau et s’il n’est toujours pas disponible, tourne à nouveau. La boucle est répétée jusqu’à un nombre maximum de fois déterminé par le paramètre d’initialisation _SPIN_COUNT. Si après toute cette boucle, le verrou n’est toujours pas disponible, le processus doit céder le processeur et se mettre en veille. Est initialement dort pour une centiseconde. Ce temps est doublé à chaque sommeil ultérieur.

Cela provoque un ralentissement et entraîne une utilisation supplémentaire du processeur, jusqu’à ce qu’un verrou soit disponible. L’utilisation du processeur est une conséquence de la “rotation” du processus. “Rotation” signifie que le processus continue de rechercher la disponibilité du verrou après certains intervalles de temps, pendant lesquels il dort.

1. Comment identifier la contention pour les verrous internes?

Vues de dictionnaire de données pertinentes à interroger :

VLATCHLATCH
VHOLDERLATCHHOLDER
VNAMELATCHNAME

Chaque ligne de la table VLATCHLATCH contient des statistiques pour un type de latch différent. Les colonnes du tableau reflètent l’activité de différents types de requêtes de verrouillage. La distinction entre ces types de demandes est de savoir si le processus demandeur continue de demander un verrou s’il n’est pas disponible :

prêt à attendre Si le verrou demandé avec une demande prête à attendre
n’est pas disponible, le processus demandeur
attend un court moment et demande à nouveau le verrou.
Le processus continue d’attendre et de demander jusqu’à ce que
le verrou soit disponible.

pas d’attente Si le verrou demandé avec une demande immédiate n’est
pas disponible, le processus de demande n’attend pas
, mais continue le traitement.

V informationLATCHNAME informations sur la clé :

OBTIENT le nombre de requêtes prêtes à attendre réussies pour
un verrou.

MANQUE Le nombre de fois où une demande initiale de prêt à attendre
a échoué.

SLEEPS Nombre de fois qu’un processus a attendu un latch demandé
après une demande initiale de wiling-to-wait.

IMMEDIATE_GETS Nombre de requêtes immédiates réussies pour chaque verrou.

IMMEDIATE_MISSES Nombre de demandes immédiates infructueuses pour chaque verrou.

Calcul du taux de réussite des verrous

Pour obtenir le taux de réussite des verrous, appliquez la formule suivante :

Ratio de réussite “prêt à attendre” =(OBTIENT-RATE) / OBTIENT
Ratio de réussite “sans attente” =(IMMEDIATE_GETS-IMMEDIATE_MISSES) / IMMEDIATE_GETS

Ce nombre doit être proche de 1. Sinon, syntonisez en fonction du nom du verrou

1. Scripts SQL utiles pour obtenir des informations sur le verrou

/*
** Afficher les statistiques de verrouillage à l’échelle du système.
* /
nom de la colonne format A32 entête tronquée “NOM DU VERROU”
entête pid de la colonne “TITULAIRE PID”
sélectionner c.name , a.addr, a.gets, a.misses, a.sleeps,
a.immediate_gets, a.immediate_misses, b. pid
de vlatchlatch a, vholderlatchholder b, vnamelatchname c
où a.addr = b.laddr(+)
et a.latch #= c.latch #
ordre par a.latch#;

/*
** Étant donné une adresse de verrouillage, découvrez le nom du verrou.
*/
nom de la colonne format a64 titre ‘Nom’
sélectionner a.name de vnamelatchname a, v blatch b
où b.addr =’&addr’
et b.latch #= a.latch#;

/*
** Afficher les statistiques du verrou par nom du verrou.
*/
nom de la colonne format a32 titre ‘NOM DU VERROU’
titre pid de la colonne ‘TITULAIRE PID’
sélectionner c.name , a.addr, a.gets, a.misses, a.sleeps,
a.immediate_gets, a.immediate_misses, b. pid
de vlatchlatch a, vholderlatchholder b, vnamelatchname c
où a.addr = b.laddr(+) et a.latch #= c.latch #
et c.name comme ‘&latch_name%’ ordre par un .latch#;

1. Liste de tous les loquets

Les versions d’Oracle peuvent différer dans le numéro de loquet attribué aux loquets existants.
La requête suivante vous aidera à identifier tous les verrous et le numéro attribué.

format du nom de la colonne a40 en-tête ‘NOM DU VERROU’
sélectionnez # du verrou, nom de vnamenom du verrou;

1. Liste des verrous les plus préoccupants pour un DBA

• VERROUS DE CACHE TAMPON: Il existe deux verrous principaux qui protègent les blocs de données dans le cache tampon. La contention pour ces deux verrous est généralement observée lorsqu’une base de données a des taux d’E / S élevés. Nous pouvons réduire les conflits pour ces verrous et les régler en ajustant certaines initialisations.paramètres ora.

Loquet de chaînes de tampons de cache :

Ce loquet est acquis chaque fois qu’un bloc du cache de tampon est accessible (épinglé).

La réduction de la contention pour le verrou des chaînes de tampon de cache nécessite généralement une réduction des débits d’E / S logiques en ajustant et en minimisant les exigences d’E / S du SQL impliqué. Des taux d’E/S élevés peuvent être le signe d’un bloc chaud (c’est-à-dire un bloc très accessible).

Voir Note 163424.1 Comment Identifier un Bloc Chaud Dans La Base de Données pour identifier correctement ce problème.

Loquet de chaîne LRU des tampons de cache:

Le loquet de chaîne lru du tampon de cache est acquis afin d’introduire un nouveau bloc dans le cache de tampon et lors de l’écriture d’un tampon sur le disque, en particulier lorsque vous essayez d’analyser la chaîne LRU (la moins récemment utilisée) contenant tous les blocs sales dans le cache de tampon.

Il est possible de réduire la contention pour le verrou de chaîne lru du tampon de cache en augmentant la taille du cache de tampon et en réduisant ainsi la vitesse à laquelle de nouveaux blocs sont introduits dans le cache de tampon. Deux paramètres dictent la taille du cache tampon, DB_BLOCK_SIZE et DB_BLOCK_BUFFERS. En réalité, seuls les DB_BLOCK_BUFFERS peuvent être modifiés sans recréer la base de données. Attention, lors du réglage du pool de tampons, évitez d’utiliser des tampons supplémentaires qui contribuent peu ou rien au taux de succès du cache. Une erreur courante est de continuer à augmenter la valeur de DB_BLOCK_BUFFERS. De telles augmentations n’ont aucun effet si vous effectuez des analyses de table complètes ou d’autres opérations qui n’utilisent pas le cache tampon. Plusieurs pools de mémoire tampon peuvent aider à réduire les conflits sur ce verrou.Vous pouvez créer des verrous de chaîne lru de tampon de cache supplémentaires en ajustant le paramètre de configuration DB_BLOCK_LRU_LATCHES. Vous pouvez réduire la charge sur les verrous de la chaîne de tampon de cache en augmentant le paramètre de configuration _DB_BLOCK_HASH_BUCKETS

• VERROUS de tampon REDOLOG : Il existe deux verrous de tampon Redo, le verrou d’allocation redo et le verrou de copie redo. Le verrou d’allocation redo doit être acquis afin d’allouer de l’espace dans le tampon. Si l’entrée de journal de rétablissement à effectuer est supérieure au paramètre de configuration LOG_SMALL_ENTRY_MAX_SIZE, la session qui acquiert le verrou d’allocation de rétablissement peut copier l’entrée dans le tampon de rétablissement immédiatement tout en maintenant le verrou d’allocation. Si l’entrée de journal est supérieure à LOG_SMALL_ENTRY_MAX_SIZE, alors la session libérera le verrou d’allocation de rétablissement et acquerra le verrou de copie de rétablissement afin de copier l’entrée. Il n’y a qu’un seul verrou d’allocation redo, mais il peut y avoir jusqu’à des verrous d’allocation LOG_SIMULTANEOUS_COPIES.

Verrou d’allocation de reprise :

Ce verrou contrôle l’allocation d’espace pour les entrées de reprise dans le tampon de journal de reprise. Il y a un verrou d’allocation redo par instance.

La contention pour ce verrou dans Oracle7 peut être réduite en diminuant la valeur de LOG_SMALL_ENTRY_MAX_SIZE sur les systèmes multi-cpu pour forcer l’utilisation du verrou de copie de restauration
. Dans Oracle8i, ce paramètre est obsolète, vous devez donc envisager d’augmenter la taille du tampon LOG_BUFFER ou de réduire la charge du tampon de journal en utilisant des fonctionnalités de NOLOGGING lorsque cela est possible.

Redo copy latch:

Ce verrou est utilisé pour écrire des enregistrements redo dans le tampon redolog. Ce verrou est attendu sur les systèmes mono et multi-cpu.

Sur les systèmes multi-cpu, la contention peut être réduite en augmentant la valeur de LOG_SIMULTANEOUS_COPIES (cachée dans Oracle8i) et / ou en augmentant LOG_ENTRY_PREBUILD_THRESHOLD (non documentée dans Oracle7).

• CACHE DE BIBLIOTHÈQUE

Loquet de cache de bibliothèque :

Les loquets de cache de bibliothèque protègent les instructions SQL mises en cache et les définitions d’objets contenues dans le cache de bibliothèque dans le pool partagé. Le verrou de cache de bibliothèque doit être acquis afin d’ajouter une nouvelle instruction au cache de bibliothèque. Lors d’une analyse, Oracle recherche dans le cache de la bibliothèque une instruction correspondante. Si l’un d’eux n’est pas trouvé, Oracle analysera l’instruction SQL, obtiendra le verrou de cache de la bibliothèque et insérera le nouveau SQL.

La première ressource pour réduire les conflits sur ce verrou est de s’assurer que l’application réutilise autant que possible la représentation d’instructions SQL. Utilisez des variables de liaison dans la mesure du possible dans l’application. Les échecs sur ce verrou peuvent également être un signe que l’application analyse SQL à un débit élevé et peut souffrir de trop de surcharge du processeur d’analyse.Si l’application est déjà réglée, la SHARED_POOL_SIZE peut être augmentée. Sachez que si l’application n’utilise pas le cache de la bibliothèque de manière appropriée, la contention peut être pire avec une structure plus grande à gérer.

Le paramètre _KGL_LATCH_COUNT contrôle le nombre de verrous de cache de bibliothèque. La valeur par défaut doit être adéquate, mais si le conflit pour le verrou de cache de la bibliothèque ne peut pas être résolu, il peut être conseillé d’augmenter cette valeur. La valeur par défaut de _KGL_LATCH_COUNT est le nombre premier suivant après CPU_COUNT. Cette valeur ne peut pas dépasser 66 (Voir :).

Loquet de broche de cache de bibliothèque :

Le loquet de broche de cache de bibliothèque doit être acquis lorsqu’une instruction dans le cache de bibliothèque est réexécutée. Les échecs sur ce verrou se produisent lorsqu’il y a des taux d’exécution SQL très élevés.

Il y a peu de choses qui peuvent être faites pour réduire la charge sur le verrou de broche du cache de la bibliothèque, bien qu’en utilisant des synonymes privés plutôt que publics ou des références d’objets directes telles que OWNER.LA TABLE peut aider.

• LOQUETS LIÉS AU POOL PARTAGÉ

Loquet de pool partagé :

Alors que le loquet de cache de bibliothèque protège les opérations dans le cache de bibliothèque, le loquet de pool partagé est utilisé pour protéger les opérations critiques lors de l’allocation et de la libération de mémoire dans le pool partagé.
Si une application utilise du SQL littéral (non partagé), cela peut limiter considérablement l’évolutivité et le débit. Le coût de l’analyse d’une nouvelle instruction SQL est coûteux à la fois en termes de besoins en CPU et en nombre de fois où le cache de bibliothèque et les verrous de pool partagé peuvent devoir être acquis et libérés. Avant Oracle9, il n’y avait qu’un seul verrou de ce type sur l’ensemble de la base de données pour protéger l’allocation de mémoire dans le cache de la bibliothèque. Dans Oracle9, plusieurs enfants ont été introduits pour soulager les conflits sur cette ressource.

Les moyens de réduire le verrou de pool partagé sont d’éviter les analyses difficiles lorsque cela est possible, d’analyser une fois, d’en exécuter plusieurs. L’élimination du SQL littéral est également utile pour éviter le verrou de pool partagé. La taille du shared_pool et l’utilisation de MTS (option serveur partagé) influencent également grandement le verrou du pool partagé. La note 62143.1 explique comment identifier et corriger les problèmes avec le pool partagé et le verrou de pool partagé.

Loquet d’objets de cache de ligne :

Ce loquet entre en jeu lorsque les processus utilisateur tentent d’accéder aux valeurs du dictionnaire de données mises en cache.

Il n’est pas courant d’avoir une contention dans ce verrou et la seule façon de réduire la contention pour ce verrou est d’augmenter la taille du pool partagé (SHARED_POOL_SIZE).

1. Tuning _SPIN_COUNT(_LATCH_SPIN_COUNT dans Oracle7)

SPIN_COUNT contrôle le nombre de fois où le processus tentera à nouveau d’obtenir le verrou avant de reculer et de se mettre en veille. Cela signifie essentiellement que le processus est dans une boucle CPU serrée essayant continuellement d’obtenir le verrou pour les tentatives de SPIN_COUNT. Sur un seul système de PROCESSEUR, si un processus Oracle tente d’acquérir un verrou mais qu’il est détenu par quelqu’un d’autre, le processus libère le processeur et se met en veille pendant une courte période avant de réessayer. Cependant, sur un système multiprocesseur (SMP), il est possible que le processus qui maintient le verrou s’exécute sur l’un des autres PROCESSEURS et libère donc potentiellement le verrou dans les instructions suivantes (les verrous ne sont généralement maintenus que pendant de très courtes périodes).

Les performances peuvent être ajustées en modifiant la valeur de SPIN_COUNT. Si une valeur élevée est utilisée, le verrou sera atteint plus tôt que si vous utilisez une valeur basse. Cependant, vous pouvez utiliser plus de temps CPU pour obtenir le loquet si vous utilisez une valeur élevée pour SPIN_COUNT. Vous pouvez diminuer cette probabilité de sommeil de session en augmentant la valeur des paramètres de configuration _LATCH_SPIN_COUNT ou SPIN_COUNT. Ce paramètre contrôle le nombre de tentatives que la session fera pour obtenir le verrou avant de dormir. Tourner sur le loquet consomme du PROCESSEUR, donc si vous augmentez ce paramètre, vous pouvez voir une augmentation de l’utilisation globale du PROCESSEUR de vos systèmes. Si votre ordinateur est proche de 100% du processeur et que votre application est axée sur le débit plutôt que sur le temps de réponse, vous pouvez envisager de réduire le nombre de SPIN afin de conserver le processeur. Le réglage de SPIN_COUNT est un essai et une erreur. En général, augmentez SPIN_COUNT uniquement s’il y a suffisamment de ressources CPU libres disponibles sur le système, et diminuez-le uniquement s’il n’y a pas de capacité CPU de rechange.