Översikt över Service Manager OLAP-kuber för avancerade analyser

Viktigt

Den här versionen av Service Manager har nått slutet av supporten, vi rekommenderar att du uppgraderar till Service Manager 2022.

I Service Manager kan data som finns i informationslagret konsolideras från olika källor. Den presenteras via Service Manager med hjälp av fördefinierade och anpassade OLAP-datakuber (Microsoft Online Analytical Processing). I korthet består avancerad analys i Service Manager av publicering, visning och manipulering av kubdata, vanligtvis i antingen Microsoft Excel eller Microsoft SharePoint. Excel används huvudsakligen fristående för att visa och hantera data. SharePoint används huvudsakligen för att publicera och dela data i kuber.

Service Manager innehåller ett System Center informationslager. Därför kan data från Operations Manager, Configuration Manager och Service Manager konsolideras till informationslagret, där du enkelt kan använda flera datavyer för att få information som du kanske vill. Det här är också ett gränssnitt där du kan placera data i samma informationslager från dina egna anpassade källor, till exempel SAP-program eller ett personalprogram från tredje part. Den här konsolideringen skapar en gemensam datamodell och möjliggör berikade analyser som hjälper dig att skapa ett informationslager i din IT-organisation som kan hantera alla dina business intelligence- och rapporteringsbehov.

När alla data finns i en gemensam modell kan du hantera information och använda gemensamma definitioner och en gemensam taxonomi för hela organisationen. Du kan göra detta genom att distribuera OLAP-datakuber och använda informationen från kuberna med standardverktyg som Excel och SharePoint. På så sätt kan användarna arbeta med verktyg de redan känner till. Du styr definitionen av affärslogiken på ett centraliserat sätt. Du kan till exempel definiera viktiga prestandaindikatorer, till exempel tröskelvärden för incidenttid till lösning och vilka värden för tröskelvärdena som är gröna, gula eller röda. Du styr dessa val på ett centralt sätt och ger användarna möjlighet att använda data på ett enkelt sätt, samtidigt som de gemensamma definitionerna visas i deras Excel-rapporter eller SharePoint-instrumentpaneler.

Om Service Manager OLAP-kuber

OLAP-kuber (Online Analytical Processing) är en funktion i Service Manager som använder den befintliga infrastrukturen för informationslager för att tillhandahålla business intelligence-funktioner med självbetjäning till slutanvändare.

En OLAP-kub är en datastruktur som ger snabb dataanalys utan de begränsningar som gäller för relationsdatabaser. Kuber kan visa och summera stora datamängder och ger sökbar tillgång till alla datapunkter. På så sätt kan data ackumuleras, segmenteras och tärnas efter behov för att hantera den bredaste mängd frågor som är relevanta för en användares intresseområde.

Programvaruleverantörer eller IT-utvecklare med fungerande kunskaper om OLAP-kuber kan skapa hanteringspaket för att definiera sina egna utökningsbara och anpassningsbara OLAP-kuber som bygger på informationslagerinfrastrukturen. Dessa kuber lagras i SQL Server Analysis Services (SSAS). Business Intelligence-verktyg med självbetjäning som Excel och SQL Server Reporting Services (SSRS) kan rikta in sig på dessa kuber i SSAS, och du kan använda dem för att analysera data från flera perspektiv.

De databaser som ett företag använder för att lagra alla sina transaktioner och poster kallas OLTP-databaser (Online Transaction Processing). Normalt innehåller de poster som anges en i taget och omfattar mängder av information som kan användas som grund för strategiskt beslutsfattande. Problemet är att dessa databaser inte är utformade för analys, och det krävs mycket tid och möda för att få fram svar ur dem. OLAP-databaser är specifikt utformade för enkel extrahering av Business Intelligence-information ur data.

OLAP-kuber kan ses som den sista pusselbiten i en datalagerlösning. En OLAP-kub, även kallad flerdimensionell kub eller hypercube, är en datastruktur i SQL Server Analysis Services (SSAS) som skapas med hjälp av OLAP-databaser för att möjliggöra nästan omedelbar dataanalys. Systemets topologi framgår av illustrationen nedan.

