DBMS-samtidighetskontroll: Låse- og tidsstempelbaserte protokoller

Hva er samtidighetskontroll?

Samtidig kontroll I et databasehåndteringssystem er en prosedyre for å administrere samtidige operasjoner uten å komme i konflikt med hverandre. Det sikrer at databasetransaksjoner utføres samtidig og nøyaktig for å produsere korrekte resultater uten å krenke dataintegriteten til den respektive databasen.

Samtidig tilgang er ganske enkelt hvis alle brukerne bare leser data, da det ikke er noen måte de kan forstyrre hverandre på. Imidlertid har enhver praktisk database en blanding av READ- og WRITE-operasjoner, og dermed blir samtidighet en utfordring.

DBMS-samtidighetskontroll brukes til å håndtere slike konflikter, som vanligvis oppstår i et flerbrukersystem. Samtidighetskontroll er derfor et av de viktigste elementene for at en database skal fungere ordentlig der to eller flere transaksjoner utføres samtidig og krever tilgang til de samme dataene. Det fungerer hånd i hånd med transaksjonshåndtering, som definerer arbeidsenhetene som samtidighetskontroll må flettes sammen på en sikker måte.

Potensielle problemer med samtidighet

Her er noen problemer du sannsynligvis vil støte på uten skikkelig samtidighetskontroll i DBMS:

• Tapte oppdateringer oppstå når flere transaksjoner velger samme rad og oppdaterer den basert på den valgte verdien.
• Uforpliktet avhengighet (skitten lesing) oppstår når en andre transaksjon velger en rad som er oppdatert av en annen transaksjon som ennå ikke er fullført.
• Ikke-repeterbar lesing skjer når en annen transaksjon åpner samme rad flere ganger og leser forskjellige data hver gang.
• Feil sammendrag skjer når én transaksjon tar et sammendrag over verdien av alle forekomster av et gjentatt dataelement, mens en annen transaksjon oppdaterer noen av disse forekomstene. Det resulterende sammendraget gjenspeiler ikke et korrekt resultat.

Hvorfor bruke en samtidighetsmetode?

Grunner for å bruke en samtidighetskontrollmetode i DBMS:

• Å anvende isolasjon gjennom gjensidig utelukkelse mellom motstridende transaksjoner.
• For å løse problemer med lese-skrive- og skrive-skrive-konflikter.
• For å bevare databasekonsistens ved å kontinuerlig håndheve utførelsesbegrensninger.
• Å kontrollere samspillet mellom samtidige transaksjoner, oppnådd ved hjelp av samtidighetskontrollordninger.
• For å bidra til å sikre serialiserbarhet.

Eksempel

Anta at to personer går til elektroniske kiosker samtidig for å kjøpe kinobillett til samme film og samme visningstidspunkt.

Det er imidlertid bare ett sete igjen til den forestillingen i kinosalen. Uten samtidighetskontroll er det mulig at begge kinogjengerne ender opp med å kjøpe en billett. Samtidighetskontroll tillater ikke dette. Begge kinogjengerne kan fortsatt få tilgang til informasjonen i kinosetedatabasen, men samtidighetskontroll gir en billett bare til kjøperen som fullfører transaksjonsprosessen først.

Protokoller for samtidighetskontroll

Ulike protokoller for samtidighetskontroll tilbyr ulike avveininger mellom mengden samtidighet de tillater og overheaden de påfører. De viktigste teknikkene for samtidighetskontroll i DBMS er:

• Låsbaserte protokoller
• Tofase låseprotokoll
• Tidsstempelbaserte protokoller
• Valideringsbaserte protokoller

Hver av dem undersøkes etter tur nedenfor, og starter med de mest brukte, låsebaserte protokollene.

Låsbaserte protokoller

Låsebaserte protokoller I DBMS er det en mekanisme der en transaksjon ikke kan lese eller skrive et dataelement før den får en passende lås. Låsebaserte protokoller bidrar til å eliminere samtidighetsproblemet ved å låse eller isolere et bestemt dataelement til en enkelt transaksjon.

En lås er en datavariabel knyttet til et dataelement som angir hvilke operasjoner som kan utføres på det. Låser hjelper med å synkronisere tilgang til databaseelementer ved hjelp av samtidige transaksjoner. Alle låseforespørsler sendes til samtidighetskontrollbehandleren, og transaksjoner fortsetter bare når låseforespørselen er innvilget.

Binære låser: En binær lås på et dataelement kan være i enten låst eller ulåst tilstand.

Delt/eksklusivt: Denne låsemekanismen skiller låser basert på bruken de bruker. Hvis en lås anskaffes for å utføre en skriveoperasjon, kalles det en eksklusiv lås.

1. Delt lås (S): En delt lås kalles også en skrivebeskyttet lås. Med en delt lås kan dataelementet deles mellom transaksjoner, fordi ingen av dem har tillatelse til å oppdatere elementet. Hvis for eksempel to transaksjoner leser en persons kontosaldo, vil database lar dem lese ved å plassere en delt lås. Hvis en annen transaksjon ønsker å oppdatere den saldoen, forhindrer den delte låsen det inntil lesingen er over.

2. Eksklusiv lås (X): Med en eksklusiv lås kan et dataelement leses så vel som skrives. Det er eksklusivt og kan ikke holdes samtidig på det samme dataelementet. En X-lås forespørres ved hjelp av lock-x-instruksjonen. Når for eksempel en transaksjon må oppdatere en kontosaldo, tillates det ved å plassere en X-lås; en andre transaksjon som ønsker å lese eller skrive blir da forhindret.

3. Forenklet låseprotokoll: Dette gjør at transaksjoner kan låse hvert objekt før en operasjon starter. Transaksjoner kan låse opp dataelementet etter at skriveoperasjonen er fullført.

