Transacciones

El contenido del script de esta página es sólo para fines de navegación y no modifica el contenido de ninguna forma.

En este capítulo se define una transacción y se describe cómo la base de datos procesa las transacciones.

Introducción a las transacciones

Una transacción es una unidad de trabajo lógica y atómica que contiene una o más sentencias SQL.

Una transacción agrupa sentencias SQL para que estén confirmadas, lo que significa que se aplican a la base de datos o se realiza un rollback de todas ellas, lo que significa que se deshacen de la base de datos. Oracle AI Database asigna a cada transacción un identificador único denominado ID de transacción.

Todas las transacciones de Oracle obedecen las propiedades básicas de una transacción de base de datos, conocidas como propiedades de ACID. ACID es un acrónimo de lo siguiente:

El uso de transacciones es una de las formas más importantes en que un sistema de gestión de bases de datos difiere de un sistema de archivos.

Transacción de muestra: Débito y crédito de cuenta

Para ilustrar el concepto de una transacción, considere una base de datos bancaria.

Cuando un cliente transfiere dinero de una cuenta de ahorros a una cuenta corriente, la transacción debe constar de tres operaciones separadas:

Oracle AI Database debe permitir dos situaciones. Si las tres sentencias SQL mantienen el saldo correcto de las cuentas, los efectos de la transacción se pueden aplicar a la base de datos. Sin embargo, si un problema como la insuficiencia de fondos, el número de cuenta no válido o un fallo de hardware impide que se completen uno o dos de los estados de cuenta de la transacción, la base de datos debe realizar un rollback de toda la transacción para que el saldo de todas las cuentas sea correcto.

El siguiente gráfico ilustra una transacción bancaria. El primer estado de cuenta resta $500 de la cuenta de ahorros 3209. El segundo estado de cuenta agrega $500 a la cuenta corriente 3208. La tercera sentencia inserta un registro de la transferencia en la tabla de asientos. La sentencia final confirma la transacción.

Figura 1: Una transacción bancaria

Descripción de la ilustración cncpt025.gif

Estructura de una transacción

Las transacciones de base de Datos constan de una o más sentencias.

En concreto, una transacción consta de una de las siguientes opciones:

Una transacción tiene un principio y un fin.

Consulte además:

Inicio de una transacción

Una transacción comienza cuando se encuentra la primera sentencia SQL ejecutable.

Una sentencia SQL ejecutable es una sentencia SQL que genera llamadas a una instancia de base de datos, incluidas las sentencias DML y DDL y la sentencia SET TRANSACTION.

Cuando se inicia una transacción, Oracle AI Database asigna la transacción a un segmento de datos de deshacer disponible para registrar las entradas de deshacer para la nueva transacción. Un ID de transacción no se asigna hasta que se asignan un segmento de deshacer y una ranura de la tabla de transacciones, lo que ocurre durante la primera sentencia DML. Un ID de transacción es exclusivo de una transacción y representa el número de segmento de deshacer, el espacio y el número de secuencia.

En el siguiente ejemplo, se ejecuta una sentencia UPDATE para iniciar una transacción y se consulta V$TRANSACTION para obtener detalles sobre la transacción:

SQL> UPDATE hr.employees SET salary=salary;

107 rows updated.

SQL> SELECT XID AS "txn id", XIDUSN AS "undo seg", XIDSLOT AS "slot",
  2  XIDSQN AS "seq", STATUS AS "txn status"
  3  FROM V$TRANSACTION;

txn id             undo seg       slot        seq txn status
---------------- ---------- ---------- ---------- ----------------
0600060037000000          6          6         55 ACTIVE

Consulte también: "Deshacer Segmentos"

Fin de una transacción

Una transacción puede terminar en diferentes circunstancias.

Una transacción finaliza cuando se produce cualquiera de las siguientes acciones:

Una vez finalizada una transacción, la siguiente sentencia SQL ejecutable inicia automáticamente la siguiente transacción. En el siguiente ejemplo, se ejecuta un UPDATE para iniciar una transacción, finaliza la transacción con una sentencia ROLLBACK y, a continuación, ejecuta un UPDATE para iniciar una nueva transacción (tenga en cuenta que los ID de transacción son diferentes):

SQL> UPDATE hr.employees SET salary=salary;
107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0800090033000000 ACTIVE

SQL> ROLLBACK;

Rollback complete.

SQL> SELECT XID FROM V$TRANSACTION;

no rows selected

SQL> UPDATE hr.employees SET last_name=last_name;

107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0900050033000000 ACTIVE

Consulte además:

Atomicidad a nivel de extracto

Oracle AI Database soporta la atomicidad de nivel de sentencia, lo que significa que una sentencia SQL es una unidad atómica de trabajo y se ejecuta correctamente o falla por completo.

Una sentencia correcta es diferente de una transacción confirmada. Una sola sentencia SQL se ejecuta correctamente si la base de datos la analiza y ejecuta sin errores como una unidad atómica, como cuando se cambian todas las filas en una actualización de varias filas.

Si una sentencia SQL produce un error durante la ejecución, no se realiza correctamente y, por lo tanto, se realiza un rollback de todos los efectos de la sentencia. Esta operación es una reversión de nivel de sentencia. Esta operación tiene las siguientes características:

Un ejemplo de error que causa un rollback a nivel de sentencia es un intento de insertar una clave primaria duplicada. Las sentencias SQL únicas implicadas en un bloqueo_bloqueo, que compite por los mismos datos, también pueden provocar un rollback a nivel de sentencia. Sin embargo, los errores detectados durante el análisis de sentencias SQL, como un error de sintaxis, aún no se han ejecutado y, por lo tanto, no provocan un rollback a nivel de sentencia.

Consulte además:

Números de Cambio del Sistema (SCNs)

Un número de cambio del sistema (SCN) es un registro de hora lógico interno que utiliza Oracle AI Database.

Los SCN ordenan los eventos que se producen en la base de datos, lo que es necesario para cumplir las propiedades ACID de una transacción. Oracle AI Database utiliza SCN para marcar el SCN antes del cual se sabe que todos los cambios están en el disco, de modo que la recuperación evita la aplicación de redo innecesario. La base de datos también utiliza SCN para marcar el punto en el que no existe ningún redo para un juego de datos para que la recuperación se pueda parar.

Los SCN se producen en una secuencia que aumenta monótonamente. Oracle AI Database puede utilizar un SCN como un reloj porque un SCN observado indica un punto lógico en el tiempo y las observaciones repetidas devuelven valores iguales o mayores. Si un evento tiene un SCN menor que otro evento, se produjo en una hora anterior en la base de datos. Varios eventos pueden compartir el mismo SCN, lo que significa que se han producido al mismo tiempo en la base de datos.

Cada transacción tiene un SCN. Por ejemplo, si una transacción actualiza una fila, la base de datos registra el SCN en el que se ha producido esta actualización. Otras modificaciones de esta transacción tienen el mismo SCN. Cuando se confirma una transacción, la base de datos registra un SCN para esta confirmación.

Oracle AI Database incrementa los SCN en el área global del sistema (SGA). Cuando una transacción modifica datos, la base de datos escribe un nuevo SCN en el segmento de datos de deshacer asignado a la transacción. A continuación, el proceso de escritor de log escribe el registro de confirmación de la transacción inmediatamente en el redo log en línea. El registro de confirmación tiene el SCN único de la transacción. Oracle AI Database también utiliza SCN como parte de sus mecanismos de recuperación de instancias y recuperación de medios.

Consulte también: "Visión General de la Recuperación de Instancias"

Visión General de Control de Transacciones

El control de transacciones es la gestión de los cambios realizados por las sentencias DML y la agrupación de sentencias DML en transacciones.

En general, los diseñadores de aplicaciones se preocupan por el control de transacciones para que el trabajo se realice en unidades lógicas y los datos se mantengan consistentes.

El control de transacciones implica el uso de las siguientes sentencias, como se describe en "Sentencias de control de transacciones":

La sesión de la Tabla 13-1 ilustra los conceptos básicos del control de transacciones.

Tabla 1 Control de transacciones

T Sesión Explicación
t0 
COMMIT;
 Esta sentencia finaliza cualquier transacción existente en la sesión.
t1 
SET TRANSACTION NAME 'sal_update';
 Esta sentencia inicia una transacción y le asigna el nombre sal_update.
t2 
UPDATE employees
 SET salary = 7000
  WHERE last_name = 'Banda';
 Esta sentencia actualiza el salario de Banda a 7000.
t3 
SAVEPOINT after_banda_sal;
 Esta sentencia crea un punto de grabación denominado after_banda_sal, lo que permite realizar un rollback de los cambios en esta transacción hasta este punto.
t4 
UPDATE employees
 SET salary = 12000
  WHERE last_name = 'Greene';
 Esta declaración actualiza el salario de Greene a 12000.
t5 
SAVEPOINT after_greene_sal;
 Esta sentencia crea un punto de grabación denominado after_greene_sal, lo que permite realizar un rollback de los cambios en esta transacción hasta este punto.
t6 
ROLLBACK TO SAVEPOINT
 after_banda_sal;
 Esta sentencia realiza un rollback de la transacción a t3, deshaciendo la actualización del salario de Greene en t4. La transacción sal_update no ha finalizado.
t7 
UPDATE employees
 SET salary = 11000
  WHERE last_name = 'Greene';
 Esta sentencia actualiza el salario de Greene a 11000 en la transacción sal_update.
t8 
ROLLBACK;
 Esta sentencia realiza un rollback de todos los cambios en la transacción sal_update y finaliza la transacción.
t9 
SET TRANSACTION NAME 'sal_update2';
 Esta sentencia inicia una nueva transacción en la sesión y le asigna el nombre sal_update2.
t10 
UPDATE employees
 SET salary = 7050
  WHERE last_name = 'Banda';
 Esta sentencia actualiza el salario de Banda a 7050.
t11 
UPDATE employees
 SET salary = 10950
  WHERE last_name = 'Greene';
 Esta declaración actualiza el salario de Greene a 10950.
t12 
COMMIT;
 Esta sentencia confirma todos los cambios realizados en la transacción sal_update2 y finaliza la transacción. La confirmación garantiza que los cambios se guardan en los archivos redo log en línea.

Nombres de transacción

