Transacción Autónoma en Oracle PL / SQL

¿Qué son las declaraciones TCL en PL/SQL?

TCL significa Sentencias de Control de Transacciones. Estas sentencias guardan las transacciones pendientes o las revierten. Juegan un papel vital, porque a menos que se guarde una transacción, los cambios realizados a través de Declaraciones DML no se almacenará permanentemente en la base de datos. A continuación se muestran las diferentes sentencias TCL en PL / SQL.

La transacción se completará en los siguientes casos:

• Cuando se emita cualquiera de las declaraciones anteriores (excepto SAVEPOINT).
• Cuando se emiten sentencias DDL (las DDL son sentencias de confirmación automática).
• Cuando se emiten sentencias DCL (las DCL son sentencias de confirmación automática).

Usando SAVEPOINT y ROLLBACK TO

La tabla anterior presenta SAVEPOINT y ROLLBACK TO, y juntos le brindan un control parcial sobre una transacción. Un SAVEPOINT marca un punto con nombre dentro de la transacción actual. Un ROLLBACK TO posterior a ese punto de guardado deshace todos los cambios realizados después de él, mientras que el mantenimientoping el trabajo realizado antes de que permaneciera intacto.

Esto es útil cuando una transacción larga realiza varias SQL Se han ejecutado varios pasos, pero solo falla el último. En lugar de descartar toda la transacción, puede revertir al último punto de guardado válido y continuar.

Sintaxis:

SAVEPOINT <savepoint_name>;
   -- one or more DML statements
ROLLBACK TO <savepoint_name>;

Puntos clave a tener en cuenta sobre los puntos de guardado:

• Un punto de guardado solo existe dentro de la transacción actual; un COMMIT o un ROLLBACK completo borra todos los puntos de guardado.
• Cuando se restaura un punto de guardado, se borran todos los puntos de guardado creados posteriormente, pero se conserva el punto de guardado al que se restaura.
• ROLLBACK TO no finaliza la transacción; los cambios realizados antes del punto de guardado permanecen pendientes hasta que se confirme o se revierta la transacción.
• Si reutilizas el nombre de un punto de guardado, el nuevo nombre de punto de guardado desplazará el marcador a la posición posterior.

Dado que ROLLBACK TO deja la transacción abierta, al final usted decide si confirma los cambios restantes o los descarta con un ROLLBACK completo.

¿Qué es la transacción autónoma?

En PL/SQL, todas las modificaciones realizadas en los datos se denominan transacciones. Una transacción se considera completa cuando se le aplica una operación de guardar o descartar. Si no se aplica ninguna operación, la transacción no se considera completa y las modificaciones realizadas en los datos no se guardarán de forma permanente en el servidor.

Por defecto, PL/SQL trata todas las modificaciones durante una sesión como una sola transacción, y guardar o descartar dicha transacción afecta a todos los cambios pendientes en la sesión. Una transacción autónoma permite al desarrollador realizar cambios en una transacción independiente y guardar o descartar esa transacción en particular sin afectar a la transacción principal de la sesión.

• Se puede especificar una transacción autónoma a nivel de subprograma.
• para hacer cualquier subprograma Para trabajar en una transacción diferente, se debe proporcionar la palabra clave PRAGMA AUTONOMOUS_TRANSACTION en la sección declarativa de ese bloque.
• Indica al compilador que trate esto como una transacción separada, y que guardar o descartar dentro de este bloque no se reflejará en la transacción principal.
• Es obligatorio emitir COMMIT o ROLLBACK antes de abandonar esta transacción autónoma y regresar a la transacción principal, ya que en cualquier momento solo puede haber una transacción activa.
• Por lo tanto, una vez que se inicia una transacción autónoma, debe guardarse y completarse antes de que el control pueda volver a la transacción principal.

Sintaxis:

DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
.
BEGIN
<execution_part>
[COMMIT|ROLLBACK]
END;
/

En la sintaxis anterior, el bloque se ha convertido en una transacción autónoma.

Ejemplo 1: En este ejemplo, vamos a comprender cómo funciona una transacción autónoma.

La captura de pantalla a continuación muestra este ejemplo de transacción autónoma y su resultado en Oracle.

