SE506534C2 - Sätt att bestämma innehåll i restaureringslogg - Google Patents

Description

506 534 2 skapas en restaureringslogg med alla uppdateringskomandon från driftstödsystemet till systemet. Normalt innehåller restaure- ringsloggen inga uppdateringar som härrör från en process. I vissa sällsynta fall måste initiativtagaren till en uppdatering skapa en restaureringsloggpost, som återspeglar uppdatering av en resursrepresentation.

Om systemet ej stödjer loggning fràn en process är en nackdel med denna princip att vissa eller alla uppdateringar från processen saknas eller är felaktiga beroende på hur bra initiativtagarna till uppdateringsbegäranden har följt regeln att skapa en restaureringsloggpost. Överensstämelsen mellan restaureringsloggen och verkliga uppdateringar av resursrepre- sentationerna är beroende av en korrekt konstruktion av ini- tiativtagaren. Avsaknad av korrekthet kan koma att inte visa sig förrän restaureringsloggen skall användas för áterställning av systemet efter en krasch.

En annan nackdel är att restaureringsloggen som används för áterställning kommer att innehålla alla uppdate- ringsbegäranden fràn driftstödsystemet ehuru endast vissa av dem kan vara av värde för en àterställning.

' Det är därför uppenbarligen en stor risk för att en àterställning kan medföra oöverensstämelse mellan resurs- repreSenCatiOflerna. OCh resurserna prOCeSSen.

Teknikens ståndpunkt.

I EP 516,900 beskrivs databackup och àterställning i ett dataprocessystem. Syftet är att eliminera nackdelen med en stor och ohanterlig àterställningslogg. En backupkopia tas av åtminstone en del av lagrade data när den delen är tillgänglig för uppdatering. Återställning av databasen sker genom återin- sättning av backupkopian och applicering av uppdateringar i loggposter gjorda efter en àterställning.

US 4,648,031 avser áterstart av ett datorsystem efter avbrott med hjälp av resurshanterare innefattande àterställ- ningslogg.

US 4,868,744 beskriver en metod för áterstart av en feltolerant operation i ett databassystem utan belastning av 506 534 3 systemloggen. Enligt metoden loggas endast en minimal mängd information. Alla transaktionsorienterade förändringar skrivs till loggen för stöd av äterställning i händelse av avbrott.

US 4,945,474 visar systemåterstart under utnyttjande av äterställningslogg och beskriver en äterställning i ett flertal steg.

US 5,l55,678 befattar sig med datatillgänglighet i àterstartbara databassystem. En metod presenteras för omkopp- ling mellan en backup-processor och en aktiv processor efter övervakning av den aktiva processorns loggposter. När den aktiva processorn fallerar, utför backup-processorn den nöd- vändiga áterställningsprocessen.

US 5,280,611 beskriver äterställning av databas efter fel under utnyttjande av logg.

US 5,287,501 avser flernivàtransaktionsáterställning i ett databassystem. Genom operationsloggning kan databasen hantera flerniväáterställning med mycket få restriktioner beträffande timingen av uppdateringar och loggpost.

Redogörelse för uppfinningen.

Syftet med uppfinningen är att åstadkomma ett sätt att välja ändringarna som skall infogas i en restaureringslogg, så att denna endast innehåller de restaureringsloggposter, som är nödvändiga i händelse av äterställning av systemet.

Enligt uppfinningen möjliggörs villkorligt skapande av en loggpost i restaureringsloggen i händelse av en mot en resursrepresentation riktad operation, genom att varje resurs- representation förses med loggningsinformation, som ger besked om huruvida en uppdatering av resursrepresentationen skall loggas i restaureringsloggen.

Varje gäng resursrepresentationen ändrar sitt data som resultat av en uppdateringsbegäran kommer den att generera en lämplig restaureringsloggpost. Denna är lika giltig för upp- dateringsbegäranden frän processen som från driftstödsystemet eller andra system.

Detta innebär att resursrepresentationen själv kan bestäma huruvida en uppdatering skall loggas eller inte och 506 554 4 användaren behöver inte ha vetskap om detta. Delar av resursre- presentationen kan àterställas till default- eller initial- värden vid àterladdning av systemet och motsvarande attribut skall alltså inte ingå i restaureringsloggposter.

Resultatet blir att restaureringsloggen endast kommer att innehålla de nödvändiga restaureringsloggposterna_ Restau- reringsloggen kan tillsamans med en systemversion exporteras från systemet och utgör då en total backup, vilken kan användas för att återställa resursrepresentationen till överensstämelse med resurserna i processen.

Enligt en fördelaktig utföringsform innefattar logg- ningsinformationen en logg-markering i varje attribut, hos vilket en förändring förorsakad av en operation skall loggas, och icke-loggmarkering hos varje attribut som inte skall loggas.

Vid uppträdande av en mot databasen riktad operation sker kontroll av om det rör sig om en dataändrande operation och om så är fallet färdigställs loggdata svarande mot opera- tionen och operationen exekveras. Kontroll kan därefter ske av loggningsinformationen hos av operationen berörda resursrepre- sentationer, och om denna anger att loggning skall ske sänds det färdigställda loggdatat till restaureringsloggen, annars kasseras det.

