Tema 3.5.1.2

// LIC.I. ARANXA ARGENTINA VELAZQUEZ

Las bases de datos son muy importantes para redes corporativas, porque pueden ser usadas en muchos sistemas informáticos, desde contabilidad hasta estadísticas. Si una base de datos deja de funcionar, esto puede resultar en pérdidas. Si no puede ser recuperada en absoluto, estas pérdidas pueden ser muy serias. Las bases de datos son archivos parecidos a otros documentos y pueden ser dañados con facilidad por los virus, todo tipo de software malicioso, fallos del disco duro, errores del sistema de archivos, acciones incorrectas del usuario, etc. En cualquier caso, incluso un pequeño error en este archivo puede resultar en la indisponibilidad de toda la base de datos lo que puede influir en su red corporativa.

La recuperación de las bases de datos consisten en información y estampas de tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un momento y fecha en particular.

Las pruebas de recuperación consisten en la restauración de los datos, después se aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado consistente en un tiempo y momento determinados. Alternativamente se puede restaurar una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de datos.

Propiedades de una transacción

Cada transacción asegura el trabajo de proteger la integridad del estado de un sistema al proveer cuatro garantías básicas conocidas como las propiedades ACID: atomicidad (atomicity), consistencia (consistency), aislamiento (isolation) y durabilidad (durability)

Una transacción tiene que ser atómica lo que significa que es indivisible; todas las operaciones deben ejecutarse o ninguna en lo absoluto. No debe haber posibilidad de que solo una parte se ejecute.

En un sistema bancario, por ejemplo, una transferencia de dinero entre dos cuentas de cheques tiene que ser atómica; tomar dinero de una cuenta para agregarlo a otra. No es posible ejecutar una de las operaciones y la otra no.

Una transacción mantendrá la consistencia de la base de datos. Esto es, si la base de datos se encuentra en un estado consistente antes de ejecutar la transacción, una vez que ésta termine la consistencia de la base de datos deberá conservarse.

En términos de base de datos esto significa que se satisfacen todas las restricciones en cuanto a su integridad que incluyen:

// Todos los valores de la llave primaria son únicos. // La base de datos mantiene integridad referencial lo que significa

que los registros solo referencian información que existe. // Ciertos predicados se mantienen. Por ejemplo, la suma de los

gastos es menor o igual al presupuesto.

Aislamiento (Isolation).

Se dice que un conjunto de transacciones está aislado si el efecto del sistema que las ejecuta es el mismo que si ejecutara cada una a la vez; las transacciones se ejecutan en secuencia.

Tómese, por ejemplo, el caso de un sistema bancario en el que dos transacciones intentaran hacer un retiro de los últimos $200 de una cuenta de cheques. Si se permite que al mismo tiempo, dos transacciones consulten el saldo antes de afectarlo, ambas determinarán que hay fondos suficientes y realizarán el retiro. En cambio, si las transacciones se ejecutan en serie -una detrás de otra-, solo una de las transacciones será capaz de retirar los últimos $200. La siguiente encontrará el saldo de la cuenta en cero. El usuario final tiene la percepción de que su transacción es la única en el sistema.

// Transacción Comprometida

Transacción Abortada

Una transacción que no termina su ejecución con éxito se dice que está abortada

Para asegurar la atomicidad, las transacciones abortadas no deben tener efecto sobre el estado de la base de datos, cualquier cambio que haya hecho la transacción abortada debe deshacerse

Una vez deshechos los cambios de una transacción abortada se dice que la transacción se ha retrocedido

Transacción CompensadoraUna vez que una transacción se ha

comprometido no se pueden deshacer sus efectos abortándola sólo se pueden invertir sus efectos mediante una transacción compensadora

No siempre se puede crear una transacción compensadora asociada a cada transacción a realizar, queda a responsabilidad del usuario.

Una transacción debe estar en uno de los siguientes estados:

// Activa (estado inicial): la transacción permanece en este estado durante su ejecución

// Parcialmente Comprometida: la transacción pasa a este estado cuando acaba de realizar la última instrucción

// Fallida: la transacción pasa a este estado tras descubrir que no puede continuar la ejecución normal

// Abortada: la transacción pasa a este estado después de haber restablecido la base de datos a su estado anterior

// Comprometida: la transacción pasa a este estado tras completarse con éxito

DIAGRAMA DE ESTADOS

TransacciónTerminada

reiniciar o cancelar

• Para poderse recuperar los fallos de transacciones, el sistema mantiene una bitácora (a veces llamada diario ) que sigue la pista a todas las operaciones de transacciones que afecta los valores de elementos de la base de datos.

// La bitácora se mantiene en disco, de modo que no la afecta ningún tipo de fallo, más que los de disco o lo catastróficos.

Además, la bitácora se respalda periódicamente en cinta para protegerse contra fallos catastróficos

