Transaction autonome dans Oracle PL / SQL

Que sont les instructions TCL en PL/SQL ?

TCL signifie Transaction Control Statements (instructions de contrôle des transactions). Ces instructions permettent soit d'enregistrer les transactions en cours, soit de les annuler. Elles jouent un rôle essentiel, car sans enregistrement, les modifications apportées à une transaction restent sans effet. Instructions DML ne seront pas stockées de manière permanente dans la base de données. Vous trouverez ci-dessous les différentes instructions TCL. PL / SQL.

La transaction sera finalisée dans les scénarios suivants :

• Lorsque l'une des instructions ci-dessus est émise (à l'exception de SAVEPOINT).
• Lorsque des instructions DDL sont émises (les instructions DDL sont des instructions à validation automatique).
• Lorsque des instructions DCL sont émises (les DCL sont des instructions à validation automatique).

Utiliser SAVEPOINT et ROLLBACK TO

Le tableau ci-dessus présente les commandes SAVEPOINT et ROLLBACK TO, qui, ensemble, vous offrent un contrôle partiel sur une transaction. Un SAVEPOINT marque un point précis au sein de la transaction en cours. Un ROLLBACK TO ultérieur à ce point de sauvegarde annule toutes les modifications effectuées après celui-ci, tandis que les modifications non enregistrées sont conservées.ping le travail effectué auparavant est intact.

Ceci est utile lorsqu'une transaction longue effectue plusieurs opérations. SQL L'opération se déroule en plusieurs étapes, seule la dernière échoue. Au lieu d'annuler la transaction entière, vous pouvez revenir au dernier point de sauvegarde valide et poursuivre.

syntaxe:

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

Points clés à retenir concernant les points de sauvegarde :

• Un point de sauvegarde n'existe que dans la transaction en cours ; une validation (COMMIT) ou une annulation complète (ROLLBACK) efface tous les points de sauvegarde.
• Lorsque vous revenez à un point de sauvegarde, tous les points de sauvegarde créés après celui-ci sont effacés, mais le point de sauvegarde auquel vous revenez est conservé.
• ROLLBACK TO ne met pas fin à la transaction ; les modifications effectuées avant le point de sauvegarde restent en attente jusqu’à ce que vous COMMANDIEZ ou ROLLBACK.
• Si vous réutilisez un nom de point de sauvegarde, le nouveau nom de point de sauvegarde déplace le marqueur vers la position ultérieure.

Étant donné que ROLLBACK TO laisse la transaction ouverte, vous décidez toujours à la fin s'il faut COMMIT les modifications restantes ou les annuler avec un ROLLBACK complet.

Qu'est-ce que la transaction autonome

En PL/SQL, toute modification apportée aux données constitue une transaction. Une transaction est considérée comme terminée lorsqu'une instruction de sauvegarde ou de suppression lui est appliquée. En l'absence d'instruction de sauvegarde ou de suppression, la transaction est considérée comme inachevée et les modifications apportées aux données ne sont pas enregistrées de manière permanente sur le serveur.

Par défaut, PL/SQL considère toutes les modifications effectuées au cours d'une session comme une seule transaction ; l'enregistrement ou l'annulation de cette transaction affecte toutes les modifications en cours dans la session. Une transaction autonome permet au développeur d'effectuer des modifications dans une transaction distincte et d'enregistrer ou d'annuler cette transaction sans affecter la transaction principale de la session.

• Une transaction autonome peut être spécifiée au niveau du sous-programme.
• Pour faire n'importe quel sous-programme Si l'opération s'effectue dans une transaction différente, le mot-clé PRAGMA AUTONOMOUS_TRANSACTION doit être indiqué dans la section déclarative de ce bloc.
• Il indique au compilateur de traiter cela comme une transaction distincte, et que les opérations d'enregistrement ou de suppression effectuées à l'intérieur de ce bloc n'auront aucun impact sur la transaction principale.
• L'émission d'une instruction COMMIT ou ROLLBACK est obligatoire avant de quitter cette transaction autonome et de revenir à la transaction principale, car à tout moment une seule transaction peut être active.
• Ainsi, une fois qu'une transaction autonome est lancée, elle doit être enregistrée et terminée avant que le contrôle puisse être rendu à la transaction principale.

syntaxe:

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

Dans la syntaxe ci-dessus, le bloc a été transformé en transaction autonome.

Exemple 1: Dans cet exemple, nous allons comprendre comment fonctionne une transaction autonome.

La capture d'écran ci-dessous illustre cet exemple de transaction autonome et son résultat. 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;

Sortie

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 Explication:

• Code ligne 2: Déclaration de l_salaire comme NUMBER.
• Code ligne 3: Déclaration de la procédure nested_block.
• Code ligne 4: Rendre la procédure nested_block une TRANSACTION AUTONOME.
• Code lignes 7-9 : Augmentation de 1002 15000 du salaire de l'employé numéro .
• Code ligne 10: S'engager dans la transaction autonome.
• Code lignes 13-16 : Impression des détails salariaux des employés 1001 et 1002 avant les modifications.
• Code lignes 17-19 : Augmentation de 1001 5000 du salaire de l'employé numéro .
• Code ligne 20: Appel de la procédure nested_block.
• Code ligne 21: Abandonner la transaction principale.
• Code lignes 22-25 : Impression des détails salariaux des employés 1001 et 1002 après les modifications.

L'augmentation de salaire de l'employé n° 1001 n'est pas prise en compte car la transaction principale a été annulée. L'augmentation de salaire de l'employé n° 1002 est prise en compte car cette opération a fait l'objet d'une transaction distincte et a été enregistrée ultérieurement.

Ainsi, indépendamment de l'enregistrement ou de l'annulation dans la transaction principale, les modifications apportées à la transaction autonome sont enregistrées sans affecter la transaction principale.

Quand utiliser les transactions autonomes

Les transactions autonomes sont puissantes ; il est donc important de savoir quand les utiliser. Réservez-les aux tâches qui doivent réussir ou échouer indépendamment de la transaction principale, et non à la logique métier essentielle. Voici quelques cas d’utilisation courants :

• Journalisation d'audit : Enregistrez qui a modifié les données sensibles, quand, ainsi que les anciennes et nouvelles valeurs, afin que le journal soit conservé même si la transaction principale est annulée.
• Journalisation des erreurs : Écrivez un enregistrement d'erreur à l'intérieur d'un exception gestionnaire et COMMIT, afin que les détails de diagnostic soient conservés tandis que la transaction ayant échoué est supprimée.
• Compteurs et statistiques : Avancer un compteur d'utilisation ou un nombre de requêtes qui doit persister quel que soit le résultat de l'appelant.
• COMMIT à l'intérieur d'un déclencheur : Un déclencheur ne peut pas émettre directement une instruction COMMIT ; seule une transaction autonome est prise en charge.

Évitez les transactions autonomes pour les mises à jour courantes qui doivent subir le même sort que la transaction principale. Leur utilisation excessive peut masquer des données derrière des validations indépendantes et compliquer le débogage. En règle générale, chaque bloc autonome doit se terminer par une validation (COMMIT) ou une annulation (ROLLBACK) explicite.

Transactions autonomes vs transactions régulières

La différence entre une transaction classique (principale) et une transaction autonome réside dans leur portée et leur indépendance. Le tableau ci-dessous les compare.

Contrairement à un régulier bloc imbriquéUn bloc autonome, dont les modifications reflètent toujours le résultat de la transaction principale, est indépendant. Comprendre cette différence vous aide à déterminer quand un bloc doit être indépendant et quand il doit refléter le résultat de la transaction principale.

FAQ