SE500656C2 - System för backuptagning i en distribuerad databas - Google Patents

Description

500 656 2 användare att uppdatera databasen och först vid commit, dvs den transaktionsoperation, som används av ett program eller operatör för att indikera att en aktuell transaktion slutförts och att dess verkningar skall kvarstå, växlas den uppdaterade kopian in och satta lås släppes.

För kopieobjekt eller objekt som ej skall underkastas backup gäller att de raderas vid återstart av databasen med omladdning.

Teknikens ståndpunkt.

Inom den aktuella tekniken är det ett krav att databassys- temet inte får stanna vid backuptagning.

I US-patentskriften 4 077 059 beskrivs ett system med ett hierarkiskt minne med två minnesenheter på varje nivå. En av enheterna innehåller alla data på den nivån. Den andra enheten innehåller endast förändringarna som har gjorts i dessa data.

Genom duplicering och återhämtning endast av förändrade data, minskas mängden data som måste transporteras vid fel.

Patentskriften ifråga beskriver inte ett databassystem i egentlig mening. Det finns ingen backupfunktion, som aktiveras genom en central hanterare, vilken har information om systemet och synkroniserar funktionen.

US,A,4 714 995 beskriver ett integrerat datorsystem med tills hörande databaser. Integrering sker av datorsystem som har behov av att dela vissa gemensamma dataelement, där varje datorsystem har en databas. Syftet är att utföra kontrollerad kopiering.

Relationer och transaktioner tillåts sträcka sig över flera databaser.

Redogörelse för uppfinningen.

Ett syfte med uppfinningen är att åstadkomma ett system av inledningsvis definierat slag, med vilket i databasen trans- aktioner tillåts utföra operationer mot databasen samtidigt som backup tas.

Detta har åstadkommits genom att vid systemet enligt upp- finningen alla data i databasen struktureras såsom tillhörande en av flera logiska databaser, varvid en logisk databas kan, men inte behöver, sträcka sig över flera datorer, backupfunktionen för en viss logisk databas aktiveras genom 500 656 3 att meddelande sänds till en central backuphanterare, vilken har information om vilka datorer som det aktuella backupsystemet sträcker sig över och synkroniserar backupfunktionen över dat- orgräns, vilken synkronisering innefattar att lokala databashan- terare informeras om att backup kommer att påbörjas, och att en ny transaktionslogg skapas, i vilken alla transaktioner som inte uppnått commit-tillstånd och som därför inte ska ingå i backupen loggas, varpå backup kommer att innehålla endast förändringar av transaktioner i den gamla transaktionsloggen.

Enligt en fördelaktig utföringsform sker backupfunktionen för en viss logisk databas periodiskt, eller vid behov av operatör.

Företrädesvis innefattar synkroniseringen att den centrala backuphanteraren beordrar de lokala databashanterarna att sätta en backupflagga i den berörda logiska databasen, vilken informe- rar de lokala databashanterarna om att backup kommer att på- börjas och gör att den ändrar beteende vad gäller lagring av objekt som ligger i den aktuella logiska databasen, varpå efter satt backupflagga de lokala databashanterarna kvitterar genom att meddela den centrala backuphanteraren att detta är utfört, Därvid kan, när alla de lokala databashanterarna kvitterat, den centrala backuphanteraren beordra alla lokala logghanterare för de aktuella procesorerna att skapa den nya transaktionslog- gen.

Den nya transaktionsloggen kan därvid företrädesvis innefatta en "BackupSynch"-variabel, som kan anta värdena "Include" eller "Exclude", och vars värde används av den lokala data- bashanteraren och av lokala backuphanterare till att bestämma om objekt skall ingå i en backup eller inte, varvid den centrala backuphanteraren beordrar de lokala logghanterarna att ändra nämnda variabel i den nya transaktionsloggen till "Exclude", in- nebärande att dess objekt inte skall ingå i backupen.

"BackupSynch"-variabeln kan hämtas av en koordinator för en transaktion i samband med att den skriver "COMIT" i transak- tionsloggen, innebärande att transaktionen uppnått commit-till- stånd, och sänder sedan "BackupSynch"-variabelns värde och "COMMIT"-meddelandet till alla deltagartransaktioner, vilka i sin tur distribuerar ut "ßackupsynch"-värdet till de olika databasobjekten, varigenom alla objekt i transaktionen får samma "BackupSynch"-värde och kommer att inkluderas alt. exkluderas SGU 656 från backupen.

