gestionamiento de transacciones en oracle bd

Departamento de Lenguajes y Sistemas Informáticos E.T.S. Ingeniería Informática. Universidad de Sevilla

Avda Reina Mercedes s/n. 41012 Sevilla

Tlf/Fax 954 557 139 E-mail [email protected] Web www.lsi.us.es

E.T.S. Ingeniería

Informática

Diseño de bases de datos Módulo II Tema 7

Recuperación de bases de datos

Sevilla, noviembre 2007 V 2007.11.1

Diseño de bases de datos

Recuperación de bases de datos Sevilla noviembre 2007, V 2007.11.1

Pág. 2 de 14

1 INTRODUCCIÓN.....................................................................................3

2 TIPOS DE FALLOS...................................................................................4

2.1 FALLOS EN TRANSACCIONES ...................................................................................4

2.2 FALLOS EN EL SISTEMA ...........................................................................................4 2.3 FALLOS DEL MEDIO.................................................................................................4

2.4 POLÍTICAS DE RECUPERACIÓN ................................................................................4 2.4.1 Recuperación de fallos del medio. ....................................................................................................................... 4 2.4.2 Recuperación de fallos de transacciones y del sistema .................................................................................... 5

3 ARQUITECTURA DE GESTIÓN DE TRANSACCIONES ..................6

3.1 (GT) GESTOR DE TRANSACCIONES .........................................................................6 3.2 (PT) PLANIFICADOR DE TAREAS .............................................................................7

3.3 (GM) GESTOR DE MEMORIA CACHÉ........................................................................7 3.4 (GR) GESTOR DE RECUPERACIÓN DE LA BASE DE DATOS........................................7

4 TIPOS DE ACTUALIZACIONES DE LA MEMORIA EXTERNA ......8

4.1 ACTUALIZACIÓN INMEDIATA ..................................................................................8

4.2 ACTUALIZACIÓN DIFERIDA .....................................................................................8 4.3 ACTUALIZACIÓN IN SITU .........................................................................................9

4.3.1 Write Ahead Loggin Protocol .............................................................................................................................. 9 4.3.2 Puntos de control (CheckPoint) .......................................................................................................................... 9

4.4 ACTUALIZACIÓN POR SOMBREO (SHADOWING)..................................................... 10

5 PERFILES DE ALGORITMOS DE RECUPERACIÓN ...................... 10

6 ALGORITMO DE RECUPERACIÓN ARIES ...................................... 11 6.1 LOG Y LSN EN ARIES.......................................................................................... 11 6.2 TABLA DE TRANSACCIONES Y DE PÁGINAS............................................................. 12 6.3 PUNTOS DE CONTROL DEL SISTEMA (CHECKPOINTING) ....................................... 12

7 PROTOCOLO DE CONFIRMACIÓN EN DOS FASES (2PC)........... 13



Pág. 3 de 14

1 Introducción El propósito de la recuperación de bases de datos es garantizar que el estado representado por esta sea el estado consistente mas reciente previo al ocasionado por un fallo.

Por otro lado se deben preservar las propiedades de una transacción (ACID transactions: Atomicity, Consistency, Isolation, Durability).

(A) Atomicidad y consistencia

Una transacción es una unidad lógica de trabajo, de modo que el conjunto de acciones que la componen deben llevar a la base de datos a un nuevo estado, si la transacción termina satisfactoriamente, o bien dejarlo en el estado en que está si la transacción se interrumpe. La transacción no puede quedar en un estado intermedio.

Sea { }1 2, ,..... ,....i nT a a a a una transacción desglosada en las acciones o primitivas de

manipulación de la base de datos en que se descompone, { }1 2, ,..... ,....jI I I I Ip el conjunto de

restricciones de integridad de la metabase de datos y S un estado inicial consistente, entonces:

S╞ I se interpreta: S satisface las restricciones de integridad ((C):Consistencia), o bien la BD está en un estado de partida consistente.

