Felsöka inkrementell uppdatering
Eftersom det finns två faser när du implementerar en inkrementell uppdateringslösning, där vi först konfigurerar parametrar, filtrerar och definierar en princip i Power BI Desktop, och den andra är den första uppdateringsåtgärden för datauppsättningen och efterföljande uppdateringar i tjänsten, tittar vi på felsökning separat för var och en av dessa faser.
Innan du felsöker inkrementell uppdatering bör du granska Inkrementell uppdatering för datauppsättningar och stegvis information i Konfigurera inkrementell uppdatering.
Konfigurera i Power BI Desktop
De flesta problem som uppstår när du konfigurerar inkrementell uppdatering har att göra med frågedekning. Enligt beskrivningen i Översikt över inkrementell uppdatering av datauppsättningar – Datakällor somstöds måste datakällan ha stöd för frågedekning.
Problem: Det tar för lång tid att läsa in data
När Power Query klickar på Använd i redigeringsredigeraren tar det för lång tid att läsa in data och datorresurser. Det finns flera möjliga orsaker:
Orsak: Matchningsfel för datatyp
Detta kan bero på ett matchningsfel för datatypen där Datum/tid är den datatyp som krävs för parametrarna RangeStart och RangeEnd, men tabelldatumkolumnen som filtren tillämpas på inte är datatypen Datum/tid eller tvärtom. Både datatypen parametrar och den filtrerade datakolumnen måste vara datatypen Datum/tid och formatet måste vara detsamma. Annars kan frågan inte viktas.
Lösning: Verifiera datatypen
Kontrollera att datum/tid-kolumnen för den inkrementella uppdateringstabellen är av datatypen Datum/tid. Om tabellen inte innehåller en kolumn med datatypen Datum/tid, men i stället använder en heltalsdatatyp, kan du skapa en funktion som konverterar datum-/tidsvärdet i parametrarna RangeStart och RangeEnd så att de matchar heltals surrogatnyckeln för datakälltabellen. Mer information finns i Konfigurera inkrementell uppdatering – Konvertera DateTime till heltal.
Orsak: Datakällan stöder inte frågedekning
Enligt beskrivningen i Inkrementell uppdatering för datauppsättningar – Kravär inkrementell uppdatering utformad för datakällor som stöder frågedekning. Se till att datakällsfrågor viktas i Power BI Desktop innan du publicerar till tjänsten, där problem med frågedekning kan vara avsevärt sammansatta.
Lösning: Verifiera och testa frågor
I de flesta fall visas en varning i dialogrutan Princip för inkrementell uppdatering som anger om frågan som ska köras mot datakällan inte stöder frågedekning. I vissa fall kan det dock vara nödvändigt att ytterligare se till att frågedekning är möjlig. Övervaka om möjligt frågan som skickas till datakällan med hjälp av ett verktyg som SQL Profiler. En fråga med filter som baseras på RangeStart och RangeEnd måste köras i en enskild fråga.
Du kan också ange en kort datum/tidsperiod i parametrarna RangeStart och RangeEnd som inte innehåller fler än några tusen rader. Om inläsningen av filtrerade data från datakällan till modellen tar lång tid och är processintensiv innebär det troligen att frågan inte är vikt.
Om du fastställer att frågan inte är vikt kan du läsa vägledningen om frågedekning i Power BI Desktop- och Power Query-frågedekning för hjälp med att identifiera vad som kan förhindra frågedekning och hur, eller om, datakällan även kan stödja frågedekning.
Uppdatering av datauppsättning i tjänsten
Felsökning av problem med inkrementell uppdatering i tjänsten varierar beroende på vilken typ av kapacitet din datauppsättning har publicerats till. Datauppsättningar på Premium stöder användning av verktyg som SQL Server Management Studio (SSMS) för att visa och selektivt uppdatera enskilda partitioner. Power BI Pro datauppsättningar ger å andra sidan inte verktygsåtkomst via XMLA-slutpunkten, så felsökning av problem med inkrementell uppdatering kan kräva lite mer utvärdering och fel.
Problem: Den första uppdateringens tids tar slut
Schemalagd uppdatering för Power BI Pro datauppsättningar i en delad kapacitet har en tidsgräns på två timmar. Den här tidsgränsen ökas till fem timmar för datauppsättningar i en Premium kapacitet. Datakällsystem kan också införa en gräns för frågereturstorlek eller tidsgräns för frågor.
Orsak: Datakällsfrågor viktas inte
Problem med frågedekning kan vanligtvis fastställas i Power BI Desktop innan du publicerar till tjänsten, men det är möjligt att datauppsättningens uppdateringsfrågor inte viktas, vilket leder till långa uppdateringstider och resursutnyttjande för kombinationsmotorn för frågor. Det beror på att en fråga skapas för varje partition i datauppsättningen. Om frågorna inte viktas och data inte filtreras vid datakällan försöker motorn filtrera data.
Lösning: Verifiera frågedekning
Använd ett spårningsverktyg vid datakällan för att fastställa att frågan som skickas för varje partition är en enskild fråga som innehåller ett filter baserat på parametrarna RangeStart och RangeEnd. Om inte kontrollerar du att frågedekning sker i Power BI Desktop när du läser in en liten filtrerad mängd data i modellen. Annars åtgärdar du den först i modellen, utför en uppdatering av metadata endast till datauppsättningen (via XMLA-slutpunkten), eller om en Power BI Pro-datauppsättning på en delad kapacitet, tar bort den ofullständiga datauppsättningen i tjänsten, publicerar om och provar en inledande uppdateringsåtgärd igen.
Om du fastställer att frågor inte viktas kan du läsa vägledningen om frågedekning i Power BI Desktop och Power Query för hjälp med att identifiera vad som kan förhindra frågedekning.
Orsak: Data som läses in i partitioner är för stora
Lösning: Minska datamängdens storlek
I många fall orsakas tidsgränsen av mängden data som måste efterfrågas och läsas in i datamängdspartitionerna överskrider de tidsgränser som har införts av kapaciteten. Minska storleken eller komplexiteten för din datauppsättning eller överväg att dela upp datauppsättningen i mindre delar.
Lösning: Aktivera lagringsformat för stora datamängder
För datauppsättningar som publiceras till Premium-kapaciteter kan du förbättra prestandan för uppdateringsåtgärden och se till att datauppsättningen inte maxar storleksgränser genom att aktivera lagringsformatet för stora datauppsättningar innan du utför den första uppdateringsåtgärden i tjänsten. Mer information finns i Stora datauppsättningar i Power BI Premium.
Lösning: Startuppdatering av Bootstrap
För datauppsättningar som publicerats Premium kapaciteter kan du bootstrap den första uppdateringsåtgärden. Bootstrapping gör att tjänsten kan skapa tabell- och partitionsobjekt för datauppsättningen, men inte läsa in och bearbeta historiska data till någon av partitionerna. Mer information finns i Avancerad inkrementell uppdatering – förhindra tidsgränser vid första fullständiga uppdatering.
Orsak: Tidsgräns för datakällans fråga
Frågor kan begränsas av en standardtidsgräns för datakällan.
Lösning: Åsidosätt tidsgränsen i frågeuttrycket
Många datakällor tillåter åsidosättning av tidsgränsen i frågeuttrycket. Mer information finns i Inkrementell uppdatering för datauppsättningar – tidsgränser.
Problem: Uppdateringen misslyckas på grund av dubblettvärden
Orsak: Postdatum har ändrats
Med en uppdateringsåtgärd uppdateras endast data som har ändrats i datakällan i datauppsättningen. Eftersom data divideras med ett datum rekommenderas inte att datum efter (transaktion) ändras.
Om ett datum ändras av misstag kan två problem uppstå: Användarna märker att en del summor har ändrats i historiska data (som inte ska inträffa) eller att ett fel returneras under en uppdatering som anger att ett unikt värde i själva verket inte är unikt. För det senare kan detta inträffa när tabellen med konfigurerad inkrementell uppdatering används i en 1:N-relation med en annan tabell som 1-sidan och ska ha unika värden. När data ändras (för ett specifikt ID) visas id:t sedan i en annan partition och motorn identifierar att värdet inte är unikt.
Lösning: Uppdatera specifika partitioner
Om ett företag behöver ändra vissa tidigare data från datumen är en möjlig lösning att använda SSMS för att uppdatera alla partitioner från den punkt där ändringen finns fram till den aktuella uppdateringspartitionen, vilket gör att 1-sidan av relationen är unik.
Problem: Data trunkeras
Orsak: Frågegränsen för datakälla har överskridits
Vissa datakällor som Azure Data Explorer, Log Analytics och Application Insights har en gräns på 64 MB (komprimerad) för data som kan returneras för en extern fråga. Azure Data Explorer kan returnera ett explicit fel, men för andra som Log Analytics och Application Insights trunkeras de data som returneras.
Lösning: Ange mindre uppdaterings- och lagringsperioder
Ange mindre uppdaterings- och lagringsperioder i principen. Om du till exempel har angett en uppdateringsperiod på ett år och ett frågefel returneras eller data som returneras trunkeras kan du prova en uppdateringsperiod på 12 månader. Du bör se till att frågor för den aktuella uppdateringspartitionen eller historiska partitioner som baseras på uppdaterings- och lagringsperioderna inte returnerar mer än 64 MB data.
Problem: Uppdateringen misslyckas på grund av partitionsnyckelkonflikter
Orsak: Datum i datakällans datumkolumn uppdateras
Filtret för datumkolumnen används för att dynamiskt partitionera data i intervall i Power BI tjänsten. Inkrementell uppdatering är inte avsedd att stödja fall där den filtrerade datumkolumnen uppdateras i källsystemet. En uppdatering tolkas som en infogning och en borttagning, inte en faktisk uppdatering. Om borttagningen sker i det historiska intervallet och inte det inkrementella intervallet hämtas den inte, vilket kan orsaka datauppdateringsfel på grund av partitionsnyckelkonflikter.
Se även
Datauppdatering i Power BI
Avancerad inkrementell uppdatering med XMLA-slutpunkten
Inkrementell uppdatering för dataflöden