Enligt en föredragen utföringsform är en räknare anordnad att ange antal pågående transaktioner i commit-tillstånd mot den gamla transaktionsloggen, varvid synkroniseringen innefattar att när räknaren är lika med 0, meddelas den centrala backupfunktio- nen att det inte finns någon koordinator för någon transaktion i aktuell dator som vill att uppdateringar skall ingå i backupen.

Vid ytterligare en föredragen utföringsform kommer, efter det att de lokala logghanterarna har meddelats om att den lokala databashanteraren har gjort alla förändringar från transaktioner som skall ingå i backupen synliga i databasen, kopieringen av objekt till backuparean att påbörjas.

Därvid kan företrädesvis synliggörandet innefatta synkroni- sering mellan den lokala databashanteraren, backup-hanteraren och logghanteraren.

Denna synkronisering kan därvid göras genom att den lokala logghanteraren håller reda på antal transaktioner som finns i den gamla transaktionsloggen, antal transaktioner räknas ner när transaktionen skriver END-TRANSACTION i den gamla transak- tionsloggen, samt END-TRANSACTION skrivs när den lokala data- bashanteraren har utfört förändringarna i databasen och meddelat transaktionen detta.

Företrädesvis beordrar den centrala backuphanteraren, när antal transaktioner i den gamla transaktionsloggen är 0 i alla lokala logghanterare, alla lokala backuphanterare att börja kopiering av de objekt som skall ingå i backupen till backupare- an, vilka objekt har backupmarkerats av den lokala datbashante- raren i och med att den bytte beteende när backupflaggan sattes.

Enligt en ytterligare föredragen utföringsform sker kopiering av objekt till backuparean, och den gamla backupen sparas på primärminne tills den nya backupen är slutförd, varpå den gamla backupen paketeras och lagras på sekundärminne.

Figgrbegkrivning.

Utföringsexempel av uppfinningen skall nu beskrivas närmare med hänvisning till bifogade ritningar, på vilka fig. 1 är avsedd att schematiskt åskådliggöra en lösning för primärminnesbackup av en databas, vid vilken uppfinningen kan tillämpas, 500 656 5 fig. 2 - 8 är flödesschemor åskådliggörande backuptagnings- funktionen vid en databas enligt fig. 1, fig. 9 i liknande vy som fig. 1 åskådliggör situationen i databasen i ett slutmoment av en enligt uppfinningen utförd backup, fig. 10 schematiskt visar en databas, vilken sträcker sig över två datorer, varvid situationen straxt före start av en backup visas, fig. 11 förstorat och mera detaljerat visar databas- och logsituationen i en av datorerna enligt fig. 3 vid en senare tidpunkt av backupen, samt fig. 12 - 14 är tabeller, som åskådliggör åtgärder, som kan krävas i samband med den med hänvisning till fig. 10 och 11 be- skrivna backupen.

Föredragna utföringsformer.

Det ovan definierade fenomenet logisk databas kan på rit- ningarna även omväxlande komma att benämnas RecDB, vilket är en förkortning för Recovery Data Base.

Figur 1 är uppdelad i två avdelningar 2 och 4, som schema- tiskt representerar en databasarea resp. backuparea i en dators primärminne. I anslutning till vardera arean finnes en katalog 6 resp. 8, som innehåller en förteckning över objekt med samhöran- de klasser, som lagras i databasen. Motsvarande kataloger som katalogerna 6 och 8 kan nedan och på senare ritningsfigurer även komma att kallas LID-tabell. Medelst en pekare 10 resp. 12 väljs med kännedom om tillhörande klass och nyckel, objekt som skall underkastas en operation.

Figur 1 visar nu databas- och backuparea 2 resp. 4 efter diverse uppdateringar av databasobjekt. I figuren identifieras objekt som uppdaterats sedan senaste backup med primtecken.

Sedan senaste backup har objekt A och C uppdaterats till A' och C'. Objekt B och D har ej uppdaterats. Backuparean är skriv- skyddad men tillåter läsningar av data. Närmare bestämt finns endast de uppdaterade objekten A' och C' lagrade i databasarean 2,.medan objekten A, B, C och D finns lagrade i backuparean 4, och databasen pekar ut objekten B och D i backuparean 4, antytt med pilar 14 och 16.

