Heart-Profit ERP

Heart-Profit Boards => Heart-Profit Releasenotes => Topic started by: Heart Informatisering B.V. on May 01, 2017, 10:32:30 am



Title: ADS - Performance SQL statistieken
Post by: Heart Informatisering B.V. on May 01, 2017, 10:32:30 am
In deze Releasenote zijn er een aantal aanpassingen gedaan inzake de wijze waarmee de ADS versie middels een SQL opdracht de data berekent voor de gefaktureerde Verkoopoverzichten. Hoewel de aanpassingen puur 'theoretisch' zijn is de verwachting dat deze leiden tot een flinke performance verbetering.

Gefaktureerde Verkoopoverzichten die er bij ons in enkele seconden er uit komen rollen, duren bij andere klanten niet werkbaar lang. In een praktijk voorbeeld duurt een selektie op niveau's G (Debiteurrubriek) en F (Debiteur) bij rapportage over (slechts) 1 week, méér dan 45 minuten alvorens ze met antwoord komt. Dit echter, bij een Faktuurtabel die groter is dan 30 GB.

Het ADS SQL commando bepaalt zelf welke SQL indexen ze inzet voor welke Query; vanuit Profit kunnen wij dat niet afdwingen. Wel kunnen we dit door een andere opbouw van de SQL Query 'manipuleren'.

Oplossingen om de performance te verbeteren zijn o.a.:

* Het elimineren van gekombineerde SQL indexen (ADS lijkt beter overweg te kunnen met separate indexen op enkele velden dan met indexen op gekombineerde velden). Minder indexen leidt automatisch tot het iets sneller kunnen reorganiseren van de tabellen.

* Data niet uit LOFR ophalen met een JOIN op LOUF, maar andersom: data uit LOUF (Fakturen) en vervoglens LOFR (Faktuurregels) er bij betrekken. Het vermoeden is dat ADS eerst van alle 30 GB aan records de Faktuurdatum erbij zocht, om vervolgens daar een filter op te leggen met een beperking tot een week. De nieuwe opzet zou dan de Faktuurheaders van 1 week moeten lokaliseren, en daar de regels bij moeten zoeken.

* Indexen op tijdelijke werktabellen; zo zal een Query op Debiteurrubriek (en op een ander veld) eerst een Subquery uitvoeren om te bepalen welke Debiteuren er in de Debiteurenrubriek zitten, om vervolgens een SQL Query op LOUF/LOFR uit te kunnen voeren met een JOIN op het resultaat van de subquery. De resultatentabel van de (tijdelijke) Subquery wordt nu voorzien van een index, opdat dit weer tot een betere performance leidt bij het ophalen van de data uit de Faktuurregels.

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
CLASSES     Geen standaard funktie    10-04-2017    26-04-2017
LOPRVKO1    Omschrijving (nog) niet bekend    11-04-2017    26-04-2017