tema 6. recuperación de fallos 1 6. recuperación de fallos objetivos apreciar la necesidad de...

Tema 6. Recuperación de fallos

1

6. Recuperación de fallos

Objetivos•Apreciar la necesidad de establecer un producto

fiable, capaz de proteger la información frente a fallos del sistema

•Identificar los tipos de fallos que pueden ocurrir en un sistema de bases de datos

•Comprender el propósito del fichero de bitácora y los puntos de validación del sistema

•Conocer y entender diferentes técnicas del sistema gestor de bases de datos para la recuperación de fallos


2


Contenidos1.Conceptos generales de recuperación2. Concepto de transacción

1. Propiedades deseables de una transacción2. Operaciones de una transacción3. Estados de una transacción

2. El proceso de recuperación del fallo de una transacción

3. Técnicas de recuperación de fallos del sistema


3

Bibliografía[EN 2002] Elmasri, R.; Navathe, S.B.: Fundamentos de

Sistemas de Bases de Datos. 3ª Edición. Addison-Wesley. (Cap. 19 y 21)

[EN 1997] Elmasri, R.; Navathe, S.B.: Sistemas de bases de datos. Conceptos fundamentales. 2ª Edición. Addison-Wesley Iberoamericana. (Cap. 17, 18 y 20)

[CBS 1998] Connolly, T.; Begg C.; Strachan, A.: Database Systems: A Practical Approach to Design, Implementation and Management. 2nd Edition. Addison-Wesley. (Cap. 17)



4

6.1 Conceptos generales de recuperación

codEmp nomEmp depto

1 José 1012 Antonio 207 Cristina 3022 Julia 205 Rubén 10... ... ...

codDep nomDep ciudSede numEmp

20 Producción Murcia 210 Dirección Madrid 230 Sistemas Valencia 1... ... ... ...

EMPLEADO

DEPARTAMENTO

• Transacción T: Añadir a la base de datos la empleada (14, ‘Eva’, 30)


5

• El código de T podría ser el siguiente: (SQL embebido)

...(1) EXEC SQL WHENEVER SQLERROR ROLLBACK;(2) EXEC SQL INSERT INTO Empleado VALUES (14, ‘Eva’, 30);(3) EXEC SQL UPDATE Departamento SET numEmp=numEmp+1

WHERE codDep = 30;(4) EXEC SQL COMMIT;...

• Única transacción con varias operaciones/sentencias SQL

• ¿Cuál es el estado de la BD entre las sentencias (2) y (3)?



6

• Idea básica: atomicidad y durabilidad de toda transacción

– Secuencia de operaciones que llevan la BD de un estado consistente a otro estado consistente

– Debe garantizarse frente a todo tipo de fallos posible

• El SGBD debe asegurar que toda transacción T ...– ejecute todas sus operaciones con éxito y su efecto

quede permanente en la BD, o bien que ... – no tenga ningún efecto sobre la BD ni otras

transacciones

Nunca deben ejecutarse sólo algunas operaciones de T – Ni siquiera por culpa de un fallo “a mitad” de T



7

• Recuperación«dejar la información de la BD en un estado correcto,

tras un fallo del sistema que ha dejado la BD en un estado inconsistente o sospechoso de serlo»

• El Subsistema Gestor de Recuperación del SGBD vela por que...– No “se pierda” ninguna transacción– Ninguna transacción quede “a medio ejecutarse”– Ninguna transacción se ejecute más de una vez



8

Fallo local:• Sólo afecta a la T

fallida• Pérdida de datos

de T en memoriaprinc. y búfer E/S

1. Locales previstos por la aplicación– «Saldo insuficiente en transacción de reintegro»

2. Locales no previstos– Error de programación (bug), interrupción

3. Por imposición del control de concurrencia– Violación de seriabilidad; bloqueo mortal

4. Fallos del sistema– Mal funcionamiento hardware o error software (SGBD, SO)• Afectan a todas las transacciones• Pérdida de la memoria principal y búfer E/S• No dañan el disco


Tipos de fallos


9

5. Fallos de disco– Fallos en dispositivos de almacenamiento• Afectan a todas las transacciones• Pérdida de la memoria principal y búfer E/S• Algunos bloques del disco pueden perder sus datos

6. Fallos físicos o catastróficos– Corte de suministro eléctrico, robo del disco, incendio,

sabotaje, sobreescritura por error, etc.


Tipos de fallos (y 2)


10