Fördelen med en OLAP-kub är att den kan innehålla data i aggregerad form. Slutanvändaren upplever att kuben redan har svaren, eftersom många värden är förhandsberäknade. Kuben kan returnera svar på en mängd olika frågor nästan omedelbart utan att behöva skicka anrop till den underliggande OLAP-databasen.

Huvudmålet med Service Manager OLAP-kuber är att ge programvaruleverantörer eller IT-utvecklare möjlighet att utföra nästan omedelbar analys av data för både historiska analyser och trendande ändamål. Service Manager gör detta genom att:

• OLAP-kuber kan definieras i hanteringspaket som skapas automatiskt i SSAS när hanteringspaketen distribueras.
• Kuben kan underhållas automatiskt, med bearbetning, partitionering, översättning och lokalisering samt schemaändringar, utan åtgärder från användare.
• Användare kan använda business intelligence-verktyg med självbetjäning, till exempel Excel, för att analysera data från flera perspektiv.
• Excel-rapporter som genereras kan sparas för framtida referens.

Om du vill se hur informationslagerkuber representeras i Service Manager-konsolen navigerar du till Data Warehouse arbetsyta och klickar sedan på Kuber.

Service Manager OLAP-kuber

Följande bild visar de viktigaste delarna i SQL Server Business Intelligence Development Studio (BIDS) som krävs för OLAP-kuber. Dessa delar är datakällan, datakällvyn, kuber och dimensioner. I följande avsnitt beskrivs OLAP-kuberna och de åtgärder användare kan utföra med dem.

Datakälla

En datakälla är ursprungspunkten för alla data som finns i en OLAP-kub. En OLAP-kub ansluter till en datakälla för att läsa och bearbeta rådata för att utföra aggregeringar och beräkningar för associerade mått. Datakällan för alla Service Manager OLAP-kuber är dataförråden, som innehåller dataförråd för både Operations Manager och Configuration Manager. Autentiseringsinformation om datakällan måste lagras i SQL Server Analysis Services (SSAS) för att skapa rätt behörighetsnivå.

Datakällans vy

Datakällans vy (DSV) är en samling vyer som representerar dimensions-, fakta- och utriggartabeller från datakällan, till exempel Service Manager dataförråd. Datakällvyn innehåller alla relationer mellan tabeller, som primära nycklar och sekundärnycklar. Med andra ord anger datakällvyn hur SSAS-databasen ska mappa till relationsschemat, och den tillhandahåller ett abstraktionslager ovanpå relationsdatabasen. Med hjälp av det här abstraktionslagret kan relationer mellan fakta- och dimensionstabeller definieras, även om det inte finns några relationer inom källrelationsdatabasen. Namngivna beräkningar, anpassade mått och nya attribut, som kanske inte finns i datalagrets dimensionsschema, kan också definieras i datakällvyn. En namngiven beräkning som definierar ett booleskt värde för Incidents Resolved beräknar till exempel värdet som sant om en incidents status är löst eller stängd. Med hjälp av den namngivna beräkningen kan Service Manager definiera ett mått för att visa användbar information, till exempel procentandelen lösta incidenter, det totala antalet lösta incidenter och det totala antalet incidenter som inte har lösts.

Ett annat enkelt exempel på en namngiven beräkning är ReleasesImplementedOnSchedule. Den här namngivna beräkningen ger en snabb kontroll av hälsostatusen för antalet versionsposter vars faktiska slutdatum är mindre än eller lika med det schemalagda slutdatumet.

OLAP-kuber

En OLAP-kub är en datastruktur som överbryggar begränsningarna med relationsdatabaser genom att tillhandahålla snabb dataanalys. OLAP-kuber kan visa och summera stora mängder data samtidigt som användarna får sökbar åtkomst till alla datapunkter så att data kan samlas upp, segmenteras och tärnas efter behov för att hantera den bredaste mängd frågor som är relevanta för en användares intresseområde.

Dimensioner

