Clash of the Titans: consistency checks en recovery

[AvD]

Gisteren is er een frontale aanvaring gebeurd tussen Jeff Hopkins en Wim Decorte. Iedereen die die twee kent, weet dat dit iets betekent.

Waarover ging het, en wat is jullie ervaring?

 

Iedereen weet dat recovery zeer destructief is, en enkel dient om gegevens te redden, zodat ze kunnen geïmporteerd worden in een zuivere kloon (je laatste backup, bijvoorbeeld). De vraag ging over "This file has not been closed properly". Wim meent dat ook zo'n bestand niet meer betrouwbaar is, en geeft het dezelfde behandeling als een gecrasht bestand: recovery en daarna onverbiddelijk de prullenmand in. De meeste mensen doen dat niet, en werken na de Consistency check gewoon verder met dat bestand. Zelf heb ik ook altijd zo gewerkt.

Nu bleek dat één of andere tool kan aangeven hoe vaak een bestand niet correct gesloten is, en dat de FileMaker templates zelf verschillende keren in dat geval zouden geweest zijn.

Wim houdt vol dat die bestanden onbetrouwbaar zijn, en Hopkins gaat frontaal in de aanval:

Point is, you are wasting time, giving bad advice and missing out on what is really important!

Mijn vraag: wat is jullie ervaring met bestanden die eens of meerdere keren niet correct gesloten zijn? Zijn daar achteraf plots (onverklaarbare) problemen mee ontstaan? Hebben jullie ooit een recovery moeten toepassen zonder dat daar enige aanwijsbare reden voor was?

Edited September 11, 2003 by Guest

[dannydv]

Zelf heb ik nog nooit een soortgelijk probleem ondervonden.

 

Ik vermoed dat het inderdaad geen kwaad kan om een bestand te gaan recoveren bij het aangeven van de kleinste fout die opgetreden is, de vraag is natuurlijk of het noodzakelijk en zinvol is. Ik heb daar in ieder geval nog geen reden voor gevonden.

 

De probleemstelling over corruptie op het niveau van een layout is natuurlijk een ander verhaal. Ik heb al advies gelezen van mensen die je zelfs afraden om een layout te dupliceren. Want als er in probleem in zou zitten (iets wat in het verleden nu wel al gebleken is dat dat kan) dan zou je dat probleem meecopieren.

Zijn dit stellingen die nog steeds up-to-date zijn met de recente versies van FMPro (5.5 - 6.0)?

[AvD]

Dank voor deze positieve reactie:

 

de vraag is natuurlijk of het noodzakelijk en zinvol is. Ik heb daar in ieder geval nog geen reden voor gevonden.

 

Inderdaad: als je bij elke consistency check je data opnieuw zou moeten importeren in een kloon, dan zet je natuurlijk het systeem van de klant even stil. Maar dat "even" duurt voor sommige bestanden uren en uren. Als je dan met een systeem zit van pakweg meer dan 50 files, waarbij een dertigtal consistency checks gebeurd zijn zonder enig verder gevolg, dan kan je je wel afvragen of je de klant kan vertellen dat de hele zaak maar beter een dagje (of meer) dichtgaat...

[Dr_Flash]

Met andere woorden: Jeff geeft een FMP-technisch gezien "betere" stelling, Wim betrekt ook de praktijkgevolgen voor een bedrijf erbij. Logisch dat ze tot verschillende conclusies komen

 

Maar als ik even een hele domme vraag mag stellen:

Iedereen weet dat recovery zeer destructief is

...ik dus niet

[AvD]

Hier al wat meer info over recovery:

 

http://www.avd-ci.be/tip049.htm

http://www.avd-ci.be/tip050.htm

http://www.avd-ci.be/tip051.htm

 

Straks zal ik de uitleg posten over wat er precies gebeurt tijdens een recovery.

[AvD]

Hierna een beschrijving van de recovery, gegeven door Marcel de Maria van FileMaker Inc.:

The Recover command should only be used on files that will not open, or are displaying index problems. If you decide to recover a file then the following happens:

 

1. A new empty database is created to hold data blocks that are about to be copied from the damaged file.

 

2. The logical End of File (EOF) in the damaged database is reset to be equal to the physical EOF and each block of the damaged database is copied over to the new file. As each block is copied, it is examined to validate its internal structure. If any problem is found, the block is repaired.

 

3. The database is reverted to a default state similar to a brand new database. The items that are removed or reverted include: Record Count, Summaries, Sub-summary sort order, Sorted Order, Custom Sort Order, List of Found Records, Import Order, Export Order, Calculation trigger table, Find Patterns, Sort Specification.

 

4. FileMaker validates each record in the database. This includes checking for valid header information and also that each field within the record has a valid key and valid (non-zero) length. As each field is validated, it is checked against a master list of existing fields. If any invalid fields or records are discovered in this process, they are removed from the database.

 

5. FileMaker validates each layout in the database. Defaults are reset and each layout is examined for consistency.

 

6. Next, all field definitions and scripts are validated. Any regenerated fields are named "Recovered Field 1", "Recovered Field 2", and so on. When a field type has been corrupted, FileMaker makes the field a text field, so that any existing data in the field can be retrieved. Every script is checked to make sure it has a valid name, status information and options. If any of these elements of a script is corrupt, then the script is deleted.

 

7. FileMaker now deletes the existing index and reconstructs the index to maintain consistency and referential integrity within the database.

 

8. Finally, any unused space and empty disk blocks are removed from the file.

 

