Feilsøke trinnvis oppdatering og sanntidsdata

Det finnes to faser når du implementerer en trinnvis oppdaterings- og sanntidsdataløsning, den første er konfigurering av parametere, filtrering og definering av en policy i Power BI Desktop, og den andre er den første semantiske modelloppdateringsoperasjonen og påfølgende oppdateringer i tjenesten. Denne artikkelen tar for seg feilsøking separat for hver av disse fasene.

Etter å ha partisjonert tabellen i Power Bi-tjeneste, er det viktig å huske på at trinnvise oppdaterte tabeller som også får sanntidsdata med DirectQuery, nå opererer i hybridmodus, noe som betyr at de opererer i både import- og DirectQuery-modus. Alle tabeller med relasjoner til en slik trinnvis oppdatert hybridtabell må bruke dobbel modus, slik at de kan brukes i import- og DirectQuery-modus uten ytelsesstraffer. I tillegg kan rapportvisualobjekter bufre resultater for å unngå å sende spørringer tilbake til datakilden, noe som vil hindre at tabellen henter de nyeste dataoppdateringene i sanntid. Den siste feilsøkingsdelen dekker disse problemene med hybridmodus.

Før du feilsøker trinnvis oppdatering og sanntidsdata, må du se gjennom trinnvis oppdatering for modeller og sanntidsdata og trinnvis informasjon i Konfigurer trinnvis oppdatering og sanntidsdata.

Konfigurere i Power BI Desktop

De fleste problemer som oppstår når du konfigurerer trinnvis oppdatering og sanntidsdata, har å gjøre med spørringsdelegering. Som beskrevet i trinnvis oppdatering for modelloversikt – støttede datakilder, må datakilden støtte spørringsdelegering.

Problem: Det tar for lang tid å laste inn data

Når du har valgt Bruk i Power Query-redigering, tar innlasting av data svært lang tid og dataressurser. Det finnes flere mulige årsaker.

Årsak: Manglende samsvar mellom datatyper

Dette problemet kan skyldes en datatypekonflikt der Date/Time er den nødvendige datatypen for RangeStart og RangeEnd parameterne, men tabelldatokolonnen som filtrene brukes på, er ikke Date/Time datatype eller omvendt. Både datatypen for parameterne og den filtrerte datakolonnen må være Date/Time datatype, og formatet må være det samme. Hvis ikke, kan ikke spørringen brettes.

Løsning: Kontrollere datatype

Kontroller at dato/klokkeslett-kolonnen for tabellen for trinnvis oppdatering er av Date/Time datatypen. Hvis tabellen ikke inneholder en kolonne med Date/Time datatype, men i stedet bruker en heltallsdatatype, kan du opprette en funksjon som konverterer dato/klokkeslett-verdien i RangeStart og RangeEnd -parameterne for å samsvare med surrogatnøkkelen for heltall i datakildetabellen. Hvis du vil ha mer informasjon, kan du se Konfigurere trinnvis oppdatering – Konverter DateTime til heltall.

Årsak: Datakilden støtter ikke spørringsdelegering

Som beskrevet i trinnvis oppdatering og sanntidsdata for modeller – krav, er trinnvis oppdatering utformet for datakilder som støtter spørringsdelegering. Kontroller at datakildespørringer brettes i Power BI Desktop før du publiserer til tjenesten, der problemer med spørringsdelegering kan være betydelig sammensatt. Denne fremgangsmåten er spesielt viktig når du inkluderer sanntidsdata i en trinnvis oppdateringspolicy fordi DirectQuery-partisjonen i sanntid krever spørringsdelegering.

Løsning: Kontrollere og teste spørringer

I de fleste tilfeller vises en advarsel i dialogboksen Policy for trinnvis oppdatering som angir om spørringen som skal kjøres mot datakilden, ikke støtter spørringsdelegering. I noen tilfeller kan det imidlertid være nødvendig å sikre at spørringsdelegering er mulig. Hvis det er mulig, kan du overvåke spørringen som sendes til datakilden ved hjelp av et verktøy som SQL Profiler. En spørring med filtre basert på RangeStart og RangeEnd må kjøres i én enkelt spørring.

