Transacción
Una transacción es una unidad lógica de trabajo, la cual no necesariamente consta de una sola operación en la base de datos; más bien, es en general una secuencia de varias de esas operaciones mediante la cual un estado consistente de la base de datos se transforma en otro estado consistente, sin conservar por fuerza la consistencia en todos los puntos intermedios. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción.
Una transacción es también la invocación a un procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una base de datos bajo el principio de todo o nada.
El concepto fundamental aquí es la noción de ?ejecución consistente? o ?procesamiento confiable? asociada con el concepto de una consulta. El concepto transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable.
Ejemplo 3.1: Considere la siguiente consulta en SQL para implementar el 10% del presupuesto del proyecto ?CAD/CAM? de la base de datos ?J?.
J (JNO, JNOMBRE, PRESUPUESTO, LUGAR)
UPDATE J
SETPRESUPUESTO = PRESUPUESTO * 1.1
WHEREJNOMBRE = ?CAD/CAM?
Esta consulta puede ser especificada, usando la notación de SQL, como una transacción otorgándole un nombre:
Begin_transaction ACTUALIZA_PRESUPUESTO
begin
UPDATE J
SETPRESUPUESTO = PRESUPUESTO * 1.1
WHEREJNOMBRE = ?CAD/CAM?
End.
Ejemplo 3.2: Considere una agencia de reservaciones para líneas aéreas con las siguientes relaciones.
FLIGHT (FNO, DATE, SRC, DEST, STSOLD, CAP)
CUST (CNAME, ADDR, BAL)
FC (FNO, DATE, CNAME, SPECIAL)
Una versión simplificada de una reservación típica puede ser implementada mediante la siguiente transacción:
Begin_transaction RESERVACION
begin
input (flight_no, date, customer_name);
EXEC SQL
UPDATE FLIGHT
SETSTSOLD = STSOLD + 1
WHEREFNO = flight_no
ANDDATE = date
EXEC SQL
INSERT
INTO FC (FNO, DATE, CNAME, SPECIAL)
VALUES (flight_no, date, customer_name, null)
Output (?Reservación terminada?)
End.
Mecanismos de recuperación
A fin de soportar una respuesta favorable para la ejecución de transacciones, el DBMS (Sistema Manejador de Bases de Datos) deberá de manejar el procesamiento de transacciones. Esto es, deberá de garantizar que si la transacción ejecuta algunas modificaciones y después se presenta una falla (por cualquier razón), antes de que llegue al termino normal de la transacción, se anularán esas modificaciones. Así, o bien se lleva a cabo la transacción en su totalidad, o se cancela en su totalidad. De esta manera puede lograrse que una secuencia de operaciones, la cual en esencia no es atómica, aparente serlo desde un punto de vista externo. El componente del sistema encargado de lograr esta apariencia de atomicidad se conoce como Manejador de transacciones, y las operaciones de COMMIT (comprometer) y ROLLBACK (retroceder) son la clave de su funcionamiento.
La operación COMMIT señala el término exitoso de la transacción: le dice al manejador de transacciones que se ha finalizado con éxito una unidad lógica de trabajo, que la base de datos esta (o debería estar) de nuevo en un estado consistente, y que se pueden hacer permanentes todas las modificaciones efectuadas por esa unidad de trabajo.
La operación ROLLBACK, en cambio, señala e término no exitoso de la transacción: le dice al manejador de transacciones que algo salió mal, que la base de datos podría estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lógica de trabajo deben retroceder o anularse.
Ejemplo 3.3: Considerando el ejemplo 3.2, veamos el caso cuando no existen asientos disponibles para hacer la reservación.
Begin_transaction RESERVACION2
begin
input (flight_no, date, customer_name);
EXEC SQL
SELECTSTSOLD, CAP
INTOtemp1, temp2
FROMFLIGHT
WHEREFNO = flight_no
ANDDATE = date
If temp1 = temp2 then
Output (?No hay asientos libres?)
Abort
else
EXEC SQL
UPDATEFLIGHT
SETSTSOLD = STSOLD + 1
WHEREFNO = flight_no AND DATE = date
EXEC SQL
INSERT
INTO FC (FNO, DATE, CNAME, SPECIAL)
VALUES (flight_no, date, customer_name, null)
Commit
Output (?Reservación terminada?)
endif
End.
PROPIEDADES ACID (Atomicity, Consistency, Isolation, Durability)
Una transacción posee cuatro propiedades fundamentales
Atomicidad. Una Transacción es una unidad de trabajo indivisible; la totalidad de sus acciones son un éxito un fracaso ("todo o nada").
Consistencia. Después de ejecuta una Transacción debe dejar al sistema en estado correcto o debe abortarlo. Si la Transacción no puede alcanzar un estado final debe regresar al sistema a su estado original.
Aislamiento. El comportamiento de una Transacción no se ve afectado por el hecho de que otras Transacciones puedan estar ejecutándose de manera concurrente; dicho de otra manera, una Transacción no puede revelar sus resultados a otras Transacciones concurrentes antes de su commit. La Transacción debe serializar todos los accesos a recursos compartidos y garantizar que ningún programa concurrente interferirá con sus operaciones respectivas.
Durabilidad. Los efectos de una Transacción son permanentes después de su grabación. Sus cambios deben sobrevivir a fallas del sistema. (Persistencia).
BITÁCORA
La operación ROLLBACKesta basada en el uso de una ?bitacora?. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitácora o diario en cinta o en disco (mas comúnmente), en el cual se registran los detalles de todas las operaciones de actualización, en particular, los valores inicial y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondientede la bitácora para restaurar el valor original del objeto restaurado.
PUNTO DE SINCRONIZACION
Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de una programa. Cuando se establece un punto de sincronización:
Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior.
Se pierde todo posible posicionamiento en la base de datos.
Se liberan todos los registros bloqueados.
Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el programa.
TIPOS DE TRANSACCIONES
Transacciones simples. Todas las operaciones se llevan acabo en el mismo nivel dentro de una T
La Transacción empieza con un begin_transaction y termina ya sea con un commit_transaction o abort_transaction. Toda la transacción es indivisible.
En un principio las Transacciones simples fueron suficientes por su sencillez y por su adaptación a operaciones bancarias breves. Actualmente las Transacciones han incursionado en todas las facetas de la computación pero no han resultado lo más adecuado, ya que tienen un comportamiento:
Frágil: En transacciones de negocios que se extienden por períodos largos.
Débil: En procesamiento por lotes.
Nulo:Situaciones que requieren dar marcha atrás.
Una Transacción simple no dura más de dos o tres segundo para evitar monopolizar recursos críticos del sistema como candados sobre la base de datos. Así que los programas OLTP se dividen en transacciones breves ejecutadas una tras otra para producir resultados.
Transacciones simples distribuidas. Una T simple puede correr en sitios múltiples y actualizar recursos localizados dentro de administradores de recursos múltiples.
Transacciones encadenadas (syncpoint, encadenadas y sagas). Un syncpoint es un punto de sincronización que permite el guardado periódico del trabajo acumulado dentro de una transacción, permitiendo de esta forma dar marcha atrás al trabajo sin, abortar la transacción. Sin embargo este trabajo no es almacenado permanentemente, por lo que si el sistema se colapsa el trabajo se pierde. Las transacciones encadenadas son una variación de los syncpoint que convierten en durable el trabajo acumulado. Las sagas extienden las transacciones encadenadas a fin de dar marcha atrás a una cadena entera si es necesario.
Transacciones anidadas. Ofrecen la posibilidad de definir transacciones dentro de otras transacciones. cada subtransacción puede emitir una grabación o retroceso para las piezas de trabajo asignadas.
PROTOCOLO DE BITÁCORA ADELANTADA
Se considera que una transacción es una unidad de recuperación. Pues si una transacción se realiza con éxito, el sistema deberá garantizar el establecimiento permanente de sus modificaciones en la base de datos, aún si el sistemas cayera en el instante siguiente. Es muy posible, por ejemplo, una caída del sistema después de haberse realizado una instrucción COMMIT, pero antes de grabarse físicamente las modificaciones en la base de datos, podrá descubrir los valores que se deben grabar examinando las entradas pertinentes de la bitácora. Para ello la bitácora se deberá haber grabado físicamente antes de que se pueda completar el procesamientode una instrucción COMMIT. Esta importante regla se conoce como Protocolo de Bitácora de Escritura adelantada. De esta forma, el procedimiento de reinicio recuperará todas las transacciones completadas con éxito pero cuyas modificaciones no lograron grabarse físicamente antes de la caída.
TIPOS DE FALLAS
Una falla local sólo afecta a la transacción en la cual se presentó esa falla, como por ejemplo un ?overflow?. Tales fallas son recuperables mediante los mecanismos de soporte de la instrucción COMMIT.
Una falla global afecta a varias transacciones (y con mucha probabilidad a la totalidad) de las transacciones que se estaban efectuando en e momento de la falla. Tales fallas se dividen en dos tipos:
Fallas del sistema, (por ejemplo interrupciones del suministro de electricidad) las cuales afectan a todas las transacciones que se están realizando pero no dañan físicamente a la base de datos.
Falla de los medios de almacenamiento (por ejemplo, un aterrizaje de cabezas en el disco), las cuales si causan daños a la base de datos o a una porción de ella, y afectan al menos a las transacciones que están utilizando esa porción.
RECUPERACIÓN A FALLAS EN EL SISTEMA
El método convencional se basa en el establecimiento síncrono de un ?punto de revisión?, lo cual implica:
Grabar físicamente el contenido de los ?buffers? de datos en la base de datos física (compromete las modificaciones a la base de datos).
Grabar físicamente un registro de punto de revisión especial en la bitácora físicamente, el cual incluye una lista de todas las transacciones que se estaban realizando en el momento de establecerse el punto de revisión.
Ejemplo:
Se presentó una falla en el momento tf.
El punto de verificación mas reciente antes de tf se tomó en el momento tv.
Las transacciones del tipo T1 se completaron antes del tiempo tv.
Las transacciones del tipo T2 se iniciaron antes del tiempo tv y se completaron después del tiempo tv y antes del tiempo tf.
Las transacciones del tipo T3 también se iniciaron antes del tiempo tv pero no se completaron antes del tiempo tf.
Las transacciones del tipo T4 se iniciaron después del tiempo tv y se completaron antes del tiempo tf.
Por último, las transacciones del tipo T5 también se iniciaron después del tiempo tv pero no se completaron antes del tiempo tf.
Al reiniciarse el sistema deberán de anularse las transacciones del los tipos T3, T5 y deberán realizarse de nuevo las transacciones de los tipos T2 y T4. Note que las transacciones de tipo T1 no entran en el proceso de reinicio, ya que sus modificaciones se grabaron físicamente en la base de datos en el momento tv como parte del proceso de punto de revisión.
En el momento de reinicio del sistema se efectúa el siguiente procedimiento a fin de identificar las transacciones de los tipos T2-T5.
Comenzar con dos listas de transacciones, la lista ANULAR y la lista REPETIR. Igualar la lista ANULAR a la lista de todas las transacciones incluidas en el registro de punto de revisión. Dejar vacía la lista REPETIR.
Examinar la bitácora hacia delante a partir del registro de punto de revisión.
Si se encuentra una entrada de bitácora de ?iniciar transacción? para la transacción T, añadir T a la lista ANULAR.
Si se encuentra una entrada de bitácora de ?comprometer? para la transacción T, pasar esa transacción de la lista ANULAR a la lista REPETIR.
Cuando se llegue al final de la bitácora, las listas ANULAR y REPETIR identificarán respectivamente, las transacciones de los tipos T3 y T5 y las de los tipos T2 y T4.
A continuación el sistema revisará la bitácora hacia atrás, anulando todas las transacciones de la lista ANULAR. A continuación la revisará otra vez hacia delante, realizando de nuevo todas las transacciones en la lista REPETIR, los cual finalízale proceso de recuperación.
RECUPERACIÓN A FALLAS EN LOS MEDIOS DE ALMACENAMIENTO
Una falla en los medios de almacenamiento es un percance en el cual se destruye físicamente alguna porción de la base de datos. La recuperación de una falla semejante implica en esencia cargar de nuevo la base de datos a partir de una copia de respaldo y utilizar después la bitácora (tanto la porción activa como la de archivo en general) para realizar de nuevo todas las transacciones terminadas desde que se hizo esa copia de respaldo.
MONITORES TP (Transaction Processing)
Un monitor de TP es un sistema operativo de procesamiento de transacciones que tiene como funciones principales:
Administración de procesos:
Poner en marcha los procesos del servidor
Canalizar el trabajo en dirección a ellos
Vigilar su correcta ejecución
Equilibrar cargas de trabajo
Administrador de transacciones
Los monitores se especializan en la administración de transacciones desde su punto de origen (por lo general en el cliente), ya través de uno o más servidores, para luego volver al cliente originario. Cuando una T llega a su fin, el monitor de TP debe cerciorarse de que todos los sistemas involucrados en ella queden en estado consistente. De esta forma un monitor de TP sabe como correr T, enrutarlas entre diferentes sistemas, equilibrar las cargas de ejecución y ponerlas nuevamente en marcha después de una falla. Todo esto sin importar los sistemas, ni los administradores de recursos.
Surgen de la necesidad de correr aplicaciones capaces de atender a cientos o miles de clientes, ya que los monitores permiten conectar en tiempo real a miles de clientes que esperan un servicio, sin necesidad de consumir tantos recursos.
Ejemplo: si un cliente necesita para ser atendido de los siguientes recursos: 1 proceso, 1 conexión, ½Mb de RAM y una docena de archivos abiertos; y además si se atienden 1000 clientes al mismo tiempo tendríamos las siguientes situaciones:
a). Sin monitor TP
| 1000 clientes | 1000 conexiones 1000 procesos 500 Mb de RAM 10000 archivos abiertos | SO de bajodesempeño |
b). Con monitor TP
| 1000 clientes | MONITOR TP | 50 conexiones 50 procesos 25 Mb de RAM 500 archivos abiertos | SO de buen desempeño
|
Generalmente en los entornos de PC el servidor suele tener sus aplicaciones de procesamiento de transacciones en línea (OLTP: On Une Transaction Processing) empaquetadas en calidad de librerías de enlace dinámico (DLL Dinamic Link Library). El monitor de TP, entonces, asigna la ejecución de las funciones DLL a clases de servidor, a procesos de fondo o a hilos preiniciados en espera de un trabajo.
Cómo realiza el monitor de TP su acto de canalización
Cuando un cliente solicita un servicio, el monitor TP la destina aun proceso, el cual se enlaza con la función DLL llamada por el cliente, la invoca, supervisa su ejecución y regresa los resultados al cliente. Una vez concluido el trabajo el proceso servidor regresa los resultados y el proceso puede ser reutilizado por otro cliente. El SO conserva en memoria las DLL para que puedan ser compartidas por otros procesos.
Si el número de solicitudes de clientes recibidas excede el número de procesos en el servidor, el monitor puede iniciar dinámicamente otros nuevos (equilibrio de cargas). Parte del equilibrio de cargas es la administración de prioridades en las solicitudes recibidas, de esta forma solicitudes con prioridad alta se asignan a clases de servidor de alta prioridad. También el monitor de TP puede dividir sus clases de acuerdo al tipo de aplicación, tiempo de respuesta deseado, recursos que administran, requerimientos de tolerancia a fallas, etc.
A un monitor de TP lo podemos ver como una arquitectura cliente / servidor compuesta de tres planos: una interfaz gráfica GUI, la lógica de aplicación y los administradores de recursos.
BENEFICIOS DE UN MONITOR TP
Estructura de desarrollo de aplicaciones cliente/servidor. Los monitores TP proporcionan una estructura preconstruida que ayuda a formar, operar y administrar una aplicación cliente/servidor. Permite. construir aplicaciones cliente/servidor robustas y de alto desempeño.
Muros de protección. Implementan muros de protección entre aplicaciones y administradores de recursos, así como entre las mismas aplicaciones.
Alta disponibilidad. Los monitores TP están diseñados para sortear todo tipo de fallas, permite crear sistemas autoremediables, ya que siempre están al tanto del estado de los recursos de cliente / servidor bajo su control, pueden detectar una falla en el momento mismo que ocurren y decidir si reinicia el proceso fallido o retrocede y conmuta aun proceso en otro nodo. (arquitecturas sin un sólo punto de falla).
Equilibrio de cargas. Los monitores de TP se especializan en la administración de procesos y soportan técnicas de carga tanto estáticas como dinámicas; soportan solicitudes con prioridad y pueden duplicar dinámicamente procesos del servidor en el mismo nodo o en otro diferente.
Facilidad de ampliación de funciones. Los monitores TP alientan la creación de procedimientos modulares reutilizables. Los monitores sólo exportan las funciones y no los datos, así se podría seguir añadiendo nuevas funciones y permitir que el monitor de TP las distribuya entre múltiples servidores. De esta forma se podrían construir aplicaciones distribuidas de alta complejidad con sólo agregar procedimientos.
Costo reducido del sistema. De acuerdo a estudios, si se usan monitores de TP se puede ahorrar más del 30% del costo total del sistema, un 40% en costos de desarrollo y ahorros en la adquisición de recursos.
Generalmente, se recomienda usar un monitor de TP si su aplicación cliente / servidor tiene más de 100 clientes, que procesen cinco o más transacciones por minuto, emplee tres o más servidores y/o haga uso de dos o más BD.
TIPOS DE PROCESAMIENTO DE TRANSACCIONES
Existe una clasificación para el procesamiento de transacciones:
TP ligero (TP lite) el cual se limita a integrar monitores TP a los administradores de BD.
TP pesado (TP heavy) en donde los monitores TP extienden la noción de transacción a todos los recursos usados para el procesamiento de transacciones.
Podemos hacer una serie de comparaciones entre ellos:
a) Alcance de la grabación
TP ligero
TP pesado
b) Administración de recursos. Mientras que el TP ligero sólo realiza actualizaciones en BD, los TP pesados realizan actualizaciones AGIO (manteniendo las propiedades de las transacciones) en múltiples administradores de recursos heterogéneos dentro del alcance de una sola transacción.
c) Administración de procesos. Los TP ligeros cargan el procedimiento, lo ejecutan y si acaso lo guardan en la memoria caché para su uso posterior. Los TP pesado cuentan con servidores preiniciados, equilibrio dinámico de carga, planeación de acuerdo a prioridades, muros de protección, redireccionamiento a otros servidores, etc.
d) Invocaciones cliente/servidor. Generalmente los TP ligeros tiene su propia forma de invocar a los RPG del servidor y no cuentan con mecanismos de autenticación, ni están integradas a directorios globales.
e) Desempeño. Los procedimientos en Trligero son mucho más veloces porque reducen en mucho el tráfico en la red y requieren menos hardware.
Fuente: http://www.ittehuacan.edu.mx/ittehuacan/
Fernando A. Mas
