DBMS-samtidighetskontroll: Låsnings- och tidsstämpelbaserade protokoll

⚡ Smart sammanfattning

Samtidighetskontroll i DBMS hanterar samtidiga transaktioner så att de körs korrekt utan att kränka dataintegriteten. Det förhindrar avvikelser som förlorade uppdateringar och dirty reads med hjälp av låsbaserade, tvåfasiga, tidsstämpelbaserade och valideringsbaserade protokoll som garanterar serialiserbara resultat.

  • 👥 Kärnsyfte: Samtidighetskontroll låter många transaktioner beröra delad data samtidigt medanping databasen är konsekvent.
  • ⚠️ Förebyggda anomalier: Förlorad uppdatering, smutsig läsning, icke-upprepningsbar läsning och felaktig sammanfattning är de fyra problemen det stoppar.
  • 🔒 Låsbaserat: Delade och exklusiva lås styr om ett dataobjekt kan läsas eller skrivas av andra.
  • 🔁 Tvåfaslåsning: En växande fas förvärvar lås och en krympande fas frigör dem, vilket garanterar serialiserbarhet.
  • ⏱️ Tidsstämpelbaserad: Äldre transaktioner prioriteras och motstridiga operationer ordnas efter en systemtidsstämpel.
  • Valideringsbaserad: Optimistisk kontroll fungerar på lokala kopior och validerar endast före skrivfasen.
  • 🎯 Mål: Maximal samtidighet med minimal omkostnad, motståndskraftig mot plats- och kommunikationsfel.

Låsnings- och tidsstämpelschemaläggare i DBMS

Vad är samtidighetskontroll?

Samtidighetskontroll I ett databashanteringssystem är en procedur för att hantera samtidiga operationer utan att de kommer i konflikt med varandra. Det säkerställer att databastransaktioner utförs samtidigt och korrekt för att producera korrekta resultat utan att kränka dataintegriteten för respektive databas.

Samtidig åtkomst är ganska enkel om alla användare bara läser data, eftersom det inte finns något sätt att de kan störa varandra. Men alla praktiska databaser har en blandning av LÄS- och SKRIV-operationer, och därför blir samtidighet en utmaning.

Samtidighetskontroll i DBMS används för att hantera sådana konflikter, som oftast uppstår i fleranvändarsystem. Samtidighetskontroll är därför ett av de viktigaste elementen för att en databas ska fungera korrekt där två eller flera transaktioner körs samtidigt och kräver åtkomst till samma data. Det fungerar hand i hand med transaktionshantering, som definierar de arbetsenheter som samtidighetskontroll måste sammanfoga på ett säkert sätt.

Potentiella problem med samtidighet

Här är några problem som du sannolikt kan stöta på utan korrekt samtidighetskontroll i DBMS:n:

  • Förlorade uppdateringar inträffa när flera transaktioner väljer samma rad och uppdaterar den baserat på det valda värdet.
  • Obestämt beroende (smutsig läsning) inträffar när en andra transaktion väljer en rad som har uppdaterats av en annan transaktion som ännu inte har genomförts.
  • Ej upprepningsbar läsning inträffar när en andra transaktion öppnar samma rad flera gånger och läser olika data varje gång.
  • Felaktig sammanfattning inträffar när en transaktion gör en sammanfattning av värdet av alla instanser av ett upprepat dataelement medan en andra transaktion uppdaterar några av dessa instanser. Den resulterande sammanfattningen återspeglar inte ett korrekt resultat.

Varför använda en samtidighetsmetod?

Skäl till att använda en samtidighetskontrollmetod i DBMS:

  • Att tillämpa isolering genom ömsesidig uteslutning mellan motstridiga transaktioner.
  • För att lösa läs-skriv- och skriv-skriv-konflikter.
  • För att bevara databasens konsistens genom att ständigt tillämpa exekveringsbegränsningar.
  • Att kontrollera interaktionen mellan samtidiga transaktioner, uppnått med hjälp av samtidighetskontrollscheman.
  • För att säkerställa serialiserbarhet.

Exempelvis

Antag att två personer går till elektroniska kiosker samtidigt för att köpa en biobiljett till samma film och samma föreställningstid.

Det finns dock bara en plats kvar för den föreställningen i biografen. Utan samtidighetskontroll är det möjligt att båda biobesökarna köper en biljett. Samtidighetskontroll tillåter inte detta. Båda biobesökarna kan fortfarande komma åt informationen i databasen över bioplatser, men samtidighetskontrollen ger endast en biljett till den köpare som slutför transaktionsprocessen först.

Protokoll för samtidighetskontroll

Olika protokoll för samtidighetskontroll erbjuder olika avvägningar mellan mängden samtidighet de tillåter och den overhead de innebär. De viktigaste teknikerna för samtidighetskontroll i DBMS är:

  • Låsbaserade protokoll
  • Tvåfaslåsningsprotokoll
  • Tidsstämpelbaserade protokoll
  • Valideringsbaserade protokoll

