Handmatig refresh via planning in Power BI werkt niet: oorzaken en oplossingen

Als een handmatige refresh wel lukt en een geplande refresh niet, ligt het probleem niet bij de gegevensbron of het gegevensmodel. Die werken – dat heb je net aangetoond door een handmatige refresh uit te voeren. Het probleem zit hem in het verschil tussen de uitvoering van handmatige en geplande refreshen.

Een handmatige refresh wordt interactief uitgevoerd onder jouw identiteit of met inloggegevens die je expliciet opgeeft op het moment van de refresh. Een geplande refresh wordt onbeheerd uitgevoerd, op een geconfigureerd tijdstip, met behulp van opgeslagen inloggegevens en een gateway die online moet zijn, zonder menselijke tussenkomst. Elke oorzaak van het verschil tussen geplande en handmatige refreshen ligt in een van die drie verschillen: de opgeslagen inloggegevens, de gateway of de timing.

Deze asymmetrie is diagnostisch. Het sluit meteen een grote groep mogelijke oorzaken uit en wijst je op de drie gebieden die daadwerkelijk verschillen tussen de twee uitvoeringsmodi. Als je het onderzoek ergens anders begint, werk je tegen het bewijs in.

De meest genoemde oorzaak voor het mislukken van een geplande refresh terwijl een handmatige refresh wel werkt, is de offline status van de gateway. De on-premise data gateway-service (PBIEgwService) is gestopt tussen het moment van de laatste succesvolle handmatige refresh en het volgende geplande refreshvenster.

Dit gebeurt omdat handmatige refreshen het probleem vaak omzeilen zonder dat de technicus het doorheeft. De technicus voert de refresh handmatig uit, de gateway start op (omdat de gateway-applicatie is geopend of de service automatisch is hersteld) en de handmatige refresh slaagt. De volgende nacht, wanneer de geplande refresh onbeheerd wordt uitgevoerd, is de service opnieuw gestopt.

Controleer de gatewaystatus in Power BI Service: ga naar Instellingen > Gateways beheren. Als de gateway offline wordt weergegeven, is de service op de gatewaymachine gestopt. Maak verbinding met de gatewaymachine en controleer de servicestatus:

Get-Service -Name "PBIEgwService"

Als de service is gestopt, start deze dan en stel het opstarttype direct in op Automatisch met herstel geconfigureerd:

Restart-Service -Name "PBIEgwService" sc.exe failure PBIEgwService reset= 86400 actions= restart/5000/restart/10000/restart/20000

De service start dan automatisch opnieuw na een crash, in plaats van gestopt te blijven totdat iemand het merkt.

Geplande refresh maakt gebruik van de referenties die in Power BI Service zijn opgeslagen tijdens de configuratie van de dataset. Deze opgeslagen referenties worden niet automatisch bijgewerkt wanneer een gebruiker zijn wachtwoord in Active Directory wijzigt of wanneer de referenties van een serviceaccount worden geroteerd.

Wanneer referenties verlopen, werkt handmatige refresh nog steeds, omdat de engineer wordt gevraagd de referenties interactief opnieuw in te voeren. Geplande refresh geeft geen interactieve prompt voor referenties; deze gebruikt de opgeslagen waarde, die nu ongeldig is, en mislukt.

De oplossing is om de opgeslagen referenties in Power BI Service bij te werken: Datasetinstellingen > Referenties van gegevensbron > Referenties bewerken > voer het huidige wachtwoord in. Dit moet elke keer worden gedaan wanneer het wachtwoord van het account wordt gewijzigd.

De duurzame oplossing is om over te stappen op service accounts met referenties die niet verlopen of op OAuth-gebaseerde referenties die hun tokens automatisch refresh. Organisaties met een wachtwoordrotatiebeleid van 90 dagen die vergeten de Power BI referenties bij te werken, krijgen voorspelbaar elke drie maanden gatewayfouten.

De geplande refresh wordt uitgevoerd op een tijdstip dat is geconfigureerd in Power BI Service — in UTC. Als de ETL-taak die de upstream-gegevensbron laadt, op een overlappend tijdstip wordt uitgevoerd, kan de geplande refresh worden uitgevoerd op een gedeeltelijk geladen dataset. Een tabel met dubbele waarden in een sleutelkolom tijdens een ETL-schrijfbewerking kan een relatiefout veroorzaken in het importmodel van Power BI, waardoor de refresh mislukt.

Deze foutmodus is intermitterend en bijzonder moeilijk te debuggen, omdat deze afhangt van het exacte moment waarop de geplande refresh de ETL overlapt. Een handmatige refresh overdag — wanneer de ETL is voltooid en de gegevens schoon zijn — slaagt. De geplande nachtelijke refresh, die om 02:00 UTC wordt uitgevoerd tijdens het ETL-venster, mislukt.

De oplossing is om de geplande refreshtijd zo in te stellen dat deze begint nadat het ETL-venster is voltooid, met een buffer. Als de ETL betrouwbaar vóór 01:45 UTC is voltooid, plan de Power BI refresh dan in voor 02:15 UTC. Dit elimineert de raceconditie.

