Lageradministration i Dataverse og programmer til finans og drift

Efterhånden som organisationer accelererer deres digitale transformationsrejser, bliver evnen til at administrere data effektivt en strategisk forretningsnødvendighed. Med fremkomsten af AI-drevne applikationer og Copilot-drevne arbejdsgange genererer og forbruger virksomheder data med hidtil usete hastigheder. Disse data giver næring til innovation, giver mulighed for tilpassede oplevelser og understøtter kritisk beslutningstagning – men kun hvis de styres og gemmes intelligent.

For at understøtte disse skiftende forretningsbehov skal organisationer vedtage en proaktiv strategi for lagerstyring. Dette sikrer, at data, der ikke længere er nødvendige for den daglige drift, håndteres ansvarligt, hvilket frigør kapacitet til arbejdsbelastninger af høj værdi, reducerer driftsfriktion og tilpasser sig overholdelses- og revisionskrav.

Fra et teknisk synspunkt forbedrer effektiv lagerstyring i Dataverse Dynamics 365 systemets ydeevne, forbedrer omkostningseffektiviteten og sikrer overholdelse af politikker for langsigtet opbevaring (LTR). Begge platforme tilbyder værktøjer og automatiseringsfunktioner, der giver organisationer mulighed for at administrere lager.

Ved at implementere de strategier, der er beskrevet i denne artikel, kan virksomheder reducere supportomkostningerne, strømline overholdelse af angivne standarder og frigøre større værdi fra deres forretningsapplikationer – og forvandle storage fra en begrænsning til en konkurrencefordel.

Vigtigste fordele

Effektiv lagerstyring i Dataverse Dynamics 365 giver flere vigtige fordele, der adresserer almindelige kundeproblemer og forbedrer den overordnede driftseffektivitet.

  • Øget overholdelse af LTR: Effektiv lagerstyring sikrer, at data gemmes i overensstemmelse med LTR-politikker. Dette hjælper ikke kun med at opfylde lovkrav, men sikrer også, at kritiske data bevares og er tilgængelige, når det er nødvendigt.

  • Forbedret ydeevne: Ved at optimere lagerstyring kan organisationer forbedre ydeevnen af deres systemer betydeligt. Effektiv lagerallokering og -administration reducerer ventetiden og forbedrer hastigheden af datahentning, hvilket fører til mere jævn og hurtigere drift.

  • Øget omkostningseffektivitet: Effektiv lagerstyring giver organisationer mulighed for at fokusere på data af høj værdi ved at strømline og rydde op i deres lagerlandskab. Ved kun at bevare det, der er nødvendigt, kan virksomheder optimere deres lagerfodaftryk, hvilket fører til smartere ressourceudnyttelse og omkostningseffektiv skalerbarhed.

Baggrund

Efterhånden som organisationer vokser og digitaliserer flere af deres aktiviteter, stiger mængden af forretningsdata, der er gemt i systemer som Dataverse og Dynamics 365, støt. Dette omfatter ikke kun aktive transaktionsdata, men også historiske optegnelser, der skal opbevares til revisions-, lovgivningsmæssige eller forretningskontinuitetsformål. Over tid kan denne akkumulering føre til forringelse af ydeevnen, øgede driftsomkostninger og stigende lageromkostninger – især når data, der ikke længere bruges aktivt, forbliver på lagerniveauer med høj ydeevne.

En veldefineret strategi for lagerstyring hjælper organisationer med at løse disse udfordringer ved at identificere data, der kan arkiveres, ryddes op eller flyttes til billigere og læseoptimeret lager. Dette er vigtigt for overholdelsesscenarier, hvor data skal forblive uforanderlige, med lav adgang og skrivebeskyttede, f.eks. økonomiske optegnelser, revisionslogfiler eller lovpligtige arkiver. At sikre, at sådanne data opbevares på en måde, der overholder reglerne, uden at påvirke ydeevnen af live-systemer, er et centralt krav for mange virksomheder.

Ved at bruge de værktøjer og strategier, der er tilgængelige på begge platforme, kan organisationer få bedre synlighed i deres lagerfodaftryk, reducere unødvendigt forbrug og sikre, at overholdelseskritiske data håndteres korrekt.

Denne artikel beskriver praktiske tilgange til lagerstyring, der hjælper kunderne med at tilpasse deres dataopbevaringspraksis til forretningsmæssige og lovgivningsmæssige behov. Dette forbedrer systemets ydeevne, reducerer driftsomkostninger og sikrer, at overholdelsesforpligtelser opfyldes uden kompromis.

Hvorfor vi gemmer data

For at vælge og optimere det rigtige dataopbevaringsmønster for dine data er det værdifuldt at reflektere over årsagerne til og anvendelserne af vores opbevaring af data.

Operationelle data

Med en forretningsapplikation er operationelle data det, der bruges til at spore salg eller økonomiske eller forsyningskædehandlinger.

Disse data skal tilgås i realtid, hvilket understøtter kunde- og interne driftsprocesser, der registrerer detaljerede handlinger, f.eks. interaktioner med kunder, ordrer eller lageraktiviteter.

