Ophalen bankaccounts uit Exact Online duurt veel te lang

Het ophalen van data met het volgende statement duurt veel te lang:

select count(*) from ExactOnlineREST..BankAccounts

De download is v.w.b. de bankaccounts volgens de logging gestart op 2021-10-27 17:28:12.645, dit issue is ingediend op 2021-10-28 12:20.

Op het moment van indienen van dit topic draait het proces nog steeds.

Hierbij vermeld te worden dient wel dat de download de 3e query is die gestart is i.v.m. het downloaden van diverse tabellen uit Exact Online. De downloads worden allen per administratie gedaan.

Daarnaast is in de tracefile te zien dat er wel veel gebeurt.
Ook de mdf-file van de database groeit flink.

Om hoeveel relaties of rijen en administraties gaat het?

Dit is terug te vinden in bijvoorbeeld de view dc_table_partition_versions_r in de achterliggende database. Zoek hierbij naar de tabelnaam.

Op een andere omgeving meten we op dit moment 66 seconden voor 3.000 BankAccount-rijen. Echter, ook hier zijn we zoals vaker deze week enorme uitschieters qua API-responsetijden:

In dit geval zorgt 1 van de 50 calls voor bijna de volledige query looptijd.

Waarschijnlijk is dat ook het geval bij jullie. We zien regelmatig responsetijden boven de minuut voor het ophalen van maar 60 rijen op alle API’s.

Advies is om de replicatie af te breken en volgende week nogmaals te proberen. In de tussentijd kan overwogen een storing te melden bij Exact Online Support op de API-responsetijden.

Ik heb de 1e administratie bekeken en tref in de Invantive-database in de view eol_bankaccounts_r 68 rijen van dezelfde bankrekening aan. In de kolom dc$sourcing_date is te zien dat deze rijen allen op dezelfde dag omstreeks hetzelfde tijdstip actief zijn geworden.

De query select count(*) from ExactOnlineREST..BankAccounts dient voor 23 administraties uitgevoerd te worden.

Het proces heb ik afgebroken toen het proces bezig was met de 5e administratie. De download voor 1e administratie van de tabel BankAccounts was gestart om:

2021-10-27 17:28:12.649 Information itgendhb044: Run SQL statement: select count(*) from ExactOnlineREST..BankAccounts

De logging laat de volgende tijd zien op bij de opdracht die uitgevoerd werd op het moment dat ik het proces stopte:

2021-10-27 18:27:11.287 Information itgendhb044: Run SQL statement: select count(*) from ExactOnlineREST..BankAccounts

In onze SAFE-database kan ik zien dat het om totaal bij deze 1e 5 administraties gaat om in totaal 5478 rijen.

Om support van Exact te voeden: Welke tekst kan ik hen het beste melden?

Op dit moment horen we van veel gebruikers dat de responsetijden op de Exact Online API’s enorm variëren. Advies is om het volgende week nogmaals te proberen.

Zojuist opnieuw voor de 1 administratie onderstaande opdracht uitgevoerd:
select count(*) from ExactOnlineREST..BankAccounts
resultaat nadat dit 1 uur en 20 minuten gelopen had was dat er nu 68 rijen van 1 relatie bij deze administratie via de view [eol_bankaccounts_r] actief waren.
Ook deze nieuwe poging deze week had dus geen effect.

Welke melding kan ik het beste doen bij support van Exact Online?

De volgende query laat zien dat er soms een ongeloofwaardige verhouding is tussen het aantal bankrekeningen en relaties na het laden met Invantive Data Hub 20.2.54:

select bat.ptn_name
,      bat.tbe_full_qualified_name
,      bat.tpn_version
,      bat.tpn_state
,      bat.tpn_count_rows
,      bat.tpn_count_rows_previous
,      bat.tpn_count_rows_delta
,      act.tpn_count_rows
       number_of_accounts