Enligt ett av uppfinningens kännetecken struktureras alla 5^O 6 f O Lïl 6 data i databasen såsom tillhörande en av flera logiska databa- ser, varvid en logisk databas kan, men inte behöver, sträcka sig över flera datorer.

Eftersom en sådan databas, såsom ovan nämnts, kan (men behöver inte) sträcka sig över flera datorer, kommer backup- tagning av densamma att vara distribuerad.

Enligt ett av uppfinningens syften skall transaktioner tillåtas utföra operationer mot databasen samtidigt som backup tas. Inom transaktionen kommer objekt att uppdateras, skapas eller tas bort vilket resulterar i att många olika versioner av ett objekt kommer att kunna finnas under den tid som backuptag- ning pågår. Backuptagningsfunktionen måste därför få information om vilken version av ett objekt som skall ingå i backupen.

Detta skall nu i första hand förklaras närmare med hänvisning till de i fig. 2 - 8 visade flödesschemorna. Av fig. 2 framgår till att börja med att backupfunktionen för en viss logisk databas aktiveras av en användare 30 genom att ett meddelande 32 att skapa backup sänds till en central backuphanterare 34, vars mottagning av meddelandet markeras vid 36. Den centrala back- uphanteraren har information om vilka datorer som det aktuella backupsystemet sträcker sig över och synkroniserar backupfunk- tionen över datorgräns, vilket startar med att tillståndet TILLSTÄND=SYNKBACKUP, markerat vid 38, intas. Synkroniseringen innefattar att lokala databashanterare, av vilka en markeras vid 40, informeras om att backup kommer att påbörjas, och beordras sätta backupflagga. En ny transaktionslogg skapas, i vilken alla transaktioner som inte uppnått commit-tillstånd och som därför inte ska ingå i backupen loggas. Därpå genomförs backup endast på förändringar av transaktioner i den gamla transaktionsloggen.

Mera i detalj kan synkroniseringen innebära följande: 1. Den centrala backuphanteraren 34 instruerar, markerat vid 42, de lokala databashanterarna 40 att sätta backupflagga i den berörda logiska databasen. Instruktionens mottagande markeras vid 44. Denna instruktion skall kvitteras. Backupflaggan in- formerar de lokala databashanterarna om att backup kommer att påbörjas och gör att de lokala databashanterararna ändrar be- teende vad gäller lagring av objekt som ligger i den aktuella logiska databasen. 2. De lokala databashanterarna sätter backupflaggan och 500 656 7 meddelar, markerat vid 46, att det är utfört. Meddelandets mottagande hos den centrala backuphanteraren markeras vid 48. 3. En tidsövervakning av att alla lokala databashanterare kvitterar sker med de steg, som antyds vid 50 i fig. 2, samt i fig. 3. När alla de lokala databashanterarna kvitterat instrue- rar, markerat vid 52, den centrala backuphanteraren lokala logghanterare 54 att utföra följande moment. Momentens utförande antyds därvid genom de vid 56 visade stegen. a) Skapa en ny transaktionslogg där alla transaktioner som inte kommit till commitfasen och som därför inte ska ingå i backupen kommer att loggas. b) Ändra en "ßackupsynch"-variabel, som ingår i transak- tionsloggen till "Exclude" (se nedan). c) När en räknare, som anger antal pågående transaktioner i commit-tillstånd mot den gamla transaktionsloggen (den tran- saktionslogg, som förelåg vid start av moment enligt punkt 1 ovan) är lika med 0, meddela den centrala backupfunktionen att det inte finns någon koordinator för någon transaktion i aktuell dator som vill att uppdateringar skall ingå i backupen. Detta meddelandes utsändning markeras vid 58, och dess mottagning vid 60. "ßackupsynch"-variabeln kan inta värdena "Include/Exclude", och dess värde skall användas av den lokala databashanteraren och av den lokala backuphanteraren till att bestämma om ett objekt skall ingå i backupen eller inte. "BackupSynch"-variabeln hämtas av koordinatorn 30 för transaktionen i samband med att den skriver "COMMIT" i transaktionsloggen, markerat vid 62 i fig. Sa och vid 64 i fig. 5b. Utsändningen och mottagandet av "BackupSynch"-variabeln markeras vid 66 i fig. Sb resp. 68 i fig. 5a. Koordinator sänder sedan "BackupSynch"-värdet och Commit-meddelandet till alla deltagartransaktioner. Dessa dis- tribuerar i sin tur ut "BackupSynch"-värdet till de olika data- basobjekten. På så sätt ser man till att alla objekt i trans- aktionen får samma "BackupSynch"-värde och kommer att inkluderas alt. exkluderas från backupen.