Un nombre de transacción es una etiqueta opcional, especificada por el usuario, que sirve como recordatorio del trabajo que está realizando la transacción. Asigne un nombre a una transacción con la sentencia SET TRANSACTION ... NAME, que si se utiliza debe ser la primera sentencia de la transacción.

En la Tabla 13-1, la primera transacción se denominó sal_update y la segunda, sal_update2.

Los nombres de transacción proporcionan las siguientes ventajas:

Consulte además:

Transacciones Activas

Una transacción activa es aquella que se ha iniciado, pero aún no se ha confirmado ni realizado un rollback.

En la Tabla 13-1, la primera sentencia que modifica datos de la transacción sal_update es la actualización del salario de Banda. Desde la ejecución correcta de esta actualización hasta que la sentencia ROLLBACK termine la transacción, la transacción sal_update está activa.

Los cambios de datos realizados por una transacción son temporales hasta que se confirma o se realiza un rollback de la transacción. Antes de que finalice la transacción, el estado de los datos es el que se muestra en la siguiente tabla.

Tabla 2 Estado de los datos antes de que finalice la transacción

Estado Descripción Para saber más
Oracle AI Database ha generado información de deshacer en SGA. Los datos de deshacer contienen los valores de datos antiguos modificados por las sentencias SQL de la transacción. "Consistencia de Lectura en el Nivel de Aislamiento Confirmado de Lectura"
Oracle AI Database ha generado redo en el buffer de redo log en línea del SGA. El registro redo log contiene el cambio en el bloque de datos y el cambio en el bloque de deshacer. "Buffer de Redo Log".
Se han realizado cambios en los buffers de la base de datos de SGA. Los cambios de datos de una transacción confirmada, almacenados en los buffers de base de datos de SGA, no se escriben necesariamente inmediatamente en los archivos de datos mediante el escritor de base de datos (DBW). La escritura en disco puede producirse antes o después de la confirmación. "Caché de Buffers de Base de Datos"
Las filas afectadas por el cambio de datos están bloqueadas. Otros usuarios no pueden cambiar los datos de las filas afectadas ni pueden ver los cambios sin confirmar. "Resumen del comportamiento de bloqueo"

Puntos de grabación

Un punto de guardado es un marcador intermedio declarado por el usuario en el contexto de una transacción.

Internamente, el marcador de punto de grabación se resuelve en un SCN. Los puntos de grabación dividen una transacción larga en partes más pequeñas.

Si utiliza puntos de grabación en una transacción larga, tendrá la opción más adelante de realizar un rollback del trabajo antes del punto actual de la transacción pero después de un punto de grabación declarado dentro de la transacción. Por lo tanto, si se produce un error, no es necesario volver a enviar todas las sentencias. La Tabla 13-1 crea el punto de grabación after_banda_sal para que la actualización del salario de Greene se pueda revertir a este punto de grabación.

Deshacer a Punto de Grabación

Un rollback a un punto de grabación en una transacción sin confirmar significa deshacer los cambios realizados después del punto de grabación especificado, pero no significa un rollback de la propia transacción.

Cuando se realiza un rollback de una transacción a un punto de grabación, como cuando se ejecuta ROLLBACK TO SAVEPOINT after_banda_sal en la Tabla 13-1, se produce lo siguiente:

  1. Oracle AI Database realiza un rollback solo de las sentencias que se ejecutan después del punto de grabación.

    En la Tabla 13-1, ROLLBACK TO SAVEPOINT hace que se realice un rollback de UPDATE para Greene, pero no de UPDATE para Banda.

  2. Oracle AI Database conserva el punto de grabación especificado en la sentencia ROLLBACK TO SAVEPOINT, pero se pierden todos los puntos de grabación posteriores.

    En la Tabla 13-1, ROLLBACK TO SAVEPOINT hace que se pierda el punto de grabación after_greene_sal.

  3. Oracle AI Database libera todos los bloqueos de tabla y fila adquiridos después del punto de grabación especificado, pero conserva todos los bloqueos de datos adquiridos antes del punto de grabación.

La transacción permanece activa y se puede continuar.

Consulte además:

Transacciones en cola

Según el escenario, las transacciones que esperan recursos bloqueados anteriormente pueden seguir bloqueándose después de un rollback en el punto de grabación.

Cuando una transacción está bloqueada por otra transacción, se pone en cola en la propia transacción de bloqueo, de modo que toda la transacción de bloqueo se debe confirmar o revertir para que la transacción bloqueada continúe.

En el escenario que se muestra en la siguiente tabla, la sesión 1 realiza un rollback a un punto de grabación creado antes de ejecutar una sentencia DML. Sin embargo, la sesión 2 sigue bloqueada porque está a la espera de que finalice la transacción de la sesión 1.

Tabla 3: Ejemplo de Rollback hasta Punto de Grabación

T Sesión 1 Sesión 2 Sesión 3 Explicación
t0 
UPDATE employees
  SET salary=7000
  WHERE last_name=
  'Banda';
     La sesión 1 inicia una transacción. La sesión coloca un bloqueo exclusivo en la fila Banda (TX) y un bloqueo de tabla subexclusivo (SX) en la tabla.
t1 
SAVEPOINT
  after_banda_sal;
     La sesión 1 crea un punto de grabación denominado after_banda_sal.
