Dataopbevaring i Fabric data warehouse

Gælder for:✅ Warehouse i Microsoft Fabric

I Microsoft Fabric bevarer og vedligeholder et lager automatisk forskellige versioner af dataene baseret på den konfigurerede opbevaringsperiode. Denne opbevaringsperiode bestemmer, hvor langt tilbage i tiden du kan udføre tidsrejseforespørgsler, oprette tabelkloner, bruge gendannelsespunkter og skabe lager-snapshots.

Dataopbevaring starter automatisk, når du opretter lageret. Som standard opbevarer lagre datahistorik i 30 kalenderdage. Du kan konfigurere opbevaringsperioden til en hvilken som helst værdi mellem 1 og 120 dage. Systemet sletter automatisk udløbne filer, når opbevaringsperioden er slut.

Lageret gemmer alle indsættelser, opdateringer og sletninger inden for den konfigurerede opbevaringsperiode.

• At øge opbevaringsperioden giver et længere vindue for tidsrejseforespørgsler, tabelkloner på et tidligere tidspunkt, gendannelsespunkter og lagersnapshots. Dog øger en længere opbevaringsperiode lagerforbruget og de tilhørende omkostninger.
• At forkorte opbevaringstiden reducerer lageromkostningerne, men begrænser, hvor langt tilbage du kan forespørge eller gendanne historiske data.

Sådan fungerer dataopbevaring

Når data ændres, kasserer lageret ikke straks den tidligere versionstilstand. I stedet bevares de tidligere versioner af dataene som en del af Delta Lake-transaktionsloggen. Denne versioneringsmekanisme er det, der muliggør tidsrejser, tabelkloner, gendannelsespunkter og lagersnapshots at fungere.

Når historiske dataversioner overstiger den konfigurerede opbevaringsperiode, fjerner en baggrundsaffaldsindsamlingsproces automatisk de udløbne filer fra OneLake. Denne oprydningsproces kører asynkront og påvirker ikke aktive forespørgsler eller igangværende transaktioner.

Lageret måler alderen på de lagrede data i absolutte kalenderdage fra det tidspunkt, dataversionen blev oprettet, inklusive hver gang Microsoft Fabric-kapaciteten er sat på pause.

Varighedsinterval

Hvis du ikke eksplicit konfigurerer opbevaringsperioden, bruger eksisterende lagre standardopbevaringsperioden på 30 kalenderdage. Du kan konfigurere dataopbevaringsperioden fra 1 til 120 dage.

Konfigurer dataopbevaring

Indstil lagringsperioden for data for et lager ved at bruge ALTER DATABASE ... SET T-SQL-kommandoen. For trin og mere information, se Sådan konfigurerer man dataopbevaring i Fabric data warehouse.

Adfærd ved ændring af retentionsperioden

At forstå adfærden, når du ændrer opbevaringsperioden, hjælper dig med at planlægge ændringer for at undgå uventet datatab eller øget lagerstørrelse.

Forlængelse af retentionstiden

Når du øger fastholdelsesperioden, træder den nye indstilling straks i kraft. Du kan dog ikke gendanne historiske data, som systemet allerede har ryddet op i under den tidligere kortere opbevaringsperiode. Kun dataversioner, der stadig eksisterer i OneLake på tidspunktet for ændringen, nyder godt af den forlængede opbevaringsperiode.

For eksempel, hvis dit lager i øjeblikket har en 7-dages opbevaringsperiode, og du øger den til 60 dage, gælder ændringen fra det tidspunkt og frem. Dataversioner, som systemet allerede har ryddet op i før ændringen (ældre end 7 dage), kan ikke gendannes. Dog vil alle dataversioner, der stadig er inden for 7-dages vinduet på tidspunktet for ændringen, sammen med eventuelle nyoprettede versioner fremover, blive bevaret i op til 60 dage.

Nedtagelse af opretholdelsestiden

Når man reducerer opbevaringsperioden, bliver dataversioner, der nu falder uden for den nye kortere opbevaringsperiode, berettiget til oprydning. Oprydningsprocessen kører asynkront i baggrunden og sker ikke øjeblikkeligt. Aktive forespørgsler, der allerede er i gang, bliver ikke påvirket.

For eksempel, hvis dit lager har en opbevaringsperiode på 30 dage, og du reducerer den til 7 dage, bliver dataversioner mellem 8 og 30 dage gamle berettiget til baggrundsoprydning.

