En la segunda parte de esta serie, describí la jerarquía estructural del registro de transacciones. Como esta publicación trata principalmente de los archivos de registro virtuales (VLF) que describí, le recomiendo que lea la segunda parte antes de continuar.
Cuando todo está bien, el registro de transacciones se repetirá sin cesar, reutilizando los VLF existentes. Este comportamiento es lo que yo llamo la naturaleza circular del registro . A veces, sin embargo, sucederá algo para evitar esto, y el registro de transacciones crece y crece, agregando más y más VLF. En esta publicación, explicaré cómo funciona todo esto, o a veces no.
VLF y truncamiento de registros
Todos los VLF tienen una estructura de encabezado que contiene metadatos sobre el VLF. Uno de los campos más importantes de la estructura es el estado del VLF, y los valores que nos interesan son cero, lo que significa que el VLF está inactivo. y dos, lo que significa que el VLF está activo . Es importante porque un VLF inactivo se puede reutilizar, pero uno activo no. Tenga en cuenta que un VLF está totalmente activo o totalmente inactivo.
Un VLF permanecerá activo mientras haya registros requeridos en él, por lo que no se puede reutilizar ni sobrescribir (hablaré de los registros en sí la próxima vez). Ejemplos de razones por las que se pueden requerir registros de registro incluyen:
- Hay una transacción de ejecución prolongada de la que forman parte los registros, por lo que no se pueden liberar hasta que la transacción se haya confirmado o haya terminado de retroceder
- Una copia de seguridad del registro aún no ha realizado una copia de seguridad de esos registros
- Esa parte del registro aún no ha sido procesada por el Log Reader Agent para la replicación transaccional o la captura de datos modificados
- Esa parte del registro aún no se ha enviado a una réplica de grupo de disponibilidad o espejo de base de datos asíncrona
Es importante tener en cuenta que si no hay motivos para que un VLF permanezca activo, no volverá a estar inactivo hasta que se lleve a cabo un proceso denominado truncamiento de registros. ocurre - más sobre esto a continuación.
Usando un registro de transacciones hipotético simple con solo cinco VLF y números de secuencia de VLF que comienzan en 1 (recuerde que la última vez que en realidad nunca lo hacen), cuando se crea el registro de transacciones, VFL 1 se marca inmediatamente como activo, como siempre lo ha hecho. ser al menos un VLF activo en el registro de transacciones:el VLF en el que se escriben actualmente los bloques de registro. Nuestro escenario de ejemplo se muestra en la Figura 1 a continuación.
Figura 1:Registro de transacciones nuevo e hipotético con 5 VLF, números de secuencia 1 a 5.
A medida que se crean más entradas de registro y se escriben más bloques de registro en el registro de transacciones, VLF 1 se llena, por lo que VLF 2 debe activarse para que se escriban más bloques de registro, como se muestra en la Figura 2 a continuación.
Figura 2:La actividad se mueve a través del registro de transacciones.
SQL Server realiza un seguimiento del inicio de la transacción no confirmada (activa) más antigua, y este LSN se conserva en el disco cada vez que se produce una operación de punto de control. También se rastrea el LSN del registro de registro más reciente escrito en el registro de transacciones, pero solo se rastrea en la memoria, ya que no hay forma de conservarlo en el disco sin encontrarse con varias condiciones de carrera. Eso no importa, ya que solo se usa durante la recuperación de fallas, y SQL Server puede calcular el LSN del "final" del registro de transacciones durante la recuperación de fallas. Los puntos de control y la recuperación de fallas son temas para futuras publicaciones de la serie.
Eventualmente, VLF 2 se llenará y VLF 3 se activará, y así sucesivamente. El quid de la naturaleza circular del registro de transacciones es que los VLF anteriores en el registro de transacciones se vuelven inactivos para que puedan reutilizarse. Esto se hace mediante un proceso llamado truncamiento de registros , que también se denomina comúnmente borrado de registros . Desafortunadamente, estos dos términos son terriblemente inapropiados porque nada se trunca o borra.
El truncamiento de registros es simplemente el proceso de examinar todos los VLF en el registro de transacciones y determinar qué VLF activos ahora se pueden marcar como inactivos nuevamente, ya que SQL Server aún no requiere ninguno de sus contenidos. Cuando se realiza el truncamiento de registros, no hay garantía de que los VLF activos puedan desactivarse; depende completamente de lo que suceda con la base de datos.
Hay dos conceptos erróneos comunes sobre el truncamiento de registros:
- El registro de transacciones se vuelve más pequeño (el concepto erróneo de "truncamiento"). No, no lo hace, no hay cambio de tamaño debido al truncamiento del registro. Lo único capaz de hacer que el registro de transacciones sea más pequeño es un DBCC SHRINKFILE explícito.
- Los VLF inactivos se ponen a cero de alguna manera (el concepto erróneo de "limpieza"). No, no se escribe nada en el VLF cuando se desactiva, excepto algunos campos en el encabezado del VLF.
La figura 3 a continuación muestra nuestro registro de transacciones donde los VLF 3 y 4 están activos, y el truncamiento del registro pudo marcar los VLF 1 y 2 como inactivos.
Figura 3:el truncamiento del registro marca los VLF anteriores como inactivos.
El momento en que se produce el truncamiento del registro depende del modelo de recuperación que se utilice para la base de datos:
- Modelo simple:el truncamiento del registro ocurre cuando se completa una operación de punto de control
- Modelo completo o modelo de registro masivo:el truncamiento del registro se produce cuando se completa una copia de seguridad del registro (siempre y cuando no se esté ejecutando una copia de seguridad diferencial o completa concurrente, en cuyo caso el truncamiento del registro se pospone hasta que se complete la copia de seguridad de los datos)
No hay excepciones a esto.
Naturaleza circular del tronco
Para evitar que el registro de transacciones tenga que crecer, el truncamiento del registro debe poder marcar los VLF como inactivos. El primer VLF físico en el registro debe estar inactivo para que el registro de transacciones tenga su naturaleza circular.
Considere la Figura 4 a continuación, que muestra que los VLF 4 y 5 están en uso y el truncamiento del registro ha marcado los VLF 1 a 3 como inactivos. Se generan más entradas de registro, se escriben más bloques de registro en VLF 5 y, finalmente, se llena.
Figura 4:La actividad llena el VLF físico más alto en el registro de transacciones.
En este punto, el administrador de registros de la base de datos observa el estado del primer VLF físico en el registro de transacciones, que en nuestro ejemplo es VLF 1, con el número de secuencia 1. VLF 1 está inactivo, por lo que el registro de transacciones puede retomar y comience a llenar de nuevo desde el principio. El administrador de registro cambia el primer VLF a activo y aumenta su número de secuencia para que sea uno más alto que el número de secuencia de VLF más alto actual. Entonces se convierte en VLF 6, y el registro continúa con el bloque de registro que se escribe en ese VLF. Esta es la naturaleza circular del registro, como se muestra a continuación en la Figura 5.
Figura 5:La naturaleza circular del registro de transacciones y la reutilización de VLF.
Cuando las cosas van mal
Cuando el primer VLF físico en el registro de transacciones no está inactivo, el registro de transacciones no puede ajustarse, por lo que crecerá (siempre que esté configurado para hacerlo y haya suficiente espacio en disco). Esto sucede a menudo porque hay algo que impide que el truncamiento de registros desactive los VLF. Si encuentra que el registro de transacciones de una base de datos está creciendo, puede consultar SQL Server para averiguar si hay un problema de truncamiento del registro utilizando este código simple a continuación:
SELECT
[log_reuse_wait_desc]
FROM [master].[sys].[databases]
WHERE [name] = N'MyDatabase'; Si el truncamiento del registro pudo desactivar uno o más VLF, entonces el resultado será NADA. De lo contrario , se le dará una razón por la cual el truncamiento de registro no pudo desactivar ningún VLF. Hay una larga lista de posibles motivos que se describen aquí en la sección Factores que pueden retrasar el truncamiento del registro.
Es importante comprender la semántica del resultado:es la razón por la que el truncamiento del registro no pudo hacer nada la última vez que intentó ejecutarse . Por ejemplo, el resultado podría ser ACTIVE_BACKUP_OR_RESTORE, pero sabe que esa copia de seguridad completa de larga duración ha finalizado. Esto solo significa que la última vez que se intentó truncar el registro, la copia de seguridad aún se estaba ejecutando.
En mi experiencia, la razón más común para evitar el truncamiento de registros es LOG_BACKUP; es decir, ¡realice una copia de seguridad del registro! Pero también hay un comportamiento extraño e interesante con LOG_BACKUP . Si ve continuamente el resultado LOG_BACKUP pero sabe que las copias de seguridad de registros se están realizando correctamente, es porque hay muy poca actividad en la base de datos y el VLF actual es el mismo que la última vez que se realizó una copia de seguridad de registros. Entonces, LOG_BACKUP significa "ir a realizar una copia de seguridad del registro" o "todos los registros respaldados son del VLF actual, por lo que no se pudo desactivar". Cuando esto último sucede, puede resultar confuso.
Dando vueltas hacia atrás...
Es muy importante mantener la naturaleza circular del registro de transacciones para evitar costosos crecimientos de registros y la necesidad de tomar medidas correctivas. Por lo general, esto significa asegurarse de que se realicen copias de seguridad de registros con regularidad para facilitar el truncamiento de registros y dimensionar el registro de transacciones para que pueda contener operaciones grandes y de ejecución prolongada, como reconstrucciones de índices u operaciones ETL, sin que se produzca un crecimiento del registro.
En la siguiente parte de la serie, cubriré los registros, cómo funcionan y algunos ejemplos interesantes.
