Blog de Rajat DBA

Esta es una copia de la Nota de Referencia 22908.1 de Metalink, para aquellos que no tienen acceso a ella.

1. ¿Qué es un pestillo?
   Los cierres son mecanismos de serialización de bajo nivel utilizados para proteger las estructuras de datos compartidos en el SGA. La implementación de pestillos depende del sistema operativo, particularmente en lo que respecta a si un proceso esperará un pestillo y durante cuánto tiempo.

Un pestillo es un tipo de cerradura que se puede adquirir y liberar muy rápidamente. Los pestillos se utilizan normalmente para evitar que más de un proceso ejecute el mismo código en un momento dado. Asociado con cada pestillo hay un procedimiento de limpieza que se llamará si un proceso muere mientras se sostiene el pestillo. Los pestillos tienen un nivel asociado que se usa para evitar bloqueos. Una vez que un proceso adquiere un pestillo a un cierto nivel, no puede adquirir posteriormente un pestillo a un nivel igual o inferior a ese nivel (a menos que lo adquiera de nuevo).

2.Pestillos vs pone en cola

pone en cola son otro tipo de mecanismo de bloqueo se utiliza en Oracle.
Un enqueue es un mecanismo más sofisticado que permite que varios procesos concurrentes tengan un grado variable de intercambio de recursos “conocidos”. Cualquier objeto que se pueda usar simultáneamente, se puede proteger con enqueues. Un buen ejemplo es el de las cerraduras en las mesas. Permitimos diferentes niveles de uso compartido en tablas, por ejemplo, dos procesos pueden bloquear una tabla en modo de uso compartido o en modo de actualización de uso compartido, etc. Una diferencia es que la cola se obtiene utilizando un mecanismo de bloqueo específico del sistema operativo. Un enqueue permite al usuario almacenar un valor en la cerradura, es decir, el modo en el que lo estamos solicitando. El administrador de bloqueo del sistema operativo realiza un seguimiento de los recursos bloqueados. Si a un proceso no se le puede conceder el bloqueo porque es incompatible con el modo solicitado y el bloqueo se solicita con wait, el sistema operativo coloca al proceso solicitante en una cola de espera que se mantiene en FIFO.

Otra diferencia entre pestillos y enqueues es que en pestillos no hay cola de camareros ordenada como en enqueues. Los camareros de Latch pueden usar temporizadores para despertar y volver a intentarlo o girar (solo en multiprocesadores). Dado que todos los camareros están volviendo a intentarlo simultáneamente (dependiendo del programador), cualquiera podría obtener el pestillo y posiblemente el primero en intentarlo podría ser el último en obtenerlo.

1. ¿Cuándo necesitamos obtener un pestillo?

Un proceso adquiere un pestillo cuando se trabaja con una estructura en el SGA (Área Global del Sistema). Continúa sosteniendo el pestillo durante el período de tiempo que trabaja con la estructura. El pestillo se cae cuando el proceso termina con la estructura. Cada pestillo protege un conjunto de datos diferente, identificado por el nombre del pestillo.

Oracle utiliza instrucciones atómicas como “probar y configurar” para operar en pestillos. Los procesos que esperan para ejecutar una parte del código para la que algún otro proceso ya ha obtenido un pestillo esperarán hasta que se libere el pestillo. Los ejemplos son pestillos de asignación de rehacer, pestillos de copia, pestillo de control de archivo, etc. La idea básica es bloquear el acceso simultáneo a estructuras de datos compartidas. Dado que las instrucciones para establecer y liberar los cierres son atómicas, el sistema operativo garantiza que solo un proceso lo obtenga. Dado que es solo una instrucción, es bastante rápido. Los pestillos se mantienen durante períodos cortos de tiempo y proporcionan un mecanismo para la limpieza en caso de que un soporte muera anormalmente mientras lo sostiene. Esta limpieza se realiza utilizando los servicios de PMON.