Fastholdelsesgrænse

Kolonnen time_travel_retention_cutoff_date i sys.databases systemkatalogvisning afspejler den tidligste dato , hvor tidsrejsedata er tilgængelige, ikke den aktuelt konfigurerede opbevaringsperiode. De ældste faktiske data kan være forskellige fra den konfigurerede opbevaringsperiode.

Den brugerkonfigurerede opbevaringsperiode definerer, hvor mange dages historik systemet skal bevare fremadrettet. Den faktiske genoprettelige historik afhænger dog af, hvilke data der blev bevaret før eventuelle ændringer i opbevaringen.

To situationer forårsager en divergens mellem konfigureret opbevaring og faktisk tilgængelig historik:

• Opbevaringen blev reduceret — Lageret markerer straks historiske data, der er ældre end den nye opbevaringsperiode for affaldsindsamling, og fjerner dem permanent.
• Opbevaringen blev efterfølgende øget — Lageret kan ikke gendanne den slettede historik. Den skal vente på, at ny historik akkumuleres, før det fulde konfigurerede vindue er tilgængeligt.

Dataopbevaringsscenarier

Overvej følgende scenarier, når du beslutter, hvordan du konfigurerer din opbevaringsperiode:

Revision og overholdelse af angivne standarder

Organisationer med regulatoriske eller compliance-krav kan have behov for at opbevare data i længere perioder for at opfylde revisionsforpligtelser. At konfigurere en opbevaringsperiode på 90 eller 120 dage kan give et bredere historisk vindue for revisorer til at gennemgå dataændringer over tid.

Udvikling og test

For udviklings- eller testarbejdsområder, hvor historiske data er mindre vigtige, kan en kortere opbevaringsperiode på 1 til 7 dage reducere lageromkostningerne. Denne reduktion er nyttig, når arbejdsområdet bruges til hurtig prototyping eller iterativ udvikling.

Omkostningsoptimering

Hvis dit lager gennemgår hyppige store dataændringer (såsom daglige fulde loads), kan mængden af lagrede historiske data vokse betydeligt. I disse scenarier hjælper en reduktion af opbevaringstiden med at kontrollere lageromkostningerne, samtidig med at man opretholder et rimeligt genopretningsvindue.

Beredskab til datagendannelse

For produktionslagre giver en længere opbevaringsperiode større fleksibilitet til datagendannelse gennem gendannelsespunkter, tabelkloner og tidsrejseforespørgsler i tilfælde af utilsigtet datakorruption.

Hvordan konfigurerbar fastholdelse påvirker afhængige egenskaber

Den konfigurerede opbevaringsperiode gælder ensartet på tværs af følgende funktioner i Fabric data warehouse. Ændring af retentionsperioden påvirker direkte tilgængeligheden og adfærden af disse funktioner.

Tidsrejse

Tidsrejser gør det muligt at forespørge data, som de eksisterede på et tidligere tidspunkt i opbevaringsperioden. Forespørgselshintet FOR TIMESTAMP AS OF kan hente data fra ethvert punkt inden for den konfigurerede opbevaringsperiode.

For eksempel, hvis opbevaringsperioden er sat til 15 dage, kan du forespørge data, som de eksisterede for op til 15 kalenderdage siden.

Klontabel

Tabelkloner er afhængige af retentionsperioden. Du kan kun oprette en klon af en tabel på et tidligere tidspunkt inden for den konfigurerede opbevaringsperiode. Hvis du anmoder om en klon ud over opbevaringsperioden, opstår der en fejl.

Genopretningspunkter

Brug gendannelsespunkter til at genoprette et lager. Systemet bevarer både systemgenererede og brugerdefinerede gendannelsespunkter i den konfigurerede opbevaringsperiode. Når opbevaringsperioden udløber, sletter systemet automatisk gendannelsespunkter.

• Lageret opretter automatisk systemgenererede gendannelsespunkter hver ottende time. Disse gendannelsespunkter er tilgængelige i den konfigurerede opbevaringsperiode.
• Brugerdefinerede gendannelsespunkter er tilgængelige for den konfigurerede opbevaringsperiode. Systemet sletter automatisk disse gendannelsespunkter efter udløb.

Fabric opretholder et minimum antal gendannelsespunkter for at sikre, at der altid er tilstrækkelige genoprettelsespunkter tilgængelige.

Snapshots af lager