Var och en undersöks i tur och ordning nedan, med början i de mest använda, låsbaserade protokollen.

Låsbaserade protokoll

Låsbaserade protokoll I DBMS är en mekanism där en transaktion inte kan läsa eller skriva ett dataelement förrän den får ett lämpligt lås. Låsbaserade protokoll hjälper till att eliminera samtidighetsproblemet genom att låsa eller isolera ett visst dataelement till en enda transaktion.

Ett lås är en datavariabel som är associerad med ett dataelement och som anger vilka operationer som kan utföras på det. Lås hjälper till att synkronisera åtkomst till databaselement genom samtidiga transaktioner. Alla låsförfrågningar görs till samtidighetskontrollhanteraren, och transaktioner fortsätter endast när låsförfrågan har beviljats.

Binära lås: Ett binärt lås på ett dataobjekt kan vara i antingen låst eller olåst tillstånd.

Delad/Exklusiv: Denna låsmekanism separerar lås baserat på deras användning. Om ett lås anskaffas för att utföra en skrivoperation kallas det ett exklusivt lås.

1. Delat lås (S): Ett delat lås kallas även ett skrivskyddat lås. Med ett delat lås kan dataobjektet delas mellan transaktioner, eftersom ingen av dem har behörighet att uppdatera objektet. Om till exempel två transaktioner läser en persons kontosaldo, databas låter dem läsa genom att placera ett delat lås. Om en annan transaktion vill uppdatera det saldot, förhindrar det delade låset det tills avläsningen är klar.

2. Exklusivt lås (X): Med ett exklusivt lås kan ett dataobjekt läsas såväl som skrivas. Det är exklusivt och kan inte hållas samtidigt på samma dataobjekt. Ett X-lock begärs med hjälp av lock-x-instruktionen. Till exempel, när en transaktion behöver uppdatera ett kontosaldo, tillåts det genom att placera ett X-lock; en andra transaktion som vill läsa eller skriva förhindras då.

3. Förenklat låsprotokoll: Detta gör att transaktioner kan låsa varje objekt innan en operation påbörjas. Transaktioner kan låsa upp dataelementet efter att skrivoperationen är klar.

4. Låsning före anspråk: Detta protokoll utvärderar operationer och skapar en lista över de dataelement som behövs för att starta exekveringen. När alla lås har beviljats ​​exekveras transaktionen, och alla lås släpps när operationerna är avslutade.

Svält: Svält är situationen när en transaktion väntar under en obestämd tid på att låsas. Orsakerna kan vara ett dåligt hanterat vänteschema för låsta objekt, en resursläcka eller att samma transaktion väljs ut som offer upprepade gånger.

Dödläge: Ett dödläge hänvisar till en situation där två eller flera processer väntar på att varandra ska frigöra en resurs och bildar en cirkulär kedja.

Tvåfaslåsningsprotokoll (2PL)

Ocuco-landskapet Tvåfaslåsningsprotokoll, även känt som 2PL, är en metod för samtidighetskontroll som säkerställer serialiserbarhet genom att tillämpa ett lås på transaktionsdata, vilket blockerar andra transaktioner från att komma åt samma data samtidigt.

Tvåfaslåsningsprotokollet gör att varje transaktion kan göra en låsnings- eller upplåsningsbegäran i två steg:

  • Växande fas: i denna fas kan en transaktion erhålla lås men kanske inte frigöra några lås.
  • Krympningsfas: I denna fas kan en transaktion frigöra lås men kanske inte erhålla något nytt lås.

Tvåfasiga låsande tillväxt- och krympningsfaser

Det är sant att 2PL erbjuder serialiserbarhet. Det garanterar dock inte att dödlägen inte uppstår. I diagrammet ovan söker lokala och globala dödlägesdetektorer efter dödlägen och löser dem genom att återgå till transaktionernas ursprungliga tillstånd.

Strikt tvåfaslåsningsmetod

Strict 2PL är nästan detsamma som 2PL. Den enda skillnaden är att Strict-2PL aldrig släpper ett lås efter att ha använt det. Den håller alla lås fram till commit-punkten och släpper dem alla på en gång när processen är över.

Centraliserad 2PL

I centraliserad 2PL ansvarar en enda plats för låshanteringsprocessen. Den har bara en låshanterare för hela DBMS-systemet.

Primär kopia 2PL

I Primary Copy 2PL-mekanismen är många låshanterare distribuerade till olika platser, och en specifik låshanterare ansvarar för att hantera låset för en uppsättning dataobjekt. När den primära kopian uppdateras sprids ändringen till slavarna.

Distribuerad 2PL

I den här mekanismen är låshanterare distribuerade till alla platser och ansvariga för att hantera lås för data på den platsen. Om ingen data replikeras motsvarar det Primary Copy 2PL. Kommunikationskostnaderna för Distributed 2PL är betydligt högre än för Primary Copy 2PL.

