Vous êtes sur la page 1sur 43

PostgreSQL, Oracle, MySQL y otros

Sahyra Ypez
Caracas, agosto 2011

Introduccin Transacciones Clasificacin de los fallos Tipos de almacenamiento Tcnicas de Recuperacin ante fallos Tcnicas basadas en el Registro Histrico Paginacin en la Sombra Tcnica de Recuperacin ARIES Recuperacin en PostgreSQL Recuperacin en Oracle Recuperacin en MySQL Otros Manejadores de BD

Definicin:
La Recuperacin de una BD es el restablecimiento de un estado correcto de la BD (consistente) despus que un fallo del sistema haya ocasionado que el estado actual sea inconsistente.

Principios en los que se fundamenta:


Redundancia fsica de los datos (disco-memoria, incluso disco-disco y redundancia mltiple)

Quin se encarga de la recuperacin?


La recuperacin la gestiona el mdulo gestor de recuperacin del SGBD.

El componente encargado de lograr la atomicidad de una transaccin se conoce como administrador de transacciones. Las operaciones COMMIT (comprometer o confirmar) y ROOLBACK (retroceder) son la clave de su funcionamiento. La operacin COMMIT indica el trmino exitoso de una transaccin. La operacin ROLLBACK, en cambio, nos indica el trmino no exitoso de una transaccin.

Fallo en la transaccin
Error lgico (violacin de restricciones, tipos incompatibles, etc.). Error del sistema (interbloqueos, espacio insuficiente, etc.).

Fallo del sistema


Error en la memoria voltil. Error en el funcionamiento del DBMS o del SO.

Fallo de disco
Errores de I/O

VOLTIL

NO VOLTIL

ESTABLE

Memoria principal / cach (ej. RAM) Acceso rpido No sobrevive a las cadas Memoria secundaria (ej. discos o cintas magnticas) Acceso ms lento Sobrevive a las cadas Se implementa a travs de soluciones como los sistemas RAID o los Sistemas de Copia de Seguridad Remota. La informacin nunca se pierde.

Archivo de log Identificador de la transaccin Hora de modificacin Identificador del registro afectado Tipo de accin Valor anterior del registro Nuevo valor del registro Informacin adicional Checkpoint

Tcnicas basadas en el registro histrico Paginacin en la sombra o pginas en espejo Tcnica de Recuperacin Aries

Secuencia de registros que mantiene un rastro de las actualizaciones realizadas a la BD. Registros de inicio de Tx, Registros de compromiso de una Tx, Registros de aborto de una Tx, Registros de actualizacin de una Tx: <Ti;A;900;1000> Debe estar guardado en almacenamiento estable. Se clasifican en:
Tcnica de actualizacin diferida Tcnica de actualizacin inmediata

Retarda la actualizacin en la BD hasta que la transaccin se compromete (commit) parcialmente.

Permite realizar escrituras en la BD mientras la transaccin an se encuentre activa y en ejecucin

La base de datos se divide en un nmero determinado de bloques de tamao fijo (pginas). En memoria voltil se mantiene la tabla actual y en memoria estable una tabla doble (sombra). La idea principal es mantener dos tablas de pginas durante la vida de una transaccin.

Procedimiento de Escritura: 1. Cuando se inicia una transaccin ambas tablas son iguales. 2. Cuando se actualiza una pgina, se escribe la pgina actualizada en una pgina no usada, y se actualiza la tabla actual para apuntar a sta (dejando la sombra sin modificar). 3. Cuando se confirma la transaccin, la tabla de pginas actual pasa a almacenamiento no voltil (se cambian las direcciones de las tablas). 4. Si se produce un fallo, la tabla sombra se copia en la actual. 5. No es necesario ni rehacer ni deshacer.

La tabla de pginas de sombra apunta siempre a las pginas de la BD correspondientes al estado anterior de cualquier transaccin que estuviera activa en el momento de la cada del sistema. De esta forma, no es necesario disponer de una operacin deshacer.

Representa a los mtodos actuales de recuperacin. Usa nmeros de secuencia del registro histrico (NSR) para implementar varias optimizaciones que reducen el tiempo de recuperacin. Estrategia robar/no forzar para la escritura en disco:
Escritura anticipada en el log. Repeticin de la historia. Anotacin en el log de las modificaciones durante el deshacer.

La recuperacin consiste en tres pasos principales:


