Trinvis opdatering i Power BIIncremental refresh in Power BI

En trinvis opdatering gør det muligt at have meget store datasæt i Power BI med følgende fordele:Incremental refresh enables very large datasets in Power BI with the following benefits:

  • Opdateringer sker hurtigere – Det er kun ændrede data, der skal opdateres.Refreshes are faster - Only data that has changed needs to be refreshed. Opdater f.eks. kun de sidste 5 dage i et datasæt på 10 år.For example, refresh only the last five days of a ten-year dataset.
  • Opdateringer er mere pålidelig – Det er ikke længere nødvendigt at vedligeholde langtidskørende forbindelser til ustabile kildesystemer.Refreshes are more reliable - It's no longer necessary to maintain long-running connections to volatile source systems.
  • Forbrug af ressourcer reduceres – Hvis der skal opdateres færre data, reduceres det overordnede forbrug af hukommelsen og andre ressourcer.Resource consumption is reduced - Less data to refresh reduces overall consumption of memory and other resources.

Bemærk

Trinvis opdatering er nu tilgængelig for Power BI Pro, Premium og delte abonnementer og datasæt.Incremental refresh is now available for Power BI Pro, Premium, and shared subscriptions and datasets.

Bemærk

Power BI Premium har for nylig udgivet en ny version af Premium med navnet Premium Gen2, der i øjeblikket er tilgængelig som prøveversion.Power BI Premium recently released a new version of Premium, called Premium Gen2, which is currently in preview. Premium Gen2 forenkler administrationen af Premium-kapaciteter og reducerer administrationsomkostningerne.Premium Gen2 will simplify the management of Premium capacities, and reduce management overhead. Premium Gen2 forbedrer den planlagte opdatering markant ved at aktivere automatisk skalering for at undgå opdateringskonflikter.Premium Gen2 significantly improves scheduled refresh, by enabling autoscaling to avoid refresh conflicts. Du kan finde flere oplysninger under Power BI Premium – Generation 2 (prøveversion).For more information, see Power BI Premium Generation 2 (preview).

Konfigurer trinvis opdateringConfigure incremental refresh

Politikker om trinvis opdatering er defineret i Power BI Desktop og anvendes, når de er publiceret i Power BI-tjenesten.Incremental refresh policies are defined in Power BI Desktop and applied when published to the Power BI service.

Filtrer store datasæt i Power BI DesktopFilter large datasets in Power BI Desktop

Store datasæt, der kan indeholde milliarder af rækker, kan måske ikke være i en Power BI Desktop-model, fordi PBIX-filen er begrænset af de hukommelsesressourcer, der er tilgængelige på den stationære computer.Large datasets with potentially billions of rows may not fit into a Power BI Desktop model because the PBIX file is limited by the memory resources available on the desktop computer. Disse datasæt filtreres derfor ofte, efter at de er importeret.Such datasets are therefore commonly filtered upon import. Denne type filtrering gælder, uanset om du bruger trinvis opdatering eller ej.This type of filtering applies whether using incremental refresh or not. I forbindelse med trinvis opdatering kan du filtrere ved hjælp af parametrene for dato/klokkeslæt i Power-forespørgsel.For incremental refresh, you filter by using Power Query date/time parameters.

Parametrene RangeStart og RangeEndRangeStart and RangeEnd parameters

I forbindelse med trinvis opdatering filtreres datasæt ved hjælp af parametrene for dato/klokkeslæt i Power-forespørgsel med de reserverede navne RangeStart og RangeEnd, hvor der skelnes mellem store og små bogstaver.For incremental refresh, datasets are filtered by using Power Query date/time parameters with the reserved, case-sensitive names RangeStart and RangeEnd. Disse parametre bruges til at filtrere de data, der importeres til Power BI Desktop, og desuden til dynamisk partitionering af dataene i intervaller, når de er publiceret til Power BI-tjenesten.These parameters are used to filter the data imported into Power BI Desktop, and also to dynamically partition the data into ranges once published to the Power BI service. Parameterværdierne er erstattet af tjenesten til filtrering efter hver partition.The parameter values are substituted by the service to filter for each partition. Det er ikke nødvendigt at angive dem under indstillinger for datasæt i tjenesten.There's no need to set them in dataset settings in the service. Når de er publiceret, overskrives parameterværdierne automatisk af Power BI-tjenesten.Once published, the parameter values are overridden automatically by the Power BI service.

