Manejo de transacciones

Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.

Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado.

Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.

• BEGIN TRAN: Especifica que va a empezar una transacción.

• COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con éxito.

• ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad.

En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.

Un ejemplo de transacción

Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la atomicidad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

Estructura de las transacciones

 La estructura de una transacción usualmente viene dada según el modelo de la transacción, estas pueden ser planas (simples) o anidadas.

Transacciones planas: Consisten en una secuencia de operaciones
primitivas encerradas entre las palabras clave BEGIN y END. Por
ejemplo: 

            BEGIN _TRANSACTION Reservación

              ….

             END.

Transacciones Anidadas: Consiste en tener transacciones que dependen de otras, estas transacciones están incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transacción de nivel superior puede producir hijos (subtransacciones) que hagan más fácil la programación del sistema y mejoras del desempeño.

En las transacciones anidadas las operaciones de una transacción pueden ser así mismo otras transacciones. Por ejemplo:

 Una transacción anidada dentro de otra conserva
las mismas propiedades que las de su padre, esto implica, que puede contener
así mismo transacciones dentro de ella. Existen restricciones obvias
en una transacción anidada: debe empezar después que su padre
y debe terminar antes que él. El compromiso de una subtransaccion es
condicional al compromiso de su padre, si el padre de una o varias subtransacciones  aborta,
las subtransacciones hijas también serán abortadas. Las transacciones
anidadas brindan un nivel más alto de concurrencia entre transacciones.
Ya que una transacción consiste de varias transacciones es posible tener
mayor concurrencia dentro de una sola transacción.

Así también, es posible recuperarse de fallas de forma independiente de cada sub transacción. Esto limita el daño a una parte más pequeña de la transacción, haciendo que el costo de la recuperación sea el menor.

 También se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces, a este tipo de transacciones se les conoce como Generales .Por el contrario, si se restringe o impone que un dato debe ser leído antes de que pueda ser escrito entonces se tendrán transacciones Restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un modelo de acción para transacciones restringidas en donde se aplica aún más la restricción de que cada par < read, write > tiene que ser ejecutado de manera atómica.

Operaciones de una transacción

• Inicio de Transacción: Operación que marca el momento en el que una transacción comienza a ejecutarse.

• Leer o Escribir: Operaciones de lectura/escritura de elementos de la base de datos.

• Fin de la Transacción: Se verifica si la transacción debe abortarse por alguna razón.

• Confirmar (COMMIT): La operación termino con éxito.

• Abortar (ROLLBACK): La transacción termino sin éxito.

Estados de una Transacción

• Transacción Activa: se encuentra en este estado justo después de iniciar su ejecución.

• Transacción Parcialmente Confirmada: en este punto, se efectúan diferentes operaciones de verificación para asegurar que la transacción no interfiera con otras transacciones en ejecución.

• Transacción Confirmada: Ha concluido su ejecución con éxito.

• Transacción Fallida: En este caso, es posible que la transacción deba ser cancelada.

• Transacción Terminada: indica que la transacción a abandonado el sistema.

Representación de los estados de una transacción

Problemas de concurrencia

La concurrencia es un fenómeno que se presenta en varios contextos. Uno de ellos es la multiprogramación ya que el tiempo del procesador es compartido dinámicamente por varios procesos. Otro caso son las aplicaciones estructuradas, donde la programación estructurada se implementa como un conjunto de procesos concurrentes. Y por último se tiene que la misma estructuración recién mencionada es utilizada en el diseño de los sistemas operativos, los cuales se implementan como un conjunto de procesos.

El termino concurrencia se refiere al hecho de que los DBMS (SISTEMAS DE ADMINISTRACION DE BD) permiten que muchas transacciones puedan accesar a una misma base de datos a la vez.

En un sistema de estos se necesitan algún tipo de mecanismos de control de concurrencia para asegurar que las transacciones concurrentes no interfieran entre sí.

En sistemas multiusuario, es necesario un mecanismo para controlar la concurrencia. Se pueden producir inconsistencias importantes derivadas del acceso concurrente, como por ejemplo, el problema de la operación perdida.

En un sistema de biblioteca, existe un campo que almacena el número de copias disponibles para préstamo. Este campo debe incrementarse en uno cada vez que se devuelve un ejemplar del libro y disminuirse en uno cada vez que se presta un ejemplar.

