Foretag fejlfinding af trinvis opdatering og data i realtid

  • Artikel

Der er to faser, når du implementerer en trinvis opdatering og en dataløsning i realtid, hvor den første er konfiguration af parametre, filtrering og definition af en politik i Power BI Desktop, og den anden er den indledende semantiske modelopdateringshandling og efterfølgende opdateringer i tjenesten. I denne artikel beskrives fejlfinding separat for hver af disse faser.

Når du har partitioneret tabellen i Power BI-tjeneste, er det vigtigt at være opmærksom på, at tabeller, der opdateres trinvist, og som også henter data i realtid med DirectQuery, nu fungerer i hybridtilstand, hvilket betyder, at de fungerer i både import- og DirectQuery-tilstand. Alle tabeller med relationer til en sådan hybridtabel, der opdateres trinvist, skal bruge Dual-tilstand, så de kan bruges i import- og DirectQuery-tilstand uden sanktioner for ydeevne. Desuden kan rapportvisualiseringer cachelagre resultater for at undgå at sende forespørgsler tilbage til datakilden, hvilket forhindrer tabellen i at hente de nyeste dataopdateringer i realtid. Det sidste fejlfindingsafsnit dækker disse hybridtilstandsproblemer.

Før du foretager fejlfinding af trinvis opdatering og data i realtid, skal du gennemse Trinvis opdatering for modeller og data i realtid og trinvise oplysninger i Konfigurer trinvis opdatering og data i realtid.

Konfiguration i Power BI Desktop

De fleste problemer, der opstår, når du konfigurerer trinvis opdatering og data i realtid, har at gøre med forespørgselsdelegering. Som beskrevet i oversigt over trinvis opdatering af modeller – Understøttede datakilder skal din datakilde understøtte forespørgselsdelegering.

Problem: Indlæsning af data tager for lang tid

Når du har valgt Anvend i Power Query-editor, tager indlæsning af data for meget tid og computerressourcer. Der er flere mulige årsager.

Årsag: Datatypen stemmer ikke overens

Dette problem kan skyldes en uoverensstemmelse mellem datatyper, hvor Date/Time er den påkrævede datatype for parametrene RangeStart og RangeEnd , men den tabeldatokolonne, som filtrene anvendes på, er ikke Date/Time datatype eller omvendt. Både parameterdatatypen og den filtrerede datakolonne skal være Date/Time datatype, og formatet skal være det samme. Hvis ikke, kan forespørgslen ikke foldes.

Løsning: Kontrollér datatype

Kontrollér, at kolonnen dato/klokkeslæt for den trinvise opdateringstabel er af Date/Time datatypen. Hvis tabellen ikke indeholder en kolonne af Date/Time datatypen, men i stedet bruger en heltalsdatatype, kan du oprette en funktion, der konverterer dato-/klokkeslætsværdien i parametrene RangeStart og RangeEnd , så den svarer til heltals surrogatnøglen i datakildetabellen. Du kan få mere at vide under Konfigurer trinvis opdatering – Konvertér DateTime til heltal.

Årsag: Datakilden understøtter ikke forespørgselsdelegering

Som beskrevet i Trinvis opdatering og data i realtid for modeller – Krav er trinvis opdatering designet til datakilder, der understøtter forespørgselsdelegering. Sørg for, at datakildeforespørgsler foldes i Power BI Desktop, før de publiceres til tjenesten, hvor problemer med forespørgselsdelegering kan forværres betydeligt. Denne fremgangsmåde er især vigtig, når du medtager data i realtid i en politik for trinvis opdatering, fordi DirectQuery-partitionen i realtid kræver forespørgselsdelegering.

Løsning: Kontrollér og test forespørgsler

I de fleste tilfælde vises der en advarsel i dialogboksen Politik for trinvis opdatering, der angiver, om forespørgslen, der skal udføres i forhold til datakilden, ikke understøtter forespørgselsdelegering. I nogle tilfælde kan det dog være nødvendigt yderligere at sikre, at forespørgselsdelegering er mulig. Hvis det er muligt, skal du overvåge den forespørgsel, der overføres til datakilden, ved hjælp af et værktøj som SQL Profiler. En forespørgsel med filtre, der er baseret på RangeStart og RangeEnd skal udføres i en enkelt forespørgsel.