Om en med datasystemet associerad process accessar datasystemet, och det icke krävs process-specifik kunskap för att omvandla en databasuppdatering baserad pà interna identite- ter till ett meddelande innehållande externa identiteter, öppnar systemet vid mottagande av en accessbegäran fràn pro- cessen en tillämpning, som skapar en transaktion. En data- bashanteringsfunktion skapar en loggdatainsamlingsfunktion och tillämpningen sänder i accessen ingående databasoperationer till denna. Databashanteringsfunktionen genomför kontrollen av om det rör sig om dataändrande operationer, och om så är fallet konverteras de dataändrande operationerna från ett för databa- sen internt format till ett externt format, och skickas de konverterade operationerna som loggdata till loggdatainsam- lingsfunktionen. Databashanteringsfunktionen beordrar logg- 506 534 5 datainsamlingsfunktionen att verkställa resultatet av kontrol- len av loggningsinformationen. Resultatet av operationerna returneras till tilllämpningen, som i sin tur vidareleder det till processen.

Om en med datasystemet associerad process accessar datasystemet och det krävs process-specifik kunskap för att omvandla en databasuppdatering baserad på interna identiteter till ett meddelande innehållande externa identiteter, öppnar systemet vid mottagande av en accessbegäran från processen en tillämpning, som skapar en transaktion och en loggdatainsam- lingsfunktion. Tillämpningen sänder i accessen ingående databa- soperationer till en databashanteringsfunktion och till logg- datainsamlingsfunktionen, och beordrar den senare att verk- ställa resultatet av kontrollen av loggningsinformationen.

Om resultatet innebär att loggningsinformation påträffats, som ~anger att loggning skall ske sänder loggdatainsamlingsfunktio- nen en begäran till en hanteringsinformationsfunktion om att få hanteringsobjektkunskap om ändringarna i databasen. Loggdatain- samlingsfunktionen omvandlar databasoperationerna från ett internt till ett externt format och sänder de konverterade operationerna till loggen. Resultatet av operationerna returne- ras till tilllämpningen, som i sin tur vidareleder det till processen.

Figgrbeskrivning.

Uppfinningen skall nu beskrivas närmare med hänvis- ning till utföringsformer visade på bifogade ritningar, på vilka fig. 1-6 är avsedda att allmänt åskådliggöra en teknisk standard, som kan sägas bilda en av grundvalarna för, och belysa senare beskrivna utföringsformer av uppfinningen, varvid fig. 1 visar exempel på ett telekommunikationsnät enligt TMN, fig. 2 schematiskt åskådliggör uppdelningen av ett i fig. 1 ingående nätelement i hanteringsskikt och resursskikt, fig. 3 schematiskt åskådliggör ett exempel på hur ett 506 534 6 driftstödsystem övervakar och styr en resurs via ett hante- ringsobjekt, som representerar resursen, fig. 4 visar ett exempel på hårdvara ingående i ett enkelt nätelement, som kan ingå i telekommunikationsnätet enligt fig. 1, fig. 5 visar hanteringsskiktet hos nätelementet enligt fig. 4, fig. 6 är en vy som åskådliggör kommunikation och in- teraktion mellan ett driftstödsystem och hanteringsobjekt ingående i ett nätelement, fig. 7 schematiskt åskådliggör sambandet mellan intern datalagring i en databas i ett nätelement och externa gränssnitt, fig. 8 schematiskt åskådliggör uppdatering av data hos ett system enligt fig. 7 enligt konventionella principer för skapande av en restaureringslogg, fig. 9 är en logisk beskrivning av en transaktions loggdata, fig. 10 schematiskt åskådliggör uppdatering enligt uppfinningen av data i en i ett nätelement ingående databas från ett externt driftstödsystem, fig. 11 visar ett mot det i fig. 10 åskådliggjorda förloppet svarande sekvensdiagram fig. 12 schematiskt åskådliggör uppdatering enligt uppfinningen av data i en i ett nätelement ingående databas från en tillämpning, enligt ett första fall, fig. 13 visar ett mot det i fig. 12 åskådliggjorda förloppet svarande sekvensdiagram fig. 14 schematiskt åskådliggör uppdatering enligt uppfinningen av data i en i ett nätelement ingående databas från en tillämpning, enligt ett andra fall, fig. 15 visar ett mot det i fig. 14 åskådliggjorda förloppet svarande sekvensdiagram.

Föredragna utföringsformer.

Som en första introduktion till den följande beskriv- ningen av utföringsexempel av uppfinningen, och eftersom dessa 506 534 7 utföringsexempel av praktiska skäl huvudsakligen baserar sig på en tillämpning av uppfinningen i TMN-miljö, kommer nu till att börja med ett antal benämningar och begrepp i detta sammanhang att diskuteras närmare med hänvisning till fig. 1-6. Användning av uppfinningen är dock ej begränsad till denna miljö, utan kan sägas omfatta all miljö som baserar sig på den internationella ISO-standarden.

Figur 1 visar schematiskt en hanteringsvy 102 enligt TM för ett telekommunikationsnät 104. I det senare antyds hur tvà abonnenter 106 och 108 är uppkopplade mot varandra via nätelement i form av en första lokalstation 110, till vilken abonnenten 106 hör, ett första transmissionssystem 112, en förmedlingsstation 114, ett andra transmissionssystem 116, och en andra lokalstation 118, till vilken abonnenten 108 hör.

Hanteringsvyn 102 innehåller förutom nätelementen 110-118 två driftstödsystem 120 och 122, som via ett datakommunikationsnät 124 och ett Q3-gränssnitt 126, kommunicerar med elementen 110- 118. Ett lokalt driftstödsystem 128 kommunicerar direkt med lokalstationen 118 via gränssnittet 126. Q3 är ett standar- diserat fysiskt gränssnitt mellan tvà TM-byggstenar, såsom nätelement och driftstödsystem. Det består av två delar, _nämligen ett hanteringsprotokoll och en i gränssnittet synlig hanteringsinformationsmodell.