t2 
UPDATE employees
  SET salary=12000
  WHERE last_name=
  'Greene';
     La sesión 1 bloquea la fila Greene.
t3   
UPDATE employees
  SET salary=14000
  WHERE last_name=
 'Greene';
   La sesión 2 intenta actualizar la fila Greene, pero no adquiere un bloqueo porque la sesión 1 tiene un bloqueo en esta fila. No se ha iniciado ninguna transacción en la sesión 2.
t4 
ROLLBACK
 TO SAVEPOINT
  after_banda_sal;
    

En la sesión 1 se realiza un rollback de la actualización al salario de Greene, que libera el bloqueo de fila de Greene. El bloqueo de tabla adquirido en t0 no se libera.

En este punto, la sesión 2 todavía está bloqueada por la sesión 1 porque la sesión 2 pone en cola la transacción de la sesión 1, que aún no se ha completado.

t5     
UPDATE employees
  SET salary=11000
 WHERE last_name=
 'Greene';
 La fila Greene está desbloqueada actualmente, por lo que la sesión 3 adquiere un bloqueo para una actualización de la fila Greene. Esta sentencia inicia una transacción en la sesión 3.
t6 
COMMIT;
     La sesión 1 se confirma y finaliza su transacción. La sesión 2 ahora se pone en cola para su actualización en la fila Greene detrás de la transacción en la sesión 3.

Consulte también: "Duración del bloqueo" para obtener más información sobre cuándo Oracle AI Database libera bloqueos

Rollback de transacciones

Un rollback de una transacción sin confirmar deshace cualquier cambio en los datos que hayan realizado las sentencias SQL en la transacción.

Una vez que se ha realizado un rollback de una transacción, los efectos del trabajo realizado en la transacción ya no existen. Al realizar un rollback de una transacción completa, sin hacer referencia a ningún punto de grabación, Oracle AI Database realiza las siguientes acciones:

La duración de un rollback es una función de la cantidad de datos modificados.

Consulte además:

Confirmaciones de transacciones

Una confirmación finaliza la transacción actual y hace permanentes todos los cambios realizados en la transacción.

En la Tabla 13-1, una segunda transacción comienza con sal_update2 y termina con una sentencia COMMIT explícita. Los cambios resultantes de las dos sentencias UPDATE se convierten ahora en permanentes.

Cuando se confirma una transacción, se producen las siguientes acciones:

Después de confirmar una transacción, los usuarios pueden ver los cambios.

Normalmente, una confirmación es una operación rápida, independientemente del tamaño de la transacción. La velocidad de una confirmación no aumenta con el tamaño de los datos modificados en la transacción. La parte más larga de la confirmación es la E/S del disco físico realizada por LGWR. Sin embargo, la cantidad de tiempo que emplea LGWR se reduce porque se ha escrito incrementalmente el contenido del buffer de redo log en segundo plano.

El comportamiento por defecto es que LGWR escriba redo en el redo log en línea de forma síncrona y que las transacciones esperen a que el redo en buffer esté en disco antes de devolver una confirmación al usuario. Sin embargo, para reducir la latencia de confirmación de transacciones, los desarrolladores de aplicaciones pueden especificar que el redo se escriba de forma asíncrona para que las transacciones no tengan que esperar a que el redo esté en el disco y puedan volver de la llamada COMMIT inmediatamente.

Consulte además:

Descripción general de transacciones en cuarentena

Una transacción acotada es una transacción que está aislada y no se recupera durante la recuperación de la base de datos. Necesita la intervención del DBA para resolver el problema antes de que se puedan liberar los bloqueos.

Oracle AI Database utiliza redo y deshacer para lograr la consistencia de los datos. Cuando la base de datos se abre después de un bloqueo, la aplicación de redo realiza un rollback de la base de datos para obtener todos los cambios confirmados, conocidos como recuperación de caché, y el proceso de deshacer realiza un rollback de los cambios realizados por las transacciones no confirmadas y ahora inactivas debido al bloqueo. Esto se conoce como recuperación de bloqueo. La base de datos abierta no espera a que se aplique el proceso de deshacer de las transacciones sin confirmar para lograr un inicio más rápido. En su lugar, marca el estado de la transacción como "inactivo" en la tabla de transacciones y la base de datos se abre rápidamente. La aplicación de deshacer para transacciones inactivas se realiza de forma asíncrona mediante el proceso en segundo plano de la supervisión del sistema (SMON) y se conoce como recuperación de transacciones.

La otra vez que SMON recupera transacciones inactivas es durante la recuperación de instancias. Una instancia de Oracle RAC se puede bloquear con transacciones en ejecución activa. Esas transacciones inactivas contienen bloqueos de filas que bloquean transacciones en las mismas filas en las otras instancias de RAC restantes. El proceso en segundo plano SMON en una de las instancias restantes realiza la recuperación de la instancia en dos fases, la recuperación de la caché y la recuperación de la transacción.

El proceso en segundo plano PMON también puede descargar en SMON el trabajo de finalización de una transacción grande durante la limpieza del proceso fallida.