Du kan også angive en kort dato-/klokkeslætsperiode i parametrene RangeStart og RangeEnd , der ikke indeholder mere end nogle få tusinde rækker. Hvis indlæsningen af filtrerede data fra datakilden til modellen tager lang tid og er proceskrævende, betyder det sandsynligvis, at forespørgslen ikke delegeres.

Hvis du finder ud af, at forespørgslen ikke foldes, kan du se Vejledning til forespørgselsdelegering i Power BI Desktop og Power Query-forespørgselsdelegering for at få hjælp til at identificere, hvad der kan forhindre forespørgselsdelegering, og hvordan eller om datakilden endda kan understøtte forespørgselsdelegering.

Opdatering af semantisk model i tjenesten

Fejlfinding af problemer med trinvis opdatering i tjenesten varierer, afhængigt af hvilken type kapacitet din model er publiceret til. Semantiske modeller på Premium-kapaciteter understøtter brug af værktøjer som SQL Server Management Studio (SSMS) til at få vist og selektivt opdatere individuelle partitioner. Power BI Pro-modeller giver på den anden side ikke værktøjsadgang via XMLA-slutpunktet, så fejlfinding af problemer med trinvis opdatering kan kræve lidt mere prøveversion og fejl.

Problem: Der opstår timeout for den indledende opdatering

Planlagt opdatering af Power BI Pro-modeller på en delt kapacitet har en tidsgrænse på to timer. Denne tidsgrænse øges til fem timer for modeller i en Premium-kapacitet. Datakildesystemer kan også medføre en grænse for forespørgsels returstørrelse eller timeout for forespørgsler.

Årsag: Datakildeforespørgsler foldes ikke

Selvom problemer med forespørgselsdelegering normalt kan bestemmes i Power BI Desktop, før de publiceres til tjenesten, er det muligt, at forespørgsler om modelopdatering ikke foldes, hvilket fører til store opdateringstider og ressourceudnyttelse af forespørgsels miksmotorer. Denne situation opstår, fordi der oprettes en forespørgsel for hver partition i modellen. Hvis forespørgslerne ikke foldes, og data ikke filtreres i datakilden, forsøger programmet at filtrere dataene.

Løsning: Kontrollér forespørgselsdelegering

Brug et sporingsværktøj i datakilden til at bestemme, om den forespørgsel, der overføres for hver partition, er en enkelt forespørgsel, der indeholder et filter, der er baseret på parametrene RangeStart og RangeEnd. Hvis ikke, skal du kontrollere, at forespørgselsdelegering sker i Power BI Desktop-modellen, når der indlæses en lille filtreret mængde data i modellen. Hvis ikke, skal du få den løst i modellen først, kun udføre en opdatering af metadata til modellen (ved hjælp af XMLA-slutpunktet), eller hvis en Power BI Pro-model på en delt kapacitet, skal du slette den ufuldstændige model i tjenesten, publicere igen og prøve en indledende opdateringshandling igen.

Hvis du finder ud af, at forespørgsler ikke foldes, kan du se Vejledningen til forespørgselsdelegering i Power BI Desktop og Power Query-forespørgselsdelegering for at få hjælp til at identificere, hvad der kan forhindre forespørgselsdelegering.

Årsag: Data, der indlæses i partitioner, er for store

Løsning: Reducer modelstørrelsen

I mange tilfælde skyldes timeouten den mængde data, der skal forespørges og indlæses i modelpartitionerne, og som overskrider de tidsgrænser, der er pålagt af kapaciteten. Reducer størrelsen eller kompleksiteten af din model, eller overvej at opdele modellen i mindre dele.

Løsning: Aktivér lagringsformat for store modeller

