ACID2

Et databasesystem skal stille følgende faciliteter til rådighed:

• Atomare transaktioner, hvilket betyder, at en ændring enten skal gennemføres helt eller også skal der ryddes så godt op, at det ser ud som om ændringen ikke er forsøgt gennemført.
• Konsistens De atomare transaktioner skal føre databasen fra en sammenhængende tilstand til en anden. Dette kræver, at de enkelte transaktioner er designet korrekt og hænger ikke kun på databasesystemet.
• Isolation To eller flere programmer, der bruger samme database, må ikke kunne se hinandens ændringer, før de er helt gennemførte. Der anvendes dog forskellige grader af isolation.
• Varighed Det skal sikres, at data ikke bare forsvinder. Det stiller krav til den anvendte hardware og krav om at skrivninger til disk laves, så data ikke kun lander i en cache undervejs.

På engelsk kaldes disse krav om bestemte egenskaber for ACID-properties efter forbogstaverne i de engelske betegnelser atomicy, consistency, isolation og durability.

[redigér]Atomare transaktioner

Hvis en transaktion kun omfatter læsning, vil den altid kunne startes forfra. Resten af afsnittet handler om transaktioner, der omfatter skrivning til databasen. Der findes flere måder at implementere atomare transaktioner på, men det almindeligste er at bruge en "skriv-foran-log" (write ahead log). Denne log vil i det følgende blive omtalt som en transaktionslog. Først skrives en beskrivelse af ændringen i transaktionsloggen og derefter gennemføres ændringen i selve databasen. Når en transaktion er gennemført, markeres den som gennemført i loggen.

Fejl håndteres forskelligt alt efter om det er fejl, der opdages af databasesystemet eller det er fejl, der opdages af det opdaterende program. Hvis fejl opdages af programmet, markeres transaktionen som fejlbehæftet, og alle opdateringer føres tilbage til udgangspunktet ved hjælp af oplysningerne i transaktionsloggen. Selvom databaseprogrammet finder en fejl, skal transaktionen så vidt muligt gennemføres. Hvis det er lykkedes at skrive transaktionen i loggen, gennemføres den fra oplysningerne her, ellers ikke. I visse tilfælde kan hensynet til korrekt isolation gøre, at en transaktion ikke kan gennemføres. I disse tilfælde bliver ændringerne ført tilbage, og det opdaterende program må forsøge at gennemføre transaktionen på ny.

[redigér]Isolation

Der opstår forskellige problemer, hvis forskellige programmer, der bruger den samme database, kan se hinandens ændringer inden de er helt gennemførte. Løsningen er, at isolere de enkelte databasetransaktioner fra hinanden. En høj grad af isolation sikrer, data hænger rigtigt sammen, men begrænser også parallelle opdateringer, hvilket kan give lange afviklingstider for de opdaterende programmer.

De mest gængse niveauer af isolation er fra det laveste til det højeste:

• Læs ikke gennemførte (read uncommitted): Ingen isolation. Et program kan læse data, som måske bliver tilbageført eller overskrevet senere.
• Læs gennemførte (read committed): Et program kan kun læse data, der er skrevet endeligt til databasen. Det er muligt, at de læste data ændres fra anden side inden transaktionen er slut.
• Gentagelige læsninger: Et program kan læse de samme data flere gange og få det samme resultat inden for den aktuelle transaktion.
• Serialisering: Ud over gentagelige læsninger er mulige, sikres det, at en transaktion ikke har kunnet læst data, der er slettet eller ændret inden transaktionen er gennemført. Data, der er tilføjet fra en anden transaktion kan heller ikke ses.

I mange tilfælde er niveauet "læs gennemførte" tilstrækkeligt.

[redigér]Varighed

For at sikre, at data opbevares i databasen så længe, det er nødvendigt, er sikkerhedskopiering en nødvendighed. Det er i den sammenhæng vigtigt, at data hænger rigtigt sammen (er konsistente) inden backup foretages. Løsningen er, at etablere et kontrolpunkt (checkpoint).

Etablering af et kontrolpunkt kan ske på denne måde:

1. Der lukkes af for nye transaktioner
2. Transaktioner, der er i gang gennemføres
3. Det sikres, at alle data er skrevet til disk
4. Det markeres i databasens log, at der er lavet et kontrolpunkt
5. Der laves backup og eventuelt anden vedligeholdelse
6. Transaktionsloggen tømmes
7. Der åbnes for transaktioner igen

Nogle databasesystemer kan sætte transaktioner i kø under oprettelse af et kontrolpunkt.