En dimension i SSAS refererar till en dimension från Service Manager informationslagret. I Service Manager motsvarar en dimension ungefär en hanteringspaketklass. Varje hanteringspaketklass har en egenskapslista, medan varje dimension har en attributlista, där varje attribut mappar till en egenskap i en klass. Med hjälp av dimensioner kan data filtreras, grupperas och etiketteras. Du kan till exempel filtrera datorer efter installerat operativsystem och gruppera personer i kategorier efter kön eller ålder. Dessa data kan sedan presenteras i ett format där de ordnas naturligt i dessa hierarkier och kategorier, vilket möjliggör djupare analys. Dimensioner kan också ha naturliga hierarkier så att användarna kan "öka detaljnivån" till mer detaljerade detaljnivåer. Dimensionen Datum har till exempel en hierarki som kan delas upp i år, kvartal, månad, vecka och slutligen dag.

Följande bild visar en OLAP-kub som innehåller dimensionerna Datum, Region och Produkt.

Till exempel kanske Microsoft-teammedlemmar vill ha en snabb och enkel sammanfattning av försäljningen av Xbox One-spelkonsolen i tillämplig version. De kan borra längre ned i dimensionerna för att få försäljningssiffrorna för en mer fokuserad tidsram. Affärsanalytiker kanske vill undersöka hur försäljningen av Xbox One konsoler påverkades av lanseringen av den nya konsoldesignen och Kinect för Xbox One. Detta hjälper dem att se de aktuella försäljningstrenderna och avgöra om affärsstrategin behöver förändras utifrån det. Genom att filtrera efter datumdimensionen kan den här informationen tas fram och användas snabbt. Dessa många datasammanställningsmöjligheter är bara tillgängliga eftersom dimensionerna har utformats med attribut och data som enkelt kan filtreras och grupperas av kunden.

I Service Manager delar alla OLAP-kuber en gemensam uppsättning dimensioner. Alla dimensioner använder det primära datalagrets datamart som källa, även om det finns flera datamarter. I ett scenario med flera datamarter kan detta leda till dimensionsnyckelfel under bearbetning av kuben.

Måttgrupp

En måttgrupp är samma begrepp som ett faktum inom datalagerterminologin. Precis som fakta innehåller numeriska mått i ett datalager, innehåller en måttgrupp mått för en OLAP-kub. Alla mått i en OLAP-kub som härleds från en enda faktatabell i en datakällvy kan också ses som en måttgrupp. Det kan dock finnas instanser där måtten i en OLAP-kub härleds från flera faktatabeller. Mått med samma detaljnivå finns i en måttgrupp. Måttgrupper definierar vilka data som läses in i systemet, hur data läses in och hur data binds till den flerdimensionella kuben.

Varje måttgrupp innehåller också en lista över partitioner, som innehåller faktiska data i separata, icke-överlappande sektioner. Måttgrupper innehåller även aggregeringsdesign, som definierar de färdigsummerade datauppsättningar som beräknas för varje måttgrupp för att förbättra resultatet av användarfrågorna.

Mått

Mått är de numeriska värden som användare vill sammanställa och analysera. De är en av de huvudsakliga anledningarna till att du vill skapa OLAP-kuber med hjälp av datalagerinfrastruktur. Med hjälp av SSAS kan du skapa OLAP-kuber som använder affärsregler och beräkningar för att formatera och visa mått i ett anpassningsbart format. En stor del av utvecklingstiden för OLAP-kuber kommer att gå åt till att avgöra och definiera vilka mått som ska visas och hur de ska beräknas.

Mått är värden som vanligtvis mappar till numeriska kolumner i en faktatabell i datalagret, men de kan även skapas för dimensioner och degenererade dimensionsattribut. Dessa mått är de viktigaste värdena som analyseras i en OLAP-kub och av störst intresse för de slutanvändare som använder OLAP-kuben. Ett exempel på ett mått som finns i datalagret är "ActivityTotalTimeMeasure". "ActivityTotalTimeMeasure" är ett mått från "ActivityStatusDurationFact" som representerar den tid under vilken varje aktivitet har en viss status. Detaljnivån för ett mått består av alla dimensioner som det refererar till. Detaljnivån för relationsfaktumet ComputerHostsOperatingSystem består till exempel av dimensionerna Dator och Operativsystem.

Aggregeringsfunktioner beräknas på mått för att möjliggöra ytterligare dataanalys. Den vanligaste aggregeringsfunktionen är Summa. En vanlig OLAP-kubfråga summerar till exempel den sammanlagda tiden för alla aktiviteter som är In Progress. Andra vanliga aggregeringsfunktioner är Min, Max och Antal.