1. ¿Modos de solicitud de pestillos?

La solicitud de pestillos se puede hacer en dos modos: “dispuesto a esperar “o”sin esperar”. Normalmente, los pestillos se solicitarán en modo “dispuesto a esperar”. Una solicitud en modo” dispuesto a esperar ”
se repetirá, esperará y solicitará de nuevo hasta que se obtenga el pestillo. En el modo “sin espera”, el proceso solicita el pestillo. Si uno no está disponible, en lugar de esperar, se solicita otro. Solo cuando todo falla, el proceso del servidor tiene que esperar.

Ejemplos de cierres” dispuestos a esperar “son: cierres de caché de biblioteca y grupo compartido
Un ejemplo de cierres” sin espera ” es el cierre de copia rehecha.

5. ¿Qué causa la contención de cierre?Si un pestillo requerido está ocupado, el proceso que lo solicita gira, lo intenta de nuevo y, si aún no está disponible, gira de nuevo. El bucle se repite hasta un número máximo de veces determinado por el parámetro de inicialización _SPIN_COUNT. Si después de todo este bucle, el pestillo aún no está disponible, el proceso debe ceder la CPU y ponerse en reposo. Inicialmente duerme un centisegundo. Este tiempo se duplica en cada sueño posterior.

Esto hace que se produzca una desaceleración y se produzca un uso adicional de la CPU, hasta que haya un pestillo disponible. El uso de CPU es una consecuencia del “giro” del proceso. “Giro” significa que el proceso continúa buscando la disponibilidad del pestillo después de ciertos intervalos de tiempo, durante los cuales duerme.

1. ¿Cómo identificar la contención de los cierres internos?

datos Relevantes diccionario vistas a la consulta:

V$PESTILLO
V$LATCHHOLDER
V$LATCHNAME

Cada fila en la V$PESTILLO de la tabla contiene las estadísticas para un tipo diferente de pestillo. Las columnas de la tabla reflejan la actividad de los diferentes tipos de solicitudes de cierre. La distinción entre estos tipos de solicitudes es si el proceso de solicitud continúa solicitando un pestillo si no está disponible:

dispuesto a esperar Si el pestillo solicitado con una solicitud dispuesta a esperar
no está disponible, el proceso de solicitud
espera un corto tiempo y solicita el pestillo nuevamente.
El proceso continúa esperando y solicitando hasta que
el pestillo esté disponible.

sin espera Si el pestillo solicitado con una solicitud inmediata no está disponible
, el proceso de solicitud no espera
, pero continúa el procesamiento.

Información clave de VNAME LATCHNAME:

OBTIENE el número de solicitudes de espera exitosas para
un latch.

FALLA el número de veces que una solicitud inicial de estar dispuesto a esperar
no tuvo éxito.

SLEEPS Número de veces que un proceso esperó un pestillo solicitado
después de una solicitud inicial de wiling-to-wait.

INMEDIATO_AMPLIA el número de solicitudes inmediatas exitosas para cada pestillo.

IMMEDIATE_MISSES Número de solicitudes inmediatas sin éxito para cada pestillo.

Cálculo de la relación de aciertos de cierre

Para obtener la relación de aciertos de los cierres, aplique la siguiente fórmula:

Relación de aciertos”dispuesto a esperar”=(SE PIERDE)/SE PIERDE
Relación de aciertos”sin espera”=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

Este número debe estar cerca de 1. Si no, sintonice de acuerdo con el nombre de latch

1. Útiles scripts SQL para obtener información de latch

