INTRODUCCION

En cada base de datos contiene al menos un archivo de datos y un archivo de registro de

transacciones. Todas las bases de datos de SQL Server tienen un registro de transacciones
que registra todas las transacciones y las modificaciones que cada transacción realiza en la
base de datos.
SOCIALIZACIÓN Y EVALUACIÓN DEL MODELO TRANSACCIONAL EN UN MOTOR DE BASES
DE DATOS ESPECÍFICO
En cada base de datos contiene al menos un archivo de datos y un archivo de registro de
transacciones. SQL Server almacena los datos físicamente en el archivo de datos (.mdf y
.ndf). El archivo de transacciones (.ldf) almacena los detalles de todas las modificaciones
que se realizan sobre la base de datos de SQL Server.

La escritura en el Log de transacciones es secuencial, y esta optimizado para ello. Se podría

decir que (por norma general) carece de sentido crear más de un fichero de log de
transacciones. Aunque el algoritmo de escritura en los .ldf es algo más complejo: si
tuviéramos más de un fichero, la escritura la haría formando un bucle circular pasando por
cada uno de ellos, respetando la secuencialidad en las transacciones. A diferencia de los
ficheros de datos, donde si es posible mejorar el rendimiento de una base de datos,
aumentado su número.

Es aconsejable ubicar el fichero del log de transacciones en diferente disco donde se

encuentren los ficheros de datos.

Registro de Transacciones SQL Server:

El principal propósito del Registro de Transacciones SQL Server es asegurar que su base de
datos pueda restaurarse a un estado consistente en el caso de una falla del sistema.
Adicionalmente, es usado para realizar otras funciones como retrotraer cuando un
comando correspondiente es usado y soporta replicación transaccional y soluciones de alta
disponibilidad.
Tenemos tres modos de configurar el log de transacciones: Simple, Full (completo) y, bulk-
logged (recuperación optimizado para cargas masivas de registros).

SQL Server registra información acerca de cada transacción hecha en el registro de

transacciones antes de que los cambios sean escritos a la base de datos. La cantidad de
información registrada depende del modelo de recuperación de su base de datos. El modelo
de recuperación de una base de datos puede cambiarse en cualquier momento. No es
frecuente cambiar de modelo de recuperación. SQL Server ofrece 3 modelos de
recuperación diferentes:

1. Modelo de recuperación COMPLETO:

Este modelo de recuperación registra cada cambio a cada fila así como una copia de
cada página añadida a los índices o tablas. Como tal el registro contiene suficiente
información para poder reconstruir completamente cada acción que ocurrió en la
base de datos, permitiéndole restaurar su base de datos a un punto de tiempo
específico, dado que usted tienen una cadena de registro completa. Todas las
entradas son mantenidas en el registro de transacciones en línea hasta que el
registro es respaldado, después de lo cual sólo las transacciones activas
permanecerán en el registro en línea. Esto significa que para obtener información
 acerca de las transacciones completadas desde el registro, las copias de seguridad
tendrán que ser tomadas en cuenta.

2. Modelo de recuperación POR MEDIO DE REGISTROS DE OPERACIONES MASIVAS:

Cuando usted está usando la opción De recuperación BULK_LOGGED, Todas las
operaciones mínimamente registradas no son escritas en el registro. Las
operaciones mínimamente registradas son operaciones como SELECT INTO, BULK
INSERT y operaciones de Índice. Esencialmente sólo la información suficiente es
registrada para poder deshacer la transacción, pero no para rehacerla. El registro es
manejado en la misma manera que en el modelo de recuperación COMPLETO, y las
transacciones inactivas son movidas a la copia de seguridad del registro cuando una
copia de seguridad es tomada. Por supuesto, la información acerca de las
transacciones masivas no está disponible.
Si la base de datos resulta dañada o se han realizado operaciones masivas desde la
última copia de seguridad completa, se han de repetir los cambios desde esa última
copia de seguridad. Se puede recuperar hasta el final de cualquier copia de
seguridad completa. No admite recuperaciones a un momento dado.

3. Modelo de recuperación SIMPLE:

El modelo de recuperación SIMPLE sólo registra suficiente información para
permitirle recuperar su base de datos. Todas las entradas inactivas del registro son
automáticamente truncadas cuando se pasa un punto de control. Todas las
operaciones todavía son registradas, pero tan pronto como se alcanza el punto de
control el registro es automáticamente truncado, lo que significa que está disponible
para reutilización y las entradas antiguas del registro pueden ser ahora sobrescritas.

SQL Server registra cada evento en una base de datos en mayor o menor grado.

• Cuando una transacción comienza o termina

• Cada update, insert o delete
• Eliminación y creación de tablas e índices
• Grado y página de asignaciones y des asignaciones
• Truncado de tablas
• Todos los bloqueos
• Puede que algunas operaciones sean mínimamente registradas cuando la base de
datos está en los modelos de recuperación simple o por medio de registros de
operaciones masivas, como bcp, BULK_INSERT, SELECT INTO y SELECT … INSERT.
El "set recovery…" es la opción que permite elegir el modelo de recuperación entre simple,
bulk-logged y completo. Los tres permiten realizar restores, pero sólo el modelo de
recuperación completo registra y mantiene en el log de transacciones todas las operaciones
e implica la realización de backups del log dentro de la política de backups. Es la opción por
defecto y la recomendable (salvo circunstancias excepcionales). Ello permite operaciones
como estas (recuperar un backup hasta un punto en el tiempo, hasta una marca). En el
modelo de recuperación simple no es así, las operaciones quedan mínimamente logadas,
los backups del log no pueden realizarse (carecen de sentido).