Efter att rådata har bearbetats i en OLAP-kub kan användarna utföra mer komplexa beräkningar och frågor med flerdimensionella uttryck (MDX) för att definiera egna måttuttryck eller beräknade medlemmar. MDX är branschstandard för datafrågor och dataåtkomst i OLAP-system. SQL Server har inte utformats för att fungera med den datamodell som flerdimensionella databaser har stöd för.

Ökad detaljnivå

När en användare går nedåt i data i en OLAP-kub analyserar han/hon data på en annan sammanfattningsnivå. Detaljnivån för data ändras efterhand som användaren går nedåt och utforskar data på olika nivåer i hierarkin. När användaren går nedåt flyttar han eller hon sig från sammanfattningsinformation till data med ett smalare fokus. Följande är exempel på detta:

• Att gå nedåt i data för att granska demografisk information om befolkningen i USA, sedan befolkningen i delstaten Washington, sedan storstadsområdet Seattle, sedan staden Redmond och slutligen Microsoft.
• Öka detaljnivån i försäljningssiffrorna för Xbox One konsoler för kalenderåret 2015, sedan årets fjärde kvartal, sedan december månad, sedan veckan före jul och slutligen julafton.

Visa detaljerad information

När användarna detaljgranskar data vill de se alla enskilda transaktioner som bidrog till OLAP-kubens aggregerade data. Användaren kan med andra ord hämta data på den allra lägsta detaljnivån för ett visst måttvärde. Om du till exempel får försäljningssiffrorna för en viss månad och produktkategori kan du använda detaljvisning för dessa data för att visa en lista över varje tabellrad som finns i den cellen med data.

Det är vanligt att förväxla termerna "öka detaljnivån" och "öka detaljnivån" med varandra. Den största skillnaden mellan dem är att en ökad detaljnivå fungerar på en fördefinierad hierarki med data, till exempel USA, sedan till Washington och sedan i Seattle i OLAP-kuben. Detaljvisning går direkt till den allra lägsta detaljnivån och hämtar en grupp rader från datakällan som har aggregerats till en enda cell.

Nyckelprestandaindikator

Organisationer kan använda nyckeltal (KPI:er) för att avgöra hur företaget mår och presterar genom att mäta framstegen mot uppsatta mål. Nyckeltal är affärsmått som kan definieras för att övervaka framsteg mot vissa fördefinierade mål. Ett nyckeltal har ett målvärde och ett faktiskt värde, som representerar ett kvantitativt mål av avgörande betydelse för organisationen. Nyckeltal visas vanligtvis i grupper på ett styrkort, vilket ger en ögonblicksbild över verksamhetens allmänna hälsotillstånd.

Ett exempel på ett nyckeltal är att slutföra alla ändringsbegäranden inom 48 timmar. Ett nyckeltal kan användas för att mäta procentandelen ändringsbegäranden som löses inom den tidsramen. Du kan skapa instrumentpaneler för att visa nyckeltal på ett grafiskt sätt. Du kan till exempel definiera ett målvärde på 75 % för nyckeltalet att slutföra alla ändringsbegäranden inom 48 timmar.

Partitioner

En partition är en datastruktur som innehåller vissa eller alla data i en måttgrupp. Alla måttgrupper är indelade i partitioner. En partition definierar en delmängd av faktadata som läses in till måttgruppen. I SSAS Standard Edition tillåts bara en partition per måttgrupp, medan en måttgrupp i SSAS Enterprise Edition kan innehålla flera partitioner. Partitioner är en funktion som är transparent för slutanvändaren, men de har avgörande betydelse för både prestanda och skalbarhet för OLAP-kuber. Alla partitioner för en måttgrupp finns alltid i samma fysiska databas.

Partitioner gör det möjligt för en administratör att bättre hantera en OLAP-kub och förbättra en OLAP-kubs prestanda. Du kan till exempel ta bort eller bearbeta data igen i en partition av en måttgrupp utan att påverka resten av måttgruppen. När du läser in nya data i en faktatabell påverkas bara de partitioner som ska innehålla den nya informationen.

