Bij het ophalen van de tabel ExactOnlineREST.Incremental.TimeCostTransactionsIncremental@eol worden alle divisies van het account waarmee de datacontainer is aangemaakt opgehaald. Hoewel er in de M-Query een expliciet filter op één divisiecode is ingesteld, blijft het probleem zich voordoen. Dit trad eerst op bij een klant en is daarna in een nieuw Power BI-bestand gereproduceerd, waar de issue zich opnieuw voordeed. In de onderstaande afbeelding van de sessions I/O is te zien dat er bij de partitions alsnog meerdere divisiecodes worden aangeroepen.
Ik heb in de Start-up SQL code nu hard de divisiecode gefilterd maar het probleem blijft.
Merk op dat query folding door Power BI noodzakelijk is om de filters te ontvangen binnen Invantive Cloud. U kunt de werking controleren door in Bridge Online Monitoring te kijken wat er gevraagd wordt door het request.
Is het mogelijk het gebruikte statement van de startup SQL toe te voegen?
Merk op dat een wijziging van de startup SQL geen invloed heeft op de waardes in caches. Indien de geselecteerde administraties gewijzigd zijn, dan zal nog steeds data geserveerd worden uit caches met de oude instellingen totdat de caches verlopen zijn.
Is het mogelijk om een (geanonimiseerde) schermafdruk van de details van het verzoek in Invantive Bridge Online Monitoring toe te voegen zoals beschreven in Meer inzicht met nieuwe Bridge Online Monitoring?
De details vindt u door te klikken op het downloadverzoek welke het onderwerp van dit onderwerp representeert.
Gelieve tenminste de volgende gegevens zichtbaar te laten:
- de titelbalk met de request ID,
- de statuscode, netwerkgrootte en tijdstippen in de linkerkolom,
- de foutcode en foutmelding helemaal onderaan in de linkerkolom,
- de gehele rechterkolom inclusief het SQL statement, tabelnaam en parameterwaardes.
Controleer zorgvuldig dat u zich aanmeldt op de Bridge Online-website die ook gebruikt wordt vanuit Power BI. U ziet alleen de verzoeken van de gebruiker waarmee u zich aanmeldt op de website.
De Bridge Online Monitoring:
met SQL:
select ...
from ExactOnlineREST.Incremental.TimeCostTransactionsIncremental@eol t
where Division = :w1
De start-up SQL:
Ik heb de cache gereset maar dit heeft het ook niet opgelost.
Dit probleem is niet reproduceerbaar gebleken zoals blijkt uit volgende SQL:
use 102673@eol
select division
, count(*)
from ExactOnlineREST.Incremental.TimeCostTransactionsIncremental@eol t
where Division = 102673
group
by division
select url
from sessionios@datadictionary
where data_container_alias not in ('CloudData')
and id > 6 /* Post login. */
order
by id desc
met als resultaat dat enkel divisiecode 102673 uit de ruim 200 beschikbare divisies is benaderd:
Het bovengetoonde request ID uit Bridge Online Monitoring is geanalyseerd en hier is blijkbaar weinig tot niks in gebeurd qua sessie I/O’s:
Indien er meerdere sessie-I/O’s zijn over meerdere divisies, dan zou deze registratie er als volgt uit hebben moeten zien:
Advies is om de verwerking zorgvuldig te controleren.
Mocht het verder niet-gedefinieerde probleem blijven optreden, dan is het advies om:
- een geisoleerd reproductiescenario zoals hierboven beschreven toe te voegen
- het probleem eenduidig te beschrijven (“het probleem” uit de initiele vraag is niet goed herleidbaar wat bedoeld wordt).
Deze vraag is automatisch gesloten na 1 week inactiviteit. Het laatste gegeven antwoord is gemarkeerd als oplossing.
Gelieve een nieuwe vraag te stellen via een apart topic als het probleem opnieuw optreedt. Gelieve in de nieuwe vraag een link naar dit topic op te nemen door de URL er van in de tekst te plakken.
Dit topic is 3 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.