El proceso SMON realiza tareas de nivel de sistema, como la limpieza de segmentos temporales no utilizados, la fusión de extensiones contiguas y muchas otras tareas. Es un proceso irrecuperable, lo que significa que un bloqueo en SMON conduce a un bloqueo de instancia de CDB. El fallo de recuperación de la transacción SMON se puede producir debido a diversos motivos:

Un bloqueo no solo detiene la recuperación de la transacción que está siendo recuperada activamente por SMON, sino que la recuperación también se detiene para el resto de las transacciones inactivas. Cuando hay un fallo persistente, los Servicios de Soporte Oracle recomiendan a los clientes desactivar la recuperación de transacciones SMON y abrir la base de datos para reducir el impacto. Esto hace que las transacciones inactivas retengan bloqueos de fila durante más tiempo. Esto afecta gravemente a las operaciones empresariales críticas.

Cualquier transacción que no se pueda recuperar se pone en cuarentena y se deja sin recuperar hasta que el DBA pueda resolver el problema. Se notifica al DBA sobre la transacción en cuarentena y debe realizar acciones inmediatas para que se puedan liberar los bloqueos de fila retenidos por la transacción en cuarentena.

El DBA recibe una alerta sobre la presencia de transacciones en cuarentena en varios logs y vistas para ayudar a identificar las transacciones en cuarentena y el motivo por el que se ponen en cuarentena. El DBA utiliza esta información para abordar el problema específico a fin de que se pueda eliminar la cuarentena.

Cuando se producen fallos en varias transacciones o abarcan toda la PDB, como la corrupción de datos lógicos debido a un bug de código, la corrupción física de varios bloques o una corrupción de SGA de PDB, la puesta en cuarentena de la recuperación de transacciones inactivas con fallos puede o no ayudar. Depende de si la causa raíz de esos fallos es la misma o no, ya que la recuperación de otras transacciones inactivas puede tener el mismo problema. El sistema se sigue ejecutando en un estado inconsistente incluso después de poner en cuarentena algunas transacciones. Puede ser peligroso cuando el fallo se debe a la corrupción de datos lógicos, porque se extiende a lo largo del tiempo. Para evitar que esto ocurra, hay un límite de cuarentena de transacción de tres (3), tras el cual la cuarentena se escala al nivel de base de datos y la PDB se terminará mediante shutdown abort si archive log está activado para la PDB y es posible cerrar la PDB. La recuperación de transacciones para la PDB se desactiva automáticamente para que el DBA pueda corregir problemas en el siguiente inicio. Una vez que se hayan resuelto los problemas, el DBA debe activar la recuperación para el siguiente inicio.

Nota: Dado que Oracle Data Guard utiliza la replicación lógica, los metadatos de cuarentena no se replican en el servidor en espera cuando se utiliza Oracle Data Guard. Por lo tanto, el contenido de las vistas de cuarentena de transacciones, como DBA_QUARANTINED_TRANSACTIONS, en el servidor en espera puede ser diferente de las entradas en el servidor principal.

Temas relacionados

Visión General del Gestor de Transacciones

Transaction Guard es una API que las aplicaciones pueden utilizar para proporcionar idempotencia de transacción, que es la capacidad de la base de datos para conservar un resultado de confirmación garantizado que indica si una transacción se ha confirmado y completado. Oracle AI Database proporciona la API para JDBC Thin, OCI, OCCI y ODP.Net.

Un error recuperable se debe a un fallo del sistema externo, independientemente de la lógica de sesión de la aplicación que se está ejecutando. Los errores recuperables se producen después de interrupciones planificadas y no planificadas de los procesos, redes, nodos, almacenamiento y bases de datos en primer plano. Si una interrupción interrumpe la conexión entre una aplicación cliente y la base de datos, la aplicación recibe un mensaje de error de desconexión. La transacción que se estaba ejecutando cuando se interrumpió la conexión se denomina transacción en ejecución.

Para decidir si desea volver a enviar la transacción o devolver el resultado (confirmado o no) al cliente, la aplicación debe determinar el resultado de la transacción en curso. Antes de Oracle Database 12c, los mensajes de confirmación devueltos al cliente no eran persistentes. La comprobación de una transacción no garantiza que no se confirmaría después de comprobarla, lo que permite transacciones duplicadas y otras formas de corrupción lógica. Por ejemplo, un usuario puede actualizar un navegador web al comprar un libro en línea y se le cobrará dos veces por el mismo libro.

Consulte además:

Ventajas del gestor de transacciones

A partir de Oracle Database 12c, el gestor de transacciones proporciona a las aplicaciones una herramienta para determinar el estado de una transacción en ejecución tras una interrupción recuperable.

Con el gestor de transacciones, una aplicación puede asegurarse de que una transacción se ejecuta no más de una vez. Por ejemplo, si una aplicación de librería en línea determina que la confirmación enviada anteriormente falló, la aplicación puede volver a enviarla de forma segura.

El gestor de transacciones proporciona una herramienta para la ejecución casi una vez a fin de evitar que la aplicación ejecute ejecuciones duplicadas. El gestor de transacciones proporciona un resultado conocido para cada transacción.

Transaction Guard es una capacidad principal de Oracle AI Database. La continuidad de aplicaciones utiliza el gestor de transacciones al enmascarar las interrupciones de los usuarios finales. Sin el gestor de transacciones, un reintento de aplicación después de un error puede provocar que se confirmen las transacciones duplicadas.

