Tags:    database locking timestamping samtidighed transaktion

Indledning

Denne artikel gennemgår de basale egenskaber og protokoller i langt de fleste 'Database Management Systems' (fork.: DBMS). Artiklen henvender sig både til den absolutte begynder indenfor dette emne, men kan også sagtens benyttes som en 'genopfriskningsguide' af dem som allerede ved lidt om dette emne. Du behøver ingen stor viden om databaser generelt, da teorien fra denne artikel vil blive gennemgået, så begynderen også sagtens kan følge med, men det er en fordel at have arbejdet en smule med databaser og SQL før. Lad os nu komme igang

Hvad er et DBMS

For at vi kan gå ordentligt igang, er det en god ide at vide lidt om hvad et DBMS egentlig er for en størrelse. DBMS er som du sikkert har læst dig til en forkortelse af DataBase Management System, og i sin simpleste form er dette et system, som sørger for at du kan skrive og læse data fra databasen. Hver eneste gang at man f.eks. vil læse/skrive noget data fra/til databasen, er der en masse handlinger som tages i brug, for at du bedst kan få de data ud/ind som du har brug for. Dette er vores DBMS som sørger for at du får lige præcis de data som du har bedt om, og ikke nogle helt andre. Du kan nu stille dig selv spørgsmålet - Hvorfor overhovedet have et system, som sørger for at vi får de rigtige data ud/ind på de rigtige steder? - Et af svarende kunne være at det er hele formålet med en database, nemlig at vi kan gemme data som vi igen kan finde frem senere, og derfor er det nødvendigt med et system, som varetager at finde præcis den slags data som vi har forespurgt.

Vores DBMS varetager ikke kun opgaver som at finde de rigtige data, det rigtige sted, men den har også nogle opgaver, som at sørge for at data ikke bliver blandet sammen. Nu tænker du måske - Hvordan kan det lade sig gøre? - Og det kan det heller, i en 'enkeltbruger database' (Eng.: Single-User Database), altså hvor der kun er en bruger tilknyttet databasen, men hvis man har en 'flerbruger database' (Eng.: Multi-User Database), så kan der opstå en masse problemer, som vores DBMS er nødt til at tage hånd om. Vi skal herunder kigge på nogle af disse problemer, og finde ud af hvordan vores Database løser dem.

Database Transaktioner

Hver eneste gang du i dit programmeringssprog sender en forespørgsel til din database, starter vores DBMS det som kaldes en transaktion (Eng.: Transaction).

A database transaction comprises a unit of work performed within a database management system (or similar system) against a database (Kilde.: Wikipedia)

En transaktion er som citatet også beskriver - En database transaktion binder en gruppe af opgaver/operationer sammen, som udføres inde i vores DBMS. Dette betyder at hver eneste gang vi laver nogle forespørgsler til vores database, laver vores DBMS en transaktion, med de forskellige forespørgsler og udfører disse. Når forespørgslen kommer til vores DBMS kaldes den også for en operation. Man kan altså sende flere forespørgsler samtidig, og på den måde kan en transaktion bestå af flere operationer (opgaver). Nu kan du så spørge hvorfor overhovedet 'grupperer' ens operationer i en transaktion, og til dette er svaret simpelthen at vores DBMS skal kunne sørge for dataene kan genskabes (Eng.: Recover) i tilfælde af Databasen fejler. Det betyder at den fejler i midten af transaktionen, så genskabes vores DBMS som det var før transaktionen. Vores DBMS skal også sørge for vores data er konsekvent behandlet. Det betyder bl.a. osgå at hvis der skulle ske en system fejl, så vil vores DBMS kunne vælge at afbryde hele transaktionen, selvom at nogle af vores data kom ind på databasen. Det som jeg har forsøgt at forklarer lidt om her, kan også udledes i nogle generelle principper omkring transaktioner. Man kan også disse principper for ACID principperne. ACID er en forkortelse af fire nøgleord omkring transaktioner, nemlig Atomicity, (da.: Atomar) Consistency, (da.: Konsistens) Isolation (da.: Isolation) og Durability (da.: Varighed). Vi skal herunder gennemgå disse fire principper mere i detaljer.

ACID Principperne

• Atomicity: En transaktion skal være atomar. Dette betyder at transaktionen er en enhed, og enten skal transaktionen fuldføre alle ændringerne i databasen, eller også skal den ikke gennemføre transaktionen overhovedet. Man kan aldrig gennemføre nogle af ændringerne i transaktionen, det skal være alt eller intet! Det betyder, lidt mere jordnært, at vores gruppe af forespørgsler (transaktion), bliver behandlet som en 'enhed'/stykke. Dvs. at hvis en af forespørgslerne i enheden fejler, så fejler alle sammen.