Partitionering förbättrar också bearbetningen och frågeprestanda för OLAP-kuber. SSAS kan bearbeta flera partitioner parallellt, vilket betyder att processor- och minnesresurser på servern kan användas på ett mycket effektivare sätt. När SSAS kör en fråga hämtas, bearbetas och läggs data till från flera partitioner. Endast partitioner som innehåller data som är relevanta för en fråga genomsöks, vilket innebär att mindre in- och utdata behöver hanteras.

Ett exempel på en partitioneringsstrategi är att placera data för varje månad i en månadspartition. I slutet av varje månad placeras alla nya data i en ny partition, vilket resulterar i en naturlig fördelning av data utan överlappande värden.

Sammansättningar

Aggregeringar i en OLAP-kub är försummerade datauppsättningar. De är analoga med en SQL SELECT-instruktion med en GROUP BY-sats. Dessa aggregeringar kan användas när SSAS svarar på frågor för att minska mängden nödvändiga beräkningar, så att svaren snabbt returneras till användaren. Inbyggda aggregeringar i OLAP-kuber minskar mängden aggregeringar som SSAS måste utföra när en fråga körs. Korrekt byggda aggregeringar kan kraftigt förbättra frågeprestanda. Det här är ofta en löpande process som pågår under OLAP-kubens hela livslängd i takt med att frågorna och användningen förändras.

En basuppsättning med aggregeringar skapas ofta, som kan användas för de flesta frågor som körs mot OLAP-kuben. Aggregeringar skapas för varje partition för en OLAP-kub i en måttgrupp. När en aggregering skapas, läggs vissa attribut för dimensioner till i den försummerade datauppsättningen. Användarna kan snabbt fråga data baserat på dessa aggregeringar när de bläddrar igenom OLAP-kuben. Aggregeringar måste utformas noga eftersom antalet potentiella aggregeringar är så stort att det skulle krävas orimligt mycket tid och utrymme att skapa alla.

Service Manager använder följande två alternativ när den skapar och utformar sammansättningar i Service Manager OLAP-kuber:

• Prestandaförbättring
• Användningsbaserad optimering

Alternativet för prestandaförbättring definierar hur många aggregeringar som skapas i antal procent. Om du till exempel använder det rekommenderade standardvärdet på 30 för det här alternativet, betyder det att aggregeringar skapas så att OLAP-kubens prestanda förbättras med 30 procent. Detta betyder dock inte att 30 procent av de möjliga aggregeringarna skapas.

Användarbaserad optimering gör det möjligt för SSAS att logga dataförfrågningarna så att informationen läggs till i aggregeringsdesignprocessen när en fråga körs. Därefter granskar SSAS informationen och rekommenderar vilka aggregeringar som bör skapas för att uppnå bästa uppskattade prestanda.

Service Manager kubpartitionering

Varje måttgrupp i en kub är uppdelad i partitioner och varje partition definierar en del av de faktadata som läses in i en måttgrupp. SQL Server Analysis Services (SSAS) på SQL Server Standard Edition tillåter endast en partition per måttgrupp, medan flera partitioner tillåts i Enterprise Edition. Partitionerna märks inte alls för slutanvändaren, men de har stor påverkan på prestanda och skalbarhet. Exempelvis kan partitionerna bearbetas separat eller parallellt. De kan ha olika sammansättningsdesigner. En partition kan ombearbetas utan att övriga partitioner i en måttgrupp påverkas. Dessutom genomsöks endast de partitioner som innehåller nödvändiga data för en fråga automatiskt av SSAS, vilket kan förbättra frågeprestanda avsevärt.

Kubpartitionering utförs vid varje körning av underhållsjobb för datalager, vilket som standard sker varje timme. Den specifika processmodul som körs kallas för ManageCubePartitions. Den körs alltid efter steget CreateMartPartitions. Dessa beroendedata lagras i tabellen infra.moduletriggercondition.

Det huvudsakliga DLL-biblioteket (Dynamic Link Library), som hanterar partitionering, finns i lagerverktyget DLL, Microsoft.EnterpriseManagement.Warehouse.Utility, i klassen PartitionUtil. Mer specifikt finns det en ManagePartitions()-metod i klassen som hanterar allt partitionsunderhåll. DLL för underhåll av informationslager, Microsoft.EnterpriseManagement.Warehouse.Maintenance och DLL för datalagerbaserad analysbearbetning (OLAP), Microsoft.EnterpriseManagement.Warehouse.Olap, anropar båda Microsoft.EnterpriseManagement.Warehouse.Utility för att hantera partitioner under underhåll och kubdistribution. Den faktiska partitionshanteringen sker därför i den gemensamma DLL-filen för datalagerverktyg för att undvika att logik eller kod dupliceras.

