We laden via Data Replicator tabellen van een 10-tal administraties in SQL Server. Dit duurt schijnbaar meerdere uren.
Hoe kan dat versneld worden?
Wij doen dit ook voor tientallen administraties en kan soms lang duren inderdaad. Er is een mogelijkheid om gebruik te maken van trickle loading wat dit proces wat kan versnellen. Er is online wat documentatie te vinden maar wellicht kan @forums dit delen?
Wij moeten dit proces ook versnellen en verbeteren en wellicht kunnen we hier van elkaars kennis gebruik maken om trickle loading zo snel mogelijk werkbaar te krijgen.
Korte klap
Heb je nog weinig ervaring met trickle loading, spaar je zelf al deze tekst en lees dit topic.
Trickle loading op Exact Online
Het versnellen van het laden van Exact Onlie tabellen in een SQL Server database kan inderdaad onder andere met trickle loading. Trickle loading is een zogenaamde replication approach. De andere twee zijn “copy” en “smart sampling”.
Met trickle loading verwerk je de mutaties die (voor Exact Online) binnenkomen in de vorm van webhooks door die te combineren met de laatste volledige replica tot een nieuwe volledige replica.
Waarschuwingen vooraf
Trickle loading/webhooks op Exact Online voldoet niet aan alle eisen die vanuit bijvoorbeeld een ITIL-georganiseerde IT-organisatie gesteld worden. Soms verdwijnen berichten zonder dat dat te achterhalen is. Je bent dus niet aantoonbaar in control. Vaak wordt trickle loading met Exact Online webhooks daarom gecombineerd met een volledige kopie eens in de zoveel tijd. Zo’n volledige kopie kun je tussentijds aftrappen met alter persistent cache force refresh approach copy. De normale alter persistent cache refresh blijft dan werken met trickle loading. Exact is bekend met deze issues en mogelijkerwijs worden in 2021 verbeteringen doorgevoerd qua ITIL-tauglichkeit.
Ook moet je in de gaten houden dat specifiek op Exact Online webhooks alleen verstuurd worden bij wijzigingen in de primaire tabel van een API. Als je bijvoorbeeld de omschrijving van een dagboek aanpast, dan worden er geen webhooks gestuurd voor elke boeking op dit dagboek. De makkelijkste oplossing hiervoor is om je rapportages netjes te normaliseren: gebruik bijvoorbeeld niet de dagboekomschrijving uit de boekstukregels, maar haal die op uit je replica van ExactOnlineREST..Journals. Gebruik je toch de dagboekomschrijving uit de boekstukregels in combinatie met trickle loading, dan kun je in je rapportages verschillende omschrijvingen zien staan bij het dagboek.
Wat wel gaaf is (en soms tricky), is dat op Exact Online de webhooks ook afgaan als je een backup terug laat zetten (dat kan niet meer handmatig). Bij een oude backup ontvang je dan soms honderdduizenden mutaties om de situatie ook in je replica terug te draaien. Over “webhook storms” staat het nodige beschreven in het topic voor OEM.
Activeerstatements
In de SQL grammatica is er meer over te lezen bij alter persistent cache, maar voor vrijwel alle setups zijn instructies ook hier te vinden. Er is wel onderscheid tussen gebruik binnen een OEM-omgeving, grotere accountants (1.000+ administraties) en kleine ondernemersomgevingen met hoogstens 100 administraties. Ook is dat verschil niet helemaal zwart/wit; sommige accountants bieden ook weer via een dochter Invantive software als OEM aan met eigen merknaam.
Het grootste verschil betreft het aantal verschillende omgevingen die je in de lucht moet houden. De makkelijkste manier om dat te bepalen is het tellen van het aantal SQL Server databases dat je hebt met telkens een andere repository van Invantive Data Replicator. De repositorytabellen herken je aan de tabelnaam; ze beginnen normaliter met dc_ zoals bijvoorbeeld dc_settings.
Heb je meer dan zeg 5 SQL Server databases met een repository, dan is de OEM-aanpak te overwegen. Die is complexer om op te zetten, maar groeit ook door naar 100 losse databases/klanten. Anders zou ik de reguliere aanpak voor trickle loading overwegen.
Snelheid
Trickle loading is voor een klein aantal API’s op Exct Online beschikbaar. Dit zijn echter vaak de tabellen met de grootste performance-issues, dus dat komt goed uit. Het samenstellen van een nieuwe versie met de complete set van gegevens uit een tabel en partitie wordt meestal teruggebracht van soms dagen voor grote administraties naar enkele seconden tot enkele minuten. De snelheid van de SQL Server databaseserver heeft maar beperkt invloed op de doorlooptijd van deze fase.
De snelheid van het wegschrijven van de nieuwe versie verbetert niet door het gebruik van trickle loading. Hier blijft de snelheid van de SQL Server databaseserver de bottleneck. Van 10 miljoen boekingen uit een enkele administratie maak je dus veel vlotter een nieuwe versie, maar het wegschrijven van pakweg 10 GB in de replica database aan data blijft net zo lang duren.