• Unidad lógica de procesamiento– Secuencia de operaciones que implican accesos a la base de

datos– ejemplo: transferencia de dinero entre dos cuentas bancarias

• Pero también se considera... – Unidad lógica de integridad– Unidad lógica de concurrencia– Unidad lógica de recuperación

6.1.1 Concepto de transacción

Una transacción es atómicaO se ejecutan todas las operaciones

que componen la transacción,o no se realiza ninguna


11

• Inicio de una transacción– Sentencia SQL (LDD o LMD) interactiva– Sentencia SQL incluida en un programa (si no tiene ya

transacción en progreso)

• Fin de una transacción– Confirmar (COMMIT) xor Anular (ROLLBACK)– Ambas operaciones pueden ser de tipo explícito o implícito

6.1.1 Concepto de transacción

T1Fin OK

BD

COMMIT T1

T2 KO

ROLLBACK T2

SGBD


12

• Atomicidad– Todo o nada

• Conservación de la Consistencia– T lleva la BD de un estado de consistencia a otro– No necesariamente se mantiene la consistencia “a mitad de T”

• Aislamiento (Isolation)– T no muestra los cambios que produce hasta que finaliza– Puede no imponerse de forma estricta (niveles de aislamiento)

• Durabilidad– Una vez que T finaliza con éxito y es confirmada,

los cambios perduran aunque el sistema falle después

Conocidas como propiedades ACID

6.1.2 Propiedades de una transacción

SubSistema deRecuperación

SubSistema deRecuperación

SS de Integridad+ Programadores

SS de Control deConcurrencia


13

ACTIVAPARCIALMENTE

CONFIRMADACONFIRMADA

TERMINADAFALLIDA

LEER / ESCRIBIR

INICIO DETRANSACCIÓN

FIN DE TRANSACCION CONFIRMAR

ABORTAR

ABORTAR

Diagrama de Transición de Estados de la ejecución de una transacción

Otras:

* DESHACER una operación

* REHACER (algunas operaciones de) una transacción

6.1.3 y 6.1.4 Operaciones y Estados de una transacción

Verificaciones para control de concurrencia

y recuperación


14

• Hay que asegurar que una vez que T se ha confirmado, nunca será necesario anularla (cancelarla, revertirla, abortarla)

• Un plan P es recuperable si ninguna transacción T de P se confirma antes de haberse confirmado toda transacción T’ que ha escrito un dato que T lee

– Una transacción Tj “lee de” la transacción Tk , si Tk escribe un elemento X y luego Tj lo lee

6.1 Conceptos generales de recuperaciónRecuperabilidad de planes de transacciones


15

– Así, Tj “no lee de” Tk...

Si Tk ha abortado antes de que Tj lea el elemento X

Si otras transacciones escriben X después de que Tk lo haya escrito y antes de que Tj lo lea

– Ejemplo de plan no recuperable

Pc: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; c2 ; ...

– Solución: postergar la confirmación de T2 hasta que T1 se confirme

Pd: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; e1(Y) ; c1 ; c2;

6.1 Conceptos generales de recuperaciónRecuperabilidad de planes de transacciones (2)


16

• En un plan recuperable ninguna T confirmada tiene que anularse jamás, pero puede ocurrir el fenómeno de la reversión en cascada

Tk no confirmada debe anularse porqueha leído X de Tj , y Tj ha sido abortada

– Ejemplo de plan con reversión en cascada

Pe: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; e1(Y) ; r1 ;– La cancelación en cascada puede consumir mucho tiempo

• Un plan P es sin cascada si toda T en el plan sólo lee datos escritos por transacciones confirmadas– ¿Cómo transformamos Pe para que evite la cancelación en

cascada?

Un plan sin cancelación en cascada, es recuperable

6.1 Conceptos generales de recuperaciónRecuperabilidad de planes de transacciones (3)


17

• Un plan P es estricto si las transacciones no pueden leer ni escribir un elemento X hasta que sea confirmada o abortada toda T que haya escrito X

• Si T1 es abortada, es necesario deshacer todas sus operaciones de escritura

• Deshacer una operación de escritura e1(X,5) consiste en restaurar el valor anterior del elemento X

• Pero esto puede no funcionar correctamente si el plan no es estricto:

Pf: e1(X,5) ; e2(X,8) ; r1 ;

Un plan estricto es recuperable y sin cancelación en cascada

6.1 Conceptos generales de recuperaciónRecuperabilidad de planes de transacciones (y 4)