Under hela synkroniseringsfasen kommer det att finnas två transaktionsloggar: -en gammal transaktionslogg som innehåller transaktioner vars förändringar av databasen kommer att speglas i backupen, och 6 LN 5GB 6 8 -en ny transaktionslogg som innehåller transaktioner som befann sig i andra faser än COMMIT när backuptagning startade och vars förändringar av databasen inte kommer att speglas av backupen.

Efter det att de lokala logghanterarna har meddelats om ändring i loggen är den ovan diskuterade synkroniseringen klar.

Kopieringen av objekt till backuparean kommer dock inte att börja förrän den lokala databashanteraren har gjort alla föränd- ringar från transaktioner som skall ingå i backupen synliga i databasen. Detta moment kräver därför också en andra synkroni- sering, nämligen mellan lokal databashanterare, lokal backuphan- terare och lokal logghanterare. Denna synkronisering bygger på att den lokala logghanteraren håller reda på antal transaktioner i commit-tillstånd, som finns i den gamla transaktionsloggen.

Antal transaktioner räknas ner när logghanteraren erhåller en instruktion att skriva "END-TRANSACTION" i den gamla transak- tionsloggen. "END-TRANSACTION" skrivs när den lokala databashan- teraren har utfört förändringarna i databasen och meddelat transaktionen detta. De sistnämnda stegen antyds i fig. 7a och b.

Sammanfattningsvis innebär den andra synkroniseringen att: 1. Den lokala databashanteraren utför de förändringar som ingår i transaktionen och meddelar transaktionen detta. 2. Transaktionen skriver "END-TRANSACTION" i transaktions- loggen. 3. De lokala logghanterarna räknar ner räknaren, som anger antal transaktioner i commit-tillstånd i transaktionsloggen och meddelar den centrala backup-hanteraren när räknarvärdet är 0.

När antal transaktioner i den gamla transaktionsloggen är 0 i alla lokala logghanterare instruerar den centrala backuphantera- ren alla lokala backuphanterare att börja kopiering av de objekt som skall ingå i backupen till backuparean. Instruktionens utsändning liksom de steg, som föregår denna antyds i fig. 4. De ifrågavarande objekten har enligt fig. 6 backupmarkerats i LID- tabellen av den lokala databashanteraren i och med att den senare bytte beteende när backupflaggan sattes. Den lokala databashanterarens beteende i samband med backup framgår av fig. 6, 8 och 9 och beskrivs närmare nedan.

Kopiering av objekt kommer att ske till backuparean. Av 500 656 9 säkerhetsskäl kommer den gamla backupen att finnas kvar på pri- märminnet tills den nya backupen är slutförd. Sedan kommer den gamla backupen att paketeras och lagras på sekundärminne. Under den tid som det tar att skapa den nya backupen och paketera den gamla kommer det att finnas två backupversioner på primärminnet, vilket inte innebär att alla objekt är dubblerade utan endast accesstrukturen eller de objekt som är specifika för respektive backup. Situationen åskådliggörs i fig. 9, där samma element som i fig. 1 erhållit samma hänvisningsbeteckningar. Figur 9 kommer i själva verket att ändras till överensstämmelse med fig. 1 efter avslutade backupmoment.

Med hänvisning till fig. 10 och 11 skall nu ett utföringsex- empel av backupfunktionen beskrivas. Närmare bestämt utgår exemplet från att backup skall tas vid tiden T=0 av en databas 100, som sträcker sig över två datorer P1 resp. P2. Tillhörande backuparea och loggarea visas ej. Vid T=0 finns två transaktio- ner T1 och T2, som accessar databasen. I datorn P1 får därvid dessa transaktioner bilda koordinator, markerat med K, och i datorn P2 deltagare, markerat med D. Figur 10 visar situationen vid T=0, och fig. 11 visar en förstorad och mera detaljerad bild av ifrågavarande databas 100 i datorn P1.

Initieringen av backup sker på följande sätt. Det första som händer vid T=0 är att, enligt 42 i fig. 2, den centrala backup- hanteraren 118 i datorn P1 kommer att beordra de lokala databas- hanterarna i P1 och P2, av vilka den i P1 antyds vid 120, att sätta upp backupflaggan i respektive databashanterare, av vilka den i P1 visas vid 122. Detta illustreras i Fig. 11 av att i en katalog 124 över tillämpningar, i figuren benämnd "RecDB-Cata- log" (RecDB = Recovery Data Base), backupflaggan är satt till 1.

