¿Qué es un registro de transacciones?
Existe un requisito en los sistemas de bases de datos relacionales de que las transacciones deben ser duraderas. Esto es "D" en las propiedades ACID de las transacciones. El sistema debe garantizar que si ocurre un bloqueo repentino, la transacción se puede reproducir. SQL Server cumple con este requisito al capturar todas las transacciones en un archivo físico llamado archivo de registro de transacciones .
En esencia, cada vez que se confirma una transacción, SQL Server registra los cambios producidos por esa transacción en un registro de transacciones. Incluso si la transacción no se ha conservado en el archivo de datos, está disponible en el registro de transacciones y se puede reproducir en caso de un bloqueo repentino.
Modelos de recuperación y registros de transacciones
SQL Server opera bajo tres modelos de recuperación:completo, registro masivo y simple.
En el modo de recuperación completa, se registran TODAS las transacciones. Por lo tanto, la base de datos se puede recuperar por completo si ocurre un bloqueo. Esto también significa que la copia de seguridad de la base de datos se puede restaurar a un momento específico si la transacción o la copia de seguridad relacionada están disponibles. En los modos de recuperación completa y de registro masivo, los registros de transacciones se truncan cada vez que se ejecuta una copia de seguridad del registro.
En el modo de recuperación simple, TODAS las transacciones aún se registran. Sin embargo, la operación del registro de transacciones se trunca cada vez que la base de datos ejecuta el punto de control.
Se produce un punto de control cuando SQL Server escribe búferes sucios en el archivo de datos. Los búferes sucios son páginas esenciales almacenadas en la memoria que han sido modificadas por transacciones, como que el estado de la memoria no coincide con el estado del disco. Sin embargo, no discutiremos esto aquí. En el modo de recuperación simple, SQL Server captura todos estos cambios en el registro de transacciones para conservarlos hasta que persistan.
La estructura del registro de transacciones
El registro de transacciones es un archivo físico visible en la capa del sistema operativo del servidor donde se aloja la base de datos de SQL Server. Cada base de datos tiene un registro de transacciones, pero es posible configurar más. La cuestión es que tener múltiples registros SQL de transacciones no trae ninguna ventaja de rendimiento. SQL Server escribe en el registro de transacciones de forma secuencial:un archivo debe estar lleno antes de que se utilice el siguiente archivo. Sin embargo, varios archivos que se encuentran en discos separados pueden salvar el día si el primer archivo se llena.
Internamente, el archivo de registro de transacciones es una serie de archivos de registro virtuales. El tamaño y la cantidad de esos archivos afectan el tiempo que lleva hacer una copia de seguridad de la base de datos o ponerla en línea. Siempre es una buena idea dimensionar el registro de transacciones correctamente y asegurarse de que la configuración de crecimiento automático se ajuste al nivel de actividad esperado. Entonces los crecimientos de archivos no ocurrirán con demasiada frecuencia.
¿Qué hace crecer el tronco?
Comencemos por crear una pequeña base de datos utilizando el código del Listado 1. El archivo de datos tiene un tamaño de 4 MB, el archivo de registro es de 2 MB para empezar. Sus bases de datos de producción nunca tendrían este tamaño, especialmente con la práctica popular de asignación previa . Elegimos tales tamaños simplemente con fines de demostración.
-- Listing 1: Create a Small Database
create database tranlogexperiment
on primary
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go
En esa base de datos, creamos una sola tabla para las instrucciones adicionales del lenguaje de manipulación de datos (DML) (Listado 2).
-- Listing 2: Create a Table
use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)
Al ejecutar el código del Listado 3, comprobamos y verificamos lo que hemos hecho.
-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';
select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');
Preste atención al Tamaño del archivo columna. Procedemos a invocar el crecimiento del registro de transacciones ejecutando INSERT y DELETE 100 000 veces (Listado 4).
-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000
El Listado 4 inserta una sola fila en el txn_log tabla y elimina la misma fila, repitiendo esta acción 100.000 veces.
En general, la tabla no crece debido a esta actividad, pero el registro de transacciones crece significativamente. Cuando repetimos la consulta en el Listado 3 después de ejecutar la instrucción DML del Listado 4, vemos cuánto ha crecido el registro de transacciones:
El registro de transacciones creció de 4 MB a 40 MB debido a esta actividad a pesar de que el archivo de datos no cambió de tamaño. Esto nos muestra claramente que el tamaño del registro de transacciones tiene poco que ver con el tamaño de los datos. El impacto en el tamaño proviene de la actividad (DML) que ocurre en la base de datos.
¿Cómo gestionamos los registros de transacciones?
Los administradores de bases de datos que administran instancias locales de SQL Server o instalaciones de IaaS deben realizar copias de seguridad de los registros de transacciones con regularidad. Es útil tener configuraciones de recuperación ante desastres como Envío de registros o AlwaysOn AG . Tales configuraciones hacen las copias de seguridad automáticamente.
En el modo de recuperación completa, una copia de seguridad del registro de SQL Server truncará las partes del registro de transacciones que ya no se necesitan para la recuperación. El truncamiento del registro elimina los archivos de registro virtuales inactivos. De esta forma, libera espacio en los registros de transacciones para su reutilización.
El código del Listado 6 muestra el tamaño del registro de transacciones y cuánto espacio libre tenemos en él.
-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name],
name AS [Logical File Name],
type_desc,
size/128.0 AS [Current Size (MB)],
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);
También podemos reducir el registro de transacciones físico utilizando el código del Listado 7. Antes de reducir, asegúrese de tener una copia de seguridad del registro de transacciones. En producción, es mejor programar las copias de seguridad del registro para evitar el crecimiento descontrolado del archivo de registro físico y garantizar que se conserven los datos. Con la opción de recuperación ante desastres como Envío de registros o AlwaysOn AG configurado, esto ya está concedido.
Podemos consultar el log_reuse_wait_desc columna en sys.databases vista de catálogo para determinar las condiciones que impiden que se reduzca el registro de transacciones. Observe que consultamos esta columna en el Listado 3.
Dichas condiciones podrían ser un punto de control pendiente, una copia de seguridad de registro pendiente, una copia de seguridad o restauración en curso, una transacción activa de larga duración y actividades similares en la base de datos.
-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO
Usamos el código del Listado 8 para hacer una copia de seguridad de la base de datos. En nuestro caso particular, primero debemos hacer una copia de seguridad completa porque las copias de seguridad de registros siempre hacen referencia a una copia de seguridad completa. La "última" copia de seguridad completa inicia la cadena cuando se trata de la recuperación de un punto en el tiempo.
-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';
Cuando se ejecuta una base de datos en modo de recuperación simple, el registro de transacciones se trunca en cada punto de control . En este modo, las copias de seguridad de registros no son posibles.
La ubicación del archivo de registro de transacciones debe tener el tamaño adecuado para adaptarse a las transacciones de ejecución prolongada que ocurren ocasionalmente. De lo contrario, el registro de transacciones aún puede llenar el espacio en disco. La figura 4 muestra lo que sucede con el registro interno cuando se realiza una copia de seguridad. Tenga en cuenta que el archivo físico sigue siendo de 40 MB, pero ahora tenemos alrededor de 37 MB de espacio libre.
¿Qué sucede en el modo de recuperación simple?
Ahora, configuremos el tranlogexperiment base de datos al modo de recuperación simple.
-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;
Cuando ejecutamos el código presentado anteriormente en el Listado 4, obtendremos un comportamiento ligeramente diferente.
La Figura 6 muestra el crecimiento del registro de transacciones en el modo de recuperación simple cuando ejecutamos el código del Listado 4. El tamaño del archivo de registro físico es de solo 15 MB. Es la mitad menos de lo que era antes con el modelo de recuperación completa. Además, observe el espacio libre de 11,5 MB.
¿Significa que hubo menos crecimiento de troncos?
No. La Figura 7 muestra que mientras la sesión estaba en ejecución, nuestro SQL Server también realizó varios puntos de control. Esto truncó el registro y dio espacio para que las transacciones reanudaran el registro creciente a intervalos.
Conclusión
El registro de transacciones es un componente increíblemente importante de una base de datos de SQL Server. Afecta a todo lo que requiere o depende de la recuperación:copias de seguridad, restauraciones, recuperación ante desastres, etc. También puede registrar la actividad de la base de datos.
En este artículo, analizamos la naturaleza del registro de transacciones, los aspectos de su administración adecuada y demostramos el comportamiento de DML en bases de datos con modos de recuperación completa o simple. Sin embargo, hay mucho más que aprender sobre el registro de transacciones. Las entradas en las referencias serían un buen punto de partida para usted.
Referencia s
- Registro de transacciones
- Bases de datos y almacenamiento de SQL Server
Leer también
Importancia del registro de transacciones en SQL Server
