forretning lager Accelerator
Business Lageracceleratoren læser data direkte fra hukommelsen. Tænk på det, som om du surfer på internettet på en opkaldsforbindelse versus en fiberforbindelse. Dial up er som traditionelt at have forespørgsler læst fra databasen, mens fiber er som at læse fra hukommelsen. Når slutbrugere begynder at klage over den hastighed, hvor forespørgsler vises, og InfoCubes allerede er blevet præstationsindstillet så meget som muligt, kan det være tid til at investere i Forretningslageracceleratoren. Det er ikke nødvendigt at foretage Transporter eller ændringer af OLAP-systemet. Det tjener blot som et hukommelseslager, der leder forespørgsler til at læse fra hukommelsen på tidspunktet for udførelsen. Slutresultatet er meget hurtigere behandling og en mere produktiv arbejdsstyrke.
hvor nemt er det at få forespørgsler til at køre hurtigere? Nå, en BV-backend-bruger ville gå ind i transaktionskode RSDDB (eller hvis du kører og ældre version af BV, prøv RSDDBIAMON2) og indeksere den underliggende InfoCube i hukommelsen. Det er en to-trins proces, der forekommer i baggrunden.
- for det første indlæses kubestrukturen i hukommelsen.
- når strukturen er indekseret i hukommelsen, er den fyldt med en kopi af dataene fra databasen. Den indledende indeksering tager noget tid (mindst en time afhængigt af lydstyrken), men alle efterfølgende roll ups (dataopdateringer) vil behandle hurtigt. Hvis der indlæses nye data i InfoCube, skal terningen rulles op med det samme. Dette er ligesom et aggregat, der skal rulles op for at opdatere de eksisterende data med de nyligt indlæste data. Det er vigtigt at rulle op til BVA for at forespørge om de nyeste data.
du undrer dig måske over, hvad der sker, hvis BVA nogensinde går ned. Det er smart nok til automatisk at kontrollere, om indekset på en bestemt terning er aktivt eller ej. Hvis den er inaktiv, rammer den bruger, der kører forespørgslen, databasen i stedet for at læse fra indekset. Dataene vil stadig være tilgængelige via traditionelle databaseforespørgsler, bare ikke ved hastigheder!
de eneste risici, der kan opstå i dit SAP-miljø, er JOBFEJL på grund af systemjobkollisioner forårsaget af tabellåsning. For eksempel, hvis 0MATERIAL kører sin attributændringskørsel, og en InfoCube, der indeholder det samme objekt 0MATERIAL, opdateres til BVA samtidigt, vil BVA-rullen mislykkes. BV-systemet har altid forrang og er smart nok til at vide, at BVV er mere en bolt på enheden. Når Attributændringskørslen er afsluttet, kan roll up-trinnet let gentages. Det er derfor, det er så vigtigt at time dine roll ups korrekt for at reducere fejl til den natlige behandling. Du kan tænke på at have skrivebeskyttet adgang til BV-systemet.
7.3-opgraderingen åbner op for nye funktioner. Hvis DSO ‘en er version 7.2 og kører oven på 7.3, kan du indeksere DSO’ er! Nå, ikke direkte … en funktion er blevet tilføjet til BV 7.3, hvor du kan indlæse direkte i BVA og omgå databasen helt. Så hvis du har nogle DSO ‘ er, du gerne vil indeksere, skal du kun oprette en InfoCube.
Trin 1: Opret en ny InfoCube med den DSO, du vil indeksere som skabelon. Vælg fra rullelisten “InfoCube gemmer kun sine data i”.
Trin 2: Her kan vi se kubens struktur. Det tager DSO ‘ erne karakteristiske felter og kaster det hele i Dimension 1. Alle DSO ‘ erne nøgletal bliver sat i mappen nøgletal i terningen. Aktiver InfoCube.
Trin 3: I transaktion RSDDB (ny til 7.3, BVA-transaktion) vi kan se indekset er rødt, hvilket betyder, at det er i færd med at blive oprettet (1).
Trin 4: i SM37 kan vi se, at indeksaktiveringen finder sted
lad os bore ind i denne joblog og se, hvad der faktisk foregår bag kulisserne:
Trin 5: Rsddb Indeksinfo (Bemærk f-tabellen har en Indeksstørrelse på 0, da vi ikke har kørt DTP fra DSO til kun InfoCube)
Trin 6: Kør DTP, når du er færdig, Administrer kun kuben
Trin 7: Når vi går tilbage til RSDDB og går til indeksinfo, kan vi se, at siden DTP er afsluttet, har f-tabelindekset 10.528 poster, der sidder i BVA.
ofte stillede spørgsmål:
1. Hvad gør vi, hvis der tilføjes regelmæssige belastninger til DSO?
du bliver nødt til at oprette en proceskæde, der starter en DTP, når du har indlæst DSO ‘ en. Du er nødt til at holde den eneste kube så nylig som muligt. Sørg for at prøve at overføre DSO delta-data til kun kube så ofte som muligt.
2. Skal vi køre DTP fra DSO til cube efter hver ny anmodning til DSO?
ja, den eneste kube vil kun skrive dataene til hukommelsen, når den eneste kubebelastning er startet. Ellers har cube ingen anelse om, at DSO ‘ en har nye data. DTP kører meget hurtigt, da den indlæses i hukommelsen, så kør den ofte.