1. TRANSACCIONES
CONCEPTO DE TRANSACCIONES
Una transacción es una secuencia de operaciones realizadas como una sola unidad lógica de trabajo. Una unidad lógica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades de atomicidad, coherencia, aislamiento y durabilidad (ACID), para ser calificada como transacción.
PROPIEDADES DE TRANSACCION
Atomicidad: Una transacción debe ser una unidad atómica de trabajo, tanto si se realizan todas sus modificaciones en los datos, como si no se realiza ninguna de ellas.
Serialidad: Es la propiedad que garantiza que un plan de ejecución concurrente es equivalente al secuencial es decir toda transacción en una base de datos debe tener un orden, debe ser continuo para evitar errores una transacción debe seguir después de otra culminada y realizada.
Los programadores de SQL son los responsables de iniciar y finalizar las transacciones en puntos que exijan la coherencia lógica de los datos. El programador debe definir la secuencia de modificaciones de datos que los dejan en un estado coherente en relación con las reglas corporativas de la organización. El programador incluye estas instrucciones de modificación en una sola transacción de forma que SQL Server 2005 Database Engine (Motor de base de datos de SQL Server 2005) puede exigir la integridad física de la misma.
Es responsabilidad de un sistema de base de datos corporativo, como una instancia de Database Engine (Motor de base de datos), proporcionar los mecanismos que aseguren la integridad física de cada transacción. Database Engine (Motor de base de datos) proporciona:
Servicios de bloqueo que preservan el aislamiento de la transacción.
Servicios de registro que aseguran la durabilidad de la transacción. Aunque se produzca un error en el hardware del servidor, el sistema operativo o la instancia de Database Engine (Motor de base de datos), la instancia utiliza registros de transacciones, al reiniciar, para revertir automáticamente las transacciones incompletas al punto en que se produjo el error del sistema.
Características de administración de transacciones que exigen la atomicidad y coherencia de la transacción. Una vez iniciada una transacción, debe concluirse correctamente; en caso contrario, la instancia de Database Engine (Motor de base de datos) deshará todas las modificaciones de datos realizadas desde que se inició la transacción.
Aislamiento: Las modificaciones realizadas por transacciones simultáneas se deben aislar de las modificaciones llevadas a cabo por otras transacciones simultáneas. Una transacción reconoce los datos en el estado en que estaban antes de que otra transacción simultánea los modificara o después de que la segunda transacción haya concluido, pero no reconoce un estado intermedio. Esto se conoce como seriabilidad, ya que deriva en la capacidad de volver a cargar los datos iniciales y reproducir una serie de transacciones para finalizar con los datos en el mismo estado en que estaban después de realizar las transacciones originales.
DURABILIDAD: Una vez terminada la transacción, los cambios realizados en la base de datos deben quedar almacenados en la base y evitar su pérdida. Para cumplir con las propiedades, se implementaros en el sistema de base de datos las BITÁCORAS y las listas de commit y rollback. Cada que se ejecuta la transacción, almacena en la bitácora el identificador de la transacción, los datos a procesar, tanto en sus valores iniciales, como los valores resultado del proceso y la finalización de la transacción. Si en algún momento, el sistema se cae, revisa la bitácora y carga cada transacción y cada operación en una lista llamada LISTA DE ROLLBACK. Va leyendo la bitácora y pasando los valores a dicha lista. Sí, encuentra el registro de terminación de transacción, pasa todos los registros leidos de dicha transacción a la LISTA DE COMMIT. Luego de terminar de revisar la bitácora, toma la Lista de commit y procesa las transacciones incluidas allí para modificar los datos y alterar la base de datos. Revisa la lista de Rollback y deja los valores en su estado inicial, para que sean reenviadas las transacciones que está en esta lista, ya que se rechazan.
3. BITÁCORAS
4. CONTROL DE CONCURRENCIA EN BD DISTRIBUIDAS.
(Candados) Lock
CANDADOS DE LECTURA Y CANDADOS DE ESCRITURA
El problema de concurrencia en las bases de datos distribuidas se presenta porque pueden existir múltiples copias de un item de datos almacenadas en diferentes nodos, y se debe garantizar que las copias son idénticas; igualmente debe asegurarse que la lectura de una de estas copias es consistente –su integridad-.
Se asume que las transacciones son de ejecución en dos fases y que existe seriabilidad y atomicidad local para las transacciones; sin embargo, los RLOCKS y WLOCKS deberán asegurar seriabilidad en el ambiente distribuido (una violación a la seriabilidad podría presentarse si existen dos transacciones teniendo un RLOCK una, y un WLOCK la otra, al mismo tiempo sobre el mismo item de datos).
Una de las estratégias de control consiste en asociar un bloqueo con cada copia del item de datos, y en otorgar o negar los bloqueos a cada transacción que requiera un RLOCK o WLOCK desde cada sitio de la copia. Debido a que el DBMS distribuido deberá ver los bloqueos sobre los items de datos en una forma global y no sobre las copias, se ha definido una regla para convertir los bloqueos sobre las copias en bloqueos sobre los items de datos, así:
Una transacción tiene un RLOCK sobre un item A, cuando ella tiene otorgado un RLOCK sobre cualquiera de las copias de A.
Una transacción tiene un WLOCK sobre un item A, cuando ella tiene otorgado un WLOCK sobre todas las copias de A.
Las reglas para otorgar o negar bloqueos son las mismas que para bases de datos centralizadas; se puede otorgar un RLOCK si ninguna otra transacción tiene un WLOCK en la copia, y se puede otorgar un WLOCK si ninguna otra transacción tiene un RLOCK o WLOCK. El efecto de esto es que dos (2) transacciones no pueden obtener un bloqueo de escritura y de lectura sobre el mismo item en el mismo momento.
Este método garantiza que si el número de nodos n=1, entonces el sistema se comporta como si fuera el único sitio existente -DB centralizada-.
Si uno o más sitios niegan un requerimiento de bloqueo, entonces el bloque sobre el item es negado. Para evitar abrazos mortales, las transacciones deben informar los desbloqueos a cada uno de los sitios que otorgaron un bloqueo, en caso contrario dos transacciones podrían estar indefinidamente esperando por la liberación de un item que la otra tiene bloqueado.
5. PROTOCOLO DE DOS FASES
Este protocolo permite al sistema saber que tipo de acción realizar ante el desarrollo de una transacción. El protocolo tiene, como su nombre lo indica, dos fases.
En la primera fase, conocida como fase Ready, el sistema permite a la transacción comenzar a ejecutarse; quedando a la espera de la respuesta de si pudo terminar o no las diferentes actividades que se involucran en la transacción. Si la respuesta de la transacción es "Termine", el protocolo sabe que el resultado hay que almacenarlo por lo que da COMMIT. Sí el resultado es "No pude terminar", el protocolo hace ROLLBACK a la transacción.
Existe además formas externas para asegurar la disponibilidad de los datos. Estas estrategias son, los procesos de backup y el manejo de discos especiales que permitan la recuperación de los datos (ej. Sistemas raid 5)
6. REGISTRO Y RECUPERACIÓN DE BD
El registro de transacciones es una secuencia de registros que guarda los cambios producidos en la base de datos desde el punto en el que ésta se creó hasta el momento actual. Cada operación registrada crea a su vez un registro de dicha operación. Estos registros generados por la transacción se graban en el disco cuando ésta se confirma. Por el contrario, las páginas de datos modificadas por la transacción no se graban inmediatamente en el disco, sino que se retienen en la caché del búfer de SQL Server y se guardan posteriormente. Este retraso en la escritura de los datos en el disco permite maximizar la eficacia de los accesos múltiples a las páginas de datos y evita las interrupciones en las exploraciones. Forzar el registro en el disco garantiza que no se pierda ningún trabajo confirmado en caso de un error grave en el servidor.
Con la recuperación se asegura que la base de datos es coherente desde el punto de vista transaccional como paso previo a su presentación en línea. Se dice que una base de datos es coherente de forma transaccional cuando presenta todo el trabajo confirmado y ha deshecho el no confirmado. El registro siempre define la vista correcta de la base de datos. En resumen, la recuperación es el proceso de hacer que los datos sean coherentes con el registro de las transacciones en un momento dado.
La recuperación se lleva a cabo de forma automática cuando se inicia SQL Server, cuando se tiene acceso a una base de datos o como paso final en la restauración de una base de datos desde la copia de seguridad. El primero de los casos, cuando la recuperación se realiza cuando se inicia SQL Server, se denomina recuperación de reinicio ("restartstartup recovery"). La recuperación desde las copias de seguridad se debe normalmente a un error del disco. Este tipo de recuperación se denomina recuperación de medios ("media recovery").
La recuperación de reinicio es automática y siempre recupera al momento dado más reciente. En el caso de la recuperación desde copias de seguridad, el administrador de la base de datos puede elegir la recuperación a un momento anterior.
La recuperación de reinicio tiene lugar de forma automática cada vez que se inicia una instancia de SQL Server y consiste en deshacer cualquier transacción que haya quedado incompleta la última vez que se cerró la instancia. En el caso de la recuperación desde copias de seguridad, el administrador de la base de datos puede elegir la recuperación a un momento anterior. Esto está sujeto a limitaciones.
LA RECUPERACIÓN CONSTA DE DOS FASES
- Se rehacen todos los cambios hasta que se encuentra el momento dado de destino en el registro de transacciones.
- Se deshace todo el trabajo realizado por las transacciones que estaban activas en el momento en el que se detuvo la acción de rehacer.
SQL Server utiliza puntos de control para acelerar la recuperación de reinicio.
El backup
dump o copia de respaldo de una base de datos puede hacerse a través de phpMyAdmin, del Admin del foro, de mySQL, etc... pero sea cual fuere el medio que se utilice, hay que configurar parámetros.
Para facilitar la cosa y evitar -en una tarea repetitiva como es un backup- tener que configurar parámetros cada vez, he creado este par de scripts complementarios que son el colmo de la simplificación: Dump y Download la Base de Datos - Restore la Base de Datos que, con un simple click son capaces de hacer lo que su propio nombre indica.
Su preparación es sencilla: 1.- Configurar en ambos scripts las cuatro variables: $db_server = "la dirección de base de datos: mysql.webcindario.com o localhost o..."; $db_name = "el nombre de la base de datos"; $db_username = "el usuario"; $db_password = "el password"; 2.- Crear en el server una carpeta con privilegios de escritura. 3.- Subir a esa carpeta ambos scripts. Su Funcionamiento Es Simple: Dump y Download la Base de Datos:
- Cada vez que se lanza el script, se borra la estructura de la base de datos y se restituye el contenido del dump que, con nombre igual al de la base de datos y extensión '.gz' o '.sql' según tenga el server o no, capacidad de compresión, respectivamente, está en la misma carpeta que el script.
- Cada vez que se lanza el script, se crea el Dump de la Base de Datos completa. - El Dump se crea comprimido si el servidor tiene capacidad para ello. - El Dump se crea con el nombre de la base de datos y extensión '.gz' o '.sql' según tenga el server o no, capacidad de compresión, respectivamente.
- El Dump creado se salva en la misma carpeta en que está el script.
- El Dump puede descargarse del server al ordenador desde la misma ventana del navegador.
- Cuando se lanza el script, no se obtiene el resultado en la ventana del navegador hasta que el dump finaliza. Eso significa que con una gran base de datos sin comprimir de 1000 Mb (1 Gb), por ejemplo, el resultado tardará en aparecer tres minutos aprox., dependiendo de la velocidad del server. - Cuando se lanza el script, no cerrar ni hacer nada con esa ventana del navegador, hasta que el script concluya y muestre el resultado.
No hay comentarios.:
Publicar un comentario