Consulte además:

Funcionamiento de Transaction Guard

En esta sección se explica el problema de los mensajes de confirmación perdidos y cómo el gestor de transacciones utiliza identificadores de transacciones lógicos para resolver el problema.

Mensajes de confirmación perdidos

Al diseñar para idempotence, los desarrolladores deben abordar el problema de los fallos de comunicación después del envío de sentencias de confirmación. Los mensajes de confirmación no persisten en la base de datos, por lo que no se pueden recuperar después de un fallo.

El siguiente gráfico es una representación de alto nivel de una interacción entre una aplicación cliente y una base de datos.

Figura 2: Mensaje de confirmación perdido

Descripción de la ilustración cncpt356.png

En el caso de confirmación estándar, la base de datos confirma una transacción y devuelve un mensaje de éxito al cliente. En la Figura 13-2, el cliente envía una sentencia de confirmación y recibe un mensaje que indica que la comunicación ha fallado. Este tipo de fallo se puede producir por varios motivos, incluido un fallo de instancia de base de datos o una interrupción de red. En este escenario, el cliente no conoce el estado de la transacción.

Después de un fallo de comunicación, es posible que la base de datos aún esté ejecutando el envío y no tenga en cuenta que el cliente se desconectó. La comprobación del estado de la transacción no garantiza que una transacción activa no se confirmará después de la comprobación. Si el cliente vuelve a enviar la confirmación debido a esta información desactualizada, la base de datos puede repetir la transacción, lo que da como resultado una corrupción lógica.

ID de transacción lógica

Oracle AI Database resuelve el fallo de comunicación mediante un identificador único global denominado ID de transacción lógica.

Este ID contiene el número de sesión lógica asignado cuando una sesión se conecta por primera vez y un número de confirmación en ejecución que se actualiza cada vez que la sesión confirma o realiza un rollback de back.Foot 1 Desde la perspectiva de la aplicación, el ID de transacción lógica identifica de forma única la última transacción de base de datos enviada en la sesión que ha fallado.

Para cada ida y vuelta desde el cliente en el que se confirman una o más transacciones, la base de datos almacena un ID de transacción lógica. Este ID puede proporcionar idempotencia de transacción para las interacciones entre la aplicación y la base de datos para cada ida y vuelta que confirme los datos.

El protocolo casi una vez permite el acceso al resultado de confirmación al solicitar a la base de datos que haga lo siguiente:

Mientras se ejecuta una transacción, tanto la base de datos como el cliente mantienen el ID de transacción lógica. La base de datos proporciona al cliente un ID de transacción lógica en la autenticación, al tomar prestado de un pool de conexiones y en cada ida y vuelta desde el controlador del cliente que ejecuta una o más operaciones de confirmación.

Antes de que la aplicación pueda determinar el resultado de la última transacción tras un error recuperable, la aplicación obtiene el ID de transacción lógica que se mantiene en el cliente mediante las API de Java, OCI, OCCI o ODP.Net. A continuación, la aplicación llama al procedimiento PL/SQL DBMS_APP_CONT.GET_LTXID_OUTCOME con el ID de transacción lógica para determinar el resultado de la última ejecución: confirmada (true o false) y llamada de usuario completada (true o false).

Al utilizar el gestor de transacciones, la aplicación puede reproducir transacciones cuando el error sea recuperable y la última transacción de la sesión no se haya confirmado. La aplicación puede continuar cuando la última transacción se haya confirmado y la llamada de usuario haya finalizado. La aplicación puede utilizar el gestor de transacciones para devolver el resultado conocido al cliente para que éste pueda decidir la siguiente acción que se va a realizar.

Consulte además:

Gestor de transacciones: ejemplo

En este escenario, el mensaje de confirmación se pierde debido a un error recuperable.

Transaction Guard utiliza el identificador de transacción lógico para conservar el resultado de la sentencia COMMIT, lo que garantiza que hay un resultado conocido para la transacción.

Figura 3: Comprobación del estado de la transacción lógica

Descripción de la ilustración cncpt365.png

En la Figura 13-3, la base de datos informa a la aplicación si la transacción se ha confirmado y si la última llamada de usuario ha finalizado. La aplicación puede devolver el resultado al usuario final. Las posibilidades son:

Consulte también: Guía de desarrollo de Oracle AI Database para aprender a utilizar Transaction Guard

Descripción general de la continuidad de aplicaciones

La continuidad de aplicaciones intenta enmascarar las interrupciones de las aplicaciones mediante la reproducción de solicitudes de aplicaciones incompletas después de interrupciones no planificadas y planificadas. En este contexto, una solicitud es una unidad de trabajo de la aplicación.

Normalmente, una solicitud se corresponde con las sentencias DML y otras llamadas a la base de datos de una única solicitud web en una única conexión a base de datos. En general, las llamadas realizadas entre la desprotección y la protección de una conexión a base de datos desde un pool de conexiones delimitan una solicitud.

Esta sección incluye los siguientes temas:

Ventajas de la continuidad de aplicaciones

Un problema básico para los desarrolladores es cómo enmascarar una sesión de base de datos perdida de los usuarios finales.