Vid kubpartitioneringsunderhåll utförs följande åtgärder:

• Skapa partitioner
• Borttagning av partitioner
• Uppdatering av partitionsgränser

För att göra detta, Structured Query Language (SQL) tabell etl. TablePartition läse för att fastställa alla faktapartitioner som har skapats för en måttgrupp. Följande åtgärder utförs:

1. Kubbearbetningen startas för varje måttgrupp i kuben
2. Alla partitioner hämtas från tabellen etl.TablePartition för måttgruppen
3. Alla partitioner som finns i måttgruppen men som saknas i tabellen etl.TablePartition tas bort
4. Alla nya partitioner som har skapats och som endast finns i tabellen etl.TablePartition läggs till
5. Alla partitioner som kan ha ändrats uppdateras genom att varje partition matchas mot RangeStartDate och RangeEndDate i tabellen etl.TablePartition

Kom ihåg följande när det gäller kubbearbetning:

• Endast måttgrupper som är riktade mot fakta innehåller flera partitioner i SQL Server Standard Edition. Som standard innehåller alla måttgrupper och dimensioner endast en partition. Det innebär att den partitionen inte har några gränsvillkor.
• Partitionsgränserna definieras av en frågebindning som baseras på datumnycklar som matchas mot datumnycklarna för motsvarande faktapartition i tabellen etl.TablePartition.

Service Manager OLAP-kubdistribution

Distribution av OLAP-kuber (Online Analytical Processing) använder Service Manager distributionsinfrastruktur för att skapa OLAP-kuber i databasen SQL Server Analysis Services (SSAS).

Ett distribuerbart objekt returnerar alltså en utvecklare med en samling resurser som serialiseras används för att skapa OLAP-kuben i SSAS-databasen. För OLAP-kuber är namnet på det distribuerbara objektet CubeDeployable för elementet SystemCenterCube och CubeExtensionDeployable för elementet CubeExtension. Distribueraren för båda elementen är CubeDeployer.

I tabellen dbo.Selector i DWStagingAndConfig-databasen finns en post för båda hanteringspaketelementen SystemCenterCube och CubeExtension. Distributionsmotorn använder dessa metadata om ytterligare distributionsbearbetning behövs för ett hanteringspaketelement när hanteringspaketet importeras till datalagret via MPSync-jobbet

Distributioner använder api:et (Analysis Management Objects) för programprogrammering (API) för att skapa och ändra alla kubkomponenter i SSAS-databasen. AMO används i frånkopplat läge eftersom CubeDeployable-elementet inte har någon anslutning till SSAS-databasen. Om du arbetar med AMO i frånkopplat läge kan du skapa hela trädet med AMO-objekt utan att upprätta någon anslutning till servern. Service Manager serialiserar sedan hierarkin för objekt som strömresurser och kopplar dem till distributionsobjektet som skickas tillbaka till distributionsinfrastrukturen. Distributionsobjektet avserialiseras sedan. Det upprättar då en anslutning till SSAD-databasen och skapar objekten genom att skicka lämpliga förfrågningar till servern.

Det går bara att serialisera större objekt. I AMO (Analysis Management Objects) betraktas större objekt som klasser som representerar ett fullständigt objekt som en fullständig entitet och inte som en del av ett annat objekt. Viktiga objekt är till exempel Server, Kub och Dimension, som alla är fristående entiteter. DimensionAttribute är däremot inte ett större objekt eftersom det bara kan skapas som en del av ett överordnat större Dimension-objekt. DimensionAttribute är därför ett mindre objekt. Utformningen av OLAP-kuben är främst avsedd för att skapa alla större objekt som behövs för kuber, tillsammans med eventuella beroende mindre objekt. Dessa huvudobjekt är de objekt som kommer att serialiseras och slutligen deserialiseras innan objekten skapas i SSAS-databasen.