Over tid kan driftsdata bevæge sig fra at blive brugt aktivt til sjældent brugt. Dataene skal muligvis være tilgængelige i næsten realtid for at hjælpe en kunde med en ordre eller i en supportsag. Overvej f.eks. følgende scenarier.

  • En kunde afgiver en ordre, mens en anden kunde, som ikke har interageret med virksomheden i et stykke tid, afgiver en ordre.
  • Hver ordre, der er afgivet og bliver afsendt, bliver konstant tilgået. Der er også ordrer, der er under en garantiperiode på tre år, som muligvis skal henvises til for support og muligvis kræve refusion.

Dette kan føre til faser med operationelle dataadgangsbehov såsom:

  • Mindre end et år med aktivt tilgåede data.
  • Mindre end tre år med sjældent anvendte data.
  • Mere end tre år, hvis der ikke længere er operationel adgang til data.

Realtidskarakteren af operationel lagring gør det relativt dyrt sammenlignet med andet lager, så det er vigtigt at genkende, hvornår data skal tilgås operationelt, og hvornår de ikke gør, for at definere opbevaringsstrategier.

Operationel integration

Som en specialiseret kategori af operationel anvendelse kan det kræves, at data replikeres mellem flere operationelle systemer, herunder mønstre såsom:

  • Bank: Administration af kunderelationer til kundeinteraktioner i frontlinjen og replikering til flere banksystemer. For eksempel har du løbende konti, kreditkort, realkreditlån og kreditkontrolsystemer.
  • Produktion: Kunderelationsstyring til frontlinjeordremodtagelse og virksomhedsressourcestyringssystem til forsyningskædestyring.
  • Politiets nødhåndtering: Styring af kunderelationer til borgerinteraktioner og et udsendelsessystem til politiafdelinger tilbyder implementeringsstyring.

I disse tilfælde kan hvert system have unikke data, det sporer, men der er ofte fælles stamdata, der skal deles mellem systemerne og holdes synkroniseret, hvilket fører til integrationsbehov.

Overvåge data

En virksomhed har typisk et lovmæssigt ansvar for at opbevare data i længere perioder – f.eks. i gennemsnit syv år – til revisionsformål, hvad enten det er internt eller eksternt, f.eks. understøttelse af finansiel revision, myndighedsoplysning eller gennemgang af svindel.

Disse data vil typisk spænde over både data, der er nødvendige til operationelle formål, og data, der ikke længere er nødvendige, da de tillader gennemgang på tværs af datasættet fra ét sted.

Analysedata

Organisationer har behov for at gennemgå og analysere deres virksomheds tilstand. De skal måle og sammenligne statistikker over tid og spænde over flere eller alle dele af virksomheden.

De store perioder og bredden af data, hvor denne analyse kan forekomme, fører til behovet for at replikere operationelle data til specialiserede analyseværktøjer. Dette undgår komplekse analyser i at påvirke driftssystemernes ydeevne, men tillader også analyse på tværs af datasæt, der går ud over den periode, hvor data er nødvendige operationelt. Det kan f.eks. være, at du skal sammenligne data over syv år i stedet for over et til to år. Forskellige analysebehov kan dog have brug for de fulde dataopbevaringsperioder eller kun spænde over de data, der opbevares i driftssystemer.

Analysedata giver typisk mulighed for aggregering af data på tværs af flere dele af virksomheden og kombinerer data fra flere systemer.

Flow af data

Dataene af disse typer flyder typisk over tid fra driftsdata og derefter til transaktionsdata eller historiske data, som vist på følgende billede.

Strømmen af data.

Forskellige typer opbevaring

Dataverse Opbevaring typer

Dataverse Organiserer lagerplads i tre hovedkategorier, hver med forskellige brugsmønstre og faktureringskonsekvenser.

Lagertype Description Almindelige use cases
Opbevaring af database Gemmer strukturerede data i tabeller – standard og brugerdefinerede. Forretningsposter, metadata, relationer og konfigurationer
Fillager Gemmer vedhæftede filer og binære data. Vedhæftede filer, billeder, dokumenter, der er uploadet via Power Apps
Opbevaring af logfiler Gemmer overvågningslogge og plugin-sporingslogfiler. Sporing af ændringer, overvågning, diagnosticering og overholdelse af angivne standarder

Lagertyper for Finance and Operations-platforme

Finans- og driftslagring administreres separat, men bliver i stigende grad integreret i økosystemet Power Platform . Det omfatter følgende lagertyper.

Lagertype Description Almindelige use cases
Operationel databaselagring Centrale transaktionsdata for økonomi, forsyningskæde, menneskelige ressourcer og meget mere Finansposter, lager, debitorordrer
Opbevaring af dokumentstyring Binære store objekter (blobs), der er gemt i Azure Blob Storage Fakturaer, kvitteringer, scannede dokumenter
Telemetri og diagnosticeringslogfiler Systemlogfiler og telemetridata Overvågning af ydeevne, problemdiagnosticering.