[AvD]

Darren Terry over de gevaren van recovery nadat iemand gevraagd had of het kwaad kan een recovery toe te passen en daarna met die file verder te werken:

 

That's not a crazy question at all. The answer is yes, you can indeed "over-recover" a file. Why? Because the Recovery option in FMP is very aggressive at seeking out corruption. It's possible to take a brand-new file and recover it, and end up losing layout objects or field definitions because the recovery process thought those things were "suspicious". If the recovery process thinks something is suspicious, it simply doesn't copy that item over to the recovered file. In this way, it's possible for a recovered file to end up missing some structural items. (Remember that the focus of recovery is to get your data out, and it will consider the structure to be expendable).

 

There was a time (back in the FMP 2.1 days) when I would recommend periodic Recovery as a maintenance routine. No more.

[Dr_Flash]

Remember that the focus of recovery is to get your data out, and it will consider the structure to be expendable.

 

Aha nou snap ik het Dank!

[eurotouring]

ik heb de melding al een paar keer gehad, filemaker herstelt toch zelf niet goed afgesloten files. Ik heb nog nooit een probleem gehad om voort te werken met deze files

[AvD]

Ik heb nog nooit een probleem gehad om voort te werken met deze files

 

Vele jaren geleden ben ik eens ontzet uit een garage gevlucht toen een techieker asbestremvoeringen aan het schoonblazen was met perslucht.

Heb die man opgebeld en een en ander ter sprake gebracht. Hij heeft toen geantwoord, letterlijk: "Ik doe dit al jaren en heb nog nooit iets van kanker gehad of gevoeld".

 

Nu, alle gekheid op een stokje. Dit onderwerp is al talloze malen ter sprake gekomen op alle FileMaker lists en discussiefora, in alle talen. De conclusie is altijd dezelfde, en FileMaker zegt dat ook: NEVER USE A RECOVERED FILE (en blijf weg van asbest).

Nog dit: verwar niet "This file has not been closed properly. FileMaker is doing a consistency check" met "This file is severely damaged and can not be opened. Use the recover command". Dat zijn twee verschillende dingen. Trouwens, dat verschil was precies het onderwerp van deze thread. Tot hiertoe is er ook nog geen duidelijk antwoord gekomen in de richting van Wim Decorte of in die van Jeff Hopkins.

 

HTH

[AvD]

Als we de oorspronkelijke posting lezen, dan zien we dat Eurotouring gelijk heeft en dus lang de kant van Hopkins staat (wat ik in dit geval ook doe en wat not done is sinds Hopkins uit de FileMaker-gemeenschap gebonjourd werd. Het is trouwens nog veel minder done van niet langs de kant van Wim Decorte te staan).

 

Dus:

- If(consistency check; we doen gewoon verder)

- If(file damaged; we doen een recovery en kieperen het origineel bestand in de prullenmand).

 

OK zo? Bedankt Eurotouring!

[Dr_Flash]

uit de FileMaker-gemeenschap gebonjourd werd.

 

En wie is dan de president van de FileMaker-gemeenschap die dit soort dingen bepaalt?

[Peter Wagemans]

Kort testje (Windows XP, FileMaker Pro 6.0v4):

 

Pake een file, maak een numeriek veld, auto enter serial "1".

Maak een script loopje dat records maakt.

Backup het bestand (eerst sluiten!).

 

Open de kopie, run de loop. Kill FileMaker na 5 seconden.

 

De eerste keer had FileMaker bij opstarten zelfs niet door dat het bestand niet goed was afgesloten!!!! 1 record bleef over. Seriele nummering in velddefinities stond nog mooi op 2.

Bij de 2de keer, ga FileMaker de foutmelding dat het bestand beschadigd was. Na recovery -> terug 1 record.

 

Conclusies: soms heb je (en FileMaker) zelfs niet door dat je bestand beschadigd is, en als je bestand beschadigd is en je herstelt het, kan het zijn dat je een heel pak kwijt bent.

 

Stel je het volgende scenario voor: Midden in een script loop die een set van records aan het updaten is, crasht FileMaker. Zelfs al wordt je bestand perfect hersteld (of staat het op een FileMaker Server en dan stelt zich dit probleem zelfs niet), is je bestand toch beschadigd. Niet fysisch, maar logisch.

 

Nu nog wat griezeliger. Stel, je bent een set van records aan het updaten in een script loop, en op dat ogenblik maak de FileMaker Server net een backup.

Een half uur later valt de stroom uit, en je zet netjes je backup terug.

Met een bestand dat logische fouten bevat...

test.fp5

[dannydv]

Ik voel me nu stukken blijer met FileMaker Pro

[Peter Wagemans]

Dit probleem stelt zich niet alleen met FileMaker.

De oplossing is om defensief te programmeren.

Flush Cache To Disk is een script stap die te weinig gebruikt wordt - ook door mezelf.

Verder kan je - en dat is veel programmeer-overhead - een soort van roll back functie inbouwen. Heel zware database systemen hebben dat standaard beschikbaar. Je maakt als het ware een kopie van de record set waarmee je werkt, en dan ga je aan de slag. Loopt er iets mis, wordt tijdens de herstel-procdure de roll back uitgevoerd.

 

Diezelfde zware systemen kunnen hele record sets locken, zodat niemand eraan kan terwijl je script draait, je kan de data-corruptie-paranoia heel ver drijven, gewone SQL systemen hebben deze feature zelfs nog niet...