La continuidad de aplicaciones intenta resolver el problema de la sesión perdida restaurando la sesión de la base de datos cuando cualquier componente interrumpe la conversación entre la base de datos y el cliente. La sesión de base de datos restaurada incluye todos los estados, cursores, variables y la transacción más reciente cuando existe.

Caso de uso para la continuidad de aplicaciones

En un caso típico, un cliente ha enviado una solicitud a la base de datos, que ha creado estados transaccionales y no transaccionales.

El estado del cliente sigue siendo actual, posiblemente con los datos introducidos, los datos devueltos y los datos y variables almacenados en caché. Sin embargo, el estado de la sesión de la base de datos, en el que la aplicación debe operar, se pierde.

Si la solicitud del cliente ha iniciado una o más transacciones, la aplicación se enfrenta a las siguientes posibilidades:

Si la reproducción se realiza correctamente, el servicio de usuario de la base de datos para interrupciones planificadas y no planificadas no se interrumpe. Si la base de datos detecta cambios en los datos vistos y sobre los que la aplicación podría actuar, se rechaza la reproducción. No se intenta reproducir cuando se supera el tiempo permitido para iniciar la reproducción, la aplicación utiliza una llamada restringida o la aplicación ha desactivado explícitamente la reproducción mediante el método disableReplay.

Consulte también: Guía de despliegue y administración de Oracle Real Application Clusters para obtener más información sobre cómo funciona la continuidad de aplicaciones para sesiones de base de datos

Continuidad de aplicación para mantenimiento planificado

La continuidad de aplicaciones para interrupciones planificadas permite a las aplicaciones continuar las operaciones para sesiones de base de datos que se pueden drenar o migrar de forma fiable.

El mantenimiento programado no tiene que interrumpir el trabajo de la aplicación. La continuidad de aplicaciones proporciona tiempo de trabajo activo para drenar de su ubicación actual a una nueva ubicación que actualmente no se ve afectada por el mantenimiento. Al final del intervalo de vaciado, las sesiones pueden permanecer en la instancia de base de datos donde se planifica el mantenimiento. En lugar de desconectar forzosamente estas sesiones, la continuidad de aplicaciones puede realizar un failover de estas sesiones en un sitio restante y volver a enviar las transacciones en ejecución.

Con la continuidad de aplicaciones activada, la base de datos puede hacer lo siguiente:

Controle el comportamiento de vaciado durante el mantenimiento planificado mediante los atributos de servicio drain_timeout y stop_option de la utilidad SRVCTL, la utilidad de control de servicios de datos globales (GDSCTL) y Oracle Data Guard Broker. El paquete DBMS_SERVICE proporciona la infraestructura subyacente.

Consulte además:

Arquitectura de continuidad de aplicaciones

Los componentes clave de la continuidad de aplicaciones son tiempo de ejecución, reconexión y reproducción.

Las fases son las siguientes:

  1. Tiempo de ejecución normal

    En esta fase, la continuidad de aplicaciones realiza las siguientes tareas:

    • Identifica las solicitudes de base de datos

    • Decide si las llamadas locales y de base de datos se pueden reproducir

    • Crea objetos proxy para activar la reproducción, si es necesario, y para gestionar colas

    • Contiene las llamadas originales y la validación de estas llamadas hasta que se desactiva el final de la solicitud o reproducción de la base de datos

  2. Reconexión

    Esta fase se dispara por un error recuperable. La continuidad de aplicaciones realiza las siguientes tareas:

    • Garantiza que la reproducción está activada para las solicitudes de base de datos

    • Gestiona los timeouts

    • Obtiene una nueva conexión a la base de datos y, a continuación, valida que se trata de un destino de base de datos válido

    • Utiliza el gestor de transacciones para determinar si la última transacción se ha confirmado correctamente (las transacciones confirmadas no se han reenviado)

  3. Reproducir

    La continuidad de aplicaciones realiza las siguientes tareas:

    • Reproduce las llamadas que se mantienen en la cola

    • Desactiva la reproducción si aparecen los cambios visibles para el usuario en los resultados durante la reproducción

    • No permite una confirmación, pero permite que se confirme la última recuperación (que ha detectado el error)

Tras una reproducción correcta, la solicitud continúa desde el punto de fallo.

Consulte además:

Visión general de las transacciones autónomas

Una transacción autónoma es una transacción independiente que se puede llamar desde otra transacción, que es la transacción principal. Puede suspender la transacción de llamada, realizar operaciones SQL y confirmarlas o deshacerlas en la transacción autónoma y, a continuación, reanudar la transacción de llamada.

Las transacciones autónomas son útiles para las acciones que se deben realizar de forma independiente, independientemente de si la transacción de llamada se confirma o se realiza un rollback. Por ejemplo, en una transacción de compra de stock, desea confirmar los datos del cliente independientemente de si se realiza la compra de stock global. Además, desea registrar mensajes de error en una tabla de depuración incluso si se realiza un rollback de la transacción general.

Las transacciones autónomas tienen las siguientes características:

