Scheitern des Indexlaufs
Thomas Berger
ThB at gymel.com
Mi Feb 27 17:53:47 CET 2002
Lieber Herr Eversberg,
> > Herr Eversberg versprach damals (glaube ich mich zu
> > erinnern), das Problem fuer eine der kommenden
> > Versionen zu entschaerfen.
> >
> Hat er auch gemacht. Es gibt eine Option -B dafuer.
> Sagen Sie
> index ... -B25000
> und schauen Sie, was dann passiert. Default ist 8000 (nicht 10000).
Aber 10.000 bei PRESTO?
Leider ist es mir trotz aller Hilfestellungen noch nie
gelungen, durch einen Export (mit einer schematisch
nach .cPR umgewandelten .cPI) eine verlaessliche
Schaetzung fuer die "maximale Schluesselsumme"
einer gegebenen Datenbank zu bekommen.
Koennten Sie nicht in der Protok eine zweite Ausgabe
analog
max. Anzahl Schlüssel je Satz: 307 (= Satz# 198890)
spendieren, etwa
max. Schluesselspeicher: nnn Bytes (= Satz# nnn)
Aber auch das hilft eigentlich nicht viel, wenn die
Indexierung wegen dieses Problems zusammenbricht.
Weitere Vorschlaege:
- die Meldungen wg. begonnener und beendeter .ald-Dateien
auch in die PROTOK-Datei schreiben (das hilft bei der
Eingrenzung von Problemen, denn bei grossen Datenbanken
mag man nicht x-Stunden vor dem Monitor sitzen, um die
Meldungen zur Kenntnis zu nehmen)
- Warnmeldungen wegen zu vieler Schluessel und zu grosser
Schluesselsumme ausgeben (sind ja oft in dem Sinne
unproblematisch, dass INDEX.EXE diese Spezifikations-
ueberschreitungen partiell "ueberlebt")
- Abbruch bei Fehlern (derzeit haspelt INDEX.EXE ja munter
weiter, produziert Stundenlang II-Dateien der Laenge 0
bzw. sogar plausibler Laenge mit korrupten Eintraegen),
erst am Ende gibt es dann den "Speicherzuordnungsfehler".
viele Gruesse
Thomas Berger
Mehr Informationen über die Mailingliste Allegro