Si existen varias bibliotecarias, una de ellas inicia la transacción t1, leyendo la variable numero ejemplares (n), cuyo contenido se guarda en la variable n1. Tiempo después, otra bibliotecaria podría leer la misma variable incrementándola en una unidad, transacción t2. Después, la transacción t1 añade una unidad a esa variable y la actualiza, el resultado es erróneo, ya que la variable N debería haber aumentado en 2 unidades, y solo ha aumentado en una. La transacción t2 se ha perdido.

Consiste en controlar la interacción entre los usuarios concurrentes para no afectar la inconsistencia de los datos.

Cuando se trabajaba con manejadores de archivos y se estaba actualizando un determinado registro, ningún otro usuario podía actualizar el mismo archivo; aunque el registro a trabajar fuera otro. Con esta característica, ya más de un usuario puede accesar a un mismo registro y actualizarlo.

El objetivo fundamental del control de concurrencia de base de datos es garantizar que la ejecución concurrente de transacciones no resulta en una pérdida de consistencia de la base de datos.

La concurrencia se da cuando dos transacciones están interconectadas, lo que es común en un entorno multiusuario. Así pues en un entorno de multiprogramación es posible ejecutar varias transacciones de manera concurrente.

Planificación

Sean A = 200 bs y B = 400

Planificaciones

• Conservar el orden de la transacción.

• P1 y P2 son secuénciales.

• N! Plantaciones válidas para N transacciones.

• No consistencia

• Dejar concurrencia al SO.

• Se puede asegurar la consistencia.

• Secuencialidad

• El sistema debe controlar la ejecución concurrente de las transacciones para asegurar que el estado de la base sigue siendo consistente.

Planificaciones que aseguran consistencia

• Se debe tener en cuenta:

• No se verifican todas las instrucciones, sólo las operaciones de lectura y de escritura de la base de datos.

• Cuando se poseen operaciones secuenciales de lectura y de escritura en el mismo punto de la base de datos entonces la planificación puede generar inconsistencias.

• La mejor forma de asegurar planificaciones correctas es asegurando las equivalencias de planificación y esto se logra con dos posibles técnicas: Secuencialidad en cuanto a conflictos y Secuencialidad en cuanto a vistas.

Planificaciones que aseguran consistencia

• Planificación 3: Ejecución concurrente equivalente a la planificación 1.

Secuencialidad en cuanto a conflictos

• Consideremos una planificación P en la cual hay dos instrucciones consecutivas Ii e Ij, pertenecientes a las transacciones Ti y Tj, respectivamente (ij).

• Si Ii e Ij se refieren a diferentes elementos de datos entonces se pueden intercambiar.

• Si Ii e Ij se refieren al mismo elemento de datos Q entonces el orden de aparición se debe tener en cuenta para la planificación. Esto se resume en la siguiente tabla:

• Se concluye que:

• Sólo en el caso que Ii e Ij, son instrucciones leer no tiene importancia el orden de ejecución de las mismas.

Existe conflicto entre Ii e Ij si existen operaciones de diferentes transacciones sobre el mismo elemento de datos, y al menos una de estas instrucciones es una operación Escribir.

EJ: planificación 3

• Planificación 5: Ejecución concurrente equivalente a la planificación 3.

• Planificación 6: Ejecución secuencial equivalente a la planificación 3.

• Al final la Secuencialidad en cuanto a conflictos es equivalente (realizando los intercambios adecuados) a una planificación secuencial como se muestra en la planificación 6. Luego, P5 y P3 son equivalentes en cuanto a conflictos por que P3 se puede transformar en P5 a través de una serie de intercambios. Y P3 es secuenciable en cuanto a conflictos porque es equivalente a una P secuencial, en este caso a P6.

• EJ: planificación 1!= planificación 2 planificación 1!= planificación 2

Esta planificación no es secuenciable en cuanto a conflictos, ya que no es equivalente ni a la planificación secuencial T3, T4 ni a la T4, T3.

• Es posible encontrar dos planificaciones que produzcan el mismo resultado y no sean equivalentes en cuanto a conflictos.

• Ej. 3.

• Esto implica que debería tenerse en cuenta los resultados de las transacciones para las planificaciones, pero esto es costoso.

Administración y respaldo

Políticas para el manejo de respaldos.

• Creación de respaldos.