Delte og integrerede lagerscenarier

  • Dobbeltskrivningslager

    • Tillader synkronisering i realtid mellem Dataverse og programmer til finans og drift.
    • Kræver omhyggelig rolle- og kapacitetsstyring for at undgå dobbeltarbejde eller overforbrug.

  • Langsigtet fastholdelse (LTR)

    • Flytter historiske data til en MDL (Managed Data Lake).
    • Reducerer det primære lagerforbrug, samtidig med at overholdelse af angivne standarder og analyseadgang opretholdes.
    • Integreres med:
      • Hurtig søgning (Dataverse-oprindelig søgning)
      • OneLake (strukturbaseret analyse)
      • Synapse Link (brugerdefineret lake-analyse)

Sådan vokser dine data over tid

Efterhånden som organisationer skalerer deres brug af Dataverse og Dynamics 365 Finance and Operations-platformen, bliver datavækst både et tegn på succes og en strategisk udfordring. Det, der begynder som et slankt, transaktionsdatasæt, kan hurtigt udvikle sig til en kompleks dataejendom i flere lag. Dette afsnit udforsker fem vigtige drivkræfter for datavækst og deres konsekvenser for lagring, ydeevne og styring.

Brug af datalagring på driftsdata

For at låse op for indsigt fra driftssystemer bruger Azure Synapse mange organisationer Link, OneLake eller dataeksport til at replikere data fra Dataverse og finans- og driftsapps til et analysesystem. Selvom dette understøtter avanceret rapportering og AI-arbejdsbelastninger, introducerer det også:

  • Redundant lager på tværs af drifts- og analyselag

    Data duplikeres ofte mellem de operationelle og analytiske miljøer. Denne redundans øger det samlede lagerforbrug og kan føre til højere omkostninger, især hvis historiske data opbevares på ubestemt tid i begge systemer.

  • Schemaduplikering og overhead til versionsstyring

    For at opretholde konsistens mellem systemer skal organisationer replikere skemaændringer – f.eks. nye felter og omdøbte kolonner – på tværs af både drifts- og analyselag. Dette øger kompleksiteten i datastyringen og øger risikoen for skemaafvigelse, som kan nedbryde downstream-rapporter eller -modeller.

  • Øget fastholdelse af historiske data til trendanalyse

    Analytiske systemer opbevarer typisk data i længere perioder for at understøtte trendanalyse, prognoser og lovpligtig rapportering. Selvom denne langsigtede opbevaring er værdifuld, kan den føre til oppustede datasæt, hvis den ikke håndteres med korrekte arkiverings- og niveauinddelingsstrategier.

Datalagring er afgørende for analyser, men uden livscykluspolitikker kan det fordoble eller tredoble dit lagerfodaftryk.

Brug af søgning på data

Funktioner som Dataverse søgning, Copilot-indeksering og relevanssøgning kræver indeksering af store mængder strukturerede og ustrukturerede data. Disse indekser ofte:

  • Forbrug log- og databaselager

    Søgeindekser gemmes i både log- og databaselager. Efterhånden som flere tabeller og felter markeres som søgbare, vokser indeksstørrelsen proportionalt. Dette kan have en betydelig indvirkning på det samlede lagerforbrug, især i miljøer med store mængder poster eller hyppige skemaændringer.

  • Bevar selv for ubrugte eller udfasede tabeller

    Selv når visse tabeller udfases eller ikke længere bruges aktivt, kan deres tilknyttede søgeindekser bestå, medmindre de eksplicit fjernes. Dette fører til unødvendigt lagerforbrug og kan komplicere kapacitetsplanlægningen.

  • Er ofte duplikeret på tværs af miljøer, f.eks. udviklings-, test- og produktionsmiljøer

    Søgeindekser replikeres typisk på tværs af udviklings-, test- og produktionsmiljøer. Selvom dette sikrer ensartet søgefunktion, multiplicerer det også lagerfodaftrykket, især når miljøer ofte klones eller opdateres.

Søgning forbedrer brugervenligheden og AI-paratheden, men indeksoppustethed er en tavs bidragyder til lageroverskud.

Aktivering af logning af data

Overvågningslogge, plug-in-sporingslogge og telemetri er afgørende for overholdelse af angivne standarder, fejlfinding og overvågning. Bemærk dog følgende punkter:

  • Loglagring vokser lineært med brug og antal brugere.

    Logdata vokser proportionalt med:

    • Antallet af brugere og deres aktivitetsniveauer
    • Mængden af transaktioner og integrationer
    • Kompleksiteten af forretningslogik som f.eks. plug-ins og arbejdsprocesser

    I miljøer med høj brug kan dette føre til hurtig udvidelse af logtabeller, hvilket forbruger både database- og loglagerkvoter.

  • Opbevaringsstandarder er ofte for generøse, f.eks. 90 dage eller mere.

    Som standard opbevarer mange logføringsfunktioner data i længere perioder, f.eks. 90 dage eller mere. Selvom dette understøtter langsigtet sporbarhed, kan det resultere i unødvendigt lagerforbrug, især når logge ikke aktivt gennemgås eller eksporteres.

  • Systemgenererede logfiler faktureres til kunden i Dataverse.

    I Dataverse tælles systemgenererede logfiler, herunder overvågningslogge og plug-in-sporingslogge, med i kundens lagerberettigelse. Det betyder, at uden ordentlige oprydnings- eller eksportstrategier kan logning direkte bidrage til lageroverskud og øgede licensomkostninger.