• Consistency: Vores transaktion skal efterlade vores database i en konsistent tilstand. Dette betyder at hvis en transaktion f.eks. sletter en række, som har referencer til andre rækker i andre tabeller i databasen, skal disse rækker også slettes, sådan så databasens data ikke har nogle løse ender, altså at den er konsistent.


• Isolation: En transaktion skal være isoleret fra andre transaktioner, således at en transaktion ikke kan se data gennemført af andre transaktioner, før disse er fuldført. Dette betyder at hvis en transaktion prøver at få adgang til at opdatere data i en række, som en anden transaktion lige har opdateret, men denne anden transaktion er ikke færdig med sine andre operationer, så må den første transaktion vente til den anden er fuldført. Dette er for at undgå det som man kalder en dirty read, som betyder at vores transaktion læser noget data, som den bruger i sin opdatering, men dette data kan stadig nå at blive ændret af vores første transaktion. Der findes dog forskellige slags isolations grader, afhængig af hvilket DBMS man benytter.


• Durability: En transaktion skal kunne genskabes ved store system fejl (f.eks. strømsvigt), for at sikre at ens database forbliver konsistent. Dette betyder at vores transaktion på en eller anden måde skal gemmes undervejs, så vi kan genskabe den hvis dette er nødvendigt. En lagring af transaktionen kan f.eks. ske under nogle checkpoints, som udstikkes i transaktionen.

Disse principper er til for at sikre databasens konistens, ved bl.a. at enten bliver en transaktion fuldført, eller også er der intet i transaktionen som bliver fuldført. Når hele transaktionen bliver fuldført, siger man også at transaktionen blev committed, og ligeledes hvis man pludselig i forløbet annullerede sin transaktion, eller der skete en fejl, kalder man det så for en rollback. En transaktion kan altså aldrig blive fuldført halvt (Atomicity), den skal altid fuldføres helt, for at der sker en ændring i databasen.

Et eksempel på at vise Commit og Rollback operationerne mere illustrativt, kunne f.eks. se således ud. Bemærk at transaktionerne jo består af en gruppe af SQL forespørgsler:

Commit Eksempel

 -- Tansaktion Start
 
 -- Indsæt Order data
 INSERT INTO Orders VALUES ('DG1024', '15-04-2011', 135);
 
 -- Indsæt OrderItems data
 INSERT INTO OrderItems VALUES ('DG1024', 4, 'HP450', 12);
 INSERT INTO OrderItems VALUES ('DG1024', 2, 'JK653', 40);
 
 -- Opdater lageret.
 UPDATE Stock SET StockQuantity = StockQuantity - 12 WHERE ProductionCode = 'HP450';
 UPDATE Stock SET StockQuantity = StockQuantity - 40 WHERE ProductionCode = 'JK653';
 
 -- Transaktion Afsluttet, Den bliver nu Commited af vores DBMS

Vi kan i vores commit eksempel se at hele transaktionen fuldføres uden fejl. Vi når derfor til det punkt at vores transaktion skal commites, altså udføres og gemmes i vores database. Herunder skal vi se på et eksempel på en transaktion der oplever et rollback.

Rollback Eksempel

 -- Transaktion Start
 
 -- Indsæt Order data
 INSERT INTO Orders VALUES ('DG1024', '15-04-2011', 135);
 
 -- Indsæt OrderItems data
 INSERT INTO OrderItems VALUES ('DG1024', 4, 'HP450', 12);
 INSERT INTO OrderItems VALUES ('DG1024', 2, 'JK653', 40);
 
 -- Opdater lageret.
 UPDATE Stock SET StockQuantity = StockQuantity - 12 WHERE ProductionCode = 'HP450';
 
 ----------- FEJL ----------------
 
 -- Vores DBMS begynder på Rollback proceduren.
 -- Alle tidligere SQL statements i denne transaktion glemmes, og databasen bliver ikke ændret overhovedet.
 -- Databasen vil nu være i den tilstand som den var i før transaktionen begyndte.

Vi kan i vores Rollback eksempel se at der pludselig under transaktionen sker en eller anden fejl, så vores DBMS vælger at bruge Rollback proceduren. Den kan jo ikke kun lave noget af vores transaktion, og herefter glemme at opdatere resten. Det var jo netop et af vores principper fra ACID modellen, nemlig Atomicity der betød at det var alt eller intet, altså hele transaktionen skulle fuldføres ellers ingenting.



Hvad synes du om denne artikel? Giv din mening til kende ved at stemme via pilene til venstre og/eller lægge en kommentar herunder.

Del også gerne artiklen med dine Facebook venner:  

Karma barometer (30 dage)

IT jobs | Kontakt | Om Udvikleren.dk | Om karma | IT nyheds arkiv | Annoncering

X