Vannacht hebben wij een aantal errors gekregen in Azure en PowerBI.
De error die het meest naar voren kwam was de 429 Too Many Requests.
Ik heb net een controle gedaan binnen Invantive. Het blijkt dat we ruim over onze Verse Duur gaan.
In Sessio I/O’s heb ik gekeken waar dit aan ligt en zag ik het volgende:
Wat ik hier vreemd vind is dat de duur 1900 seconden is, terwijl het aantal rijen ‘maar’ 358 is. Enig idee waarom de duur bij de lage hoeveelheid rijen zo lang is?
Er kunnen verschillende redenen zijn waarom de duur zo lang is. Standaard is daarbij overmatige drukte (vanaf 1 januari zal het ongetwijfeld weer heel druk zijn bij Exact en Invantive) of specifiek in het geval van Exact downtijd (Exact is vaak tussen 01:00 en 04:00 kort- maar soms ook langdurig down). We raden aan om automatische downloads niet te starten op een rond tijdstip zoals 0:00 of 3:00, maar bijvoorbeeld 5:13. Dan zijn de servers normaliter vele malen minder druk dan om klokslag 0:00.
In dit geval waarbij er sprake is van een incrementele tabel valt daarnaast te denken aan:
Zitten er echt maar 358 rijen in, of is een filter of where toegepast?
Is de incrementele cache bijgewerkt vanaf scratch doordat de Invantive-engine beoordeelde dat de incrementele data mogelijk niet kloppend waren?
Hou er rekening mee dat een incrementele Exact Online-tabel vrijwel altijd alle rijen moet verwerken om de situatie te actualiseren, ook al laat een filter daarna maar enkele rijen door.
Advies is om niet alleen te kijken naar de BridgeOnlineOdata4 sessie I/O, maar ook naar de ExactOnline sessie I/O’s die gedurende deze periode opgetreden zijn en systeemberichten die een hint geven dat er herhaaldelijk geprobeerd is gedurende de downtijd van Exact contact op te nemen. Afhankelijk van de instellingen worden de pogingen over een langere tijd gespreid en kan een verzoek rustig 30 minuten duren als Exact zolang down is.
Merk op dat Verse Duur als het goed is momenteel 5x zoveel hoog mag zijn als volgens de Fair Use-regels. Dit in afwachting van de 24.0-release die een verbeterde meetmethode voor duur zal gaan aanbieden, evenals SQL execution profiling.
Er zitten meer rijen in, maar met een OData query worden middels een filter de nieuwste rijen opgehaald. Het aantal verschilt per nacht, omdat wordt gekeken naar de laatste timestamp in onze database, deze wordt als input gebruikt voor de OData query.
De tweede vraag die jullie stellen snap ik niet helemaal. Hoe is dit te controleren?
Voor incrementele tabellen is ook het totale aantal rijen van belang.
Wat is het totale aantal?
Met tweede vraag wordt mogelijk dit bedoeld:
Is de incrementele cache bijgewerkt vanaf scratch doordat de Invantive-engine beoordeelde dat de incrementele data mogelijk niet kloppend waren?
Dit is te zien door in het scherm naar de sessie I/O’s te kijken van het request. Zijn het er 2 of enkele per administratie? Dan is de cache niet vanaf scratch opgebouwd. Zijn het er pakweg 1 per 1.000 rijen in totaal in de tabel (zonder filtering), dan is de cache vanaf scratch opnieuw opgebouwd.
Het opnieuw opbouwen is ook te zien in de Exact Online datadictionary tabellen zoals beschreven in:
voor tabellen zoals IncrementalLoadEventLogEntries.
Het vreemde aan de situatie is eigenlijk ook dat we vóór vannacht geen errors kregen op basis van duur en/of limieten omdat we onze query’s hebben geüpdatet/geoptimaliseerd.
Wij hebben namelijk weinig tot geen wijzigingen gedaan in de tabellen die ontsloten worden.
Is hier een andere verklaring mogelijk? (Exact Online / Invantive / etc.?)
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.