Du kan også angi en kort dato/tidsperiode i RangeStart og RangeEnd parametere som ikke inneholder mer enn noen få tusen rader. Hvis belastningen av filtrerte data fra datakilden til modellen tar lang tid og prosessen er intensiv, betyr det sannsynligvis at spørringen ikke blir brettet.

Hvis du finner ut at spørringen ikke blir brettet, kan du se Veiledning for spørringsdelegering i Power BI Desktop og Power Query-spørringsdelegering for å få hjelp til å identifisere hva som kan hindre spørringsdelegering og hvordan, eller hvis datakilden til og med kan støtte spørringsdelegering.

Semantisk modelloppdatering i tjenesten

Feilsøking av trinnvise oppdateringsproblemer i tjenesten varierer avhengig av hvilken type kapasitet modellen har blitt publisert til. Semantiske modeller på Premium-kapasiteter støtter bruk av verktøy som SQL Server Management Studio (SSMS) for å vise og selektivt oppdatere individuelle partisjoner. Power BI Pro-modeller gir derimot ikke verktøytilgang gjennom XMLA-endepunktet, så feilsøking av trinnvise oppdateringsproblemer kan kreve litt mer prøving og feiling.

Problem: Innledende oppdatering blir tidsavbrutt

Planlagt oppdatering for Power BI Pro-modeller på en delt kapasitet har en tidsgrense på to timer. Denne tidsgrensen økes til fem timer for modeller i en Premium-kapasitet. Datakildesystemer kan også innføre en størrelsesgrense for spørringsretur eller tidsavbrudd for spørring.

Årsak: Datakildespørringer blir ikke brettet

Selv om problemer med spørringsdelegering vanligvis kan fastslås i Power BI Desktop før publisering til tjenesten, er det mulig at modelloppdateringsspørringer ikke blir brettet, noe som fører til store oppdateringstider og ressursutnyttelse for spørringsflettingsmotor. Denne situasjonen skjer fordi det opprettes en spørring for hver partisjon i modellen. Hvis spørringene ikke blir brettet, og dataene ikke filtreres på datakilden, prøver motoren å filtrere dataene.

Løsning: Bekreft spørringsdelegering

Bruk et sporingsverktøy i datakilden til å fastslå at spørringen som sendes for hver partisjon, er én enkelt spørring som inneholder et filter basert på RangeStart- og RangeEnd-parameterne. Hvis ikke, kontrollerer du at spørringsdelegering forekommer i Power BI Desktop-modellen når du laster inn en liten filtrert mengde data i modellen. Hvis ikke, kan du få det løst i modellen først, utføre en metadataoppdatering bare til modellen (ved hjelp av XMLA-endepunkt), eller hvis en Power BI Pro-modell på en delt kapasitet sletter du den ufullstendige modellen i tjenesten, publiserer på nytt og prøver en første oppdateringsoperasjon på nytt.

Hvis du finner ut at spørringer ikke blir brettet, kan du se Veiledning for spørringsdelegering i Power BI Desktop og Power Query-spørringsdelegering for å få hjelp til å identifisere hva som kan hindre spørringsdelegering.

Årsak: Data som lastes inn i partisjoner, er for store

Løsning: Redusere modellstørrelsen

I mange tilfeller er tidsavbruddet forårsaket av mengden data som må spørres og lastes inn i modellpartisjonene, overskrider tidsbegrensningene som er pålagt av kapasiteten. Reduser størrelsen eller kompleksiteten på modellen, eller vurder å bryte modellen i mindre deler.

Løsning: Aktiver lagringsformat for stor modell

For modeller publisert til Premium-kapasiteter, kan du forbedre ytelsen for oppdateringsoperasjoner hvis modellen vokser utover 1 GB eller mer, og sikre at modellen ikke maksimerer størrelsesgrensene ved å aktivere Lagringsformat for stor modell før du utfører den første oppdateringsoperasjonen i tjenesten. Hvis du vil ha mer informasjon, kan du se Store modeller i Power BI Premium.

Løsning: Bootstrap første oppdatering

For modeller som er publisert til Premium-kapasiteter, kan du starte den første oppdateringsoperasjonen. Bootstrapping gjør det mulig for tjenesten å opprette tabell- og partisjonsobjekter for modellen, men ikke laste inn og behandle historiske data i noen av partisjonene. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – Forhindre tidsavbrudd ved første fullstendige oppdatering.

Årsak: Tidsavbrudd for datakildespørring

Spørringer kan begrenses av en standard tidsbegrensning for datakilden.

Løsning: Overstyre tidsgrensen i spørringsuttrykket

Mange datakilder tillater overstyrende tidsbegrensning i spørringsuttrykket. Hvis du vil ha mer informasjon, kan du se Trinnvis oppdatering for modeller – tidsbegrensninger.

Problem: Oppdatering mislykkes på grunn av dupliserte verdier

Årsak: Innleggsdatoer er endret

Med en oppdateringsoperasjon oppdateres bare data som er endret i datakilden, i modellen. Ettersom dataene er delt på en dato, anbefales det at datoer etter (transaksjon) ikke endres.

Hvis en dato endres ved et uhell, kan det oppstå to problemer: Brukere legger merke til at noen totalsummer endres i de historiske dataene (som ikke skal skje), eller under en oppdatering returneres en feil som angir at en unik verdi ikke faktisk er unik. For sistnevnte kan denne situasjonen skje når tabellen med trinnvis oppdatering konfigurert brukes i en relasjon med en 1:N annen tabell som 1 side og bør ha unike verdier. Når dataene endres for en bestemt ID, vises ID-en i en annen partisjon, og motoren oppdager at verdien ikke er unik.

Løsning: Oppdatere bestemte partisjoner

Der det er et forretningsbehov for å endre tidligere data fra datoene, er en mulig løsning å bruke SSMS til å oppdatere alle partisjoner fra det punktet hvor endringen er plassert opp til gjeldende oppdateringspartisjon, og dermed holde 1 siden av relasjonen unik.

Problem: Data avkortes

Årsak: Spørringsgrensen for datakilde er overskredet

Noen datakilder, for eksempel Azure Data Explorer, Log Analytics og Application Insights, har en grense på 64 MB (komprimert) på data som kan returneres for en ekstern spørring. Azure Data Explorer kan returnere en eksplisitt feil, men for andre som Log Analytics og Application Insights avkortes dataene.

Løsning: Angi mindre oppdaterings- og lagringsperioder

Angi mindre oppdaterings- og lagringsperioder i policyen. Hvis du for eksempel har angitt en oppdateringsperiode på ett år, og en spørringsfeil returneres eller data som returneres, avkortes, kan du prøve en oppdateringsperiode på 12 måneder. Du vil sikre at spørringer for gjeldende oppdateringspartisjon eller eventuelle historiske partisjoner basert på oppdaterings- og lagringsperiodene ikke returnerer mer enn 64 MB med data.

Problem: Oppdatering mislykkes på grunn av partisjonsnøkkelkonflikter

Årsak: Dato i datokolonnen i datakilden oppdateres

Filteret på datokolonnen brukes til dynamisk å partisjonere dataene i periodeområder i Power Bi-tjeneste. Trinnvis oppdatering er ikke utformet for å støtte tilfeller der den filtrerte datokolonnen oppdateres i kildesystemet. En oppdatering tolkes som en innsetting og sletting, ikke en faktisk oppdatering. Hvis slettingen forekommer i det historiske området og ikke det trinnvise området, blir det ikke plukket opp, noe som kan føre til dataoppdateringsfeil på grunn av partisjonsnøkkelkonflikter.

