Problemen met incrementeel vernieuwen oplossen

Omdat er twee fasen zijn bij het implementeren van een oplossing voor incrementeel vernieuwen, de eerste is het configureren van parameters, filteren en definiëren van een beleid in Power BI Desktop, en de tweede is de eerste vernieuwingsbewerking voor gegevenssets en daaropvolgende vernieuwingen in de service, kijken we afzonderlijk naar het oplossen van problemen voor elk van deze fasen.

Voordat u problemen met incrementeel vernieuwen gaat oplossen, controleert u Incrementeel vernieuwen voor gegevenssets en stapsgewijze informatie in Incrementeel vernieuwen configureren.

Configureren in Power BI Desktop

De meeste problemen die optreden bij het configureren van incrementeel vernieuwen hebben te maken met het vouwen van query's. Zoals beschreven in Overzicht incrementeel vernieuwen voor gegevenssets - Ondersteunde gegevensbronnen,moet uw gegevensbron ondersteuning bieden voor het vouwen van query's.

Probleem: het laden van gegevens duurt te lang

In Power Query Editor duurt het laden van gegevens veel tijd en computerbronnen nadat u op Toepassen hebt geklikt. Er zijn verschillende mogelijke oorzaken:

Oorzaak: Gegevenstype komt niet overeen

Dit kan worden veroorzaakt door een gegevenstype dat niet overeenkomen, waarbij Datum/tijd het vereiste gegevenstype is voor de parameters RangeStart en RangeEnd, maar de tabeldatumkolom waarop de filters worden toegepast, geen datum/tijd-gegevenstype is, of vice versa. Zowel het gegevenstype parameters als de gefilterde gegevenskolom moeten datum/tijd-gegevenstype zijn en de indeling moet hetzelfde zijn. Zo niet, dan kan de query niet worden gevouwen.

Oplossing: Gegevenstype controleren

Controleer of de datum/tijd-kolom voor de tabel incrementeel vernieuwen van het gegevenstype Datum/tijd is. Als uw tabel geen kolom bevat van het gegevenstype Datum/tijd, maar in plaats daarvan een gegevenstype geheel getal gebruikt, kunt u een functie maken die de datum/tijd-waarde in de parameters RangeStart en RangeEnd converteert zodat deze overeenkomen met de surrogaatsleutel voor gehele getallen van de gegevensbrontabel. Zie Incrementeel vernieuwen configureren - Datum/tijd converteren naar een geheel getal voor meer informatie.

Oorzaak: De gegevensbron biedt geen ondersteuning voor het vouwen van query's

Zoals beschreven in Incrementeel vernieuwen voor gegevenssets - Vereisten,is incrementeel vernieuwen ontworpen voor gegevensbronnen die ondersteuning bieden voor het vouwen van query's. Zorg ervoor dat gegevensbronquery's worden gevouwen in Power BI Desktop publiceren naar de service, waarbij problemen met het vouwen van query's aanzienlijk kunnen worden verergerd.

Oplossing: Query's controleren en testen

In de meeste gevallen wordt er een waarschuwing weergegeven in het dialoogvenster Beleid voor incrementeel vernieuwen dat aangeeft of de query die moet worden uitgevoerd op basis van de gegevensbron geen ondersteuning biedt voor het vouwen van query's. In sommige gevallen kan het echter nodig zijn om ervoor te zorgen dat query's kunnen worden gevouwen. Controleer indien mogelijk de query die wordt doorgegeven aan de gegevensbron met behulp van een hulpprogramma zoals SQL Profiler. Een query met filters op basis van RangeStart en RangeEnd moet worden uitgevoerd in één query.

U kunt ook een korte datum/tijd-periode opgeven in de parameters RangeStart en RangeEnd die niet meer dan een paar duizend rijen bevatten. Als het laden van gefilterde gegevens uit de gegevensbron naar het model lang duurt en procesintensief is, betekent dit waarschijnlijk dat de query niet wordt gevouwen.

Als u bepaalt dat de query niet wordt gevouwen, raadpleegt u Query Folding guidance in Power BI Desktop and Power Query query folding (Query Folding-richtlijnen in Power BI Desktop en Power Query Query Folding) voor hulp bij het identificeren van wat query folding mogelijk verhindert en hoe, of, of de gegevensbron zelfs ondersteuning kan bieden voor het vouwen van query's.