18

• Cuando ocurre un fallo... ... ¿cómo restaurar la base de datos a un estado consistente?

Redundancia + Técnica de Recuperación


Bitácora

Acciones para restablecer el contenido de la BD a un estado que asegure:

– Consistencia de la BD– Atomicidad de

transacciones– Durabilidad de

transacciones

Seguir la pista de la ejecución de cada transacción

– Cuándo se inicia, confirma o aborta

– Qué operaciones realiza sobre qué datos

FICHERODE

BITÁCORA


19

• Fichero que almacena detalles sobre las operaciones efectuadas como parte de las transacciones– Log, diario, journal, registro histórico...

• Se mantiene en el disco– En un área distinta a donde se almacenan los datos de la

BD– No le afecta ningún tipo de fallo, salvo los de tipo 5 y 6– Se suele realizar periódicamente una copia de seguridad

(en cinta)

• Cada registro del fichero se denomina entrada, que puede ser de diversos tipos


Bitácora (2)


20

< INICIAR, T >– Indica que la transacción T ha comenzado su ejecución

< ESCRIBIR, T, X, valor_anterior, valor_nuevo >– Indica que T ha modificado el valor del elemento X

< LEER, T, X >– Indica que T leyó el valor del elemento X de la base de datos

< COMMIT, T >– Indica que T finalizó con éxito y su efecto puede ser

confirmado en la base de datos en disco: los cambios que ha realizado pueden quedar permanentes en la BD

< ROLLBACK, T >– Indica que la transacción T ha sido anulada de forma que

ninguna de sus operaciones tendrá efecto sobre la BD: la transacción será revertida, todas sus operaciones serán deshechas


Bitácora (3): tipos de entradas


21

Suponemos que...• Las transacciones no se pueden anidar• Toda modificación «permanente» de la BD «ocurre»

dentro de una transacción

Recuperar un fallo de T consistirá en deshacer o rehacer algunas de sus operaciones, a partir del contenido de la bitácora (se verá)


Bitácora (y 4)


22

• Cada T posee un área de trabajo privada donde guarda todo elemento que lee/escribe– Espacio en memoria principal y local a la transacción– Se crea al iniciarse T y se elimina cuando T finaliza

• Búfer de base de datos que contiene temporalmente los bloques de BD que las transacciones requieren– Uno o más bloques en memoria principal (en la caché del

SGBD)– Común a todas las transacciones


Acceso a datos almacenados

BD

MEMORIA PRINCIPAL

Area de trabajo

de TBúferde BD


23

• Cuando T termina de ejecutar COMMIT significa que...– Todas sus operaciones se ejecutaron con éxito– El efecto de dichas operaciones se anotó en bitácora,

incluyendo el COMMIT

T ha llegado a su punto de confirmación... y se puede suponer que...– T está confirmada– Sus cambios son permanentes en la BD– Bloqueos liberados y cursores cerrados


Punto de confirmación de una transacción

UPDATE... INSERT...

SELECT...T1

COMMIT

...<INICIAR,T1><ESCRIBIR,T1,...><LEER,T1,...><ESCRIBIR,T1,...><COMMIT,T1>...

BD okBD ok

Bitácora


24

• Cuando T termina de ejecutar ROLLBACK significa que...– T ha resultado fallida– El ROLLBACK se anotó en bitácora

... y se puede suponer que...– T ha sido cancelada (deshecha)– Sus operaciones han sido anuladas: ningún efecto en la BD– Bloqueos liberados y cursores cerrados

6.1 Conceptos generales de recuperaciónPunto de confirmación de una transacción (y 2)

UPDATE... SELECT...T1

ROLLBACK

...<INICIAR,T1><ESCRIBIR,T1,...><LEER,T1,...><ROLLBACK,T1>...

BD ok


25

• Si el fallo ocurre cuando T está en curso de ejecución, entonces se debe deshacer T – Pues no alcanzó su punto de confirmación (no anotó <COMMIT,T>)

6.2 El proceso de recuperación del fallo de una transacción

T

UPDATE... SELECT...T

COMMIT

• Si el fallo ocurre cuando T ya ha sido confirmada, entonces se debe rehacer T – No es seguro que todo cambio haya sido llevado a la BD en

disco


26

• deshacer T implica deshacer cada una de sus operaciones, a partir de las anotaciones en bitácora, empezando por la última (orden inverso)