Anlisis: Identifica las pginas sucias y el conjunto de transacciones activas en el momento de la cada y el punto del log apropiado para empezar la operacin REHACER Rehacer: se replican las operaciones del log. Deshacer: Se recorre el log hacia atrs y se deshacen las transacciones activas en el momento de la cada, o iniciadas despus, de las que no se ha encontrado confirmacin.

En una planificacin con transacciones recin iniciadas:

tres

{T1: update(C), T2: update(B); T1: commit, pto.control, T3: update(A), T2: commit, FALLO }

Log disponible
NSD 1 2 3 4 5 6 7 LTIMO_NSD 0 0 1 ini_control fin_control 0 2 T3 T2 Act Conf A InfoTablas .... .... ID_TRAN T1 T2 T1 TIPO Act Act Conf ID_PAG C B OTRA_INF .... .... ....

Tablas guardadas en el punto de control


ID_TRAN T1 T2 LTIMO_NSD 3 2 TIPO Conf en prog ID_PAG C B NSD 1 2

Tabla de transacciones

Tabla de pginas sucias

En la fase de ANLISIS partimos de las tablas guardadas en el punto de control y las recreamos.
ID_TRAN LTIMO_NSD TIPO ID_PAG NSD

T1 T2 T3

3 7 6 Tabla de transacciones

Conf Conf en prog

C B A

1 2 6 Tabla de pginas sucias

Tablas reconstruidas en la fase de anlisis

En la fase REHACER, empezando desde el mnimo NSD en la tabla de pginas sucias (min(NSD)=1)) se rehacen las actualizaciones del log (en este caso NSD=1, 2, 6). En la fase DESHACER, se deshacen las actualizaciones del log de las transacciones no confirmadas (T3) (i.e. NSD=6).

Recuperacin basada en WAL (Write Ahead Logging) con fases de Rehacer y Deshacer similares a Aries. El directorio pg_xlog contiene los diarios de escritura adelantada (WAL). Un archivo pg_clog registra el estado actual de cada transaccin.

Se implementan como un conjunto de segmentos (ficheros) de un tamao de 16Mb y divididos en pginas de 8Kb. Al realizar un COMMIT se escriben los datos del buffer WAL en los ficheros de diario WAL. Los cambios en los data files deben ser escrito slo luego de que estos cambios han sido registrados (log). Cualquier cambio que no haya sido aplicado a los data files puede rehacerse desde el log de registros.

Los checkpoints son puntos en las secuencias de transacciones que indican que toda la informacin registrada antes del mismo, ha sido vaciada en los data files. Son creados automticamente cada checkpoint_segments o cada checkpoint_timeout dependiendo de lo que ocurra primero. El mtodo wal_sync_method() es utilizado para forzar la escritura de los datos en disco.

Reduccin significativa en el nmero de escrituras en disco. El archivo log es escrito secuencialmente, por lo tanto el costo de sincronizacin del log es mucho menor que el costo de liberar las pginas de data. WAL guarda el contenido completo del data page en el log, lo cual es requerido para asegurar la consistencia luego de una recuperacin por crash.

Redo Log Files: dos o ms archivos donde se registra cualquier modificacin transaccional de una memoria intermedia de la BD. Archivos de control: metadatos necesarios para operar en la Base de Datos, incluyendo informacin sobre copias de seguridad. Guan la recuperacin. Segmento Rollback: guarda las ltimas sentencias realizadas sobre la BD y sabe cundo se ha confirmado o no una transaccin.

De acuerdo a la arquitectura de Oracle, una instancia de Oracle est conformada por varios procesos de fondo y espacios de memoria compartida denominada System Global Area (SGA) que son necesarios para acceder a la informacin contenida en la base de datos. A continuacin se detallan los procesos de instancia involucrados en el proceso de recuperacin ante fallo.

SMON: System Monitor, este proceso es el encargado de recuperar la instancia y abrir la base de datos en caso de que ocurra alguna falla. Recupera las transacciones que pudieran haberse interrumpido debido a una falla del sistema. CKPT: CheckPoint Process, Sintoniza las tareas de grabacin en la base de datos. Advierte al proceso DBWR de efectuar un proceso de actualizacin en el disco de los datos mantenidos en memoria.

DBWR: DataBase Writer, escribe los bloques de datos de la memoria (buffers de bloques) en la base de datos. LGWR: Log Writer, graba los bloques del redo log del buffer a los archivos Redo Log File. ARCH (archiver): respalda la informacin almacenada en los archivos redo log cuando stos se llenan.