Logføring kan ikke forhandles for regulerede brancher, men skal parres med opbevarings- og eksportstrategier, f.eks. Azure Monitor eller Log Analytics.

At have flere kopier af produktionsmiljøet

For at understøtte udvikling, test, oplæring og fejlfinding opretter kunderne ofte sandkassemiljøer eller klonede miljøer. Hvert eksemplar:

  • Replikerer det fulde data- og indeksfodaftryk.
  • Kan omfatte ikke-indlysende afhængigheder som søgeindekser, overvågningslogge og metadata.
  • Ryddes sjældent op efter brug.

Miljøspredning er en vigtig drivkraft for lageromkostninger og kompleksitet. Styringspolitikker og automatisering er nøglen til inddæmning.

Optimering af forespørgsler på data

Efterhånden som datamængderne vokser, og programresponsiviteten bliver kritisk, implementerer kunder og ISV'er ofte forskellige teknikker til optimering af forespørgsler for at forbedre ydeevnen i Dataverse og Dynamics 365. Disse strategier er især almindelige i rapporterings-, analyse- og integrationstunge scenarier.

For at forbedre ydeevnen opretter kunder og ISV'er ofte:

  • Brugerdefinerede indekser og materialiserede visninger

    Disse bruges til at fremskynde udførelsen af forespørgsler ved at forudberegne joinforbindelser eller sammenlægninger. De er nyttige i scenarier, der involverer komplekse filtre eller store datasæt.

  • Denormaliserede tabeller til rapportering

    For at forenkle rapporteringen og reducere forespørgselskompleksiteten opretter udviklere ofte samkopierede versioner af relationsdata. Disse tabeller reducerer behovet for kørselsjoinforbindelser og forbedrer dashboardets ydeevne.

  • Cachelagring af lag eller aggregater

    Ofte anvendte data er nogle gange forudaggregeret eller cachelagret i mellemliggende tabeller eller eksterne lagre for at reducere belastningen på den primære database.

Selvom disse forbedrer reaktionsevnen, gør de også:

  • Øg lagerforbruget

    Hvert optimeringslag introducerer flere datastrukturer, uanset om det er en kopi af eksisterende data i et denormaliseret format, en forudberegnet visning eller en cachetabel. Disse strukturer duplikerer ofte data, der allerede er gemt andre steder, hvilket fører til et større samlet lagerfodaftryk. I miljøer med strenge lagerkvoter eller omkostningsbaserede licensmodeller Dataverse kan dette hurtigt eskalere til undgåelige overforbrug.

  • Kan blive forældreløse i takt med, at apps udvikler sig

    Efterhånden som programmer udvikler sig, refereres der muligvis ikke længere til nogle optimeringsartefakter af aktive rapporter, dashboards eller integrationer. Disse forældreløse objekter fortsætter med at forbruge lagerplads og kan endda gøre systemdriften langsommere, f.eks. under sikkerhedskopiering eller indeksering, hvis de ikke identificeres og fjernes. Uden regelmæssige revisioner kan de akkumuleres ubemærket og underminere selve de præstationsgevinster, de blev skabt til at understøtte.

Optimering af forespørgsler er afgørende for skalering, men skal afbalanceres med lagerhygiejne og telemetridrevet justering.

Indekser og deres indvirkning på lagring

Indekser er afgørende for at forbedre ydeevnen for forespørgsler og bruge hurtig datahentning i store datasæt. I både Dataverse og Dynamics 365 Finance and Operations-apps oprettes der automatisk indekser for primære nøgler og felter, der ofte forespørges, og andre brugerdefinerede indekser kan defineres for at understøtte specifikke forretningsscenarier.

Selvom indekser er afgørende for ydeevnen, har de også en direkte indvirkning på lagerforbruget, som ofte undervurderes under løsningsdesign.

Sådan bruger indekser lagerplads

  • Fysisk duplikering af data: Hvert indeks gemmer en kopi af de indekserede kolonner sammen med markører til de tilsvarende rækker. Jo flere kolonner og rækker, der indekseres, jo større er indeksstørrelsen.

  • Vækst med datamængde: Efterhånden som den underliggende tabel vokser, vokser indekset også. I miljøer med mange transaktioner kan indekser vokse hurtigt, især på store, denormaliserede tabeller eller tabeller med hyppige indsættelser og opdateringer.

  • Flere indekser pr. tabel: Det er almindeligt, at en enkelt tabel har flere indekser, f.eks. til søgning, filtrering, sortering og joinforbindelser. Hvert andet indeks føjer til det kumulative lagerfodaftryk.

  • Søg indekser i Dataverse: Funktioner som Dataverse søgning og Copilot-indeksering opretter specialiserede indekser, der spænder over flere felter og tabeller. Disse gemmes i DataverseSearch-tabellen og kan optage betydelig plads, især når de bruges på tværs af flere miljøer, f.eks. udviklings-, test- og produktionsmiljøer.

  • Systemgenererede indekser: Nogle indekser oprettes automatisk af platformen, f.eks. til opslagsfelter eller relationer. Disse kan bestå, selvom de tilknyttede tabeller udfases, medmindre de udtrykkeligt fjernes.

