Autonom transaktion i Oracle PL / SQL

Hvad er TCL-erklæringer i PL/SQL?

TCL står for Transaction Control Statements (Transaktionskontrolerklæringer). Disse erklæringer gemmer enten de ventende transaktioner eller ruller dem tilbage. De spiller en afgørende rolle, fordi medmindre en transaktion gemmes, vil de ændringer, der foretages via DML erklæringer vil ikke blive gemt permanent i databasen. Nedenfor er de forskellige TCL-sætninger i PL / SQL.

Transaktionen vil være gennemført under følgende scenarier:

• Når en af ​​ovenstående erklæringer udstedes (undtagen SAVEPOINT).
• Når DDL-udsagn udstedes (DDL er auto-commit-udsagn).
• Når DCL-udsagn udstedes (DCL er auto-commit-udsagn).

Brug af SAVEPOINT og ROLLBACK TO

Tabellen ovenfor introducerer SAVEPOINT og ROLLBACK TO, og sammen giver de dig delvis kontrol over en transaktion. Et SAVEPOINT markerer et navngivet punkt i den aktuelle transaktion. En senere ROLLBACK TO til det gemte punkt fortryder alle ændringer foretaget efter det, mensping det arbejde, der blev udført før det, intakt.

Dette er nyttigt, når en lang transaktion udfører flere SQL trin, og kun det sidste trin mislykkes. I stedet for at kassere hele transaktionen kan du rulle tilbage til det sidste gode gemte punkt og fortsætte.

Syntaks:

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

Vigtige punkter at huske på om savepoints:

• Et SAVEPOINT findes kun i den aktuelle transaktion; en COMMIT eller en fuld ROLLBACK sletter alle savepoints.
• Når du vender tilbage til et gemte punkt, slettes alle gemte punkter, der er oprettet efter det, men det gemte punkt, du vender tilbage til, bevares.
• ROLLBACK TO afslutter ikke transaktionen; ændringer foretaget før gemte punktet forbliver ventende, indtil du udfører COMMIT eller ROLLBACK.
• Hvis du genbruger et navn på et gemt punkt, flytter det nyere gemte punkt markøren til den senere position.

Fordi ROLLBACK TO lader transaktionen være åben, bestemmer du stadig til sidst, om du vil COMMIT de resterende ændringer eller kassere dem med en fuld ROLLBACK.

Hvad er autonom transaktion

I PL/SQL kaldes alle ændringer foretaget på data en transaktion. En transaktion betragtes som fuldført, når der foretages en gemning eller kassering på den. Hvis der ikke angives nogen gemning eller kassering, betragtes transaktionen ikke som fuldført, og ændringerne foretaget på dataene vil ikke blive permanente på serveren.

Som standard behandler PL/SQL alle ændringer under en session som en enkelt transaktion, og lagring eller kassering af denne transaktion påvirker alle ventende ændringer i sessionen. En autonom transaktion giver udvikleren mulighed for at foretage ændringer i en separat transaktion og gemme eller kassere den pågældende transaktion uden at påvirke hovedsessionstransaktionen.

• En autonom transaktion kan specificeres på underprogramniveau.
• At lave evt underprogram arbejde i en anden transaktion, skal nøgleordet PRAGMA AUTONOMOUS_TRANSACTION angives i den deklarative del af den blok.
• Den instruerer compileren til at behandle dette som en separat transaktion, og lagring eller kassering i denne blok vil ikke afspejles i hovedtransaktionen.
• Det er obligatorisk at udstede COMMIT eller ROLLBACK, før man forlader denne autonome transaktion og vender tilbage til hovedtransaktionen, da kun én transaktion kan være aktiv på noget tidspunkt.
• Så når en autonom transaktion er startet, skal den gemmes og fuldføres, før kontrollen kan vende tilbage til hovedtransaktionen.

Syntaks:

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

I ovenstående syntaks er blokken blevet gjort til en autonom transaktion.

Eksempel 1: I dette eksempel vil vi forstå, hvordan en autonom transaktion fungerer.

Skærmbilledet nedenfor viser dette eksempel på en autonom transaktion og dens output i 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;

Produktion

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

• Code linje 2: Deklarerer l_salary som NUMBER.
• Code linje 3: Deklarering af nested_block-proceduren.
• Code linje 4: Gør nested_block-proceduren til en AUTONOMOUS_TRANSACTION.
• Code linje 7-9: Forhøjelse af lønnen for medarbejder nummer 1002 med 15000.
• Code linje 10: Udførelse af den autonome transaktion.
• Code linje 13-16: Udskrivning af lønoplysninger for medarbejdere 1001 og 1002 før ændringerne.
• Code linje 17-19: Forhøjelse af lønnen for medarbejder nummer 1001 med 5000.
• Code linje 20: Kald af nested_block-proceduren.
• Code linje 21: Kassering af hovedtransaktionen.
• Code linje 22-25: Udskrivning af lønoplysninger for medarbejdere 1001 og 1002 efter ændringerne.

Lønforhøjelsen for medarbejder nummer 1001 afspejles ikke, fordi hovedtransaktionen er blevet kasseret. Lønforhøjelsen for medarbejder nummer 1002 afspejles, fordi den pågældende blok er blevet gjort til en separat transaktion og gemt til sidst.

Så uanset om der gemmes eller kasseres ved hovedtransaktionen, gemmes ændringerne i den autonome transaktion uden at påvirke hovedtransaktionen.

Hvornår skal man bruge autonome transaktioner

Autonome transaktioner er effektive, så det er nyttigt at vide, hvornår de passer ind. Reserver dem til arbejde, der skal lykkes eller mislykkes uafhængigt af hovedtransaktionen, ikke til kerneforretningslogik. Almindelige anvendelsesscenarier inkluderer:

• Revisionslogning: Registrer hvem der ændrede følsomme data, hvornår, og de gamle og nye værdier, så loggen bevares, selvom hovedtransaktionen rulles tilbage.
• Fejllogning: Skriv en fejlpost i en undtagelse handler og COMMIT den, så de diagnostiske detaljer bevares, mens den mislykkede transaktion kasseres.
• Tællere og statistikker: Fremfør en brugstæller eller et hittæller, der skal bevares uanset opkalderens resultat.
• COMMIT inde i en trigger: En trigger kan ikke udstede COMMIT direkte; en autonom transaktion er den eneste understøttede måde at gøre det på.

Undgå autonome transaktioner til almindelige opdateringer, der skal dele skæbne med hovedtransaktionen. Overforbrug af dem kan skjule data bag uafhængige commits og gøre fejlfinding vanskeligere. Som regel skal enhver autonom blok afsluttes med en eksplicit COMMIT eller ROLLBACK.

Autonome vs. regelmæssige transaktioner

Forskellen mellem en almindelig (hoved)transaktion og en autonom transaktion kommer an på omfang og uafhængighed. Tabellen nedenfor sammenligner dem.

I modsætning til en almindelig indlejret blok, hvis ændringer altid deler resultatet af den omgivende transaktion, står en autonom blok alene. Forståelse af denne forskel hjælper dig med at beslutte, hvornår en blok skal være uafhængig, og hvornår den skal dele resultatet af hovedtransaktionen.

Ofte Stillede Spørgsmål