Ändringsloggning är en DBMS -funktion som lagrar den information som behövs för att återställa databasen till ett tidigare konsekvent tillstånd i händelse av logiska eller fysiska fel.
I det enklaste fallet består ändringsloggningen i sekventiell skrivning till externt minne av alla ändringar som görs i databasen. Följande information registreras:
Informationen som genereras på detta sätt kallas databasändringsloggen . Loggen innehåller transaktionsstart- och slutmärken, och kontrollpunktsgodkännandemärken (se nedan).
I en återskrivnings-DBMS är externa minnesdatablock taggade med sekvensnumret för den senaste ändringen som utfördes på det datablocket. I händelse av ett systemfel låter detta märke dig ta reda på vilken version av datablocket som lyckades nå det externa minnet.
En återskrivnings-DBMS utför kontrollpunkter med jämna mellanrum. Under denna process överförs all oskriven data till ett externt minne, och ett godkännandemärke för kontrollpunkt skrivs till loggen. Därefter kan innehållet i loggen som skrivits före kontrollpunkten raderas.
Ändringsloggen får inte skrivas direkt till externt minne, utan ackumuleras i driftminnet. Om transaktionen bekräftas, väntar DBMS på att resten av loggen skrivs till externt minne. Således är det garanterat att all data som matas in efter bekräftelsesignalen kommer att överföras till externt minne, utan att vänta på omskrivning av alla ändrade block från diskcachen . DBMS väntar på att resten av loggen skrivs på samma sätt när en kontrollpunkt utförs.
I händelse av ett logiskt fel eller en återställningssignal för en transaktion skannas loggen bakåt och alla register över den återställda transaktionen hämtas från loggen fram till transaktionens början. Enligt den extraherade informationen utförs åtgärder som avbryter transaktionens åtgärder, och kompenserande poster skrivs till loggen . Denna process kallas återställning .
I händelse av ett fysiskt fel , om varken loggen eller själva databasen är skadad, utförs rollforward- processen . Loggen skannas i riktning framåt, med början från föregående kontrollpunkt. Alla poster hämtas från loggen fram till slutet av loggen. Information som hämtas från loggen läggs in i externa minnesdatablock som har en ändringsnummermarkering som är mindre än den som registrerats i loggen. Om körningen misslyckas igen kommer loggsökningen att starta om från början, men återställningen kommer faktiskt att fortsätta där den slutade.
För att öka feltoleransen kan DBMS skriva flera identiska kopior av ändringsloggen samtidigt. Om, i händelse av ett fel, en av kopiorna av loggen blir otillgänglig, kommer DBMS att återställa databasen med någon av de tillgängliga kopiorna. Denna strategi kallas changelog multiplexing .
Som regel skrivs ändringsloggen över först, så snart det tilldelade externa minnesutrymmet tar slut. Detta gör att du kan återställa databasen till ett uppdaterat och konsekvent tillstånd, men bara om själva databasen inte går förlorad, även om den inte är uppdaterad.
Men i vissa informationssystem måste återhämtning garanteras även om hela databasen går förlorad. I sådana system säkerhetskopieras databasen regelbundet och ändringsloggen delas upp i successiva segment och arkiveras. Innan säkerhetskopieringen startar utförs en kontrollpunkt och loggen delas upp i segment som skrivs före och efter start av säkerhetskopieringen. I slutet av säkerhetskopieringen raderas all ändringslogg som skrivits innan säkerhetskopieringen startade. Således, med en säkerhetskopia och alla arkiverade ändringsloggar sedan säkerhetskopieringen togs, kan databasen återställas till ett uppdaterat tillstånd även om alla datablock har förlorats.
Inte alla riktiga DBMS följer det klassiska förändringsloggimplementeringsschemat, delvis av effektivitetsskäl.
Oracle Database använder två typer av ändringsloggar: en cyklisk redo-logg online ( redo log ) och en arkiverad redo log ( arkivlogg ), där poster från den första loggen överförs när den första går igenom en hel cykel. Båda loggarna skrivs till permanent media, data om operationen kommer in i onlineloggen i ögonblicket innan data överförs till icke-flyktiga medier, arkivloggen fungerar endast i ett speciellt läge för att stödja databasloggarkivering ( archivelog ). Information från ändringsloggarna används inte för att återställa transaktionen, utan används för återställning. Återställningsprocessen utförs av administratören med hjälp av en databassäkerhetskopiering och sekventiell tillämpning av arkiv- och gör om loggar till den.
Återställningsinformation ( ångra logg ) grupperas i återställningssegment som underhålls av en speciell typ av tabellutrymme . Denna data loggas också om, vilket innebär att den är skyddad på samma sätt som annan data i databasen. I händelse av en återställning används loggen för att återställa posten för transaktionen som ändras. Dessutom används information från redo-loggen för att upprätthålla läsintegriteten för att ge tillgång till ögonblicksbilden av data som togs vid tidpunkten för hämtningen [1] .
I Informix DBMS är ändringsloggen ett diskutrymme uppdelat i delar som kallas transaktionsloggfiler (dessa filer har inget att göra med filer i filsystemet) eller logisk logg . Huruvida ändringar skrivs till den här loggen beror på om databasen är i icke-journaliserat, buffrat-loggat eller obuffrat-loggat läge. Alla ändringar går först till de logiska loggbuffertarna och sedan rensas de till transaktionsloggen beroende på databasloggningsläget.
För återhämtning vid fel, den sk. den fysiska journalen till vilken sidbilder kopieras innan de ändras. I händelse av ett serverfel återställs oengagerad data under uppstart.
| Databas | |
|---|---|
| Begrepp |
|
| Objekt |
|
| Nycklar | |
| SQL |
|
| Komponenter | |