Konsekvenser for opbevaring

  • Øget database- og loglager: Indekser bidrager til både database- og loglagerforbrug, hvilket kan påvirke licensomkostningerne i Dataverse.
  • Miljøduplikering: Når miljøer kopieres eller opdateres, duplikeres alle indekser, hvilket forstærker lagerforbruget på tværs af udviklings-, test- og produktionsmiljøer.
  • Vedligeholdelsesomkostninger: Indekser skal opdateres, når data ændres, hvilket kan øge skriveventetiden og ressourceforbruget.

Synkronisering på serversidens indvirkning på lageret

Synkronisering på serversiden giver Dataverse mulighed for problemfri integration af e-mails, aftaler og opgaver mellem Microsoft Exchange og Dataverse. Samtidig med at det øger produktiviteten og automatiseringen, bidrager det også til lagerforbruget på følgende måder.

  • Oprettelse af aktivitetspost: Hver synkroniseret mail eller aftale genererer en aktivitetspost i Dataverse, som indeholder metadata, brødtekst og potentielt vedhæftede filer.
  • Lagring af vedhæftede filer: Hvis vedhæftede filer ikke filtreres eller aflastes, gemmes de direkte i Dataverse, hvilket øger lagerforbruget.
  • Overholdelse og opbevaring: Organisationer, der bruger synkronisering på serversiden til sporing af overholdelse af angivne standarder, kan beholde flere data end nødvendigt, hvilket øger lagerpladsen yderligere.
  • Beskyttet indhold: Selv Purview-beskyttede mails, selvom de er begrænsede i indholdssynlighed, genererer stadig pladsholderposter, der bruger plads.

For at håndtere denne påvirkning bør virksomheder implementere opbevaringspolitikker, overveje at aflaste vedhæftede filer og overvåge aktivitetsregistreringsmængder regelmæssigt.

Hvordan kan jeg administrere det stadigt voksende lager?

Uanset om du allerede står over for lageroverskud eller sigter mod at være på forkant med dem, kræver administration af datavækst i Dataverse Dynamics 365 Finance and Operations-platformen en bevidst, politikdrevet tilgang. Dette afsnit skitserer to strategiske indgangspunkter: reaktiv afhjælpning og proaktiv styring.

Der er to mulige scenarier:

  1. Du vil proaktivt anvende bedste praksis til at administrere lager og undgå høje omkostninger i fremtiden.
  2. Du er allerede i en situation, hvor det er nødvendigt at reducere lagerstørrelse og omkostninger.

Anvend bedste praksis til at administrere lagerstørrelse og -omkostninger

Scenarie 1: Du vil proaktivt anvende bedste praksis til administration af lager

Hvis du endnu ikke er i krisetilstand, er det nu, du skal anvende værktøjer og teknikker til at administrere lageret proaktivt.

Konfigurer analyser for dine data

Efterhånden som organisationer vokser, vokser behovet for at udtrække indsigt fra driftsdata uden at påvirke ydeevnen af kerneforretningsapplikationer. Microsoft tilbyder flere måder at tillade analyse af Dataverse og Dynamics 365-data til finans og drift på ved at integrere med din egen datasø eller lagersted.

Her er to effektive muligheder at overveje:

Mulighed 1. Brug Azure Synapse Link – medbring din egen sø

Azure Synapse Link giver dig mulighed for at oprette direkte forbindelse Dataverse til dit eget Azure Data Lake- eller Synapse-arbejdsområde. Dette giver mulighed for replikering af driftsdata i næsten realtid i et analytisk miljø uden at skrive komplekse ETL-pipelines.

Fordele:

  • Kør avancerede analyse- og AI-modeller på live eller næsten live data.
  • Undgå at påvirke dine produktionssystemer af ydeevnen.
  • Brug velkendte værktøjer som T-SQL, Spark eller Power BI til rapportering.

Eksempel på brugseksempel: En detailvirksomhed bruger Synapse Link til at analysere kundernes købsadfærd på tværs af områder og kombinere Dataverse data om kunderelationsstyring med eksterne markedsdata i deres egen sø.

Mulighed 2. Brug OneLake – samlet analyse med Microsoft Fabric

OneLake, som er en del af Microsoft Fabric, giver en samlet datasøoplevelse, hvor du kan gemme og analysere data fra flere kilder, herunder Dataverse og programmer til finans og drift, uden duplikering.

