Estoy tratando de reunir algunos conocimientos sobre bases de datos SQL y tengo algunas preguntas sobre el archivo de registro de transacciones (LDF).
En primer lugar, cuando crea una base de datos, debe definir un Tamaño de archivo inicial tanto para la base de datos como para el archivo de registro. Por lo que puedo ver, una vez que los archivos se crean en el disco, tendrán el tamaño especificado, independientemente de si hay datos reales en la base de datos o si ha habido alguna transacción (registro).
Mi entendimiento fue que respaldar una base de datos:
- Trunca el registro de transacciones y
- Reduce el tamaño
del archivo LDF en el disco "vaciando" los registros dentro de él.
Ahora parece que no estaba entendiendo esto correctamente porque el archivo de registro parece ser de tamaño fijo. Mi pregunta real es así:
¿Qué hacen realmente los registros truncados al archivo de registro (LDF)? Se supone que este proceso evita que los discos se llenen.
Por favor, corríjame si no entiendo algunos conceptos correctamente.
¡Gracias!
fuente
Emparejar y mezclar
Hacer una copia de seguridad del registro de transacciones no es lo mismo que truncar el archivo de registro de transacciones, y truncar el archivo de registro de transacciones no es lo mismo que reducir el archivo de registro de transacciones. Ah, sí, y hacer una copia de seguridad del archivo de registro de transacciones no tiene que desencadenar un truncamiento. Dependiendo de la carga actual, el motor de la base de datos podría decidir establecer un punto de control, pero esperar un poco con el truncamiento.
Explicando
El archivo de registro de transacciones es donde el motor de la base de datos almacena las modificaciones realizadas a los datos en una base de datos, independientemente de si la base de datos está en el modelo de recuperación SIMPLE o en el modelo de recuperación COMPLETO. (Importante)
Ahora el archivo de registro de transacciones de la base de datos no es solo un contenedor de almacenamiento continuo, sino una colección de archivos de registro virtuales (VLF) que se crean en un orden secuencial dentro del archivo de registro de transacciones (TLog). El tamaño de los VLF varía según la versión de SQL Server que esté utilizando actualmente y también según el tamaño inicial que seleccionó durante la creación del archivo TLog y también el tamaño que seleccionó (si corresponde) para la configuración de crecimiento automático de TLog archivo.
Referencias:
- Cambio importante en el algoritmo de creación de VLF en SQL Server 2014 (SQLSkills.com)
- Números de secuencia de VLF iniciales y tamaño de archivo de registro predeterminado (SQLSkills.com)
- Dentro del motor de almacenamiento: más sobre la naturaleza circular del registro (SQLSkills. com)
... y tal vez en el orden inverso
Cuando los datos se modifican en la base de datos, el Motor de base de datos escribirá estos cambios en el TLog de la base de datos correspondiente para mantener la coherencia transaccional. Esto también se conoce como ACID: atomicidad, consistencia, aislamiento, durabilidad . Las transiciones reales de estos cambios se almacenan en los VLF del TLog (archivo). Cuando un VLF está lleno, las transacciones más recientes se almacenarán en el siguiente VLF disponible en orden secuencial.
Excepciones
Sin embargo, si se alcanza el final del archivo TLog, las modificaciones se almacenarán en el primer VLF al comienzo del archivo TLog. (explicado en Inside the Storage Engine: más sobre la naturaleza circular del registro )
Cuando no hay VLF disponibles para almacenar nuevas transacciones y si la configuración de crecimiento automático está configurada, el Motor de base de datos hará crecer el archivo TLog en la cantidad definida y creará VLF adicionales dependiendo del tamaño definido en la configuración de crecimiento automático y la fórmula explicado en Cambio importante al algoritmo de creación de VLF en SQL Server 2014 . Luego se pueden almacenar más transacciones en el próximo VLF dentro del archivo TLog.
Copia de seguridad del archivo TLog
Cuando activa una copia de seguridad del archivo TLog, todo lo que está haciendo es decirle al motor de la base de datos que
Hasta ahora no se ha liberado espacio dentro del archivo TLog para que el motor de la base de datos pueda reutilizar ...
Truncamiento automático del archivo TLog
... pero si el Motor de base de datos tiene algunos ciclos libres y no está bajo una presión muy alta, ocasionalmente echará un vistazo al archivo TLog, notará el Punto de control y liberará los VLF para su reutilización. El espacio dentro del archivo TLog todavía es utilizado por los VLF (mismo tamaño, misma ubicación) pero son libres de ser reutilizados.
Esto se documenta en el truncamiento del registro de transacciones :
Hay algunos casos en que esto no sucede:
Visualizar el truncamiento de registros
Se puede observar el truncamiento del registro cuando se consulta el tamaño de TLog mediante declaraciones SQL o el informe del Espacio de base de datos en la IU de SSMS. Puede observar que el espacio utilizado dentro del archivo TLog podría ser solo el 1% del tamaño del archivo TLog disponible.
Reducir o no reducir
La recomendación general es no reducir el archivo TLog, porque creció por una cierta razón y posiblemente volverá a crecer hasta el tamaño que alguna vez fue. Pero esa es una historia para otra publicación. Hay algunas buenas razones, una es cuando está recreando el tamaño de los VLF dentro de su archivo TLog.
Contestando tus preguntas
Inline justo debajo de sus suposiciones y preguntas
Esta es una suposición equivocada. Hacer una copia de seguridad de su base de datos (COMPLETO, DIFERENCIAL) no hace nada con los archivos TLog. Una copia de seguridad COMPLETA creará un estado consistente de su base de datos junto con las transacciones confirmadas del archivo TLog. Una copia de seguridad DIFF creará un estado consistente de todas las copias de seguridad TLog pasadas desde la última copia de seguridad COMPLETA de su base de datos.
Sin embargo, una copia de seguridad de TLOG creará una copia de seguridad de las transacciones confirmadas del archivo TLog, establecerá un punto de control y posiblemente (cuando no esté bajo una carga pesada) liberando los VLF para su reutilización.
No, al considerar las copias de seguridad COMPLETAS y DIFF. No, al considerar las copias de seguridad de TLOG, pero liberará los VLF dentro del archivo TLog, si el motor de la base de datos tiene tiempo de sobra.
Truncar los registros permite reutilizar los VLF. Eso es todo.
Este proceso puede tener la ventaja de evitar que el archivo TLog crezca SI se han establecido configuraciones de crecimiento automático.
Si no se ha establecido una configuración de crecimiento automático , porque su proceso de ingeniería de requisitos determinó que el archivo TLog tendría un tamaño fijo, entonces el peor de los casos aquí es que el TLog se llena porque no se produce una copia de seguridad de TLog y, por lo tanto, no se liberan VLF. El TLog no puede crecer y los VLF no se liberan para permitir que se escriban más transacciones en el archivo TLog (o VLF internamente).
fuente
Si bien Brent Ozar ya le ha dado una explicación sobre cómo se ve el archivo de registro de transacciones, me centraré en ciertas preguntas
La copia de seguridad completa no hace nada en los registros de transacciones en ningún modelo de recuperación. En el modelo de recuperación completa, cuando realiza una copia de seguridad del registro de transacciones, trunca el registro. Tenga en cuenta que si una transacción de larga duración todavía está allí con los VLF o según la explicación de Brent todavía necesita los cajones, otra transacción no puede reutilizar el cajón o, en términos técnicos, no se truncaría para que se pueda reutilizar.
Tampoco reduce el registro de transacciones. Para reducir los registros, debe usar el
dbcc shrinkfilecomandoHace que el archivo de registro sea reutilizable para que otras transacciones puedan usarlo o, según la analogía de Brent, otra persona puede usar los cajones para guardar cosas allí.
Después de analizar la respuesta, le recomiendo que lea sobre el registro de transacciones en SQLSKILLS.com
fuente