Sedan ändras, enligt 52 och 56 i fig. 2, "BackupSynch"-varia- belns värde i Plzs och P2:s logg från "include", visat vid 126 för datorn P1, till "exclude". En ny transaktionslogg skapas, jfr 56 i fig. 2, vilket för datorn P1 antyds i fig. 11 vid 128.

Vid TO finns två transaktioner som arbetar mot databasen, nämligen: -transaktion T1 som befinner sig i commitfasen och som ska uppdatera objekt B och ta bort objekt D i dator P1, samt upp- datera objekt F i dator P2. -transaktion T2 som befinner sig i ínitialfasen ska skapa 590 656 10 objekt E i dator P1 och uppdatera objekt G i dator P2.

Exempel på synkronisering av transaktioner mot backup kommer nu att beskrivas.

Eftersom transaktion T1 är en koordinerande transaktion skriver den, enligt 64 i fig. 5b, COMMIT i den gamla transak- tionsloggen, antydd vid 130 i fig. 11, och hämtar "ßackupsynch = Include", jfr 68 i fig. 5a. Backupsynch variabeln skickas till deltagare T1 i dator P2 i samband med GLOBAL-COMMIT. Sedan kommer transaktionen T1 att anropa olika metoder i databashante- raren för att göra de ändringar, som transaktionen har utfört mot data, synliga i databasen. I det föreliggande exemplet kommer transaktion T1 att vilja lagra objekt B' och ta bort objekt D. Generellt för alla typer av anrop (när backupflaggan är satt) gäller att databashanteraren jämför värdet i objektets Backupsynch variabel med värdet för samma variabel i LID-tabel- lens ingång för objektet. Beroende på jämförelsens utfall och vilken metod som objektet anropade kommer databashanteraren att utföra någon av de åtgärder som beskrivs i tabellerna i fig. 12- 14. I fig. 12 hanteras därvid uppdatering av objekt, i fig. 13 skapande av nytt objekt, samt i fig. 14 avlägsnande av objekt.

För objekt B, som skulle uppdateras gäller därvid det andra fallet i spalt 2, eftersom både backupvärdet i databasposten och i LID-tabellen är include. För objekt D gäller i fig. 14 likaså fall 2 i spalt 2 av samma orsak som i föregående fall. Även objekt E skall ingå i backupen.

När databashanteraren har gjort transaktion T1:s operationer synliga i databasen kommer den att meddela transaktionen som i sin tur meddelar loggen. Loggen räknar ner antalet transaktioner i den gamla commitloggen och eftersom den nu blir 0 meddelas den centrala backupfunktionen, jfr 58, 60 i fig. 2, om att kopiering av objekt från databasarean till backuparean kan starta. När de deltagande lokala logghanterarna meddelat att de kan starta backup så beordrar den centrala backupfunktionen alla lokala backuphanterare att starta dumpning till backup, såsom framgår av de i fig. 4 ingående stegen.

För dumpning av objekt till backuparean gäller följande med hänvisning till fig. 8. De lokala backup-hanterarna kommer att gå igenom LID-tabellen, markerat vid 140, och kontrollera värdet på Backupsynch variabeln, markerat vid 142. Om den är lika med 500 656 ll "Include" kommer objektet att kopieras till backuparean om den är lika med "Exlude" kopieras inte objektet men variabelns värde sätts till "Include" som förberedelse till nästa backup, jfr. stegen 144 och 146. När alla objekt i LID-tabellen har blivit kopierade kommer objekten i backupbufferten att kopieras till backuparean. Sedan kommer backup-hanteraren att sätta backup- flaggan för databasen till 0 så att databashanteraren kan återgå till vanligt beteende.

Claims (12)

500 656 12 Patentkrav.

1. System för backuptagning i en distribuerad realtidsdatabas i drift, som ligger på primärminne, kännetecknat av att alla data i databasen struktureras såsom tillhörande en av flera logiska databaser, varvid en logisk databas kan, men inte behöver, sträcka sig över flera datorer, backupfunktionen för en viss logisk databas aktiveras genom att meddelande sänds till en central backuphanterare, vilken har information om vilka datorer som det aktuella backupsystemet sträcker sig över och synkroniserar backupfunktionen över dat- orgräns, vilken synkronisering innefattar att lokala databashan- terare informeras om att backup kommer att påbörjas, och att en ny transaktionslogg skapas, i vilken alla transaktioner som inte uppnått commit-tillstånd och som därför inte ska ingå i backupen loggas, varpå backup kommer att innehålla endast förändringar av transaktioner i den gamla transaktionsloggen.

