Heart-Profit ERP

Waar Profit normaliter (omwille van performance) de Database en de Indexen op twee fysiek gescheiden disks plaatst, was dit voor ADS ook standaard het uitgangspunt. De standaard opzet was dan ook een ADS_DATA_SHARE op disk1 en een ADS_INDEX_SHARE op disk2. Database en Data Dictionary stonden op de ADS_DATA_SHARE en de indexen werden weggeschreven op de ADS_INDEX_SHARE.

Op zich leek dit allemaal te werken. Bij het reorganiseren konden we de indexen wegschrijven naar het index volume, in de Data Dictionary werd het volledige path naar de indexfile opgenomen, en alles leek erop te wijzen dat dit werkte.

Helaas hebben we moeten konkluderen dat het bij de Restore niet goed gaat.

De AdsBackup laat ons netjes een backup maken van onze Data Dictionary. In deze backup staat de Data Dictionary en de Data (maar géén indexen, omdat die opnieuw zullen worden opgebouwd vanuit wat er bekend is in de Data Dictionary). Hoewel de gebackupte Data Dictionary wel de juiste lokatie bevatte naar de indexfiles (bijv. \\ADS-Server\ADS_INDEX_SHARE\INDX0001\LO\LOTI\LOVR_IN1.ADI), kan de Restore er niet tegen dat deze index op een ander volume staat. Bij het restoren worden weliswaar indexen aangemaakt, ook nog conform de juiste struktuur, maar... op het data volume ! Daar wordt dus ook ineens een directory ADS_INDEX_SHARE\INDX0001\LO\LOTI aangemaakt.
Iets anders geformuleerd, op disk2 zouden we een \ADS_INDEX_SHARE directory hebben die als zodanig geshared is, en nu wordt op disk1 diezelfde directory aangemaakt (die niet geshared is).

Restoren we naar een bestaande Data Dictionary, dan zal die Data Dictionary van zichzelf nog weten dat de indexen op het index volume staan, en zouden we in theorie kunnen volstaan met alleen te reorganiseren. We hebben dan hooguit onnodig lang mogen wachten op het opbouwen van de indexen vanuit de Restore, die naar een verkeerde plek zijn teruggehaald, maar in theorie zou het te herstellen zijn.
Groter is het probleem als bijv. onze disk gecrashed is, en we de backup willen terugzetten naar een nieuwe lokatie. In dat geval worden de indexfile niet alleen teruggezet naar een nieuwe lokatie, maar in de Data Dictionary wordt vervolgens geen path meer opgenomen naar de indexfiles, met als resultaat dat er een inconsistente Data Dictionary ontstaat die zich totaal niet meer laat openen !
Het verwijderen van de onjuist in de Data Dictionary opgenomen indexen lukt ook niet, want de Data Architect zal bij het verwijderen van de index deze indexfile ook fysiek van disk willen verwijderen, en dat lukt niet, immers, de boel is inconsistent.

Zolang indexen op een ander volume niet formeel ondersteund wordt door ADS, bouwen we vanaf heden de indexen op op het data volume.

Backup-/Restore werken daarna wel, en ook het restoren naar andere directories is mogelijk.