Gränssnittet 126, över vilket driftstödsystemen, såsom 120, 122 och 128, i TMN betraktar telekommunikationsnätet 104, är ett standardiserat maskin-maskingränssnitt, där alla typer av nätutrustning kan övervakas och styras på samma sätt.

Q3-gränssnittet definierar både en objektorienterad informa- tionsmodell av nätelementen 110-118, och komunikationsproto- kollet mellan driftstödsystemen 120, 122 och nätelementen 110- 118.

Med hänvisning till fig. 2 är ett schematiskt visat nätelement 202 uppdelat i ett hanteringsskikt 204 och ett resursskikt 206. Från det här med 208 betecknade driftstöd- systemet är endast hanteringsskiktet 204 synligt. Hanterings- skiktet 204 består av en samling hanteringsobjekt 210, vilka kan övervakas och styras från driftstödsystemet 208 via Q3- 506 554 8 gränssnittet. Ett hanteringsobjekt realiserar ett gränssnitt för extern hantering av en eller flera resurser i ett system.

Hanteringsobjekten 210 väljs med avseende pá hur nätelementet 202 kommer att te sig för en underhållstekniker. Det finns standardiserade hanteringsobjekt för de flesta tilllämpningar.

En underhållstekniker kommer därför att veta hur nätelement från olika leverantörer skall styras.

Resursskiktet 206 är den verkliga implementationen av nätelementet 202. Resurser väljs för att uppnå de bästa egen- skaperna hos systemet. Exekveringstid och minnesàtgång utgör exempel pá egenskaper som skall beaktas vid implementering av resursskiktet.

Resurserna i ett nätelement används av trafikhante- ringen. En trunk används exempelvis för att bära ett telefonan- rop i en riktning. Sàsom redan nämnts är endast nätelementets hanteringsskikt synligt för driftstödsystemen. Om en trunk skall kunna hanteras fràn ett driftstödsystem måste den repre- senteras av ett hanteringsobjekt.

Som exempel visar fig. 3 hur ett trunkresursobjekt 302 uppfàngas, pil 304, för ett anrop internt i ett nätelement 306. Den visar även hur resursobjektet 302 kan övervakas och styras, pil 308, fràn ett driftstödsystem 310 genom ett hante- ringsobjekt 312, som representerar, pil 314, trunkresursobjek- tet 302. Hanteringsobjektet 312 verkar dä som ett "gränssnitt" mot driftstödsystemet. Ett hanteringsobjekt kan inte lagra data, utan alla data tillhör resursobjekten.

I fig. 4 visas maskinvaran hos ett enkelt nätelement 402, som här kan antagas motsvara t.ex. lokalstationen 110 i fig. 1. Nätelementet 402 innehåller en datoriserad växel 404, till vilken tvâ processorer 406 och 408 visas vara anslutna.

Till den datoriserade växeln 404 är vidare en abonnent 410, som kan tänkas vara densamma som abonnenten 106 i fig. 1, ansluten via en abonnentlinjekrets 412. Nätelementet 402 har en anslut- ning till resten av nätet genom en stationsterminal 414, som kommunicerar över en PCM-länk 416. Detta enkla nätelement kan övervakas och styras fràn ett till processorn 406 anslutet driftstödsystem 418, motsvarande driftstödsystemet 120 i fig. 506 534 I fig. 5 visas endast hanteringsskiktet av nätelemen- tet i fig. 4 och betecknas med 502, varvid driftstödsystemet erhållit beteckningen 504. Hanteringsskiktet 502 består närmare bestämt av hanteringsobjekt, vilka anges med respektive klass- namn och instans i fig. 5.

I hanteringsskiktet 502 representeras abonnenten 410 i fig. 4 av en instans 7273000 av ett objekt 506 av klassen Subscriber. Objektet 506 innehåller abonnentdata och är kopplat till en instans 11 av ett objekt 508 av klassen Subscriber- line, som innehåller linjekopplingsdata. Detta objekt represen- terar närmare bestämt linjen mellan abonnenten och linjekretsen 412 i fig. 4. Talkanalerna i PCM-länken 416 i fig. 4 repre- senteras av varsin instans av ett objekt 510 av klassen Trunk.

I nätelementet visas tvá trunkar kopplade till utgående rikt- .ning, medan tre trunkar är kopplade till inkomande riktning.

Detta representeras av en instans "outgoing" av ett objekt 512 av klassen Route, respektive en instans "incoming“ av ett objekt 514 av samma klass. Resten av trunkarna i PCM-länken används ej av nätelementet 402.

Data hos ett hanteringsobjekt specificeras som attri- but. Ett attribut hos ett hanteringsobjekt kan motsvara ett varaktigt lagrat attribut hos ett resursobjekt, men det kan även kalkyleras i en algoritm, som hämtar attribut från flera resursobjekt. Resursdata kan även lagras i filsystemet eller i maskinvaruregister. Ett hanteringsobjekt för en trunk kan exempelvis ha följande attribut: trunkld, state, och myRoute. I detta fall motsvarar alla tre attributen attribut i samma resursobjekt.

Operationer som kan utföras pá ett hanteringsobjekt är: "skapa" (create) och "ta bort" (delete) en instans av ett hanteringsobjekt, "hämta" (get) och "ställ" (set) ett attributvärde, "åtgärd" (action), anmodar ett hanteringsobjekt att utföra en uppgift. Åtgärder används när operationen är mer komplex än 506 534 10 bara att hämta eller ställa ett attributvärde för ett hante- ringsobjekt. Åtgärder inbegriper objektet i dess helhet, men kan även indirekt inbegripa andra objekt.