Vælg Administrer parametre for at definere parametrene med standardværdier i redigeringsfunktionen til Power-forespørgsel.To define the parameters with default values, in the Power Query Editor, select Manage Parameters.

Administrer parametre

Når parametrene er defineret, kan du anvende filteret ved at vælge menupunktet Brugerdefineret filter for en kolonne.With the parameters defined, you can then apply the filter by selecting the Custom Filter menu option for a column.

Brugerdefineret filter

Du skal sikre, at rækker filtreres, hvor kolonneværdien er efter eller lig med RangeStart og før RangeEnd.Ensure rows are filtered where the column value is after or equal to RangeStart and before RangeEnd. Andre filterkombinationer kan resultere i dobbelt optælling af rækker.Other filter combinations may result in double counting of rows.

Filtrer rækker

Vigtigt

Kontrollér, at forespørgsler har et lighedstegn (=) ved enten RangeStart eller RangeEnd, men ikke begge.Verify queries have an equal to (=) on either RangeStart or RangeEnd, but not both. Hvis lighedstegnet (=) er ved begge parametre, kan en række opfylde betingelserne for to partitioner, hvilket kan medføre, at data i modellen duplikeres.If the equal to (=) exists on both parameters, a row could satisfy the conditions for two partitions, which could lead to duplicate data in the model. F.eks.For example,
#"Filtrerede rækker" = Table.SelectRows(dbo_Fact, hver [OrderDate] >= RangeStart og [OrderDate] <= RangeEnd) kan medføre duplikerede data.#"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] <= RangeEnd) could result in duplicate data.

Tip

Da datatypen for parametrene skal være dato/klokkeslæt, er det muligt at konvertere dem, så de overholder kravene til datakilden.While the data type of the parameters must be date/time, it's possible to convert them to match the requirements of the datasource. Følgende funktion i Power-forespørgsel konverterer f.eks. en dato/klokkeslæt-værdi, så den ligner en heltalssurrogatnøgle i formatet yyyymmdd, hvilket er almindeligt for data warehouse-lagre.For example, the following Power Query function converts a date/time value to resemble an integer surrogate key of the form yyyymmdd, which is common for data warehouses. Funktionen kan kaldes af filtreringstrinnet.The function can be called by the filter step.

(x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)

Vælg Luk og anvend fra redigeringsfunktionen til Power-forespørgsel.Select Close and Apply from the Power Query Editor. Du får et undersæt af datasættet i Power BI Desktop.You should have a subset of the dataset in Power BI Desktop.

Filtrer opdateringer af datokolonnerFilter date column updates

Filteret i datokolonnen bruges til dynamisk partitionering af dataene i intervaller i Power BI-tjenesten.The filter on the date column is used to dynamically partition the data into ranges in the Power BI service. Trinvis opdatering er ikke beregnet til at understøtte tilfælde, hvor den filtrerede datokolonne opdateres i kildesystemet.Incremental refresh isn't designed to support cases where the filtered date column is updated in the source system. En opdatering fortolkes som en indsætning og en sletning, ikke en egentlig opdatering.An update is interpreted as an insertion and a deletion, not an actual update. Hvis sletningen sker i historikintervallet og ikke i det trinvis interval, registreres den ikke.If the deletion occurs in the historical range and not the incremental range, it won't get picked up. Dette kan medføre fejl under dataopdatering på grund af konflikter i forbindelse med partitionsnøglen.This can cause data refresh failures due to partition-key conflicts.

ForespørgselsfoldningQuery folding

Det er vigtigt, at partitionsfiltre pushes til kildesystemet, når der sendes forespørgsler til opdatering.It's important the partition filters are pushed to the source system when queries are submitted for refresh operations. For at kunne pushe filtrering ned skal datakilden understøtte forespørgselsfoldning.To push filtering down means the datasource should support query folding. De fleste datakilder, der understøtter SQL-forespørgsler, understøtter forespørgselsfoldning.Most data sources that support SQL queries support query folding. Datakilder såsom flade filer, BLOB-filer og webfeeds gør dog typisk ikke.However, data sources like flat files, blobs, and web feeds typically do not. I de tilfælde, hvor filteret ikke understøttes af datakildens backend, kan det ikke pushes ned.In cases where the filter is not supported by the datasource back-end, it cannot be pushed down. I sådanne tilfælde kompenserer miksprogrammet og anvender filteret lokalt, hvilket kan kræve, at hele datasættet skal hentes fra datakilden.In such cases, the mashup engine compensates and applies the filter locally, which may require retrieving the full dataset from the data source. Dette kan medføre, at trinvis opdatering er meget langsom, og processen kan løbe tør for ressourcer enten i Power BI-tjenesten eller i datagatewayen i det lokale miljø, hvis de bruges.This can cause incremental refresh to be very slow, and the process can run out of resources either in the Power BI service or in the on-premises data gateway if used.

På grund af de forskellige supportniveauer af forespørgselsfoldning for de enkelte datakilder anbefales det, at det kontrolleres, at filterlogikken er inkluderet i kildeforespørgslerne.Given the various levels of query folding support for each datasource, it's recommended that verification is performed to ensure the filter logic is included in the source queries. For at gøre det nemmere forsøger Power BI Desktop til at udføre denne kontrol for dig.To make this easier, Power BI Desktop attempts to perform this verification for you. Hvis det var ikke muligt at bekræfte, vises der en advarsel i dialogboksen til trinvis opdatering, når du definerer politikken for trinvis opdatering.If unable to verify, a warning is displayed in the incremental refresh dialog when defining the incremental refresh policy. SQL-baserede datakilder, som SQL, Oracle og Teradata, kan bruge denne advarsel.SQL based data sources such as SQL, Oracle, and Teradata can rely on this warning. Andre datakilder kan muligvis ikke bekræfte uden at spore forespørgsler.Other data sources may be unable to verify without tracing queries. Hvis Power BI Desktop ikke kan bekræfte, vises følgende advarsel.If Power BI Desktop is unable to confirm, the following warning is displayed. Hvis du får vist denne advarsel og gerne vil kontrollere, at den nødvendige forespørgselsdelegering finder sted, kan du bruge funktionen Forespørgselsdiagnosticering eller spore de forespørgsler, du har modtaget fra kildedatabasen.If you see this warning and want to check that the necessary query folding is occurring, you can use the Query Diagnostics feature, or trace queries received by the source database.

Forespørgselsfoldning

Definer opdateringspolitikkenDefine the refresh policy

Trinvis opdatering er tilgængelig via genvejsmenuen for tabeller, undtagen for modeller med direkte forbindelse.Incremental refresh is available on the context menu for tables, except for Live Connection models.

Opdateringspolitik

Dialogboksen Trinvis opdateringIncremental refresh dialog

Dialogboksen Trinvis opdatering vises.The incremental refresh dialog is displayed. Brug til/fra-tasten til at aktivere dialogboksen.Use the toggle to enable the dialog.

Detaljer om opdatering

Bemærk

Hvis udtrykket fra Power-forespørgsel for tabellen ikke henviser til parametrene med reserverede navne, er til/fra-tasten slået fra.If the Power Query expression for the table doesn't refer to the parameters with reserved names, the toggle is disabled.

Teksten i sidehovedet forklarer følgende:The header text explains the following:

  • Opdateringspolitikker defineres i Power BI Desktop, og de anvendes af opdateringshandlinger i tjenesten.Refresh policies are defined in Power BI Desktop, and they are applied by refresh operations in the service.

  • Hvis du ikke kan hente den PBIX-fil, der indeholder en politik for trinvis opdatering, fra Power BI-tjenesten, kan den ikke åbnes i Power BI Desktop.If you're able to download the PBIX file containing an incremental-refresh policy from the Power BI service, it cannot be opened in Power BI Desktop. Dette understøttes muligvis i fremtiden, men vær opmærksom på, at disse datasæt kan vokse sig så store, at det er upraktisk at downloade og åbne dem på en normal stationær computer.While this may be supported in the future, keep in mind these datasets can grow to be so large that they are impractical to download and open on a typical desktop computer.

OpdateringsintervallerRefresh ranges

I følgende eksempel defineres en opdateringspolitik, hvor data for 5 hele kalenderår samt data for det aktuelle år op til den aktuelle dato gemmes, og hvor data for 10 hele dage gradvist opdateres.The following example defines a refresh policy to store data for five full calendar years plus data for the current year up to the current date, and incrementally refresh ten full days of data. Under den første opdateringshandling indlæses der historiske data.The first refresh operation loads historical data. De efterfølgende opdateringer er trinvise, og følgende handlinger udføres (hvis de er planlagt til at køre dagligt):Subsequent refreshes are incremental, and (if scheduled to run daily) perform the following operations:

  • Tilføj en ny dags data.Add a new day of data.

  • Opdater 10 hele dage op til dags dato.Refresh ten full days up to the current date.

  • Fjern kalenderår, der er ældre end fem år fra den aktuelle dato.Remove calendar years that are older than five years prior to the current date. Hvis den aktuelle dato f.eks. er 1. januar 2019, fjernes år 2013.For example, if the current date is January 1 2019, the year 2013 is removed.

Under den første opdatering i Power BI-tjenesten kan det tage længere tid at importere alle fem hele kalenderår.The first refresh in the Power BI service may take longer to import all five full calendar years. Efterfølgende opdateringer kan udføres på meget kortere tid.Subsequent refreshes may be finished in a fraction of the time.

Opdateringsintervaller

Aktuel datoCurrent date

Den aktuelle dato er baseret på systemdatoen for opdateringstidspunktet.The current date is based on the system date at the time of refresh. Hvis en planlagt opdatering er aktiveret for datasættet i Power BI-tjenesten, tages der hensyn til den pågældende tidszone, når den aktuelle dato fastsættes.If scheduled refresh is enabled for the dataset in the Power BI service, the specified time zone will be taken into account when determining the current date. Der tages hensyn til tidszonen for både manuelt udløste og planlagte opdateringer gennem Power BI-tjenesten, hvis tidszonen er tilgængelig.Both manually invoked and scheduled refreshes through the Power BI service observe the time zone if available. En opdatering, der finder sted kl. 20.00 Pacific Time (USA og Canada) og har en angiven tidszone, fastsætter den aktuelle dato ud fra Pacific Time og ikke GMT (hvilket i så fald ville være den efterfølgende dag).For example, a refresh that occurs at 8 PM Pacific Time (US and Canada) with time zone specified will determine the current date based on Pacific Time, not GMT (which would otherwise be the next day). Opdateringshandlinger, der ikke blev kaldt via Power BI-tjenesten, f.eks. TMSL-opdateringskommandoen, tager ikke hensyn til tidszonen for planlagt opdateringRefresh operations not invoked through the Power BI service, such as the TMSL refresh command, will not consider the scheduled refresh time zone

Tidszone

Bemærk

En definition af disse intervaller kan være det eneste, du skal bruge, og i dette tilfælde kan du gå direkte til trinnet for publicering nedenfor.Definition of these ranges might be all you need, in which case you can go straight to the publishing step below. De ekstra rullemenuer bruges til avancerede funktioner.The additional dropdowns are for advanced features.

Avancerede politikindstillingerAdvanced policy options

Registrer dataændringerDetect data changes

