¿Que es un log de transacciones en un SGBD?

El concepto básico de un log transaccional es aquel que la define como las tabla(s) de la base de datos, donde son registrados todos los cambios a los datos.

Toda transacción SQL como insert, update, delete, se deben guardar en la tabla(s) de logs, con el propósito de contar con un repositorio de datos que permita contar con los mecanismos de  auditoria e identificar los cambios realizados a la información por parte de los usuarios que interactúan con el sistema de información.

Para las transacciones de tipo Update se requiere guardar en el log el estado antes y después del estado de la información.

Las tablas encargadas de registrar los logs de las transacciones deben permitir:

• Identificar a los diferentes usuarios que interactúan con el sistema.
• La fecha y hora en que los usuarios realiza la transacción, de tal forma de hacerlos responsables por las acciones que ellos realizan en los aplicativos que interactúan con la base de datos.

Existen dos alternativas para registrar en las tablas los logs de las transacciones ejecutadas:

• La primera es llenar las tablas  mediante el aplicativo, esto significa mucho esfuerzo en programación, especialmente cuando existen cambios en la Base de Datos.
• La segunda alternativa es llenar las tablas mediante el diseño de triggers, esta opción tiene la ventaja de ser independiente del aplicativo y las tablas se llenarán ya sea cuando se haga modificaciones directamente mediante sentencias SQL o mediante opciones de menú o comandos del aplicativo.

¿Que es lo recomendable?

Se recomienda utilizar el diseño de trigger. Esto debido a que se ejecutan cuando sucede un evento como Insert, Delete, Update y se disparan antes (Before) y/o después (After) de que la información sea modificada y con ello evitar la implementación a nivel de aplicación.

El control de los logs a través de trigger permite registrar las transacciones realizadas mediante la base de datos como de los aplicativos.

¿Que esquema de log utilizar?

La estructura  de los trigger  a utilizar para registrar los logs de las transacciones en las  tablas   de auditoria, antes de que la información sea modificada  es el siguiente:

Descripción del esquema logs

Breve descripción del significado de los campos que componen el esquema del logs de transacciones para una tabla

Importancia de un Log Transaccional

Un Log Transaccional es una parte vital de la base de datos y muy importante para poder tener un sistema saludable. En el Log de Transacciones se guardan todas y cada una de las transacciones que se realizan en la base de datos, el explicar lo que es una transacción en base de datos sera otro post completo y dedicado a explicarlas, pero por ahora debe quedar claro que el log de transacciones es el que asegura que una transacción tenga la propiedad ACID (Atomicity, Consistency, Isolation and Durability), debido a que cuando se modifica un dato en la base de datos, lo primero que se hace para asegurar que la transacción ha sido confirmada es escribir en el log de transacciones los cambios realizados por la transacción, una vez realizado esto recién se puede decir que la transacción esta completada, esta es la única manera de asegurar que una transacción sea durable en el tiempo, porque si ocurriese un problema justo después de hacer «commit» a una transacción, el log de transacciones es el único medio que tiene la base de datos para poder reproducir los cambios en los archivos de datos de la base de datos.

El log de transacciones se maneja dependiendo del modelo de recuperación que tenga configurado la base de datos. Se debe tener en claro que los registros dentro de log de transacciones manejan estados (activo / inactivo), de esta manera se identifica los registros que ya no son útiles y se  pueden sobrescribir, o de los cuales se pueden reclamar espacio en disco. Si no hay espacio libre o registros inactivos para que el log de transacciones pueda escribir sobre ellos, entonces el este crecerá un determinado numero de bytes, este crecimiento es costoso en términos de performance. De esto podemos derivar la conclusión de que el log de transacciones tiene un comportamiento cíclico, es decir que cuando llega al final de archivo buscara  espacio libre al inicio para poder seguir escribiendo las transacciones de la base de datos.

Como ya hemos mencionado el log de transacciones tiene la habilidad de crecer pero hasta que tamaño o en que proporción, puede ser configurable, dependiendo del SGBD que se este utilizando. Como ejemplo, un log puede estar configurado para crecer ilimitadamente (columna «maxsize») y que ademas dicho crecimiento automático del 10% del tamaño del log, es decir que la proxima vez que necesite crecer el log de transacciones, este crecerá en un 10% del tamaño actual. Esta configuración no es muy optima porque el log de transacciones no debe de crecer tan seguido, entonces para evitar eso debemos colocar un valor fijo y no un porcentaje, el valor fijo que coloquemos debe ser suficiente como para aguantar la llegada de todas las transacciones de la base de datos sin necesidad de volver a crecer automáticamente y volver a golpear la performance de la base de datos.

Otra de las características del log de transacciones es que su método de escritura es secuencial es decir va en un orden predeterminado, no es como un archivo de datos de una base de datos que escribe la data en forma aleatoria según la ubicación de las paginas de datos. El log de transacciones al ser un archivo de escritura secuencial es mas rápido en cuanto a escritura de disco concierne porque la aguja del disco duro no debe moverse aleatoriamente, sino que esta solo debe moverse en una dirección hasta que se llegue al final del archivo y se necesite aplicar el comportamiento cíclico del archivo y se regrese al inicio del archivo para seguir ingresando transacciones.