DECLARE
   l_salary   NUMBER;
   PROCEDURE nested_block IS
   PRAGMA autonomous_transaction;
    BEGIN
     UPDATE emp
       SET salary = salary + 15000
       WHERE emp_no = 1002;
   COMMIT;
   END;
BEGIN
   SELECT salary INTO l_salary FROM emp WHERE emp_no = 1001;
   dbms_output.put_line('Before Salary of 1001 is'|| l_salary);
   SELECT salary INTO l_salary FROM emp WHERE emp_no = 1002;
   dbms_output.put_line('Before Salary of 1002 is'|| l_salary);    
   UPDATE emp 
   SET salary = salary + 5000 
   WHERE emp_no = 1001;

nested_block;
ROLLBACK;

 SELECT salary INTO  l_salary FROM emp WHERE emp_no = 1001;
 dbms_output.put_line('After Salary of 1001 is'|| l_salary);
 SELECT salary INTO l_salary FROM emp WHERE emp_no = 1002;
 dbms_output.put_line('After Salary of 1002 is '|| l_salary);
end;

Resultado

Before:Salary of 1001 is 15000 
Before:Salary of 1002 is 10000 
After:Salary of 1001 is 15000 
After:Salary of 1002 is 25000

Code Explicación:

• Code línea 2: Declarando l_salary como NÚMERO.
• Code línea 3: Declarando el procedimiento nested_block.
• Code línea 4: Convertir el procedimiento nested_block en una TRANSACCIÓN AUTÓNOMA.
• Code líneas 7-9: Incrementar el salario del empleado número 1002 en 15000.
• Code línea 10: Realizando la transacción autónoma.
• Code líneas 13-16: Impresión de los detalles salariales de los empleados 1001 y 1002 antes de los cambios.
• Code líneas 17-19: Incrementar el salario del empleado número 1001 en 5000.
• Code línea 20: Llamando al procedimiento nested_block.
• Code línea 21: Descartando la transacción principal.
• Code líneas 22-25: Impresión de los detalles salariales de los empleados 1001 y 1002 después de los cambios.

El aumento salarial del empleado número 1001 no se refleja porque la transacción principal se descartó. El aumento salarial del empleado número 1002 sí se refleja porque ese bloque se convirtió en una transacción separada y se guardó al final.

Por lo tanto, independientemente de si se guarda o se descarta en la transacción principal, los cambios en la transacción autónoma se guardan sin afectar a la transacción principal.

¿Cuándo utilizar transacciones autónomas?

Las transacciones autónomas son potentes, por lo que conviene saber cuándo son apropiadas. Resérvelas para tareas que deban tener éxito o fracasar independientemente de la transacción principal, no para la lógica empresarial central. Algunos casos de uso comunes son:

• Registro de auditoría: Registra quién modificó los datos confidenciales, cuándo y los valores antiguos y nuevos, para que el registro se conserve incluso si la transacción principal se revierte.
• Registro de errores: Escriba un registro de error dentro de un excepción manejador y COMMIT, de modo que se conserva el detalle de diagnóstico mientras que la transacción fallida se descarta.
• Contadores y estadísticas: Incrementar un contador de uso o un contador de visitas que debe persistir independientemente del resultado de la llamada.
• COMMIT dentro de un disparador: Un disparador no puede emitir COMMIT directamente; una transacción autónoma es la única forma admitida de hacerlo.

Evite las transacciones autónomas para actualizaciones ordinarias que deberían seguir el mismo destino que la transacción principal. Su uso excesivo puede ocultar datos tras confirmaciones independientes y dificultar la depuración. Por regla general, cada bloque autónomo debe finalizar con una confirmación (COMMIT) o una reversión (ROLLBACK) explícitas.

Transacciones autónomas frente a transacciones regulares

La diferencia entre una transacción regular (principal) y una transacción autónoma radica en su alcance e independencia. La siguiente tabla las compara.

A diferencia de un regular bloque anidadoUn bloque autónomo, cuyos cambios siempre comparten el resultado de la transacción que lo contiene, es independiente. Comprender esta diferencia ayuda a decidir cuándo un bloque debe ser independiente y cuándo debe compartir el resultado de la transacción principal.

Preguntas Frecuentes