La política de respaldos se definirá con base en la solución de las siguientes interrogantes:

1.1.1 ¿Qué datos son importantes para la institución y cual es su periodicidad de respaldo?

Los datos a respaldar y su periodicidad de respaldos serán las siguientes: 1.1.1.1 Bitácoras de transacciones: los archivos producto del modo seguro de transacción será respaldados una vez al día al cierre de operaciones ó al momento de menor cantidad de transacciones.

1.1.1.2 Archivo de control: será respaldado una vez al día, creándose dos copias del mismo en caso de que una de ellas llegue a fallar.1.1.1.3 Archivo de inicialización: se respaldará cada vez que sufra alguna modificación en su contenido.

1.1.1.4 Archivos de datos: se respaldarán aquellos archivos de datos críticos para la organización una vez a la semana.

1.1.2 ¿En qué medios de almacenamiento vamos a guardarlos?

Los medios de almacenamiento a utilizar serán cintas magnéticas, CD"s, entre otros.

1.1.2.1 Bitácoras y archivos de datos: la organización basará sus respaldos en la teoría de las tres cintas (hija, madre y abuela). Estas cintas sufrirán un proceso de rotación conforme su uso.

1.1.2.2 Archivo de control y archivo de inicialización: la institución almacenará estos respaldos en CD"s.

1.1.3 ¿Dónde debe estar situada la copia de seguridad?• Los respaldos serán trasladados a un sitio seguro que cumpla con las normas internacionales tanto de confidencialidad de la ubicación del sitio como de calidad del ambiente.

• La divulgación de la ubicación del sitio, así como, la mala administración de las condiciones de operación serán castigadas según las normativas internas de la organización e inclusive vía penal dependiendo del tipo de daño causado.

1.2 Codificación de respaldos.

La codificación de los respaldos se basará en los siguientes aspectos:• Se codificarán los respaldos haciendo uso de un algoritmo de encriptación que brinde la mayor seguridad a los datos.

• La clave para desencriptar la codificación de los respaldos será guardada bajo estrictas normas de seguridad para evitar el plagio.

• La codificación seguirá un estándar preestablecido que facilite la búsqueda de respaldos en caso de que se llegasen a necesitar.• La empresa designará al personal correspondiente para que lleve a cabo la codificación de los respaldos y los capacitará para que cumplan sus funciones de manera adecuada.

• Una vez que se hayan codificado los datos se procederá a llenar el correspondiente registro que haya establecido la empresa.

1.3 Almacenamiento de respaldos.

Se definen los siguientes criterios a evaluar:

1.3.1 Transporte del respaldo.

Deberá realizarse en la fecha y hora establecida por la compañía llenándose el registro que haga constar cuando y a que hora fue entregado el respaldo, además de quién lo entregó y quién lo recibió.

El transporte deberá contar con un clima óptimo para conservar el buen estado de los respaldos.

1.3.2 Hospedaje de la información.

El sitio donde se hospeden los respaldos deberá cumplir con los siguientes aspectos:• Altal seguridad y cerrado a personal no autorizado.

• Clima idóneo en el cual los datos se mantengan seguros tomando en cuenta la temperatura y humedad.

• Instrumentos para constatar las condiciones del cuarto de almacenamiento.• Almacenamiento por los años que indique la regulación interna del país.• Se le permitirá a la organización realizar visitas periódicas para monitorear que se cumpla con las normas establecidas.

• 2. Tipos de respaldos a realizar.

• Según el tipo de archivo y el tipo de empresa se deben realizar diferentes tipos de respaldos.

• 2.1 Respaldo Parcial.

• 2.1.1 Para los archivos de control se debe generar un archivo de rastreo. Dicho archivo debe ser modificado para su futuro uso.

Data base backup

Hace copia de seguridad de una base de datos completa de SQL Server para crear una copia de seguridad de la base de datos, o uno o más archivos o grupos de archivos de la base de datos para crear una copia de seguridad de archivo (BACKUP DATABASE). Además, con el modelo de recuperación completa o con el modelo de recuperación optimizado para cargas masivas de registros, realiza la copia de seguridad del registro de transacciones de la base de datos para crear una copia de seguridad de registros (BACKUP LOG).

SINTAXIS

Backing Up a Whole Database

BACKUP DATABASE { database_name | @database_name_var }

TO [ ,…n ]