Fordele:

  • Centraliseret lager til alle analytiske arbejdsbelastninger.
  • Oprindelig integration med Power BI Synapse- og AI-tjenester.
  • Forenklet styring og sikkerhed på tværs af datadomæner.

Eksempel på brugstilfælde: En finansiel virksomhed bruger OneLake til at konsolidere driftsdata fra økonomi- og driftsapps og Dataverse med eksterne økonomiske indikatorer, hvilket muliggør realtid, risikomodellering og ledelsesdashboards. Ved at gøre dette kan du afkoble driftsdata fra dine kernesystemer og tillade skalerbare, omkostningseffektive analyser ved at eksportere disse data til deres egne, analytiske miljøer uden at duplikere arbejdsbelastninger eller påvirke ydeevnen.

Værktøjer og teknikker til at reducere lagerpladsen

Dataverse Tilbyder flere indbyggede værktøjer og strategier, der hjælper administratorer med at administrere lageret effektivt og opretholde systemets ydeevne.

Dataverse

Oprydning i miljø og data

  • Slet ubrugte miljøer: Du kan slette et miljø for at genoprette lagerplads og fjerne personligt identificerbare oplysninger (PII).
  • Massesletningsjob: Du kan slette følgende data på én gang:
    • Forældede data eller data, der er irrelevante for virksomheden.
    • Unødvendige test- eller eksempeldata.
    • Data, der er ukorrekt importeret fra andre systemer.

Fil- og tabeloptimering

  • Reducer fillagring ved hjælp af forhåndssøgning: Denne artikel giver dig 15 metoder til bedre at administrere din lagerplads. Du kan bruge en eller flere af disse metoder til at kontrollere det samlede datalagerforbrug. Du kan slette kategorier data efter behov, eller du kan konfigurere massesletningsjob til at køre med de indstillede intervaller. Du kan f.eks. slette noter, vedhæftede filer, importoversigter og andre data.
  • Ryd op i poster fra systemjobtabeller (AsyncOperationBase) og proceslogtabeller (WorkflowLogBase): Hvis din organisation gør stor brug af arbejdsprocesser eller forretningsprocesforløb, vokser disse tabeller (AsyncOperationBase, WorkflowLogBase) over tid og bliver til sidst store nok til at medføre problemer med ydeevnen og forbruge for meget lagerplads i din organisationsdatabase. For WorkflowLogBase kan du konfigurere automatisk at slette fuldførte baggrundsarbejdsgangsjob.

Langtidsopbevaring og arkivering

Optimering af søgeindeks

  • Reducer Dataverse søgning: Du kan reducere lagerstørrelsen ved at udføre alle trinene i Dataverse kapacitetsbaserede lageroplysninger.
  • Reducer størrelsen på DataverseSearch-tabellen: DataverseSearch-tabellen er det kumulative lager, der bruges af søgeindekset Dataverse . Den indeholder data fra alle felter, der kan søges i, hentes og filtreres i de tabeller, du har indekseret for dit miljø. Du kan reducere tabelstørrelsen ved at fjerne søgekolonner, visningskolonner og filterbetingelser for en eller flere tabeller. Du kan slå Dataverse-søgning fra for at fjerne alle indekserede data.
Finans og drift-apps

Programmer til finans og drift giver fleksible muligheder for administration af lager på tværs af produktions- og sandkassemiljøer.

Miljøledelse

  • Begræns antallet af fulde produktionskopier: Du kan reducere det samlede lagerforbrug for programmer til finans og drift ved at fjerne fulde produktionskopier i sandkassemiljøer. Hvis du f.eks. har fem kopier af produktionsmiljøer i en sandkasse, er dit lagerforbrug summen af produktionen plus fem kopier af produktionsmiljøer i en sandkasse.
  • Trim data i sandkassemiljøer: Ved at trimme dataene i et sandkassemiljø kan du reducere det samlede lagerfodaftryk. Du kan følge metoderne nedenfor for at rense dataene i sandkassen.
    • Gendannelsesprocessen giver en åbnings- og trimningsudførelse
    • Skriv T-SQL
    • Skriv X++
  • Udfør en transaktionsfri kopi mellem miljøer: Miljøkopi til programmer til finans og drift har traditionelt involveret fuld databaseduplikering, herunder konfiguration, stamdata og transaktioner, hvilket, selvom det er nyttigt til fejlfinding, øger lagerforbruget betydeligt på tværs af både finans og drift og Dataverse.

Brugerdefineret oprydning og logstyring

  • Skriv tilpassede oprydningsrutiner efter behov: Du kan skrive tilpassede oprydningsrutiner efter behov for din virksomhed for at rense de uønskede data.
  • Undgå at gemme logfiler: Du kan flytte SysDatabaseLog til en mindre transaktionsdatabase for at reducere det samlede lagerfodaftryk.

Arkivering og langtidsopbevaring