Hvis modellen vokser til mere end 1 GB for modeller, der er publiceret til Premium-kapaciteter, kan du forbedre ydeevnen for opdateringshandlinger og sikre, at modellen ikke overskrider størrelsesgrænserne ved at aktivere Lagringsformat for store modeller, før du udfører den første opdateringshandling i tjenesten. Du kan få mere at vide under Store modeller i Power BI Premium.

Løsning: Startstrap indledende opdatering

For modeller, der er publiceret til Premium-kapaciteter, kan du starte den indledende opdateringshandling. Bootstrapping gør det muligt for tjenesten at oprette tabel- og partitionsobjekter for modellen, men ikke indlæse og behandle historiske data i nogen af partitionerne. Du kan få mere at vide under Avanceret trinvis opdatering – Undgå timeout ved indledende fuld opdatering.

Årsag: Timeout for datakildeforespørgsel

Forespørgsler kan begrænses af en standardtidsgrænse for datakilden.

Løsning: Tilsidesæt tidsgrænsen i forespørgselsudtrykket

Mange datakilder tillader tilsidesættelse af tidsbegrænsning i forespørgselsudtrykket. Du kan få mere at vide under Trinvis opdatering af modeller – Tidsgrænser.

Problem: Opdateringen mislykkes på grund af dublerede værdier

Årsag: Postdatoer er blevet ændret

Med en opdateringshandling opdateres kun data, der er ændret i datakilden, i modellen. Da dataene divideres med en dato, anbefales det, at postdatoer (transaktionsdatoer) ikke ændres.

Hvis en dato ændres ved et uheld, kan der opstå to problemer: Brugerne bemærker, at nogle totaler er ændret i de historiske data (det er ikke meningen, at det skal ske), eller at der under en opdatering returneres en fejl, der angiver, at en entydig værdi faktisk ikke er entydig. For sidstnævnte kan denne situation opstå, når tabellen med trinvis opdatering konfigureret bruges i en relation med en 1:N anden tabel som 1 side og skal have entydige værdier. Når dataene ændres for et bestemt id, vises dette id derefter i en anden partition, og programmet registrerer, at værdien ikke er entydig.

Løsning: Opdater bestemte partitioner

Hvor der er et forretningsmæssigt behov for at ændre nogle tidligere data fra datoerne, er en mulig løsning at bruge SSMS til at opdatere alle partitioner fra det punkt, hvor ændringen er placeret op til den aktuelle opdateringspartition, så siden af relationen bevares 1 entydig.

Problem: Dataene afkortes

Årsag: Grænsen for datakildeforespørgslen er overskredet

Nogle datakilder, f.eks. Azure Data Explorer, Log Analytics og Application Insights, har en grænse på 64 MB (komprimeret) på data, der kan returneres for en ekstern forespørgsel. Azure Data Explorer returnerer muligvis en eksplicit fejl, men for andre, f.eks. Log Analytics og Application Insights, afkortes de returnerede data.

Løsning: Angiv mindre opdaterings- og lagerperioder

Angiv mindre opdaterings- og lagringsperioder i politikken. Hvis du f.eks. har angivet en opdateringsperiode på ét år, og der returneres en forespørgselsfejl, eller hvis de returnerede data afkortes, kan du prøve en opdateringsperiode på 12 måneder. Du vil sikre, at forespørgsler for den aktuelle opdateringspartition eller historiske partitioner, der er baseret på perioderne Opdater og Gem, ikke returnerer mere end 64 MB data.

Problem: Opdateringen mislykkes på grund af konflikter mellem partitionsnøglen

Årsag: Dato i datokolonnen i datakilden opdateres

Filteret på datokolonnen bruges til dynamisk at partitionere dataene i periodeområder i Power BI-tjeneste. Trinvis opdatering er ikke designet til at understøtte tilfælde, hvor den filtrerede datokolonne opdateres i kildesystemet. En opdatering fortolkes som en indsættelse og en sletning, ikke en faktisk opdatering. Hvis sletningen sker i det historiske område og ikke i det trinvise interval, hentes den ikke, hvilket kan medføre fejl i dataopdateringen på grund af partitionsnøglekonflikter.

