En transaktion er en gruppe af sekventielle operationer med en database , som er en logisk enhed for arbejde med data. En transaktion kan enten gennemføres med succes, med respekt for dataintegriteten og uafhængig af andre samtidige transaktioner, eller slet ikke fuldføres, i hvilket tilfælde den ikke burde have nogen effekt. Transaktioner behandles af transaktionssystemer , i løbet af hvilke der oprettes en transaktionshistorik .
Skelne sekventielle (normale), parallelle og distribuerede transaktioner . Distribuerede transaktioner involverer brugen af mere end ét transaktionssystem og kræver meget mere kompleks logik (for eksempel to-faset commit - en to-faset transaktion commit protokol ). Nogle systemer implementerer også autonome transaktioner eller deltransaktioner, som er en autonom del af modertransaktionen.
Eksempel: du skal overføre beløbet på 10 pengeenheder fra bankkonto nummer 5 til konto nummer 7. Dette kan for eksempel opnås ved følgende rækkefølge af handlinger:
Disse handlinger repræsenterer en logisk arbejdsenhed "overførsel af beløb mellem konti", og er således en transaktion. Hvis denne transaktion afbrydes, for eksempel i midten, og ikke annullerer alle ændringer, er det nemt at lade ejeren af kontonummer 5 stå uden 10 enheder, mens ejeren af kontonummer 7 ikke vil modtage dem.
Et af de mest almindelige sæt krav til transaktioner og transaktionssystemer er ACID -sættet (Atomicitet, Konsistens, Isolation, Durability). ACID-kravene blev hovedsageligt formuleret i slutningen af 1970'erne af Jim Gray [1] . Samtidig er der specialiserede systemer med svækkede transaktionsegenskaber [2] .
Ideelt set bør transaktioner fra forskellige brugere udføres på en sådan måde, at den illusion skabes, at brugeren af den aktuelle transaktion er den eneste. Men i virkeligheden, af præstationsmæssige årsager og for at udføre nogle specielle opgaver, giver DBMS forskellige niveauer af transaktionsisolering.
Niveauerne er beskrevet i rækkefølge for at øge isoleringen af transaktioner og dermed pålideligheden af at arbejde med data.
Jo højere isolationsniveauet er, jo flere ressourcer kræves der for at levere det. Følgelig kan stigende isolation føre til et fald i hastigheden af parallelle transaktioner, som er "betalingen" for at øge pålideligheden.
I DBMS kan transaktionsisolationsniveauet vælges både for alle transaktioner på én gang og for en specifik transaktion. Som standard bruger de fleste databaser niveau 1 (Read Committed). Niveau 0 bruges primært til at spore ændringer i langvarige transaktioner eller til at læse data, der ændrer sig sjældent. Niveau 2 og 3 bruges til øgede krav til transaktionsisolering.
Fuldstændig implementering af isolationsniveauer og ACID-egenskaber er ikke en triviel opgave. Behandling af indgående data fører til en masse små ændringer, herunder opdatering af både selve tabellerne og indekserne. Disse ændringer kan potentielt mislykkes: at løbe tør for diskplads, operationen tager for lang tid (timeout) osv. Systemet skal korrekt returnere databasen til tilstanden før transaktionen i tilfælde af fejl.
Tidlige kommercielle DBMS'er (såsom IBM's DB2 ) brugte udelukkende dataadgangslåsning til at levere ACID-egenskaber. Men et stort antal låse fører til et betydeligt fald i ydeevnen. Der er to populære familier af løsninger på dette problem, der reducerer blokering:
I begge tilfælde skal der sættes låse på al information, der opdateres. Afhængigt af isolationsniveauet og implementeringen placeres skrivelåse også på den information, der blev læst af transaktionen.
Med proaktiv logning , brugt i Sybase og MS SQL Server før version 2005, skrives alle ændringer til loggen, og først efter vellykket afslutning - til databasen. Dette gør det muligt for DBMS at vende tilbage til en fungerende tilstand efter et uventet systemnedbrud. Skyggesider indeholder kopier af disse databasesider i begyndelsen af den transaktion, hvor ændringerne sker. Disse kopier aktiveres ved vellykket afslutning. Mens skyggesider er nemmere at implementere, er proaktiv logning mere effektiv [4] .
Yderligere udvikling af databasestyringsteknologier førte til fremkomsten af blokløse teknologier. Ideen om samtidighedskontrol ved hjælp af tidsstempelbaseret samtidighedskontrol blev udviklet og førte til fremkomsten af en multiversionsarkitektur MVCC . Disse teknologier kræver ikke ændringslogning eller skyggesider. Arkitekturen implementeret i Oracle 7.x og senere skriver ældre versioner af sider til et særligt rollback-segment, men de er stadig læsbare. Hvis transaktionen ved læsning rammer en side, hvis tidsstempel er nyere end starten af læsning, tages dataene fra rollback-segmentet (det vil sige, at den "gamle" version bruges). For at understøtte dette arbejde føres en transaktionslog, men i modsætning til "proaktiv logning" indeholder den ikke data. At arbejde med det består af tre logiske trin:
Transaktionsloggen, i kombination med rollback-segmentet (det område, der gemmer en kopi af alle de data, der ændres under transaktionen), garanterer integriteten af dataene. I tilfælde af en fejl, lanceres en gendannelsesprocedure, der ser på dens individuelle poster som følger:
Firebird har overhovedet ingen ændringslog eller rollback-segment, men implementerer MVCC ved at skrive nye versioner af tabelrækker direkte ind i det aktive datarum. Det samme gør MS SQL 2005. Teoretisk giver det maksimal effektivitet, når der arbejdes med data parallelt, men prisen er behovet for "skraldsamling", det vil sige fjernelse af gamle og ikke længere nødvendige versioner af dataene.
Transaktionsbehandling har til formål at vedligeholde et computersystem (normalt en database eller nogle moderne filsystemer ) i en kendt, konsistent tilstand ved at sikre, at alle operationer, der finder sted på systemet, er indbyrdes afhængige og enten alle er gennemført med succes eller fuldstændigt og annulleret med succes. [5]
Overvej for eksempel en typisk banktransaktion, der involverer at flytte $700 fra en kundes opsparingskonto til en kundes checkkonto. Denne transaktion er en enkelt transaktion for banken, men den omfatter mindst to separate transaktioner i computertermer: $700 krediteres indbetalingskontoen, og $700 krediteres checkkontoen. Hvis debettransaktionerne lykkes, og kredittransaktionerne ikke er det (eller omvendt), vil bankens bøger ikke have en saldo ved dagens slutning. Derfor skal der være en måde at sikre, at begge operationer enten lykkes eller mislykkes, så der aldrig opstår inkonsistens i bankens database som helhed. Transaktionsbehandling er designet til at give dette.
Transaktionsbehandling giver mulighed for automatisk at koble flere separate transaktioner sammen som en enkelt, udelelig transaktion. Transaktionsbehandlingssystemer sikrer, at enten alle operationer i en transaktion gennemføres uden fejl, eller ingen af dem. Hvis nogle af operationerne er gennemført, men med fejl, og andre uden, instruerer transaktionsbehandlingssystemet at "rulle tilbage" alle transaktioner af transaktionen (inklusive vellykkede), hvilket betyder at slette alle spor af operationen og gendanne systemet til en konsekvent kendt tilstand, der var før starten af transaktionsprocessen. Hvis alle operationer af transaktionen er gennemført med succes, så er transaktionen begået i systemet, og alle ændringer i databasen bliver "permanente" ( committed ); transaktioner kan ikke fortrydes, hvis de allerede er foretaget.
Transaktionsbehandling beskytter mod hardware- og softwarefejl, der kan efterlade en transaktion delvist afsluttet, hvor systemet efterlades i en ukendt, inkonsekvent tilstand. Hvis et computersystem svigter midt i en transaktion, sikrer transaktionsbehandlingen, at alle transaktioner i eventuelle ikke-forpligtede (det vil sige ikke fuldt behandlede) transaktioner rulles tilbage.
Transaktioner er arrangeret i streng kronologisk rækkefølge. Hvis transaktion N+1 har til hensigt at berøre den samme del af databasen som transaktion N, starter transaktion N+1 ikke, før transaktion N indtræffer. Forud for enhver transaktion skal alle andre transaktioner, der berører samme del af systemet, også gennemføres; der kan ikke være "huller" i rækkefølgen af tidligere transaktioner. [6] [5]
De grundlæggende principper for alle transaktionsbehandlingssystemer er de samme. Terminologien kan dog variere fra et transaktionsbehandlingssystem til et andet, og de termer, der bruges nedenfor, er ikke nødvendigvis universelle. [7]
Rollback ( eng. rollback )Transaktionsbehandlingssystemer sikrer databaseintegritet ved at registrere databasens mellemtilstand, før den ændres, og derefter bruge disse registreringer til at gendanne databasen til en kendt tilstand, hvis transaktionen ikke kan udføres. For eksempel laves kopier af information i en database, før den blev ændret af en transaktion, af systemet før transaktionen, der kan foretage ændringer (nogle gange kaldet før billede ). Hvis en del af transaktionen mislykkes, før den er begået, bruges disse kopier til at gendanne databasen til den tilstand, den var i, før transaktionen begyndte ( Rullback ). [6]
Kør ( eng. rollforward )Du kan også føre en separat log over alle databaseændringer (nogle gange kaldet efter billeder ); dette kræver ikke en tilbagerulning af mislykkede operationer, men det er nyttigt til at opdatere databasen i tilfælde af en databasefejl, hvorfor nogle transaktionsbehandlingssystemer har denne funktion. Hvis databasen fejler fuldstændigt, skal den gendannes fra den sidste sikkerhedskopi. Sikkerhedskopier vil ikke afspejle handlinger, der er udført efter den blev oprettet. Men når databasen er blevet gendannet, kan efterbilleder- loggen anvendes på databasen ( rollforward ) for at opdatere den. Alle transaktioner, der er i gang på tidspunktet for fejlen, kan rulles tilbage. Resultatet er en database i en kendt konsistent tilstand, der inkluderer resultaterne af alle transaktioner, der er begået indtil fejlpunktet. [6]
Gensidig blokering ( eng. deadlocks )I nogle tilfælde kan to transaktioner, under deres behandling, forsøge at få adgang til den samme del af databasen på samme tid, på en måde, der forhindrer dem i at blive gennemført. For eksempel kan transaktion A få adgang til del X af databasen, og transaktion B kan få adgang til del Y af databasen. Hvis transaktion A på dette tidspunkt forsøger at få adgang til del Y af databasen, mens transaktion B forsøger at få adgang til del X, opstår der en deadlock-situation, og ingen transaktion kan fortsætte. Transaktionsbehandlingssystemer er designet til at opdage sådanne situationer. Typisk fortrydes begge transaktioner og rulles tilbage, og derefter startes de automatisk i en anden rækkefølge, så dødvandet ikke opstår igen. Eller nogle gange er det kun én af de fastlåste transaktioner, der rulles tilbage, rulles tilbage og forsøges automatisk igen efter en kort forsinkelse.
Deadlocks kan forekomme mellem tre eller flere transaktioner. Jo flere transaktioner der er forbundet, jo sværere er de at opdage. Transaktionsbehandlingssystemer har endda sat en praktisk grænse for de dødvande, de kan opdage.
| Database | |
|---|---|
| Begreber |
|
| Objekter | |
| Nøgler | |
| SQL | |
| Komponenter | |