// [inicio_de_transacción, T]: Asienta que se ha iniciado la ejecución de la transacción T. // [escribir_elemento,T,X, Valor_anterior,nuevo_valor]: Asienta que la

transacción T cambió el valor del elemento de base de datos X de valor_anterior a nuevo_valor.

// [leer_elemento,T,X]: Asienta que la transacción T leyó el valor del elemento de base de datos X.

// [confirmar,T]: Asienta que la transacción T terminó con éxito y establece que su efecto se

puede confirmar (asentar permanentemente) en la base de datos.

// [abortar,T]: Asienta que se abortó la transacción T.

Los protocolos de recuperación que evitan las reversiones en cascada no requieren que las operaciones LEER se asienten en la bitácora del sistema, pero otros protocolos sí necesitan estas entradas para la recuperación. En el primer casi, el costo extra de asentar las operaciones en la bitácora se reduce, porque en ella se registran menos operaciones, sólo las de ESCRIBIR. Además, los protocolos estrictos requieren entradas ESCRIBIR más simples que no incluyen nuevo _ valor.

También podemos rehacer el efecto de las operaciones ESCRIBIR de una transacción t rastreando hacia delante en la bitácora y cambiando todos los elementos modificados por una operación ESCRIBIR de T a su nuevo _ valor.

Una transacción T llega a su punto de confirmación cuando todas sus operaciones que tienen acceso a la base de datos se han ejecutado con éxito y el efecto de todas estas operaciones se ha asentado en la bitácora.

• Contenido de la bitácora

La bitácora contiene un registro de las modificaciones de los datos en orden cronológico. Las transacciones se escriben en la bitácora, antes de su aplicación a la base de datos. Si el sistema se cae antes de que la transacción haya sido registrada y el momento en que se aplica, en el peor de los casos, existe un registro de una transacción no aplicada. Si las transacciones fueron aplicadas antes de su inclusión en la bitácora, seria posible modificar la base de datos, pero no tener registro del cambio.

• Respaldo Las utilerías de respaldo crean una copia de seguridad de la

base de datos, casi siempre vertiendo toda la base de datos en cinta. La copia de seguridad puede servir para restaurar la base de datos en caso de un fallo catastrófico.

En si, SQL Server no tiene una bitácora donde se registran todos los movimientos que se hacen en las tablas. Aunque si se registra todo lo que haces en el log de transacciones, no tienes acceso visual a esas informaciones, sino que el mismo te servirá para restaurar a un estado anterior tu base de datos. Deberías programar una bitácora.

¿Como? Pues con el siguiente segmento de código: Primero debes crear la tabla AUDIT donde se almacenaran los datos de las acciones llevadas a cabo

por los usuarios en una tabla determinada, en este ejemplo nos enfocaremos en la tabla clientes

• CREATE TABLE [dbo]. [AUDIT] ( • [id_evento] [int] IDENTITY (1, 1) NOT NULL , [tipo_evento] [char] (10) NOT NULL , [fecha] [datetime] NOT NULL ,

[descripcion] [char] (50) NULL , [usuario] [char] (30) NULL ,

[terminal] [char] (30) NULL , [aplicacion] [char] (30) NULL

• ) ON [PRIMARY]

GO ALTER TABLE [dbo]. [AUDIT] WITH NOCHECK ADD CONSTRAINT [PK_AUDIT] PRIMARY KEY NONCLUSTERED ( [id_evento] ) ON [PRIMARY]

GO Luego se crean los tres trigger (insert, update y delete) para la tabla clientes CREATE TRIGGER AUDITdel ON CLIENTES FOR DELETE AS Insert into AUDIT select "Delete", getdate(), "Eliminacion de un registro", SYSTEM_USER, host_name(),APP_NAME() CREATE TRIGGER AUDITins ON CLIENTES FOR INSERT AS insert into AUDIT select "Insert", getdate(), "Insercion de un registro", SYSTEM_USER, host_name(),APP_NAME() CREATE TRIGGER AUDITdel ON CLIENTES FOR UPDATE AS

insert into AUDIT select "Update", getdate(), "Modificacion de un registro", SYSTEM_USER, host_name(),APP_NAME()

// Con esto guardaras información del usuario, la fecha , la aplicación y la acción que se llevo a cabo en dicha tabla.

// el código, es una simple modificación a una tabla llamada AUDIT, a la cual se le esta modificando su PRIMARY KEY, que esta en su columna id_evento.

• CREAR UNA BITACORA EN MYSQL• Con el crecimiento de Internet, y el desarrollo de sistemas de información bajo la

arquitectura Cliente/Servidor, los sistemas de cómputo ,en general, están expuestos a múltiples amenazas, vulnerabilidades y ataques cada vez más complejos. Por lo tanto, es importante que las organizaciones implementen bitácoras (o archivos logs) para almacenar los sucesos que ocurren en el sistema. La información contenida en una bitácora es muy importante y útil cuando ocurre un incidente de seguridad o cuando se realiza una auditoría de sistemas.