Hybridmodus i tjenesten (forhåndsvisning)

Når Power BI bruker en policy for trinnvis oppdatering med sanntidsdata, gjør den tabellen trinnvis oppdatert til en hybridtabell som fungerer i både import- og DirectQuery-modus. Legg merke til DirectQuery-partisjonen på slutten av listen over partisjoner nedenfor i en eksempeltabell. Tilstedeværelsen av en DirectQuery-partisjon har implikasjoner for relaterte tabeller og rapportvisualobjekter som spør denne tabellen.

Skjermbilde av hybridtabell.

Problem: Spørringsytelsen er dårlig

Hybridtabeller som opererer i både import- og DirectQuery-modus krever at relaterte tabeller opererer i dobbel modus, slik at de kan fungere som hurtigbufrede eller ikke bufrede, avhengig av konteksten til spørringen som sendes til Power BI-modellen. Dobbel modus gjør det mulig for Power BI å redusere antall begrensede relasjoner i modellen og generere effektive datakildespørringer for å sikre god ytelse. Begrensede relasjoner kan ikke sendes til datakilden som krever at Power BI henter mer data enn nødvendig. Siden doble tabeller kan fungere som enten DirectQuery- eller Importer-tabeller, unngås denne situasjonen.

Når du konfigurerer en policy for trinnvis oppdatering, minner Power BI Desktop deg på å bytte relaterte tabeller til dobbel modus når du velger Hent de nyeste dataene i sanntid med DirectQuery (bare Premium). Sørg i tillegg for at du ser gjennom alle eksisterende tabellrelasjoner i modellvisning.

Skjermbilde som viser konvertering av relaterte tabeller til dobbel modus.

Tabeller som for øyeblikket opererer i DirectQuery-modus, byttes enkelt til dobbel modus. Velg Dobbel fra listeboksen lagringsmodus under Avansert i tabellegenskapene. Tabeller som for øyeblikket opererer i importmodus, krever imidlertid manuelt arbeid. Doble tabeller har samme funksjonelle begrensninger som DirectQuery-tabeller. Power BI Desktop kan derfor ikke konvertere importtabeller fordi de kan være avhengige av annen funksjonalitet som ikke er tilgjengelig i dobbel modus. Du må gjenopprette disse tabellene manuelt i DirectQuery-modus og deretter konvertere dem til dobbel modus. Hvis du vil ha mer informasjon, kan du se Behandle lagringsmodus i Power BI Desktop.

Problem: Rapportvisualobjekter viser ikke de nyeste dataene

Årsak: Spørringsresultater for Power BI-hurtigbuffere forbedrer ytelsen og reduserer belastningen på bakenden

Som standard bufrer Power BI spørringsresultater, slik at spørringer av rapportvisualobjekter kan behandles raskt selv om de er basert på DirectQuery. Hvis du unngår unødvendige datakildespørringer, forbedres ytelsen og datakildebelastningen reduseres, men det kan også bety at de nyeste dataendringene i kilden ikke er inkludert i resultatene.

Løsning: Konfigurere automatisk sideoppdatering

Hvis du vil fortsette å hente de nyeste dataendringene fra kilden, konfigurerer du automatisk sideoppdatering for rapportene i Power Bi-tjeneste. Automatisk sideoppdatering kan utføres med faste intervaller, for eksempel fem sekunder eller ti minutter. Når det bestemte intervallet er nådd, sender alle visualobjekter på denne siden en oppdateringsspørring til datakilden og oppdaterer deretter. Du kan også oppdatere visualobjekter på en side basert på å oppdage endringer i dataene. Denne fremgangsmåten krever et endringsgjenkjenningsmål som Power BI deretter bruker til å undersøke datakilden for endringer. Endringsgjenkjenning støttes bare i arbeidsområder som er en del av en Premium-kapasitet. Hvis du vil ha mer informasjon, kan du se Automatisk sideoppdatering i Power BI.