Resurser som omsluter större objekt måste skapas i en viss ordning för att distributionen ska kunna slutföras och uppfylla OLAP-kubelementens krav på beroenden. I följande två listor visas distributionsordningen för elementen SystemCenterCube respektive CubeExtension.

1. DataSourceView-element
2. dimensionselement
3. datumdimensionselement
4. kubelement
5. DataSourceView-element
6. kubelement

Service Manager OLAP-kubbearbetning

När en OLAP-kub (Online Analytical Processing) har distribuerats och alla dess partitioner har skapats är den redo att bearbetas så att den kan visas. Bearbetning av en kub är det sista steget efter ETL-körningar (extrahering, transformering och inläsning). Dessa steg vidtas som följer:

1. Extrahera: Extrahera data från källsystemet
2. Transformera: Använd funktioner för att anpassa data till ett standarddimensionellt schema
3. Läs in: Läs in data i dataarkivet för förbrukning
4. Process: Läs in data från data mart till OLAP-kuben för surfning

En OLAP-kub bearbetas när alla aggregeringar för kuben har beräknats och kuben laddats med dessa aggregeringar och data. Dimensioner och faktatabeller läses, och data beräknas och läses in i kuben. När du designar en OLAP-kub måste bearbetningen planeras noggrant eftersom en bearbetning av miljontals poster kan ha en betydande inverkan på produktionsmiljön. En fullständig process av alla partitioner i en sådan miljö kan ta allt från dagar till jämna veckor, vilket kan göra Service Manager infrastruktur och kuber oanvändbara för slutanvändare. En rekommendation är att inaktivera bearbetningsschemat för alla kuber som inte används för att reducera överbelastningen i systemet.

Bearbetning av OLAP-kuber består av två skilda uppgifter:

1. Dimensionsbearbetning
2. Partitionsbearbetning

Varje OLAP-kub har ett motsvarande bearbetningsjobb i Service Manager-konsolen och körs enligt ett användarkonfigurerbart schema. De olika typerna av bearbetningsuppgifter beskrivs i följande avsnitt.

Dimensionsbearbetning

När en ny dimension läggs till i databasen SQL Server Analysis Server (SSAS) måste en fullständig process köras på dimensionen för att den ska få ett fullständigt bearbetat tillstånd. När en dimension har bearbetats finns det dock ingen garanti för att den kommer att bearbetas igen när en annan kub som riktas mot samma dimension bearbetas. Genom att inte automatiskt ombearbeta dimensionen förhindrar Service Manager från att bearbeta om varje dimension för varje kub. Det har särskilt stor effekt om dimensionen nyligen har bearbetats, eftersom det inte är troligt att det finns nya data som ännu inte bearbetats. För att optimera bearbetningseffektiviteten finns det en singleton-klass som definieras i hanteringspaketet Microsoft.SystemCenter.Datawarehouse.OLAP.Base med namnet Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval. Följande är ett exempel på den här klassen:

<!-- This singleton class defines the minimum interval of time in minutes that must elapse before a shared dimension is reprocessed. -->   
<ClassType ID="Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval" Accessibility="Public" Abstract="false" Base="AdminItem!System.AdminItem" Singleton="true">  
<Property ID="IntervalInMinutes" Type="int" Required="true" DefaultValue="60"/>  
</ClassType>  

Den här singleton-klassen innehåller en egenskap, IntervalInMinutes, som beskriver hur ofta en dimension ska bearbetas. Standardvärdet för egenskapen är 60 minuter. Om en dimension till exempel bearbetades kl. 15:05 och en annan kub som har samma dimension som mål bearbetas kl. 15:45 bearbetas inte dimensionen på nytt. En nackdel med denna metod är att det finns en ökad risk för dimensionsnyckelfel. En återförsöksmekanism hanterar dimensionsnyckelfel för att bearbeta om dimensionen och sedan kubpartitionen. Mer information om bearbetningsfel finns i avsnittet "Vanliga problem med felsökning och felsökning".

När en dimension har bearbetats fullständigt körs inkrementell bearbetning med ProcessUpdate . Den enda andra gången som ProcessFull körs är när ett dimensionsschema ändras, eftersom det resulterar i att dimensionen återgår till ett obearbetat tillstånd. Kom ihåg att om ProcessFull utförs på en dimension, kommer alla berörda kuber och deras partitioner därefter att finnas i ett obearbetat tillstånd och de måste bearbetas fullständigt vid nästa schemalagda körning.