Indbyggede oprydningsrutiner

  • Oprydningsrutiner: I Dynamics 365 Finance og Dynamics 365 Supply Chain Management oprydningsrutiner er tilgængelige i forskellige moduler. Oprydningsrutiner giver et overblik over de rutiner, der er tilgængelige i øjeblikket. Når du har kopieret sandkassedatabasen, skal du køre disse oprydningsrutiner proaktivt for at fjerne unødvendige tabeller, f.eks. batchhistorik, logge og detailtransaktionshistorik. Slet forældede eller irrelevante data.
  • Arkiver kreditkorttransaktionsdata: Beskriver et arkiveringsjob Dynamics 365 Commerce , der kan hjælpe med at frigøre plads i databasen ved at arkivere kreditkortbetalingstokens.

Reducer lagerstørrelse og -omkostninger

Scenarie 2: Du er allerede i en situation, hvor det er nødvendigt at reducere lagerstørrelsen og omkostningerne

Vurder, hvad der forbruger lagerplads

  • Brug Power Platform Administration og lagerrapporter for finans og drift til at identificere de mest forbrugende tabeller, filtyper og logfiler.
  • Brug telemetri, hvis det er tilgængeligt, til at tildele forbrug til bestemte apps, brugere eller afdelinger.

Prioriter oprydningskandidater

  • Fokus på:
    • Midlertidige tabeller og integrationstabeller, f.eks. buffere til dobbeltskrivning
    • Overvågningslogfiler: Gem dem i dit eget lager
    • Ubrugte miljøer eller sandkasser
    • Tabte metadata og søgeindekser
    • Slet det, du ikke har brug for, f.eks. massesletning

Brug Synapse Link og OneLake til analytisk rapportering

  • Eksportér analysedataene til Synapse Link.
  • Brug OneLake til at få adgang til de opbevarede data og forretningsdata til rapporterings- og analyseformål.

Anvend langsigtet opbevaring (LTR)

  • Flyt historiske data til en MDL (Managed Data Lake) ved hjælp af LTR-politikker.
  • Oprethold søge- og analyseadgang via Quick Find, Synapse Link eller OneLake.

Bruge sager

Brugsscenarier til lagerstyring i Dataverse økonomi- og driftsmiljøer er afgørende for at optimere databaseplads, forbedre systemets ydeevne og opfylde lovmæssige krav. Nedenfor er nogle typiske scenarier, der viser, hvordan disse strategier kan anvendes:

  • Styring af vækst i historiske data

    • Scenarie: En virksomhed har været live på Dynamics 365 i flere år og har akkumuleret store mængder historiske transaktioner og vedhæftede filer.
    • Handling: Implementer langsigtede opbevaringsstrategier for at bevare inaktive data, reducere størrelsen på den primære database og opretholde overholdelse af overvågningskravene.

  • Compliance-drevet dataopbevaring

    • Scenarie: En reguleret branchekunde skal opbevare økonomiske data eller kundedata i syv til ti år i et manipulationssikkert format.
    • Handling: Brug LTR til at bevare de uforanderlige, skrivebeskyttede data i overensstemmelse med juridiske og lovmæssige krav, samtidig med at forretningsdata holdes slanke uden at gå på kompromis med analyser og rapportering.

  • Optimering af søge- og Copilot-indeks

    • Scenarie: Dataverse Søgning og Copilot-indeksering er aktiveret på tværs af alle miljøer, herunder ubrugte tabeller.
    • Handling: Overvåg søgbare felter, og deaktiver indeksering for tabeller med lav værdi eller udfasede tabeller. Overvåg størrelsen på DataverseSearch-tabellen, og optimer konfigurationer for at reducere log- og databaselageret.

  • Administration af overvågning og telemetri

    • Scenarie: Plug-in-sporingslogge og overvågningslogge vokser hurtigt, hvilket forbruger lagerplads og påvirker ydeevnen.
    • Handling: Eksportér logge til eksterne systemer, f.eks. Azure Monitor, og automatiser oprydning af gamle poster for at bevare synligheden uden at øge lageret.

  • Integration af datalagring og analyse

    • Scenarie: Organisationen replikerer driftsdata til Azure Synapse eller OneLake til analyse, hvilket fører til duplikeret lager.
    • Handling: Brug trinvise eksporter, anvend filtre, og undgå fuld replikering af datasæt for at minimere redundans, samtidig med at du tillader omfattende indsigt.

  • Reduktion af lageroverskud

    • Scenarie: En kunde modtager en meddelelse om overskridelse af sin Dataverse lagerkvote, hvilket medfører uventede omkostninger.
    • Handling: Brug kapacitetsrapporter til at identificere de mest forbrugende tabeller, rydde op i forældede miljøer og fjerne ubrugte vedhæftede filer eller logfiler. Overvej at flytte kolde data – typisk historiske eller sjældent anvendte poster – til lagerniveauer med lavere omkostninger.

  • Optimering af ydeevne i store borde

    • Scenarie: Forretningskritiske processer bliver langsommere på grund af store tabeller.
    • Handling: Arkiver gamle poster, ryd op i systemjob, f.eks. AsyncOperationBase og WorkflowLogBase.

  • Styring af miljølivscyklus

    • Scenarie: Udviklings- og testmiljøer klones fra produktionen, hvilket duplikerer alle data og indekser.
    • Handling: Trim sandkassemiljøer efter en opdatering, deaktiver unødvendig søgeindeksering, og fjern testdata for at reducere overflødigt lagerforbrug. Slet ubrugte sandkassemiljøer for at spare lagerplads.

