Autonom transaksjon i Oracle PL / SQL

Hva er TCL-uttalelser i PL/SQL?

TCL står for Transaction Control Statements (transaksjonskontrollutsagn). Disse utsagnene lagrer enten ventende transaksjoner eller tilbakestiller ventende transaksjoner. De spiller en viktig rolle, fordi med mindre en transaksjon lagres, vil endringene som gjøres gjennom DML uttalelser vil ikke bli lagret permanent i databasen. Nedenfor er de forskjellige TCL-setningene i PL / SQL.

Transaksjonen vil bli fullført under følgende scenarier:

• Når noen av de ovennevnte utstedelsene utstedes (unntatt SAVEPOINT).
• Når DDL-setninger utstedes (DDL er auto-commit-setninger).
• Når DCL-setninger utstedes (DCL er auto-commit-setninger).

Bruke SAVEPOINT og ROLLBACK TO

Tabellen ovenfor introduserer LAGREPOINT og TILBAKERULLING TIL, og sammen gir de deg delvis kontroll over en transaksjon. Et LAGREPOINT markerer et navngitt punkt i den gjeldende transaksjonen. En senere TILBAKERULLING TIL det lagringspunktet angrer alle endringer som er gjort etter det, mensping arbeidet som ble gjort før det intakt.

Dette er nyttig når en lang transaksjon utfører flere SQL trinn, og bare det siste trinnet mislykkes. I stedet for å forkaste hele transaksjonen, kan du rulle tilbake til det siste gode lagringspunktet og fortsette.

Syntaks:

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

Viktige punkter å huske på om lagringspunkter:

• Et SAVEPOINT finnes bare i den gjeldende transaksjonen; en COMMIT eller en fullstendig ROLLBACK sletter alle savepoints.
• Når du ruller tilbake til et lagringspunkt, slettes alle lagringspunkter som ble opprettet etter det, men lagringspunktet du ruller tilbake til beholdes.
• ROLLBACK TO avslutter ikke transaksjonen; endringene som ble gjort før lagringspunktet forblir ventende inntil du COMMIT eller ROLLBACK.
• Hvis du bruker et lagringspunktnavn på nytt, flytter det nyere lagringspunktet markøren til den senere posisjonen.

Fordi ROLLBACK TO lar transaksjonen være åpen, bestemmer du fortsatt på slutten om du vil UTFØRE de gjenværende endringene eller forkaste dem med en fullstendig ROLLBACK.

Hva er autonom transaksjon

I PL/SQL kalles alle modifikasjoner som gjøres på data en transaksjon. En transaksjon anses som fullført når en lagring eller forkasting er angitt på den. Hvis ingen lagring eller forkasting er angitt, anses ikke transaksjonen som fullført, og modifikasjonene som er gjort på dataene vil ikke bli permanente på serveren.

Som standard behandler PL/SQL alle modifikasjonene i løpet av en økt som én enkelt transaksjon, og lagring eller forkasting av den transaksjonen påvirker alle ventende endringer i økten. En autonom transaksjon gir utvikleren muligheten til å gjøre endringer i en separat transaksjon og lagre eller forkaste den bestemte transaksjonen uten å påvirke hovedsesjonstransaksjonen.

• En autonom transaksjon kan spesifiseres på underprogramnivå.
• Å lage noen delprogram fungerer i en annen transaksjon, bør nøkkelordet PRAGMA AUTONOMOUS_TRANSACTION oppgis i den deklarative delen av den blokken.
• Den instruerer kompilatoren til å behandle dette som en separat transaksjon, og lagring eller forkastelse i denne blokken vil ikke gjenspeiles i hovedtransaksjonen.
• Det er obligatorisk å utstede COMMIT eller ROLLBACK før man forlater denne autonome transaksjonen og går tilbake til hovedtransaksjonen, fordi bare én transaksjon kan være aktiv til enhver tid.
• Så når en autonom transaksjon er startet, må den lagres og fullføres før kontrollen kan gå tilbake til hovedtransaksjonen.

Syntaks:

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

I syntaksen ovenfor er blokken gjort til en autonom transaksjon.

Eksempel 1: I dette eksemplet skal vi forstå hvordan en autonom transaksjon fungerer.

Skjermbildet nedenfor viser dette eksemplet på autonom transaksjon og resultatet 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;

Produksjon

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: Deklarerer nested_block-prosedyren.
• Code linje 4: Gjør nested_block-prosedyren til en AUTONOMOUS_TRANSACTION.
• Code linje 7–9: Øke lønnen for ansatt nummer 1002 med 15000.
• Code linje 10: Utfører den autonome transaksjonen.
• Code linje 13–16: Utskrift av lønnsdetaljene til ansatte 1001 og 1002 før endringene.
• Code linje 17–19: Øke lønnen for ansatt nummer 1001 med 5000.
• Code linje 20: Kaller nested_block-prosedyren.
• Code linje 21: Forkaster hovedtransaksjonen.
• Code linje 22–25: Utskrift av lønnsdetaljene til ansatte 1001 og 1002 etter endringene.

Lønnsøkningen for ansatt nummer 1001 gjenspeiles ikke fordi hovedtransaksjonen er forkastet. Lønnsøkningen for ansatt nummer 1002 gjenspeiles fordi den blokken er gjort til en separat transaksjon og lagret på slutten.

Så uavhengig av lagring eller forkastelse ved hovedtransaksjonen, lagres endringene i den autonome transaksjonen uten at det påvirker hovedtransaksjonen.

Når skal man bruke autonome transaksjoner

Autonome transaksjoner er kraftige, så det hjelper å vite når de passer. Reserver dem for arbeid som må lykkes eller mislykkes uavhengig av hovedtransaksjonen, ikke for kjernevirksomhetslogikk. Vanlige brukstilfeller inkluderer:

• Revisjonslogging: Registrer hvem som endret sensitive data, når, og de gamle og nye verdiene, slik at loggen bevares selv om hovedtransaksjonen rulles tilbake.
• Feillogging: Skriv en feiloppføring inni en unntak behandleren og COMMIT den, slik at diagnostikkdetaljene beholdes mens den mislykkede transaksjonen forkastes.
• Tellere og statistikk: Fremskynd en bruksteller eller treffteller som må vare uavhengig av innringerens utfall.
• COMMIT inne i en trigger: En trigger kan ikke utstede COMMIT direkte; en autonom transaksjon er den eneste støttede måten å gjøre det på.

Unngå autonome transaksjoner for vanlige oppdateringer som skal dele skjebnen med hovedtransaksjonen. Overbruk av dem kan skjule data bak uavhengige commits og gjøre feilsøking vanskeligere. Som regel må hver autonom blokk avsluttes med en eksplisitt COMMIT eller ROLLBACK.

Autonome vs. vanlige transaksjoner

Forskjellen mellom en vanlig (hoved)transaksjon og en autonom transaksjon kommer ned til omfang og uavhengighet. Tabellen nedenfor sammenligner dem.

I motsetning til en vanlig nestet blokk, hvis endringer alltid deler resultatet av den omsluttende transaksjonen, står en autonom blokk på egenhånd. Å forstå denne forskjellen hjelper deg med å bestemme når en blokk skal være uavhengig og når den skal dele resultatet av hovedtransaksjonen.

Spørsmål og svar