Ett hanteringsobjekt sänder en “notifikation" (noti- fication), och informerar driftstödsystemet att en händelse har inträffat i nätelementet. Ett alarmtillstànd utgör exempel på en notifikation. Notifikationer används även för andra ändamål, t.ex. laddning av data och trafikstatistik. När det tar lång tid att utföra en åtgärd, kan returvärdet vid mottagande av "åtgärd" informera om att åtgärden påbörjats. Därpå sänds resultatet som en notifikation.

Dessutom kan hanteringsobjekt ha associativa relatio- ner till andra hanteringsobjekt. Trunkar kan exempelvis utgöra delar av en väg (route). Associativa relationer specificeras som attribut.

I det som exempel ovan med hänvisning till fig. 4 och 5 angivna nätelementet ingår flera trunkar. Alla har samma attribut, actions och notifikationer. I objektorienterade termer utgör de instanser av hanteringsobjektklassen Trunk.

Samlingen av alla skapade hanteringsobjektinstanser i ett nätelement benämns hanteringsinformationsbas MIB (Manage- ment Information Base). Hanteringsinformationsbasen är ett abstrakt begrepp och skall ej förväxlas med en fysisk databas, som används för att stadigvarande lagra data i ett system.

Kommunikationen mellan driftstödsystem och nätelement definieras i Q3-gränssnittet. Standardföreskrifter rekommende- rar hur man skall nå och arbeta med hanteringsobjekt från ett driftstödsystem. Dessutom rekommenderar standard hur hante- ringsobjekt skall informera driftstödsystemet om händelser i nätelementet.

En hanterare i driftstödsystemet manipulerar hante- ringsobjekten i nätelementet via en operationsagentfunktion.

Interaktionen mellan hanteraren och agentfunktionen visas närmare i fig. 6. Det med 602 i fig. 6 betecknade driftstödsys- temet är det hanterande systemet och det med 604 betecknade nätelementet det hanterade systemet. Hanteraren betecknas med 606 och agentfunktionen med 608. 506 534 ll Hanteraren 606 initierar kontakt med agenten 608 genom att upprätta en association till agenten. Denna associa- tion kan betraktas som en kommunikationslänk mellan de tvâ systemen. När associationen har ställts upp kan hanteraren och agenten kommunicera med varandra. Hanteraren 606 manipulerar de med 6l0n_l betecknade hanteringsobjekten genom användning av definierade operationer (create, delete, set, action) antydda genom pil 612. Hanteringsobjekten 610 genererar information, notifikationer, som kan vidareledas som händelserapporter, pil 614, till driftstödsystemet. Vid 616n_1 antyds av hanteringsob- jekten 610 representerade resursobjekt. Operationerna och hän- delserapporterna utgör delar av en gemensam hanteringsinforma- tionstjänst (Common Management Information Service CMIS). Det protokoll som används för kommunikationen benämns gemensamt hanteringsinformationsprotokoll (Common Management Information .Protocol CMIP), och de operationer, som ingår i en aktuell transaktion följaktligen CMIP-operationer.

Fig. 7 bygger på fig. 6 och element i fig. 7 som har motsvarighet i fig. 6 har erhällit samma hänvisningsbeteck- ningar som i fig. 6. Fig. 7 åskådliggör närmare bestämt sam- bandet mellan intern datalagring i en databas 702 i nätelemen- tet 604 och externa gränssnitt såsom driftstödaccesser, acces- ser från andra externa system, samt trafikala accesser. Som exempel visas i fig. 7 ett Q3-gränssnitt 704 mot driftstödsys- temet 602. Vid 706 indikeras ett gränssnitt mot ett externt system 708. Vid 710 indikeras trafikal tillämpning förorsakad av en vid 712 antydd abonnent.

I fig. 7 àskádliggörs särskilt fallet transaktion genererad från driftstödsystemet 602 mot en resurs i nätelemen- tet 604. En operationsbegäran riktas fràn driftstödsystemet 602 via Q3-gränsnittet mot ett i databasen 702 befintligt resurs- objekt 616n, som representerar resursen. Operationsagentfunk- tionen 608 sköter kommunikationen mot driftstödsystemet 602 och hittar med hjälp av ett hanteringsobjektnamn, som finns med i operationsbegäran, samt via ett tillhörande gränssnitt 714, i det aktuella exemplet även benämnt MOSI (Managed Object Support Interface), fram till en hanteringsobjektinstans 610n, som 506 534 12 representerar resursobjektet 616n. Gränssnittet MOSI innehåller parametrar för access till attribut och exekvering av metoder i resursobjektet. Hanteringsobjektinstansen 610n manipulerar via ett generiskt gränssnitt 716, även benämnt DMI (Data Manipula- tion Interface), samt en databashanterare 718 resursobjektet 616n i databasen 702. Databashanteraren 718 bildar del av databasens 702 operativsystem och tillhandahåller gränssnittet 716, mot driftstödsystemet 602, liksom mot tillämpningen 710 och annat system 706/708. DMI-gränssnittet skall kunna användas av alla användare.

Med hänvisning till fig. 8 skall nu uppdatering av data hos ett system enligt fig. 7 enligt konventionella prin- ciper för skapande av en restaureringslogg beskrivas i korthet.