[ ] [ next-mirror-to ]

[ WITH { DIFFERENTIAL | [ ,…n ] } ]

[;]

Backing Up Specific Files or Filegroups

BACKUP DATABASE { database_name | @database_name_var }

[ ,…n ]

TO [ ,…n ]

[ ] [ next-mirror-to ]

[ WITH { DIFFERENTIAL | [ ,…n ] } ]

[;]

Creating a Partial Backup

BACKUP DATABASE { database_name | @database_name_var }

READ_WRITE_FILEGROUPS [ , [ ,…n ] ]

TO [ ,…n ]

[ ] [ next-mirror-to ]

[ WITH { DIFFERENTIAL | [ ,…n ] } ]

[;]

Backing Up the Transaction Log (full and bulk-logged recovery models)

BACKUP LOG { database_name | @database_name_var }

TO [ ,…n ]

[ ] [ next-mirror-to ]

[ WITH { | } [ ,…n ] ]

[;]

::=

{

{ logical_device_name | @logical_device_name_var }

| { DISK | TAPE } =

{ 'physical_device_name' | @physical_device_name_var }

}

::=

MIRROR TO [ ,…n ]

::=

{

FILE = { logical_file_name | @logical_file_name_var }

| FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

}

::=

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

[ ,…n ]::=

–Backup Set Options

COPY_ONLY

| { COMPRESSION | NO_COMPRESSION }

| DESCRIPTION = { 'text' | @text_variable }

| NAME = { backup_set_name | @backup_set_name_var }

| { EXPIREDATE = { 'date' | @date_var }

| RETAINDAYS = { days | @days_var } }

–Media Set Options

{ NOINIT | INIT }

| { NOSKIP | SKIP }

| { NOFORMAT | FORMAT }

| MEDIADESCRIPTION = { 'text' | @text_variable }

| MEDIANAME = { media_name | @media_name_variable }

| BLOCKSIZE = { blocksize | @blocksize_variable }

–Data Transfer Options

BUFFERCOUNT = { buffercount | @buffercount_variable }

| MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

–Error Management Options

{ NO_CHECKSUM | CHECKSUM }

| { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

–Compatibility Options

RESTART

–Monitoring Options

STATS [ = percentage ]

–Tape Options

{ REWIND | NOREWIND }

| { UNLOAD | NOUNLOAD }

–Log-specific Options

{ NORECOVERY | STANDBY = undo_file_name }

| NO_TRUNCATE

Al restaurar una copia de seguridad creada por BACKUP DATABASE (una copia de seguridad de datos), se restaura la copia de seguridad completa. Solo una copia de seguridad del registro se puede restaurar hasta un momento o transacción concretos dentro de la copia de seguridad.

LOG

Especifica que solo se realizará la copia de seguridad del registro de transacciones. Se realiza la copia de seguridad del registro desde la última copia de seguridad del registro ejecutada correctamente hasta el final actual del registro.Para poder crear la primera copia de seguridad del registro, debe crear una copia de seguridad completa.

Puede restaurar una copia de seguridad del registro hasta un momento o transacción concretos dentro de la copia de seguridad especificando WITH STOPAT, STOPATMARK o STOPBEFOREMARK en la instrucción RESTORE LOG.

Tablespace backup

Un tablespace es una unidad lógica de almacenamiento dentro de una base de datos oracle. Es un puente entre el sistema de ficheros del sistema operativo y la base de datos. Cada tablespace se compone de, al menos, un datafile y un datafile solo puede pertenecer a un tablespace. Cada tabla o índice de oracle pertenece a un tablespace, es decir cuando se crea una tabla o índice se crea en un tablespace determinado.

Sintaxis:

CREATE [UNDO] TABLESPACE tablespace_name

DATAFILE Datafile_Options Storage_Options ;

Datafile_Options:

'filespec' [AUTOEXTEND OFF]

'filespec' [AUTOEXTEND ON [NEXT int K | M] [MAXSIZE int K | M]]

La opción Autoextend Maxsize es por defecto UNLIMITED si no se especifica valor.

Storage_Options:

DEFAULT [COMPRESS|NOCOMPRESS] STORAGE storage_clause

MINIMUM EXTENT int {K|M}

BLOCKSIZE int K

LOGGING | NOLOGGING

FORCE LOGGING

ONLINE | OFFLINE

PERMANENT | TEMPORARY

EXTENT MANAGEMENT {DICTIONARY |

LOCAL {AUTOALLOCATE | UNIFORM [SIZE int K | M]} }

SEGMENT SPACE MANAGEMENT {MANUAL | AUTO}

DATABASE

Especifica una copia de seguridad completa de la base de datos.Si se especifica una lista de archivos y grupos de archivos, solo se realiza la copia de seguridad de esos archivos o grupos de archivos.Durante una copia de seguridad completa o diferencial de una base de datos, SQL Server realiza la copia de seguridad de una parte suficiente del registro de transacciones para producir una base de datos coherente cuando se restaure la base de datos.

TECNICAS Y RECUPERACION DE BASE DE DATOS

Concepto de recuperación

Recuperarse al fallo de una transacción significa que la base de datos se restaura al estado coherente más reciente, inmediatamente anterior al momento del fallo para esto el sistema guarda las información sobre los cambios de las transacciones esta información se guarda en el registro del sistema.

1. Si hay un fallo como la caída del disco, el sistema restaura una copia se seguridad del registro, hasta el momento del fallo.

2. Cuando el daño se vuelve inconsistente, se pueden rehacer algunas operaciones para restaurar a un estado consistente. En este caso no se necesita una copia archivada.

Técnicas de recuperación

Existen diversos métodos para la restauración de una base de datos corrupta a un estado previo libre de daños. El tipo de técnica de recuperación usado en cada situación determinada depende de varios factores, incluyendo los siguientes:

La extensión del daño sufrido por la base de datos. Por ejemplo, si se encuentra que ha sido un único registro el que ha sufrido daños, la técnica de recuperación es trivial, en comparación con el procedimiento de restauración necesario después de un choque de una cabeza.

El nivel de actividad de la base de datos. Las técnicas de recuperación son fáciles de implementar en bases de datos que se modifican con escasa frecuencia. Por el contrario, resulta mucho más difícil y caro el diseño de técnicas de recuperación para bases de datos que se están actualizando continuamente. En este último caso, suele tratarse también de bases de datos de gran importancia para sus usuarios, por lo que es de vital importancia que la recuperación sea rápida.

La naturaleza de la información de la base de datos. Para algunos tipos de datos, la pérdida de una pequeña cantidad de información puede no resultar particularmente crítica. En otras situaciones, tales como bases de datos financieras, no es aceptable ninguna pérdida de datos, independientemente de su cuantía. Los dos tipos de circunstancias requieren muy diferentes aproximaciones en lo que se refiere a fiabilidad y recuperación.

Copias de seguridad de la base de datos

Para poder efectuar cualquier tipo de restauración de una base de datos, es necesaria la realización de copias de seguridad (backups) de la base de datos de forma periódica. Este proceso consiste en la escritura de una copia exacta de la base de datos en un dispositivo magnético separado del que contiene a la propia base de datos. En los sistemas más grandes, este dispositivo suele ser una cinta magnética. En los sistemas basados en microordenadores, puede tratarse de un cartucho de cinta de casete, o de uno o más discos flexibles. Habitualmente, mientras se está generando una copia de seguridad es preciso detener todas las demás actividades de la base de datos.

A menudo se realiza más de una única copia, que luego se almacenan en un lugar lejos del ordenador, y alejadas entre sí, con el fin de que si algún tipo de suceso catastrófico produjese la destrucción del ordenador, al menos una de las copias en cinta no resultase dañada por el mismo suceso. Cuando se trata de bases de datos críticas, como las que guardan información bancaria, suele guardarse al menos una copia en un lugar alejado bastantes kilómetros de la instalación del ordenador. Además, no es raro que se mantengan varias generaciones de copias, para añadir un nivel de seguridad adicional.

Un método sencillo de recuperación

El método más simple de recuperación de una base de datos es el expuesto a continuación. Periódicamente, quizá una vez cada día, se realiza una copia de seguridad de la base de datos. Comenzando a partir del momento en el que se hace cada copia, se lleva manualmente una lista física, o diario (log), de todos los cambios subsiguientes que se efectúan en la base de datos. Si la base de datos es dañada o destruida, para recuperarla es preciso seguir la secuencia de pasos siguiente:

– Reparar el problema de hardware o software que causó la caída del sistema.

– Restaurar la base de datos a partir de la copia de seguridad más reciente. Esto no restaura la base de datos a su estado en el instante en el que tuvo lugar el daño.

– Volver a introducir manualmente en la base de datos los cambios realizados desde que se hizo la copia, usando la lista física.

Diarios de transacciones y restauración/reejecución

Una extensión de la técnica anterior consiste en el mantenimiento automático de un fichero de ordenador, que contenga una lista de los cambios hechos en la base de datos entre dos copias de seguridad consecutivas. Esta lista se conoce como diario de transacciones, y se mantiene siempre en un dispositivo físico diferente del que almacena a la propia base de datos. Habitualmente se utiliza para este propósito una unidad de cinta magnética, o una unidad de disco diferente. La razón para usar un dispositivo separado es simplemente que si la base de datos resulta dañada, la causa de dicho daño no tiene por qué afectar a los datos almacenados en un dispositivo físico diferente.

La forma de utilizar un diario de transacciones como ayuda para la restauración es idéntica a la que ya se ha descrito, excepto en la última etapa. En este caso, la restauración de las transacciones anotadas en el diario las realiza una utilidad del SGBD, que devuelve la base de datos al estado inmediatamente anterior al momento del fallo. Este proceso se conoce habitualmente como restauración/reejecución.

La clave para el uso con éxito de un diario de transacciones radica en la capacidad del SGBD para reconocer el comienzo y el final de cada transacción. Para cada transacción de la base de datos, el diario contiene marcas de "comienzo de transacción" y "final de transacción", además de una grabación de los cambios individuales realizados en la base de datos para dicha transacción. La marca de "final de transacción" se graba en el diario sólo después de la conclusión con éxito de la transacción. Así, si una caída del sistema interrumpe el procesamiento de una transacción, no aparecerá ninguna marca de "final de transacción" en el diario. Cuando se realice un proceso de restauración/reejecución, sólo se restaurarán a partir del diario las transacciones completadas, y se generará un informe impreso, que indicará qué transacciones no se han completado y, por tanto, no han sido introducidas en la base de datos.

Para bases de datos extremadamente activas, la técnica de restauración/reejecución puede resultar inadecuada, ya que el reprocesamiento del diario puede llevar varias horas, durante las cuales la base de datos no puede ser usada con normalidad. Si una base de datos es muy activa, esta no disponibilidad puede revelarse intolerable, y será preciso emplear otras técnicas de restauración.

Recuperación por retroceso

La recuperación por retroceso resulta útil en situaciones en las que el procesamiento de la base de datos se ve interrumpido, pero la base de datos en sí no resulta dañada de forma alguna. Un ejemplo de esto podría ser algún tipo de fallo que produzca una terminación anormal de la ejecución del SGBD. Las transacciones en marcha podrían ser abortadas antes de su finalización, y los registros asociados a las mismas quedarían en estados desconocidos, aunque el resto de la base de datos no se vería afectada.

La técnica de recuperación por retroceso requiere que el diario de transacciones contenga imágenes iniciales de cada registro de la base de datos que haya sufrido modificaciones desde la última copia de seguridad. Una imagen inicial es una copia de un registro tal como se encontraba inmediatamente antes de ser modificado como parte de una transacción, es decir, justo antes del inicio de dicha transacción.

El procesado de recuperación por retroceso conlleva que después de que se haya colocado nuevamente en funcionamiento el SGBD, con la base de datos correcta, tal como estaba cuando tuvo lugar la interrupción, se pase a procesar el diario de transacciones. Para cada transacción incompleta anotada en el diario se reemplaza la versión actual del registro de la base de datos por la imagen inicial correspondiente. Así, cada registro de la base de datos que ha sufrido modificaciones durante una transacción no completada es devuelto a su estado inicial, antes del comienzo de la transacción. El resultado de este proceso es la eliminación de la base de datos de todas las huellas de transacciones incompletas, es decir, las que estaban en marcha cuando tuvo lugar la caída.

Para que la recuperación por retroceso pueda funcionar, el diario de transacciones debe contener marcas de "comienzo de transacción" y de "final de transacción" para cada transacción. Cuando se realiza un proceso de recuperación, las transacciones incompletas se detectan por la ausencia de una marca de "final de transacción".

La cantidad de esfuerzo necesaria para efectuar una recuperación por retroceso puede ser mucho menor que la que se necesita para una recuperación por restauración/reejecución. Por ejemplo, supongamos que se han grabado 1000 transacciones en un diario entre el momento en que se hizo la última copia de seguridad y el instante del fallo (un fallo que no dañe a la base de datos). Supongamos asimismo que en el instante del fallo se encuentran en marcha 5 transacciones. Con la técnica de restauración/reejecución, la base de datos debe ser restaurada a partir de la última copia, por lo que habrá que procesar 995 transacciones. Por su parte, una recuperación por retroceso parte de la base de datos tal como se encuentra, limitándose a deshacer los efectos de las 5 transacciones incompletas.

Recuperación por adelanto

El adelanto es otro tipo de mecanismo de recuperación, que se usa a menudo cuando una base de datos ha sido dañada y debe, por tanto, ser restaurada a partir de una copia de seguridad. Se parece a la técnica del retroceso, y comparte con ésta la ventaja de que es mucho más rápida que el método de restauración/reejecución. Requiere que el diario de transacciones contenga una imagen final de cada registro de la base de datos que ha sido modificado desde la última copia. Una imagen final es una copia de un registro, inmediatamente después de haber sido modificado como parte de una transacción, es decir, en el estado en que se encuentra al finalizar dicha transacción.

En su forma más simple, esta técnica consta de dos etapas:

1. Después de un fallo que produce un daño en la base de datos, se utiliza la última copia de seguridad para restaurarla.

2. Se procesa el diario, a partir del punto en que se efectuó la última copia de seguridad. Para cada transacción completada anotada en el diario, se sustituye la versión actual del registro de la base de datos por la imagen final correspondiente.

Esta técnica es considerablemente más rápida que la de restauración/reejecución, ya que la sustitución de un registro por su imagen final lleva mucho menos tiempo que el proceso de recreación de la base de datos completa a partir de la copia de seguridad.

Existen variaciones del método de adelanto básico, diseñadas para mejorar aún más la velocidad de la recuperación de la base de datos. Por ejemplo, el conjunto completo de imágenes finales puede ordenarse primero por número de registro. De esta forma, después sólo hace falta escribir en la base de datos la última imagen final de cada registro. Para los registros con varias modificaciones anotadas en el diario, esto puede suponer un considerable ahorro en tiempo de procesamiento.

Seguridad y control de acceso en bases de datos

MECANISMOS DE SEGURIDAD

Son los mecanismos utilizados para implementar las reglas establecidas en la política de seguridad. Pueden dividirse en tres categorías: prevención, detección y recuperación. En cada grupo existen varios mecanismos de seguridad cuya misión consiste en paliar o reducir las amenazas concretas a la seguridad.

Los mecanismos de prevención intentan evitar que se produzcan violaciones de seguridad durante el funcionamiento del sistema (p.ej., limitando el acceso físico al sistema). Los mecanismos de detección se utilizan para detectar intentos y violaciones de la seguridad en el momento o después de producirse. Los mecanismos de recuperación hacen su aparición cuando se ha producido una violación de seguridad, y su función es la de devolver el sistema al estado en que se encontraba antes del ataque.

Los principales y más importantes mecanismos de seguridad son
los de autentificación e identificación, control de acceso, separación,
comunicación y detección y recuperación.

AUTENTIFICACIÓN E IDENTIFICACIÓN

Un mecanismo de autentificación hace posible identificar de forma unívoca, lo que es necesario antes de que otros mecanismos del sistema tomen decisiones en función precisamente de la identidad. Ya que se trata de un mecanismo básico para la mayoría de los otros sistemas de seguridad es necesario que sea lo más fiable y robusto posible.

Antes de iniciar el proceso de autentificación es necesaria una identificación única, que debe ser algo muy difícil de copiar o imitar por terceros. Ejemplos típicos son las tarjetas magnéticas, tarjetas chip, la huella dactilar o incluso la lectura de la retina de un usuario. El proceso de validación de una identidad es lo que se denomina autentificación. Para garantizar la máxima seguridad debe contarse con un administrador de seguridad, responsable de crear, mantener y controlar el uso de las identidades aceptadas en el sistema. Una buena forma de aumentar el grado de seguridad del sistema es crear identidades con fecha de caducidad, es decir, delimitadas en el tiempo.

La autentificación puede clasificarse en simple o fuerte. En la autentificación simple los mecanismos utilizados son los habituales disponibles en la mayoría de sistemas: el uso de un identificador y una contraseña. La autentificación fuerte implica el uso de mecanismos que se no muestran al exterior durante el proceso de autentificación. Son, por ejemplo, los mecanismos de encriptación asimétrica en los que sólo una parte sabe cómo codificar un mensaje mientras varios tienen la clave para descodificarlo. El proceso de autentificación puede darse a dos bandas o por parte de terceros.

En el primer caso se trata de una entidad cliente que debe ser autentificada por otra entidad servidor. La forma más sencilla de llevar a cabo este proceso es que el cliente envíe su contraseña al servidor y que éste la compruebe en sus registros. Este método tiene dos problemas: el cliente no sabe si está dialogando con el servidor adecuado y la contraseña puede ser capturada en la transmisión (amenaza pasiva). Formalmente, este método se conoce como Procedimiento de autentificación simple desprotegida.

Un método mejor es el de usar un protocolo de intercambio en la que la contraseña se envíe desde el cliente mediante un algoritmo también conocido por el servidor. Generalmente se utiliza una combinación de contraseña, hora de creación y un número aleatorio. El paquete completo se envía al servidor que hace los mismos cálculos que el cliente para verificar la contraseña. Este método se conoce como Procedimiento de autentificación simple protegida.

Sin embargo, los dos procedimientos mencionados tienen un grave problema. Cuando un secreto es conocido por muchas personas, la seguridad del sistema depende de que nadie lo revele. Y la solución es utilizar un Procedimiento de autentificación fuerte, como la codificación, o encriptación, asimétrica. La característica principal de este método es que un objeto codificado con una clave, precisa de otra distinta para ser descodificado. Manteniendo en secreto la clave de codificación y haciendo pública la de descodificación, sólo una entidad podrá realizar la codificación mientras todas las demás podrán hacer la descodificación. Esto significa que una entidad puede verificar la identidad de otra al ser esta la única que tiene la clave privada, y por tanto es capaz de crear un mensaje descodificable con la clave pública. Esto es lo que se conoce como sistema de clave pública/ clave privada.

Pero tambien este método tiene su lado oculto: todos los sistemas que quieran autentificar a clientes deben conocer la clave pública o la privada de todos los posibles clientes del sistema, lo que genera una replicación extraordinaria que hace imposible su mantenimiento en grandes sistemas. Una posible solución viene de la mano de la autentificación por parte de terceros, que consiste en la utilización de un tercer sistema (además del cliente y el servidor) que lleve a cabo el proceso de autentificación. Una solución muy utilizada es el conocido Kerberos, usado ampliamente en sistemas Unix, y recientemente incorporada a Windows 2000. Consiste en un servidor centralizado de autentificación que genera claves para uso de entidades individuales. Así, la seguridad del proceso de autentificación depende sólo de la propia seguridad del servidor Kerberos. Cada entidad dispone de una clave privada que comparte con Kerberos (véase Figura 3).

CONTROL DE ACCESO

El mecanismo de control de acceso se usa en el acceso a los objetos e indica la forma en que puede llevarse a cabo. Los componentes básico de estos mecanismos son entidades, objetos y derechos de acceso. Los derechos de acceso delimitan los privilegios, las condiciones y la manera como las entidades pueden acceder a los objetos. Por norma general, los sistemas actuales disponen de las herramientas necesarias para determinar estos derechos de acceso, aunque por razones prácticas suele generalizarse el acceso por agrupaciones de objetos.

El funcionamiento del control de acceso se define en la política de seguridad mediante políticas de control de acceso, que pueden dividirse en discrecional e imperativa. En el control de acceso discrecional es el propietario de un objeto (una base de datos, por ejemplo) el que tiene la posibilidad de protegerlo frente a otras entidades delimitando quién, cuándo y cómo pueden acceder a él. En el control de acceso imperativo, el sistema comprueba siempre los derechos de acceso de una entidad para acceder a un objeto. Ni la entidad ni el propietario del objeto pueden eludir o cambiar una decisión del sistema.

Existen diferentes métodos de implementar los mecanismos de control de acceso. Los más comunes las agrupaciones, las listas de acceso, las listas de capacitación y los mecanismos de bloqueo. Existe también la posibilidad de crear combinaciones de estas implementaciones en la mayoría de sistemas operativos actuales.