De laatste tijd krijg ik vaak foutmeldingen terug wanneer Power BI de data uit Exact wil verversen. Het probleem zit hem bijna altijd in de ItemsIncremental-tabel (dit is ook veruit de grootste tabel uit de dataset).
Power BI zelf geeft deze foutmelding:
OData:
Unable to read data from the transport connection:
An existing connection was forcibly closed by the remote host.
Het betreft artikelen uit meerdere administraties. Uit analyse van dit specifieke request komt geen specifieke reden. De data wordt vers opgehaald (niet uit de incremental caches) en dit kost circa 1 seconde per 1.000 rijen.
In totaal 300.000 artikelen is voor Invantive Cloud een reguliere omvang. Performanceproblemen die aandacht behoeven beginnen meestal vanaf circa 2 a 3 miljoen rijen in release 24.0 (zie achtergrond in Foutcode itgenboe147 na 5 minuten). Veelal wordt dan overgestapt op ADF. In release 25.0 zal de “pijngrens” naar verwachting verhoogd zijn naar downloads van 5 a 6 miljoen rijen via OData4, en ergens dit jaar komt naar verwachting ook het TDS-protocol beschikbaar (zie Topics met de tag invantive-universalsql-server).
Na 407 seconden verdwijnt de HTTP-client die de data ophaalt volgens de gedetailleerde logging. Deze logging is niet beschikbaar voor gebruikers, maar in het scherm Sessie I/O’s zijn de achterliggende aanroepen van Exact Online terug te vinden en in Systeemberichten de uiteindelijke foutmelding.
Merk op dat PowerBI.com en Power BI Desktop een verschillend gedrag hebben qua betrouwbaarheid. In het algemeen is Power BI Desktop stabieler.
Advies is de download te herhalen.
Het volledig opbouwen van de incrementele cache zal normaliter eens in de zoveel dagen gebeuren. Een volgende download zal sowieso van de delen reeds opgehaald gebruik maken en daardoor veel sneller draaien.
Ik heb het idee dat het vernieuwen nooit echt incrementeel gebeurt, omdat ik in de gebruiksstatistieken in invantive altijd hetzelfde verbruik zie. Kan het zijn dat er bepaalde instellingen in mijn database niet goed staan?
In het scherm Sessie I/O’s is te vinden welke verzoeken veel tijd kosten sinds 0:00 UTC. Op zich is er voor 8 mei niks spannends te zien buiten dat mogelijk dezelfde dataset vaker opgehaald worden. De inhoud van dat scherm is vergelijkbaar met deze query uitvoer:
