Transaktionsstyring i DBMS: Tilstande, typer og ACID

⚡ Smart opsummering

Database Transaction Management behandler en eller flere databaseoperationer som en enkelt logisk enhed, der flytter databasen fra én konsistent tilstand til en anden. Den er afhængig af ACID-egenskaber, definerede transaktionstilstande og tidsplaner for at holde samtidig adgang korrekt.

🔁 Kerneenhed: En transaktion grupperer relaterede læse- og skriveoperationer, så de lykkes eller fejler sammen, aldrig halvvejs.
🧪 SYRE egenskaber: AtomIsitet, konsistens, isolation og holdbarhed garanterer korrekte resultater, selv under fejl eller samtidighed.
🚦 Transaktionsstater: Aktiv, delvist committet, committet, mislykket og afsluttet beskriver en transaktions livscyklus.
👥 Hvorfor samtidighed: En database er delt, så mange transaktioner kører på én gang og må ikke beskadige hinandens data.
???? Tidsplaner: En tidsplan beordrer handlingerne i parallelle transaktioner, samtidig med at hver transaktions interne rækkefølge bevares.
🔗 Serialiserbarhed: En samtidig tidsplan er korrekt, når dens resultat er lig med en eller anden seriel udførelse, bedømt ud fra konflikt eller visningsækvivalens.
↩️ Genopretning: En mislykket transaktion rulles tilbage, så dens delvise skrivninger aldrig når den committede database.

Læs mere

Hvad er en databasetransaktion?

A Databasetransaktion er en logisk behandlingsenhed i et DBMS, som involverer en eller flere databaseadgangsoperationer. Kort sagt repræsenterer databasetransaktioner virkelige begivenheder i enhver virksomhed.

Alle typer databaseadgangsoperationer, der afholdes mellem start- og sluttransaktionssætningerne, betragtes som en enkelt logisk transaktion i DBMS. Under transaktionen er databasen inkonsistent. Først når transaktionen er committet, ændres tilstanden fra én konsistent tilstand til en anden.

Databasetransaktion bevæger sig mellem konsistente tilstande — Databasetransaktion

Fakta om databasetransaktioner

En transaktion er en programenhed, hvis udførelse kan ændre indholdet af en database eller ikke.
Transaktionskonceptet i DBMS udføres som en enkelt enhed.
Hvis databaseoperationerne ikke opdaterer databasen, men kun henter data, kaldes denne type transaktion en skrivebeskyttet transaktion.
En vellykket transaktion kan ændre databasen fra én KONSISTENT TILSTAND til en anden.
DBMS-transaktioner skal være atomare, konsistente, isolerede og holdbare.
Hvis databasen var i en inkonsistent tilstand før en transaktion, ville den forblive i den inkonsistente tilstand efter transaktionen.

Hvorfor har du brug for samtidighed i transaktioner?

En database er en delt ressource. Den bruges af mange brugere og processer samtidigt. Eksempler omfatter banksystemer, jernbane- og flyreservationssystemer, aktiemarkedsovervågning samt supermarkeders lagerbeholdning og kasser.

Hvis du ikke administrerer samtidig adgang, kan det skabe problemer som:

Hardwarefejl og systemnedbrud.
Samtidig udførelse af samme transaktion, dødvande, eller langsom ydeevne.

Det er opgaven for at kontrollere denne delte adgang samtidighedskontrol, som bruger låsning og tidsstempler til at sammenflette transaktioner sikkert. Før det er det nyttigt at kende de tilstande, en transaktion går igennem.

Transaktionstilstande

De forskellige tilstande af et transaktionskoncept i DBMS er angivet nedenfor:

Tilstand	Beskrivelse
Aktiv tilstand	En transaktion går ind i aktiv tilstand, når udførelsesprocessen begynder. I denne tilstand kan læse- eller skriveoperationer udføres.
Delvist engageret	En transaktion går ind i den delvist committede tilstand efter transaktionens afslutning.
Engageret stat	Når transaktionen når den committede tilstand, er den udført korrekt, og alle dens ændringer registreres permanent i databasen.
Mislykket tilstand	En transaktion betragtes som mislykket, når en af kontrollerne fejler, eller hvis transaktionen afbrydes, mens den er i aktiv tilstand.
Opsagt stat	En transaktions tilstand når den afsluttede tilstand, når transaktionen forlader systemet og ikke kan genstartes.

Lad os studere en tilstandsovergangsdiagram der fremhæver, hvordan en transaktion bevæger sig mellem disse forskellige stater.

Når en transaktion starter udførelsen, bliver den aktiv. Den kan udføre en LÆSNINGS- eller SKRIVNINGSoperation.
Når LÆSNINGS- og SKRIVNINGSoperationerne er fuldført, når transaktionen den delvist committede tilstand.
Dernæst skal nogle gendannelsesprotokoller sikre, at en systemfejl ikke resulterer i, at transaktionens ændringer ikke kan registreres permanent. Hvis denne kontrol lykkes, committes transaktionen og går i committed-tilstand.
Hvis kontrollen mislykkes, går transaktionen til tilstanden mislykket.
Hvis transaktionen afbrydes, mens den er i aktiv tilstand, går den tilbage til den fejlede tilstand. Transaktionen skal rulles tilbage for at fortryde effekten af dens skriveoperationer på databasen.
Den afsluttede tilstand refererer til transaktionen, der forlader systemet.

Hvad er ACID-egenskaber?

SYRE egenskaber bruges til at opretholde databasens integritet under transaktionsbehandling. ACID i DBMS står for Atomicitet, Cvedholdenhed, Isolation, og Dholdbarhed.