Al ejecutar la transacción T se genera un nuevo estado T(S) que también debe ser consistente, luego el nuevo estado debe verificar T(S)╞ I.

Pero ningún estado intermedio ( )( )( )( )1 .... 2 1i ia a a a S− representará un estado consistente,

razón por la cual no podrá reflejarse en la base de datos.

(D) Durabilidad

Los estados que se reflejan en la BD son estados que permanecen (son persistentes) y serán visibles a otras transacciones.

(I) Aislamiento

Las transacciones, aunque se ejecuten concurrentes, vistas como unidades lógicas de trabajo, no deben colisionar entre si, de modo que sus efectos se vean reflejados en la BD como si se ejecutasen independientemente del resto de actividad contra la misma.

Ejemplo: suponga un cajero automático conectado a una base de datos centralizada con la gestión transaccional de cuentas bancarias de una entidad financiera.

En este sistema deberá cumplirse que el balanceo de saldos de cuentas en un período deberá coincidir, necesariamente, con el balanceo de dinero efectivo expedido por la red de cajeros automáticos. Si suponemos que las transacciones realizadas en los cajeros mantienen los registros de dinero expedido y los saldos de las cuentas de la base de datos y se produce un fallo en una o en un conjunto de transacciones entonces podría provocarse un desequilibrio en dichos balances; dicho de otro modo: si se contemplan esas dos grandes operaciones, en función del diseño del código de dichas transacciones, una interrupción o fallo en la transacción entre las dos operaciones generaría la actualización de un registro y no del registro complementario (el cajero o el saldo de la cuenta o viceversa).

La misión del sistema de recuperación será garantizar que dichos balances son los adecuados tanto si se ha expedido el dinero efectivo como si no se ha producido dicha expedición.

Ylnner

Resaltado

Ylnner

Resaltado

Ylnner

Resaltado

Ylnner

Resaltado

Ylnner

Resaltado

Ylnner

Resaltado

Ylnner

Resaltado

Ylnner

Resaltado

Ylnner

Resaltado

Ylnner

Resaltado



Pág. 4 de 14

2 Tipos de fallos Podrían clasificarse en:

• Fallos en transacciones

• Fallos en el sistema

• Fallos del medio

Pueden establecerse políticas y, en concreto, procedimientos para paliar los efectos indeseables en función de estas categorías de fallos.

En este capítulo se pormenorizarán las actuaciones que proceden en el seno del SGBD.

2.1 Fallos en transacciones Las transacciones pueden tener fallos por el diseño del flujo lógico, asociados a las entradas de datos o a conversiones de los mismos. P.ej.: bucles sin fin, direccionamientos no permitidos, errores de conversión de tipos, errores aritméticos (división por cero, logaritmos de números negativos, etc.), etc.

Este tipo de fallos son fallos locales o fallos en la transacción donde se produce. Se caracterizan porque, en principio, no deben afectar a otras transacciones (salvo acoplamiento de efectos por gestión de concurrencia: p.ej.: efecto dominó en los algoritmos de ordenación por timestamp).

2.2 Fallos en el sistema Este tipo de fallos afectan a un grupo de transacciones que están en ese instante en ejecución (transacciones en vuelo). Se pueden originar por fallos en aplicaciones (p.ej.: en el propio SGBD, monitores de transacciones, etc.), en el sistema operativo o por fallos físicos que afectan globalmente al sistema: p.ej.: cortes de corriente, fallos en la RAM, etc.). Se aíslan de esta categoría los fallos que afectan al medio de almacenamiento externo que se definen en el siguiente epígrafe.

2.3 Fallos del medio Los fallos del medio alteran el estado de la memoria externa de almacenamiento; p.ej.: fallos en superficies del disco, cabezales de lectura, sabotajes o daños físicos en general a estas unidades o soportes.

2.4 Políticas de recuperación En función del tipo de fallo pueden establecerse políticas de recuperación que se plasman en procedimientos de recuperación, bien manuales, bien automáticos.

