Alto PAGELATCH_ * y WRITELOG esperan. ¿Están relacionados?


11

Estamos viendo muy altos tipos de espera PAGELATCH_EX y PAGELATCH_SH junto con altas esperas de WRITELOG. He diagnosticado la consulta que causa las esperas de PAGELATCH y puedo eliminarlas al reducir la tasa de inserción en una clave principal en clúster ocupada definida con un valor de IDENTIDAD. Entiendo que este fenómeno se conoce como la última contención de inserción de página.

Sin embargo, mi pregunta es cuando se inserta un nuevo registro, ¿SQL Server toma un PAGELATCH_EX exclusivo en una página de búfer, inserta el registro en la página de búfer, escribe el registro en el registro de transacciones y luego libera el PAGELATCH_EX exclusivo como https detallado : // www.microsoft.com/en-ie/download/details.aspx?id=26665 Página 24. ¿O escribe primero el registro en el registro de transacciones antes de tomar el PAGELATCH_EX como se detalla "Resolviendo la contención de PAGELATCH en cargas de trabajo INSERT altamente concurrentes" Información básica Guía de SQLCAT para: motor relacional

Si el registro se escribe para iniciar sesión fuera del mecanismo de enclavamiento, entonces puedo descartar escrituras lentas en el disco como causa de altas esperas de PAGELATCH. Pero si el pestillo se mantiene hasta que el registro se haya endurecido para iniciar sesión, entonces probablemente debería tener en cuenta WRITELOG.

Además, ¿tener múltiples índices no agrupados provocaría que el enganche PAGELATCH_ * se mantenga por más tiempo, es decir, si una tabla tiene un agrupamiento y múltiples índices no agrupados se agregan y liberan simultáneamente en cada una de las páginas de búfer de índice?

Actualización 1 Después de leer confio-sql-server-writelog-wait slide two y arquitectura general WAL. Ahora entiendo que el paso "Registrar una entrada de registro de que la fila ha sido modificada" detallado en ambos documentos se refiere a que SQL Server registra un cambio en la memoria caché del registro de transacciones, no en el disco. Una vez que la transacción está completa o el búfer lleno, todos los registros se vuelcan inmediatamente al disco.


1
Mirando un problema muy similar a este en este momento ..
Dave Lawrence

¿Ha investigado posibles VLF altos que causan problemas?
Kin Shah

@Kin, ¿quiere decir en términos de un vaciado de registro lento al disco que mantiene abierto un pestillo PAGELATCH_EX y provoca una contención de pestillo?
Pixelado

No hay ninguna razón para que una implementación de SQL Server deba generar el registro de registro bajo un pestillo de página. ¿Por qué lo harían de esta manera? Increíble. Además, si las escrituras de registro se hicieran bajo patchlatch, casi nunca vería las esperas de WRITELOG. Solo puede tomarse un tipo de espera a la vez.
Usr

Respuestas:


1

Sin embargo, mi pregunta es cuando se inserta un nuevo registro, ¿SQL Server toma un PAGELATCH_EX exclusivo en una página de búfer, inserta el registro en la página de búfer, escribe el registro en el registro de transacciones y luego libera el PAGELATCH_EX exclusivo

Debe tener en cuenta que el enganche solo protege la integridad física de la página mientras está en la memoria, por lo que el enganche se tomaría cuando la página está en la memoria. Suponga que se está insertando un registro y que esa página necesita ser recuperada. Primero, la página se bloquearía y se llevaría a la memoria, luego se bloquearía y se escribiría información. El proceso después de esto sería

  • Generar registro de registro

  • Actualice la página LSN para que coincida con la del registro

  • Cambiar datos (ensucia la página)

  • Latch Latch

  • Iniciar transacción de inicio

  • FlushToLSN de Commit

  • Liberar cerraduras

  • Confirmar transacción completada

Para obtener más detalles y explicaciones sobre los pasos anteriores, lea el blog de presentación de E / S de Bob Dorr

Las esperas de Pagelatch * no son esperas de E / S y he visto la mayoría de las veces que estas esperas son importantes debido a la contención de la asignación. Mi presentimiento es que tiene que ver algo con cómo tempdb is configured. Entonces, ¿cómo está configurado su tempdb ?, ¿cuántos archivos de datos tempdb están presentes? Asegúrese de que tengan el mismo crecimiento automático y el mismo tamaño. Cuando se crea una nueva página, las páginas del sistema como GAM, SGAM y PFS necesitan actualizarse o se accede a ellas, y cuando SQL Server encuentra contención al acceder a estas páginas, tales esperas entran en escena.


Hola @Shanky, basado en sys.dm_os_waiting_tasks.resource_description junto con DBCC PAGE y el tipo de PAGELATCH_ * He descartado tempDB. Según la cadena de eventos de Bob Dorr, parece que el paso "Generar registro de registro" se ha completado dentro del mecanismo de bloqueo.
Pixelado

3
Ambos son eventos mutuamente excluyentes, la escritura en el archivo de registro no tiene nada que ver con bloquear su solo SQL Server siguiendo el protocolo WAL para escribir información en el registro antes de realmente realizar la transacción
Shanky
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.