I fig. 8 har liknande element som i fig. 7 erhållit samma hänvisningsbeteckningar som denna figur.

Driftstödsystemet 602 skickar en operationsbegäran till nätelementet 604 enligt pil 802. Operationsagenten kon- trollerar operationen och färdigställer med ledning därav loggdata, block 804. Hanteringsobjektet 610n exekverar opera- tionen, pil 806, och returnerar resultatet, pil 808, till operationsagenten 608.

Operationsagenten 608 färdigställer, enligt block 810, en loggpost och skickar den, pil 812, till en restaure- ringslogg 814. Operationsagenten 608 skickar resultatet av operationen till driftstödsystemet 602 enligt pil 816.

Generellt gäller att alla datorsystem associerade med en process interagerar såväl med processen som med operatörer och/eller driftstödsystem. Exempel på sådana datorsystem är digitala telekommunikationsväljare, exemplifierat med nätele- mentet 604 i fig. 7, övervakningssystem för kraftdistribution, och olika typer av tillverkningsstödsystem. Alla dessa typer av system har, såsom tidigare nämnts, en mjukvarurepresentation av varje resurs i processen. I objektorienterade datorsystem utgörs denna resursrepresentation av ett resursobjekt, såsom 6l6n i fig. 7. Resursrepresentationen 616n kan påverkas av en uppdateringsbegäran från processen till systemet. Den kan även påverkas av uppdateringsbegäran från en operatör, exemplifierat 506 534 13 vid 720 och 722 i fig. 7, och/eller andra system, såsom 602 och 708 i fig. 7. Senare kan resursrepresentationen påverkas pá grund av uppdateringsbegäran från såväl processen som från operatören.

I ett telekommunikationssystem betraktas abonnenter, såsom 712 i fig. 7, som del av processen och deras invokering av tjänster betraktas som uppdateringsbegäranden från processen till växelns styrsystem, såsom nätelementet 604 i fig. 7.

Tjänster som skapas från ett driftstödsystem, såsom 602 i fig. 7, betraktas som uppdateringsbegäranden från ett annat sys- tem/operatör, dvs. från exempelvis systemet 708 i fig. 7.

Genom att ha en s.k. versionshantering av datorsystem kan en operatör och programerade funktioner hämta information om systemhistorien. Versionshanteringen ger stöd för val och omladdning av systemversion. Den pekar även ut en logg som beskriver systemversionens förändringar.

Närmare bestämt utgör en systemversion en komplett beskrivning av information som krävs för att ladda och starta ett datorsystem, som beskrivs av versionen. Till systemversio- nen är en restaureringslogg kopplad, som innehåller trans- aktioner riktade mot en restaureringsdomän, som omfattas av _restaureringsloggen. Denna domän definieras så att enbart transaktioner som i sin helhet riktar sig mot domänen är möjliga. Restaureringsloggen utnyttjas vid restaurering, varmed avses omladdning av ett system med omladdningsinformation för att upprepa inga, vissa eller alla i loggen ingående operatio- ner.

En systemversion omfattar programvara, databasschema, konfigurationsdata samt databasinnehàll. De tre förstnämnda är oförändrade över hela systemgenerationen, med undantag för procedurer avsedda att förändra i dessa, t.ex. för systemupp- gradering. Sådana procedurer påbörjas alltid med en informativ post i restaureringsloggen och avslutas alltid med att en ny systemversion skapas. Databasinnehàllet förändras över system- generationens livslängd. Förändringarna sparas i restaurerings- loggen. Backup av databasinnehàllet, som tillförs versionshan- teringen, ger upphov till ny systemgeneration. 506 554 14 En mängd systemversioner, som har samma uppsättning programvara, databasschema och konfigurationsdata benämns systemgeneration. Systemversionerna utgör systemgenerationens historik. Ny systemgeneration genereras vid laddning/omladdning av ett system och vid avslutad procedur för förändring av pro- gramvara, databasschema och/eller konfigurationsdata.

Regelbunden databackup bidrar till att vidmakthålla robusthet hos ett datasystem. Operatören har möjlighet att välja backupintervall, vid anläggningskonfigurering eller under drift. Med backup avses här arkivbackup, dvs. backup lagrad på sekundärminne.

Backuptidpunkter och -intervall finns lagrade i ett hanteringsobjekt i form av ett backupschema. I backupschemat finns även en gallringsmetod angiven. Endast ett mindre antal arkivkopior finns lagrade lokalt. En del av övriga, äldre kopior överförs till en driftstödsnod.

Med hänvisning till fig. 9 består en restaurerings- loggpost av två delar, nämligen en statisk transaktionsdel 902, som utgörs av transaktionsgemensamma uppgifter, och en dynamisk operationsdel 904, som kan bestå av ett godtyckligt antal operationer.

Följande attribut förekommer i restaureringslogg- posten: COMMIT-tid: anger när transaktionen avslutades i databasen.

Systemversionsldentitet: identitet för senast skapad systemversion.

Transaktionsldentitetz anger vilken identitet trans- aktionen har.

"Bäst före" tid: anger hur länge transaktionen är giltig och används vid pàläsning av restaureringsloggen sålunda att endast transaktioner pàläses, vilkas bästföretid inte passerats. Om transaktionen exempelvis motsvarar en beställd väckning är den transaktionen giltig till dess att väckningen är utförd.

Gamalt värde: anger vilket värde ett attribut hade innan operationen utfördes. Observera att ett attributs eventu- 506 534 15 ellt nya värde finns tillgängligt i aktuell operation.