< ESCRIBIR, T, X, valor_anterior, valor_nuevo >

deshacer (< ESCRIBIR, T, X, 10, 5 >) X = 10 en la BD

• rehacer T implica rehacer cada una de sus operaciones, a partir de las anotaciones en bitácora, empezando por la primera (en el mismo orden)

< ESCRIBIR, T, X, valor_anterior, valor_nuevo >

rehacer (< ESCRIBIR, T, X, 10, 5 >) X = 5 en la BD



27

• Las entradas < LEER,... > son necesarias para detectar reversión en cascada

T2 debe ser deshecha !

• Si el método de concurrencia / recuperación garantizara planes sin cascada o planes estrictos, no sería necesario anotar entradas LEER en bitácora


...< ESCRIBIR, T1, X, 10, 5 >...< LEER, T2, X >< ESCRIBIR, T2, X, 5, 25 >...< ROLLBACK, T1 >...


28

• La bitácora es un fichero almacenado en disco, por lo que para insertar una nueva entrada es necesario...– Copiar el bloque adecuado del fichero a memoria principal– Actualizar el bloque en memoria, insertando la nueva

entrada– Copiar el bloque desde memoria al disco

Una escritura de bloque en disco por cada nueva entrada!!

• Búfer de bitácora, que contiene un bloque del fichero de bitácora hasta que se llena de entradas, momento en el que se escribe en el disco– Espacio en memoria principal (en la caché del SGBD)

Una única escritura por bloque

Escritura anticipada en bitácora



29

• Cuando ocurre un fallo, algunas entradas pueden no haber sido llevadas al fichero de bitácora en disco– Entradas del bloque incompleto, en el búfer de bitácora– Con el fallo se pierde el contenido de la memoria principal

• Dichas entradas no serán consideradas en el proceso de recuperación, pues el SGBD acude al fichero bitácora

• Esto puede impedir la restauración correcta tras el fallo de una transacción

• Es necesario seguir un protocolo de escritura anticipada en bitácora, o bitácora adelantada

Escritura anticipada en bitácora (2)



30

Bitácora adelantada• No se puede grabar en disco los cambios

realizados por T hasta que se haya escrito en disco toda entrada de bitácora para T hasta el momento actual

Escritura anticipada en bitácora (3)


UPDATE... DELETE...

TCOMMIT

CAMBIOSa disco

BITÁCORAa disco

PUNTO DE CONFIRMACIÓN

• El COMMIT de T no se completa hasta que se haya escrito en disco toda entrada de bitácora para T pendiente

»Se fuerza la escritura en disco de las entradas de búfer de bitácora para T, antes de consolidar cambios hechos por T


31

• Nunca puede ocurrir...

UPDATE... DELETE...

TCOMMIT

ESCRITURA ENDISCO DE CAMBIOS ESCRITURA EN

DISCO DE BITÁCORA

UPDATE... DELETE...

TCOMMIT

CAMBIOSa disco

BITÁCORAa disco

• Pero sí puede suceder... PUNTO DE CONFIRMACIÓN

Escritura anticipada en bitácora (y 4)


SELECT... INSERT...

TCOMMIT

CAMBIOSa disco

BITÁCORAa disco


32

• ¿Cómo sabe el SGBD qué transacciones debe deshacer?

• ¿Y cómo sabe cuáles debe rehacer?

Puntos de validación


UPDATE... SELECT...T1

INSERT...

DELETE... SELECT...

T2COMMIT

UPDATE... INSERT...T3

SELECT...

...<INICIAR,T2><INICIAR,T3><ESCRIBIR,T2,...><INICIAR,T1><ESCRIBIR,T1,...><ESCRIBIR,T3,...><LEER,T1,...><ESCRIBIR,T3,...><LEER,T2,...><ESCRIBIR,T1,...><COMMIT,T2><LEER,T3,...>

Examinar TODA la bitácora: ausencia de entradas COMMIT

Rehacer TODAS las Ti confirmadas

mejora conpuntos devalidación


33

• SGBD marca automáticamente un punto de validación...– Cada m minutos, o– Tras escribir t entradas <COMMIT,Ti> en bitácora desde

el último punto de validación

• Es otro tipo de entrada en el fichero de bitácora< registro_de_validación >– Este registro contiene:

• Lista de identificadores de transacciones activas en ese instante• Dirección en el fichero bitácora de 1ª y ultª entradas para cada Ti

activa

Puntos de validación (2)



34