A modo de ejemplo muestro como cambiar el modelo de configuración del log de

transacciones:

alter database bbdd set recovery simple -- Pone el modelo de recuperación del log a simple
go
alter database bbdd set recovery full -- Pone el modelo de recuperación del log a completa.
go
Si cambias al modelo de recuperación simple, interrumpirá la cadena de copias de
seguridad de registros. Por lo tanto, es muy recomendable realizar una copia de seguridad
del registro inmediatamente antes de realizar el cambio. De esta manera, podrá recuperar
la base de datos hasta ese momento. Tras el cambio, necesitará realizar copias de seguridad
completas y periódicas para proteger sus datos y para truncar la parte inactiva del registro
de transacciones.

El cambio al modelo de recuperación completa o bulk-logged sólo tiene efecto después de

la primera copia de seguridad de base de datos.

backup database TU_bbdd to disk = '<Unida:_ruta> TU_bbdd.bak' with init , NOUNLOAD ,

NAME = N'Copia de seguridad TU_bbdd', NOSKIP , STATS = 10, NOFORMAT

Si no se quieren sobrescribir los ficheros de backup. Muestro un ejemplo, de cómo crear los
backups, teniendo en cuenta el nombre de los ficheros, de esta forma mantendremos una
secuencia en los nombres:

declare @fichero varchar(250)

select @fichero = '< Unida:_ruta>bbdd_tlog_' + convert(varchar(20), getdate(),112) +

left(replace(convert(varchar(10), getdate(), 114), ':', ''), 4) + '.Bak'

backup database TU_bbdd to disk = @fichero with init;

Las copias de seguridad del log de transacciones son un aspecto fundamental de los
modelos de recuperación completa o bulk-logged. Las copias de seguridad de registros
permiten que se trunque el registro de transacciones. Si no realiza la copia de seguridad con
la frecuencia suficiente, el registro de transacciones se puede expandir hasta quedarse sin
espacio en disco. Muestro un ejemplo, de cómo crear los backups del log de transacciones,
teniendo en cuenta el nombre de los ficheros, de esta forma mantendremos una secuencia
en los nombres, por si fuera necesario restaurar, en un punto en el tiempo.

declare @fichero varchar(250)

select @fichero = '< Unida:_ruta TU_bbdd_tlog_' + convert(varchar(20), getdate(),112) +
left(replace(convert(varchar(10), getdate(), 114), ':', ''), 4) + '.trn'

backup log [TU_bbdd] to disk = @fichero

Si cambia del modelo de recuperación completa o bulk-logged al modelo de recuperación

simple, interrumpirá la cadena de copias de seguridad de registros. Por lo tanto, es muy
recomendable realizar una copia de seguridad del registro inmediatamente antes de
realizar el cambio. De esta manera, podrá recuperar la base de datos hasta ese momento.
Tras el cambio, necesitará realizar copias de seguridad periódica para proteger sus datos y
para truncar la parte inactiva del registro de transacciones.

SQL Server ofrece muchos métodos que pueden ser implementados como medidas
preventivas para evitar la necesidad de usar el registro de transacciones SQL Server para
auditar una base de datos. Esto incluye a SQL Server Auditing (SQL 2008 +), los rastros y los
eventos extendidos, por mencionar algunos. La mayoría de estos con excepción del rastro
por defecto, requieren implementación previa a la ocurrencia de un evento.

De todos modos, el registro de transacciones SQL Server siempre está presente y como tal
puede ofrecer información valiosa después de que ocurrió un evento a pesar del hecho de
que no se hizo ninguna configuración avanzada.

En la ausencia de todas las medidas preventivas, poder leer el registro de Transacciones SQL
Server ofrece la habilidad de descubrir quién realizó una transacción específica después del
hecho, así como la habilidad de obtener los valores que han sido modificados con la opción
para retrotraerlos.

Recuperación:
Ya que cada acción es registrada en el registro de transacciones de tal modo que una
transacción puede arrastrarse o retrotraerse, el registro de transacciones SQL Server puede
ser usado para recuperar datos perdidos. Dado que sólo los cambios son registrados y los
datos en el registro no están almacenados en un formato legible para humanos, obtener
esta información del registro no es fácil, pero los datos están disponibles si usted sabe
dónde buscar y cómo leerlos. Más acerca de esto más adelante en este artículo en la sección
acerca de interpretar los datos en fn_dblog y fn_dump_dblog.

Cuando se trata de tener que restaurar una copia de seguridad, sabiendo el punto exacto
en el tiempo en que la base de datos puede ser restaurada para obtener los datos dañados
o perdidos es una enorme ventaja. En lugar de restaurar múltiples copias de seguridad hasta
que encuentre cuál tiene los datos relevantes intactos, usted puede leer el registro de
transacciones para determinar cuándo ocurrió el evento y restaurar al momento preciso
justo antes de que el evento ocurriera.
El registro de transacciones SQL Server es un archivo que usualmente tiene la extensión
.LDF. Aunque es posible tener múltiples archivos de registro para una base de datos, el
registro de transacciones es siempre escrito secuencialmente y múltiples archivos físicos de
registros son tratados como un archivo continuo circular.

SQL Server usa el registro de transacciones para asegurarse de que todas las transacciones
mantienen su estado en caso de una falla de la base de datos o el servidor. Todas las
transacciones son escritas en el Registro de Transacciones antes de ser escritas en los
archivos de datos. Esto es conocido como registro de escritura adelantada.