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.
Respuestas:
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.fuente