Hybridtilstand i tjenesten (prøveversion)

Når Power BI anvender en politik for trinvis opdatering med data i realtid, konverteres den trinvist opdaterede tabel til en hybridtabel, der fungerer i både import- og DirectQuery-tilstand. Bemærk DirectQuery-partitionen i slutningen af følgende partitionsliste for en eksempeltabel. Tilstedeværelsen af en DirectQuery-partition har konsekvenser for relaterede tabeller og rapportvisualiseringer, der forespørger denne tabel.

Skærmbillede af hybridtabel.

Problem: Forespørgselsydeevnen er dårlig

Hybridtabeller, der fungerer i både import- og DirectQuery-tilstand, kræver, at alle relaterede tabeller fungerer i Dual-tilstand, så de enten kan fungere som cachelagret eller ikke cachelagret, afhængigt af konteksten for den forespørgsel, der er sendt til Power BI-modellen. Dual-tilstand gør det muligt for Power BI at reducere antallet af begrænsede relationer i modellen og generere effektive datakildeforespørgsler for at sikre en god ydeevne. Begrænsede relationer kan ikke pushes til datakilden, der kræver, at Power BI henter flere data end nødvendigt. Da Dual-tabeller kan fungere som enten DirectQuery- eller Import-tabeller, undgås denne situation.

Når du konfigurerer en politik for trinvis opdatering, minder Power BI Desktop dig om at skifte relaterede tabeller til Dual-tilstand, når du vælger Hent de nyeste data i realtid med DirectQuery (kun Premium). Derudover skal du kontrollere, at du gennemser alle eksisterende tabelrelationer i Modelvisning.

Skærmbillede, der viser konvertering af relaterede tabeller til dobbelttilstand.

Tabeller, der i øjeblikket fungerer i DirectQuery-tilstand, skiftes nemt til Dual-tilstand. I tabelegenskaberne under Avanceret skal du vælge Dual på listen Lagringstilstand. Tabeller, der i øjeblikket fungerer i importtilstand, kræver dog manuelt arbejde. Dual-tabeller har de samme funktionelle begrænsninger som DirectQuery-tabeller. Power BI Desktop kan derfor ikke konvertere importtabeller, fordi de muligvis er afhængige af andre funktioner, der ikke er tilgængelige i Dual-tilstand. Du skal genoprette disse tabeller manuelt i DirectQuery-tilstand og derefter konvertere dem til Dual-tilstand. Du kan få mere at vide under Administrer lagringstilstand i Power BI Desktop.

Problem: Rapportvisualiseringer viser ikke de nyeste data

Årsag: Power BI cachelagrer forespørgselsresultater for at forbedre ydeevnen og reducere back end-belastningen

Power BI cachelagrer som standard forespørgselsresultater, så forespørgsler fra rapportvisualiseringer kan behandles hurtigt, selvom de er baseret på DirectQuery. Undgå unødvendige datakildeforespørgsler forbedrer ydeevnen og reducerer indlæsningen af datakilder, men det kan også betyde, at de seneste dataændringer i kilden ikke er inkluderet i resultaterne.

Løsning: Konfigurer automatisk sideopdatering

Hvis du vil fortsætte med at hente de seneste dataændringer fra kilden, skal du konfigurere automatisk sideopdatering for dine rapporter i Power BI-tjeneste. Automatisk sideopdatering kan udføres med faste intervaller, f.eks. fem sekunder eller ti minutter. Når dette specifikke interval nås, sender alle visualiseringer på den pågældende side en opdateringsforespørgsel til datakilden og opdateres tilsvarende. Du kan også opdatere visualiseringer på en side baseret på registrering af ændringer i dataene. Denne fremgangsmåde kræver en måling til registrering af ændringer, som Power BI derefter bruger til at forespørge datakilden om ændringer. Registrering af ændringer understøttes kun i arbejdsområder, der er en del af en Premium-kapacitet. Du kan få mere at vide under Automatisk sideopdatering i Power BI.

Relateret indhold