En transaktion är en grupp av sekventiella operationer med en databas , som är en logisk enhet för arbete med data. En transaktion kan antingen slutföras framgångsrikt, med respekt för dataintegritet och oberoende av andra samtidiga transaktioner, eller inte slutföras alls, i vilket fall den inte bör ha någon effekt. Transaktioner bearbetas av transaktionssystem , varvid en transaktionshistorik skapas .
Särskilja sekventiella (normala), parallella och distribuerade transaktioner . Distribuerade transaktioner involverar användning av mer än ett transaktionssystem och kräver mycket mer komplex logik (till exempel två-fas commit - ett två-fas transaktion commit protokoll ). Vissa system implementerar också autonoma transaktioner , eller deltransaktioner, som är en autonom del av modertransaktionen.
Exempel: du måste överföra beloppet av 10 monetära enheter från bankkonto nummer 5 till konto nummer 7. Detta kan till exempel uppnås genom följande sekvens av åtgärder:
Dessa åtgärder representerar en logisk arbetsenhet "överföring av belopp mellan konton", och är således en transaktion. Om denna transaktion avbryts, till exempel i mitten, och inte avbryter alla ändringar, är det lätt att lämna ägaren av kontonummer 5 utan 10 enheter, medan ägaren av kontonummer 7 inte kommer att ta emot dem.
En av de vanligaste uppsättningarna av krav för transaktioner och transaktionssystem är ACID -uppsättningen (Atomicitet, Konsistens, Isolation, Durability). Syrakraven formulerades huvudsakligen i slutet av 1970-talet av Jim Gray [1] . Samtidigt finns det specialiserade system med försvagade transaktionsegenskaper [2] .
Helst bör transaktioner av olika användare utföras på ett sådant sätt att illusionen skapas att användaren av den aktuella transaktionen är den enda. Men i verkligheten, av prestandaskäl och för att utföra vissa speciella uppgifter, tillhandahåller DBMS olika nivåer av transaktionsisolering.
Nivåerna beskrivs i ordningsföljd för att öka isoleringen av transaktioner och därmed tillförlitligheten i arbetet med data.
Ju högre isoleringsnivån är, desto mer resurser krävs för att tillhandahålla den. Följaktligen kan ökad isolering leda till en minskning av hastigheten på parallella transaktioner, vilket är "betalningen" för att öka tillförlitligheten.
I DBMS kan transaktionsisoleringsnivån väljas både för alla transaktioner samtidigt och för en specifik transaktion. Som standard använder de flesta databaser nivå 1 (Read Committed). Nivå 0 används främst för att spåra förändringar i långa transaktioner eller för att läsa data som ändras sällan. Nivå 2 och 3 används för ökade krav på transaktionsisolering.
Att fullt ut implementera isoleringsnivåer och ACID-egenskaper är inte en trivial uppgift. Bearbetning av inkommande data leder till många små förändringar, inklusive uppdatering av både själva tabellerna och indexen. Dessa ändringar kan potentiellt misslyckas: ta slut på diskutrymme, operationen tar för lång tid (timeout), etc. Systemet måste korrekt återställa databasen till tillståndet före transaktionen i händelse av fel.
Tidiga kommersiella DBMS:er (som IBM:s DB2 ) använde uteslutande dataåtkomstlåsning för att tillhandahålla ACID-egenskaper. Men ett stort antal lås leder till en betydande minskning av prestanda. Det finns två populära familjer av lösningar på detta problem som minskar blockering:
I båda fallen ska lås sättas på all information som uppdateras. Beroende på isoleringsnivå och implementering placeras även skrivlås på informationen som lästes av transaktionen.
Med proaktiv loggning , som används i Sybase och MS SQL Server före version 2005, skrivs alla ändringar till loggen, och först efter framgångsrikt slutförande - till databasen. Detta gör att DBMS kan återgå till ett fungerande tillstånd efter en oväntad systemkrasch. Skuggsidor innehåller kopior av dessa databassidor i början av transaktionen där ändringar sker. Dessa kopior aktiveras när de är klara. Skuggsidor är lättare att implementera, men proaktiv loggning är effektivare [4] .
Ytterligare utveckling av databashanteringsteknologier ledde till uppkomsten av blockfria teknologier. Idén om samtidighetskontroll med hjälp av tidsstämpelbaserad samtidighetskontroll utvecklades och ledde till uppkomsten av en multiversionsarkitektur MVCC . Dessa tekniker kräver inte ändringsloggning eller skuggsidor. Arkitekturen implementerad i Oracle 7.x och senare skriver äldre versioner av sidor till ett speciellt återställningssegment, men de är fortfarande läsbara. Om transaktionen, vid läsning, träffar en sida vars tidsstämpel är nyare än läsningens början, tas data från återställningssegmentet (det vill säga den "gamla" versionen används). För att stödja detta arbete förs en transaktionslogg, men till skillnad från "proaktiv loggning" innehåller den ingen data. Att arbeta med det består av tre logiska steg:
Transaktionsloggen, i kombination med rollback-segmentet (det område som lagrar en kopia av all data som ändras under transaktionen), garanterar dataintegriteten. I händelse av ett misslyckande startas ett återställningsförfarande som tittar på dess individuella poster enligt följande:
Firebird har ingen ändringslogg eller återställningssegment alls, utan implementerar MVCC genom att skriva nya versioner av tabellrader direkt i det aktiva datautrymmet. Detsamma gör MS SQL 2005. Teoretiskt ger detta maximal effektivitet när man arbetar med data parallellt, men priset är behovet av "sopsamling", det vill säga borttagning av gamla och inte längre nödvändiga versioner av datan.
Transaktionsbehandling syftar till att upprätthålla ett datorsystem (vanligtvis en databas eller vissa moderna filsystem ) i ett känt, konsekvent tillstånd genom att säkerställa att alla operationer som äger rum på systemet är beroende av varandra och antingen alla framgångsrikt slutförts eller helt och avbrutits framgångsrikt. [5]
Tänk till exempel på en typisk banktransaktion som innebär att flytta $700 från en kunds sparkonto till en kunds checkkonto. Denna transaktion är en enda transaktion för banken, men den inkluderar minst två separata transaktioner i datortermer: 700 USD krediteras inlåningskontot och 700 USD krediteras checkkontot. Om debettransaktionerna lyckas och kredittransaktionerna inte är det (eller vice versa), kommer bankens böcker inte att ha ett saldo vid dagens slut. Därför måste det finnas ett sätt att säkerställa att båda operationerna antingen lyckas eller misslyckas, så att det aldrig blir någon inkonsekvens i bankens databas som helhet. Transaktionsbehandling är utformad för att tillhandahålla detta.
Transaktionsbehandling gör att flera separata transaktioner automatiskt kan länkas samman som en enda, odelbar transaktion. Transaktionsbehandlingssystem säkerställer att antingen alla operationer i en transaktion genomförs utan fel, eller ingen av dem. Om några av operationerna har slutförts, men med fel, och andra utan, instruerar transaktionsbearbetningssystemet att "rulla tillbaka" alla transaktioner av transaktionen (inklusive framgångsrika sådana), vilket innebär att radera alla spår av operationen och återställa systemet till en konsekvent känt tillstånd som var före starten av transaktionsprocessen. Om alla operationer av transaktionen slutförs framgångsrikt, så begås transaktionen i systemet, och alla ändringar i databasen blir "permanenta" ( committed ); transaktioner kan inte ångras om de redan har gjorts.
Transaktionsbearbetning skyddar mot hårdvaru- och mjukvarufel som kan lämna en transaktion delvis slutförd, med systemet kvar i ett okänt, inkonsekvent tillstånd. Om ett datorsystem misslyckas mitt i en transaktion säkerställer transaktionsbearbetningen att alla transaktioner i eventuella icke-åtagande (det vill säga inte helt behandlade) transaktioner rullas tillbaka.
Transaktioner ordnas i strikt kronologisk ordning. Om transaktion N+1 har för avsikt att röra samma del av databasen som transaktion N, startar transaktion N+1 inte förrän transaktion N inträffar. Före eventuella transaktioner måste alla andra transaktioner som påverkar samma del av systemet också slutföras; det kan inte finnas några "hål" i sekvensen av tidigare transaktioner. [6] [5]
De grundläggande principerna för alla transaktionsbehandlingssystem är desamma. Terminologin kan dock variera från ett transaktionsbehandlingssystem till ett annat, och termerna som används nedan är inte nödvändigtvis universella. [7]
Rollback ( eng. rollback )Transaktionsbehandlingssystem säkerställer databasens integritet genom att registrera databasens mellantillstånd innan den ändras, och sedan använda dessa poster för att återställa databasen till ett känt tillstånd om transaktionen inte kan utföras. Till exempel görs kopior av information i en databas innan den ändrades av en transaktion av systemet före transaktionen som kan göra några ändringar (kallas ibland före bild ). Om någon del av transaktionen misslyckas innan den genomförs, används dessa kopior för att återställa databasen till det tillstånd den var i innan transaktionen började ( Återställning ). [6]
Kör ( eng. rollforward )Du kan också hålla en separat logg över alla databasändringar (kallas ibland efter bilder ); detta kräver inte en återställning av misslyckade operationer, men det är användbart för att uppdatera databasen i händelse av ett databasfel, vilket är anledningen till att vissa transaktionsbehandlingssystem tillhandahåller denna funktion. Om databasen misslyckas helt måste den återställas från den senaste säkerhetskopian. Säkerhetskopieringar kommer inte att återspegla operationer som utförts efter att de skapades. Men när databasen har återställts kan efterbildersloggen appliceras på databasen ( rollforward ) för att uppdatera den. Alla transaktioner som pågår vid tidpunkten för felet kan återställas. Resultatet är en databas i ett känt konsekvent tillstånd som inkluderar resultaten av alla transaktioner som begåtts fram till felet. [6]
Ömsesidig blockering ( eng. blockerat låsläge )I vissa fall kan två transaktioner under sin bearbetning försöka komma åt samma del av databasen samtidigt, på ett sätt som hindrar dem från att slutföras. Till exempel kan transaktion A komma åt del X av databasen, och transaktion B kan komma åt del Y av databasen. Om, vid denna tidpunkt, transaktion A försöker komma åt del Y av databasen medan transaktion B försöker komma åt del X, uppstår en dödlägessituation och ingen transaktion kan fortsätta. Transaktionsbehandlingssystem är utformade för att upptäcka sådana situationer. Vanligtvis ångras båda transaktionerna och rullas tillbaka, och sedan startas de automatiskt i en annan ordning så att dödläget inte uppstår igen. Eller ibland rullas bara en av de låsta transaktionerna tillbaka, rullas tillbaka och försöker automatiskt igen efter en kort fördröjning.
Deadlocks kan uppstå mellan tre eller flera transaktioner. Ju fler transaktioner som är kopplade, desto svårare är de att upptäcka. Transaktionsbehandlingssystem har till och med satt en praktisk gräns för de dödlägen de kan upptäcka.
| Databas | |
|---|---|
| Begrepp |
|
| Objekt |
|
| Nycklar | |
| SQL |
|
| Komponenter | |