Tidsstämpelbaserade protokoll

Ocuco-landskapet Tidsstämpelbaserat protokoll I DBMS är en algoritm som använder systemtiden eller en logisk räknare som tidsstämpel för att serialisera exekveringen av samtidiga transaktioner. Den säkerställer att varje motstridig läs- och skrivoperation exekveras i tidsstämpelordning.

Den äldre transaktionen prioriteras alltid i den här metoden. Den använder systemtid för att bestämma transaktionens tidsstämpel, och det är det vanligaste samtidighetsprotokollet. Låsbaserade protokoll hanterar ordningen mellan motstridiga transaktioner när de körs; tidsstämpelbaserade protokoll hanterar konflikter så snart en operation skapas.

Exempel:

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.

fördelar:

  • Scheman är serialiserbara, precis som 2PL-protokoll.
  • Ingen väntan på transaktionen, vilket eliminerar risken för dödlägen.

Nackdelar: Svält är möjlig om samma transaktion startas om och kontinuerligt avbryts.

Valideringsbaserat protokoll

Ocuco-landskapet Valideringsbaserat protokoll I DBMS, även känt som den optimistiska samtidighetskontrolltekniken, är en metod för att undvika samtidighetskonflikter i transaktioner. I detta protokoll uppdateras lokala kopior av transaktionsdata snarare än själva data, vilket resulterar i mindre störningar under exekveringen.

Det valideringsbaserade protokollet utförs i tre faser:

  1. Läs Fas
  2. Valideringsfas
  3. Skriv Fas

Läs Fas

I läsfasen kan datavärden läsas av en transaktion, men skrivåtgärder eller uppdateringar tillämpas endast på de lokala datakopiorna, inte på själva databasen.

Valideringsfas

I valideringsfasen kontrolleras data för att säkerställa att tillämpningen av uppdateringarna inte bryter mot serialiserbarheten.

Skriv Fas

I skrivfasen tillämpas uppdateringarna på databasen om valideringen lyckas; annars ignoreras uppdateringarna och transaktionen återställs.

Jämförelse av protokoll för samtidighetskontroll

De fyra protokollfamiljerna gör olika satsningar på hur ofta transaktioner faktiskt kolliderar. Tabellen nedan sammanfattar var varje protokoll passar in.

Protokoll Tillvägagångssätt Dödläge Bäst när
Låsbaserad Pessimistisk, lås före åtkomst Möjligt Konflikter är vanliga
Tvåfaslåsning Pessimistiska, växande och krympande faser Möjligt Serialiserbarhet krävs
Tidsstämpelbaserad Beställningar efter tidsstämpel Dödlägesfri Beställningen är viktig, väntan är kostsam
Valideringsbaserad Optimistisk, validera innan du skriver Dödlägesfri Konflikter är sällsynta

Kort sagt antar låsbaserade och 2PL-protokoll att konflikter är vanliga och förhindrar dem i förväg, medan tidsstämpel- och valideringsprotokoll antar att konflikter är sällsynta och löser dem endast när de uppstår.

Egenskaper hos ett bra samtidighetsprotokoll

En ideal mekanism för samtidighetskontroll har följande mål:

  • Den måste vara motståndskraftig mot fel på plats och kommunikation.
  • Det möjliggör parallellt genomförande av transaktioner för att uppnå maximal samtidighet.
  • Dess lagringsmekanismer och beräkningsmetoder bör vara blygsamma för att minimera omkostnader.
  • Det måste införa vissa begränsningar för strukturen hos transaktionernas atomära handlingar.

Vanliga frågor

Ett delat lås tillåter samtidig läsning men ingen skrivning, så flera transaktioner kan hålla det. Ett exklusivt lås tillåter läsning och skrivning och kan inte delas, så endast en transaktion håller det.

Nr. 2PL garanterar serialiserbarhet men inte frihet från dödläge. Två transaktioner kan fortfarande vänta på varandras lås, så en separat detekterings- eller timeout-mekanism behövs fortfarande.

När konflikter är sällsynta. Valideringsbaserad kontroll undviker låsningsoverhead och låter transaktioner köras fritt, med kontroll endast vid commit. Vid kraftig konkurrens slösar den bort arbete genom frekventa återställningar.

AI studerar tidigare arbetsbelastningar för att förutsäga vilka transaktioner som kommer att komma i konflikt, och rekommenderar sedan en isoleringsnivå eller låsgranularitet som ökar dataflödet samtidigt som den hållerping resultat kan serialiseras.

Den får aldrig en transaktion att vänta. En konflikterande operation tillåts antingen av tidsstämpelordningen eller så avbryts transaktionen och startas om, så ingen cirkulär väntetid kan uppstå och ett dödläge kan inte uppstå.

Sammanfatta detta inlägg med: