Transición en base de datos

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 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.

TRANSACCIONES EN BASES DE DATOS

Los comandos DML cambian datos en tablas. También va a cambiar datos en los índices, pero esto es automático y sucederá sin conocimiento del programador. El paradigma de base de datos relacional define la manera en que una o más declaraciones DML deben ser agrupadas en transacciones. Este no es el lugar para entrar en detalles sobre el paradigma de base de datos relacional. Existes números textos académicos sobre esto.  Pero una rápida revisión de la teoría de la transacción es necesaria antes de mirar la forma en que Oracle ha implementado la gestión de transacciones y DML.

El mecanismo de Oracle para asegurar la integridad de transacciones es la combinación de Segmentos Undo y los Redo Log Files: este mecanismo es sin duda el mejor de cualquier base de datos y se ajusta perfectamente con los estándares internaciones para procesamiento de datos. Otros proveedores de bases de datos cumplen con los mismos estándares con sus propios mecanismos, pero con diferentes niveles de eficiencia.  En resumen, cualquier base de datos relacional debe ser capaz de pasar la prueba ACID. Esta debe garantizar ATOMICIDAD, CONSISTENCIA, AISLAMIENTO y DURABILIDAD.

Ejecutando declaraciones SQL.

El total del lenguaje SQL es solo una docena de comandos.  Los únicos que nos preocupan aquí son:

·SELECT

·INSERT

·UPDATE

·DELETE

Recuerde que el standard SQL1999(implementado con Oracle Database release 9i) introdujo una poderoso comando MERGE, que combina INSERT e UPDATE. El standard SQL2003 (introducido con Oracle Database release 10g) MERGE fue mas alla, agregando capacidad DELETE. En cuanto a bases de datos se refiere, un MERGE no nada más que una combinación de INSERT, UPDATE y DELETE que pasan a ser ejecutadas con una sola pasada a través de los datos en lugar de varias. No hay necesidad de considerar por separado aquí.

Ejecutando una declaración SELECT.

El comando SELECT recupera datos. La ejecución de una declaración SELECT es un proceso en etapas: El proceso servidor que ejecuta la declaración primero comprueba si el bloque que contiene los datos requeridos ya está en memoria, en el Database Buffer Cache. Si ya esta, la ejecución puede proceder inmediatamente, si no está, el servidor debe localizarlo en el disco, y copiarlo sobre el Database Buffer Cache.

Examen

Siempre recuerde que el servidor Lee bloques desde los Datafiles al Database Buffer Cache, DBwn escribe bloques desde EL Database Buffer Cache a los Datafiles.

Una vez que los bloques requeridos para la consulta están en el Database Buffer Cache, cualquier futuro procesamiento (tales como ordenamiento o agrupación) es llevado a cabo en la PGA de la sesión. Cuando las ejecución es completada, el conjunto de resultados es regresado al proceso usuario.

Como se relaciona esto con la prueba ACID descrita? Para mantener la coherencia, si la consulta encuentra un Block que ha sido cambiado desde el momento que la consulta inicio, el proceso servidor va al Segmento Undo que protege el cambio, localiza la versión vieja del Dato, y (para los efectos de la consulta) hace roll back el cambio. Así, cualquier ha sido confirmado (committed), no solo sobre si los datos han sido cambiados. Claramente, si los datos necesarios para hacert este roll back  ya no están en los segmentos Undo, este mecanismo no funcionara. Que es cuando se obtiene el error “snapshot too old”.

Figura 10-1 muestra una representación de la forma de procesar una sentencia SELECT. En la figura, en el paso 1 es la transmisión de la declaración SELECT del proceso usuario al proceso servidor. El servidor buscará en el database buffer cache para averiguar si los bloques necesario ya están en memoria, y si ya están, procede el paso 4. Si no están, el paso 2 que es localizar los bloques en los datafiles, y el paso 3 es copiarlos en el Database Buffer Cache. El Paso 4 transfiere los datos al proceso servidor, donde puede haber un futuro procesamiento anterior, el paso 5 regresa los resultados  de la consulta al proceso usuario.