Partitionsbearbetning

Partitionsbearbetning är en krävande uppgift som kräver en del planering eftersom ombearbetningar av stora partitioner går mycket långsamt och slukar stora processorresurser på servern som fungerar som värd för SSAS. Partitionsbearbetning tar i allmänhet längre tid än dimensionsbearbetning. Till skillnad från vid dimensionsbearbetning har bearbetning av en partition inga sidoeffekter på andra objekt. De enda två typerna av bearbetning som utförs på System Center – Service Manager OLAP-kuber är ProcessFull och ProcessAdd.

I likhet med dimensionerna krävs att en ProcessFull-uppgift för partitionen är i ett tillstånd där den kan ta emot förfrågningar för att det ska gå att skapa nya partitioner i en OLAP-kub. Eftersom en ProcessFull-uppgift är en kostsam åtgärd bör du bara utföra den när det är nödvändigt, till exempel när du skapar en partition eller om en rad har uppdaterats. I scenarier där rader har lagts till och inga rader har uppdaterats kan Service Manager utföra en ProcessAdd-uppgift. För att göra detta använder Service Manager vattenstämplar och andra metadata. Specifikt tillfrågas tabellerna etl.cubepartition respektive etl.tablepartition för att fastställa vilken typ av bearbetning som ska utföras.

Följande diagram visar hur Service Manager avgör vilken typ av bearbetning som ska utföras baserat på vattenstämpeldata.

När en ProcessAdd-uppgift utförs begränsar Service Manager frågans omfattning med hjälp av vattenstämplar. Om värdet för InsertedBatchId till exempel är 100 och värdet för WatermarkBatchId är 50 laddas bara data från datamarten där InsertedBatchId är större än 50 och mindre än 100.

Slutligen är det viktigt att observera att Service Manager inte stöder manuell bearbetning av OLAP-kuber med SSAS eller Business Intelligence Development Studio. Bearbetning av kuber utanför metoderna som finns i System Center – Service Manager, inklusive Service Manager-konsolen och Service Manager cmdletar, uppdaterar inte vattenstämpeltabellerna. Det finns därför en risk för att det kan bli problem med dataintegriteten. Om kuben har bearbetats om manuellt av misstag kan det eventuellt åtgärdas genom att återföra OLAP-kuben till obearbetat tillstånd manuellt med samma metod. Nästa gång Service Manager bearbetar kuben utför den automatiskt en ProcessFull-uppgift eftersom partitionerna är i ett obearbetat tillstånd. Det medför att alla vattenstämplar och metadata uppdateras korrekt, så att alla eventuella problem med dataintegriteten åtgärdas.

Underhålla Service Manager OLAP-kuber

Informationen i följande avsnitt beskriver metodtips för underhåll för OLAP-kuber (Online Analytical Processing).

Bearbeta analysis services-dimensioner med jämna mellanrum

SQL Server Analysis Services (SSAS) rekommenderar att SSAS-dimensioner bearbetas fullständigt regelbundet. Prestanda för frågor och kuber kan försämras med tiden, men förbättras av en fullständig ombearbetning av dimensioner som innebär att indexen byggs om och datalagringen av multidimensionella data optimeras. Det liknar regelbunden defragmentering av en hårddisk i en dator.

En nackdel med att helt bearbeta en SSAS-dimension är dock att alla berörda OLAP-kuber blir obearbetade, och de måste också bearbetas fullständigt för att returnera dem till det tillstånd där du kan fråga dem. Service Manager bearbetar inte uttryckligen SSAS-dimensioner. utan du väljer när du vill utföra denna underhållsaktivitet.

Minnesöverväganden

Om du kör alla ETL-åtgärder (ETL) och OLAP-kubfunktioner på en server bör du noga överväga minnesbehoven för operativsystemet, informationslagret och SSAS för att säkerställa att servern kan hantera alla dataintensiva åtgärder som kan köras samtidigt. Detta är särskilt viktigt eftersom bearbetning av OLAP-kuber är en minnesintensiv åtgärd.

Nästa steg

• Modellera OLAP-kuber i hanteringspaket.