/*
** Muestra estadísticas de pestillo de todo el sistema.
* /
formato de nombre de columna A32 encabezado truncado “NOMBRE DE CIERRE”
encabezado pid de columna “SOPORTE PID”
seleccionar c.name, a. addr, a. gets,a.misses, a.sleeps,
a.immediate_gets,a.immediate_misses, b. pid
de v lat latch a, v v latchholder b, vname latchname c
donde a.addr = b. laddr(+)
y a. latch# = c. latch #
ordenar por a. latch#;

/*
** Dada la dirección de Latch, averigua el nombre de Latch.
* /
formato de nombre de columna a64 encabezado ‘Nombre’
seleccionar a.name de vname latchname a, v donde b.addr = ‘& addr ‘
y b. latch# = a. latch#;

/*
** Mostrar estadísticas de cierre por nombre de cierre.
* /
formato de nombre de columna a32 encabezado ‘NOMBRE DE CIERRE’
encabezado de columna pid ‘SOPORTE PID’
seleccionar c.name,a.addr,a.gets,a.misses, a.sleeps,
a.immediate_gets,a.immediate_misses, b.pid
de v lat latch a, v v latchholder b, vname latchname c
donde a. addr = b. laddr (+) y a.latch# = c. latch #
y c.name como ‘& latch_name% ‘ ordenar por un.latch#;

1. Lista de todos los cierres

Las versiones de Oracle pueden diferir en el número de cierre asignado a los cierres existentes.
La siguiente consulta le ayudará a identificar todos los pestillos y el número asignado.

nombre de columna formato a40 encabezado ‘NOMBRE DE CIERRE’
seleccione cierre#, nombre de vname nombre de cierre;

1. Lista de cierres que son de mayor preocupación para un DBA

• CIERRES DE CACHÉ DE BÚFER: Hay dos cierres principales que protegen los bloques de datos en la caché de búfer. La contención para estos dos pestillos generalmente se ve cuando una base de datos tiene altas tasas de E/S. Podemos reducir la contención de estos pestillos y sintonizarlos ajustando cierto inicio.parámetros ora.

Bloqueo de cadenas de búferes de caché:

Este bloqueo se adquiere cada vez que se accede a un bloque en la caché de búfer (fijado).

Reducir la contención para el cierre de cadenas de búfer de caché generalmente requerirá reducir las tasas de E/S lógicas ajustando y minimizando los requisitos de E/S del SQL involucrado. Las altas tasas de E/S podrían ser un signo de un bloque caliente (es decir, un bloque de alto acceso).

Véase la Nota 163424.1 Cómo Identificar un Bloque Caliente Dentro de La Base de Datos para identificar correctamente este problema.

Bloqueo de cadena LRU de búferes de caché:

El bloqueo de cadena lru de búfer de caché se adquiere para introducir un nuevo bloque en la caché de búfer y al escribir un búfer de nuevo en el disco, específicamente al intentar escanear la cadena LRU (menos utilizada recientemente) que contiene todos los bloques sucios en la caché de búfer.

Es posible reducir la contención del cierre de cadena lru del búfer de caché aumentando el tamaño de la caché del búfer y, por lo tanto, reduciendo la velocidad a la que se introducen nuevos bloques en la caché del búfer. Dos parámetros dictan el tamaño de la caché del búfer, DB_BLOCK_SIZE y DB_BLOCK_BUFFERS. En realidad, solo los DB_BLOCK_BUFFERS se pueden cambiar sin volver a crear la base de datos. Precaución, al ajustar el grupo de búferes, evite el uso de búferes adicionales que contribuyen poco o nada a la proporción de aciertos de caché. Un error común es continuar aumentando el valor de DB_BLOCK_BUFFERS. Estos aumentos no tienen efecto si está realizando exploraciones de tablas completas u otras operaciones que no utilizan la caché de búfer. Varios grupos de búferes pueden ayudar a reducir la contención en este pestillo.Puede crear cierres de cadena lru de búfer de caché adicionales ajustando el parámetro de configuración DB_BLOCK_LRU_LATCHES. Es posible que pueda reducir la carga en los cierres de cadena de búfer de caché aumentando el parámetro de configuración _DB_BLOCK_HASH_BUCKETS

• CIERRES de BÚFER REDOLOG: Hay dos cierres de búfer Rehacer, el cierre de asignación rehacer y el cierre de copia rehacer. El pestillo de asignación de rehacer debe adquirirse para asignar espacio dentro del búfer. Si la entrada de registro de rehacer a realizar es mayor que el parámetro de configuración LOG_SMALL_ENTRY_MAX_SIZE, la sesión que adquiere el cierre de asignación de rehacer puede copiar la entrada en el búfer de rehacer inmediatamente mientras mantiene el cierre de asignación. Si la entrada de registro es mayor que LOG_SMALL_ENTRY_MAX_SIZE, entonces la sesión liberará el cierre de asignación de rehacer y adquirirá el cierre de copia rehacer para copiar la entrada. Solo hay un pestillo de asignación rehacer, pero puede haber pestillos de asignación LOG_SIMULTANEOUS_COPIES.

Pestillo de asignación de rehacer:

Este pestillo controla la asignación de espacio para entradas de rehacer en el búfer de registro de rehacer. Hay un pestillo de asignación de rehacer por instancia.

La contención de este pestillo en Oracle7 se puede reducir disminuyendo el valor de LOG_SMALL_ENTRY_MAX_SIZE en sistemas multi-cpu para forzar el uso del pestillo de copia rehacer
. En Oracle8i este parámetro está obsoleto, por lo que debe considerar aumentar el tamaño del LOG_BUFFER o reducir la carga del búfer de registro utilizando características de NOLOGGING cuando sea posible.

Pestillo de rehacer copia:

Este pestillo se usa para escribir registros de rehacer en el búfer de redolog. Este pestillo se espera en sistemas de cpu individuales y múltiples.

En sistemas multi-cpu, la contención se puede reducir aumentando el valor de LOG_SIMULTANEOUS_COPIES (Oculto en Oracle8i) y/o aumentando LOG_ENTRY_PREBUILD_THRESHOLD (indocumentado en Oracle7).

• CACHÉ DE BIBLIOTECA

Cierre de caché de biblioteca:

Los cierres de caché de biblioteca protegen las definiciones de objetos y sentencias SQL almacenadas en caché en la caché de biblioteca dentro del grupo compartido. El pestillo de caché de biblioteca se debe adquirir para agregar una nueva instrucción a la caché de biblioteca. Durante un análisis, Oracle busca en la caché de la biblioteca una instrucción coincidente. Si no se encuentra uno, Oracle analizará la instrucción SQL, obtendrá el pestillo de caché de biblioteca e insertará el nuevo SQL.

El primer recurso para reducir la contención de este bloqueo es asegurarse de que la aplicación está reutilizando tanto como sea posible la representación de instrucciones SQL. Utilice variables de enlace siempre que sea posible en la aplicación. Las fallas en este pestillo también pueden ser una señal de que la aplicación está analizando SQL a una velocidad alta y puede estar sufriendo de demasiada sobrecarga de CPU de análisis.Si la aplicación ya está afinada, se puede aumentar el TAMAÑO de SHARED_POOL_SIZE. Tenga en cuenta que si la aplicación no está utilizando la caché de la biblioteca de forma adecuada, la contención podría ser peor con una estructura más grande que se maneje.

El parámetro _KGL_LATCH_COUNT controla el número de cierres de caché de biblioteca. El valor predeterminado debería ser adecuado, pero si no se puede resolver la contención del bloqueo de caché de la biblioteca, puede ser aconsejable aumentar este valor. El valor predeterminado de _KGL_LATCH_COUNT es el siguiente número primo después de CPU_COUNT. Este valor no puede exceder de 66 (Ver: ).

Bloqueo de pin de caché de biblioteca:

El bloqueo de pin de caché de biblioteca debe adquirirse cuando se vuelve a ejecutar una instrucción en la caché de biblioteca. Las fallas en este cierre se producen cuando hay tasas de ejecución SQL muy altas.

Es poco lo que se puede hacer para reducir la carga en el bloqueo del pin de caché de la biblioteca, aunque se utilizan sinónimos privados en lugar de públicos o referencias directas a objetos como OWNER.La MESA puede ayudar.

• CIERRES RELACIONADOS CON EL GRUPO COMPARTIDO

Cierre de grupo compartido:

Mientras que el cierre de caché de biblioteca protege las operaciones con la caché de biblioteca, el cierre de grupo compartido se utiliza para proteger las operaciones críticas al asignar y liberar memoria en el grupo compartido.
Si una aplicación hace uso de SQL literal (no compartido), esto puede limitar gravemente la escalabilidad y el rendimiento. El costo de analizar una nueva instrucción SQL es costoso tanto en términos de requisitos de CPU como en el número de veces que es necesario adquirir y liberar la caché de biblioteca y los cierres de grupo compartido. Antes de Oracle9, solía haber un solo pestillo en toda la base de datos para proteger la asignación de memoria en la caché de la biblioteca. En Oracle9 se introdujeron varios niños para aliviar la disputa sobre este recurso.

Las formas de reducir el cierre de la piscina compartida son, evitar análisis duros cuando sea posible, analizar una vez, ejecutar muchos. Eliminar SQL literal también es útil para evitar el cierre de grupo compartido. El tamaño del shared_pool y el uso de MTS (opción de servidor compartido) también influyen en gran medida en el cierre del grupo compartido. La nota 62143.1 explica cómo identificar y corregir problemas con la piscina compartida y el pestillo de la piscina compartida.

Bloqueo de objetos de caché de fila:

Este bloqueo entra en juego cuando los procesos de usuario intentan acceder a los valores del diccionario de datos almacenados en caché.

No es común tener contención en este pestillo y la única manera de reducir la contención para este pestillo es aumentando el tamaño del grupo compartido (SHARED_POOL_SIZE).

1. Tuning _SPIN_COUNT (_LATCH_SPIN_COUNT en Oracle7)

SPIN_COUNT controla cuántas veces el proceso volverá a intentar obtener el pestillo antes de retroceder e irse a dormir. Esto básicamente significa que el proceso está en un bucle apretado de la CPU tratando continuamente de obtener el cierre para los intentos SPIN_COUNT. En un solo sistema de CPU, si un proceso Oracle intenta adquirir un pestillo, pero es mantenido por otra persona, el proceso liberará la CPU y permanecerá en reposo durante un corto período de tiempo antes de volver a intentarlo. Sin embargo, en un sistema multiprocesador (SMP) es posible que el proceso que sostiene el pestillo se ejecute en una de las otras CPU y, por lo tanto, libere potencialmente el pestillo en las próximas instrucciones (los pestillos generalmente se mantienen durante períodos de tiempo muy cortos).

El rendimiento se puede ajustar cambiando el valor de SPIN_COUNT. Si se utiliza un valor alto, el pestillo se alcanzará antes que si se utiliza un valor bajo. Sin embargo, puede usar más tiempo de CPU girando para obtener el pestillo si usa un valor alto para SPIN_COUNT. Puede disminuir esta probabilidad de suspensión de la sesión aumentando el valor de los parámetros de configuración _LATCH_SPIN_COUNT o SPIN_COUNT. Este parámetro controla el número de intentos que hará la sesión para obtener el pestillo antes de dormir. Girar en el pestillo consume CPU, por lo que si aumenta este parámetro, es posible que vea un aumento en la utilización general de la CPU de sus sistemas. Si su computadora está cerca del 100% de CPU y su aplicación está impulsada por el rendimiento en lugar de por el tiempo de respuesta, podría considerar disminuir el SPIN_COUNT para conservar la CPU. Ajustar SPIN_COUNT es prueba y error. En general, solo aumente SPIN_COUNT si hay suficientes recursos de CPU libres disponibles en el sistema, y disminuya solo si no hay capacidad de CPU de repuesto.