En PL/SQL, una transacción autónoma se ejecuta dentro de un ámbito autónomo, que es una rutina marcada con el pragma AUTONOMOUS_TRANSACTION. En este contexto, las rutinas incluyen bloques PL/SQL anónimos de nivel superior y subprogramas y disparadores PL/SQL. Un pragma es una directiva que indica al compilador que realice una opción de compilación. El pragma AUTONOMOUS_TRANSACTION indica a la base de datos que este procedimiento, cuando se ejecuta, se debe ejecutar como una nueva transacción autónoma que es independiente de su transacción principal.

El siguiente gráfico muestra cómo el control fluye de la rutina principal (MT) a una rutina autónoma y viceversa. La rutina principal es proc1 y la rutina autónoma es proc2. La rutina autónoma puede confirmar varias transacciones (AT1 y AT2) antes de que el control vuelva a la rutina principal.

Figura 4: Flujo de control de transacciones

Descripción de la ilustración cncpt288.gif

Al introducir la sección ejecutable de una rutina autónoma, la rutina principal se suspende. Al salir de la rutina autónoma, se reanuda la rutina principal.

En la Figura 13-4, COMMIT dentro de proc1 hace permanente no solo su propio trabajo, sino cualquier trabajo pendiente realizado en su sesión. Sin embargo, un COMMIT en proc2 solo hace permanente el trabajo realizado en la transacción proc2. Por lo tanto, las sentencias COMMIT de las transacciones AT1 y AT2 no tienen ningún efecto en la transacción MT.

Consulte también: Guía de desarrollo de Oracle AI Database y Referencia de lenguaje PL/SQL de Oracle AI Database para aprender a utilizar transacciones autónomas

Visión general de transacciones distribuidas

Una transacción distribuida es una transacción que incluye una o más sentencias que actualizan datos en dos o más nodos distintos de una base de datos distribuida, utilizando un objeto de esquema denominado enlace de base de datos.

Una base de datos distribuida es un juego de bases de datos de un sistema distribuido que puede aparecer a las aplicaciones como un único origen de datos. Un enlace de base de datos describe cómo una instancia de base de datos puede conectarse a otra.

A diferencia de una transacción en una base de datos local, una transacción distribuida altera los datos en varias bases de datos. En consecuencia, el procesamiento de transacciones distribuidas es más complicado porque la base de datos debe coordinar la confirmación o el rollback de los cambios en una transacción como una unidad atómica. Toda la transacción se debe confirmar o realizar un rollback. Oracle AI Database debe coordinar el control de transacciones sobre una red y mantener la consistencia de los datos, incluso si se produce un fallo de la red o del sistema.

Confirmación en Dos Fases

El mecanismo de confirmación en dos fases garantiza que todas las bases de datos que participan en una transacción distribuida confirman o deshacen todas las sentencias de la transacción. El mecanismo también protege el DML implícito realizado por restricciones de integridad, llamadas a procedimientos remotos y disparadores.

En una confirmación en dos fases entre varias bases de datos, una base de datos coordina la transacción distribuida. El nodo de inicio se denomina coordinador global. El coordinador pregunta a las otras bases de datos si están preparadas para comprometerse. Si alguna base de datos responde con un valor No, se realiza un rollback de toda la transacción. Si todas las bases de datos votan Sí, el coordinador emite un mensaje para que la confirmación sea permanente en cada una de las bases de datos.

El mecanismo de confirmación en dos fases es transparente para los usuarios que emiten transacciones distribuidas. De hecho, los usuarios ni siquiera necesitan saber que la transacción está distribuida. Una sentencia COMMIT que indica el final de una transacción dispara automáticamente el mecanismo de confirmación en dos fases. No se necesita codificación ni sintaxis de sentencias complejas para incluir transacciones distribuidas en el cuerpo de una aplicación de base de datos.

Consulte además:

Transacciones Dudosas

Una transacción distribuida dudosa se produce cuando cualquier tipo de fallo del sistema o de la red interrumpió una confirmación en dos fases.

Por ejemplo, dos bases de datos informan a la base de datos de coordinación que estaban preparadas para confirmar, pero la instancia de base de datos de coordinación falla inmediatamente después de recibir los mensajes. Las dos bases de datos que están preparadas para la confirmación ahora se quedan bloqueadas mientras esperan la notificación del resultado.

El proceso en segundo plano del recuperador (RECO) resuelve automáticamente el resultado de las transacciones distribuidas dudosas. Una vez que se repara el fallo y se restablece la comunicación, el proceso RECO de cada base de datos Oracle local confirma o revierte automáticamente cualquier transacción distribuida dudosa de forma consistente en todos los nodos implicados.

En caso de fallo a largo plazo, Oracle AI Database permite a cada administrador local confirmar o deshacer manualmente cualquier transacción distribuida que esté en duda debido al fallo. Esta opción permite al administrador de la base de datos local liberar los recursos bloqueados que se mantienen indefinidamente debido a un fallo a largo plazo.

Si se debe recuperar una base de datos hasta un momento anterior, las utilidades de recuperación de bases de datos permiten a los administradores de bases de datos de otros sitios devolver sus bases de datos al momento anterior. Esta operación garantiza que la base de datos global permanezca consistente.

Consulte además:

Notas

Nota a Pie de Página 1:

Para Oracle Real Application Clusters (Oracle RAC), el ID de transacción lógica incluye el número de instancia de base de datos como prefijo.