MAX_CACHE_SIZEZie ook
http://devzone.advantagedatabase.com/dz/webhelp/advantage9.1/max_cache_memory.htmMiddels een setting MAX_CACHE_SIZE kan richting ADS worden aangegeven hoeveel geheugenruimte er door ADS gebruikt moet worden om informatie (vnl. indexen) te cachen;
advies is deze Cache uit te schakelen.
Waarom Cache?Cache is een tijdelijk geheugen waarin informatie wordt opgeslagen, om deze informatie (later) sneller te kunnen benaderen. Cache geheugen wordt gebruikt bij het lezen van gegevens, maar kan ook worden gebruikt bij het schrijven van gegevens. Dit topic gaat over dat laatste type: schrijf-cache.
Het cachen van gegevens tijdens het schrijven betekent dat deze gegevens niet direkt naar disk worden geschreven, maar bewaard worden in tijdelijk geheugen, om op een later moment alsnog naar disk geschreven te kunnen worden. Wanneer 'later' is hangt af van de specifieke software. Het daadwerkelijk schrijven kan plaatsvinden als de opgegeven grootte van het cache geheugen helemaal gevuld is, het kan op basis van een tijdsinterval (eens per xxx seconden/minuten), het kan op explicitie opdracht (Flush), of bijvoorbeeld van een aktie (het sluiten van een tabel) getriggerd worden.
Het gebruiken van Cache geheugen heeft alles met "Performance" (prestaties/snelheid) te maken. Lees-/schrijfopdrachten in het geheugen zijn vele malen sneller dan lees-/schrijfbewerkingen naar disk. Daarnaast geldt dat als we naar disk schrijven, zo'n disk in 'blokken' is ingedeeld, en ook al zouden we slechts een klein deel van een blok moeten beschrijven, er zal altijd een volledig blok beschreven moeten worden. Zie dit maar zo dat als we een Artikel toevoegen, en 1 Artikel een index heeft op Bedrijfs-id (11 posities) en op Artikelnummer (15 posities) dan moeten er 26 tekens (bytes) naar de index worden geschreven (de overige indexen even buiten beschouwing gelaten). De grootte van een disk-blok is bijvoorbeeld 4K (4096 bytes). Ondanks dat we nu 26 tekens moeten schrijven, zal dit toch een blok van 4096 bytes in beslag nemen. Hieruit volgt al dat het wenselijk kan zijn om net zoveel toegevoegde Artikelen uitgesteld in Cache geheugen te bewaren tot we er 157 hebben, want dan kan dit als 1 blok naar disk worden geschreven, wat nagenoeg evenveel tijd kost.
Bij een test met het inlezen van 2500 Verkooporderregels is gekonstateerd dat dit inlezen 645 seconden duurt (met Cache aktief) versus 715 seconden (Cache uitgeschakeld). Zodra de Cache aktief is, wordt er een klein kwartier in het geheel niet naar de index geschreven; alle index informatie wordt opgeslagen in het Cache geheugen. Pas als we in het Hoofdmenu in Profit de gegevens vrijgeven, zien we dat indexinformatie wordt weggeschreven naar disk (de ADI's worden beschreven). Is Cache uitgeschakeld, dan wordt er direkt naar zowel ADT als ADI geschreven. Dit duurt weliswaar iets langer, maar, als we nu klaar zijn, is ook alle informatie daadwerkelijk naar disk geschreven.
NadelenAls we bovenstaande lezen, dan kunnen we bedenken dat we het Cache geheugen niet groot genoeg kunnen definieren. Theoretisch klopt dat ook wel, maar er is ook een praktische kant. En wel eentje die ons toch doet adviseren deze MAX_CACHE_MEMORY uit te schakelen!
Het geheugen van een computer betreft een tijdelijke opslag van gegevens. Uiteindelijk is het ook de bedoeling dat de computer (Server) in staat gesteld wordt om de informatie die ze in haar cache geheugen heeft staan naar disk weg te schrijven, maar... wat als ze die mogelijkheid
niet krijgt ? In de situatie van een crash van de Server (de stekker wordt uit de Server getrokken, en staat van het ene op het andere moment uit), zal alle informatie die in het geheugen stond verloren gaan. Als de computer opnieuw aan wordt gezet, zal de informatie die nog niet was weggeschreven naar disk verloren zijn gegaan. Die gegevens bent u gewoonweg kwijt !
Maar het kan nog veel erger... en eigenlijk moeten we bovenstaande zin uitbreiden met 'in het gunstigste geval'... De Database kan inconsistent raken !
Een tabel heeft altijd 1 of meerdere indexen. Wordt er een nieuw record toegevoegd, dan wordt dit record ook opgenomen in de betreffende indexen; de sorteersleutels voor de tabel. Het schrijven van data naar de tabel doet ADS wel direkt, het beschrijven van de indexen loopt via Cache geheugen. En, zoals we uit de link kunnen halen, is het reeel om te stellen dat er wel 256 MB aan data gecached wordt. Stel nu eens dat alle 15 indexen van 1 Verkooporderregel tezamen 1 KB aan ruimte in beslag nemen, dan zou dit impliceren dat er 256.000 records orderregels (bestellingen) uitgesteld weggeschreven worden (natuurlijk wordt de 256 MB verdeeld over meerdere tabellen, maar het gaat om een idee omtrent de hoeveelheden waar we het over hebben). Als de Server nu zou uitvallen, dan zijn we van duizenden Orderregels de bijbehorende index informatie kwijt. De Database komt dan niet meer overeen met de Index en is dan inconsistent.
"Ach, het betreft maar een index, en die kunnen we met reorganiseren toch gewoon opnieuw opbouwen ?". Ja... Dat klopt. En daarmee kan de foutieve index altijd wel weer hersteld worden... maar... het reorganiseren neemt tijd in beslag. Hoeveel tijd? Dat hangt volledig af van de grootte van de tabellen, het aantal indexen, en de specifikaties van de Server. Inmiddels hebben we het al over tabellen die de grootte van 25 GB zijn gepasseerd. En, daar vooraf niet bekend zal zijn van welke tabellen de indexen verknald zijn, zal het er al snel op neer komen dat "alles" opnieuw gereorganiseerd moet worden, hetgeen al snel enkele uren in beslag kan nemen, gedurende welke tijd u met het hele bedrijf niet in Profit kan werken.
Voor een aantal scenario's kunnen we maatregelen nemen. Met een UPS (Uninterruptible Power Supply) kunnen we ervoor zorgen dat als de stroom uitvalt, de Server toch doordraait op een noodstroomvoorziening. Helaas is 'een stroomstoring' slechts 1 van de oorzaken van het ongewenst down gaan van de Server.
Het uitzetten van de Cache dient u zelf te regelen via een registry setting. Of u dit uitzet bepaalt u zelf. Het zal een performance verlies van zo'n 10% opleveren, wat voor sommige processen misschien merkbaar is, maar mogelijk best mee kan vallen, maar wat wel degelijk zal opwegen tegen de mogelijke downtijd tijdens na een crash. Zijn er nl. geen indexen corrupt, dan hoeft er ook niet gereorganiseerd te worden, wat weer enkele uren kan schelen.
Hoe en waar op te nemen* Zorg ervoor dat er geen gebruikers meer in Profit zitten (zoals bij een Upgrade).
* Stop de Advantage Database Server Service.
* Met de Registery Editor dient op de ADS Server in \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Advantage\Configuration een DWORD-32bit value "MAX_CACHE_MEMORY" te worden aangemaakt; de waarde dient met 0 te worden gevuld (= default voor de DWORD value) om Cache uit te schakelen.
* Herstart de Advantage Database Server Service
* Gebruikers mogen weer opnieuw in Profit.
