DBMS samtidighetskontroll: tidsstempel og låsebaserte protokoller

Samtidig tilgang er ganske enkelt hvis alle brukere bare leser data. Det er ingen måte de kan forstyrre hverandre. Selv om for enhver praktisk database vil den ha en blanding av LES- og SKRIV-operasjoner, og dermed er samtidigheten en utfordring.

DBMS Concurrency Control brukes til å løse slike konflikter, som for det meste oppstår med et flerbrukersystem. Derfor er samtidighetskontroll det viktigste elementet for riktig funksjon av et databasestyringssystem der to eller flere databasetransaksjoner utføres samtidig, som krever tilgang til de samme dataene.

Potensielle problemer med samtidighet

Her er noen problemer du sannsynligvis vil møte når du bruker DBMS Concurrency Control-metoden:

• Tapte oppdateringer oppstår når flere transaksjoner velger samme rad og oppdaterer raden basert på den valgte verdien
• Uforpliktede avhengighetsproblemer oppstår når den andre transaksjonen velger en rad som oppdateres av en annen transaksjon (skitten lese)
• Ikke-repeterbar lesing oppstår når en andre transaksjon prøver å få tilgang til samme rad flere ganger og leser forskjellige data hver gang.
• Feil oppsummeringsproblem oppstår når en transaksjon overtar verdien av alle forekomstene av et gjentatt dataelement, og den andre transaksjonen oppdaterer noen få forekomster av den spesifikke dataelementet. I den situasjonen gjenspeiler ikke det resulterende sammendraget et korrekt resultat.

Hvorfor bruke samtidighetsmetoden?

Årsaker til å bruke samtidighetskontrollmetoden er DBMS:

• Å bruke isolasjon gjennom gjensidig utestenging mellom motstridende transaksjoner
• For å løse lese-skrive og skrive-skrive konfliktproblemer
• For å bevare databasekonsistens gjennom konstant å bevare utførelseshindringer
• Systemet må kontrollere interaksjonen mellom de samtidige transaksjonene. Denne kontrollen oppnås ved bruk av samtidige kontrollskjemaer.
• Samtidig kontroll bidrar til å sikre serialiserbarhet

Eksempel

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

Imidlertid er det bare ett sete igjen for filmshowet i det aktuelle teatret. Uten samtidighetskontroll i DBMS er det mulig at begge kinogjengerne ender opp med å kjøpe billett. Imidlertid tillater ikke samtidighetskontrollmetoden at dette skjer. Begge kinogjengere kan fortsatt få tilgang til informasjon skrevet i databasen for filmseter. Men samtidighetskontroll gir kun en billett til kjøperen som har fullført transaksjonsprosessen først.

Protokoller for samtidighetskontroll

Ulike samtidighetskontrollprotokoller gir forskjellige fordeler mellom mengden samtidighet de tillater og mengden overhead de pålegger. Følgende er teknikkene for samtidighetskontroll i DBMS:

• Låsbaserte protokoller
• To-fase låseprotokoll
• Tidsstempelbaserte protokoller
• Valideringsbaserte protokoller

En lås er en datavariabel som er knyttet til et dataelement. Denne låsen betyr at operasjoner som kan utføres på dataelementet. Låser i DBMS hjelper til med å synkronisere tilgang til databaseelementene ved samtidige transaksjoner.

Alle låseforespørsler sendes til samtidighetskontrollansvarlig. Transaksjoner fortsetter først når låseforespørselen er innvilget.

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

Delt/eksklusivt: Denne typen låsemekanismer skiller låsene i DBMS basert på deres bruk. Hvis en lås er innhentet på et dataelement 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 den delte låsen kan dataelementet deles mellom transaksjoner. Dette er fordi du aldri vil ha tillatelse til å oppdatere data på dataelementet.

Vurder for eksempel et tilfelle der to transaksjoner leser kontosaldoen til en person. De database lar dem lese ved å plassere en delt lås. Men hvis en annen transaksjon ønsker å oppdatere den kontoens saldo, vil delt lås forhindre det til leseprosessen er over.

2. Eksklusiv lås (X):

Med den eksklusive låsen kan et dataelement leses og skrives. Dette er eksklusivt og kan ikke holdes samtidig på samme dataelement. X-lås etterspørres ved hjelp av lås-x instruksjon. Transaksjoner kan låse opp dataelementet etter at "skrive"-operasjonen er fullført.

For eksempel når en transaksjon trenger å oppdatere kontosaldoen til en person. Du kan tillate denne transaksjonen ved å plassere X-lås på den. Derfor, når den andre transaksjonen ønsker å lese eller skrive, forhindrer eksklusiv lås denne operasjonen.

3. Simplistic Lock Protocol

Denne typen låsebaserte protokoller lar transaksjoner oppnå en lås på hvert objekt før operasjonen startes. Transaksjoner kan låse opp dataelementet etter at "skrive"-operasjonen er fullført.

4. Forhåndskrav Låsing

Forhåndskrevende låseprotokoll hjelper til med å evaluere operasjoner og lage en liste over nødvendige dataelementer som er nødvendige for å starte en utførelsesprosess. I situasjonen når alle låser er gitt, utføres transaksjonen. Etter det frigjøres alle låsene når alle operasjonene er over.

Sult