2.4.1 Recuperación de fallos del medio. Cuando el medio externo (hoy en día, normalmente discos externos de almacenamiento) ve alterado su estado normal de funcionamiento y en ese medio reside la base de datos física (BDF) es necesario restablecer el estado del mismo a un estado consistente anterior que haya sido copiado (back up) a un medio redundante (cintas, cartuchos, discos redundantes, etc.).



Pág. 5 de 14

El procedimiento de recuperación debe, por tanto, contemplar:

a) Realización de copias de seguridad periódicas (Back Up).

Pueden utilizarse soportes offline (cintas, cartuchos, etc.) o bien online (discos redundantes).

Las copias pueden ser totales (la base de datos entera) o bien incrementales (cambios realizados a la BDF desde la última copia de seguridad).

Es especialmente relevante la verificación del estado de la copia de seguridad para asegurar que el soporte redundante será válido en caso de necesidad.

b) Custodia de copias de seguridad

Es importante la designación de los lugares (sitios físicos) de custodia de las copias de seguridad y el número de copias de seguridad a mantener teniendo en cuenta:

• Desastres (incendios, inundaciones, etc.) naturales o intencionados que puedan producirse.

• Salvaguarda en armarios ignífugos y estancos.

• Custodia en sitios alternativos y distantes del centro de proceso de datos.

c) Recuperación del medio

El medio (discos de almacenamiento de la BDF) se restablecerá a un estado consistente anterior lo más cercano al desastre mediante una recuperación en frio (Cold Recovery) que consistirá en:

• Restablecer en el medio una copia o copias de seguridad anteriores (teniendo en cuenta la disposición de copias totales y/o incrementales).

• Arranque del sistema, incluyendo el arranque del SGBD.

2.4.2 Recuperación de fallos de transacciones y del sistema Bajo la hipótesis de medio externo estable, lo que significa que la BDF y los diarios de transacciones (log) son accesibles por el software (SGBD) pueden establecerse procedimientos automáticos de recuperación o recuperación en caliente (Warm Recovery) que consistirán en:

• Reconocer el estado consistente más reciente y/o cercano al instante del fallo.

• Deshacer las transacciones que no han podido alcanzar el punto de COMMIT antes del fallo.

• Rehacer las transacciones que ganaron el punto de COMMIT.

• Reanudar el proceso normal de gestión de transacciones.

Estos procedimientos de recuperación automática son objeto de estudio en los siguientes apartados.



Pág. 6 de 14

3 Arquitectura de gestión de transacciones Es conocido el entorno de ejecución concurrente de tareas(transacciones) en una base de datos; también es conocido que las transacciones emiten instrucciones de muy alto nivel (en lenguajes de especificación) contra esquemas externos de la base de datos. El SGBD actúa como interfaz entre los programas(transacciones) y el sistema operativo (métodos de acceso a ficheros) para realizar la recuperación física de las páginas o bloques físicos de datos (unidades mínimas de transferencia entre la memoria externa y la memoria principal).

En el esquema1 presentado figuran los distintos subsistemas en que puede descomponerse la funcionalidad del

SGBD para dar servicios a estas transacciones y, simultáneamente, garantizar la consistencia de representación de estados en la base de datos física.

Se diferencian los siguientes subsistemas:

• (GT) Gestor de transacciones.

• (PT) Planificador de tareas o gestor de transacciones concurrentes.

• (GM) Gestor de memoria caché.

• (GR) Gestor de recuperación de la base de datos.

3.1 (GT) Gestor de transacciones El gestor de transacciones recibe las peticiones de las transacciones (lecturas, inserciones, actualizaciones, eliminaciones, alcance de los datos que quedan afectados, etc.) y es capaz de servir los datos a dichas transacciones como retorno a su petición así como los códigos de estado (códigos de retorno) que informan del nivel de finalización de dicha petición.