Una bitácora puede registrar mucha información acerca de eventos relacionados con el sistema que la genera los cuales pueden ser:

•Fecha y hora. •Host origen. •Usuario. •Actividad realizada.

•La importancia de las bitácoras es la de recuperar información ante incidentes de seguridad, detección de comportamiento inusual, información para resolver problemas, evidencia legal, es de gran ayuda en las tareas de cómputo forense.

• ejemplo de una bitácora desarrollada para la siguiente base de datos de MySQL, llamada proyecto, que tiene las tablas carrera, departamento y maestros.

• CREATE DATABASE proyecto;• USE proyecto

• CREATE TABLE IF NOT EXISTS `carrera` (`clave_carrera` int(11) NOT NULL, `nom_carrera` varchar(20) NOT NULL, `num_depto` int(11) NOT NULL, PRIMARY KEY (`clave_carrera`), KEY `num_depto` (`num_depto`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

• CREATE TABLE IF NOT EXISTS `departamento` ( `num_departamento` int(11) NOT NULL,`nombre_dept` varchar(20) NOT NULL, `jefe_num_tarjet` int(11) NOT NULL, PRIMARY KEY (`num_departamento`), KEY `jefe_num_tarjet` (`jefe_num_tarjet`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

• La estructura de la tabla bitácora sería la siguiente:

• CREATE TABLE IF NOT EXISTS `bitacora` (`id` int(11) NOT NULL AUTO_INCREMENT, `operacion` varchar(10) DEFAULT NULL, `usuario` varchar(40) DEFAULT NULL, `host` varchar(30) NOT NULL, `modificado` datetime DEFAULT NULL, `tabla` varchar(40) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

• La bitácora debe registrar todos los movimientos (insertar, eliminar y modificar) que se realicen en las tablas de la base de datos. Para lograr lo anterior es necesario crear un trigger para que se ejecute después de la operación de insertar, otro para después de eliminar y el último para después de modificar para cada una de las 3 tablas de la base de datos. Los nueve triggers necesarios para que funcione la bitácora son los siguientes:

• DROP TRIGGER IF EXISTS `bit_carr_ins`;DELIMITER //CREATE TRIGGER `bitacora` AFTER INSERT ON `carrera`FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),’@')+1)), SUBSTRING(USER(),1,(instr(user(),’@')-1)), “INSERTAR”, NOW(), “CARRERA”)//

• DROP TRIGGER IF EXISTS `bit_carr_upd`;CREATE TRIGGER `bit_carr_upd` AFTER UPDATE ON `carrera`FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),’@')+1)), SUBSTRING(USER(),1,(instr(user(),’@')-1)), “ACTUALIZAR”, NOW(), “CARRERA”)//

DROP TRIGGER IF EXISTS `bit_carr_del`;CREATE TRIGGER `bit_carr_del` AFTER DELETE ON `carrera`FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),’@')+1)), SUBSTRING(USER(),1,(instr(user(),’@')-1)), “ELIMINAR”, NOW(), “CARRERA”)//

• DROP TRIGGER IF EXISTS `bit_depto_del`;CREATE TRIGGER `bit_depto_del` AFTER DELETE ON `departamento`FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),’@')+1)), SUBSTRING(USER(),1,(instr(user(),’@')-1)), “ELIMINAR”, NOW(), “DEPARTAMENTO”)//

• DROP TRIGGER IF EXISTS `bit_mae_ins`;CREATE TRIGGER `bit_mae_ins` AFTER INSERT ON `maestros`FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),’@')+1)), SUBSTRING(USER(),1,(instr(user(),’@')-1)), “INSERTAR”, NOW(), “MAESTROS”)//

• DROP TRIGGER IF EXISTS `bit_mae_upd`;CREATE TRIGGER `bit_mae_upd` AFTER UPDATE ON `maestros`FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),’@')+1)), SUBSTRING(USER(),1,(instr(user(),’@')-1)), “ACTUALIZAR”, NOW(), “MAESTROS”)//

• DROP TRIGGER IF EXISTS `bit_mae_del`;CREATE TRIGGER `bit_mae_del` AFTER DELETE ON `maestros`FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado, tabla) VALUES (SUBSTRING(USER(), (INSTR(USER(),’@')+1)), SUBSTRING(USER(),1,(instr(user(),’@')-1)), “ELIMINAR”, NOW(), “MAESTROS”)//

// El resultado que se espera de la bitácora se muestra en la siguiente imagen.

http://labredes.itcolima.edu.mx/fundamentosbd/sd_u3_5.htm

http://www.itsed.net/file.php/541/materials.html

http://grupos.emagister.com/debate/bitacoras_en_sql/6906-489372http://grupos.emagister.com/debate/bitacora_en_sql_server_2000/6906-489296http://www.recoverytoolbox.com/es/mysql.htmlhttp://www.recoverytoolbox.com/es/repair_sql.html