2. System enligt krav l, kännetecknat av att aktiveringen av backupfunktionen för en viss logisk databas sker periodiskt, eller vid behov av operatör.

3. System enligt krav 1 eller 2, kännetecknat av att synkroniseringen innefattar att den centrala backuphanteraren beordrar de lokala databashanterarna att sätta en backupflagga i den berörda logiska databasen, vilken informerar de lokala data- bashanterarna om att backup kommer att påbörjas och gör att den ändrar beteende vad gäller lagring av objekt som ligger i den aktuella logiska databasen, varpå efter satt backupflagga de lokala databashanterarna kvitterar genom att meddela den cen- trala backuphanteraren att detta är utfört,

4. System enligt krav 3, kännetecknat av att, när alla de lokala databashanterarna kvitterat, beordrar den centrala back- uphanteraren alla lokala logghanterare för de aktuella proceso- rerna att skapa den nya transaktionsloggen.

5. System enligt krav 4, kännetecknat av att den nya transaktionsloggen innefattar en "BackupSynch“- variabel, som kan anta värdena "Include" eller "Exclude“, och vars värde används av den lokala databashanteraren och av lokala backuphanterare till att bestämma om objekt skall ingå i en backup eller inte, och att den centrala backuphanteraren beordrar de lokala logghante- 500 656 13 rarna att ändra nämnda variabel i den nya transaktionsloggen till “Exclude", innebärande att dess objekt inte skall ingå i backupen.

6. System enligt krav 5, kännetecknat av att "BackupSynch"- variabeln hämtas av en koordinator för en transaktion i samband med att den skriver "COMMIT" i transaktionsloggen, innebärande att transaktionen uppnått commit-tillstånd, och sänder sedan "BackupSynch"-variabelns värde och "COMMIT"-meddelandet till alla deltagartransaktioner, vilka i sin tur distribuerar ut "BackupSynch“-värdet till de olika databasobjekten, varigenom alla objekt i transaktionen får samma "BackupSynch"-värde och kommer att inkluderas alt. exkluderas från backupen.

7. System enligt något av föregående patentkrav, kännetecknat av att en räknare är anordnad att ange antal pågående trans- aktioner i commit-tillstånd mot den gamla transaktionsloggen, och att synkroniseringen innefattar att när räknaren är lika med 0, meddelas den centrala backupfunktionen att det inte finns någon koordinator för någon transaktion i aktuell dator som vill att uppdateringar skall ingå i backupen.

8. System enligt något av föregående patentkrav, kännetecknat av att efter det att de lokala logghanterarna har meddelats om att den lokala databashanteraren har gjort alla förändringar från transaktioner som skall ingå i backupen synliga i databasen påbörjas kopieringen av objekt till backuparean.

9. System enligt krav 8, kännetecknat av att synliggörandet innefattar synkronisering mellan den lokala databashanteraren, backup-hanteraren och logghanteraren.

10. System enligt krav 9, kännetecknat av att synkronise- ringen görs genom att den lokala logghanteraren håller reda på antal transaktioner som finns i den gamla transaktionsloggen, antal transaktioner räknas ner när transaktionen skriver END- TRANSACTION i den gamla transaktionsloggen, samt END-TRANSACTION skrivs när den lokala databashanteraren har utfört förändringar- na i databasen och meddelat transaktionen detta.

11. System enligt krav 3 och 9, kännetecknat av att när antal transaktioner i den gamla transaktionsloggen är 0 i alla lokala logghanterare beordrar den centrala backup-hanteraren alla lokala backuphanterare att börja kopiering av de objekt som skall ingå i backupen till backuparean, vilka objekt har backup- 500 656 14 markerats av den lokala datbashanteraren i och med att den bytte beteende när backupflaggan sattes.

12. System enligt något av föregående krav, kännetecknat av att kopiering av objekt sker till backuparean, och att den gamla backupen sparas på primärminne tills den nya backupen är slut- förd, varpå den gamla backupen paketeras och lagras på sekundär- minne.