1 En negro (y/o trazo fino) flujos e control entre transacciones y módulos del SGBD. En azul (y/o trazo

grueso) flujo de datos intercambiado entre el almacenamiento externo, la memoria (BP) y la memoria

privada direccionada por las transacciones Ti.

(GT) Gestor

Transacciones

(PT) Planificador

Tareas

(Ti) Transacción

genérica

BDF

Log

Gestor de datos

(GR) Gestor

Recuperación

(GM) Gestor de Memoria

(BP) Buffer Pool



Pág. 7 de 14

3.2 (PT) Planificador de tareas La función de este módulo o subsistema del SGBD es gestionar el ámbito de concurrencia de dichas transacciones (Ver tema de concurrencia en SGBDs) en función de las políticas y algoritmos implementados para resolver los conflictos de concurrencia que pueden originarse (Bloqueo en 2 fases, Métodos de ordenación de transacciones, Gestión optimista de transacciones, etc.). Dicho de otro modo: el Scheduler puede decidir, y en qué orden, si acepta o rechaza determinadas peticiones que recibe del gestor de transacciones, implementando primitivas específicas de cancelación (ABORT) o reinicio (RESTART) de transacciones.

3.3 (GM) Gestor de memoria caché. Este módulo trata de optimizar el throughput(flujo o rendimiento global de transacciones por segundo) del sistema. Para ello la política se basa en acaparar la memoria rápida disponible (memoria caché donde se ubican los buffers del sistema, conocido como buffer pool(BP) del SGBD).

En el (BP) se alojan los gránulos o páginas intercambiados con el almacenamiento externo. El (GM) procura además retener estas páginas una vez cargadas en el (BP) con objeto de minimizar repetidas lecturas de la misma desde la memoria externa o base de datos física si otras transacciones la requiriesen. Las transacciones que generan modificaciones de estas páginas generan en el (BP) una nueva versión de dicha página denominada página sucia (dirty page).

Por otro lado, dado que el (BP) se aloja en memoria volátil, es imposible mantener indefinidamente una página sucia en el mismo, teniendo lugar, antes o después, una descarga de dichas páginas a la memoria externa o base de datos física (BDF).

Normalmente, para optimizar los accesos mas costosos a la memoria externa (IOs), se utilizan técnicas de agrupamiento de operaciones (buffering) que intentan arrastrar páginas adyacentes a la página buscada en las lecturas o bien descargar grupos de páginas sucias al almaceamiento cada vez que se implementa una descarga de páginas.

El (GM) tiene que gestionar todas estas operaciones buscando el mejor rendimiento global del sistema.

3.4 (GR) Gestor de recuperación de la base de datos. Tiene que implementar los procedimientos adecuados para garantizar la representación de estados persistentes (almacenados en la BDF) consistentes. Es el módulo software objeto de estudio en este capítulo.

(GR) requiere de una estructura adicional de datos en memoria externa estable para garantizar sus actuaciones: el diario (Log) de transacciones, manteniendo en el mismo un registro de la actividad de todas las transacciones y de los procesos de descarga masiva de páginas del (BP) a la (BDF).

La actividad o registros del Log están representados por:

• Puntos de sincronismo de transacciones: Begin(T), Commit(T), Abort(T). Marcan el inicio y la terminación, normal o anormal, de una transacción.

• Puntos de control del sistema(CheckPoint): Marcan la actividad de descarga masiva de páginas sucias del (BP) a la (BDF).



Pág. 8 de 14

• Preimágenes de páginas(PreI(P)): Es el estado de una página correspondiente antes de la actualización generada por la transacción que la recupera. Las preimágenes permitirán devolver, en caso de fallo, el estado de la base de datos al estado consistente inicial o anterior al inicio de la transacción (Backward Recovery).

