Your SlideShare is downloading. ×
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Transacciones y seguridad
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Transacciones y seguridad

1,483

Published on

Published in: Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,483
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Resultado de la ejecución de un programa de usuario escrito en algún lenguaje de programación o de manipulación de datos de alto nivel (SQL, Cobol, Pascal, C, etc.)
  • Consistencia: La suma de A + B no debe ser alterada al ejecutar la transacción. Sin el requisito de consistencia ¡la transacción podría crear o destruir dinero! La responsabilidad de asegurar la consistencia de una transacción es del programador de la aplicación que la codifica. Atomicidad: Supongamos que antes de la transacción, los valores de las cuentas A y B son 20,000 y 40,000, respectivamente Durante la ejecución, hay momentos en que la BD se encuentra en un estado inconsistente . La atomicidad garantiza que esos estados inconsistentes no sean visibles sino al interior de la transacción. La BD conserva los valores antiguos (en disco), y si la transacción no se completa, recupera dichos valores. La responsabilidad de asegurar la atomicidad es del gestor de transacciones de la BD. Durabilidad: Cuando se ha completado con éxito la transacción, no debe suceder que una falla en el sistema produzca la pérdida de datos correspondientes a la transferencia. Las modificaciones realizadas en la transacción se guardan en disco antes que ésta finalice Esta información guardada es suficiente para reconstruirla en caso de fallo. La responsabilidad de asegurar la durabilidad es del gestor de recuperaciones de la BD, estrechamente ligado al gestor de transacciones. Aislamiento: Aunque haya otras transacciones accedan concurrentemente a A y B, sus operaciones no se entrelazarán de modo que ocasionen inconsistencias en la BD. Es decir, las transacciones se ejecutan “como si” su tratamiento fuera secuencial. La responsabilidad de asegurar la atomicidad es del componente de control de concurrencias de la BD.
  • Si el DBMS encuentra un begin transaction cuando hay otra transacción en proceso, bloquea la nueva hasta que la anterior termine. Este método elimina la interferencia, pero es pesimista al suponer que cualquier actividad concurrente representa una amenaza de interferencia.
  • Transacción A: transferir $20 de R a P Transacción B: transferir $30 de R a P Las acciones se están intercalando sin resultados indeseables
  • Activa , el estado inicial; permanece en ese estado durante su ejecución Parcialmente comprometida , después de ejecutarse su última instrucción Fallida , tras descubrir que no puede continuar su ejecución normal Abortada , después de haber retrocedido la transacción y restablecido la BD a su estado anterior al comienzo de la misma. Comprometida , tras completarse con éxito.
  • Con bloqueo estricto de dos fases
  • El bloqueo se aplica sobre criterios de búsqueda, no sobre tuplas individuales
  • Lectura registrada: solamente bloqueos X Lectura repetible: bloqueos X y S, sobre objetos individuales Seriable: bloqueos sobre criterios de búsqueda
  • En Esperar – Morir, una transacción más antigua debe esperar a que una más reciente libere sus elementos de datos. Así, cuanto más antigua se vuelve, más tiende a esperar. Por el contrario, en herir – esperar, una transacción más antigua nunca espera a una más reciente. En esperar – morir, si Ti muere y se retrocede a causa de haber solicitado un elemento de dato que posee Tj, entonces Ti puede volver a realizar la misma secuencia de peticiones cuando vuelva a comenzar. Si Tj posee todavía ese elemento de dato, Ti morirá de nuevo. Así, Ti puede morir varias veces hasta que adquiera el elemento que necesita. Por el contrario, en el esquema herir-esperar, si Ti está herida y retrocede porque Tj solicita un elemento de datos que posee; cuando vuelva a comenzar Ti y solicita el elemento de datos que ahora posee Tj, Ti espera. De este modo puede haber menos retrocesos en el esquema herir-esperar.
  • Transcript

    • 1. Base de Datos: PROCESAMIENTO DE TRANSACCIONES Y SEGURIDAD EN LAS BD Profesor: MSC. Luis Serna Jherry
    • 2. Objetivos del Día de Hoy
      • Concurrencia
      • Recuperación
      • Seguridad
    • 3. Procesamiento de Transacciones “ El problema de la modificación perdida” tiempo Transacción A Transacción B Traer R ($250) Traer R ($250) Actualizar R=R-20 ($230) Actualizar R=R-30 ($220)
    • 4.
      • Para mantener la integridad de la base de datos en ambientes multiusuario, el sistema relacional proporciona:
        • Facilidades para el Control de Transacciones
        • Mecanismos de Seguridad para el control de concurrencias
        • Sistema de registro y recuperación para restaurar la base de datos después de una falla del sistema.
      Procesamiento de Transacciones
    • 5.
      • Transacción
      • Unidad lógica de trabajo (LUW) o procesamiento. Debe ser totalmente completada o no realizada en absoluto.
      • Delimitado por declaraciones (o llamadas a función) de la forma inicio de transacción y fin de transacción
      • La transacción consiste en todas las operaciones que se ejecutan entre el inicio y el final de la transacción
      • Cuando una transacción no pudo ser completada el servidor efectúa un rollback de la transacción incompleta, removiendo toda evidencia de que comenzó alguna vez.
      Procesamiento de Transacciones
    • 6.
      • Propiedades ACID:
      • Atomicidad : se realizan todas las operaciones de la transacción, o ninguna de ellas. (Gestor de Transacciones)
      • Consistencia : La ejecución de la transacción conserva la consistencia de la BD. La BD debe ser consistente antes y después de una transacción ( programador de la aplicación)
      • Aislamiento (Isolation) : Aunque se ejecuten concurrentemente, cada transacción no afecta a ninguna otra, es decir ignora al resto que esté ejecutándose y no se puede ver a una transacción en su estado intermedio. (Control de Concurrencia)
      • Durabilidad : Tras la finalización exitosa de una transacción, los cambios en la BD permanecen, incluso si hay fallos en el sistema ( Gestor de recuperaciones)
      Procesamiento de Transacciones
    • 7.
      • “ Transferir 1000 dólares de la cuenta R a la cuenta P.”
      • Leer el registro de la cuenta R
      • Actualizar el registro de la cuenta R , restándole 1000 dólares
      • Leer el registro de la cuenta P
      • Actualizar el registro de la cuenta P, sumándole 1000 dólares
      • Si fallara el último paso (p.ej. debido a una interrupción de la corriente eléctrica) y los previos se hubieran ejecutado, la BD perdería consistencia.
      Procesamiento de Transacciones
    • 8. Procesamiento de Transacciones 2 retiros de 20 y 30 tiempo Transacción A Transacción B Begin transaction Leer R ($250) Begin transaction esperar Actualizar R=R-20 ($230) esperar Commit esperar Traer R ($230) Actualizar R=R-30 ($200) commit
    • 9. Procesamiento de Transacciones tiempo Incluyendo transferencia de R a P Transacción A Transacción B Leer R ($250) Actualizar R= R-20 ($230) Leer R ($230) Leer P ($600) Actualizar R=R-30 ($200) Actualizar P = P+20 ($620) Leer P ($620) Actualizar P = P+30 ($650)
    • 10. Procesamiento de Transacciones
      • El componente del DBMS encargado de lograr la culminación efectiva de las transacciones es conocido como el Subsistema de Recuperación
        • COMMIT
        • ROLLBACK
    • 11. Transición de Estados de una Transacción Read/write endTransaction Abort Abort Commit Confirmada Parcialmente confirmada Activa Fallida Terminada
    • 12. Concurrencia: P lanificadores
      • Sean n transacciones, T 1 , T 2 , ..., T n .
      • Las llamadas a la BD de T i son c i1 , c i2 , ..., c imi
      • Un planificador para T 1 , T 2 , ..., T n es una disposición lineal de las c ij que preserva el orden de las llamadas dentro de cualquier transacción dada.
      • I.E. si
          • d 1 , d 2 , ... es un planificador, y
          • d s = c ij , d t = c ik , con j < k,
            •  s < t
    • 13. Concurrencia: Planificadores C 11 : leer R C 12 : actualizar R C 21 : leer R C 13 : leer P C 22 : actualizar R C 14 : actualizar P C 23 : leer P C 24 : actualizar P
      • Las llamadas a la BD de Ti son c i1 , c i2 , ..., c imi
      T 1 T 2 C 11 : leer R C 21 : leer R C 12 : actualizar R C 22 : actualizar R C 13 : leer P C 23 : leer P C 14 : actualizar P C 24 : actualizar P Planificador
    • 14. Concurrencia: Tipos de Planificadores
      • En Serie
        • No hay intercalación de las operaciones de las transacciones en ejecución: primero T 1 y después T 2 , o viceversa
      • No en Serie
        • Las operaciones de las transacciones en ejecución se intercalan de alguna manera
      • Seriable
        • Equivalente a algún plan en serie de las transacciones en ejecución
    • 15. Concurrencia - Planificador Seriable -
      • Un planificador para transacciones T 1 , T 2 , ..., T n es seriable si existe una permuta (i 1 , i 2 , ..., i n ) de (1, 2, ..., n), tal que el estado de la BD que resulte de efectuar las llamadas de BD en la secuencia del planificador es el mismo que el alcanzado si se corren las transacciones en aislamiento en el orden Ti 1 , Ti 2 , ..., Ti n
      • El resultado será equivalente al de la ejecución en algún orden arbitrario, escogido por la BD .
    • 16. Concurrencia - Prueba de Seriabilidad por Conflictos -
      • Dos operaciones de un plan están en conflicto si cumplen las siguientes condiciones:
        • Pertenecen a diferentes transacciones
        • Tienen acceso al mismo elemento
        • Al menos una de las operaciones es de escritura
    • 17. Concurrencia - Prueba de Seriabilidad por Conflictos -
      • Crear un nodo Ti en el Grafo de Precedencia , para cada transacción en el plan P
      • Cuando Tj ejecuta una orden read(X) después que Ti ejecute una orden write(X) crear un arco (Ti  Tj) en el grafo
      • Cuando Tj ejecuta una orden write(X) después que Ti ejecute una orden read(X) crear un arco (Ti  Tj) en el grafo
      • Cuando Tj ejecuta una orden write(X) después que Ti ejecute una orden write(X) crear un arco (Ti  Tj) en el grafo
      • El plan P es serializable si y solo si el grafo de precedencia no tiene ciclos
    • 18. Planes y sus Grafos de Precedencia tiempo T1 T2 X PLAN A En T1 se transfieren reservas de un avión a otro En T2 simplemente se reserva asientos en un avión T1 T2 Read X X:= X-N Write X Read Y Y:= Y + N Write Y Read X X:= X + M Write X
    • 19. Planes y sus Grafos de Precedencia tiempo T1 T2 X PLAN B T1 T2 Read X X:= X + M Write X Read X X:= X-N Write X Read Y Y:= Y + N Write Y
    • 20. Planes y sus Grafos de Precedencia tiempo T1 T2 X PLAN C X *** ACTUALIZACION PERDIDA : El valor de X es incorrecto, el numero de asientos es inconsitente T1 T2 Read X X:= X-N Read X X:= X + M Write X Read Y Write X *** Y:= Y + N Write Y
    • 21. Planes y sus Grafos de Precedencia tiempo T1 T2 PLAN D X T1 T2 Read X X:= X-N Write X Read X X:= X + M Write X Read Y Y:= Y + N Write Y
    • 22. Control de Concurrencia
      • Métodos estándar para garantizar la seriabilidad:
            • Bloqueos
            • Marcas de Tiempo
            • Multiversión
            • Validación o Certificación (Protocolos optimistas)
    • 23. Control de Concurrencia: Bloqueo El bloqueo asegura que un objeto que va a ser utilizado por una transacción no cambie de manera impredecible, si esto puede afectar la confiabilidad del resultado. El efecto del bloqueo es no permitir que otras transacciones tengan acceso al objeto. Bloqueo Exclusivo : Si una Transacción A tiene un bloqueo X sobre el objeto R, cualquier otra Transacción B que solicite un bloqueo (de cualquier tipo) sobre R, entrará en un estado de espera, hasta que A libere el bloqueo sobre R. Bloqueo Compartido : Si una Transacción A tiene un bloqueo S sobre el objeto R: Si otra Transacción B solicita un bloqueo X sobre R, entrará en un estado de espera, hasta que A, libere a R. Si en cambio B, solicita un bloqueo S, su solicitud será concedida X: escritura, S:lectura
    • 24. Control de Concurrencia Bloqueo y operaciones sobre Registros N: Hay conflicto, la transacción B entra en espera. S: Compatibilidad, se concede el bloqueo solicitado por B X S X N N S N S A B
    • 25. Protocolos de Bloqueo
      • Reglas que indican el momento en que una transacción puede bloquear o desbloquear un elemento de la BD.
      • Si T i solicita un bloqueo de un tipo M sobre un elemento R, se le concede si:
        • No hay otra transacción con bloqueo sobre R que esté en conflicto con M
        • No hay otra transacción esperando un bloqueo sobre R, solicitado antes que T
        • Evita el fenómeno de inanición para T i
    • 26. Protocolos de Bloqueo
      • Bloqueo de dos fases:
      • Fase de Crecimiento: una transacción puede obtener bloqueos pero no puede liberarlos ni rebajar su intensidad
      • Fase de decrecimiento: una transacción puede liberar bloqueos pero no puede obtener ninguno nuevo.
      • Si se retienen los bloqueos hasta completar la transacción se conoce como bloqueo estricto de dos fases
    • 27. Control de Concurrencia Bloqueo Mutuo, Punto Muerto o Interbloqueo : tiempo Transacción A Transacción B Solicita bloqueo X sobre R1 - concedido - Solicita bloqueo X sobre R2 - concedido - Solicita bloqueo X sobre R2 Esperar Solicita bloqueo X sobre R1 esperar esperar esperar esperar -------- --------
    • 28. Control de Concurrencia El problema de la “lectura sucia”. tiempo Transacción A Transacción B Leer R ($250) Actualizar R= R-20 ($230) Leer R ($230) rollback Actualizar R=R-30 ($200) commit
    • 29. Solución de bloqueo para la “lectura sucia” tiempo Transacción A Transacción B Obtener bloqueo S para R - concedido Leer R ($250) Obtener bloqueo X para R – concedido Actualizar R= R-20 ($230) Obtener bloqueo S para R – esperar rollback - esperar - Bloqueo concedido Leer R ($250) Obtener bloqueo X para R - concedido Actualizar R=R-30 ($220) commit
    • 30. Control de Concurrencia El problema de la “lectura irrepetible” tiempo Transacción A Transacción B Leer R ($250) Leer R ($250) Actualizar R=R-30 ($220) commit Leer R ($220) ¡interferencia detectada!
    • 31. Solución de bloqueo para la “lectura irrepetible” tiempo Transacción A Transacción B Obtener bloqueo S para R – concedido Leer R ($250) Obtener bloqueo S para R – concedido Leer R ($250) Obtener bloqueo X para R - esperar Leer R ($250) esperar (lectura repetible) esperar ............... ....................
    • 32. Control de Concurrencia El problema de la aparición de “fantasmas”, resumen incompleto o análisis inconsistente tiempo Transacción 1 Transacción 2 Traer C 1 (40):Suma=40 Traer C 2 (50):Suma=90 Traer C 3 (30) Actualizar C 3 (20) Traer C 1 (40) Actualizar C 1 (50) COMMIT Traer C 3 (20):Suma=110
    • 33. Solución de bloqueo para el problema de la aparición de “fantasmas” Transacción 1 Transacción 2 Obtener bloqueo S sobre C - concedido Traer C 1 (40):Suma=40 Traer C 2 (50):Suma=90 Obtener bloqueo X sobre C - esperar Traer C 3 (30):Suma=120 Esperar commit esperar Conceder bloqueo .............. ..............
    • 34. Control de Concurrencia
      • El bloqueo estricto de dos fases evita los problemas de lectura sucia , lectura irrepetible y aparición de fantasmas , pero no evita el punto muerto o interbloqueo
      • Niveles de Aislamiento:
      • Especifican la cantidad de interferencia tolerable:
        • Lectura no Confirmada : Operación sin bloqueos y 3 violaciones
        • Lectura Confirmada : Bloqueo X para actualizaciones, sin bloqueo S. Evita lectura sucia
        • Lectura Repetible: Bloqueos X y S (sobre objetos individuales). Evita lectura sucia y no repetibles.
        • Serializable : Bloquea criterios de búsqueda que evitan lecturas sucias, lecturas no repetibles ni fantasmas
    • 35. Nivel de Aislamiento / Interferencia Nivel de Aislamiento Situación de Interferencia Lectura sucia Lectura no repetible Fantasma Lectura no registrada Posible Posible Posible Lectura registrada No posible Posible Posible Lectura repetible No posible No posible Posible Seriable No posible No posible No posible
    • 36. Seriabilidad por marcas temporales
      • Asegura la secuencialidad asignando un orden entre todo par de transacciones:
      • Por el reloj del sistema
      • Usando un contador lógico
      • Si la marca de MT(T i ) es menor que MT(T j ), asegura que la planificación a ejecutar equivale a una secuencial, con Ti antes que T j
      • Asegura la ausencia de interbloqueos
    • 37. Seriabilidad por marcas temporales Se asocia a cada tupla dos valores de marca temporal: t u es la marca temporal de la transacción más reciente que ha actualizado o creado la tupla t r es la marca temporal de la transacción más reciente que ha observado la tupla Obsérvese que siempre t u  t r (una transacción siempre observa la tupla antes de actualizarla)
    • 38. Seriabilidad por marcas temporales Si la transacción t solicita leer una tupla: Si t >= t u  se ejecuta la operación leer y se actualiza t r por max ( t , t r ) Si t < t u  una transacción más reciente (posterior en el tiempo) ya escribió el valor de la tupla, antes de que t tuviera oportunidad de leerla. T se retrocede y vuelve a iniciarse con una marca t’ más grande.
    • 39. Seriabilidad por marcas temporales Si t solicita actualizar una tupla: Si t  t r  se ejecuta la actualización, dado que ninguna transacción más reciente que t ha leído siquiera la tupla Si t < t r ó t < t u  se retrocede (rollback) la transacción t y se reinicia con una marca temporal mayor, porque alguna transacción posterior a t ya leyó o escribió la tupla antes de que t pueda hacerlo Si un rollback comprende la reinstalación de valores previos, el rollback debe tener una marca de hora nueva, que actualizará t u y t r de la tupla reinstalada
    • 40. Prevención de Interbloqueos
      • Evitar esperas cíclicas, ordenando las peticiones de bloqueo o exigiendo que todos los bloqueos se adquieran juntos
      • Realizar retrocesos de las transacciones en lugar de esperar un bloqueo, si éste puede llevar potencialmente a un interbloqueo.
    • 41. Prevención de interbloqueos Esperar o Morir Si T i solicita un elemento que posee T j , T i puede esperar sólo si T i < T j (T i es más antigua que T j ) en otro caso T i se retrocede (muere) Herir o Esperar Si T i solicita un elemento que posee T j , T i espera sólo si T i > T j (T i es más reciente que T j ) ; en otro caso T j se retrocede (T i hiere a T j ). No-espera Si Ti no puede obtener un bloqueo se aborta de inmediato y se reinicia después de un cierto lapso sin comprobar si ocurriría o no un bloqueo mortal Espera Cautelosa Si Ti solicita un elemento que posee Tj, Ti espera sólo si Tj no está detenida (no está esperando que se libere ningún otro elemento bloqueado); en caso contrario Tj aborta.
    • 42.
      • Transaction Log
      • Es una tabla del catálogo de la BD. Contiene una lista secuencial de todas las modificaciones a cada objeto dentro de la BD (bitácora), así como también toda la información necesaria para mantener la integridad de los datos.
      • Es compartido por todos los usuarios de una BD.
      • Los datos se escriben primero en esta tabla y luego en las tablas correspondientes de la BD.
      Recuperación
    • 43. Transaction Log Programa de Aplicación DBMS Acceso Base de Datos Transaction Log (a) (b) Actualización de los datos (a) (b) Se modifican los datos (a) ante-imagen (b) post-imagen
    • 44. Recuperación
      • Transaction Log con actualizaciones diferidas:
      • Cuando comienza una transacción T se registra su inicio en el log
      • Durante la transacción, la escritura de un nuevo valor para cualquier registro provoca la escritura de un registro en el log.
      • Cuando todas las acciones de T se ejecutan exitosamente, se escribe el registro COMMIT en el log
      • Por último, se realizan las operaciones de escritura en la BD desde los registros del log
    • 45. Recuperación
      • Recuperación con actualizaciones diferidas:
      • Cuando ocurre un fallo, el DBMS examina el log para determinar las transacciones que deben rehacerse (REDO):
      • Si el log registra el inicio y el fin de la transacción T (hasta el commit), significa que la transacción T se debe volver a aplicar.
      • Si no figura el commit en el log, la transacción T no se completó, y al reiniciar no es necesario tomar acción, pues la BD permanece consistente. T tiene que reiniciarse.
    • 46. Recuperación
      • Transaction Log con actualizaciones inmediatas:
      • 1° Cuando comienza una transacción T se registra su inicio en el log
      • 2° Durante la transacción, la escritura de un nuevo valor para cualquier registro provoca la escritura de un registro en el log (primero) y luego en la BD
      • 3° Cuando todas las acciones de T se ejecutan exitosamente, se escribe el registro COMMIT en el log
    • 47. Recuperación
      • Recuperación con actualizaciones inmediatas:
      • Cuando ocurre un fallo, el DBMS examina el log para determinar las transacciones que deben rehacerse (REDO) o deshacerse (UNDO):
      • Si el log registra el inicio y el fin de la transacción T (hasta el commit), significa que la transacción T se debe volver a aplicar (REDO)
      • Si no figura el commit en el log, la transacción T no se completó, y al reiniciar es necesario restablecer los valores antiguos de los datos (UNDO). T tiene que reiniciarse.
    • 48. Recuperación de la BD
      • Progresiva: Se restaura el último backup y se aplican luego todas las transacciones válidas desde la bitácora, aplicando las imágenes posteriores (post-imágenes).
      • Regresiva: Se deshacen los cambios efectuados por transacciones erróneas o procesadas parcialmente, mediante la aplicación de las imágenes anteriores. Las transacciones válidas que estaban en proceso al momento de la falla se vuelven a iniciar.
    • 49. Recuperación
      • Recuperación del Sistema y de los Medios de Almacenamiento
        • Fallas del Sistema (por ejemplo corte del fluido eléctrico), las cuales afectan a todas las transacciones que se están efectuando pero no dañan los datos físicos en la base de datos.
        • Fallas de los medios de almacenamiento (por ejemplo pérdida de direcciones o pistas dañadas), que sí causan daño a la base de datos o a una porción de ella.
        • Falla computador (error de hardware o de software);
        • Error en transacción (división entre 0, overflow, malos parámetros, etc.);
        • Catástrofes.
    • 50. Recuperación - Fallas del Sistema - Se pierde el contenido de la memoria principal y de las áreas de almacenamiento temporal. Por lo tanto, se perderá el estado preciso de la transacción que se está ejecutando y no podrá ser completada con éxito. Por este motivo será preciso anularla (retroceder) cuando se reinicie el sistema (aplicación de los registros ante-imagen desde el Log de transacciones). Para reducir este proceso, se introducen periódicamente Puntos de Revisión o Verificación .
    • 51. Recuperación
      • Fallas del Sistema
      • Punto de Revisión (checkpoint):
      • Detiene el inicio de nuevas transacciones
      • Escribe todos los registros del log de transacciones que radican en la memoria volátil (los buffers de la memoria principal), en almacenamiento estable (en disco)
      • Graba físicamente un registro de Punto de Revisión especial en la bitácora física. Este incluye una lista de todas las transacciones en ejecución en ese momento.
      • Reactiva las transacciones en ejecución
    • 52. Recuperación
      • Deberá anularse las transacciones T3 y T5 (UNDO)
      • Deberá aplicarse nuevamente las transacciones T2 y T4 (REDO)
      • La transacción T1 no interviene en el proceso de reinicio, porque sus modificaciones ya estaban grabadas en la BD en el momento tv, como parte del proceso de punto de revisión.
      T1 T2 T3 T4 T5 tv tf Falla del Sistema Punto de verificación
    • 53. Recuperación
      • Fallas de los Medios de Almacenamiento
      • Se pierden direcciones del disco o se producen averías en las pistas o falla el controlador del disco. La consecuencia es la destrucción física de una porción de la base de datos.
      • La recuperación de una falla semejante, implica en esencia, cargar de nuevo o restaurar (restore) la base de datos a partir de una copia de respaldo (backup) y después utilizar el transaction log, para realizar de nuevo todas las transacciones terminadas desde que se efectuó este último backup (aplicación de los registros post-imagen)
    • 54.
      • Seguridad en la BD implica asegurar que los usuarios están autorizados para llevar a cabo las tareas que tratan de realizar
        • Subsistema de Seguridad del DBMS
        • Aspectos éticos y legales relativos al derecho de acceso a cierta información
        • Políticas gubernamentales o institucionales relacionadas con la clase de información que no debe estar disponible para el público, como la clasificación de crédito o el historial médico: la empresa decide quiénes tienen acceso y a qué.
        • Identificación de niveles de seguridad y de clasificar los datos y usuarios según estos niveles: top secret, secreto, confidencial, no confidencial
      Seguridad en Bases de Datos
    • 55. Seguridad en el DBMS
      • Mecanismos de Seguridad:
        • Discrecionales : conceden privilegios a los usuarios para acceder a elementos específicos de la BD en un determinado modo (lectura, escritura o actualización)
        • Obligatorios : imponen seguridad de múltiples niveles clasificando los datos y los usuarios. Permitir a los usuarios de cierto nivel acceder a los elementos de información de su mismo nivel o de niveles inferiores
    • 56. La seguridad de la BD y el DBA
      • Creación de Cuentas
        • Para crear cuentas y contraseñas para un usuario o grupo con el fin de que puedan acceder al DBMS
      • Concesión de Privilegios
        • Para conceder ( GRANT ) ciertos privilegios ( authority ) a ciertas cuentas
      • Revocación de privilegios ( REVOKE )
      • Asignación de niveles de seguridad
        • Asigna cuentas de usuario al nivel de clasificación de seguridad apropiado
    • 57. Protección de Acceso y Auditoría de la BD
      • Cuando un usuario entra ( log in ), el DBMS puede registrar su nombre y asociarlo al terminal de donde se conectó. Todas las operaciones sobre la BD de ese terminal se asocian a la cuenta del usuario hasta que éste salga del sistema.
      • Se puede modificar el log de transacciones (diario del sistema), ampliando las entradas para incluir la cuenta de usuario y el terminal desde donde se aplicó cada operación. El diario del sistema se denomina en esos casos diario de auditoría
    • 58. Privilegios Discrecionales
      • A Nivel de Cuenta
        • Se asignan a cada cuenta de usuario, independientemente de las relaciones de la BD
        • Ejemplos: CREATE, ALTER, DROP, MODIFY, SELECT
      • A Nivel de Relación (o tabla):
        • Controla privilegios para acceder a cada relación individual de la base de datos o a columnas concretas de ellas.
        • Ejemplos: SELECT (lectura), MODIFY (update, insert, delete)
    • 59. Seguridad – Consideraciones Adicionales
      • Controles Físicos: Límite de accesos a la sala de máquinas (servidores).
      • Problemas Operativos: Mantenimiento de los passwords, su confidencialidad y tiempo de validez.
      • Controles del equipo: Claves para protección de áreas de almacenamiento.
      • Seguridad de Sistema Operativo: Mantenimiento de los espacios de almacenamiento, compactación.
    • 60. Bibliografia
      • Fundamentos de Sistemas de Base de Datos. Ramez Elmasri, Shamkant Navathe

    ×