Estos son algunos de los eventos de espera comunes de Oracle que todos deberían saber.
Eventos de espera
Puede encontrar qué sesión de evento lo está esperando siguiendo la consulta
select event from V$session_wait where sid=&1
Estoy tratando de explicar algunos eventos comunes de espera de Oracle, sus causas y resoluciones
poner en cola
El proceso está esperando una cola de Oracle (un bloqueo que puede ver en v$lock). Esto suele ocurrir cuando un usuario intenta actualizar una fila en una tabla que otro usuario está actualizando actualmente. Los bloqueadores se pueden encontrar utilizando la siguiente consulta
select * from dba_waiters
pin de caché de biblioteca
El proceso desea anclar un objeto en la memoria caché de la biblioteca para examinarlo, asegurándose de que ningún otro proceso pueda actualizar el objeto al mismo tiempo. Esto sucede cuando está compilando o analizando un objeto PL/SQL o una vista. Evite compilar el objeto PL/SQL o la vista de Oracle en momentos de alto uso para evitar este evento de espera
bloqueo de carga de caché de biblioteca
El proceso está esperando la oportunidad de cargar un objeto o una parte de un objeto en la memoria caché de la biblioteca. (Solo un proceso puede cargar un objeto o una parte de un objeto a la vez).
sin pestillo
El proceso está esperando un latch sostenido por otro proceso. (Este evento de espera no se aplica a los procesos que giran mientras esperan un latch; cuando un proceso gira, no está esperando). Los latches son dispositivos de serialización livianos que se utilizan para coordinar el acceso de múltiples usuarios a estructuras de datos compartidas, objetos, y archivos.
Los latches son bloqueos diseñados para mantenerse durante períodos de tiempo extremadamente cortos, por ejemplo, el tiempo que lleva modificar una estructura de datos en memoria. Se utilizan para proteger ciertas estructuras de memoria, como la memoria caché del búfer de bloque de la base de datos o la memoria caché de la biblioteca en el grupo compartido.
Oracle Latches generalmente se solicita internamente en un modo "dispuesto a esperar". Esto significa que si el pestillo no está disponible, la sesión solicitante se suspenderá durante un breve período de tiempo y volverá a intentar la operación más tarde. Se pueden solicitar otros pestillos en un modo 'inmediato', que es similar en concepto a SELECCIONAR PARA ACTUALIZAR SIN ESPERA, lo que significa que el proceso irá a hacer otra cosa, como intentar tomar un pestillo hermano equivalente que puede estar libre, en lugar de sentarse y esperar a que este pestillo esté disponible. Dado que muchas solicitudes pueden estar esperando un bloqueo al mismo tiempo, es posible que algunos procesos esperen más que otros.
Los pestillos se asignan de forma bastante aleatoria, según la suerte del sorteo, por así decirlo. Cualquiera que sea la sesión que solicite un pestillo justo después de que se haya liberado, lo obtendrá. No hay una fila de camareros con pestillo, solo una multitud de camareros que constantemente vuelven a intentarlo.
espera de búfer ocupado
El proceso desea acceder a un bloque de datos que actualmente no está en la memoria, pero otro proceso ya emitió una solicitud de E/S para leer el bloque en la memoria. (El proceso está esperando que el otro proceso termine de traer el bloque a la memoria). Los bloques calientes se pueden encontrar usando la vista V$BH
archivo db lectura dispersa
El proceso ha emitido una solicitud de E/S para leer una serie de bloques contiguos de un archivo de datos en la memoria caché del búfer y está esperando que se complete la operación. Esto suele ocurrir durante un análisis completo de la tabla o un análisis completo del índice.
Deberíamos verificar si la consulta debe usar el escaneo completo de la tabla. Asegúrese de que las estadísticas del optimizador de Oracle estén actualizadas. Utilice la eliminación de particiones para reducir la cantidad de bloques visitados
Si una consulta que ha estado funcionando bien durante un tiempo de repente registra mucho tiempo en el evento de lectura dispersa del archivo db y no ha habido un cambio de código, es posible que desee verificar si uno o más índices se han eliminado o quedar inutilizable.
lectura secuencial del archivo db
El proceso ha emitido una solicitud de E/S para leer un bloque de un archivo de datos en el caché del búfer y está esperando que se complete la operación. Esto suele ocurrir durante una búsqueda de índice o una extracción de una tabla de Oracle por ROWID cuando el bloque de datos requerido aún no está en la memoria. ¡No se deje engañar por el confuso nombre de este evento de espera!
Deberíamos comprobar si se están utilizando los índices correctos. Un índice incorrecto puede hacer que la consulta funcione mal. Asegúrese de que las estadísticas del optimizador estén actualizadas.
lectura paralela del archivo db
El proceso ha emitido varias solicitudes de E/S en paralelo para leer bloques de archivos de datos en la memoria y está esperando que se completen todas las solicitudes. La documentación dice que este evento de espera ocurre solo durante la recuperación, pero de hecho también ocurre durante la actividad regular cuando un proceso procesa por lotes muchas solicitudes de E/S de un solo bloque y las emite en paralelo. (A pesar del nombre, no verá este evento de espera durante la consulta paralela o el DML paralelo. En esos casos, en su lugar, ocurren eventos de espera con PX en sus nombres).
escritura paralela de archivo db
El proceso, generalmente DBWR, ha emitido varias solicitudes de E/S en paralelo para escribir bloques sucios desde la memoria caché del búfer al disco y está esperando que se completen todas las solicitudes.
lectura de ruta directa, escritura de ruta directa
El proceso ha emitido solicitudes de E/S asincrónicas que omiten la memoria caché del búfer y está esperando que se completen. Estos eventos de espera generalmente involucran segmentos de clasificación.
Las instrucciones SQL con funciones que requieren ordenaciones, como ORDER BY, GROUP BY, UNION, DISTINCT y ROLLUP, escriben ejecuciones de ordenación en el espacio de tabla temporal cuando el tamaño de entrada es mayor que el área de trabajo en PGA
Asegúrese de que las estadísticas del optimizador estén actualizadas y que la consulta utilice la tabla de control correcta. Verifique si las columnas del índice compuesto se pueden reorganizar para que coincidan con la cláusula ORDER BY para evitar ordenar por completo.
Asegúrese de establecer el valor adecuado PGA_AGGREGATE_TARGET. Si es posible, use UNION ALL en lugar de UNION.
Cierre de piscina compartida
El pestillo del grupo compartido se usa para proteger las operaciones críticas al asignar y liberar memoria en el grupo compartido. Las disputas por los bloqueos de caché de la biblioteca y el grupo compartido se deben principalmente a un análisis intenso y riguroso. Un análisis completo se aplica a los cursores nuevos y a los cursores que están obsoletos y se deben volver a ejecutar.
El costo de analizar una nueva instrucción SQL es elevado tanto en términos de requisitos de CPU como en la cantidad de veces que la biblioteca almacena en caché y el grupo compartido. es posible que sea necesario adquirir y soltar los pestillos.
La eliminación de SQL literal también es útil para evitar el bloqueo del grupo compartido
control de lectura secuencial de archivos
El proceso está esperando que se lean los bloques de un archivo de control. Esto sucede generalmente
- hacer una copia de seguridad de los archivos de control
- compartir información (entre instancias) del archivo de control
- leyendo otros bloques de los archivos de control
- leyendo el bloque de encabezado
Si este es un evento de espera importante, significa que la ubicación del archivo de control debe cambiarse a una ubicación de disco más rápida
archivo de control escritura paralela
El proceso ha emitido varias solicitudes de E/S en paralelo para escribir bloques en todos los archivos de control y está esperando que se completen todas las escrituras.
espacio de búfer de registro
El proceso está esperando que haya espacio disponible en el búfer de registro (el espacio está disponible solo después de que LGWR haya escrito el contenido actual del búfer de registro en el disco). Esto suele suceder cuando las aplicaciones generan rehacer más rápido de lo que LGWR puede escribirlo. al disco.
Esto también puede suceder si la E/S del disco donde se encuentran los registros de rehacer es lenta
No debe haber esperas de espacio en el búfer de registro como tal en la base de datos. Considere aumentar el tamaño del búfer de registro si es pequeño o considere mover los archivos de registro a discos más rápidos, como discos seccionados.
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');
pct_buff_alloc_retries debe ser cero o inferior a 0,01 (<1 %). Si es mayor, considere aumentar el búfer de registro. Si es mayor, considere mover los archivos de registro a discos más rápidos, como discos seccionados.
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';
lectura secuencial del archivo de registro
El proceso está esperando que se lean los bloques del registro de rehacer en línea en la memoria. Esto ocurre principalmente al inicio de la instancia y cuando el proceso ARCH archiva los registros de rehacer en línea llenos.
escritura paralela del archivo de registro
El proceso está esperando que se escriban bloques en todos los miembros del registro de rehacer en línea en un grupo. LGWR suele ser el único proceso para ver este evento de espera. Esperará hasta que todos los bloques se hayan escrito para todos los miembros.
sincronización de archivos de registro
El proceso está esperando que LGWR termine de vaciar el búfer de registro en el disco. Esto ocurre cuando un usuario confirma una transacción. (Una transacción no se considera confirmada hasta que todo el proceso de rehacer para recuperar la transacción se haya escrito correctamente en el disco).
Un proceso LGWR lento puede introducir esperas de sincronización de archivos de registro, lo que hace que el usuario experimente tiempos de espera durante la confirmación o la reversión. Los eventos de escritura paralela del archivo de registro y de espera de sincronización del archivo de registro están interrelacionados y deben tratarse simultáneamente.
Debemos intentar asignar los registros de rehacer al disco de alto rendimiento (disco de estado sólido). También deberíamos intentar reducir la carga en LGWR al reducir las confirmaciones en las aplicaciones.
La pieza de copia de seguridad en caliente manual también puede introducir estrés en el sistema al generar muchas cosas de rehacer, así que evítela durante las horas pico
A veces LGWR está hambriento de recursos de CPU. Si el servidor está muy ocupado, LGWR también puede quedarse sin CPU. Esto conducirá a una respuesta más lenta de LGWR, aumentando las esperas de "sincronización de archivos de registro". Después de todo, estas llamadas al sistema y llamadas de E/S deben usar CPU. En este caso, la "sincronización de archivos de registro" es un síntoma secundario y la resolución de la causa raíz del uso elevado de la CPU reducirá las esperas de "sincronización de archivos de registro".
Debido a problemas de falta de memoria, LGWR también se puede paginar. Esto también puede conducir a una respuesta más lenta de LGWR.
deshacer extensión de segmento
La sesión está esperando a que se amplíe o se reduzca un segmento de deshacer.
escribir esperas completas
La sesión está esperando que se escriba en el disco un búfer solicitado; el búfer no se puede usar mientras se está escribiendo.
Latch:cadenas de búfer de caché
Los latches de cadenas de búferes de caché se utilizan para proteger una lista de búferes en la caché de búferes. Estos pestillos se utilizan al buscar, agregar o eliminar un búfer de la memoria caché del búfer.
Los bloques en el caché del búfer se colocan en listas enlazadas (cadenas de búfer de caché) que cuelgan de una tabla hash. La cadena hash en la que se coloca un bloque se basa en el DBA y la CLASE del bloque. Cada cadena hash está protegida por un único pestillo secundario. Los procesos necesitan obtener el pestillo correspondiente para permitirles escanear una cadena hash en busca de un búfer para que la lista vinculada no cambie debajo de ellos.
La contención en este pestillo generalmente significa que hay un bloque que está en gran contención (conocido como bloque caliente).
Para identificar la cadena de búfer a la que se accede con mucha frecuencia y, por lo tanto, el bloque en disputa, consulte las estadísticas de bloqueos temporales de las cadenas de búferes de caché utilizando la vista V$LATCH_CHILDREN. Si hay un latch secundario de cadenas de búfer de caché específico que tiene muchos más OBTENER, MISSES y SLEEPS en comparación con los otros latches secundarios, entonces este es el latch secundario en disputa.
Este pestillo tiene una dirección de memoria, identificada por la columna 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 /
Utilice el valor de la columna ADDR junto con la vista V$BH para identificar los bloques protegidos por este latch. Por ejemplo, dada la dirección (V$LATCH_CHILDREN.ADDR) de un pestillo muy disputado, consulta los números de archivo y bloque:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH es un recuento de toques para el búfer. Un valor alto de X$BH.TCH indica un bloque activo.
Muchos bloques están protegidos por cada pestillo. Uno de estos búferes probablemente será el bloque caliente. Cualquier bloque con un valor alto de TCH es un bloque caliente potencial. Realice esta consulta varias veces e identifique el bloque que aparece constantemente en la salida.
Una vez que haya identificado el bloque activo, consulte DBA_EXTENTS utilizando el número de archivo y el número de bloque para identificar el segmento.
Información importante sobre el evento de espera
La vista v$session_wait muestra información sobre los eventos de espera por los que están esperando actualmente las sesiones activas. La siguiente es la descripción de esta vista y contiene algunas columnas muy útiles, especialmente las referencias P1 y P2 a los objetos asociados con los eventos de espera.
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)
Usando v$session_wait, es fácil interpretar cada parámetro de evento de espera usando las columnas de texto descriptivo correspondientes para ese parámetro. Además, se agregaron columnas de clase de espera para que varios eventos de espera pudieran agruparse en las áreas de procesamiento relacionadas, como red, aplicación, inactividad, simultaneidad, etc.
Esta columna también se agregó a la tabla v$session desde 10g en adelante . Entonces puede usar v$session para encontrar todos los detalles
Cada evento de espera contiene otros parámetros que brindan información adicional sobre el evento.
Cómo encontrar la información sobre el evento de espera y su parámetro
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';
Digamos, por ejemplo, que tomamos
Los valores de entrada event_name:archivo db lectura dispersa
Valor original de 3:WHERE NOMBRE ='&event_name A'
El nuevo valor 3:WHERE NOMBRE ='archivo db lectura dispersa'
El nombre P1 P2 P3
archivo db archivo de lectura disperso # bloque # bloques
archivo #:número de archivo de datos
Bloque #:número de bloque inicial
bloques:para leer el número del bloque de datos
Ahora veamos cómo la información anterior puede ayudarnos a capturar varias cosas
Suponga que una sesión en particular espera un evento de espera de búfer ocupado, el objeto de la base de datos que causa este evento de espera se puede determinar fácilmente:
select username, event, p1, p2 from v$session_wait where sid = 4563;
El resultado de esta consulta para una sesión particular con SID 4563 podría verse así:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Las columnas P1 y P2 permiten que el DBA determine los números de archivo y bloque que causaron este evento de espera. La consulta a continuación recupera el nombre del objeto que posee el bloque de datos 155, el valor de P2 anterior:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
La capacidad de analizar y corregir los eventos de espera de la base de datos de Oracle es fundamental en cualquier proyecto de ajuste. La mayor parte de la actividad en una base de datos implica la lectura de datos, por lo que este tipo de ajuste puede tener un impacto enorme y positivo en el rendimiento.
Nota:Al realizar un análisis de espera, es fundamental recordar que todas las bases de datos de Oracle experimentan eventos de espera y que la presencia de esperas no siempre indica un problema. De hecho, todas las bases de datos bien ajustadas tienen algún cuello de botella.
podemos usar el evento 10046 para rastrear el evento de espera de la sesión también
También lee
Documentación de Oracle
v$active_session_history
Explicar el plan en Oracle