En trinvis opdatering på 10 dage er selvfølgelig meget mere effektiv end en komplet opdatering på 5 år.Incremental refresh of ten days is more efficient than full refresh of five years. Det er imidlertid muligt at gøre det på en endnu bedre måde.However, it's possible to do even better. Hvis du markerer afkrydsningsfeltet Registrer dataændringer, kan du vælge en dato/klokkeslæt-kolonne, der bruges til at identificere og kun opdatere de dage, hvor dataene er blevet ændret.If you select the Detect data changes checkbox, you can select a date/time column used to identify and refresh only the days where the data has changed. Det er en forudsætning, at der findes en sådan kolonne i kildesystemet, der typisk bruges til overvågning.This assumes such a column exists in the source system, which is typically for auditing purposes. Det må ikke være den samme kolonne, der bruges til at partitionere dataene med parametrene RangeStart/RangeEnd.This should not be the same column used to partition the data with the RangeStart/RangeEnd parameters. Maksimumværdien for denne kolonne evalueres for hver af perioderne i det trinvise interval.The maximum value of this column is evaluated for each of the periods in the incremental range. Hvis den ikke er ændret siden den seneste opdatering, er det ikke nødvendigt at opdatere perioden.If it has not changed since the last refresh, there is no need to refresh the period. I eksemplet kan dette yderligere reducere antallet af dage for den trinvise opdatering fra 10 til ca. 2 dage.In the example, this could further reduce the days incrementally refreshed from ten to around two.

Registrer ændringer

Tip

Det aktuelle design kræver, at kolonnen til registrering af dataændringer bevares og cachelagres i hukommelsen.The current design requires that the column to detect data changes is persisted and cached into memory. Du kan evt. overveje en af følgende metoder for at reducere kardinalitet og hukommelsesforbrug.You may want to consider one of the following techniques to reduce cardinality and memory consumption.

Bevar kun den maksimale værdi for denne kolonne på tidspunktet for opdateringen, måske ved hjælp af en funktion i Power-forespørgsel.Persist only the maximum value of this column at time of refresh, perhaps using a Power Query function.

Reducer præcisionen til et niveau, der er acceptabelt i forhold til dine krav om opdateringshyppighed.Reduce the precision to a level that is acceptable given your refresh-frequency requirements.

Definer en brugerdefineret forespørgsel om registrering af dataændringer ved hjælp af XMLA-slutpunktet, og undgå helt at bevare kolonneværdien.Define a custom query for detecting data changes using the XMLA endpoint and avoid persisting the column value altogether. Du kan finde flere oplysninger i brugerdefinerede forespørgsler om registrering af dataændringer nedenfor.See custom queries for detect data changes below for more information.

Opdater kun samlede perioderOnly refresh complete periods

Lad os antage, at din opdatering er planlagt til at køre kl. 4:00 hver morgen.Let's say your refresh is scheduled to run at 4:00 AM every morning. Hvis der vises data i kildesystemet i løbet af disse 4 timer, ønsker du måske ikke at gøre rede for dem.If data appears in the source system during those 4 hours, you may not want to account for it. Nogle målepunkter for virksomheder, f.eks. tønder pr. dag i olie- og gasbranchen, giver ingen mening, hvis dagene er delvise.Some business metrics such as barrels per day in the oil and gas industry make no sense with partial days.

Et andet eksempel er opdatering af data fra et økonomisystem, hvor data for den foregående måned godkendes den 12. kalenderdag i måneden.Another example is refreshing data from a financial system where data for the previous month is approved on the 12th calendar day of the month. Du kan indstille det trinvise interval til 1 måned og planlægge, at opdateringen skal køre den 12. dag i måneden.You could set the incremental range to 1 month and schedule the refresh to run on the 12th day of the month. Når denne indstilling er markeret, opdateres dataene fra januar f.eks. den 12. februar.With this option checked, it would for example refresh January data on February 12th.

Samlede perioder

Bemærk

Opdateringshandlinger i tjenesten kører i UTC-tid.Refresh operations in the service run under UTC time. Dette kan være afgørende for ikrafttrædelsesdatoen og have indflydelse på samlede perioder.This can determine the effective date and affect complete periods. Vi har planer om at gøre det muligt at tilsidesætte ikrafttrædelsesdatoen for en opdateringshandling.We plan to add the ability to override the effective date for a refresh operation.

Publicer i tjenestenPublish to the service

Du kan nu opdatere modellen.You can now refresh the model. Den første opdatering kan tage længere tid, da oversigtsdataene skal importeres.The first refresh may take longer to import the historical data. Efterfølgende opdateringer kan være meget hurtigere, fordi der bruges en trinvis opdatering.Subsequent refreshes can be much quicker because they use incremental refresh.

Timeout for forespørgselQuery timeouts