Gegevensset vernieuwen in de service

Het oplossen van problemen met incrementeel vernieuwen in de service is afhankelijk van het type capaciteit waarin uw gegevensset is gepubliceerd. Gegevenssets op Premium ondersteunen het gebruik van hulpprogramma's zoals SQL Server Management Studio (SSMS) om afzonderlijke partities weer te geven en selectief te vernieuwen. Power BI Pro gegevenssets daarentegen bieden geen toegang tot hulpprogramma's via het XMLA-eindpunt, dus voor het oplossen van problemen met incrementeel vernieuwen is mogelijk iets meer trial and error vereist.

Probleem: Er t/m de eerste keer vernieuwen is een tijdsvernieuwing

Geplande vernieuwing voor Power BI Pro gegevenssets op een gedeelde capaciteit hebben een tijdslimiet van twee uur. Deze tijdslimiet wordt verhoogd tot vijf uur voor gegevenssets in een Premium capaciteit. Gegevensbronsystemen kunnen ook een limiet voor de retourgrootte of time-out van query's opleggen.

Oorzaak: Gegevensbronquery's worden niet gevouwen

Hoewel problemen met het vouwen van query's meestal kunnen worden vastgesteld in Power BI Desktop voordat ze naar de service worden gepubliceerd, is het mogelijk dat query's voor het vernieuwen van gegevenssets niet worden gevouwen, wat leidt tot overmatige vernieuwingstijden en resourcegebruik van de mashup-engine voor query's. Dit komt doordat er een query wordt gemaakt voor elke partitie in de gegevensset. Als de query's niet worden gevouwen en gegevens niet worden gefilterd op de gegevensbron, probeert de engine de gegevens te filteren.

Oplossing: Query Folding controleren

Gebruik een traceringshulpprogramma bij de gegevensbron om te bepalen of de query die wordt doorgegeven voor elke partitie één query is die een filter bevat op basis van de parameters RangeStart en RangeEnd. Zo niet, controleert u of query folding plaatsvindt in het Power BI Desktop model bij het laden van een kleine gefilterde hoeveelheid gegevens in het model. Als dat niet het probleem zich voordeed in het model, voert u een alleen metagegevensupdate uit voor de gegevensset (via XMLA-eindpunt). Als u een Power BI Pro-gegevensset op een gedeelde capaciteit hebt, verwijdert u de onvolledige gegevensset in de service, voert u de gegevensset opnieuw uit en probeert u een eerste vernieuwingsbewerking opnieuw uit te voeren.

Als u bepaalt dat query's niet worden gevouwen, raadpleegt u Query Folding-richtlijnen in Power BI Desktop en Power Query Query Folding voor hulp bij het identificeren van wat query folding mogelijk verhindert.

Oorzaak: Gegevens die in partities zijn geladen, zijn te groot

Oplossing: Grootte van gegevensset beperken

In veel gevallen wordt de time-out veroorzaakt door de hoeveelheid gegevens die moet worden opgevraagd en geladen in de partities van de gegevensset, en overschrijdt deze de tijdslimieten die zijn opgelegd door de capaciteit. Verklein de grootte of complexiteit van uw gegevensset of overweeg om de gegevensset in kleinere delen op te delen.

Oplossing: Opslagindeling voor grote gegevenssets inschakelen

Voor gegevenssets die naar Premium-capaciteiten worden gepubliceerd, kunt u, als de gegevensset groter wordt dan 1 GB of meer, de prestaties van de vernieuwingsbewerking verbeteren en ervoor zorgen dat de gegevensset geen maximale groottelimieten bereikt door de opslagindeling voor grote gegevenssets in te stellen voordat u de eerste vernieuwingsbewerking in de service gaat uitvoeren. Zie Grote gegevenssets in Power BI Premium voor meer Power BI Premium.

Oplossing: Bootstrap-initiële vernieuwing