Sult er situasjonen når en transaksjon må vente på ubestemt tid for å få en lås.

Følgende er årsakene til sult:

• Ved venteordning for låste gjenstander er ikke riktig administrert
• Ved ressurslekkasje
• Den samme transaksjonen velges som et offer gjentatte ganger

vranglås

Deadlock refererer til en spesifikk situasjon der to eller flere prosesser venter på at hverandre skal frigjøre en ressurs eller mer enn to prosesser venter på ressursen i en sirkulær kjede.

Denne låseprotokollen deler utførelsesfasen av en transaksjon i tre forskjellige deler.

• I den første fasen, når transaksjonen begynner å utføre, krever den tillatelse for låsene den trenger.
• Den andre delen er der transaksjonen får alle låsene. Når en transaksjon frigjør sin første lås, starter den tredje fasen.
• I denne tredje fasen kan ikke transaksjonen kreve nye låser. I stedet slipper den bare de ervervede låsene.

To-fase låseprotokollen lar hver transaksjon foreta en låse- eller opplåsningsforespørsel i to trinn:

• Vekstfase: I denne fasen kan transaksjonen få låser, men kan ikke frigjøre noen låser.
• Krympende fase: I denne fasen kan en transaksjon frigjøre låser, men ikke få noen ny lås

Det er sant at 2PL-protokollen tilbyr serialiserbarhet. Det sikrer imidlertid ikke at vranglås ikke oppstår.

I diagrammet ovenfor kan du se at lokale og globale vranglåsdetektorer søker etter vranglåser og løser dem ved å gjenoppta transaksjoner til de opprinnelige tilstandene.

Streng to-fase låsemetode

Strict-To-fase låsesystem er nesten likt 2PL. Den eneste forskjellen er at Strict-2PL aldri frigjør en lås etter bruk. Den holder alle låsene til commit-punktet og frigjør alle låsene på en gang når prosessen er over.

Sentralisert 2PL

I sentralisert 2 PL er et enkelt nettsted ansvarlig for låseadministrasjonsprosessen. Den har bare én låsbehandler for hele DBMS.

Primærkopi 2PL

Primær kopi 2PL-mekanisme, mange låseadministratorer er distribuert til forskjellige nettsteder. Etter det er en bestemt låseansvarlig ansvarlig for å administrere låsen for et sett med dataelementer. Når primærkopien er oppdatert, forplantes endringen til slavene.

Distribuert 2PL

I denne typen to-fase låsemekanisme er låseadministratorer distribuert til alle nettsteder. De er ansvarlige for å administrere låser for data på dette nettstedet. Hvis ingen data er replikert, tilsvarer det primær kopi 2PL. Kommunikasjonskostnadene for distribuert 2PL er ganske høyere enn primærkopi 2PL

Den eldre transaksjonen blir alltid prioritert i denne metoden. Den bruker systemtid til å bestemme tidsstemplet for transaksjonen. Dette er den mest brukte samtidighetsprotokollen.

Låsbaserte protokoller hjelper deg med å administrere rekkefølgen mellom de motstridende transaksjonene når de skal utføres. Tidsstempelbaserte protokoller håndterer konflikter så snart en operasjon er opprettet.

Eksempel:

Suppose there are there 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 transaction T2 and lastly Transaction T3.

Fordeler:

• Tidsplaner kan serialiseres akkurat som 2PL-protokoller
• Ingen venting på transaksjonen, noe som eliminerer muligheten for vranglås!

Ulemper:

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

Den valideringsbaserte protokollen utføres i følgende tre faser:

1. Les fase
2. Valideringsfase
3. Skriv fase

Les fase

I lesefasen kan dataverdiene fra databasen leses av en transaksjon, men skriveoperasjonen eller oppdateringene brukes bare på de lokale datakopiene, ikke den faktiske databasen.

Valideringsfase

I valideringsfasen blir dataene sjekket for å sikre at det ikke er noen brudd på serialiserbarheten mens transaksjonsoppdateringene påføres databasen.

Skriv fase

I skrivefasen blir oppdateringene brukt på databasen hvis valideringen er vellykket, ellers; oppdateringene blir ikke tatt i bruk, og transaksjonen rulles tilbake.

Kjennetegn på Good Concurrency Protocol

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

• Må være motstandsdyktig mot anleggs- 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 atomære handlinger av transaksjoner.

Sammendrag

• Samtidig kontroll er prosedyren i DBMS for å håndtere samtidige operasjoner uten å komme i konflikt med hverandre.
• Tapte oppdateringer, skitten lesing, ikke-repeterbar lesing og feil oppsummeringsproblem er problemer som står overfor på grunn av manglende samtidighetskontroll.
• Låsebasert, tofaset, tidsstempelbasert, valideringsbasert er typer samtidighetshåndteringsprotokoller
• Låsen kan være delt (S) eller eksklusiv (X)
• To-fase låseprotokoll, som også er kjent som en 2PL-protokoll trenger transaksjon, bør anskaffe en lås etter at den frigjør en av låsene. Den har 2 faser som vokser og krymper.
• Den tidsstempelbaserte algoritmen bruker et tidsstempel for å serialisere utførelsen av samtidige transaksjoner. Protokollen bruker Systemtid eller logisk telle som et tidsstempel.