I artiklen Fejlfinding i forbindelse med opdatering forklares det, at der kan opstå timeout for opdateringshandlinger i Power BI-tjenesten.The troubleshooting refresh article explains that refresh operations in the Power BI service are subject to timeouts. Forespørgsler kan også være begrænset af standardtimeout for datakilden.Queries can also be limited by the default timeout for the data source. De fleste relationskilder tillader tilsidesættelse af timeout i M-udtryk.Most relational sources allow overriding timeouts in the M expression. I udtrykket nedenfor bruges funktionen SQL Server-dataadgang f.eks. til at angive det til to timer.For example, the expression below uses the SQL Server data-access function to set it to 2 hours. Hver periode, der er defineret af politikintervallerne, sender en forespørgsel, der overholder indstillingen for timeout for kommandoer.Each period defined by the policy ranges submits a query observing the command timeout setting.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

Fordele ved XMLA-slutpunktet for trinvis opdateringXMLA endpoint benefits for incremental refresh

XMLA-slutpunktet for datasæt i en Premium-kapacitet kan aktiveres til læse-/skrivehandlinger, hvilket kan give store fordele for trinvis opdatering.The XMLA endpoint for datasets in a Premium capacity can be enabled for read-write operations, which can provide considerable benefits for incremental refresh. Opdateringshandlinger via XMLA-slutpunktet er ikke begrænset til 48 opdateringer pr. dag, og timeout for den planlagte opdatering er ikke pålagt, hvilket kan være nyttigt i scenarier med trinvis opdatering.Refresh operations through the XMLA endpoint are not limited to 48 refreshes per day, and the scheduled refresh timeout is not imposed, which can be useful in incremental refresh scenarios.

Administration af opdatering med SQL Server Management Studio (SSMS)Refresh management with SQL Server Management Studio (SSMS)

Med XMLA-slutpunktet kan læse-/skriveaktiveret SSMS bruges til at få vist og administrere partitioner, der er oprettet ved anvendelse af politikker for trinvis opdatering.With XMLA endpoint read-write enabled, SSMS can be used to view and manage partitions generated by the application of incremental refresh policies. Dette gør det muligt f.eks. at opdatere en bestemt historisk partition, der ikke er i det trinvise interval, for at udføre en tilbagedateret opdatering uden at skulle opdatere alle historiske data.This allows, for example, to refresh a specific historical partition not in the incremental range to perform a back-dated update without having to refresh all historical data. Du kan også bruge SSMS til at indlæse historiske data for meget store datasæt ved at foretage en trinvis tilføjelse/opdatering af historiske partitioner i batches.You can also use SSMS to load historical data for very large datasets by incrementally adding/refreshing historical partitions in batches.

Partitioner i SSMS

Tilsidesæt funktionsmåde for trinvis opdateringOverride incremental refresh behavior

Med SSMS får du også mere kontrol over, hvordan du aktiverer trinvise opdateringer ved hjælp af TMSL (Tabular Model Scripting Language) og TOM (Tabular Object Model).With SSMS, you also have more control over how to invoke incremental refreshes from using the Tabular Model Scripting Language (TMSL) and the Tabular Object Model (TOM). I SSMS kan du f. eks. højreklikke på en tabel i Object Explorer og derefter vælge menupunktet Behandl tabel.For example, in SSMS, in Object Explorer, right-click a table and then select the Process Table menu option. Klik derefter på knappen Script for at generere en TMSL-opdateringskommando.Then click the Script button to generate a TMSL refresh command.

Knappen Script i dialogboksen Behandl tabel

