DBMS samtidighetskontroll: tidsstempel og amp; Låsebaserte protokoller

Hva er samtidighetskontroll?

Concurrency Control in Database Management System er en prosedyre for å håndtere samtidige operasjoner uten å komme i konflikt med hverandre. Det sikrer at databasetransaksjoner utføres samtidig og nøyaktig for å gi riktige resultater uten å krenke dataintegriteten til den respektive databasen.

Samtidig tilgang er ganske enkelt hvis alle brukere bare leser data. Det er ingen måte de kan forstyrre hverandre. Skjønt for enhver praktisk database, ville 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 flerbruker-system. Concurrency Control er derfor det viktigste elementet for riktig funksjon av et databasestyringssystem der to eller flere databasetransaksjoner utføres samtidig, som krever tilgang til de samme dataene.

I denne veiledningen vil du lære

• Hva er samtidighetskontroll?
• Potensielle problemer med samtidighet
• Hvorfor bruke Concurrency-metoden?
• Protokoller for samtidighetskontroll
• Låsebaserte protokoller
• To-faselåsing (2PL) -protokoll
• Tidsstempelbaserte protokoller
• Valideringsbasert protokoll
• Kjennetegn på Good Concurrency Protocol

Potensielle problemer med samtidighet

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

• Tapte oppdateringer oppstår når flere transaksjoner velger den samme raden og oppdaterer raden basert på verdien som er valgt
• Uforpliktende avhengighetsproblemer oppstår når den andre transaksjonen velger en rad som oppdateres av en annen transaksjon ( skitten lesing )
• Ikke-repeterbar lesing skjer 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 tar sammendrag over verdien av alle forekomster av et gjentatt dataelement, og den andre transaksjonen oppdaterer få forekomster av det spesifikke dataelementet. I den situasjonen gjenspeiler ikke det resulterende sammendraget et riktig resultat.

Hvorfor bruke Concurrency-metoden?

Årsaker til å bruke Concurrency control method er DBMS:

• Å bruke isolasjon gjennom gjensidig utelukkelse mellom motstridende transaksjoner
• For å løse problemer med lese- og skrive-skrive-konflikter
• For å bevare databasekonsistens gjennom kontinuerlig å bevare hindringer for utførelse
• Systemet må kontrollere samspillet mellom samtidige transaksjoner. Denne kontrollen oppnås ved hjelp av samtidige kontrollskjemaer.
• Samtidighetskontroll hjelper til med å sikre serieiserbarhet

Eksempel

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

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

Protokoller for samtidighetskontroll

Ulike samtidighetskontrollprotokoller gir forskjellige fordeler mellom mengden samtidighet de tillater og mengden overhead som de pålegger. Følgende er Concurrency Control teknikker i DBMS:

• Låsebaserte protokoller
• To-faselåsingsprotokoll
• Tidsstempelbaserte protokoller
• Valideringsbaserte protokoller

Låsebaserte protokoller

Låsebaserte protokoller i DBMS er en mekanisme der en transaksjon ikke kan lese eller skrive dataene før den får en passende lås. Låsebaserte protokoller hjelper til med å eliminere samtidighetsproblemet i DBMS for samtidige transaksjoner ved å låse eller isolere en bestemt transaksjon til en enkelt bruker.

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 med å synkronisere tilgang til databaseelementene ved samtidig transaksjoner.

Alle låseforespørsler gjøres til lederen for samtidig kontroll. Transaksjoner fortsetter bare når låseforespørselen er gitt.

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

Delt / eksklusivt: Denne typen låsemekanisme skiller låsene i DBMS basert på deres bruk. Hvis en lås er anskaffet 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 transaksjonene. Dette er fordi du aldri vil ha tillatelse til å oppdatere data på dataelementet.

Tenk for eksempel på et tilfelle der to transaksjoner leser kontosaldoen til en person. Databasen lar dem lese ved å plassere en delt lås. Imidlertid, hvis en annen transaksjon vil oppdatere kontosaldoen, kan delt lås forhindre den før leseprosessen er over.

2. Eksklusiv lås (X):

Med den eksklusive låsen kan et dataelement både leses og skrives. Dette er eksklusivt og kan ikke holdes samtidig på samme dataelement. X-lock blir bedt ved hjelp av lock-x instruksjon. Transaksjoner kan låse opp dataelementet etter endt "skriv" -operasjon.

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 tillater transaksjoner å få en lås på hvert objekt før operasjonen påbegynnes. Transaksjoner kan låse opp dataelementet etter endt "skriv" -operasjon.

4. Pre-claiming Locking

Pre-claiming lock protocol hjelper deg med å evaluere operasjoner og lage en liste over nødvendige dataelementer som er nødvendige for å starte en kjøringsprosess. I situasjonen når alle låser er gitt, utføres transaksjonen. Etter det frigjøres alle låser når alle operasjoner er over.

Sult

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

Følgende er årsakene til sult:

• Når du venter ordningen for låste gjenstander blir ikke riktig administrert
• I tilfelle ressurslekkasje
• Den samme transaksjonen er valgt som et offer gjentatte ganger

Dødlås

Deadlock refererer til en bestemt 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.

To-faselåsingsprotokoll

To-faselåsingsprotokoll, også kjent som 2PL-protokoll, er en metode for samtidighetskontroll i DBMS som sikrer seriabilisering ved å bruke en lås til transaksjonsdataene som blokkerer andre transaksjoner for å få tilgang til de samme dataene samtidig. To-faselåsingsprotokoll hjelper til med å eliminere samtidighetsproblemet i DBMS.

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

• I den første fasen, når transaksjonen begynner å gjennomføres, krever den tillatelse for låsene den trenger.
• Den andre delen er der transaksjonen får alle låser. 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 frigjør den bare de anskaffede låser.

To-faselåsen protokollen tillater hver transaksjon å foreta en lås eller låse opp forespørsel i to trinn:

• Voksende fase : I denne fasen kan det hende at transaksjoner får låser, men ikke frigjør noen låser.
• Krympefase : I denne fasen kan en transaksjon frigjøre låser, men ikke få noen ny lås

Det er sant at 2PL-protokollen gir seriøsitet. Det sikrer imidlertid ikke at fastlåsning ikke skjer.

I det ovennevnte diagrammet kan du se at lokale og globale fastlåste detektorer søker etter lås og løser dem ved å gjenoppta transaksjoner til de opprinnelige tilstandene.

Streng tofaset låsemetode

Strict-Two-phase locking system er nesten lik 2PL. Den eneste forskjellen er at Strict-2PL aldri frigjør en lås etter bruk. Den holder alle låser til kommisjonspunktet og frigjør alle låser på en gang når prosessen er over.

Sentralisert 2PL

I Centralized 2 PL er et enkelt nettsted ansvarlig for låseadministrasjonsprosessen. Den har bare en låsesjef for hele DBMS.

Primærkopi 2PL

Primær kopi 2PL-mekanisme, mange låseadministratorer distribueres til forskjellige nettsteder. Etter det er en bestemt låsesjef ansvarlig for å administrere låsen for et sett med dataelementer. Når hovedkopien er oppdatert, overføres endringen til slavene.

Distribuert 2PL

I denne typen tofaset låsemekanisme distribueres Lock-ledere til alle nettsteder. De er ansvarlige for å administrere låser for data på dette nettstedet. Hvis ingen data blir replikert, tilsvarer det primærkopi 2PL. Kommunikasjonskostnadene for Distribuert 2PL er ganske høyere enn primærkopi 2PL

Tidsstempelbaserte protokoller

Tidsstempelbasert protokoll i DBMS er en algoritme som bruker Systemtid eller Logisk teller som et tidsstempel for å serieisere utførelsen av samtidige transaksjoner. Den tidsstemplebaserte protokollen sørger for at alle motstridende lese- og skriveoperasjoner utføres i en tidsstempelrekkefølge.

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

Låsebaserte protokoller hjelper deg med å administrere ordren mellom motstridende transaksjoner 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 0010T2 has entered the system at 0020T3 has entered the system at 0030Priority will be given to transaction T1, then transaction T2 and lastly Transaction T3.

Fordeler :

• Tidsplaner kan serienummeres akkurat som 2PL-protokoller
• Ingen ventetid på transaksjonen, noe som eliminerer muligheten for blokkeringer!

Ulemper:

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

Valideringsbasert protokoll

Valideringsbasert protokoll i DBMS, også kjent som Optimistic Concurrency Control Technique, er en metode for å unngå samtidighet i transaksjoner. I denne protokollen oppdateres de lokale kopiene av transaksjonsdataene i stedet for selve dataene, noe som resulterer i mindre forstyrrelser under gjennomføring av transaksjonen.

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 blir bare brukt på de lokale datakopiene, ikke den faktiske databasen.

Valideringsfase

I valideringsfasen blir dataene sjekket for å sikre at det ikke er noe brudd på serialiserbarhet mens transaksjonsoppdateringene brukes i databasen.

Skriv fase

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

Kjennetegn på Good Concurrency Protocol

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

• Må være motstandsdyktig mot nettsteds- og kommunikasjonsfeil.
• Det tillater parallell gjennomføring av transaksjoner for å oppnå maksimal samtidighet.
• Lagringsmekanismer og beregningsmetoder bør være beskjedne for å minimere overhead.
• Det må håndheve noen begrensninger på strukturen til atomhandlinger av transaksjoner.

Sammendrag

• Samtidighetskontroll er prosedyren i DBMS for å håndtere samtidige operasjoner uten å komme i konflikt med hverandre.
• Mistede oppdateringer, skitten lesing, ikke-repeterbar lesing og feil sammendragsproblemer er problemer som oppstår på grunn av manglende samtidighetskontroll.
• Låsebasert, tofaset, tidsstempelbasert og valideringsbasert er typer protokoller for samtidig håndtering
• 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 skaffe seg en lås etter at den har frigitt en av låsene. Den har to faser som vokser og krymper.
• Den tidsstemplebaserte algoritmen bruker en tidsstempel for å serieisere utførelsen av samtidige transaksjoner. Protokollen bruker systemtid eller logisk telling som en tidsstempel.