Database en Indexen op separate volumes
De titel van topic
http://ha1.heartprofit.nl/profit/index.php?topic=24626.0 doet vermoeden dat het in ADS helemaal niet mogelijk is om de indexen op ander volume te plaatsen dan waarop de database zich bevindt. Het topic zelf legt al uit dat we het op zich wel gerealiseerd hadden, maar, dat de ADS Restore hier niet tegen kon; derhalve gebruiken we dit nu niet...
Vandaag houden we dit nogmaals tegen het licht... temeer omdat via topic
http://ha1.heartprofit.nl/profit/index.php?topic=29357.0 is gebleken dat als informatie zoals de lokatie van de index bij een restore uit de te restoren Data Dictionary wordt gelezen, dit *dus* impliceert dat de indexfiles zouden moeten worden aangemaakt op de oorspronkelijke lokatie, en niet op de lokatie waarnaar gerestored wordt (waaruit weer volgt dat we een restore omwille van de indexen altijd zullen moeten restoren naar haar oorspronkelijke omgeving).
Daarmee zou gelden dat, mits we maar naar die oorspronkelijke lokatie restoren, niets ons ervan weerhoudt om de indexen niet op de ADS_DATA_SHARE aan te maken, maar hier een separate ADS_INDEX_SHARE voor te maken.
Zo zien we onderstaand een voorbeeld waarbij de index is aangemaakt op hetzelfde volume (ADS_DATA_SHARE) als waarop de database staat:
En in onderstaand voorbeeld staan die indexen op een separaat ADS_INDEX_SHARE volume:
Hoe stellen we in dat de Indexen op een ander volume moeten komen te staan?
Allereerst zullen we op dat nieuwe volume een nieuwe Sharenaam moeten aanmaken, bijvoorbeeld:
ADS_INDEX_SHARE.
Dan zullen we in de
NCONFIG.HRT moeten aangeven dat Indexen op die nieuwe sharenaam moeten worden aangemaakt.
De lokatie van de Data Dictionary, alsmede de Database geven we aan m.b.v. een regel:
ADSDDPATH=\\ADSServer\ADS_DATA_SHARE\LIVE0001Door hier een nieuwe regel aan toe te voegen:
ADSDDINDEXPATH=\\ADSServer\ADS_INDEX_SHARE\LIVE0001geven we aan dat de indexen op een ander volume (ADS_INDEX_SHARE) terecht moeten komen. Merk hierbij op dat de naam van de ADS Server zowel bij de Data als bij de Indexen dezelfde zal moeten zijn. De naam die representatief is voor uw 'omgeving' mág in beide gevallen dezelfde zijn, maar dat hoeft niet. U kunt zowel op het data- als op het index volume 'LIVE0001' aanhouden, maar u zou er ook voor kunnen kiezen om deze map 'DATA0001' op het data volume te noemen, en 'INDEX001' op het index volume.
Hoe kontroleren we of het gelukt is?
Als we Profit opnieuw opstarten, dan kunnen we, als we eenmaal in het Hoofdmenu zitten, een RightClick doen op het achtergrondscherm (FrmTop). Aldaar kiezen we voor optie 'ADS Info'. Het popup welke dan verschijnt toont ons allerlei informatie omtrent de ADS omgeving, waaronder (helemaal bovenin) de lokatie van de ADS Data Dictionary, het Path naar de ADS tabellen, en het Path naar de ADS Indexen. Bij deze laatste zult u nu de lokatie moeten zien die naar de ingestelde ADS_INDEX_SHARE verwijst.
Opnieuw reorganiseren
Het feit dat we in de
NCONFIG.HRT een tag
ADSDDINDEXPATH opnemen doet op zich nog niets... Het zegt hooguit dat áls we gaan reorganiseren, de indexen moeten worden opgebouwd op het ADS_INDEX_SHARE volume. Als we deze setting zojuist nieuw hebben opgenomen, of we hebben de lokatie gewijzigd, dan zullen alle Tabellen gewoon nog op hun oude lokatie hebben staan.
Dus, voor de duidelijkheid: als we géén ADSDDINDEXPATH hebben opgenomen, staan onze indexen op het ADS_DATA_SHARE volume. Nemen we nu een ADSDDINDEXPATH op, dan zal bij een eerst volgende reorganisatie de indexfile van het ADS_DATA_SHARE volume worden verwijderd, en opnieuw worden opgebouwd op het ADS_INDEX_SHARE volume. Zolang we de tabellen niet opnieuw hebben gereorganiseerd, verwacht ADS deze files dus nog gewoon op het ADS_DATA_SHARE volume. Kunnen we die files niet even snel 'verplaatsen' van de oude lokatie naar de nieuwe lokatie? Nee. ADS slaat de lokatie van de indexfile op in de definitie van de Tabel. Zouden we de indexen verplaatsen, dan ontstaat er vervolgens een inconsistente dataset, en kan ADS de Tabel niet meer openen. Opnieuw reorganiseren dus!
Tip: Bij Reorganiseren Bestanden (Hoofdmenu-9-5-1) is het mogelijk om als type "
ADS" in te vullen. Type "ADS" scant uw Data Dictionary en reorganiseert alle tabellen die in uw situatie "over zijn naar ADS". Daarmee reorganiseert u dus als vanzelf alle Tabellen uit de ADS Data Dictionary.
Backup -/ Restore
Zojuist hebben we een omgeving gekreëerd waarbij de data (de ADT's) zich bevinden op een ADS_DATA_SHARE volume, en de indexen zich bevinden op een ADS_INDEX_SHARE volume; beide in een subdirectory 'LIVE0001'.
Van deze omgeving hebben we vanuit de Advantage Data Architect een Backup gemaakt (dit werkt o.b.v. het AdsBackup.exe commando).
Daarna hebben we in Profit 'Reset Mutatiebestanden' uitgevoerd; een tool die eigenlijk ooit voor Heart zelf is ontwikkeld om bijv. een Behoefterun te kunnen testen. De tool schoont alle 'Mutatiebestanden' in Profit op, maar laat de 'Stambestanden' staan. M.a.w., we hebben daarne géén Verkooporders, géén Verkooporderregels, géén Inkooporders etc. meer, maar nog wel onze Artikelen, Relaties en Debiteuren e.d.. Een situatie die zich eenvoudig laat kontroleren, door bijv. naar Raadplegen Verkooporders te gaan (Hoofdmenu-3-1-1) en te konstateren dat alle orders weg zijn.
Daarna is er een Restore uitgevoerd van de eerder gemaakte Backup. Deze restore is gedaan naar exakt dezelfde lokatie.
Resultaat is dat de Tabellen (de ADT's) netjes zijn gerestored naar de opgegeven lokatie (waarbij we de oorspronkelijke lokatie hadden geselekteerd) en de indexen netjes zijn bijgewerkt op het ADS_INDEX_SHARE volume.
Gaan we nu opnieuw naar Raadplegen Verkooporders, dan zien we dat alle orders weer terug zijn.
LET OP:Bij het restoren van bijv. een LIVE0001 omgeving moet deze altijd worden teruggezet naar de oorspronkelijke lokatie (LIVE0001). Dit is nodig omdat de lokatiegegevens van de indexfiles horende bij de tabellen is opgeslagen in de (gebackupte) ADS Data Dictionary, en deze naar deze lokatie worden teruggezet als we een Tabel restoren. Zie verder topic http://ha1.heartprofit.nl/profit/index.php?topic=29357.msg48972#msg48972