• Marcar un punto de validación significa ...1. Suspender la ejecución de las transacciones2. Forzar escritura en disco del búfer de bitácora3. Forzar escritura en disco de todo bloque del

búfer de BD modificado 4. Escribir en búfer de bitácora el registro_de_validación

y forzar su escritura en disco5. Escribir en Fichero Especial de Arranque la dirección

que ocupa el registro_de_validación dentro del fichero bitácora

6. Reanudar la ejecución de las transacciones




35

Al marcar un punto de validación se transfiere al disco el efecto de las operaciones ESCRIBIR realizadas hasta ese instante por las transacciones– Pero no son los únicos momentos en los que se consolidan

cambios en disco... ¿en qué otros se realiza?

• El uso de puntos de validación permite, en el proceso de recuperación...– Recorrer la bitácora a partir del último punto de

validación (y no desde el principio)

– Ignorar Ti confirmadas antes del último punto de validación (no es necesario rehacer todas las confirmadas)




36

Tras un fallo de tipo 5 o 6, que produjo daños en la BD...• Restaurar copia de seguridad de la BD • Reconstruir un estado más actual: rehacer operaciones de T

confirmadas hasta el momento de la caída bitácora

Tras un fallo de tipos 1 a 4...• Invertir modificaciones que provocaron la inconsistencia:

deshacer algunas operaciones bitácora• Si es necesario, asegurar cambios correctos: rehacer

algunas otras operaciones bitácora

Es necesario seguir una técnica de recuperación

Estrategia de recuperación representativa

6.3 Técnicas de recuperación de fallos


37

• Ninguna transacción T modifica la BD antes de llegar a su punto de confirmación

• Se difiere la consolidación de cambios realizados por T hasta después de confirmarse T

Técnica basada en la actualización diferida


UPDATE... DELETE...

TCOMMIT

• Si el fallo ocurre antes de alcanzar T su punto de confirmación, no es necesario deshacer sus operaciones

• Si el fallo ocurre después de alcanzar T su punto de confirmación, es necesario rehacer sus operaciones

BITÁCORAa disco

CAMBIOSa disco


38

Algoritmo NO-DESHACER / REHACER

1. Crear dos listas ACTIVAS y CONFIRMADAS, vacías2. Inicializar ACTIVAS con la lista de transacciones activas almacenada en

el último registro_de_validación en bitácora3. Examinar la bitácora a partir del último punto de validación en adelante4. Si se encuentra una entrada <INICIAR,T>, añadir T a la lista ACTIVAS

5. Si se encuentra una entrada <COMMIT,T>, mover T de ACTIVAS a CONFIRMADAS

6. Al terminar de examinar la bitácora:• Rehacer las operaciones <ESCRIBIR,...> de las transacciones en

CONFIRMADAS, en el mismo orden en que aparecen en bitácora• Ignorar transacciones de la lista ACTIVAS (más adelante Reiniciar)

Técnica basada en la actualización diferida (2)



39

• En bitácora, las entradas <ESCRIBIR,...> sólo necesitan guardar el valor_nuevo: pueden rehacerse pero nunca deshacerse

• La operación reiniciar T es reintroducir T en el sistema, como si fuera nueva

– Puede hacerlo el SGBD de forma automática– o el usuario manualmente

Las operaciones se reharán en el orden en que aparecen anotadas en bitácora.No se rehace cada T confirmada “en aislado”, sino que se van rehaciendo todas las confirmadas “a la vez”, operación a operación.

Técnica basada en la actualización diferida (y 3)



40

• Una transacción T puede modificar la BD antes de llegar a su punto de confirmación

• Algunos cambios realizados por T pueden consolidarse en disco antes de confirmarse T ( modificaciones no comprometidas )

Técnica basada en la actualización inmediata


UPDATE... DELETE...T

COMMIT

BITÁCORAa disco

• Si el fallo ocurre antes de alcanzar T su punto de confirmación (quizá después de grabar cambios en BD), es necesario deshacer sus operaciones

CAMBIOSa disco

• Si el fallo ocurre después de alcanzar T su punto de confirmación, es necesario rehacer sus operaciones


41

Algoritmo DESHACER / REHACER1. Crear dos listas ACTIVAS y CONFIRMADAS, vacías2. Inicializar ACTIVAS con la lista de transacciones activas almacenada en

