En mis últimas dos publicaciones, hablé sobre formas de reducir la cantidad de registro de transacciones que se genera y cómo garantizar que el registro de transacciones siempre se borre correctamente. En esta publicación quiero continuar con el tema del rendimiento del registro de transacciones y discutir algunos problemas de configuración del registro de transacciones que pueden causar problemas.
Demasiados VLF
El registro de transacciones se divide en fragmentos llamados archivos de registro virtuales (VLF) para que el sistema de administración de registros pueda realizar fácilmente un seguimiento de qué partes del registro de transacciones están disponibles para su reutilización. Hay una fórmula para la cantidad de VLF que obtiene cuando crea su registro de transacciones, lo hace crecer manualmente o lo hace automáticamente:
| Hasta 1 MB | 2 VLF, cada uno aproximadamente la mitad del tamaño total |
|---|---|
| 1 MB a 64 MB | 4 VLF, cada uno aproximadamente 1/4 del tamaño total |
| 64 MB a 1 GB | 8 VLF, cada uno aproximadamente 1/8 del tamaño total |
| Más de 1 GB | 16 VLF, cada uno aproximadamente 1/16 del tamaño total |
Por ejemplo, si crea un registro de transacciones de 8 GB, obtendrá 16 VLF donde cada uno tiene aproximadamente 512 MB. Si luego aumenta el registro en otros 4 GB, obtendrá 16 VLF adicionales, cada uno con aproximadamente 256 MB, para un total de 32 VLF.
Nota:este algoritmo cambió ligeramente para SQL Server 2014 para aliviar los problemas de fragmentación de VLF; consulte esta publicación de blog para obtener más detalles
Una mejor práctica general es establecer el crecimiento automático del registro en algo diferente al 10 % predeterminado, de modo que pueda controlar la pausa que se requiere cuando se inicializa en cero el nuevo espacio del registro de transacciones. Supongamos que crea un registro de transacciones de 256 MB y establece el crecimiento automático en 32 MB, y luego el registro crece a un tamaño de estado estable de 16 GB. Dada la fórmula anterior, esto dará como resultado que su registro de transacciones tenga más de 2000 VLF.
Esta cantidad de VLF probablemente dará como resultado algunos problemas de rendimiento para las operaciones que procesan el registro de transacciones (por ejemplo, recuperación de fallas, borrado de registros, copias de seguridad de registros, replicación transaccional, restauraciones de bases de datos). Esta situación se denomina tener fragmentación VLF. En general, cualquier número de VLF de más de mil será problemático y debe abordarse (¡lo máximo que he oído es 1,54 millones de VLF en un registro de transacciones que tenía más de 1 TB de tamaño!).
La forma de saber cuántos VLF tiene es usar el DBCC LOGINFO no documentado (y completamente seguro) dominio. El número de filas de salida es el número de VLF en su registro de transacciones. Si crees que tienes demasiados, la forma de reducirlos es:
- Permitir que se borre el registro
- Reducir manualmente el registro
- Repita los pasos 1 y 2 hasta que el registro alcance un tamaño pequeño (lo que puede ser complicado en un sistema de producción ocupado)
- Haga crecer manualmente el registro hasta el tamaño que debería tener, en pasos de hasta 8 GB para que cada VLF no supere los 0,5 GB
Puede leer más sobre los problemas de fragmentación de VLF y el proceso para solucionarlos en:
- Artículo de Microsoft KB que aconseja reducir los números de VLF
- ¿El crecimiento de los archivos de registro puede afectar a DML?
- 8 pasos para mejorar el rendimiento del registro de transacciones
Tempdb
Tempdb necesita tener su registro de transacciones configurado como cualquier otra base de datos, y puede crecer como cualquier otra base de datos. Pero también tiene un comportamiento insidioso que puede causarle problemas.
Cuando una instancia de SQL Server se reinicia por cualquier motivo, los datos y los archivos de registro de tempdb volverán al tamaño que tenían más recientemente. Esto es diferente de todas las demás bases de datos, que permanecen en su tamaño actual después de reiniciar una instancia.
Este comportamiento significa que si el registro de transacciones de tempdb ha crecido para adaptarse a la carga de trabajo normal, debe realizar un ALTER DATABASE para establecer el tamaño del archivo de registro; de lo contrario, su tamaño disminuirá después de reiniciar una instancia y tendrá que volver a crecer. Cada vez que un archivo de registro crece o crece automáticamente, el nuevo espacio debe inicializarse en cero y la actividad de registro se detiene mientras se hace. Por lo tanto, si no administra correctamente el tamaño del archivo de registro de tempdb, pagará una penalización de rendimiento a medida que crezca después de cada reinicio de instancia.
Reducción regular de archivos de registro
Muy a menudo escucho a personas decir cómo suelen reducir el registro de transacciones de una base de datos después de que crece a partir de una operación regular (por ejemplo, una importación de datos semanal). Esto no es algo bueno de hacer.
Tal como expliqué anteriormente, cada vez que el registro de transacciones crece o crece automáticamente, hay una pausa mientras la nueva parte del archivo de registro se inicializa en cero. Si reduce regularmente el registro de transacciones porque crece al tamaño X, eso significa que sufre problemas de rendimiento con regularidad, ya que el registro de transacciones vuelve a crecer automáticamente al tamaño X.
Si su registro de transacciones sigue creciendo hasta el tamaño X, ¡déjelo en paz! Establézcalo proactivamente en el tamaño X, administre sus VLF como expliqué anteriormente y acepte el tamaño X como el tamaño que se requiere para su carga de trabajo normal. Un registro de transacciones más grande no es un problema.
Múltiples archivos de registro
La creación de varios archivos de registro para una base de datos no mejora el rendimiento. Sin embargo, puede ser necesario agregar un segundo archivo de registro si el archivo de registro existente se queda sin espacio y no está dispuesto a forzar el borrado del registro de transacciones cambiando al modelo de recuperación simple y realizando un punto de control (ya que esto interrumpe la copia de seguridad del registro). cadena).
A menudo me preguntan si hay alguna razón apremiante para eliminar el segundo archivo de registro o si está bien dejarlo en su lugar. La respuesta es que debes eliminarlo tan pronto como puedas.
Aunque el segundo archivo de registro no causa problemas de rendimiento para su carga de trabajo, sí afecta la recuperación ante desastres. Si su base de datos se destruye por algún motivo, deberá restaurarla desde cero. La primera fase de cualquier secuencia de restauración es crear los datos y los archivos de registro si no existen.
Puede hacer que la creación de archivos de datos sea casi instantánea habilitando la inicialización instantánea de archivos que omite la inicialización cero pero que no se aplica a los archivos de registro. Esto significa que la restauración tiene que crear todos los archivos de registro que existían cuando se realizó la copia de seguridad completa (o se crean durante el período de tiempo cubierto por una copia de seguridad del registro de transacciones) e inicializarlos en cero. Si creó un segundo archivo de registro y se olvidó de soltarlo nuevamente, la inicialización en cero durante una operación de recuperación ante desastres se sumará al tiempo de inactividad total. Este no es un problema de rendimiento de la carga de trabajo, pero afecta la disponibilidad del servidor como un todo.
Revertir desde una instantánea de la base de datos
El problema final en mi lista es en realidad un error en SQL Server. Si usa una instantánea de la base de datos como una forma de recuperarse rápidamente a un punto conocido en el tiempo sin tener que restaurar las copias de seguridad (lo que se conoce como revertir desde la instantánea), entonces puede ahorrar mucho tiempo. Sin embargo, hay un gran inconveniente.
Cuando la base de datos se revierte desde la instantánea de la base de datos, el registro de transacciones se vuelve a crear con dos VLF de 0,25 MB. Esto significa que tendrá que volver a hacer crecer su registro de transacciones a su tamaño y número óptimos de VLF (o crecerá automáticamente), con todas las pausas de cero inicialización y carga de trabajo que he discutido anteriormente. Claramente no es el comportamiento deseado.
Resumen
Como puede ver en esta publicación y en mis dos publicaciones anteriores, hay muchas cosas que pueden conducir a un rendimiento deficiente del registro de transacciones, lo que luego tiene un efecto en cadena en el rendimiento de su carga de trabajo general.
Si puede ocuparse de todas estas cosas, tendrá registros de transacciones saludables. Pero no termina ahí, ya que debe asegurarse de que está monitoreando sus registros de transacciones para recibir alertas sobre cosas como el crecimiento automático y las latencias de E/S de lectura y escritura excesivas. Cubriré cómo hacerlo en una publicación futura.
