Ændringslogning er en DBMS -funktion , der gemmer de nødvendige oplysninger for at gendanne databasen til en tidligere konsistent tilstand i tilfælde af logiske eller fysiske fejl.
I det enkleste tilfælde består ændringslogning i sekventiel skrivning til ekstern hukommelse af alle ændringer udført i databasen. Følgende oplysninger er registreret:
De oplysninger, der genereres på denne måde , kaldes databaseændringsloggen . Loggen indeholder transaktionens start- og slutmærker og kontrolpunkters acceptmærker (se nedenfor).
I en tilbageskrivnings-DBMS mærkes eksterne hukommelsesdatablokke med sekvensnummeret for den sidste ændring, der blev udført på den datablok. I tilfælde af en systemfejl giver dette mærke dig mulighed for at finde ud af, hvilken version af datablokken det lykkedes at nå den eksterne hukommelse.
En tilbageskrivnings-DBMS udfører kontrolpunkter med jævne mellemrum. Under denne proces overføres alle uskrevne data til ekstern hukommelse, og et checkpoint-acceptmærke skrives til loggen. Derefter kan indholdet af den log, der er skrevet før checkpointet, slettes.
Ændringsloggen kan ikke skrives direkte til ekstern hukommelse, men akkumuleres i operationel hukommelse. Hvis transaktionen bekræftes, venter DBMS på, at resten af loggen bliver skrevet til ekstern hukommelse. Det er således garanteret, at alle data, der indtastes efter bekræftelsessignalet, vil blive overført til ekstern hukommelse uden at vente på omskrivning af alle ændrede blokke fra diskcachen . DBMS venter på, at resten af loggen bliver skrevet på samme måde, når der udføres et kontrolpunkt.
I tilfælde af en logisk fejl eller et rollback-signal for en transaktion scannes loggen baglæns, og alle registreringer af den rullede tilbage-transaktion hentes fra loggen frem til starten af transaktionen. Ifølge de udtrukne oplysninger udføres handlinger, der annullerer transaktionens handlinger, og kompenserende poster skrives til loggen . Denne proces kaldes rollback .
I tilfælde af en fysisk fejl , hvis hverken loggen eller selve databasen er beskadiget, udføres rollforward-processen . Loggen scannes i fremadgående retning, startende fra det forrige kontrolpunkt. Alle poster hentes fra loggen op til slutningen af loggen. Information hentet fra loggen indtastes i eksterne hukommelsesdatablokke, der har et ændringsnummermærke, der er mindre end det, der er registreret i loggen. Hvis kørslen mislykkes igen, genstartes logscanningen fra begyndelsen, men gendannelsen fortsætter faktisk, hvor den slap.
For at øge fejltolerancen kan DBMS skrive flere identiske kopier af ændringsloggen på samme tid. Hvis en af kopierne af loggen bliver utilgængelig i tilfælde af en fejl, vil DBMS gendanne databasen ved hjælp af en af de tilgængelige kopier. Denne strategi kaldes changelog- multipleksing .
Som regel overskrives ændringsloggen først, så snart den eksterne hukommelsesplads, der er afsat til den, løber tør. Dette giver dig mulighed for at gendanne databasen til en opdateret og konsistent tilstand, men kun hvis selve databasen ikke går tabt, selvom den ikke er opdateret.
I nogle informationssystemer skal genopretning dog garanteres, selvom hele databasen går tabt. I sådanne systemer sikkerhedskopieres databasen med jævne mellemrum , og ændringsloggen opdeles i successive segmenter og arkiveres. Inden start af backup udføres et kontrolpunkt og loggen opdeles i segmenter skrevet før og efter start af backup. Ved afslutningen af backup-processen slettes al ændringslog skrevet før starten af backup. Med en sikkerhedskopi og alle arkiverede ændringslogs siden sikkerhedskopien blev taget, kan databasen således gendannes til en opdateret tilstand, selvom alle datablokke er gået tabt.
Ikke alle rigtige DBMS'er følger det klassiske changelog-implementeringsskema, til dels af effektivitetshensyn.
Oracle Database bruger to typer ændringslogs: en cyklisk online-redo-log ( redo-log ) og en arkiveret redo-log ( arkiv-log ), hvor poster fra den første log overføres, når den første gennemgår en fuld cyklus. Begge logfiler skrives til permanente medier, data om operationen kommer ind i online-loggen i det øjeblik, før dataene er forpligtet til ikke-flygtige medier, arkivloggen fungerer kun i en speciel tilstand til at understøtte databaselogarkivering ( archivelog ). Oplysninger fra ændringsloggene bruges ikke til at rulle tilbage transaktionen, men bruges til gendannelse. Gendannelsesprocessen udføres af administratoren ved hjælp af en databasesikkerhedskopiering og sekventiel anvendelse af arkiv- og gentaglogfiler til den.
Rollback-oplysninger ( fortryd log ) er grupperet i rollback-segmenter, der vedligeholdes af en speciel type tablespace . Disse data logges også igen, hvilket betyder, at de er beskyttet på samme måde som andre data i databasen. I tilfælde af en tilbagerulning bruges loggen til at gendanne registreringen af transaktionen, der ændres. Derudover bruges information fra redo-loggen til at opretholde læseintegritet for at give adgang til snapshot af data, der blev taget på tidspunktet for hentning [1] .
I Informix DBMS er ændringsloggen en diskplads opdelt i dele kaldet transaktionslogfiler (disse filer har intet at gøre med filer på filsystemet) eller logisk log . Hvorvidt ændringer skrives til denne log afhænger af, om databasen er i ikke-journaliseret, buffer-logget eller ikke-buffer-logget tilstand. Alle ændringer går først til de logiske logbuffere, og derefter tømmes de til transaktionsloggen afhængigt af databasens logningstilstand.
Til genopretning i tilfælde af fejl, den såkaldte. den fysiske journal , som sidebilleder kopieres til, inden de ændres. I tilfælde af en serverfejl vil ikke-forpligtede data blive gendannet under opstart.
| Database | |
|---|---|
| Begreber |
|
| Objekter | |
| Nøgler | |
| SQL | |
| Komponenter | |