Følgende parametre kan indsættes i TMSL-opdateringskommandoen for at tilsidesætte standardfunktionsmåden for trinvis opdatering.The following parameters can be inserted into the TMSL refresh command to override the default incremental refresh behavior.

  • applyRefreshPolicy – Hvis en tabel har defineret en trinvis opdateringspolitik, bestemmer applyRefreshPolicy, om politikken anvendes eller ej.applyRefreshPolicy – If a table has an incremental refresh policy defined, applyRefreshPolicy will determine if the policy is applied or not. Hvis politikken ikke anvendes, efterlader en Behandl komplet-handling partitionsdefinitionerne uændrede, og der udføres en fuld opdatering af alle partitioner i tabellen.If the policy is not applied, a process full operation will leave partition definitions unchanged and all partitions in the table will be fully refreshed. Standardværdien er True.Default value is true.

  • effectiveDate – Hvis der anvendes en politik for trinvis opdatering, skal den kende den aktuelle dato for at bestemme det rullende vindues intervaller for det historiske interval og det trinvise interval.effectiveDate – If an incremental refresh policy is being applied, it needs to know the current date to determine rolling window ranges for the historical range and the incremental range. Parameteren effectiveDate gør det muligt for dig at tilsidesætte den aktuelle dato.The effectiveDate parameter allows you to override the current date. Dette er nyttigt i forbindelse med test, demoer og forretningsscenarier, hvor data opdateres trinvist til en dato i fortiden eller fremtiden (f. eks. budgetter i fremtiden).This is useful for testing, demos, and business scenarios where data is incrementally refreshed up to a date in the past or the future (for example, budgets in the future). Standardværdien er den aktuelle dato.The default value is the current date.

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

Du kan få mere at vide om, hvordan du tilsidesætter standardfunktionen til trinvis opdatering med TMSL, under Opdater kommando.To learn more about overriding default incremental refresh behavior with TMSL, see Refresh command.

Brugerdefinerede forespørgsler om registrering af dataændringerCustom queries for detect data changes

Du kan bruge TMSL og/eller TOM til at tilsidesætte funktionsmåden for de registrerede dataændringer.You can use TMSL and/or TOM to override the detected data changes behavior. Det kan ikke kun bruges til at undgå, at kolonnen med den seneste opdatering i cachen i hukommelsen bevares, men det kan gøre det muligt at aktivere scenarier, hvor en konfigurations-/instruktionstabel klargøres af ETL-processer, med det formål kun at markere de partitioner, der skal opdateres.Not only can this be used to avoid persisting the last-update column in the in-memory cache, it can enable scenarios where a configuration/instruction table is prepared by ETL processes for the purpose of flagging only the partitions that need to be refreshed. Det kan skabe en mere effektiv trinvis opdateringsproces, hvor kun de påkrævede perioder opdateres, uanset hvor længe det er, siden dataopdateringerne fandt sted.This can create a more efficient incremental refresh process where only the required periods are refreshed, no matter how long ago data updates took place.

pollingExpression er beregnet til at være et M-letvægtsudtryk eller et navn på en anden M-forespørgsel.The pollingExpression is intended to be a lightweight M expression or name of another M query. Det skal returnere en skalaværdi og udføres for hver partition.It must return a scalar value and will be executed for each partition. Hvis den returnerede værdi er forskellig fra den værdi, der blev returneret, sidste gang en trinvis opdatering forekom, er partitionen markeret med henblik på fuld behandling.If the value returned is different to what it was the last time an incremental refresh occurred, the partition is flagged for full processing.

Følgende eksempel dækker alle 120 måneder i det historiske område for tilbagedaterede ændringer.The following example covers all 120 months in the historical range for backdated changes. Hvis du angiver 120 måneder i stedet for 10 år, er datakomprimering muligvis ikke helt lige så effektiv, men du undgår at skulle opdatere et helt historisk år, hvilket ville være dyrere, og en måned ville være tilstrækkelig til en tilbagedateret ændring.Specifying 120 months instead of 10 years means data compression may not be quite as efficient, but avoids having to refresh a whole historical year, which would be more expensive when a month would suffice for a backdated change.

"refreshPolicy": {
    "policyType": "basic",
    "rollingWindowGranularity": "month",
    "rollingWindowPeriods": 120,
    "incrementalGranularity": "month",
    "incrementalPeriods": 120,
    "pollingExpression": "<M expression or name of custom polling query>",
    "sourceExpression": [
    "let ..."
    ]
}

Udrulning udelukkende af metadataMetadata-only deployment