Controleer ook de refreshgeschiedenis van Power BI voor de specifieke foutcode. Een relatiefout veroorzaakt door dubbele sleutels ziet er anders uit dan een gatewayfout: het foutbericht verwijst naar de relatie en de betrokken kolommen.

Power BI Service kan Power Query-code die dynamisch een verbindingsreeks construeert tijdens het uitvoeren van een query, niet evalueren. Dit houdt bijvoorbeeld in dat een URL wordt opgebouwd uit een parameter of dat een server naam wordt samengevoegd uit een tabelwaarde. Dit type dynamische bron werkt wel in Power BI Desktop (waar query's lokaal worden uitgevoerd), maar mislukt bij een geplande refresh in Power BI Service, waarvoor statische verbindingsreeksen vereist zijn.

De foutmelding verwijst naar privacyinstellingen of vermeldt dat de gegevensbron niet kan worden geëvalueerd. Deze foutmelding verschijnt alleen bij een geplande refresh, niet bij een handmatige refresh vanuit de desktop.

De oplossing is om de Power Query aan te passen zodat de basis-URL of server naam statisch is en alleen het pad of de parameters variëren. De functie Web.Contents ondersteunt een optie RelativePath waarmee statische basis-URL's met dynamische padcomponenten mogelijk zijn:

let

BaseUrl = "https://api.example.com",

Source = Json.Document(Web.Contents(BaseUrl, [RelativePath = "/data/" & MyParameter])) in

Source

De basis-URL moet een letterlijke tekenreeks zijn die Power BI Service kan interpreteren als een vast endpoint. Het relatieve pad kan dynamisch zijn. Dit patroon voldoet aan de vereisten van Power BI Service en behoudt tegelijkertijd de parameterisering die nodig is in de query.

De persoonlijke Power BI gateway is ontworpen voor individueel gebruik: deze draait op de eigen computer van de gebruiker, vereist dat de gebruiker is aangemeld en is niet bedoeld voor gedeelde of onbeheerde geplande refreshen. Het gebruik van een persoonlijke gateway voor geplande refreshen in een productieomgeving is een veelvoorkomende en betrouwbare oorzaak van het probleem dat ontstaat bij geplande versus handmatige refreshen.

Het falingsmechanisme: de persoonlijke gateway vereist een actieve gebruikerssessie op de computer waarop deze is geïnstalleerd. Wanneer de computer in de slaapstand gaat, de gebruiker zich afmeldt of het scherm vergrendelt, stopt de gateway met het verwerken van geplande refreshstaken. De gebruiker wekt de computer vervolgens weer, opent de sessie, voert een handmatige refresh uit en deze werkt – omdat de gateway nu actief is.

Gebruik voor elke dataset die betrouwbare geplande refresh vereist de standaard on-premise data gateway (niet de persoonlijke modus). Installeer deze op een dedicated server of VM die altijd aan staat, nooit in de slaapstand gaat en waarvan de gatewayservice is geconfigureerd om automatisch te starten. De persoonlijke gateway is uitdrukkelijk niet ontworpen voor productiegebruik.

Power BI Service plant refreshen in UTC. De tijd die in de gebruikersinterface wordt weergegeven, kan afhankelijk van de browser- en accountinstellingen in een lokale tijdzone worden weergegeven, maar de onderliggende planning is UTC. Technici die een refresh instellen voor "08:00" in de verwachting dat deze om 08:00 lokale tijd wordt uitgevoerd, kunnen merken dat de refresh om 08:00 UTC wordt uitgevoerd. Dit kan, afhankelijk van de tijdzone, enkele uren afwijken.

Dit zorgt er niet voor dat de geplande refresh mislukt, maar wel dat deze op het verkeerde moment wordt uitgevoerd. Dit kan ertoe leiden dat de refresh plaatsvindt tijdens een ETL-venster dat juist vermeden had moeten worden, of dat de SLA-termijn met enkele uren wordt overschreden.

Controleer de geconfigureerde refreshtijd door de gegevenssetinstellingen in Power BI Service te bekijken en te bevestigen of de weergegeven tijd overeenkomt met UTC of lokale tijd. Pas de planning aan om rekening te houden met het UTC-verschil voor de beoogde lokale uitvoeringstijd.

MetricSign bewaakt Power BI datasets via de REST API en genereert 'refresh_failed'-incidenten wanneer een geplande refresh mislukt, en 'refresh_delayed'-incidenten wanneer een verwachte refresh niet binnen een instelbaar tijdsvenster na de geplande tijd is gestart.

Het 'refresh_delayed'-signaal is met name relevant voor het geval de gateway offline is. Wanneer de gateway offline is, mislukt de geplande refresh niet alleen, maar start deze vaak helemaal niet. Power BI plaatst de refresh taak in de wachtrij, maar kan deze niet naar de offline gateway verzenden. De refresh wordt weergegeven als 'in behandeling' of start nooit, in plaats van te mislukken met een foutcode.

Een 'refresh_delayed'-waarschuwing betekent dat het probleem zichtbaar is voordat gebruikers verouderde dashboards melden, zelfs in gevallen waarin de foutmodus geen foutcode genereert waarop een waarschuwing kan worden gebaseerd.