I fig. 10 àskádliggörs i en liknande vy som i fig. 7 och 8 principen för skapande av en restaureringslogg baserat pà en loggmarkering i anslutning till varje attribut, och vid en fràn driftstödsystemet genererad transaktion. Samma element som i fig. 7 och 8 har därvid givits samma hänvisningsbeteckningar.

I fig. 11 visas ett motsvarande sekvensdiagram.

I fig. 10 indikeras resursobjektet 616n såsom innehål- lande ett attribut A1, som kan ha en markering L eller NL, som avses stà för LOG resp. NOLOG. Markeringarna L och NL innebär att attributet A1 skall loggas resp. inte loggas vid ändring av attributet.

Driftstödsystemet 602 sänder en operationsbegäran till operationsagenten 608 i nätelementet 604 enligt pil 1002.

Operationsagenten 608 skapar en mot databashanteraren 718 .riktad transaktion enligt pil 1102.

Operationsagenten kontrollerar om det rör sig om en dataändrande operation. Om så är fallet skickar operationsagen- ten 608 operationen, med en instruktion 1004 att färdigställa loggdata, till en av databashanteraren 718 vid mottagandet av transaktionen skapad loggdatagenerator 1006. Loggdatageneratorn 1006 genomför detta genom att kopiera operationen.

Operationsagenten 608 beordrar genom instruktionen 'PerformOp' enligt pil 1104 hanteringsobjektet 1010 att exe- kvera operationen. Hanteringsobjektet 1010 anropar en dataob- jektagent DOA i DMI-gränssnittet 716, via vilken operationen exekveras, pil 1012. Hanteringsobjektet 1010 erhåller resulta- tet och vidarebefordrar det till operationsagenten 608 enligt pil 1016.

Operationsagenten 608 committar transaktionen, dvs. beordrar genom 'CommitTrans' enligt pil 1108 databashanteraren 718 att utföra den transaktionsoperation, som används för att indikera att transaktionen slutförts och att dess verkningar skall kvarstå. Resultatet av operationen är nu synligt i nätelementet 604.

Endera av två fall är nu tänkbart, nämligen att ett loggtriggande attribut i resursobjektet 616n ändrats resp. inte 506 534 16 ändrats av operationen. Det första fallets uppträdande i fig. 11 markeras med streckad linje 1109.

I det första fallet instruerar databashanteraren 718 genom 'LogIt', pil 1110, operationsagenten 608 att sända loggdata till den med 1018 betecknade restaureringsloggen.

Operationsagenten 608 beordrar loggdatageneratorn 1006 genom instruktionen 'SendLogData', pil 1020, att sända loggdata till restaureringsloggen 1018. Loggdatageneratorn 1006 genomför detta enligt pil 1022. Operationen har därmed loggats.

Loggdatageneratorn 1006 rapporterar tillbaka enligt pil 1024 till operationsagenten 608.

I det andra fallet, vars uppträdande i fig. 11 marke- ras med streckad linje 1112, kan databashanteraren 718 genom 'NoLog' ha rapporterat tillbaka till operationsagenten 608 att inget loggtriggande attribut påverkats, pil 1114 i fig. 11.

Operationsagenten 608 beordrar då loggdatageneratorn genom 'ClearLogData', pil 1116 i fig. 11, att kassera de enligt ovan iordningställda operationsloggdata.

Streckad linje 1115 markerar att det som därefter följer i fig. 11 är gemensamt för de båda fallen. För båda alternativen returnerar således operationsagenten enligt pil 1026 resultatet av operationen i 'Reply' till driftstódsystemet 602.

Med hänvisning till tvà i fig. 12 och 13 resp. fig. 14 och 15 äskàdliggjorda fall skall nu generella principer beskrivas för att enligt uppfinningen skapa en restaurerings- logg vid uppdateringar mot en databas fràn en trafiktillämp- ning. Det antas för enkelhetens skull att det i fig. 12 och 14 rör sig om samma databas och samma nätelement som i fig. 10.

Motsvarande element som i fig. 10 har därför i fig. 12 och 14 erhållit sama hänvisningsbeteckningar som i fig. 10.

Det rör sig i bàda fallen om en process, som inte utför operationer mot databasens resursrepresentationer via hanteringsobjekt med externa identiteter utan via i DMI-gräns- snittet 716 befintliga interna databasidentiteter. Eftersom àterställning av databasen från en restaurerinslogg måste ske via det i fig. 12 och 14 för enkelhetens skull ej visade 506 534 17 driftstödsystemets hanteringsvy, dvs. via hanteringsobjekt, mäste i restaureringsloggen befintliga loggdata ha det externa formatet. Formatet hos de i operationen ingående interna identiterna måste därför före loggning omvandlas till ett externt format.

I fallet enligt fig. 12 och 13 förutsätts det att databasens 702 accessfunktioner kan konstruera ett CMIP-med- delande utan specifika kunskaper om semantiken för ett speci- fikt hanteringsobjekt, med användande endast av syntaxkunskap.

Detta innebär i praktiken att den enda reella konvertering som görs är att interna identiteter konverteras till externa med hjälp av generella översättningsfunktioner. Fördelen är att den trafikala tillämpningen ej behöver utrustas med speciella funktioner för att skapa och sända loggposter till restaure- ringsloggen.

