M.i.v. heden is er een speciale Reorganisatie tool ontwikkeld t.b.v. de ADS versie van Heart-Profit.
OpstartenZodra de reorganisatie funktionaliteit wordt opgestart opent zich het onderstaande scherm.
Middels een Combobox geeft u eerst aan op welke Drive Profit (ADS) is geďnstalleerd (ervanuitgaande dat er maar 1 ADS versie aktief is, zal er maar 1 Driveletter geselekteerd kunnen worden).
Als de driveletter geselekteerd is, wordt de 2e Combobox met de Profit-directory opgebouwd. Hierin zal normaliter iets staan als \FOX\LO\LOPW (doch indien uw systeem beschikt over Profit-Base-Test zal hier ook \FOX\LO\LOTW kunnen staan). Uit de geselekteerde directory wordt de NCONFIG.HRT file gelezen, welke de information aangaande het connecten met de ADS Data Dictionary zal bevatten.
Als laatste kan middels een Combobox T/P worden aangegeven of we met de Testbestanden danwel met de Produktiebestanden willen werken (deze setting kan al worden afgedwongen door de selektie van de Profit Directory). De brede button bevat de uiteindelijke lokatie van de Data Dictionary waarmee geconnect moet worden.
Click nu op deze brede button. Er zal dan verbinding worden gemaakt met de betreffende Data Dictionary en de tabellen die daarin als ADS_ADT tabel zijn gedefinieerd worden vervolgens opgesomd in een Listview control.
Selekteer de te reorganiseren tabellenDe tabellen worden in eerste instantie opgenomen op aflopende grootte van de betreffende tabel; de grootste tabel staat bovenaan, de kleinste staat onderaan. Voor iedere tabel is een Checkbox opgenomen, waarmee we kunnen aangeven dat we een specifieke tabel wel/niet willen reorganiseren.
Boven de Listview control staat een Checkbox "Select All", welke gebruikt kan worden om in één opdracht ňf alle tabellen aan te vinken, danwel voor alle tabellen het vinkje weer weg te halen.
"In eerste instantie", omdat er ook een situatie is waarin de volgorde anders is...
Na een crash van een ADS Server hebben we te maken gehad met een situatie dat ADS bij het opnieuw openen van de tabellen konstateert dat er 'iets mis is', en dit gaat proberen te herstellen. Tijdens dit 'herstellen' is de Server vnl. bezig met het lezen uit de ADT (de tabel) en het schrijven naar de ADI files (de indexen), waaruit we zouden kunnen konkluderen dat ze intern met een re-index bezig is. Tegelijkerheid gaf de betreffende Server ook aan dat er vanuit een 'Image' werd gelezen, en werd teruggeschreven naar disk. Wat nu precies wat heeft veroorzaakt is nog niet duidelijk (daarvoor zouden we bewust een Server met veel data een paar keer moeten laten crashen), maar, na de herstelwerkzaamheden van ADS was het resultaat dat er alsnog een aantal indexen ontbraken.
Een oorzaak kan zijn dat deze index informatie al fout in de Data Dictionary stond nog vóórdat ADS ging proberen de boel te herstellen. Het zou ook mogelijk kunnen zijn dat e.e.a. juist verknald is doordat Gebruikers al weer aan het werk zijn gegaan, en pas bij het benaderen van een specifieke (corrupte) index, de interne herstelprocedure van ADS zelf aan de slag ging, maar toen de tabel (en de indexfile) al door talloze gebruikers in gebruik was. Ook kan ik niet uitsluiten dat er misschien twee processen (ADS + het terugschrijven vanuit een Image) tegelijkertijd dingen doen die elkaar dwars zitten.
Hoe dan ook: in de situatie van e.d. crash is het van uiterst belang dat
niemand Profit opstart, en deze run als eerste gebruikt gaat worden!
De run zal als extra kontrole alle ADS tabellen met hun indexen (stand t.t.v. de laatste Upgrade) vergelijken met de huidige set indexen zoals deze in de ADS Data Dictionary bekend zijn. Dit nog zónder de betreffende tabel te openen (en daarmee een interne herstelpoging van ADS te triggeren). Als hier fouten uit komen, zullen deze regels rood gemarkeerd helemaal bovenin de Listview worden opgenomen, opdat ze goed opvallen. Op zich kan deze situatie eenvoudig worden gesimuleerd door bijv. vanuit de Advantage Data Dictionary een specifieke index van een tabel te verwijderen. De run zal dan moeten detecteren dat deze index er conform de laatste upgrade gegevens wel had moeten zijn, en markeert de tabel als 'fout'.
Reindex of opnieuw opbouwen ?Onder de Listview control vinden we een Checkbox "ADS Reindex (conform current DD settings)". Als hier een vinkje wordt geplaatst, zal de tabel opnieuw worden gereorganiseerd door ADS een Re-Index te laten uitvoeren. Een ADS Re-Index is een zéér snelle wijze van reorganiseren, omdat ADS de tabel maar één keer doorloopt, en dan op een slimme wijze direkt alle indexen tegelijk opbouwt. Uiteraard kan dit alleen werken indien de ADS Data Dictionary korrekt is, ofwel, in de bovengenoemde foutsituatie (als er rode regels in de Listview staan) zal deze optie worden disabled om te voorkomen dat we conform een onjuiste Data Dictionary de indexen op een onjuiste manier opnieuw gaan opbouwen.
Is het vinkje er niet, dan zullen de indexen stuk voor stuk opnieuw worden opgebouwd, op de wijze waarop dit normaal gesproken vanuit Profit gebeurt. De snelheid hiervan is volledig afhankelijk van de hoeveelheid geheugen die in de ADS Server beschikbaar is. Om een voorbeeld te geven: als we een tabel van 8 GB reorganiseren terwijl er veel meer dan 8 GB geheugen in de Server zit, dan zal de hele tabel in het geheugen ingelezen kunnen worden, en hoeft er niet meer van disk gelezen te worden bij de opbouwen van de separate indexen. Hebben we 16 GB geheugen in de Server, maar hebben we te maken met tabellen die veel groter zijn, dan geldt dat er niet meer vanuit het geheugen gewerkt kan worden, en er steeds opnieuw van disk gelezen moet worden. Advies is dan ook om minimaal net wat meer geheugen in de Server te hebben dan de grootste tabel, opdat de tabel tijdens reorganisatie in het geheugen past.
Nb: Ook hier zal wel gelden dat als we twee grote tabellen tegelijk willen reorganiseren, ze eigenlijk 'tegelijk' in het geheugen moeten passen om dit zo effektief mogelijk te laten verlopen.
Terug naar de genoemde foutsituatie: als de indexset t.t.v. de laatste Upgrade niet overeenkomt met wat er nú in de Data Dictionary staat, dan is het niet mogelijk om de ADS Re-Index optie te gebruiken. Maar... alvorens de indexen opnieuw op te bouwen, worden alle indexen éérst ontkoppeld (en verwijderd) zónder hiervoor de tabel zelf te openen. Dit, met als doel dat áls het heropenen van een tabel ADS zelf laat triggeren de tabel te gaan reindexen, er t.t.v. dat openen van de tabel geen indexen meer gekoppeld zullen zijn. Natuurlijk zijn we dan alsnog tijd kwijt aan het reorganiseren van de betreffende tabel, maar dat is altijd nog beter dan dat ADS eerst zelf de tabel automatisch reorganiseert, en wij vervolgens moeten konkluderen dat alsnog niet alle indexen teruggezet zijn, en we nogmaals moeten wachten op het zelf reorganiseren van de tabel.
Pack table ?De Checkbox "Pack Table" is bedoeld om de records in de tabel die als 'deleted' zijn gemarkeerd, daadwerkelijk te verwijderen. Omwille van performance zal deze setting standaard uit staan. Het verwijderen van 'als gedelete aangemerkte records' speelt in ADS ook een stuk minder dan in normaal Visual FoxPro toen we nog met een 2 GB limiet van een tabel te maken hadden. Ervanuitgaande dat de diskruimte ons in mindere mate interesseert, hoeft dit niet geaktiveerd te worden. Hebben we toch veel verwijderde records in een tabel, en willen we de tabel kleiner maken, dan kan alsnog voor deze optie gekozen worden. Leuk om eens in het weekend te kunnen doen als er niemand in het systeem zit en het niet uitmaakt dat het reorganiseren wat langer duurt, maar al snel geen optie als er a.g.v. een foutsituatie noodgedwongen gereorganiseerd moet worden, en het hele bedrijf plat ligt en zo snel mogelijk weer door moet kunnen. In dat laatste geval vooral GEEN pack uitvoeren (de default instelling).
No of simultaneous index processesEen van de belangrijkste redenen voor de ontwikkeling van deze tool betreft het tegelijk kunnen reorganiseren van meerdere tabellen. Als we vanuit een Profitsessie een bestand gaan reorganiseren, gebeurt dat in feite niet op het werkstation zelf, maar op de ADS Server. Profit geeft de ADS Server de opdracht de tabel te reorganiseren, en zodra deze ADS Server hiermee klaar is, krijgt Profit het bericht dat ze weer verder kan met een volgende taak. Proefondervindelijk is gekonstateerd dat de ADS Server één core inzet voor e.d. reorganisatie job, hetgeen inhoudt dat 'de andere cores' in de Server 'niets' staan te doen. Bij een simpel voorbeeld van een Server met 4 cores herkennen we dat de CPU van de Server niet hoger komt dan 25%. Die 25% wordt dan veroorzaakt doordat 1 van de 4 cores op 100% bezig is, maar dat slechts 25% is van de totale capaciteit van de Server.
Zouden we een ander werkstation opstarten en deze een tweede tabel laten reorganiseren, dan zien we dat de CPU naar 50% gaat. Bij een 3e reorganisatie opdracht wordt het 75% en bij 4 gelijktijdige opdrachten gaat de CPU naar 100%.
Met deze nieuwe tool1 is het niet meer nodig om op 4 verschillende werkstations Profit op te starten; vanaf één werkstation kan nu een opdracht worden verstrekt om tot maximaal 16 verschillende Reorganisatieopdrachten tegelijkertijd uit te laten voeren.
Let op: Zodra er méér opdrachten tegelijk worden uitgevoerd dan uw Server aan kan (stel dat we in het voorbeeld van de Server met 4 cores er 8 tegelijkertijd laten uitvoeren), dan mag duidelijk zijn dat 1 core ineens 2 jobs tegelijk zal moeten verwerken, waardoor het reorganisatie proces niet meer optimaal zal kunnen verlopen. Ook kan de lees-/schrijf snelheid van de disk waarop de ADS data staat op enig moment een bottleneck gaan vormen wat ervoor zorgt dat het sneller is als we minder jobs tegelijkertijd aanbieden. Wat in uw situatie optimaal is zal proefondervindelijk moeten worden bepaald.
ReorganiserenIndien alle gegevens ingevuld zijn kan de button "Start Indexing" worden gebruikt om te gaan reorganiseren. Er worden nu net zoveel Index Processen opgestart (speciale executables die op de achtergrond draaien) als is aangegeven. Ieder proces gaat op zoek naar de eerst volgende, nog niet in behandeling genomen zijnde reorganisatie opdracht, en pakt deze op. Ongeacht de volgorde waarin de tabellen op het scherm worden weergegeven (gesorteerd zijn), bij het reorganiseren zal het grootste bestand altijd als eerste worden opgepakt. Zodra een van de indexprocessen klaar is, pakt ze automatisch een volgende job op, hetgeen 'steeds sneller' zal gaan omdat de tabellen steeds kleiner worden. Het beste is dus dat in de tijd die nodig is om de grootste bestanden te kunnen reorganiseren, de rest van de CPU kracht wordt gebruikt om de overige tabellen te kunnen reorganiseren.
1x per ongeveer 3 seconden wordt de informatie van de aktieve processen bijgewerkt; op die manier is zichtbaar wel proces met welke tabel bezig is.
Ook wordt in de Listview control de status van iedere tabel bijgehouden. Is de reorganisatieopdracht van de tabel nog wachtend ? Is ze al in behandeling genomen? Door welke proces? Is het reorganiseren van de tabel al klaar? Hoelang heeft het geduurd? etc.
Als we ondertussen op de ADS Server gaan kijken, zien we dat er tegelijkertijd uit meerdere tabellen (ADT's) wordt gelezen, en dat er wordt geschreven naar de ADI's (indexen).
Profit blokkerenAls we te maken hebben met een foutsituatie, dan is het de bedoeling dat NIEMAND Profit opstart. Deze run zal als enige moeten worden opgestart om te kontroleren of de indexen overeenkomen met wat er in de Data Dictionary geregistreerd is, en deze run zal gebruikt moeten worden om te reorganiseren. Weten we niet zeker wat, dan hoort mogelijk 'alles' gedaan te worden, om er maar zeker van te zijn dat we niets missen. Het toch opstarten van Profit kan ertoe leiden dat ADS de boel zelf gaat proberen te herstellen, en hierin niet slaagt. Ook zou dit kunnen impliceren dat een herstel procedure van ADS uitgevoerd moet worden, maar niet uitgevoerd kán worden omdat de tabel met index al door andere gebruikers geopend is. De Systeembeheerder zal Profit zelf (handmatig) even moeten blokkeren voor opstarten. Handmatig; dus niet eerst Profit opstarten en de menuopties daarvoor gebruiken; maar door een PROFIT.BLK file te plaatsen in de \FOX\LO\LOPW\ directory.
