Es muy común que el concepto de log transaccional no sea comprendido a la primera. Este artículo describe dicho concepto y realiza recomendaciones en su uso
El concepto básico de un log transaccional es aquel que la define como aquella tabla de la base de datos donde todos los cambios a los datos son registrados.
El uso de areas log tiene como fundamento el concepto transaccional. Todos los manejadores de datos deben controlar las transacciones de los usuarios como unidades de trabajo, y en general se entiende como una transacción el conjunto de uno o mas comandos de insert-update-delete que se realizan de forma exitosa o fallida como unidad.
Una transacción se puede delimitar por medio de comandos begin transaction y commit transaction según cada manejador. Esto permíte garantizar la consistencia y la posibilidad de recuperación.
Cada base de datos maneja su propia área log, en la cual automáticamente se registra cualquier transacción. No debe ser posible evitar este registro de ninguna forma.
La mayoria de los esquemas de administración de log se manejan por medio del método de "escritura adelantada" (write ahead en inglés). Cuando un usuario modifica los datos, el manejador escribe los cambios primero en el área log, y una vez que se han completado, los graba en los datos correspondientes que se encuentran en el caché o memoria del manejador, para después ser grabados definitivamente a disco. El manejador siempre escribirá un registro de "fin" al concluír cada transacción, indicando si ésta fué fallida o exitosa.
COMO DETERMINAR EL ESPACIO ASIGNADO A LAS AREAS LOG?
Este espacio está determinado principalmente por 2 aspectos:
1. El volumen de transacciones para actualización en la base de datos.
2. La frecuencia con la que se limpiará el área log.
Como una regla no escrita, siempre el área log equivale a un aproximado de 10-25% del tamaño predefinido para el área de datos. Los comandos DML (insert, update, delete) siempre ocupan espacio de log. Los comandos de limpieza DUMP extraen el contenido del area log (las transacciones terminadas con COMMIT) y lo guardan en un archivo en disco.
Usualmente los comandos UPDATE requieren conservar en log la imagen de "antes" y "después" de un registro, así que para transacciones de update se debe contemplar al menos el doble del tamaño del numero de registros a actualizar, o el doble del tamaño de la tabla mas grande de la base de datos. Como tip, se recomienda realizar UPDATEs en pequeños grupos o batch, entre los cuales se puede realizar el DUMP del área log.
RECOMENDACIONES.
Las bases de datos se componen básicamente de datos y log. Hay que procurar, en lo posible y si la configuración del equipo lo permíte, crearlos en dispositivos físicos separados. Esto es muy útil en escenarios de recuperación de bases de datos después de una falla general, y para un óptimo tiempo de respuesta.
Es recomendable generar un esquema periódico de limpieza de log, y más aún si se trata de un ambiente altamente transaccional.
¿Qué es un registro de transacciones?Un registro de transacciones es un archivo – parte integral de toda base de datos SQL Server. Contiene registros producidos durante el proceso de registro en una base de datos SQL Server. El registro de transacciones es el componente más importante de una base de datos SQL Server cuando se trata de recuperaciones de desastres – sin embargo, debe estar no corrupto. Después de cada modificación de la base de datos – ocurrencia de transacción, un registro es escrito en el registro de transacciones. Todos los cambios son escritos secuencialmente.
¿Qué almacena un registro de transacciones SQL Server?
Un registro de transacciones almacena cada transacción hecha a una base de datos SQL Server, excepto algunas que son mínimamente registradas como BULK IMPORT o SELECT INTO. Internamente está dividido en partes más pequeñas llamadas Archivos de Registros Virtuales (Virtual Log Files, VLFs). Cuando un VLF se llena, el registro continúa en el siguiente registro de transacciones disponible. El archivo de registro de transacciones puede ser representado como un archivo circular. Cuando el registro llega al final del archivo, inicia de nuevo desde el principio, pero sólo si todos los requerimientos han sido cumplidos y las partes inactivas han sido truncadas. El proceso de truncar es necesario para marcar todas las partes inactivas de modo que puedan ser usadas de nuevo y sobrescritas.
Un registro ya no es necesario en el registro de transacciones si todos los siguientes son verdaderos:
- La transacción de la que es parte se ha enviado
- Las páginas de la base de datos que cambió han sido todas escritas un disco por un punto de control
- El registro no es necesario para una copia de seguridad (completa, diferencial o de registro)
- El registro no es necesario para ninguna característica que lee el registro (como bases de datos en espejo o replicación) [1]
El registro lógico es una parte activa del registro de transacciones. Un Log Sequence Number (LSN) identifica cada transacción en el registro de transacciones. EL MiniLSN es el punto de partida de la transacción activa más antigua en el registro de transacciones en línea.
Disponibilidad Laboral: FullTime