Med hänvisning till fig. 12 och 13 sänder en process förorsakad av en vid 1202 antydd telefonabonnent en opera- tionsbegåran 1204 till nätelementet 604. Nâtelementet 604 förutsätts innehålla tillämpningsspecifik programvara, indi- kerad med ett block 1206, nedan i korthet benämnd tillämpning, med uppgifter av specialiserad karaktär för att kunna ta hand om operationsbegäran och därav resulterande, nedan närmare beskrivna förlopp. Med ett block 1208 i tillämpningen 1206 in- dikeras funktionalitet för att för dessa förlopp utföra lämplig beräkning och uppdateringar.

Tillämpningen 1206 skapar en transaktion riktad, pil 1302, mot databashanteraren 718. Databashanteraren 718 skapar, pil 1304, en loggdatainsamlare 1210. Trafiktillämpningen 1206 sänder databasoperationer, pil 1306, till databashanteraren 718. Databashanteraren 718 kontrollerar om det rör sig om dataändrande operationer eller inte. Om så är fallet färdig- ställs loggdata, indikerat med block 1212, genom att de data- ändrande operationerna omvandlas frän det interna till det externa formatet, och de konverterade operationerna sänds, pil 1308, till loggdatainsamlaren 1210.

Databashanteraren 718 sänder en instruktion 'perform operation', pil 1310, till berörda databasobjekt, exemplifie- 506 534 18 rade med objektet 616n, att utföra operationen. Databasobjektet exekverar operationerna och returnerar resultatet, pil 1312, till databashanteraren 718. Trafiktillämpningen 1206 committar transaktionen, dvs. beordrar databashanteraren 718, pil 1314, att utföra den transaktionsoperation, som används för att in- dikera att transaktionen slutförts och att dess verkningar skall kvarstå.

Kontroll sker, indikerat vid 1214, av om något logg- triggande attribut i ett databasobjekt ändrats av operationerna i transaktionen. Liksom i fig. 11 inträder därmed endera av två möjliga fall, nämligen att ett sådant loggtriggande attribut påträffats resp. inte påträffats. Det första fallets uppträdan- de i fig. 13 markeras med streckad linje 1315. I detta fall instruerar databashanteraren 718 genom 'send log data', pil 1316, loggdatainsamlaren 1210 att skapa en loggpost av de färdigställda loggdata, indikerat med block 1216, och sända denna till restaureringsloggen 1018. Loggdatainsamlaren 1210 genomför detta enligt pil 1218. Såsom framgått av ovanstående, innebär detta att operationerna loggas pà det externa formatet.

Loggdatinsamlaren 1210 rapporterar tillbaka enligt pil 1220 till databashanteraren 718.

Det andra fallets uppträdande i fig. 13 markeras med streckad linje 1317. Om kontrollen 1214 ger vid handen att inget loggtriggande attribut påverkats, instruerar databashan- teraren 718 enligt pil 1318 loggdatainsamlaren 1210 genom instruktionen 'ClearLogData', block 1222, att kassera de färdigställda loggdata.

Med streckad linje 1319 markeras att det som därefter följer i fig. 13 är gemensamt för de båda fallen. För båda alternativen returnerar alltså databashanteraren 718 sedan resultatet av operationerna till tillämpningen 1206, som vidarebefordrar det till processen, jfr. pilar 1320 resp. 1322.

Fallet enligt fig. 14 och 15 förutsätter, i motsats till fallet enligt fig. 12 och 13, att det krävs tillämpnings- specifik kunskap för att omvandla en databasuppdatering baserad på interna identiteter till ett CMIP-meddelande med externa identiteter. Generell översättning mellan interna databasiden- 506 534 19 titeter och externa identiteter är således ej möjlig.

En process förorsakad av en vid 1402 antydd tele- fonabonnent sänder en operationsbegâran 1404 till nätelementet 604. Såsom i fallet enligt fig. 12 och 13 förutsätts nätelemen- tet 604 innehålla tillämpningsspecifik programvara, indikerad med ett block 1406, nedan i korthet benämnd tillämpning, med uppgifter av specialiserad karaktär för att kunna ta hand om operationsbegâran och därav resulterande, nedan närmare be- skrivna förlopp. Med ett block 1408 i tillämpningen 1406 in- dikeras funktionalitet för att för dessa förlopp utföra lämplig beräkning och uppdateringar. Tillämpningen 1406 skapar en transaktion riktad, pil 1502, mot databashanteraren 718, samt en loggdatainsamlare 1410, pil 1504. Tillämpningen 1406 sänder databasoperationer till databashanteraren 718, pil 1506, och till loggdatainsamlaren 1410, pil 1508.

Databashanteraren 718 sänder en instruktion 'perform operation', pil 1510, till berörda databasobjekt, exemplifie- rade med objektet 616n att utföra operationen. Denna instruk- tion inkluderar även instruktion, indikerad med block 1412, att färdigställa loggdata. Databasobjektet exekverar operationerna I och returnerar resultatet, pil 1512, till databashanteraren 718. Tillämpningen 1406 committar transaktionen, dvs. beordrar databashanteraren 718, pil 1514, att utföra den transaktions- operation, som används för att indikera att transaktionen slut- förts och att dess verkningar skall kvarstå.

Kontroll sker, indikerat vid 1414, av om något logg- triggande attribut i ett objekt ändrats av operationerna i transaktionen. Såsom i fig. 11 och 13 uppträder nu två fall, nämligen att loggtriggande attribut ändrats resp. inte ändrats.