Casestudier

Casestudie 1: Reduktion af lageroverskud gennem indeksoprydning

Kundeprofil: En global produktionsvirksomhed, der bruger Dynamics 365 til forsyningskæde og programmer til finans og drift.

Udfordring: Kunden oplevede uventede lageroverforbrug og forringelse af ydeevnen i deres produktionsmiljø. Undersøgelsen viste, at flere brugerdefinerede indekser og materialiserede visninger, der blev oprettet under den tidlige implementering, ikke længere var i brug, men stadig brugte betydelig lagerplads.

Løsning: Teamet gennemførte en kvartalsvis revision af alle brugerdefinerede indekser og fjernede dem, der ikke refereres til af aktive forespørgsler eller rapporter. De implementerede også en styringspolitik for at gennemgå nye indeksanmodninger før implementering.

Udfald:

  • Reduceret databaselager med 28 %.
  • Forbedret forespørgselsydeevne med 15 %.
  • Undgik en forventet $12,000 om året i andre lageromkostninger.

Casestudie 2: Arkivering af historiske data for at opfylde overholdelses- og præstationsmål

Kundeprofil: Et finansielt firma, der bruger Dataverse Dynamics 365 til kundeonboarding og sagsstyringsfunktionalitet.

Udfordring: Firmaet havde brug for at opbevare kundeoptegnelser i mere end syv år for at opfylde lovkravene, men den stigende mængde inaktive data bremsede aktive arbejdsgange og øgede lageromkostningerne.

Løsning: Kunden implementerede en langsigtet opbevaringsstrategi ved hjælp af Dataverse arkiveringsfunktionerne. Inaktive poster blev flyttet til et skrivebeskyttet, omkostningsoptimeret lagerniveau, mens aktive data forblev i et lager med høj ydeevne.

Resultat:

  • Arkiveret over 1,2 millioner optegnelser.
  • Reduceret primær databasestørrelse med 40 %.
  • Opretholdt fuld auditerbarhed og overholdelse af opbevaringspolitikker.

Casestudie 3: Strømlining af søgeindekser på tværs af miljøer

Kundeprofil: En detailorganisation med flere Dataverse miljøer, herunder udviklings-, test- og produktionsmiljøer, der understøtter en Copilot-aktiveret løsning til administration af kunderelationer.

Udfordring: Søgeindekser blev brugt på tværs af alle miljøer, herunder ubrugte tabeller og testdata. Dette førte til oppustede DataverseSearch-tabeller og unødvendigt lagerforbrug.

Løsning: Teamet gennemgik søgbare felter og stoppede med at bruge indeksering på ikke-kritiske tabeller i udviklings- og testmiljøer. De automatiserede også indeksoprydning under miljøopdateringer.

Resultat:

  • Reduceret lagring af søgeindeks med 35 %.
  • Forbedrede opdateringstider for miljøet med 20 %.
  • Reduceret samlet brug af log og databaselager.

Casestudie 4: Brug af dataeksport til analyser uden duplikeret lager

Kundeprofil: En sundhedsudbyder, der bruger Dynamics 365 og Dataverse til patientengagement og fakturering.

Udfordring: Analyseteamet havde brug for adgang til driftsdata til trendanalyse og AI-modellering, men duplikering af data til et separat lager øgede lageromkostningerne og kompleksiteten.

Løsning: Kunden brugte Azure Synapse Link med trinvis eksport og lagdelt lager i OneLake. De bevarede kun vigtige analytiske data og anvendte opbevaringspolitikker til at administrere historisk dybde.

Resultat:

  • Aktiveret analyser i realtid uden at påvirke driftssystemer.
  • Reduceret redundant storage med 45 %.
  • Forbedret styring over livscyklussen for analytiske data.

Konklusion

Effektiv lagerstyring er afgørende for at opretholde systemets ydeevne og optimere ressourceudnyttelsen i Dynamics 365-miljøer. De oprydningsrutiner og arkiveringsopgaver, der er beskrevet i denne artikel, giver robuste løsninger til at frigøre værdifuld databaseplads og strømline driften. Ved at bruge disse værktøjer som LTR og lignende teknikker kan kunderne løse almindelige lagringsudfordringer og skabe bæredygtig datastyringspraksis. Desuden demonstrerer casestudier fra den virkelige verden effektiviteten af disse tilgange og giver indsigt i deres praktiske anvendelser. Vedtagelse af disse strategier giver organisationer mulighed for proaktivt at administrere deres lagerbehov og forbedre den samlede effektivitet.

Referencer

Oprydning af opbevaring i Dataverse:

Oprydning af lager i finans og drift:

Lagerkapacitet:

  • Last updated on