Hvad er samtidighedskontrol?
Concurrency Control i Database Management System er en procedure til styring af samtidige operationer uden at komme i konflikt med hinanden. Det sikrer, at databasetransaktioner udføres samtidigt og nøjagtigt for at producere korrekte resultater uden at krænke dataintegriteten i den respektive database.
Samtidig adgang er ret let, hvis alle brugere bare læser data. Der er ingen måde, de kan forstyrre hinanden på. Skønt for enhver praktisk database, ville den have en blanding af LÆS og SKRIFT-operationer, og dermed er samtidigheden en udfordring.
DBMS Concurrency Control bruges til at løse sådanne konflikter, som for det meste opstår med et flerbruger-system. Derfor er samtidighedskontrol det vigtigste element for korrekt funktion af et databasestyringssystem, hvor to eller flere databasetransaktioner udføres samtidigt, som kræver adgang til de samme data.
I denne vejledning lærer du
- Hvad er samtidighedskontrol?
- Potentielle problemer med samtidighed
- Hvorfor bruge Concurrency-metoden?
- Protokoller for samtidighedskontrol
- Låsebaserede protokoller
- To-faselåsning (2PL) -protokol
- Tidsstempelbaserede protokoller
- Valideringsbaseret protokol
- Karakteristika for god concurrency-protokol
Potentielle problemer med samtidighed
Her er nogle problemer, som du sandsynligvis vil stå over for, når du bruger metoden DBMS Concurrency Control:
- Mistede opdateringer opstår, når flere transaktioner vælger den samme række og opdaterer rækken baseret på den valgte værdi
- Uforpligtede afhængighedsproblemer opstår, når den anden transaktion vælger en række, der opdateres af en anden transaktion ( beskidt læsning )
- Ikke-gentagelig læsning opstår, når en anden transaktion forsøger at få adgang til den samme række flere gange og læser forskellige data hver gang.
- Forkert opsummeringsproblem opstår, når en transaktion overtager værdien af alle forekomsterne af et gentaget dataelement, og den anden transaktion opdaterer få forekomster af det specifikke dataelement. I denne situation afspejler det resulterende resume ikke et korrekt resultat.
Hvorfor bruge Concurrency-metoden?
Årsager til brug af Concurrency control-metoden er DBMS:
- At anvende isolation gennem gensidig udelukkelse mellem modstridende transaktioner
- For at løse problemer med at læse og skrive og skrive og skrive
- At bevare databasekonsistens gennem konstant bevarelse af eksekveringshindringer
- Systemet skal kontrollere interaktionen mellem de samtidige transaktioner. Denne kontrol opnås ved hjælp af samtidige kontrolordninger.
- Samtidig kontrol hjælper med at sikre serieiserbarhed
Eksempel
Antag, at to personer, der går til elektroniske kiosker på samme tid for at købe en filmbillet til den samme film og samme showtid.
Der er dog kun et sæde tilbage til filmshowet i det pågældende teater. Uden samtidighedskontrol i DBMS er det muligt, at begge filmgæster ender med at købe en billet. Samtidig kontrolmetode tillader imidlertid ikke dette at ske. Begge filmgæster kan stadig få adgang til oplysninger, der er skrevet i databasen over filmoverførsler. Men samtidighedskontrol giver kun en billet til den køber, der først har gennemført transaktionsprocessen.
Protokoller for samtidighedskontrol
Forskellige samtidighedskontrolprotokoller giver forskellige fordele mellem mængden af samtidighed, de tillader, og mængden af faste omkostninger, de pålægger. Følgende er Concurrency Control teknikker i DBMS:
- Låsebaserede protokoller
- To-faselåseprotokol
- Tidsstempelbaserede protokoller
- Valideringsbaserede protokoller
Låsebaserede protokoller
Låsebaserede protokoller i DBMS er en mekanisme, hvor en transaktion ikke kan læse eller skrive dataene, før den får en passende lås. Låsebaserede protokoller hjælper med at eliminere samtidighedsproblemet i DBMS til samtidige transaktioner ved at låse eller isolere en bestemt transaktion til en enkelt bruger.
En lås er en datavariabel, der er knyttet til et dataelement. Denne lås betyder, at handlinger, der kan udføres på dataelementet. Låse i DBMS hjælper med at synkronisere adgangen til databaseelementerne ved hjælp af samtidige transaktioner.
Alle låseanmodninger fremsættes til manager for samtidig kontrol. Transaktioner fortsætter kun når låseanmodningen er imødekommet.
Binære låse: En binær lås på et dataelement kan enten være låst eller ulåst.
Delt / eksklusiv: Denne type låsemekanisme adskiller låsene i DBMS baseret på deres anvendelser. Hvis der erhverves en lås på et dataelement for 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 den delte lås kan dataelementet deles mellem transaktionerne. Dette skyldes, at du aldrig har tilladelse til at opdatere data om dataelementet.
Overvej f.eks. Et tilfælde, hvor to transaktioner aflæser en persons kontosaldo. Databasen lader dem læse ved at placere en delt lås. Men hvis en anden transaktion vil opdatere kontosaldo, forhindrer delt lås det, indtil læsningsprocessen er afsluttet.
2. Eksklusiv lås (X):
Med den eksklusive lås kan et dataelement både læses og skrives. Dette er eksklusivt og kan ikke opbevares samtidigt på det samme dataelement. X-lock anmodes om ved hjælp af lock-x instruktion. Transaktioner kan muligvis låse dataelementet op efter afslutning af 'skriv'-operationen.
For eksempel når en transaktion skal opdatere en persons kontosaldo. Du kan tillade denne transaktion ved at placere X-lås på den. Derfor, når den anden transaktion ønsker at læse eller skrive, forhindrer eksklusiv lås denne handling.
3. Forenklet låseprotokol
Denne type låsebaserede protokoller gør det muligt for transaktioner at få en lås på hvert objekt inden operationen påbegyndes. Transaktioner kan muligvis låse dataelementet op efter afslutning af 'skriv'-operationen.
4. Forudgående krav om låsning
Forudgående kravlåseprotokol hjælper med at evaluere operationer og oprette en liste over krævede dataelementer, der er nødvendige for at starte en eksekveringsproces. I den situation, hvor alle låse er tildelt, udføres transaktionen. Derefter frigøres alle låse, når alle dens operationer er slut.
Sult
Sult er situationen, hvor en transaktion skal vente på ubestemt tid for at erhverve en lås.
Følgende er årsagerne til sult:
- Når der venter ordning for låste genstande styres ikke korrekt
- I tilfælde af ressourceudslip
- Den samme transaktion vælges gentagne gange som et offer
Dødlås
Deadlock henviser til en specifik situation, hvor to eller flere processer venter på hinanden for at frigive en ressource, eller mere end to processer venter på ressourcen i en cirkulær kæde.
To-faselåseprotokol
To-faselåseprotokol, også kendt som 2PL-protokol, er en metode til samtidig kontrol i DBMS, der sikrer seriabilisering ved at anvende en lås til transaktionsdataene, som blokerer andre transaktioner for at få adgang til de samme data samtidigt. To faselåsning protokol hjælper med at eliminere samtidighedsproblemet i DBMS.
Denne låseprotokol opdeler eksekveringsfasen af en transaktion i tre forskellige dele.
- I den første fase, når transaktionen begynder at udføre, kræver den tilladelse til de låse, den har brug for.
- Den anden del er, hvor transaktionen får alle låse. Når en transaktion frigiver sin første lås, starter den tredje fase.
- I denne tredje fase kan transaktionen ikke kræve nye låse. I stedet frigiver det kun de erhvervede låse.
To-faselåsning-protokollen giver hver transaktion mulighed for at foretage en låse- eller låseopfordring i to trin:
- Vækstfase : I denne fase får transaktioner muligvis låse, men frigiver muligvis ikke låse.
- Krympefase : I denne fase kan en transaktion muligvis frigive låse, men ikke få nogen ny lås
Det er rigtigt, at 2PL-protokollen giver seriabilitet. Det sikrer dog ikke, at blokeringer ikke sker.
I det ovennævnte diagram kan du se, at lokale og globale dødvandsdetektorer søger efter blokeringer og løser dem ved at genoptage transaktioner til deres oprindelige tilstande.
Streng låsemetode i to faser
Strict-Two-phase locking system svarer næsten til 2PL. Den eneste forskel er, at Strict-2PL aldrig frigiver en lås efter brug af den. Det holder alle låse indtil forpligtelsespunktet og frigiver alle låse på én gang, når processen er slut.
Centraliseret 2PL
I Centralized 2 PL er et enkelt sted ansvarlig for låsestyringsprocessen. Den har kun en låsemanager til hele DBMS.
Primær kopi 2PL
Primær kopi 2PL-mekanisme, mange låseadministratorer distribueres til forskellige steder. Derefter er en bestemt låsemanager ansvarlig for at styre låsen for et sæt dataelementer. Når den primære kopi er opdateret, overføres ændringen til slaverne.
Distribueret 2PL
I denne form for tofaset låsemekanisme distribueres låseadministratorer til alle sider. De er ansvarlige for at administrere låse til data på dette websted. Hvis ingen data replikeres, svarer det til primær kopi 2PL. Kommunikationsomkostninger for Distribueret 2PL er ret højere end primær kopi 2PL
Tidsstempelbaserede protokoller
Tidsstempelbaseret protokol i DBMS er en algoritme, der bruger Systemtid eller Logisk tæller som et tidsstempel til at serieisere udførelsen af samtidige transaktioner. Den tidsstempelbaserede protokol sikrer, at alle modstridende læse- og skrivehandlinger udføres i en tidsstempelrækkefølge.
Den ældre transaktion prioriteres altid i denne metode. Det bruger systemtid til at bestemme transaktionens tidsstempel. Dette er den mest anvendte samtidige protokol.
Låsebaserede protokoller hjælper dig med at styre ordren mellem de modstridende transaktioner, når de udføres. Tidsstempelbaserede protokoller håndterer konflikter, så snart en operation oprettes.
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.
Fordele :
- Tidsplaner kan serienummeres ligesom 2PL-protokoller
- Ingen ventetid på transaktionen, hvilket eliminerer muligheden for blokeringer!
Ulemper:
Sult er mulig, hvis den samme transaktion genstartes og kontinuerligt afbrydes
Valideringsbaseret protokol
Valideringsbaseret protokol i DBMS, også kendt som optimistisk samtidighedskontrolteknik, er en metode til at undgå samtidighed i transaktioner. I denne protokol opdateres de lokale kopier af transaktionsdataene snarere end selve dataene, hvilket resulterer i mindre interferens under udførelsen af transaktionen.
Den valideringsbaserede protokol udføres i følgende tre faser:
- Læs fase
- Valideringsfase
- Skriv fase
Læs fase
I læsefasen kan dataværdierne fra databasen læses ved en transaktion, men skrivehandlingen eller opdateringerne anvendes kun på de lokale datakopier, ikke den faktiske database.
Valideringsfase
I valideringsfasen kontrolleres dataene for at sikre, at der ikke er nogen krænkelse af serialiserbarhed, når transaktionsopdateringerne anvendes i databasen.
Skriv fase
I skrivefasen anvendes opdateringerne til databasen, hvis valideringen er vellykket, ellers; opdateringerne anvendes ikke, og transaktionen rulles tilbage.
Karakteristika for god concurrency-protokol
En ideel DBMS-mekanisme for samtidig kontrol har følgende mål:
- Skal være modstandsdygtig over for fejl på webstedet og kommunikationen.
- Det giver mulighed for parallel udførelse af transaktioner for at opnå maksimal samtidighed.
- Dens lagringsmekanismer og beregningsmetoder skal være beskedne for at minimere omkostninger.
- Det skal håndhæve nogle begrænsninger for strukturen af atomhandlinger i transaktioner.
Resumé
- Samtidig kontrol er proceduren i DBMS til styring af samtidige operationer uden at komme i konflikt med hinanden.
- Mistede opdateringer, beskidt læsning, ikke-gentagelig læsning og forkert oversigtsproblemer er problemer på grund af manglende samtidighedskontrol.
- Låsebaseret, tofaset, tidsstempelbaseret, valideringsbaseret er typer af samtidige håndteringsprotokoller
- Låsen kan være delt (S) eller eksklusiv (X)
- To-faselåseprotokol, der også er kendt som en 2PL-protokol, der har brug for transaktion, skal erhverve en lås, når den frigiver en af dens låse. Den har 2 faser, der vokser og krymper.
- Den tidsstempelbaserede algoritme bruger en tidsstempel til at serieisere udførelsen af samtidige transaktioner. Protokollen bruger systemtid eller logisk optælling som tidsstempel.