DBMS Samtidighedskontrol: Låsnings- og tidsstempelbaserede protokoller
⚡ Smart opsummering
Samtidighedskontrol i DBMS administrerer samtidige transaktioner, så de kører præcist uden at krænke dataintegriteten. Det forhindrer anomalier såsom mistede opdateringer og uhensigtsmæssige læsninger ved hjælp af låsebaserede, tofasede, tidsstempelbaserede og valideringsbaserede protokoller, der garanterer serialiserbare resultater.

Hvad er samtidighedskontrol?
Samtidighedskontrol I et databasestyringssystem er en procedure til at styre samtidige operationer uden at være i konflikt med hinanden. Det sikrer, at databasetransaktioner udføres samtidigt og præcist for at producere korrekte resultater uden at krænke dataintegriteten i den respektive database.
Samtidig adgang er ret nemt, hvis alle brugere kun læser data, da der ikke er nogen måde, de kan forstyrre hinanden på. Imidlertid har enhver praktisk database en blanding af LÆSNINGS- og SKRIVNINGSoperationer, og derfor bliver samtidighed en udfordring.
DBMS-samtidighedskontrol bruges til at håndtere sådanne konflikter, som oftest opstår i et flerbrugersystem. Samtidighedskontrol er derfor et af de vigtigste elementer for en korrekt funktion af en database, hvor to eller flere transaktioner udføres samtidigt og kræver adgang til de samme data. Det fungerer hånd i hånd med transaktionsstyring, som definerer de arbejdsenheder, som samtidighedskontrol skal interleave sikkert.
Potentielle problemer med samtidighed
Her er nogle problemer, du sandsynligvis vil støde på uden korrekt DBMS-samtidighedskontrol:
- Mistede opdateringer opstå, når flere transaktioner vælger den samme række og opdaterer den baseret på den valgte værdi.
- Uforpligtet afhængighed (dirty read) opstår, når en anden transaktion vælger en række, der er blevet opdateret af en anden transaktion, der endnu ikke er blevet committet.
- Ikke-gentagelig læsning opstår, når en anden transaktion tilgår den samme række flere gange og læser forskellige data hver gang.
- Forkert opsummering forekommer, når én transaktion opsummerer værdien af alle forekomster af et gentaget dataelement, mens en anden transaktion opdaterer et par af disse forekomster. Det resulterende opsummering afspejler ikke et korrekt resultat.
Hvorfor bruge en samtidighedsmetode?
Årsager til at bruge en samtidighedskontrolmetode i DBMS:
- At anvende isolation gennem gensidig udelukkelse mellem modstridende transaktioner.
- For at løse problemer med læse-skrive- og skrive-skrive-konflikter.
- At bevare databasekonsistens ved konstant at håndhæve udførelsesbegrænsninger.
- At kontrollere interaktionen mellem samtidige transaktioner, opnået ved hjælp af samtidighedskontrolordninger.
- For at sikre serialiserbarhed.
Eksempel
Antag, at to personer går til elektroniske kiosker på samme tid for at købe en biografbillet til den samme film og samme visningstidspunkt.
Der er dog kun én plads tilbage til den forestilling i teatret. Uden samtidighedskontrol er det muligt, at begge biografgængere ender med at købe en billet. Samtidighedskontrol tillader ikke dette. Begge biografgængere kan stadig få adgang til oplysningerne i biografens sædedatabase, men samtidighedskontrol giver kun en billet til den køber, der gennemfører transaktionsprocessen først.
Protokoller til samtidighedskontrol
Forskellige protokoller til samtidighedskontrol tilbyder forskellige afvejninger mellem den mængde samtidighed, de tillader, og den overhead, de pålægger. De vigtigste teknikker til samtidighedskontrol i DBMS er:
- Låsebaserede protokoller
- Tofaset låseprotokol
- Tidsstempelbaserede protokoller
- Valideringsbaserede protokoller
Hver af dem undersøges efter tur nedenfor, startende med de mest anvendte, låsebaserede protokoller.
Låsebaserede protokoller
Låsebaserede protokoller I DBMS er der en mekanisme, hvor en transaktion ikke kan læse eller skrive et dataelement, før den får en passende lås. Låsebaserede protokoller hjælper med at eliminere samtidighedsproblemet ved at låse eller isolere et bestemt dataelement til en enkelt transaktion.
En lås er en datavariabel, der er knyttet til et dataelement, og som angiver, hvilke handlinger der kan udføres på det. Låse hjælper med at synkronisere adgang til databaseelementer via samtidige transaktioner. Alle låseanmodninger sendes til samtidighedskontrolstyringen, og transaktioner fortsætter først, når låseanmodningen er godkendt.
Binære låse: En binær lås på et dataelement kan være i enten en låst eller en ulåst tilstand.
Delt/Eksklusivt: Denne låsemekanisme adskiller låse baseret på deres anvendelse. Hvis en lås erhverves til at udføre en skriveoperation, kaldes det en eksklusiv lås.
1. Delt lås (S): En delt lås kaldes også en skrivebeskyttet lås. Med en delt lås kan dataelementet deles mellem transaktioner, fordi ingen af dem har tilladelse til at opdatere elementet. Hvis for eksempel to transaktioner læser en persons kontosaldo, vil database lader dem læse ved at placere en delt lås. Hvis en anden transaktion ønsker at opdatere den saldo, forhindrer den delte lås det, indtil aflæsningen er færdig.
2. Eksklusiv lås (X): Med en eksklusiv lås kan et dataelement både læses og skrives. Det er eksklusivt og kan ikke holdes samtidigt på det samme dataelement. En X-lås anmodes ved hjælp af lock-x-instruktionen. For eksempel, når en transaktion skal opdatere en kontosaldo, tillades det ved at placere en X-lås; en anden transaktion, der ønsker at læse eller skrive, forhindres derefter.
3. Forenklet låseprotokol: Dette gør det muligt for transaktioner at opnå en lås på hvert objekt, før en operation påbegyndes. Transaktioner kan låse dataelementet op efter at skriveoperationen er afsluttet.
4. Låsning før krav: Denne protokol evaluerer operationer og opretter en liste over de dataelementer, der er nødvendige for at starte udførelsen. Når alle låse er givet, udføres transaktionen, og alle låse frigives, når operationerne er afsluttet.
Sult: Sult er den situation, hvor en transaktion venter i en ubestemt periode på at blive låst. Årsagerne kan være en dårligt administreret venteordning for låste elementer, en ressourcelækage eller at den samme transaktion gentagne gange vælges som offer.
Dødlåsning: En deadlock refererer til en situation, hvor to eller flere processer venter på, at hinanden frigiver en ressource og danner en cirkulær kæde.
Tofaset låseprotokol (2PL)
Tofaset låseprotokol, også kendt som 2PL, er en metode til samtidighedskontrol, der sikrer serialiserbarhed ved at anvende en lås på transaktionsdata, som blokerer andre transaktioner fra at få adgang til de samme data samtidigt.
Tofaselåseprotokollen tillader hver transaktion at foretage en låsnings- eller oplåsningsanmodning i to trin:
- Vækstfase: I denne fase kan en transaktion opnå låse, men muligvis ikke frigive nogen låse.
- Krympningsfase: I denne fase kan en transaktion frigive låse, men muligvis ikke modtage nogen ny lås.
Det er sandt, at 2PL tilbyder serialiserbarhed. Det sikrer dog ikke, at der ikke opstår deadlocks. I diagrammet ovenfor søger lokale og globale deadlock-detektorer efter deadlocks og løser dem ved at genoptage transaktioner til deres oprindelige tilstande.
Streng to-faset låsemetode
Strict 2PL er næsten det samme som 2PL. Den eneste forskel er, at Strict-2PL aldrig frigiver en lås efter brug. Den holder alle låse indtil commit-punktet og frigiver dem alle på én gang, når processen er slut.
Centraliseret 2PL
I centraliseret 2PL er et enkelt sted ansvarligt for låsestyringsprocessen. Det har kun én låseadministrator for hele DBMS'et.
Primær kopi 2PL
I Primary Copy 2PL-mekanismen er mange låseadministratorer distribueret til forskellige lokationer, og en bestemt låseadministrator er ansvarlig for at administrere låsen for et sæt dataelementer. Når den primære kopi opdateres, overføres ændringen til slaverne.
Distribueret 2PL
I denne mekanisme er låseadministratorer distribueret til alle lokationer og er ansvarlige for at administrere låse for data på det pågældende sted. Hvis der ikke replikeres data, svarer det til Primary Copy 2PL. Kommunikationsomkostningerne ved Distributed 2PL er en del højere end ved Primary Copy 2PL.
Tidsstempelbaserede protokoller
Tidsstempelbaseret protokol I DBMS er en algoritme, der bruger systemtiden eller en logisk tæller som et tidsstempel til at serialisere udførelsen af samtidige transaktioner. Det sikrer, at alle modstridende læse- og skriveoperationer udføres i tidsstempelrækkefølge.
Den ældre transaktion prioriteres altid i denne metode. Den bruger systemtid til at bestemme transaktionens tidsstempel, og det er den mest almindeligt anvendte samtidighedsprotokol. Låsebaserede protokoller styrer rækkefølgen mellem modstridende transaktioner, når de udføres; tidsstempelbaserede protokoller styrer konflikter, så snart en operation oprettes.
Eksempel:
Suppose there are three transactions T1, T2, and T3. T1 has entered the system at time 0010 T2 has entered the system at 0020 T3 has entered the system at 0030 Priority will be given to transaction T1, then T2 and lastly T3.
fordele:
- Tidsplaner kan serialiseres, ligesom 2PL-protokoller.
- Ingen ventetid på transaktionen, hvilket eliminerer muligheden for fastlåste transaktioner.
Ulemper: Sult er mulig, hvis den samme transaktion genstartes og kontinuerligt afbrydes.
Valideringsbaseret protokol
Valideringsbaseret protokol I DBMS, også kendt som den optimistiske samtidighedskontrolteknik, er en metode til at undgå samtidighedskonflikter i transaktioner. I denne protokol opdateres lokale kopier af transaktionsdataene i stedet for selve dataene, hvilket resulterer i mindre interferens under udførelsen.
Den valideringsbaserede protokol udføres i tre faser:
- Læs fase
- Valideringsfase
- Skriv fase
Læs fase
I læsefasen kan dataværdier læses af en transaktion, men skriveoperationer eller opdateringer anvendes kun på de lokale datakopier, ikke på selve databasen.
Valideringsfase
I valideringsfasen kontrolleres dataene for at sikre, at anvendelsen af opdateringerne ikke vil krænke serialiserbarheden.
Skriv fase
I skrivefasen anvendes opdateringerne på databasen, hvis valideringen lykkes; ellers kasseres opdateringerne, og transaktionen rulles tilbage.
Sammenligning af samtidighedskontrolprotokoller
De fire protokolfamilier satser på, hvor ofte transaktioner rent faktisk er i konflikt. Tabellen nedenfor opsummerer, hvor hver enkelt passer ind.
| protokol | Tilgang | deadlock | Bedste når |
|---|---|---|---|
| Låsebaseret | Pessimistisk, låser før adgang | Mulig | Konflikter er hyppige |
| Tofaset låsning | Pessimistiske, voksende og krympende faser | Mulig | Serialiserbarhed er påkrævet |
| Tidsstempelbaseret | Ordrer efter tidsstempel | Uden fastlåsning | Bestilling er vigtig, ventetid er dyrt |
| Valideringsbaseret | Optimistisk, valider før skrivning | Uden fastlåsning | Konflikter er sjældne |
Kort sagt antager låsebaserede og 2PL-protokoller, at konflikt er almindelig og forhindrer den på forhånd, mens tidsstempel- og valideringsprotokoller antager, at konflikt er sjælden og kun løser den, når den opstår.
Karakteristika for en god samtidighedsprotokol
En ideel mekanisme til samtidighedskontrol har følgende mål:
- Den skal være modstandsdygtig over for fejl på stedet og kommunikationen.
- Det tillader parallel udførelse af transaktioner for at opnå maksimal samtidighed.
- Dens lagringsmekanismer og beregningsmetoder bør være beskedne for at minimere overhead.
- Det skal håndhæve nogle begrænsninger på strukturen af transaktioners atomare handlinger.

