Ophalen TransactionLinesIncremental duurt veel langer dan TransactionLinesBulk

Op dit moment gebruik ik:

create or replace table transactionlinesincremental@sqlserver
as
select  *
from   transactionlinesincremental@eol

Deze query blijft “alle data” ophalen vanuit Exact online. En waar TransactionlinesBulk er 22 minuten over doet, duurt deze 3.5 uur.

Enig idee hoe ik het “incrementele” van de incremental versies op de juiste manier kan inzetten?

Een paar controles die je zou kunnen uitvoeren staan hieronder.

Omvang

Een paar regels om de omvang vast te stellen:

  • Hoeveel administratie(s) gaat het om?
  • Hoeveel regels zitten er in de administratie(s)?
  • Hoeveel werkgeheugen heeft het verwerkende apparaat?

SQL Server als oorzaak uitsluiten

Hoe lang duurt deze query:

create or replace table transactionlinesincremental@InMemoryStorage
as
select  *
from   transactionlinesincremental@eol

Is die sneller klaar? Alhoewel de andere laadactie ik vermoed ook richting SQL Server gaat, is het handig om SQL Server (batchladen of niet) uit te sluiten. De in-memory storage driver is in principe meteen klaar.

Werkgeheugen uitsluiten

Hoeveel geheugen heeft het apparaat dat je gebruikt?

Een statement op de sync API’s zoals

create or replace table transactionlinesincremental@sqlserver
as
select  *
from   transactionlinesincremental@eol

zal eerst alle gegevens moeten ontsleutelen en decomprimeren, daarna de mutaties verwerken, daarna de nieuwe situatie versleuteld vastleggen en pas daarna beginnen met resultaten terug te geven, die dan vrijwel meteen weggeschreven worden.

In tegenstelling daartoe zal een statement op TransactionLinesBulk:

create or replace table transactionlinesincremental@sqlserver
as
select  *
from   transactionlinesbulk@eol

meteen beginnen met lezen uit de Exact Online API’s en elke paar seconden al (bijvoorbeeld) een 3.000 records wegschrijven in SQL Server.

Het maximale geheugenbeslag van het kopieren van TransactionLinesBulk is een paar MB door dit streaming gedrag, terwijl het maximale geheugenbeslag van TransactionLinesIncremental rustig een paar KB per regel kan zijn door het batchmatige gedrag.

Een miljoen regels van TransactionLinesIncremental vragen dan al de nodige gigabytes. Het exacte geheugenbeslag is moeilijk te bepalen zonder de query te draaien; Invantive SQL ontdubbelt bijvoorbeeld vaak terugkomende teksten om het geheugengebruik te beperken.

Zodra het geheugengebruik te groot wordt, zal paging/swapping optreden en mogelijk “trashing” wat de looptijd enorm kan verlengen.

Processor

Er zijn in principe tussen de twee varianten geen grote verschillen in rekentijd. Het versleutelen en ontsleutelen zal de benodigde rekentijd misschien verdrievoudigen, maar ik zie dat niet tot uren extra rekentijd leiden. De versleuteling is redelijk efficient; vergelijkbaar met een VPN-tunnel.

Deze vraag is automatisch gesloten na tenminste 2 weken inactiviteit nadat een mogelijk passend antwoord is gegeven. 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.