Voici quelques-uns des événements d'attente Oracle courants que tout le monde devrait connaître.
Événements d'attente
Vous pouvez trouver quelle session d'événement l'attend en suivant la requête
select event from V$session_wait where sid=&1
J'essaie d'expliquer quelques événements d'attente Oracle courants, leurs causes et leurs résolutions
mettre en file d'attente
Le processus attend une mise en file d'attente oracle (un verrou que vous pouvez voir dans v$lock). Cela se produit généralement lorsqu'un utilisateur tente de mettre à jour une ligne dans une table en cours de mise à jour par un autre utilisateur. Les bloqueurs peuvent être découverts en utilisant la requête suivante
select * from dba_waiters
broche de cache de bibliothèque
Le processus souhaite épingler un objet en mémoire dans le cache de la bibliothèque pour examen, en s'assurant qu'aucun autre processus ne peut mettre à jour l'objet en même temps. Cela se produit lorsque vous compilez ou analysez un objet PL/SQL ou une vue. Évitez de compiler l'objet PL/SQL ou la vue oracle à un temps d'utilisation élevé pour éviter cet événement d'attente
verrouillage du chargement du cache de la bibliothèque
Le processus attend l'opportunité de charger un objet ou une partie d'un objet dans le cache de la bibliothèque. (Un seul processus peut charger un objet ou un morceau d'objet à la fois.)
sans loquet
Le processus attend un verrou détenu par un autre processus. (Cet événement d'attente ne s'applique pas aux processus qui tournent en attendant un verrou ; lorsqu'un processus tourne, il n'attend pas.). Les verrous sont des dispositifs de sérialisation légers utilisés pour coordonner l'accès multi-utilisateur aux structures de données partagées, aux objets, et fichiers.
Les verrous sont des verrous conçus pour être maintenus pendant des périodes de temps extrêmement courtes, par exemple, le temps nécessaire pour modifier une structure de données en mémoire. Ils sont utilisés pour protéger certaines structures de mémoire, telles que le cache de tampon de bloc de base de données ou le cache de bibliothèque dans le pool partagé.
Les verrous Oracle sont généralement demandés en interne dans un mode "prêt à attendre". Cela signifie que si le verrou n'est pas disponible, la session demandeuse dormira pendant une courte période de temps et réessayera l'opération plus tard. D'autres verrous peuvent être demandés dans un mode "immédiat", qui est similaire dans son concept à un SELECT FOR UPDATE NO-WAIT, ce qui signifie que le processus ira faire autre chose, comme essayer de saisir un verrou frère équivalent qui peut être libre, plutôt que de s'asseoir et d'attendre que ce loquet soit disponible. Étant donné que de nombreuses requêtes peuvent attendre un verrouillage en même temps, certains processus peuvent attendre plus longtemps que d'autres.
Les verrous sont attribués plutôt au hasard, en fonction de la chance du tirage, si vous voulez. Quelle que soit la session qui demande un verrou juste après sa libération, elle l'obtiendra. Il n'y a pas de file d'attente de serveurs de verrouillage, juste une foule de serveurs qui réessayent constamment.
le tampon occupé attend
Le processus veut accéder à un bloc de données qui n'est actuellement pas en mémoire, mais un autre processus a déjà émis une requête d'E/S pour lire le bloc en mémoire. (Le processus attend que l'autre processus finisse de mettre le bloc en mémoire.). Les blocs actifs peuvent être trouvés en utilisant la vue V$BH
lecture dispersée du fichier db
Le processus a émis une demande d'E/S pour lire une série de blocs contigus à partir d'un fichier de données dans le cache tampon et attend la fin de l'opération. Cela se produit généralement lors d'une analyse complète de la table ou de l'index complet.
Nous devons vérifier si la requête doit utiliser l'analyse complète de la table. Assurez-vous que les statistiques de l'optimiseur Oracle sont à jour. Utilisez l'élagage de partition pour réduire le nombre de blocs visités
Si une requête qui fonctionne correctement depuis un certain temps horloge soudainement beaucoup de temps sur l'événement de lecture dispersée du fichier db et qu'il n'y a pas eu de changement de code, vous voudrez peut-être vérifier si un ou plusieurs index ont été supprimés ou devenir inutilisable.
lecture séquentielle du fichier db
Le processus a émis une demande d'E/S pour lire un bloc d'un fichier de données dans le cache tampon et attend la fin de l'opération. Cela se produit généralement lors d'une recherche d'index ou d'une extraction à partir d'une table oracle par ROWID lorsque le bloc de données requis n'est pas déjà en mémoire. Ne vous laissez pas induire en erreur par le nom déroutant de cet événement d'attente !
Nous devrions vérifier si les bons index sont utilisés. Un mauvais index peut rendre la requête moins performante. Assurez-vous que les statistiques de l'optimiseur sont à jour.
lecture parallèle du fichier db
Le processus a émis plusieurs requêtes d'E/S en parallèle pour lire des blocs de fichiers de données dans la mémoire, et attend que toutes les requêtes se terminent. La documentation indique que cet événement d'attente se produit uniquement pendant la récupération, mais en fait, il se produit également pendant l'activité normale lorsqu'un processus regroupe de nombreuses demandes d'E/S à bloc unique et les émet en parallèle. (Malgré son nom, vous ne verrez pas cet événement d'attente lors d'une requête parallèle ou d'un DML parallèle. Dans ces cas, les événements d'attente avec PX dans leurs noms se produisent à la place.)
écriture parallèle de fichier db
Le processus, généralement DBWR, a émis plusieurs requêtes d'E/S en parallèle pour écrire des blocs modifiés du cache de tampon sur le disque, et attend que toutes les requêtes se terminent.
lecture directe du chemin, écriture directe du chemin
Le processus a émis des requêtes d'E/S asynchrones qui contournent le cache de tampon et attend qu'elles se terminent. Ces événements d'attente impliquent généralement des segments de tri.
Les instructions SQL avec des fonctions qui nécessitent des tris, telles que ORDER BY, GROUP BY, UNION, DISTINCT et ROLLUP, écrivent des exécutions de tri dans l'espace de table temporaire lorsque la taille d'entrée est supérieure à la zone de travail dans PGA
Assurez-vous que les statistiques de l'optimiseur correspondent aux données et que la requête utilise la bonne table de pilotage. Vérifiez si les colonnes de l'index composite peuvent être réorganisées pour correspondre à la clause ORDER BY afin d'éviter complètement le tri.
Assurez-vous que la valeur appropriée PGA_AGGREGATE_TARGET est définie. Si possible, utilisez UNION ALL au lieu de UNION.
Loquet de piscine partagé
Le verrou 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é. Les conflits concernant les verrous du pool partagé et du cache de la bibliothèque sont principalement dus à une analyse intensive intense. Une analyse matérielle s'applique aux nouveaux curseurs et aux curseurs qui ont expiré et doivent être réexécutés
Le coût de l'analyse d'une nouvelle instruction SQL est élevé à la fois en termes d'exigences de processeur et de nombre de fois que le cache de la bibliothèque et le pool partagé il peut être nécessaire d'acquérir et de libérer des loquets.
L'élimination du SQL littéral est également utile pour éviter le verrouillage du pool partagé
contrôler la lecture séquentielle du fichier
Le processus attend que des blocs soient lus à partir d'un fichier de contrôle. Cela se produit généralement
- faire une sauvegarde des fichiers de contrôle
- partage d'informations (entre instances) à partir du fichier de contrôle
- lire d'autres blocs depuis les fichiers de contrôle
- lire le bloc d'en-tête
S'il s'agit d'un événement d'attente majeur, cela signifie que l'emplacement du fichier de contrôle doit être remplacé par un emplacement de disque plus rapide
contrôler l'écriture parallèle du fichier
Le processus a émis plusieurs requêtes d'E/S en parallèle pour écrire des blocs dans tous les fichiers de contrôle et attend la fin de toutes les écritures.
espace tampon de journal
Le processus attend que de l'espace se libère dans la mémoire tampon du journal (l'espace devient disponible uniquement après que LGWR a écrit le contenu actuel de la mémoire tampon du journal sur le disque.) Cela se produit généralement lorsque les applications génèrent un rétablissement plus rapidement que LGWR ne peut l'écrire sur disque.
Cela peut également se produire si les E/S sur le disque où se trouvent les journaux redo sont lentes
Il ne devrait pas y avoir d'attente d'espace de tampon de journal en tant que tel dans la base de données. Envisagez d'agrandir le tampon de journal s'il est petit ou envisagez de déplacer les fichiers journaux vers des disques plus rapides tels que des disques entrelacés.
Select event, total_waits, total_timeouts, time_waited, average_wait
from v$system_event
where event = 'log buffer space';
Select sid, event, seconds_in_wait, state
from v$session_wait
where event = 'log buffer space';
Select name, value
from v$sysstat
where name in ('redo log space requests');
Le pct_buff_alloc_retries doit être nul ou inférieur à 0,01 (<1 %). S'il est supérieur, envisagez d'agrandir le tampon du journal. S'il est supérieur, envisagez de déplacer les fichiers journaux vers des disques plus rapides tels que des disques entrelacés.
Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries, trunc(v1.value/v2.value,4) as pct_buff_alloc_retries from v$sysstat v1, v$sysstat v2 where v1.name = 'redo buffer allocation retries' and v2.name = 'redo entries';
lecture séquentielle du fichier journal
Le processus attend que les blocs soient lus du journal de rétablissement en ligne dans la mémoire. Cela se produit principalement au démarrage de l'instance et lorsque les archives du processus ARCH ont rempli les journaux redo en ligne.
écriture parallèle de fichier journal
Le processus attend que les blocs soient écrits dans tous les membres du journal de rétablissement en ligne d'un groupe. LGWR est généralement le seul processus à voir cet événement d'attente. Il attendra que tous les blocs aient été écrits pour tous les membres.
synchronisation des fichiers journaux
Le processus attend que LGWR finisse de vider la mémoire tampon du journal sur le disque. Cela se produit lorsqu'un utilisateur valide une transaction. (Une transaction n'est pas considérée comme validée tant que toutes les opérations de restauration pour récupérer la transaction n'ont pas été écrites avec succès sur le disque.)
Un processus LGWR lent peut introduire des attentes de synchronisation des fichiers journaux, ce qui oblige l'utilisateur à subir des temps d'attente lors de la validation ou de la restauration. Les événements d'écriture parallèle du fichier journal et d'attente de synchronisation du fichier journal sont interdépendants et doivent être traités simultanément.
Il faut essayer d'allouer les redo logs sur un disque haute performance (Solid state disk). Nous devrions également essayer de réduire la charge sur LGWR en réduisant les validations dans les applications.
La sauvegarde manuelle à chaud peut également introduire du stress dans le système en générant beaucoup de tâches à refaire, évitez donc cela pendant les heures de pointe
Parfois LGWR manque de ressources CPU. Si le serveur est très occupé, LGWR peut également manquer de CPU. Cela entraînera une réponse plus lente de LGWR, augmentant les attentes de « synchronisation des fichiers journaux ». Après tout, ces appels système et appels d'E/S doivent utiliser le CPU. Dans ce cas, la "synchronisation des fichiers journaux" est un symptôme secondaire et la résolution de la cause première de l'utilisation élevée du processeur réduira les attentes de "synchronisation des fichiers journaux".
En raison de problèmes de manque de mémoire, LGWR peut également être paginé. Cela peut également entraîner une réponse plus lente de LGWR.
annuler l'extension de segment
La session attend qu'un segment d'annulation soit étendu ou réduit.
écrire les attentes complètes
La session attend qu'un tampon demandé soit écrit sur le disque ; le tampon ne peut pas être utilisé pendant son écriture.
Latch :chaînes de tampon de cache
Les verrous de chaînes de tampons de cache sont utilisés pour protéger une liste de tampons dans le cache de tampons. Ces verrous sont utilisés lors de la recherche, de l'ajout ou de la suppression d'un tampon du cache de tampons.
Les blocs du cache de tampons sont placés sur des listes chaînées (chaînes de tampons de cache) suspendues à une table de hachage. La chaîne de hachage sur laquelle un bloc est placé est basée sur le DBA et la CLASS du bloc. Chaque chaîne de hachage est protégée par un seul verrou enfant. Les processus doivent obtenir le verrou approprié pour leur permettre d'analyser une chaîne de hachage à la recherche d'un tampon afin que la liste chaînée ne change pas en dessous d'eux.
Un conflit sur ce loquet signifie généralement qu'il y a un bloc qui est en grand conflit (connu sous le nom de bloc chaud).
Pour identifier la chaîne de tampons fortement sollicitée, et donc le bloc en concurrence, consultez les statistiques de verrouillage des verrous des chaînes de tampons de cache à l'aide de la vue V$LATCH_CHILDREN. S'il existe un verrou enfant de chaînes de tampons de cache spécifique qui a beaucoup plus de GETS, MISSES et SLEEPS par rapport aux autres verrous enfants, il s'agit alors du verrou enfant.
Ce verrou a une adresse mémoire, identifiée par la colonne ADDR.
SELECT addr, sleeps FROM v$latch_children c, v$latchname n WHERE n.name='cache buffers chains' and c.latch#=n.latch# and sleeps > 100 ORDER BY sleeps /
Utilisez la valeur de la colonne ADDR jointe à la vue V$BH pour identifier les blocs protégés par ce verrou. Par exemple, étant donné l'adresse (V$LATCH_CHILDREN.ADDR) d'un verrou fortement en conflit, cela interroge les numéros de fichier et de bloc :
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH est un nombre de contacts pour le tampon. Une valeur élevée pour X$BH.TCH indique un bloc chaud.
De nombreux blocs sont protégés par chaque loquet. L'un de ces tampons sera probablement le bloc chaud. Tout bloc avec une valeur TCH élevée est un bloc chaud potentiel. Effectuez cette requête plusieurs fois et identifiez le bloc qui apparaît systématiquement dans la sortie.
Après avoir identifié le bloc actif, interrogez DBA_EXTENTS en utilisant le numéro de fichier et le numéro de bloc pour identifier le segment.
Informations importantes sur l'événement d'attente
La vue v$session_wait affiche des informations sur les événements d'attente pour lesquels les sessions actives sont actuellement en attente. Ce qui suit est la description de cette vue, et elle contient des colonnes très utiles, en particulier les références P1 et P2 aux objets associés aux événements d'attente.
desc v$session_wait Name Null? Type --------------------------- -------- ------------ SID NUMBER SEQ# NUMBER EVENT VARCHAR2(64) P1TEXT VARCHAR2(64) P1 NUMBER P1RAW RAW(4) P2TEXT VARCHAR2(64) P2 NUMBER P2RAW RAW(4) P3TEXT VARCHAR2(64) P3 NUMBER P3RAW RAW(4) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) WAIT_TIME NUMBER SECONDS_IN_WAIT NUMBER STATE VARCHAR2(19)
À l'aide de v$session_wait, il est facile d'interpréter chaque paramètre d'événement d'attente à l'aide des colonnes de texte descriptif correspondantes pour ce paramètre. En outre, des colonnes de classe d'attente ont été ajoutées afin que divers événements d'attente puissent être regroupés dans les domaines de traitement connexes tels que le réseau, l'application, l'inactivité, la concurrence, etc.
Ces colonnes ont également été ajoutées à la table v$session à partir de 10g . Vous pouvez donc simplement utiliser v$session pour trouver tous les détails
Chaque événement d'attente contient d'autres paramètres qui fournissent des informations supplémentaires sur l'événement.
Comment trouver les informations sur l'événement d'attente et son paramètre
The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of col name format a25; col p1 format a10; col p2 format a10; col p3 format a10; SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3 FROM V$EVENT_NAME WHERE NAME = '&event_name';
Disons par exemple que nous avons pris
Les valeurs d'entrée du nom de l'événement :lecture dispersée du fichier db
Valeur d'origine 3 :WHERE NAME ='&nom_événement A'
La nouvelle valeur 3 :WHERE NAME =« lecture dispersée du fichier db »
Le nom P1 P2 P3
fichier db fichier de lecture dispersé # bloc # blocs
file # :numéro du fichier de données
Block # :numéro du bloc de départ
blocks :pour lire le numéro du bloc de données
Voyons maintenant comment les informations ci-dessus peuvent nous aider à capturer diverses choses
Supposons qu'une session particulière attende un événement d'attente de tampon occupé, l'objet de base de données à l'origine de cet événement d'attente peut facilement être déterminé :
select username, event, p1, p2 from v$session_wait where sid = 4563;
Le résultat de cette requête pour une session particulière avec le SID 4563 pourrait ressembler à ceci :
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Les colonnes P1 et P2 permettent au DBA de déterminer les numéros de fichier et de bloc qui ont provoqué cet événement d'attente. La requête ci-dessous récupère le nom de l'objet propriétaire du bloc de données 155, la valeur de P2 ci-dessus :
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
La capacité d'analyser et de corriger les événements d'attente d'Oracle Database est essentielle dans tout projet de réglage. La majorité de l'activité dans une base de données implique la lecture de données. Ce type de réglage peut donc avoir un impact positif considérable sur les performances.
Remarque :lors de l'analyse des attentes, il est essentiel de se rappeler que toutes les bases de données Oracle subissent des événements d'attente et que la présence d'attentes n'indique pas toujours un problème. En fait, toutes les bases de données bien réglées ont un goulot d'étranglement.
nous pouvons également utiliser l'événement 10046 pour suivre l'événement d'attente de la session
Lit également
Documentation Oracle
v$active_session_history
Expliquer le plan dans Oracle
