sql >> Base de Datos >  >> RDS >> Sqlserver

Importancia del registro de transacciones en SQL Server

Los registros de transacciones son un componente vital e importante de la arquitectura de la base de datos. En este artículo, analizaremos los registros de transacciones de SQL Server, su importancia y su función en la migración de la base de datos.

Introducción

Hablemos de las diferentes opciones para realizar copias de seguridad de SQL Server. SQL Server admite tres tipos diferentes de copias de seguridad.
1. Completo
2. Diferencial
3. Registro de transacciones

Antes de saltar a los conceptos de registro de transacciones, analicemos otros tipos básicos de copias de seguridad en SQL Server.

Una copia de seguridad completa es una copia de todo. Como su nombre lo indica, hará una copia de seguridad de todo. Hará una copia de seguridad de todos los datos, cada objeto de la base de datos, como un archivo, un grupo de archivos, una tabla, etc.:– Una copia de seguridad completa es la base para cualquier otro tipo de copias de seguridad.

Una copia de seguridad diferencial hará una copia de seguridad de los datos que han cambiado desde la última copia de seguridad completa.

La tercera opción es una copia de seguridad del registro de transacciones, que registrará todas las declaraciones que emitimos a la base de datos en el registro de transacciones. El registro de transacciones es un mecanismo conocido como “WAL” (Write-Ahead-Logging). Primero escribe cada pieza de información en el registro de transacciones y luego en la base de datos. En otras palabras, el proceso normalmente no actualiza la base de datos directamente. Esta es la única opción completa disponible con el modelo de recuperación completa de la base de datos. En otros modelos de recuperación, los datos son parciales o no hay suficientes datos en el registro. Por ejemplo, la entrada de registro al registrar el inicio de una nueva transacción (la entrada de registro LOP_BEGIN_XACT) contendrá la hora en que comenzó la transacción, y las entradas de registro LOP_COMMIT_XACT (o LOP_ABORT_XACT) registrarán la hora en que se confirmó (o canceló) la transacción.

Para encontrar las partes internas del registro de transacciones en línea, puede consultar la función sys.fn_dblog.

La función del sistema sys.fn_dblog acepta dos parámetros, primero, comienza el LSN y finaliza el LSN de la transacción. De forma predeterminada, se establece en NULL. Si se establece en NULL, devolverá todos los registros del archivo de registro de transacciones.

USE WideWorldImporters
GO
SELECT [Current LSN],
[Operation],
[Transaction Name],
[Transaction ID],
[Log Record Fixed Length],
[Log Record Length]
[Transaction SID],
[SPID],
[Begin Time],
*
FROM fn_dblog(null,null)

Como todos sabemos, las transacciones se almacenan en formato binario y no en un formato legible. Para leer el archivo de registro de transacciones fuera de línea, puede usar fn_dump_dblog.

Consultemos el archivo de registro de transacciones para ver quién ha soltado un objeto usando fn_dump_dblog.

SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], SUSER_SNAME ([Transaction SID]) AS DBUser
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
Context IN ('LCX_NULL') AND Operation IN ('LOP_BEGIN_XACT')
AND [Transaction Name] LIKE '%DROP%'

Usaremos la función fn_dblog() para leer la parte activa del registro de transacciones para encontrar la actividad que se realiza en los datos. Una vez que se borra el registro de transacciones, debe consultar los datos de un archivo de registro mediante fn_dump_dblog().

Esta función proporciona el mismo conjunto de filas que fn_dblog(), pero tiene una funcionalidad interesante que la hace útil en algunos escenarios de solución de problemas y recuperación. Específicamente, puede leer no solo el registro de transacciones de la base de datos actual, sino también las copias de seguridad del registro de transacciones en disco o cinta.

Para obtener la lista de los objetos que se descartan mediante el archivo de transacciones, ejecute la siguiente consulta. Inicialmente, los datos se vuelcan en la tabla temporal. En algunos casos, la ejecución de fun_dump_dblog() tarda un poco más en ejecutarse. Por lo tanto, es mejor capturar los datos en la tabla temporal.

Para obtener un ID de objeto de la columna Información de bloqueo, ejecute la siguiente consulta.