,      case 
       when act.tpn_count_rows = 0 
	   then null
	   else cast(round(bat.tpn_count_rows / act.tpn_count_rows, 1) as numeric(5, 1))
	   end 
	   ratio
from   dc_table_partition_versions_r bat
left
outer
join   dc_table_partition_versions_r act
on     act.tbe_full_qualified_name like '%.AccountsIncremental'
and    act.tpn_state = 'R'
and    act.ptn_name = bat.ptn_name
where  bat.tbe_full_qualified_name like '%BankAccounts'
and    bat.tpn_state not in ('S', 'I', 'D')
order 
by     ratio desc

De verhoudingen zijn extreem voor bijvoorbeeld partitie 1908302:

De volgende query geeft op dit moment 297 rijen terug:

select /*+ ods(false) */ count(*) 
from   accountsincremental

De volgende query geeft op dit moment 281 rijen terug:

select /*+ ods(false) */ * 
from   bankaccounts

Dit is een realistisch aantal.

Echter, de replica bevat voor bijvoorbeeld account E07C4E26-15D7-4F99-84ED-C14713FA1A29 meer dan hoogstens een paar rijen, namelijk 124:

select *
into testcopy
from eol_bankaccounts_r
where division=1908302
and account = 'E07C4E26-15D7-4F99-84ED-C14713FA1A29'

Vreemd genoeg zitten gegevens van in meerdere divisies:

select division
,      dc$partition
,      count(*)
from   testcopy
group 
by     division, dc$partition
order 
by     1
,      2

met als resultaat:

Aantal voorkomens per administratie

Analyseren we de 30 rijen in de juiste divisie en partitie met

select id
,      modified
,      dc$date_modified
,      dc$transaction_modified
from   testcopy
where  division = dc$partition
order
by     1
,      2
,      3

Hierbij blijkt dat dezelfde bankrekening 30x voorkomt, maar wel telkens met een andere laadmoment in de database vanuit een andere transactie:

De volgende query laat zien dat dit niet eens de meest extreme uitschieter is, de partitie 1810417 laadt ruim 137 miljoen bankrekeningen:

select top 1000 *
from   dc_event_log_r
where  tbe_full_qualified_name like '%BankAccounts'
order 
by     elg_id desc

Enorm aantal bankrekeningen

Vandaag heb ik de nieuwe releases opgehaald en geïnstalleerd voor Data Hub en de Query Tool, nl. 20.2.86.
Vervolgens vanuit de querytool de download van de bankaccounts weer aan gezet voor 1 administratie. Hieronder een screenshot van een tussenstand. Zodra de query afgerond is, meld ik dit ook nog even.

nog even een update:
Wat daarbij op valt is dat de tracefile niet meer opgeknipt wordt in stukken van maximaal 10 Mb, maar ondertussen al gegroeid is tot 90 Mb

Daarnaast zitten we al op de 24 miljoen aan gedownloade rijen:

zojuist het downloaden afgebroken er waren ondertussen 32,5 miljoen rijen gedownload

De tracefile is te groot (bijna 100 Mb) om mee te sturen

Graag een statusupdate.
Als ik iets kan aanleveren aan Invantive of iets moet melden bij support van Exact Online dan verneem ik dit graag.

Op dit moment is er geen voortgang gepland op dit punt. De problemen met de Exact Online refresh tokens krijgen voorrang gezien de impact.

We zijn ondertussen ruim een maand verder.
Is er al een voortgang in deze zaak?

Er is op dit moment geen voortgang gepland op het punt. Het lukt niet om het punt te reproduceren of analyseerbaar te maken.

Advies is:

  • Het probleem via zo weinig mogelijk SQL-statements (liefst 1 of 2) reproduceerbaar te maken op de eigen omgeving, dus zonder batchfiles en andere SQL-statements.
  • Daarna een consult te plannen om gezamenlijk deze statements uit te voeren op een Invantive-omgeving met de eigen credentials.
  • Indien het een bug betreft in de Invantive software zelf dan worden de uren niet in rekening gebracht.