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.
MANEJO DE LOG TRANSACCIONAL EN SYBASE
En Sybase, el proceso CHECKPOINT tiene como tarea realizar la limpieza de las áreas log de las bases de datos con el parámetro "trunc log on chkpt" habilitado. De esta forma no es necesario preocuparse por limpiar periódicamente el área log.
En caso de no habilitar dicho parámetro, se puede programar en el manejador lo que se conoce como "last chance threshold procedure", el cual monitorea el espacio libre remanente en el área log y en caso de acercarse a un nivel crítico, realiza las tareas que se le hallan programado con el fin de liberar el espacio en dicha área.
El performance se puede ver mejorado si se defíne un área especial en el caché para las áreas log.
Es posible abortar transacciones que llenan un log configurando el parámetro "abort tran on log full".
Antes de empezar a respaldar el area de log a disco, es necesario ejecutar SIEMPRE un respaldo total de la base de datos vía DUMP.
El checkpoint siempre permitirá sincronizar la memoria con el contenido en disco, es decír, bajará de memoria los cambios que se hallan realizado para consolidarlos definitivamente en disco.
SYBASE tiene 3 escenarios o eventos que NO son registrados en el área log : writetext, comandos de select into y bcps.