• Postimágnes de páginas(PosI(P)): Es el estado de una página (página sucia en principio) después de la actualización (inserción, modificación o eliminación) generada por una transacción. Las postimágenes permitirán reconstruir, en caso de fallo, la actividad de una transacción hacia delante (Forward recovery) hasta el punto de confirmación de la misma, si este se produjo.

Todos estos registros se almacenan en el Log cronológicamente, asociando a los mismos la transacción correspondiente, el valor (PreI(P), PosI(P), Begin(T), Commit(T), Abort(T)) y un puntero, si procede, para el registro anterior y registro posterior de la transacción en dicho Log, de modo que pueda establecerse una cadena de registros con direccionamiento directo a través de dichos punteros, bien hacia delante (Forward) o bien hacia atrás (Backward).

4 Tipos de actualizaciones de la memoria externa En función del momento o del direccionamiento de la actualización pueden establecerse los siguientes tipos:

Por el momento o instante:

• Actualización inmediata

• Actualización diferida

Por la dirección física de las páginas actualizadas:

• Actualización in situ

• Actualización por sombreo

4.1 Actualización inmediata Las páginas son inicialmente actualizadas en caché. Tan pronto como se origina una modificación a la página dicha página se copia a la memoria externa.

4.2 Actualización diferida Las páginas pasan de la memoria caché a la memoria externa bien al confirmarse la transacción o bien agrupando un cierto número de transacciones confirmadas (técnicas de agrupamiento de operaciones).



Pág. 9 de 14

4.3 Actualización in situ Las páginas existentes en memoria externa tienen asociada una dirección en el medio. Cuando una página es actualizada es devuelta a la dirección original.

Para implementar un procedimiento de recuperación de transacciones es necesario tener disponibles ficheros de log en memoria externa estable para el gestor de recuperación (GR) y respetar el siguiente protocolo (Write Ahead Loggin Protocol):

4.3.1 Write Ahead Loggin Protocol Regla 1. Undo: Antes de que una página sucia (PosI(P))sea descargada a la base de datos física (machacando la PreI(P)) su preimagen debe estar en el log. Regla 2. Redo: Antes de que una transacción ejecute el COMMIT todas sus páginas sucias deben estar en el log.

4.3.2 Puntos de control (CheckPoint) Periódicamente, bien aleatoriamente o bajo alguna regla del sistema se descargan masivamente páginas de la memoria caché a la memoria externa; se conoce esta acción como punto de control del sistema (checkpoint); llevándose a cabo las siguientes operaciones:

a) Se suspende la ejecución normal de transacciones temporalmente.

b) Se fuerza la escritura de páginas sucias a disco.

c) Se graba un registro de checkpoint en el log.

d) Se vuelve a la ejecución normal de transacciones.

Los puntos de control marcan la frontera temporal de transacciones en vuelo en un procedimiento de recuperación de transacciones.

Cualquier transacción que haya alcanzado el commit antes del último checkpoint habrá grabado toda su actividad en la base de datos física, razón por la que no estará implicada en el procedimiento de recuperación; Ej.: transacciones T1, T2.

Las transacciones que tienen el commit entre el último checkpoint y el fallo del sistema no tienen garantizada la grabación de toda su actividad en la base de datos física, razón por la cual deberán ser rehechas (REDO); Ej.: TR.

Las transacciones que no han alcanzado el commit al producirse el fallo deben ser desechas (UNDO).

El procedimiento de recuperación consistirá en manejar las listas de transacciones a rehacer y la de transacciones a deshacer para devolver la base de datos a un estado consistente lo más

cercano posible al instante del fallo.

T1

T2

TDa

TDb

TDc

TR

CP1 CP2 Fallo



Pág. 10 de 14

4.4 Actualización por sombreo (shadowing) Este tipo de actualización ofrece siempre una dirección alternativa para la nueva versión de la página.

5 Perfiles de algoritmos de recuperación En función del tipo de descarga de páginas de la memoria caché (Buffer Pool) a disco se pueden contemplar los siguientes casos:

Robo de páginas (Steal). Algunas páginas sucias pueden ser grabadas en la BDF antes de que la transacción alcance el COMMIT. Se mejora la utilización del buffer pool.

Sin robo de páginas (No Steal). Las páginas sucias de una transacción no pueden llegar a la BDF antes de que la transacción gane el COMMIT.

Forzada (Force). Se fuerza la descarga de páginas sucias a la BDF justo antes del COMMIT.

No forzada (No Force). La descarga de páginas sucias no se fuerza en tiempo de COMMIT; es decir serán descargadas en un punto de control del sistema. La ventaja es que una página puede residir más tiempo en el buffer pool para ulteriores actualizaciones por otras transacciones.

La combinación de estas posibilidades nos da los siguientes perfiles de algoritmos de recuperación:

Robo (Steal) Sin Robo(No Steal)

Descarga forzada (Force) Undo/No Redo No Undo/No Redo

Descarga no forzada (No Force) Undo/Redo No Undo/Redo

Undo/No Redo: algoritmos que están mas penalizados al deshacer transacciones. Rehacer es poco costoso puesto que las postimágenes ya llegaron a la BDF (al estar forzada al instante del COMMIT).

No Undo/Redo: algoritmos que están mas penalizados al rehacer transacciones. Deshacer es poco costoso puesto que las postimágenes no llegaron a la BDF (al estar diferida hasta el COMMIT).

Undo/Redo. Algoritmo que se ve penalizado en los dos tipos de operaciones pero por el contrario permite implementar la agrupación de operaciones (buffering) con mayor libertad (antes del commit o en el commit según convenga).

No Undo/No Redo. Parece una paradoja pero realmente estos algoritmos solo son implementables mediante las técnicas de actualización por sombreo, manteniendo dos tablas de direcciones de páginas: (a)Tabla de preimágenes y (b)Tabla de páginas sombra (Postimágenes). El COMMIT llevará a dar por buena la tabla de direcciones de páginas sombra, mientras que la cancelación de la transacción equivaldrá a mantener la tabla de direcciones original. El coste de cualquiera de las operaciones equivale a manejar dichas tablas puesto que las páginas sucias ya fueron descargadas a nuevas direcciones.



Pág. 11 de 14

6 Algoritmo de recuperación ARIES El algoritmo, del tipo Undo/Redo (Steal/No force), se basa en una recuperación en caliente (warm recovery) después de un fallo, teniendo en cuenta:

a) el protocolo WAL (Write Ahead Logging).

b) Reconstrucción del estado hacia adelante durante el proceso REDO utilizando las postimágenes del log.

c) Deshacer los cambios en la BDF utilizando las preimágenes del log.

d) Si hubiese un fallo en el mismo proceso de recuperación se reiniciaría el mismo en el punto donde falló éste.

El algoritmo ARIES consta de tres pasos:

a) Analisis. Se identifican las páginas sucias que residían en el buffer pool y el conjunto de transacciones en vuelo en el instante del fallo del sistema. También se establece el punto del log para aplicación de los siguientes pasos que coincide con el último registro de CheckPoint.

b) Redo. Se aplican las acciones para la reconstrucción hacia adelante de las transacciones que ganaron el COMMIT. Se parte del punto de inicio establecido para la recuperación en el log.

c) Undo. El log se rastrea hacia atrás desde el punto del fallo hasta el punto marcado en el log como inicio de la recuperación deshaciendo cambios en las páginas de la BDF afectadas por transacciones que no ganaron el COMMIT llegado el instante del fallo.

6.1 Log y LSN en ARIES ARIES genera registros de log identificados mediante un número de secuencia de log (Log seqence number: LSN), registrando los siguientes tipos de entradas:

a) Copias de páginas actualizadas.

b) Punto de sincronismo COMMIT de una transacción.

c) Punto de sincronismo ABORT de una transacción. Se graba también un Registro de compensación en caso de realización de un proceso UNDO