Warehouse-snapshots kan referere til data inden for den konfigurerede opbevaringsperiode. Snapshot-tidsstemplet kan sættes til et hvilket som helst tidspunkt inden for den konfigurerede opbevaringsperiode eller til databasens oprettelsestid, alt efter hvad der kommer senere.

Lagerfakturering

Dataopbevaring påvirker direkte forbruget af OneLake-lagring. Hver bevaret version af data optager lagerplads, og længere opbevaringsperioder akkumulerer flere historiske versioner.

Når du planlægger opbevaringskonfigurationen, bør du overveje afvejningen mellem fordelene ved længere adgang til datahistorikken og de tilknyttede lagringsomkostninger. For mere information om overvågning af lagring, se Overvåg ved brug af Capacity Metrics-appen.

• Lagrede datafiler: Historiske versioner af data gemt som parquet-filer i OneLake bruger lagring. Lageromkostningerne er proportionale med mængden og hyppigheden af dataændringer i opbevaringsperioden.
• Gendannelsespunkter: Metadata for systemgenererede og brugerdefinerede gendannelsespunkter bruger også lagerplads. Dog gemmer gendannelsespunkterne primært metadata og refererer til eksisterende datafiler, så deres lagringsoverhead er relativt lille.
• Ingen beregningsgebyrer for opbevaring: Der påløber ingen beregningsgebyrer udelukkende for opbevaring af historiske data. Beregningsgebyrer gælder kun, når du aktivt forespørger eller gendanner data.

For at estimere lagringspåvirkningen af en ændring i opbevaringsperioden, overvej:

• Den gennemsnitlige daglige mængde dataændringer i dit lager.
• Den nuværende opbevaringsperiode og den foreslåede nye opbevaringsperiode.
• Deltaet mellem de to perioder ganget med det gennemsnitlige daglige modifikationsvolumen giver en omtrentlig ændring i lagerforbruget.

Designovervejelser

• Konfigurér lagringsperioden baseret på organisationens krav til datagendannelse, overholdelse og omkostninger. Standarden på 30 dage giver en balance mellem datatilgængelighed og lageromkostninger for de fleste arbejdsbelastninger.
• Koordiner ændringer i opbevaringsperioden med din backup- og katastrofeberedskabsstrategi. Sørg for, at opbevaringsperioden stemmer overens med dine recovery point-mål (RPO).
• Overvåg forbruget af OneLake lagring efter at have ændret opbevaringsperioden for at forstå virkningen på lagringsomkostningerne.
• Planlæg ændringer i opbevaringsperioden under lavaktivitetsperioder, når det er muligt, så der ikke er brugerpåvirkning.
• Opbevaringsperioden fastsættes på lagerniveau. Hvis du har brug for forskellige opbevaringsperioder for forskellige datasæt, så overvej at organisere dem i separate lagre. Individuelle tabelniveau-retentionsindstillinger understøttes ikke i øjeblikket.

Begrænsninger

• Angiv opbevaringsperioden i hele dage. Brøkværdier understøttes ikke.
• At forkorte opbevaringstiden genvinder ikke straks lagerpladsen. Oprydning af udløbne data sker asynkront i baggrunden.
• At sætte Microsoft Fabric-kapaciteten på pause påvirker oprydningsaktiviteten for affald. Processen fjerner ikke historiske data, der er ældre end de nuværende dataopbevaringsindstillinger, mens kapaciteten er sat på pause. Oprydningsaktiviteterne indhentes, når kapaciteten genoptages.
• Indstillingen for opbevaring gælder kun for lagre. SQL-analyse-endpointet i Lakehouse understøttes ikke.
• Query Insights- og SQL-revisionslogs er ikke underlagt denne dataopbevaringspolitik og administreres separat.

Droppet genstandsopbevaring (forhåndsvisning)

Droppede varebevarelser bevarer lagre og deres tilknyttede tabeller, skemaer, snapshots, tilladelser og gemte forespørgsler i en konfigurerbar periode efter, at de er blevet fjernet eller slettet. Dette sikrer, at utilsigtede sletninger ikke resulterer i permanent datatab eller forretningsmæssige nedbrud. Droppet opbevaring garanterer en minimumsopbevaringsperiode på 7 kalenderdage og har en separat lejer-niveau opbevaringskonfiguration. Du kan konfigurere opbevaringsperioden for tabte genstande i indstillingen for Item Recovery-lejeren.

Næste trin

Relateret indhold

• Genopret på stedet for et lager i Microsoft Fabric