Releasenote
http://ha1.heartprofit.nl/profit/index.php?topic=27884.0 beschijft de opname van een optie 'Inklusief SQL Indexen J/N' bij het Reorganiseren van Bestanden in de ADS versie.
Deze optie is in februari 2017 opgenomen nadat bij een klant indexen van de tabel LOVM waren beschadigd na een crash van de Server. In dit specifieke voorbeeld betrof het 1 tabel, maar, het zou hier evengoed "alle" tabellen kunnen betreffen.
De tabel was van dermate omvang dat het reorganiseren ervan in totaal 3,5 uur in beslag nam, waarvan 1,5 uur voor de SQL Indexen; m.a.w. 2 uur voor de Profit Indexen. SQL Indexen worden in Profit vnl. gebruikt op plekken waar SQL Queries worden ingezet sneller te maken. Voor het normale "toevoegen/wijzigen/verwijderen/raadplegen" hebben we die indexen in verreweg de meeste gevallen niet nodig. En, al zouden deze indexen ontbreken, dan zullen de toepassingen die zich baseren op SQL Queries (bijv. Statistieken, of het printen van een (Kolommen-) Balans) op zich nog best werken, maar een stuk trager.
De noodreorganisatie optie om te kunnen reorganiseren zónder de SQL Indexen op te bouwen, is opgenomen om de downtijd in dit voorbeeld te kunnen beperken tot 2 uur, om daarna op een beter geschikt moment ('s avonds of in het weekend) de tabel nogmaals te kunnen reorganiseren mét SQL indexen.
Op zich dit deze oplossing "de job", maar we gaan we nu een stukje verder...
Immers, van iets wat 3,5 uur duurde, hebben we nu 2 uur uitgevoerd, en als we in de oude situatie terug wilden naar een tabel mét SQL indexen, moesten we de tabel dus nogmaals reorganiseren. Kortom, wéér 3,5 uur wachten waarvan er eigenlijk al 2 uur waren uitgevoerd. Eigenlijk willen we dus alleen het "niet uitgevoerde deel" alsnog kunnen uitvoeren, nl. het aanvullend opbouwen van de SQL indexen. Dat zou dan slechts de 1,5 uur in beslag nemen die eerder was overgeslagen.
Met ingang van heden is de Checkbox waarmee we er voor konden kiezen om géén SQL Indexen op te bouwen, vervangen door een Optiongroup waarmee we kunnen aangeven wat er gereorganiseerd moet worden:
Hierin kunnen we kiezen voor 3 situaties:
1. Reorganiseren Profit-Indexen én SQL-Indexen (Defaultwaarde)
2. Reorganiseren alléén Profit-Indexen (en dus geen SQL-Indexen)
3. Reorganiseren alléén SQL-Indexen
Optie #3 is bedoeld als "aanvullend" op optie #2. Dit is echter geen verplichting. Het kan op zich geen kwaad om #3 uit te voeren indien de tabel de vorige keer via optie #1 was gereorganiseerd. Alvorens de SQL Indexen opnieuw op te bouwen, zullen eerst alle eventueel bestaande SQL Indexen worden verwijderd.
Merk hierbij wel op dat bij een tweede keer SQL Indexen reorganiseren, de indexfile groter wordt. Het 'verwijderen' van de reeds bestaande indexen maakt dus niet de diskruimte vrij die die indexen in beslag nemen. Ofwel, als we een tabel hebben van 1.000 MB waarvan de index op 800 MB zit, en laat die 800 MB eens verdeeld zijn over 500 MB aan Profit-Indexen en 300 MB aan SQL Indexen, dan zal de Index na reorganisatie met optie #2 op 500 MB zitten. Reorganiseren we de tabel aanvullend met SQL Indexen, dat komt ze op 800 MB (ofwel, dezelfde grootte als we direkt #1 hadden gedaan). Reorganiseren we de SQL-Indexen daarna nog een keer, dan komt er wéér 300 MB aan indexgrootte bij; de index file komt daarmee op 1100 MB. Nogmaals SQL indexen reorganiseren, en het wordt 1400 MB etc.
Kombineren we echter het opbouwen van de SQL Indexen met een PACK, dan wordt de grootte op zich wel weer gereset naar 800 MB, maar, dan streven we eigenlijk ook een doel voorbij: de PACK met de ProfitIndexen AAN zal als vanzelf die Profit-Indexen ook opnieuw moeten reorganiseren; we zouden dan dus beter de PACK kunnen kombineren met optie #1.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| CLASSES | Geen standaard funktie | 03-04-2019 | 03-04-2019 |
| LOBHOI | Reorganiseren Bestanden | 27-03-2019 | 03-04-2019 |
| LOBHOIVA | Omschrijving (nog) niet bekend | 13-02-2017 | 03-04-2019 |
| SYBHOIDD | Omschrijving (nog) niet bekend | 15-02-2019 | 03-04-2019 |
| SYBHOIIO | Omschrijving (nog) niet bekend | 08-01-2019 | 03-04-2019 |
