Dc_event_log en dc_incoming_messages verkleinen

Wij slaan in diverse repositories gigantisch hoeveelheden in de tabellen dc_event_log en dc_incoming_messages op.

Zo te zien wordt de dc_incoming_messages tabel niet leeggegooid, hiervan staan alle webhook messages sinds het aanmaken van deze database (64 GB messages voor één respository).

De dc_event_log wordt denk ik 35 dagen bewaard (alle eventlogs gaan terug tot 21 december). Ook dit resulteert in datavolumes tot 19GB voor één respository.

Vragen:

  • Is er binnen Data Hub een manier om deze beide logtabellen maar bijvoorbeeld een week op te slaan en alles ouder automatisch te verwijderen?
  • Zo nee, is er een risico om via SQL Server zelf alle oude regels te verwijderen of de tabel leeg te gooien?

De bewaarperiode van dc_event_log (of nauwkeuriger gezegd: PREFIX + event_log) staat standaard op 35 dagen. Vanaf 35 dagen na het aanmaken kunnen de rijen automatisch verwijderd worden. Dit gebeurt niet meteen en kan rustig een dag extra duren.

dc_event_log opschonen

In dc_event_log staan de logging op Data Replicator niveau. Deze logging is complementair op de trace logs en het afdrukken van meldingen op het scherm, en zit qua details tussen beiden in.

De volgende instelopties van de Data Replicator driver beinvloeden het opschonen van dc_event_log (documentatie):

  • retention-event-log-entries-days: Retention of event log entries in days (standaard 35).
  • purge-interval-event-log-entries-minutes: Interval in minutes between completed purges of ancient event log entries (standaard 60).
  • event-log-entries-delete-page-size-rows: Number of rows to delete per batch on maintaining event log entries (standaard 1000).

Als er een grote achterstand is, dan wordt het opschonen uitgesmeerd over een langere periode om te voorkomen dat andere processen hierdoor stokken.

dc_incoming_messages opschonen

In dc_incoming_messages staan de te verwerken mutatieberichten voor trickle loading. Op bijvoorbeeld Exact Online zijn dat de webhookberichten.

De bewaarperiode is standaard 8 dagen (1 week + 1 dag speling) gemeten vanaf het toepassen van de mutatieberichten. Niet-gebruikte mutatieberichten worden niet weggehaald. In de database geeft de kolom forwarded_flag (tabel) of ime_forwarded_flag (view) aan of een rij verwerkt is.

Het verwijderen van de mutatieberichten gebeurt op tabelpartitieniveau direct na het verversen van een tabelpartitie. Ook de registratie dat een rij verwerkt is gebeurt dan.

De standaardbewaarperiode is terug te vinden in dc_settings (of nauwkeuriger gezegd: PREFIX + settings) als sec_retention_fwd_ime. De waarde mag niet rechtstreeks in de tabellen aangepast worden, zoals geldt voor de inhoud van alle tabellen die door Data Replicator gebruikt wordt. Het DDL statement is (zie ook de SQL grammatica):

alter persistent cache set retention forwarded incoming messages 86400

Handmatig opschonen

Het handmatig opschonen van deze tabellen wordt niet ondersteund. Via Professional Services kan een consultant erbij betrokken worden om eventuele grote achterstanden uit te zoeken en gezamenlijk op te lossen.