En la Recuperacin de un fallo:
1.

Recupera los datos con REHACER (Desde Redo Log File) Deshace las transacciones no comprometidas con Deshacer (Desde el segmento de rollback).

2.

Estructura de un archivo redo log:


N Transaccin. Fecha/Hora. Estado (en curso, validada, anulada). Direccin del Atributo (A.Base, Bloque, Lnea, Columna). Valor Anterior. Nuevo Valor.

Utilizacin de un log de registro llamado registro binario. Contiene todas las sentencias que han actualizado datos o podran haberlo hecho. El registro binario se hace inmediatamente despus de que se completa una consulta, pero antes de que se libere cualquier bloqueo o se haga ningn commit.

Proceso de escritura:
Todas las actualizaciones (UPDATE, DELETE, o INSERT) que cambian alguna tabla son almacenadas en cache (Tablas InnoDB). Al comenzar la ejecucin de una transaccin se reserva un buffer de tamao binlog_cache_size. Posteriormente la transaccin completa escrita en el registro binario por mysqld. Sincronizacin del registro binario con el disco. es

Por defecto, el registro binario no se sincroniza con el disco en cada escritura. La variable global sync_binlog permite establecer que el registro binario se sincronice con el disco tras cada N escrituras. De igual forma, la opcin --innodb-safebinlog, aade consistencia entre el contenido de las tablas InnoDB y el registro binario.

Configuracin del Binary Log en el archivo my.conf:


# The following can be used as easy to replay backup logs # or for replication. # note: if you are setting up a replication slave, see # README.Debian about other settings you may # need to change. #server-id = 1 log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M #binlog_do_db = include_database_name binlog_do_db = sms binlog_do_db = demo #binlog_ignore_db = include_database_name #

Listado de Logs Creados :


root@syepez-laptop:/etc/mysql# ls -l /var/log/mysql total 32 -rw-rw---- 1 mysql adm 3190 2011-08-02 20:43 error.log -rw-rw---- 1 mysql adm 634 2011-08-02 19:37 error.log-old -rw-rw---- 1 mysql adm 125 2011-08-02 20:20 mysql-bin.000001 -rw-rw---- 1 mysql adm 125 2011-08-02 20:20 mysql-bin.000002 -rw-rw---- 1 mysql adm 125 2011-08-02 20:34 mysql-bin.000003 -rw-rw---- 1 mysql adm 367 2011-08-02 20:43 mysql-bin.000004 -rw-rw---- 1 mysql adm 848 2011-08-02 20:55 mysql-bin.000005 -rw-rw---- 1 mysql adm 160 2011-08-02 20:43 mysql-bin.index

Ver contenido del Logs

SQL Server
Usa registro histrico secuencia de registros identificados por LSN (Log Sequence Number). Se basa en el esquema ARIES. Permite configurar intervalos de recuperacin (en base a ello ajusta dinmicamente la frecuencia de los Checkpoint).

DB2
Implementa esquema de recuperacin ARIES Uso de instrucciones explcitas: commit, rollback, begin transaction y end transaction. Soporta 2 tipos de configuracin:
Registro Histrico circular: Slo til para recuperacin de cadas o de un fallo de la aplicacin. la

Registro de archivo: necesario para la recuperacin hacia delante de una copia de seguridad de archivo.

Las tcnicas de recuperacin anteriores slo son tiles si no hay prdida del almacenamiento no voltil. Si esto sucede, se debe recurrir a un Backup para recuperar nuevamente un estado consistente de la base de datos.

http://es.scribd.com/doc/54102737/Apuntes1P#outer_page_25 http://www.econ.uba.ar/sistemas/materias/657/echinkes/m aterial/ComparacionDBMS_ParteII_VJunio2007.pdf http://aulavirtual.uv.es/file/26218084/BD2Tema5.ppt http://www.postgresql.org/docs/8.0/static/wal.html http://alfa.facyt.uc.edu.ve/computacion/pensum/cs0347/do wnload/exposiciones2005-2006/recovery.pdf http://dev.mysql.com/doc/refman/5.0/es/binary-log.html http://www.profesionalhosting.com/soporte-en-linea/losficheros-de-registro-log-de-mysql-preg203.html

Vous aimerez peut-être aussi