d) Fin de transacción.

e) Puntos de Ckeck Point.

Cada registro tiene asociado un LSN único que crece monótonamente para garantizar el orden cronológico de registros en el log. Las páginas actualizadas (Preimágenes, Postimágenes tienen un apuntador al último LSN de la página actualizada en el log).

Cada registro del log tiene:

a) El LSN del registro anterior de la transacción.

b) El ID de la transacción.

c) El tipo de registro del log a que corresponde según los tipos anteriores.



Pág. 12 de 14

6.2 Tabla de transacciones y de páginas ARIES mantiene las siguientes tablas para garantizar una recuperación eficiente:

a) Tabla de transacciones activas o en vuelo. Contiene una entrada para cada transacción activa con información del ID de la transacción, estado de la misma y puntero LSN al registro más reciente de la transacción en el log.

b) Tabla de páginas sucias. Contiene una entrada para cada página sucia en el buffer pool que incluye el ID de la página y el LSN correspondiente al registro en el log del estado actualizado inmediatamente anterior de la página.

6.3 Puntos de control del sistema (checkpointing) ARIES realiza las siguientes acciones en los puntos de control del sistema:

a) Escribe un registro de inicio de checkpoint en el log.

b) Escribe un registro de fin de checkpoint en el log al que van añadidas las tablas de transacciones activas y la tabla de páginas sucias.

c) Salva el LSN del registro de inicio de checkpoint en un fichero especial de acceso rápido. Este fichero de acceso rápido se utiliza durante el procedimiento de rearranque en caliente para acceder inmediatamente al punto del log del último checkpoint.

Ejemplos de tablas:



Pág. 13 de 14

7 Protocolo de confirmación en dos fases (2PC) Los procedimientos analizados en este capítulo corresponden a la ejecución en el seno de un gestor de base de datos centralizado.

Cuando el entorno de ejecución de una transacción corresponde a un entorno de base de datos distribuida (multi-base de datos) donde la ejecución de una transacción precisa de la colaboración de múltiples nodos donde en cada uno existe un SGBD local.

En este escenario: una transacción alcanza el COMMIT si y sólo si todos los nodos pueden alcanzar el COMMIT individualmente.

Este esquema de confirmación se conoce bajo la terminología de “Protocolo de confirmación en dos fases (two phase commit protocol: 2PC) y se basa en lo siguiente:

a) Bien un nodo central o uno de los nodos adquiere el rol de nodo con el proceso de control maestro de la transacción. En este nodo central se ubicará un log global de proceso de la transacción.

b) Cada nodo local (nodos donde se ejecutan SGBDs locales y que actúan como procesos esclavos) gestiona un log local de cada subtransacción gestionando la recuperación local de cada BDF si procede.



Pág. 14 de 14

c) Se mantendrá el siguiente esquema lógico:

Acciones en el proceso global o maestro Acciones en todos los procesos

locales o esclavos

Log PreCommit

SI algún proceso-esclavo

NO CONTESTA o FALLA

Log Abort

SINO

Iniciar actualización

Log Commit

SI algún proceso-esclavo

NO CONTESTA O FALLA

Log Abort

FIN SI

FIN SI

Log PreCommint

Log Abort

Realizar cambios

Log COMMIT

Log Abort

En este proceso se distinguen claramente dos fases:

a) Pre-Commit. Esta primera fase trata de asegurar que todos los procesos involucrados están listos. Si alguno no estuviera listo la transacción global será abortada, abortando todas las subtransacciones.

b) Commit. En esta fase cada nodo local realizará los cambios que le competan en su BD local, manteniendo su propio log local. Si algún proceso falla en la realización de los cambios o en la sincronización del punto de confirmación, nuevamente, la transacción global será abortada. Cuando todos los procesos involucrados alcanzan el punto de sincronismo COMMIT la transacción global habrá sido confirmada.

gestionamiento de transacciones en oracle bd

Documents