Atomisby: En transaktion er en enkelt operationsenhed. Du udfører det enten helt eller slet ikke. Der kan ikke være tale om delvis udførelse.
Konsistens: Når transaktionen er udført, bør den flytte fra en konsistent tilstand til en anden.
Isolering: En transaktion bør udføres isoleret fra andre transaktioner. Under samtidig udførelse bør mellemliggende resultater fra samtidigt udførte transaktioner ikke stilles til rådighed for hinanden.
Holdbarhed: Efter en vellykket afslutning af en transaktion bør ændringerne i databasen bevares, selv i tilfælde af systemfejl.

ACID-egenskab i DBMS med eksempel

Nedenfor er et eksempel på ACID-egenskaben i DBMS:

Transaction 1: Begin X=X+50, Y = Y-50 END
Transaction 2: Begin X=1.1*X, Y=1.1*Y END

Transaktion 1 er at overføre $50 fra konto X til konto Y.

Transaktion 2 krediterer hver konto med en rentebetaling på 10%.

Hvis begge transaktioner indsendes sammen, er der ingen garanti for, at transaktion 1 udføres før transaktion 2 eller omvendt. Uanset ordren skal resultatet være, som om transaktionerne finder sted serielt, den ene efter den anden.

Typer af transaktioner

Baseret på anvendelsesområder:

Ikke-distribueret vs. distribueret.
Kompenserende transaktioner.
Transaktionstidspunkt.
Online vs. batch.

Baseret på handlinger:

To-trins.
Begrænset.
Handlingsmodel.

Baseret på struktur:

Flade eller simple transaktioner: består af en sekvens af primitive operationer udført mellem en start- og slutoperation.
Indlejrede transaktioner: en transaktion, der indeholder andre transaktioner.
Workflow.

Hvad er et skema?

En tidsplan er en proces, hvor man opretter en enkelt gruppe af flere parallelle transaktioner og udfører dem en efter en. Den skal bevare den rækkefølge, som instruktionerne vises i i hver transaktion. Hvis to transaktioner udføres på samme tid, kan resultatet af den ene transaktion påvirke outputtet af den anden.

Eksempel

Initial Product Quantity is 10
Transaction 1: Update Product Quantity to 50
Transaction 2: Read Product Quantity

Hvis Transaktion 2 udføres før Transaktion 1, vil forældede oplysninger om produktmængden blive læst. Derfor er tidsplaner påkrævet.

Parallel udførelse i en database er uundgåelig. Men parallel udførelse er tilladt, når der er en ækvivalensrelation mellem de samtidigt udførende transaktioner. Denne ækvivalens er af tre typer.

Resultatækvivalens: Hvis to tidsplaner viser det samme resultat efter udførelse, kaldes det en resultatækvivalent tidsplan. De kan tilbyde det samme resultat for nogle værdier og forskellige resultater for et andet sæt værdier. For eksempel opdaterer én transaktion produktmængden, mens en anden opdaterer kundeoplysninger.

Vis ækvivalens: Visningsækvivalens opstår, når transaktionerne i begge tidsplaner udfører en lignende handling. For eksempel indsætter én transaktion produktoplysninger i produkttabellen, mens en anden transaktion indsætter produktoplysninger i arkivtabellen. Transaktionen er den samme, men tabellerne er forskellige.

Konfliktækvivalens: I dette tilfælde opdaterer eller viser to transaktioner det samme datasæt. Der er en konflikt mellem transaktionerne, da udførelsesrækkefølgen vil påvirke outputtet.

Hvad er serialiseringsevne?

Serialiserbarhed er processen med at søge efter en samtidig tidsplan, hvis output er lig med en seriel tidsplan, hvor transaktioner udføres efter hinanden. Afhængigt af typen af tidsplan er der to typer serialiserbarhed:

Konfliktserialiserbarhed.
Se serialiserbarhed.

De to adskiller sig i, hvor strengt de vurderer ækvivalens, som opsummeret nedenfor.

Aspect	Konfliktserialiserbarhed	Vis serialiserbarhed
Basis	Rækkefølgen af modstridende operationer	Læs-fra- og slut-skriv-relationer
Test	Præcedensgrafen skal være acyklisk	Vis ækvivalens til en seriel tidsplan
Strenghed	Strengere, en delmængde	Bredere, inkluderer blinde skrivninger
Pris for at tjekke	Effektiv	Beregningsmæssigt vanskelig

Enhver konfliktserialiserbar tidsplan er også visningsserialiserbar, men ikke omvendt, hvilket er grunden til, at konfliktserialiserbarhed er den praktiske test, et DBMS anvender.

Ofte Stillede Spørgsmål

Commit gør en transaktions ændringer permanente i databasen. Rollback fortryder alle ændringer siden transaktionen startede og vender tilbage til den konsistente tilstand, der eksisterede, før den startede.

Atomicity. Hvis der opstår et nedbrud midtvejs, sikrer atomicitet, at det delvise arbejde kasseres, så transaktionen behandles, som om den aldrig har kørt. Holdbarhed beskytter derefter committed-arbejde efter gendannelse.

AI analyserer lock waits og deadlock-grafer for at finde de transaktioner, der blokerer andre, og anbefaler derefter et isolationsniveau eller en indeksændring, der reducerer transaktionskonflikt uden at svække korrektheden.

Til en vis grad. Ved at lære de låse-anmodningsmønstre, der gik forud for tidligere fastlåste situationer, kan en model markere en risikabel transaktionsmix tidligt, hvilket lader planlæggeren forsinke eller omarrangere, før en cyklus dannes.

En seriel tidsplan kører én transaktion fuldt ud, før den næste starter, så ingen interleaving kan ødelægge data. Den er langsom, hvilket er grunden til, at målet er en samtidig tidsplan, der kan serialiseres til den.