Voor gegevenssets die naar Premium zijn gepubliceerd, kunt u de initiële vernieuwingsbewerking bootstrapen. Met bootstrapping kan de service tabel- en partitieobjecten maken voor de gegevensset, maar geen historische gegevens laden en verwerken in een van de partities. Zie Advanced incremental refresh - Prevent timeouts on initial full refresh (Geavanceerde incrementele vernieuwing - Time-outs voorkomen bij initiële volledige vernieuwing) voor meer informatie.

Oorzaak: Time-out van gegevensbronquery

Query's kunnen worden beperkt door een standaard tijdslimiet voor de gegevensbron.

Oplossing: De tijdslimiet in de queryexpressie overschrijven

Veel gegevensbronnen staan het overschrijven van de tijdslimiet in de query-expressie toe. Zie Incrementeel vernieuwen voor gegevenssets - Tijdslimieten voor meer informatie.

Probleem: Vernieuwen mislukt vanwege dubbele waarden

Oorzaak: De datums na de datum zijn gewijzigd

Bij een vernieuwingsbewerking worden alleen gegevens die zijn gewijzigd bij de gegevensbron vernieuwd in de gegevensset. Omdat de gegevens worden gedeeld door een datum, wordt het aanbevolen datums na (transactie) niet te wijzigen.

Als een datum per ongeluk wordt gewijzigd, kunnen er twee problemen optreden: Gebruikers merken dat er totalen zijn gewijzigd in de historische gegevens (die niet mogen plaatsvinden) of dat er tijdens een vernieuwing een fout wordt geretourneerd die aangeeft dat een unieke waarde in feite niet uniek is. Voor het laatste kan dit gebeuren wanneer de tabel waarop incrementeel vernieuwen is geconfigureerd, wordt gebruikt in een 1:N-relatie met een andere tabel als de 1-zijde en unieke waarden moet hebben. Wanneer de gegevens worden gewijzigd (voor een specifieke id), wordt die id vervolgens weergegeven in een andere partitie en detecteert de engine dat de waarde niet uniek is.

Oplossing: Specifieke partities vernieuwen

Als het nodig is om eerdere gegevens uit de datums te wijzigen, is het mogelijk om SSMS te gebruiken om alle partities te vernieuwen vanaf het punt waar de wijziging zich bevindt tot aan de huidige vernieuwingspartitie, waardoor de 1-zijde van de relatie uniek blijft.

Probleem: Gegevens worden afgekapt

Oorzaak: De querylimiet voor de gegevensbron is overschreden

Sommige gegevensbronnen, zoals Azure Data Explorer, Log Analytics en Application Insights hebben een limiet van 64 MB (gecomprimeerd) voor gegevens die kunnen worden geretourneerd voor een externe query. Azure Data Explorer kan een expliciete fout retourneren, maar voor anderen, zoals Log Analytics en Application Insights, worden de geretourneerde gegevens afgekapt.

Oplossing: Geef kleinere vernieuwings- en winkelperioden op

Geef kleinere vernieuwings- en opslagperioden op in het beleid. Als u bijvoorbeeld een vernieuwingsperiode van één jaar hebt opgegeven en er een queryfout wordt geretourneerd of als de geretourneerde gegevens worden afgekapt, probeert u een vernieuwingsperiode van 12 maanden. Zorg ervoor dat query's voor de huidige vernieuwingspartitie of historische partities op basis van de perioden Vernieuwen en Opslaan niet meer dan 64 MB aan gegevens retourneren.

Probleem: Vernieuwen mislukt vanwege partitiesleutelconflicten

Oorzaak: De datum in de datumkolom bij de gegevensbron wordt bijgewerkt

Het filter op de datumkolom wordt gebruikt om de gegevens dynamisch te partitioneren in periodebereiken in Power BI service. Incrementeel vernieuwen is niet bedoeld ter ondersteuning van gevallen waarin de gefilterde datumkolom in het bronsysteem wordt bijgewerkt. Een update wordt beschouwd als een invoeging en een verwijdering en niet als een echte update. Als de verwijdering plaatsvindt in het historische bereik en niet het incrementele bereik, wordt deze niet opgehaald, wat kan leiden tot fouten bij het vernieuwen van gegevens vanwege partitiesleutelconflicten.

Zie ook

Gegevens vernieuwen in Power BI
Geavanceerd incrementeel vernieuwen met het XMLA-eindpunt
Incrementeel vernieuwen voor gegevensstromen