el último registro_de_validación en bitácora3. Examinar la bitácora a partir del último punto de validación en adelante4. Si se encuentra una entrada <INICIAR,T>, añadir T a la lista ACTIVAS5. Si se encuentra una entrada <COMMIT,T>, mover T de ACTIVAS a

CONFIRMADAS6. Al terminar de examinar la bitácora:

• Deshacer las operaciones <ESCRIBIR,...> de las transacciones de la lista ACTIVAS, en orden inverso al que se anotaron en bitácora

• Rehacer las operaciones <ESCRIBIR,...> de las transacciones en CONFIRMADAS, en el mismo orden en que aparecen en bitácora

Técnica basada en la actualización inmediata (2)



42

• En bitácora, las entradas <ESCRIBIR,...> necesitan guardar el valor_anterior y valor_nuevo: pueden deshacerse o rehacerse

• Se debe deshacer primero, y rehacer después Las operaciones se desharán en el orden inverso al

de anotación en bitácoraNo se deshace cada T activa “en aislado”, sino que se van deshaciendo todas las activas “a la vez”, operación a operación

Las operaciones se reharán en el mismo orden en que aparecen en bitácoraNo se rehace cada T confirmada “en aislado”, sino que se van rehaciendo todas las confirmadas “a la vez”, operación a operación

Técnica basada en la actualización inmediata (3)



43

• Una transacción T puede modificar la BD antes de alcanzar su punto de confirmación

• Todos los cambios hechos por T se llevan a la BD antes de llegar T a su punto de confirmación

Técnica de actualización inmediata: variación


UPDATE... DELETE...T

COMMIT

BITÁCORAa disco

• Si el fallo ocurre antes de alcanzar T su punto de confirmación (quizá después de grabar cambios en BD), es necesario deshacer sus operaciones

CAMBIOSa disco

• Si el fallo ocurre después de alcanzar T su punto de confirmación, no es necesario rehacer sus operaciones

PUNTO DE CONFIRMACIÓN


44

• Código del Algoritmo DESHACER/NO-REHACER– Usado en la variación de la técnica de actualizaciones

inmediatas

• Cambios necesarios en los algoritmos si el sistema no utilizara puntos de validación/revisión

Lo que se deja como “ejercicio”...


• Aplicar los tres algoritmos al ejemplo de la diapositiva 27• ¿Qué ocurre con transacciones que terminan con

ROLLBACK?

Práctica…


45

Inicio de transacción– Cuando no hay ya una transacción en progreso, y se ejecuta una

sentencia LDD o LMD (interactivamente o dentro de una aplicación)– Cada sentencia LDD es tratada como una transacción – No existe sentencia de tipo BEGIN TRANSACTION

Fin de transacción• COMMIT

– Finaliza la transacción actual y hace permanentes (confirma) los cambios realizados

– COMMIT implícito (por parte del SGBD)• El programa finaliza de forma normal • Se sale de la herramienta (SQL*Plus, ...) correctamente• Se ejecuta una sentencia LDD

– Oracle realiza COMMIT antes y después (si tiene éxito) de ejecutarla– COMMIT explícito (por parte del programador/usuario)

COMMIT [WORK] ;

Anexo. Control de transacciones en Oracle


46

Fin de transacción (cont.)

• ROLLBACK – Finaliza la transacción actual y deshace los cambios realizados– ROLLBACK implícito (por parte del SGBD)

• La aplicación finaliza de forma anormal • Se sale de la herramienta (SQL*Plus, ...) cerrando la ventana

– ROLLBACK explícito (por parte del programador/usuario) ROLLBACK [WORK] [TO SAVEPOINT savepoint];

Anexo. Control de transacciones en Oracle (2)


47

Anexo. Control de transacciones en Oracle (y 3)

Reversión parcial de una transacción• SAVEPOINT savepoint ;

– Establece un punto hasta el que se podrá hacer ROLLBACK después

UPDATE Empleado SET salario = 2000 WHERE nombre = 'Julia Ibáñez' ;SAVEPOINT julia_salario ;

UPDATE Empleado SET salario = 1500 WHERE nombre = 'Cristina Ortín' ;SAVEPOINT cristina_salario ;

SELECT SUM(salario) FROM Empleado ; no se cumple que sea 315.000€

ROLLBACK TO SAVEPOINT julia_salario ;

UPDATE Empleado SET salario = 1300 WHERE nombre= 'Cristina Ortín' ;COMMIT ;

tema 6. recuperación de fallos 1 6. recuperación de fallos objetivos apreciar la necesidad de...

Documents