Scheitern des Indexlaufs

[Thomas Berger]

Lieber Herr Herrmann, lieber Herr Deblon,

> > ich habe auf meinem privaten Rechner (Windows 2000
> > Professional) vorgestern eine Vollindexierung der Datenbank
> > "Index theologicus", die ja von uns in der UB Tuebingen her-
> > gestellt wird, vorgenommen. Die Indexierung brach an der
> > Stelle ab, an der Qrix aufgerufen werden soll. Es kam die
> > Meldung "Speicherzuordnungsfehler. COMMAND kann nicht
> > ausgefuehrt werden. System angehalten". Wahrscheinlich
> > handelt es sich um ein Speicherproblem auf der DOS-Ebene
> > (die Indexierung wird durch eine Batchdatei initiiert). Index.exe
> > und Qrix.exe stimmen mit den auf den dienstlichen Geraeten
> > verwendeten, neuesten Versionen ueberein.
...
 
> Wir hatten dasselbe Phänomen nach Umstieg auf WIN2000.
> Ueberraschenderweise hatte in unserm Fall Herr Berger mit seiner
> Vermutung voellig recht gehabt:
> 
> Evtl. produziert ein Satz zu viele Schluessel, dadurch
> dass viel mehr II-Dateien produziert werden steigt die
> Wahrscheinlichkeit, dass dieser Satz "am Ende" einer
> II-Datei bearbeitet wird, das gibt dann oft diese Meldung
> (erneuter Aufruf von qs.bat wird vermutlich scheitern,
> da die II-Dateien ab einer gewissen Nummer moeglicherweise
> korrupt sind).
> 
> (vgl. seine Antwort vom 31.01.02 auf meine Anfrage).
> 
> Dabei konnte Herr Berger garnicht wissen, was wir so alles in
> unsere Datensaetze 'reinpacken ...

Nee, aber die Fehlermeldung ist sehr characteristisch
fuer das Problem. Ich hatte im Herbst des oefteren (an
einer Datenbank von Frau Tews, spaeter dann an einer 
eigenen) daran herumlaboriert.

Gemein ist, dass das Problem ploetzlich auftreten kann
- wenn Sie mehr DOS Speicher haben als frueher
  (typischerweise wird es aber umso wahrscheinlicher,
  je weniger Speicher Sie haben)
- Wenn Sie einen Datensatz in der Datenbank loeschen
Der problematische Datensatz wird dann ploetzlich
virulent, obwohl er evtl. viele Jahre lang nicht
angefasst worden ist (selbst wenn die Indexparameter 
sich nicht geaendert haben).

Herr Eversberg versprach damals (glaube ich mich zu
erinnern), das Problem fuer eine der kommenden 
Versionen zu entschaerfen.

Hintergrund des Problems ist folgender: Ein Satz darf
nur 1000 (frueher 500) Schluessel produzieren, die
Gesamtlaenge darf 10.000 Bytes nicht ueberschreiten,
dabei zaehlen pro Schluessel einige Bytes fuer die
Satznummer bereits mit. Die von INDEX.EXE produzierten
II-Dateien werden bis zu einer Groesse von ca.
70.000 Zeichen im Speicher aufgebaut (die genaue
Groesse haengt von der .CFG, dem verfuegbaren
DOS-Speicher und dem "Fuellungsgrad" ab), wird eine
gewisse "Hochwassermarke" ueberschritten, beginnt
INDEX.EXE die naechste Datei. Das Limit von 10.000
Zeichen verstehe ich so, dass die "Hochwassermarke"
10.000 Bytes niedriger als der maximal zur Verfuegung
stehende Platz ist. Produziert ein Satz Schluessel
einer Gesamtgroesse von mehr als 10.000 Bytes (in
solchen Problemdatenbanken habe ich auch 15.000 bis
20.000 schon gesehen), passiert nichts boeses, wenn
dieser Satz durch Zufall bearbeitet wird, waehren
die aktuelle II-Datei noch sehr wenig gefuellt wird.
Einen Crash gibt es dann, wenn die Schluessel den zur
Verfuegung stehenden Platz sprengen, was immer dann
der Fall ist, wenn die II-Datei schon knapp bis zur 
"Hochwassermarke" gefuellt war und der fragliche
Satz mehr Bytes als erlaubt produziert.

Weil diese Position ja auch von der Reihenfolge und
Aufteilung aller anderen bisher abgearbeiteten Saetze
abhaengt, kann man beobachten, dass Loeschen von Satz
1 in der Datenbank die Indexierung bei Satz 50.000
zum crash bringt. Man kann auch beobachten, dass eine
Indexierung, die aus dem Cockpit heraus funktionierte,
in einer direkten DOS-Box nicht funktioniert und
umgekehrt. Man kann auch beobachten, dass das Kopieren
der Datenbank auf eine Netzwerkplatte das Problem 
verschwinden oder entstehen laesst (Win NT / NTFS 
liefert die Dateien immer reproduzierbar alphabetisch, 
Win '9x / FAT 16 bzw. FAT 32 liefern eine "zufaellige"
Reihenfolge, die mit der Anlegungsreihenfolge der
Dateien zu tun hat). Sie sehen, die Sache ist ziemlich
unappetitlich ...

viele Gruesse
Thomas Berger