Cada base de datos de SQL Server contiene uno o más archivos de registro de transacciones además de los archivos de datos. Los archivos de registro registran todas las transacciones y modificaciones de la base de datos realizadas por cada uno de ellos.
Este artículo se centra en el registro de transacciones y cómo SQL Server registra las modificaciones de datos para utilizar los datos para la recuperación de errores de la base de datos.
Introducción al archivo de registro de transacciones de SQL Server
Como recordamos, cada transacción es “todo o nada”. Si una parte de la transacción falla, la transacción completa falla y el estado de la base de datos permanece sin cambios.
SQL Server almacena un registro de cada transacción realizada en la base de datos en el archivo de registro. Si algún desastre implica el apagado de SQL Server, utiliza un registro de transacciones para recuperar la base de datos a un estado consistente con la integridad de los datos.
Después del reinicio, SQL Server inicia el proceso de recuperación de fallas. Lee el archivo de registro de transacciones para garantizar que todos los datos válidos se almacenen en los archivos de datos y que las transacciones no confirmadas se deshagan.
Durante el funcionamiento normal, SQL Server también utiliza el registro de transacciones. La información contenida en el archivo es necesaria para identificar qué debe hacer SQL Server cuando una transacción se revierte debido a un error o a una instrucción ROLLBACK especificada por el usuario.
Cómo utiliza SQL Server el registro de transacciones
El registro de transacciones es un archivo físico con la extensión LDF . SQL Server lo crea automáticamente para cualquier base de datos nueva junto con el archivo de datos principal (.MDF ) que almacena los objetos de la base de datos y los datos mismos.
Cada vez que el código T-SQL cambia un objeto de la base de datos o los datos que contiene, los detalles del cambio se registran como un registro en el archivo de registro de transacciones.
El registro de registro contiene la información de un cambio específico realizado en la base de datos (por ejemplo, insertar una sola fila). Por lo tanto, tendremos una serie de registros para describir completamente los efectos de una sola transacción.
Arquitectura del registro de transacciones
Números de secuencia de registro
Un registro tiene un número de secuencia de registro único que se incrementa automáticamente (LSN ), que nos permite encontrar este registro en el registro de transacciones. LSN describe el cambio de datos y contiene la siguiente información:
- la operación y la fila afectada
- las versiones anterior y nueva de los datos
- la transacción que realizó la modificación
LSN se compone de tres números:
LSN =
Cada página de archivo de datos tiene un LSN en su encabezado de página que identifica el registro de registro más reciente cuyo cambio se refleja en la página. Esto es fundamental para la recuperación de fallas.
Cuando se ejecuta la recuperación de fallas, compara los LSN de los registros de transacciones confirmadas o no confirmadas con los LSN en las páginas de archivos de datos para determinar si hay que rehacer o deshacer en esos registros en particular.
Cuando crea una base de datos, una buena práctica es especificar el tamaño del registro de transacciones . Si no hace esto, SQL Server creará automáticamente el registro de transacciones con el tamaño predeterminado.
El tamaño predeterminado del registro de transacciones de una nueva base de datos es el mayor de 0.5 MB o 25% del tamaño total de todos los archivos de datos creados en la misma sentencia CREATE DATABASE.
Debe tener mucho cuidado porque las nuevas partes del registro de transacciones siempre se inicializan a cero . Si tiene la instrucción CREATE DATABASE sin especificar el tamaño del archivo de registro y crea, por ejemplo, una base de datos de 1 TB, SQL Server creará el registro de transacciones de 250 GB.
Como el registro debe inicializarse en cero, no utiliza la inicialización instantánea del archivo. Esta función se agregó en SQL Server 2005 para permitir que los archivos de datos se creen o crezcan casi instantáneamente.
Podemos ver lo que sucede cuando CREAMOS LA BASE DE DATOS:se produce la inicialización cero de nuestro registro mediante trace flag 3004 que imprime mensajes sobre inicialización cero y trace flag 3605 que permite imprimir esos mensajes de registro mediante el indicador de seguimiento 3004.
La siguiente demostración muestra cómo puede ver cómo se lleva a cabo la puesta a cero del archivo de registro.
1. Ejecute el siguiente script para asegurarse de que no tenemos una base de datos llamada DBTest2014
USE master;
GO
IF DATABASEPROPERTY(N'DBTest2014', N'Version')>0
BEGIN
ALTER DATABASE DBTest2014 SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
DROP DATABASE DBTest2014;
END
GO
2. Habilite las marcas de rastreo para ver la inicialización cero
DBCC TRACEON (3605, 3004, -1);
GO
3. Flush the error log
EXEC sp_cycle_errorlog;
GO
3. Crea una base de datos
CREATE DATABASE DBTest2014 ON PRIMARY (
NAME = N'DBTest2014',
FILENAME = N'D:\DBTest2014_data.mdf')
LOG ON (
NAME= N'DBTest2014_log',
FILENAME= N'D:\DBTest2014_log.ldf',
SIZE = 10MB,
FILEGROWTH = 10 MB);
GO
4. Lea el archivo de registro de errores
EXEC sys.xp_readerrorlog;
GO
Archivos de registro virtuales
El registro de transacciones se divide internamente en una serie de fragmentos denominados archivos de registro virtuales. (VLF ) para simplificar la gestión.
Cada vez que se crea un registro de transacciones, proporciona una cierta cantidad de VLF. Los VLF recién creados están inactivos y sin usar. Un VLF activo no se puede reutilizar hasta que se deshabilite borrando el registro.
Sin embargo, hay una excepción:el primer VLF en una nueva base de datos siempre está activo porque cualquier registro de transacciones debe tener al menos un VLF activo.
Cada archivo de registro también tiene una página de encabezado de archivo que ocupa 8KB al comienzo del archivo de registro de transacciones. La página de encabezado del archivo almacena metadatos sobre el archivo, como el tamaño y la configuración de crecimiento automático.
SQL Server determina la cantidad y el tamaño de los VLF en una nueva parte del registro de transacciones. Es imposible configurarlo.
Si el tamaño recién agregado es:
- <1 MB es irrelevante para la discusión
- <64 MB habrá 4 VLF nuevos (cada 1/4 del tamaño de crecimiento)
- 64 MB a 1 GB habrá 8 VLF nuevos (cada 1/8 del tamaño de crecimiento)
- > 1GB habrá 16 VLF nuevos (cada uno 1/16 de tamaño de crecimiento)
Esto se aplica al registro de transacciones creado inicialmente y para cada crecimiento manual o automático que se produzca. Cuando conoce la fórmula del número potencial de VLF y su tamaño potencial, ayuda a administrar el registro. Muy pocos o demasiados VLF pueden causar problemas de rendimiento con las operaciones del registro de transacciones.
Número de secuencia VLF
Cada VLF tiene un número de secuencia para identificar de forma única el VLF dentro del registro de transacciones. El número de secuencia aumenta en uno cada vez que el sistema de gestión de registros activa el siguiente VLF. La cadena de números de secuencia proporciona el conjunto de VLF actualmente activo.
El inicio de la parte activa del registro de transacciones comienza con un VLF que tiene el número de secuencia más bajo y aún está activo. Los VLF inactivos tienen números de secuencia, pero no forman parte de la parte activa del registro.
La parte activa del registro tiene registros que SQL Server requiere por algún motivo.
Cuando crea una nueva base de datos por primera vez, los números de secuencia de VLF no comienzan en 1. Comienzan con el número de secuencia de VLF más alto que se encuentra en el registro de transacciones de la base de datos modelo, más 1. . Es imposible quedarse sin números de secuencia VLF. SQL Server tiene un código que forzará el cierre de la instancia si un número de secuencia VLF llega a cero (si el siguiente número de secuencia VLF es menor que el anterior).
VLF y bloques de registro
Dentro de los VLF, hay bloques de registro de tamaño variable. El tamaño mínimo del bloque de registro es 512 los bytes y los bloques de registro crecen hasta un tamaño máximo de 60 KB . El tamaño se establece cuando ocurre uno de los siguientes casos:
- Una transacción genera un registro para confirmar o terminar de abortar una transacción
- El tamaño del bloque de registro alcanza los 60 KB sin que se confirme o cancele una transacción
Hay registros de registro dentro de un bloque de registro (coloreados en el diagrama). Los registros de registro también tienen un tamaño variable. El diagrama muestra que los registros de varias transacciones simultáneas pueden existir dentro del mismo bloque de registro. Los registros de registro se almacenan en el orden escrito de manera similar a un archivo de página de datos.
Cada VLF contiene un encabezado VLF con la siguiente información:
- Si el VLF está activo o no.
- El número de secuencia de registro cuando se creó el VLF.
- Los bits de paridad actuales para todos los bloques de 512 bytes en el VLF.
Los bits de paridad comienzan en 64 por primera vez en el uso de VLF. Si VLF se vuelve inactivo, pero se vuelve a reactivar, los bits de paridad se convertirán en 128. Estos se utilizan durante la recuperación de fallas.
Examinar los detalles del registro de transacciones:DBCC LOGINFO
La única forma de ver la estructura del registro de transacciones es usar el DBCC LOGINFO no documentado dominio. La sintaxis del comando es:
DBCC LOGINFO [({'dbname | dbid'})]Si no especifica dbname y dbid , le volcará el contenido del registro de la base de datos actual.
El resultado es una fila para cada VLF que se encuentra en el registro de transacciones de esa base de datos. Los campos devueltos son:
- Id. de unidad de recuperación — agregado en SQL Server 2012 pero actualmente sin usar
- Id. de archivo — ID del archivo de registro de transacciones dentro de una base de datos.
- Tamaño de archivo — Tamaño de VLF en bytes.
- Desplazamiento inicial — desplazamiento inicial del VLF en el archivo de registro de transacciones, en bytes
- FSeqNo — El número de secuencia VLF
- Estado — Si el VLF está activo o no (0 =inactivo, 2 =activo, 1 – no se usa)
- Paridad — bits de paridad actual (64 o 128, o 0 si el VLF nunca ha estado activo)
- Crear LSN — el LSN cuando se creó el VLF (0 =el VLF se creó cuando se creó inicialmente el archivo de registro de transacciones). Todos los demás VLF agregados después de la creación inicial del archivo de registro de transacciones tendrán CreateLSN distinto de cero.
Podemos ejecutar el siguiente comando para el DBTest2014 base de datos, que hemos creado anteriormente:
DBCC LOGINFO (N'DBTest2014');
GO
Ver el resultado:
DBCC SQLPERF (ESPACIO DE REGISTRO)
La única forma en Transact-SQL de examinar la cantidad del registro utilizado es DBCC SQLPERF. La sintaxis del comando es:
DBCC SQLPERF
(
[ LOGSPACE ]
|
[ "sys.dm_os_latch_stats" , CLEAR ]
|
[ "sys.dm_os_wait_stats" , CLEAR ]
)
[WITH NO_INFOMSGS ]
El comando devuelve un conjunto de resultados con una fila por base de datos:
- Nombre de la base de datos
- Tamaño del registro (MB)
- Espacio de registro utilizado (%)
- Estado:siempre establecido en cero
En mi entorno, el siguiente comando:
DBCC SQLPERF (LOGSPACE);
GO
Devuelve el siguiente resultado:
En el próximo artículo, examinaremos los registros.