Når du publicerer en ny version af en PBIX-fil fra Power BI Desktop til et arbejdsområde i Power BI Premium, bliver du bedt om at erstatte det eksisterende datasæt, hvis der allerede findes et datasæt med det samme navn.When publishing a new version of a PBIX file from Power BI Desktop to a workspace in Power BI Premium, if a dataset with the same name already exists, you are prompted to replace the existing dataset.

Prompt om erstatning af datasæt

I nogle tilfælde vil du muligvis ikke erstatte datasættet, især i tilfælde af trinvis opdatering.In some cases you may not want to replace the dataset, especially with incremental refresh. Datasættet i Power BI Desktop kan være meget mindre end det, der er i tjenesten.The dataset in Power BI Desktop could be much smaller than the one in the service. Hvis der er anvendt en politik for trinvis opdatering på datasættet i tjenesten, kan det indeholde flere års historiske data, der går tabt, hvis datasættet erstattes.If the dataset in the service has an incremental refresh policy applied, it may have several years of historical data that will be lost if the dataset is replaced. Opdatering af alle historiske data kan tage flere timer og resultere i systemnedetid for brugerne.Refreshing all the historical data could take hours and result in system downtime for users.

Det er bedre at udføre en udrulning udelukkende af metadata.Instead, it's better to perform a metadata-only deployment. Dette gør det muligt at installere nye objekter uden at miste de historiske data.This allows deployment of new objects without losing the historical data. Hvis du f. eks. har tilføjet et par målinger, kan du nøjes med at udrulle de nye målinger uden at skulle opdatere dataene, hvilket sparer meget tid.For example, if you have added a few measures, you can deploy only the new measures without needing to refresh the data, saving a lot of time.

Når XMLA-slutpunktet er konfigureret til læsning/skrivning, sørger det for kompatibilitet med de værktøjer, der får dette til at ske.When configured for read-write, the XMLA endpoint provides compatibility with tools that make this happen. ALM Toolkit er f. eks. et skemasammenligningsværktøj til Power BI-datasæt og kan kun bruges til udrulning af metadata.For example, the ALM Toolkit is a schema diff tool for Power BI datasets and can be used to perform deployment of metadata only.

Hent og installér den nyeste version af ALM Toolkit fra git-lageret til Analysis Services.Download and install the latest version of the ALM Toolkit from the Analysis Services Git repo. Dokumentationslinks og oplysninger om support er tilgængelige via Hjælp-båndet.Documentation links and information on supportability are available via the Help ribbon. Hvis du vil udføre en udrulning udelukkende af metadata, skal du udføre en sammenligning og vælge den kørende Power BI Desktop-instans som kilde og det eksisterende datasæt i tjenesten som destination.To perform a metadata only deployment, perform a comparison and select the running Power BI Desktop instance as the source, and the existing dataset in the service as the target. Overvej de forskelle, der vises, og spring over opdateringerne af tabellen med partitionerne med trinvise opdatering, eller brug dialogboksen Indstillinger til at angive, at du vil beholde partitioner til tabelopdateringer.Consider the differences displayed and skip the update of the table with incremental refresh partitions, or use the Options dialog to retain partitions for table updates. Valider valget for at sikre destinationsmodellens integritet, og opdater derefter.Validate the selection to ensure the integrity of the target model and then update.

ALM Toolkit

Se ogsåSee also

Netværksmulighed for datasæt med XMLA-slutpunktet Dataset connectivity with the XMLA endpoint
Fejlfinding i forbindelse med opdatering af scenarierTroubleshooting refresh scenarios

Power BI har introduceret Power BI Premium Gen2 som et prøveversionstilbud, der forbedrer Power BI Premium-oplevelsen på følgende områder:Power BI has introduced Power BI Premium Gen2 as a preview offering, which improves the Power BI Premium experience with improvements in the following:

  • YdeevnePerformance
  • Licens pr. brugerPer-user licensing
  • Større skaleringGreater scale
  • Forbedrede målepunkterImproved metrics
  • Automatisk skaleringAutoscaling
  • Reducerede administrationsomkostningerReduced management overhead

Du kan finde flere oplysninger om Power BI Premium Gen2 under Power BI-Premium – Generation 2 (prøveversion).For more information about Power BI Premium Gen2, see Power BI Premium Generation 2 (preview).