I fig. 15 markeras det första fallets uppträdande med streckad linje 1515. I detta fall instruerar tillämpningen 1406 genom 'log it', pil 1516, loggdatainsamlaren 1210 att skapa en loggpost, indikerat med block 1416, och sända denna, indikerat med block 1418, till restaureringsloggen 1018. Loggdatainsam- laren 1410 sänder då en begäran, pil 1518, till en klass- specifik hjálpfunktion 1519, som i form av en hanteringsin- formationsmodell tillhandahåller beskrivning av existerande 506 554 20 hanteringsobjektklasser, om att erhålla hanteringsobjektspe- cifik information om ändringarna i databasen 702. Den ifråga- varande hjälpfunktionen 1519 kan vara av det slag, som beskrivs närmare i det svenska patentet 470,456. Loggdatainsamlaren 1410 erhåller den efterfrågade informationen enligt pil 1520. Med hjälp därav omvandlar loggdatainsamlaren 1410 databasoperatio- nerna från ett internt till ett externt format och sänder de konverterade operationerna till loggen enligt pil 1420. Logg- datainsamlaren 1410 rapporterar tillbaka enligt pil 1422 till tillämpningen 1406.

Det andra fallets uppträdande markeras i fig. 15 med streckad linje 1521. Om kontrollen 1414 således ger vid handen att inget loggtriggande attribut påverkats, instruerar, pil 1522, tillämpningen 1406 loggdatainsamlaren 1410 genom 'Clear- LogData', block 1424, att kassera de insamlade operationerna.

För båda alternativen returnerar loggdatainsamlaren 1410, pil 1524, resultatet av operationerna till tillämpningen 1406, som vidarebefordrar det till processen, pil 1426.

Claims (6)

LH CD CÅ (_51 CJ il 21 Patentkrav.

1. Sätt att skapa restaureringsloggposter i en res- taureringslogg i ett datasystem, vilket innehåller mjuk- och hårdvaruresurser och en databas innehållande mjukvarurepre- sentationer av resurserna i ett resursskikt, vilka resurs- representationer innehåller data i tillhörande attribut och kan utsättas för operationer via en hanteringsfunktion från en med datasystemet associerad process eller från ett driftstödsystem för datasystemet, varvid en restaureringsloggpost skall åter- spegla en uppdatering av en resursrepresentation, som utförs från processen eller från driftstödsystemet, kännetecknat av att, för att möjliggöra villkorligt skapande av en logg- post i restaureringsloggen i händelse av en mot en resurs- representation via hanteringsfunktionen riktad operation, förses varje resursrepresentation med loggningsinformation, som ger besked om huruvida en uppdatering av resursrepresentationen skall loggas i restaureringsloggen, varvid vid uppträdande av en operation hanteringsfunktionen (608; 1206; 1406) kontrollerar om det rör sig om en dataändrande opera- tion och, om så är fallet, färdigställer loggdata svarande mot operationen, exekverar operationen, kontrollerar loggningsinformationen hos av opera- tionen berörda resursrepresentationer, och om denna anger att loggning skall ske sänds det färdigställda loggdatat till restaureringsloggen, annars kasseras det.

2. Sätt enligt krav 1, kännetecknat av att loggnings- informationen utgöres av en loggmarkering i ett attribut hos resursrepresentationen.

3. Sätt enligt krav 1, kånnetecknat av att loggnings- informationen innefattar en logg-markering i varje attribut, hos vilket en förändring förorsakad av en operation skall loggas.

4. Sätt enligt krav 3, kännetecknat av att loggnings- informationen innefattar en icke-loggmarkering hos varje attribut som inte skall loggas. 5Û6 554 22

5. Sätt enligt något av krav 1-4, där en med data~ systemet associerad process accessar datasystemet och det icke krävs process-specifik kunskap för att omvandla en databasupp- datering baserad pá interna identiteter till ett meddelande innehållande externa identiteter, kännetecknat av att systemet vid mottagande av en accessbegäran från processen öppnar en tillämpning, som skapar en transaktion, hanteringsfunktionen skapar en loggdatainsamlings- funktion, tillämpningen sänder i accessen ingående databasope- rationer till hanteringsfunktionen, hanteringsfunktionen genomför kontrollen av om det rör sig om dataändrande operationer, och om så är fallet konverteras de dataändrande operationerna frän ett för databa- sen internt format till ett externt format, och skickas de konverterade operationerna som loggdata till loggdatainsam- lingsfunktionen, hanteringsfunktionen beordrar loggdatainsamlings- funktionen att verkställa resultatet av kontrollen av logg- informationen, resultatet av operationerna returneras till till- lämpningen, som i sin tur vidareleder det till processen.

6. Sätt enligt något av krav 1-4, där en med datasys- temet associerad process accessar datasystemet och det krävs process-specifik kunskap för att omvandla en databasuppdatering baserad pá interna identiteter till ett meddelande innehållande externa identiteter, kännetecknat av att systemet vid mottagande av en accessbegäran från processen öppnar en tillämpning, som skapar en transaktion och en loggdatainsamlingsfunktion, tillämpningen sänder i accessen ingående databasope- rationer till hanteringsfunktionen och till loggdatainsamlings- funktionen, tillämpningen beordrar loggdatainsamlingsfunktionen att verkställa resultatet av kontrollen av loggningsinformatio- nen, om resultatet innebär att loggningsinformation på- 506 534 23 träffats, som anger att loggning skall ske sänder loggdatain- samlingsfunktionen en begäran till en hanteringsinformations- funktion om att få hanteringsobjektkunskap om ändringarna i databasen, loggdatainsamlingsfunktionen omvandlar databasopera- tionerna från ett internt till ett externt format och sänder de konverterade operationerna till loggen, resultatet av operationerna returneras till till- lämpningen, som i sin tur vidareleder det till processen.