Heart-Profit ERP

Waar we ADS kunnen inzetten om tabellen te benaderen die groter zijn dan 2 GB, denken wij al meteen een stap verder.

---

Reorganiseren specifieke index / Edit: Vervallen, zie topic hieronder.

---

Als we normaliter de tabel Verkooporderegels (LOVR) reorganiseren, dan voeren we een PACK uit (verwijderen van de als deleted gemarkeerde regels) en bouwen we daarna alle indexen opnieuw op. In een praktijksituatie in ADS heeft dit bij een tabel van ongeveer 7 GB geleidt tot het opbouwen van ongeveer 2 minuten per index. Met 15 indexen zijn we dan alsnog 30 minuten bezig + een initiële 10 minuten voor het uitvoeren van de PACK.

Met als uitgangspunt dat het PACK-en vnl. bedoeld was om diskruimte vrij te maken, en, met als uitgangspunt dat die ruimte ons i.g.v. ADS niet echt meer intereseeert, is het reorganiseren van een ADS tabel zodanig aangepast dat we standaard geen PACK meer uitvoeren (maar optioneel dit nog wel kunnen aangeven). Dit scheelt alvast een stuk op de totale tijd.

Maar... ervanuitgaande dat we iedere index in een separate indexfile wegschrijven, zijn we nu in staat om op te kunnen geven dat we één specifieke index willen reorganiseren.

(http://www.heartprofit.com/www/transfer/graphics/ads/lobhoi120323001.png)

Stel dus dat de tabel er een 16e index bij krijgt, dan hebben we index 1 t/m 15 al. Waarom zouden we die nogmaals moeten reorganiseren? Kortom, door alleen de 16 (nieuw erbij gekomen index) te reorganiseren, hebben we aan 2 minuten voor die index voldoende. Resultaat: 2 minuten versus 40 minuten daarvoor.

Nb: Bij de Funktie Reorganiseren Bestanden is deze funktionaliteit al aktief. In een volgende stap zou dit automatisch moeten worden bepaald tijdens de Upgrade, immers, dat is veelal de plek waar de extra erbij gekomen index gekonstateerd wordt.

---

Verdelen Database over meerdere ADS Servers / Edit: Vervallen, zie topic hieronder.

---

In http://ha1.heartprofit.nl/profit/index.php?topic=24183.0 staat beschreven dat we met ADSDDPATH en ADSDDINDEXPATH kunnen aangeven met welke Data Dictionary er geconnect moet worden. Maar... in werkelijkheid mogen we deze regels meer dan één keer opnemen.

Kijk maar eens naar (http://www.heartprofit.com/www/transfer/graphics/ads/nconfig120323001.PNG) in deze afbeelding komt het setje 2x voor.  Een set verwijst naar \\192.168.100.192\ terwijl de andere set naar \\192.168.100.195\ verwijst.

Met het meerdere malen opnemen van deze 2 commando's, kunnen we de ADS Database binnen Profit verdelen over meerdere Advantage Database Servers  :smile:

Profit voor ADS ondersteunt daarmee de aansturing van meerdere ADS Servers tegelijk ! en waarmee we e.e.a. zodanig kunnen inrichten dat we bijv. Verkooporders door ADS-Server1 laten afhandelen, en Verkooporderregels door ADS-Server2; of alle Logistieke bestanden door de ene server, en alle financiële bestanden door een andere server.

Nb: Hoewel deze ondersteuning er al wel is, en ook werkt, zijn er nog geen berichten van klanten die dit ook daadwerkelijk zo gaan toepassen. Omwille van mogelijk toekomstig benodigde performance issues, is e.e.a. al wel vast zo opgezet. Zo is gekonstateerd dat een Server, bestaande uit 4 Cores, bij het reorganiseren van 1 tabel tot 25% van zijn CPU capaciteit komt. Reorganiseren we 2 tabellen tegelijk, dan komen we uit op 50%, en bij het gelijktijdig reorganiseren van 4 tabellen, benutten we de volledige 100%.

Dit "gelijktijdig" reorganiseren kunnen we nu alleen triggeren door op 4 werkstations een reorganisatie opdracht voor een andere ADS tabel te geven. Maar, we hebben al ontwerpjes uitgewerkt om één werkstation simultaan 4 reorganisatie opdrachten te kunnen laten geven (of beter, w.s. net zoveel als dat er cores beschikbaar zijn). Kombineer dat vervolgens met het verdelen van de ADS tabellen over meerdere Servers, en 8 tabellen die normaliter na elkaar gereorganiseerd zouden moeten worden en ieder 1 uur in beslag nemen, worden nu ineens tegelijkertijd in 1 uur gereorganiseerd.

Aan het minimaliseren van deze downtijd hangt echter een prijskaartje, immers, iedere ADS Server zal een aparte licentie vereisen.

Nb: In bovenstaand setje zijn we inmiddels al aanbelandt bij Data Dictionary volgnummer 0300.
Merk op dat de data, ook al is deze verdeeld over meerdere servers, wel tezamen een consistente set moet opleveren.
Volgnummer 0300 op de ene server wordt dan ook gekombineerd met volgnumer 0300 op de andere servers.
Inmiddels zijn er in deze nieuwe Data Dictionary ook al een stuk meer tabellen opgenomen in de ADS Database.

Bekijken we nu nogmaals het RichtClick scherm met de ADS Informatie, dan zien we dat er nu 2 ADS Connections gekoppeld zijn.

(http://www.heartprofit.com/www/transfer/graphics/ads/syrcads120323004.png)

Per Connection wordt aangegeven op welke Server deze zich bevindt, en welke tabellen door die Connection worden afgehandeld.

Zouden we nu, bij de aanwezigheid van meerdere ADS Servers, nogmaals kijken naar het Uploaden van een file naar de ADS Server, dan zien we dat we daar nu kunnen kiezen naar welke van de gekoppelde ADS Servers we willen uploaden; die op 192.168.100.192 of die op 192.168.100.195.

(http://www.heartprofit.com/www/transfer/graphics/ads/sybhbako120323002.png)

Voor beide punten geldt inmiddels dat het idee leuk is/was, maar de toepassing minder bruikbaar.


Behoort op zich tot de (ontwikkelde) mogelijkheden, maar is alleen toepasbaar bij ADS tabellen van het type ADS_VFP, omdat deze met separate indexfiles kunnen werken.
De methode is toch weinig zinvol, omdat we niet voor ADS_VFP zullen kiezen maar voor ADS_ADT, al was het maar omdat ADS_ADT toestaat om Differentiele Backups te maken (en ADS_VFP niet). ADS_ADT werkt met zgn. auto-indexen en daarbij hebben we zelf geen invloed meer op het indexeren van een specifieke index.



Hierbij aanvullend de opmerking dat het voor Backup-/Restore doeleinden niet handig uitpakt dat de database over meerdere Servers verdeeld is; Backups moeten nl. wel "consistent" zijn. D.w.z. als de ene Server vaker, of op andere tijdstippen gebackupped wordt dan de andere Servers, kan er nooit een consistente restore worden gemaakt.