A lo largo de mi carrera como profesional de datos, tanto dentro de Microsoft como como consultor, descubrí que una de las partes más incomprendidas de una base de datos de SQL Server es el registro de transacciones. La falta de conocimiento sobre cómo funciona el registro de transacciones y cómo debe administrarse, o simplemente conceptos erróneos, pueden generar todo tipo de problemas de producción, incluidos:
- El registro de transacciones crece fuera de control y potencialmente se queda sin espacio
- Problemas de rendimiento debido a la reducción repetida del registro de transacciones
- Problemas de rendimiento debido a un problema conocido como fragmentación de VLF , que discutí en esta publicación
- La incapacidad de recuperar a un punto deseado en el tiempo usando copias de seguridad del registro de transacciones
- La incapacidad de realizar una copia de seguridad del registro final durante la recuperación ante desastres (consulte aquí para obtener una explicación de las copias de seguridad del registro final)
- Varios problemas relacionados con las conmutaciones por error y la restauración del rendimiento
Con esta publicación, estoy comenzando una serie ocasional sobre el registro de transacciones y cómo funciona y cómo debe administrarse, y abordaré todos los problemas anteriores a lo largo del curso. En esta publicación, explicaré qué es el registro y por qué es necesario.
Terminología básica sobre el registro
Cuando hablo de cualquier mecanismo en SQL Server, encuentro que hay un problema del huevo y la gallina en el que necesito usar una palabra o frase antes de explicarla. Para evitar ese problema en esta serie, comenzaré explicando cierta terminología que debe usarse cuando se habla de registro, y ampliaré muchos de estos términos a medida que avance la serie.
Transacción, confirmación y reversión
Una transacción abarca un cambio o un conjunto de cambios en una base de datos. Tiene un principio definido y un final definido. El comienzo es cuando se utiliza una instrucción BEGIN TRANSACTION o SQL Server inicia automáticamente una transacción por usted. El final puede ser una de cuatro cosas:
- La transacción se confirma cuando se ejecuta una instrucción COMMIT TRANSACTION
- La transacción se confirma cuando SQL Server confirma automáticamente la transacción en el caso de una transacción de confirmación automática
- La transacción termina de retroceder después de que se ejecuta una instrucción ROLLBACK TRANSACTION
- La transacción termina de revertirse después de que ocurrió un problema y SQL Server revierte automáticamente la transacción
Cuando se confirma una transacción, los cambios realizados por la transacción se finalizan en la base de datos y son duraderos en el registro de transacciones de SQL Server en el disco. Tenga en cuenta que dije, "en el registro de transacciones". Los cambios reales en las páginas del archivo de datos en la memoria *no* se escriben en el disco cuando se confirma la transacción. No es necesario que sean duraderos en los archivos de datos porque los cambios ya son duraderos en el registro de transacciones. Eventualmente, las páginas del archivo de datos se escribirán en el disco mediante una operación de punto de control.
Por el contrario, cuando una transacción se revierte, los cambios de datos que la transacción realizó ya no están presentes en la base de datos. Todavía habrá algunos cambios físicos en la base de datos, ya que revertir una transacción significa realizar más cambios, pero puede pensar que una transacción revertida no ha afectado los datos en la base de datos.
Los puntos de control y las operaciones de reversión son temas dignos de sus propias publicaciones, por lo que los explicaré más adelante en la serie.
Analizo estos tres términos con mucha más profundidad en el tutorial Introducción a las transacciones de SQL Server en el blog de SentryOne.
Registro, registros de registro y registro de transacciones de SQL Server
Registrar simplemente significa crear una descripción duradera de un cambio en una base de datos, casi siempre en el contexto de una transacción. Cuando se realiza un cambio, el cambio se describe en un registro. Un registro de registro generalmente tiene suficiente información para permitir que el cambio se reproduzca en la base de datos o se revierta en la base de datos si es necesario.
Este registro estará inicialmente en la memoria y puede escribirse en el disco antes de que se confirme la transacción, pero definitivamente debe escribirse en el disco antes la transacción puede terminar de comprometerse, de lo contrario, la transacción no sería duradera. Una excepción a esta regla es cuando la durabilidad retrasada función está habilitada, que Aaron Bertrand analiza en esta publicación.
Los registros de registro se almacenan en el registro de transacciones (uno o más archivos de registro en el disco), que tiene una arquitectura interna algo compleja, y hablaré de eso y mucho más en los registros de registro en la próxima publicación de la serie.
Recuperación de bloqueo
Un bloqueo es cuando SQL Server se cierra inesperadamente y las diversas bases de datos modificadas no se pueden cerrar correctamente (asegurándose de que todas las páginas de archivos de datos modificados se escriban en el disco y que la base de datos esté marcada como cerrada correctamente).
Cuando SQL Server se inicia, verifica todas las bases de datos para ver si alguna no se marcó como cerrada limpiamente. Si encuentra uno, esa base de datos debe pasar por una recuperación de bloqueo. Esto asegura lo siguiente:
- Para cualquier transacción que se haya confirmado antes del bloqueo, asegúrese de que todos los cambios en la transacción se reflejen en la base de datos (es decir, reproduzca la transacción)
- Para cualquier transacción que no se haya confirmado antes del bloqueo, asegúrese de que ninguno de los cambios en la transacción se refleje en la base de datos (es decir, revierta la transacción)
En otras palabras, la recuperación de fallas hace que una base de datos sea transaccionalmente consistente desde el momento en que ocurrió el accidente. Se utiliza la recuperación de bloqueo:
- Cuando SQL Server se inicia y encuentra una base de datos que debe recuperarse
- Durante una conmutación por error a una copia secundaria de una base de datos
- Al final de una secuencia de restauración que involucre copias de seguridad (ver aquí)
La recuperación de fallas es un proceso complejo y requiere otras publicaciones de la serie antes de que pueda explicarlo en profundidad.
¿Por qué es necesario iniciar sesión?
La razón más básica para el registro es permitir que la base de datos de SQL Server haga que las transacciones sean duraderas, de modo que puedan recuperarse durante la recuperación de fallas o revertirse si es necesario durante las operaciones normales de la base de datos. Si no hubiera registro, una base de datos sería transaccionalmente inconsistente y posiblemente estructuralmente corrupta después de un bloqueo.
Sin embargo, sin iniciar sesión, una gran cantidad de otras características en SQL Server no serían posibles, incluyendo:
- Copias de seguridad de datos que se pueden recuperar de manera consistente
- Copias de seguridad del registro de transacciones de SQL Server que se pueden usar durante una operación de restauración y para implementar el trasvase de registros
- Replicación, que se basa en poder recolectar transacciones del registro de transacciones
- Change Data Capture, que utiliza el Log Reader Agent de replicación transaccional para recopilar cambios del registro de transacciones
- Grupos de disponibilidad y duplicación de bases de datos, que se basan en el envío de registros a copias secundarias de la base de datos para su reproducción
SQL Server (y todos los servidores de bases de datos similares) utiliza lo que se llama registro de escritura anticipada . Esto significa que las descripciones de los cambios deben escribirse en el disco antes de los cambios mismos para garantizar la capacidad de recuperar correctamente una base de datos. Si se escribió un cambio en un archivo de datos antes de que los registros lo describieran y SQL Server fallara, no habría forma de saber qué revertir y la base de datos sería inconsistente. Este orden es invariable, sin importar el nivel de aislamiento, el tipo de transacción o si se utiliza la característica de durabilidad retrasada. Registro de registros primero, páginas de datos después.
Solo la punta del iceberg
Como puede ver en esta publicación introductoria, una gran cantidad se destina al registro de transacciones y al inicio de sesión en una base de datos de SQL Server, y todo lo que he hecho hasta ahora es definir una terminología de alto nivel y explicar por qué se requiere el registro. ¡Espero que te unas a mí a medida que me expando y profundizo a medida que avanza la serie!