SELECT * INTO TEMP
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
[Transaction ID] in(
SELECT DISTINCT [Transaction ID]
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
[Transaction Name] LIKE '%DROP%')
and [Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%'

Para obtener un ID de objeto de la columna Información de bloqueo, ejecute la siguiente consulta.

SELECT DISTINCT [Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4,
Substring([Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4) objectid
from temp

El object_id se puede encontrar manipulando el valor de la columna Información de bloqueo. Para encontrar el nombre del objeto para la identificación del objeto correspondiente, restaure la base de datos desde la copia de seguridad justo antes de que se elimine la tabla. Después de la restauración, puede consultar la vista del sistema para obtener el nombre del objeto.

USE AdventureWorks2016;
GO
SELECT name, object_id from sys.objects
WHERE object_id = '1815677516';

Ahora, veamos las diferentes formas de los mismos detalles de transacción usando sys.dn_dblog, sys.fn_full_dblog. La función del sistema fn_full_dblog solo funciona con SQL Server 2017.

Consulta para obtener las 10 transacciones principales usando fn_dblog.

SELECT TOP 10 * FROM sys.fn_dblog(null,null)

Desde SQL Server 2017 en adelante, puede usar fn_full dblog.

SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)

Puede profundizar más en la función del sistema utilizando sp_helptext fn_full_dblog.

A continuación, consulte el archivo de respaldo usando la función del sistema usando fn_full_dblog. Nuevamente, esto es aplicable solo desde SQL Server 2017 en adelante.

Restauración de un momento dado

Supongamos que tiene la lista de la copia de seguridad de registro completa y, luego, cuando tiene la intención de restaurar los registros, tiene la posibilidad de realizar una restauración de los datos en un momento dado. Por lo tanto, en el proceso de restauración de registros, no necesariamente necesita restaurar todos los datos, puede restaurarlos justo antes o después de cualquier transacción individual. Por lo tanto, si la base de datos falla en un momento específico y tenemos una copia de seguridad completa y copias de seguridad de registros, deberíamos poder restaurar primero la copia de seguridad completa y luego restaurar la copia de seguridad de registros y, en el proceso, restaurar el último registro hasta un momento determinado. , y eso dejaría la base de datos en el estado exacto en que estaba antes de que ocurriera este problema.

Las copias de seguridad de registros son VLDB (base de datos muy grande) bastante comunes y las bases de datos más críticas. Siempre se recomienda probar el proceso de restauración. Siempre que realice copias de seguridad de la base de datos, se recomienda pensar bien en el proceso de restauración, y siempre debe probar el proceso de restauración con más frecuencia.

Siempre es bueno aliviar la prueba del proceso de restauración de vez en cuando, así que asegúrese de que el proceso se realice con normalidad a través de las copias de seguridad.

Escenarios

Hablemos de un escenario, cuando necesita restaurar una base de datos muy grande y todos sabemos que normalmente puede llevar varias horas, y eso es algo que todos deberían tener en cuenta. Si está planeando una migración de base de datos sin pérdida de datos y ventanas de interrupción más pequeñas, eso podría ser un problema bastante grande. Así que asegúrese de confiar en la copia de seguridad del registro de transacciones para acelerar el proceso.

Consideremos otro escenario en el que está realizando una migración de base de datos en paralelo entre dos versiones diferentes de SQL Server; está involucrado en la migración de la base de datos a la misma versión de software en el destino y eso incluye la transferencia del sistema operativo, la base de datos, la aplicación y la red, etc.:-; migrar la base de datos de una pieza de hardware a otra; cambiar tanto el software como el hardware. El proceso de migración de la base de datos siempre es un desafío donde la pérdida de datos siempre es posible y está sujeta al medio ambiente.

Prácticas recomendadas de migración de bases de datos

Analicemos las prácticas estándar de la gestión de migración de bases de datos.

La migración debe realizarse de forma transaccional para evitar inconsistencias en los datos. Los pasos habituales del proceso de migración son convencionalmente los siguientes:

  • Detenga el servicio de aplicaciones:aquí es donde comienza el tiempo de inactividad
  • Inicie la copia de seguridad del registro, depende de sus requisitos
  • Ponga la base de datos en modo de recuperación para que no se realicen más cambios en la base de datos
  • Mover los archivos de registro
  • Restaurar los archivos de registro de transacciones de la base de datos:siempre que haya restaurado la copia de seguridad completa de la base de datos en el destino y deje la base de datos en estado de restauración.
  • Clonar los inicios de sesión y corregir los usuarios huérfanos
  • Crear trabajos
  • Instalar la aplicación
  • Configurar red:cambiar las entradas de DNS
  • Reconfigurar los ajustes de la aplicación
  • Iniciar el servicio de aplicaciones
  • Probar la aplicación

Cómo empezar

En este artículo, discutiremos cómo manejar la migración de bases de datos OLTP muy grandes. Discutiremos estrategias para usar técnicas de servidor SQL y herramientas de terceros para la seguridad de los datos junto con una interrupción mínima o nula de la disponibilidad del sistema de producción. Durante el proceso, siempre existe la posibilidad de perder los datos. ¿Cree que el manejo fluido de las transacciones es una buena estrategia? En caso afirmativo, ¿cuáles son sus opciones favoritas?

Profundicemos en las opciones disponibles:

  • Copia de seguridad y restauración
  • Envío de registros
  • Duplicación de bases de datos
  • Herramientas de terceros

Copia de seguridad y restauración

La técnica de base de datos de copia de seguridad y restauración es la opción más viable para cualquier migración de base de datos. Si se planifica y prueba correctamente, evitaremos muchos errores de migración imprevistos. Todos sabemos que la copia de seguridad es un proceso en línea, es fácil iniciar la copia de seguridad del registro de transacciones de manera oportuna para reducir la cantidad de transacciones que se suministrarán a la nueva base de datos. Durante la ventana de migración, podemos limitar el acceso de los usuarios a la base de datos e iniciar una última copia de seguridad del registro y transferirlo al destino. De esta manera, el tiempo de inactividad se puede reducir significativamente.

Envío de registros

Todos entendemos la importancia de los archivos de registro en el mundo de las bases de datos. La técnica de envío de registros ofrece una buena solución de recuperación ante desastres y admite acceso limitado de solo lectura a bases de datos secundarias, durante el intervalo entre trabajos de restauración. Es esencialmente un concepto de copia de seguridad del registro de transacciones y se reproduce en una copia de seguridad completa en una base de datos secundaria más. Estas bases de datos secundarias son copias duplicadas de la base de datos principal y restauran continuamente las copias de seguridad del registro de transacciones a su propia copia, para mantenerlas sincronizadas con la base de datos principal. Dado que la base de datos secundaria se encuentra en un hardware independiente, en caso de que falle la principal por cualquier motivo, la copia de seguridad completa del sistema está disponible de inmediato para su uso y el tráfico de la red puede simplemente redirigirse al servidor secundario, sin que ningún usuario sepa que existe una base de datos. se ha producido un fallo. El envío de registros proporciona una manera fácil y efectiva de administrar la migración en mayor medida en la mayoría de los casos.

Duplicación

La creación de reflejo de la base de datos también es una opción para la migración de la base de datos siempre que tanto el origen como el destino sean de las mismas versiones y ediciones. Básicamente, la duplicación crea dos copias duplicadas de una base de datos en dos instancias de hardware. Las transacciones ocurrirían en ambas bases de datos simultáneamente. Tiene la capacidad de desconectar una base de datos de producción, cambiar a la versión duplicada de esa base de datos y permitir que los usuarios continúen accediendo a los datos como si nada hubiera pasado. En términos de implementación, tratamos con un servidor principal, un servidor espejo y un testigo. Pero será una función obsoleta y se eliminará de futuras versiones de SQL Server.

Resumen

En este artículo, discutimos los tipos de copias de seguridad, la copia de seguridad del registro de transacciones en detalle, los estándares, el proceso y la estrategia de migración de datos, y aprendimos a usar técnicas de SQL para el manejo efectivo de los pasos de migración de datos.

El mecanismo de escritura del registro de transacciones WAL garantiza que las transacciones siempre se escriban primero en el archivo de registro. De esta manera, SQL Server garantiza que los efectos de todas las transacciones confirmadas finalmente se escribirán en los archivos de datos (en el disco) y que cualquier modificación de datos en el disco que se origine a partir de transacciones incompletas será ROLLBACK y no se reflejará en los archivos de datos.

En la mayoría de los casos, el retraso en la sincronización de datos es imprevisto y la pérdida de datos es permanente. La mayoría de las veces, todo depende del tamaño de la base de datos y la infraestructura disponible. Como práctica recomendada, es mejor ejecutar las migraciones manualmente que como parte de la implementación para mantener las cosas segregadas para que el resultado sea más predecible.

Personalmente, preferiría el envío de registros por varios motivos:puede realizar una copia de seguridad completa de los datos del servidor antiguo con mucha antelación, pasarla al nuevo servidor, restaurarla y luego aplicar las transacciones residuales (copia de seguridad de t-log). ) desde el punto hasta el momento del corte. El proceso es bastante simple.

La migración de la base de datos no es difícil si se hace de la manera correcta. Espero que esta publicación lo ayude a ejecutar las migraciones de la base de datos de una manera más fluida.