4. Låsing før krav: Denne protokollen evaluerer operasjoner og lager en liste over dataelementene som trengs for å starte utførelsen. Når alle låser er gitt, utføres transaksjonen, og alle låser frigjøres når operasjonene er over.

Sult: Sult er situasjonen når en transaksjon venter i en ubestemt periode på å bli låst. Årsaker inkluderer en dårlig administrert venteordning for låste elementer, en ressurslekkasje eller at den samme transaksjonen gjentatte ganger blir valgt som offer.

Vranglås: En vranglås refererer til en situasjon der to eller flere prosesser venter på at hverandre skal frigjøre en ressurs, og danner en sirkulær kjede.

Tofaselåseprotokoll (2PL)

Ocuco Tofase låseprotokoll, også kjent som 2PL, er en metode for samtidighetskontroll som sikrer serialiserbarhet ved å bruke en lås på transaksjonsdata, som blokkerer andre transaksjoner fra å få tilgang til de samme dataene samtidig.

Tofaselåseprotokollen lar hver transaksjon foreta en låse- eller opplåsingsforespørsel i to trinn:

• Vekstfase: I denne fasen kan en transaksjon få låser, men ikke oppheve noen låser.
• Krympefase: I denne fasen kan en transaksjon frigjøre låser, men den kan ikke få noen ny lås.

Det er sant at 2PL tilbyr serialiserbarhet. Det garanterer imidlertid ikke at det ikke oppstår vranglåser. I diagrammet ovenfor søker lokale og globale vranglåsdetektorer etter vranglåser og løser dem ved å gjenoppta transaksjoner til deres opprinnelige tilstander.

Streng to-fase låsemetode

Strict 2PL er nesten det samme som 2PL. Den eneste forskjellen er at Strict-2PL aldri frigir en lås etter bruk. Den holder alle låser frem til commit-punktet og frigir dem alle samtidig når prosessen er over.

Sentralisert 2PL

I sentralisert 2PL er ett enkelt sted ansvarlig for låshåndteringsprosessen. Det har bare én låseadministrator for hele DBMS-systemet.

Primærkopi 2PL

I Primary Copy 2PL-mekanismen er mange låseadministratorer distribuert til forskjellige steder, og en bestemt låseadministrator er ansvarlig for å administrere låsen for et sett med dataelementer. Når primærkopien oppdateres, overføres endringen til slavene.

Distribuert 2PL

I denne mekanismen er låseadministratorer distribuert til alle steder og er ansvarlige for å administrere låser for data på det stedet. Hvis ingen data replikeres, tilsvarer det Primary Copy 2PL. Kommunikasjonskostnadene for Distributed 2PL er ganske mye høyere enn for Primary Copy 2PL.

Tidsstempelbaserte protokoller

Ocuco Tidsstempelbasert protokoll I DBMS er en algoritme som bruker systemtiden eller en logisk teller som et tidsstempel for å serialisere utførelsen av samtidige transaksjoner. Den sikrer at alle motstridende lese- og skriveoperasjoner utføres i tidsstempelrekkefølge.

Den eldre transaksjonen prioriteres alltid i denne metoden. Den bruker systemtid til å bestemme tidsstempelet for transaksjonen, og det er den mest brukte samtidighetsprotokollen. Låsebaserte protokoller administrerer rekkefølgen mellom motstridende transaksjoner når de utføres; tidsstempelbaserte protokoller håndterer konflikter så snart en operasjon opprettes.

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.

Fordeler:

• Tidsplaner er serialiserbare, akkurat som 2PL-protokoller.
• Ingen venting på transaksjonen, noe som eliminerer muligheten for fastlåste situasjoner.

Ulemper: Sult er mulig hvis den samme transaksjonen startes på nytt og kontinuerlig avbrytes.

Valideringsbasert protokoll

Ocuco Valideringsbasert protokoll I DBMS, også kjent som den optimistiske samtidighetskontrollteknikken, er en metode for å unngå samtidighetskonflikter i transaksjoner. I denne protokollen oppdateres lokale kopier av transaksjonsdataene i stedet for selve dataene, noe som resulterer i mindre interferens under utførelse.

Den valideringsbaserte protokollen utføres i tre faser:

1. Les fase
2. Valideringsfase
3. Skriv fase

Les fase

I lesefasen kan dataverdier leses av en transaksjon, men skriveoperasjoner eller oppdateringer brukes bare på de lokale datakopiene, ikke den faktiske databasen.

Valideringsfase

I valideringsfasen kontrolleres dataene for å sikre at oppdateringene ikke krenker serialiserbarheten.

Skriv fase

I skrivefasen blir oppdateringene brukt i databasen hvis valideringen er vellykket; ellers blir oppdateringene forkastet og transaksjonen rulles tilbake.

Sammenligning av protokoller for samtidighetskontroll

De fire protokollfamiliene satser på ulike måter hvor ofte transaksjoner faktisk kommer i konflikt. Tabellen nedenfor oppsummerer hvor hver enkelt passer inn.

Kort sagt antar låsebaserte og 2PL-protokoller at konflikt er vanlig og forhindrer den på forhånd, mens tidsstempel- og valideringsprotokoller antar at konflikt er sjelden og løser den bare når den oppstår.

Kjennetegn ved en god samtidighetsprotokoll

En ideell mekanisme for samtidighetskontroll har følgende mål:

• Den må være motstandsdyktig mot feil på stedet og kommunikasjonsfeil.
• Den tillater parallell utførelse av transaksjoner for å oppnå maksimal samtidighet.
• Lagringsmekanismene og beregningsmetodene bør være beskjedne for å minimere overhead.
• Det må håndheve noen begrensninger på strukturen til de atomære handlingene i transaksjoner.

Spørsmål og svar