Aufbau großer Datenbanken
Thomas Berger
ThB at gymel.com
Di Jan 14 15:21:47 CET 2003
Liebe Frau Koczian,
> dazu noch Daten. Immerhin sieht es aus, als sei Index glatt durchgelaufen:
> protok und protoq enden regulaer, es gibt keine ii-Dateien mehr, sondern
> eine .adx-Datei.
>
> Zwei Fragen an dieser Stelle: Der qrix-Aufruf am Ende von protok endet mit
> ... -Pc:\allegro a -x9999
> Was bedeutet dieses a? Es steht wirklich so da, nicht -a.
das ist Schmutz, der steht da schon immer (naja, zumindest
seit 199x mit x ziemlich klein).
> Und am Ende von protoq erscheint der Index-Aufruf für den zweiten
> Durchlauf; allerdings gibt es tatsaechlich keine Stammsaetze in der
> Datenbank (wohl aber die entsprechenden Befehle in den Indexparametern).
> Verewigt sich dieser zweite Durchlauf in einem Protokoll, und in welchem?
> Im Handbuch habe ich nichts dazu gefunden.
das ist der "second run" index -fa, der "verewigt" sich
durch einen Datummsstempel an der Datei protok und evtl.
ein bis zwei zusaetzlichen Zeilen dortselbst:
7 relations expanded
299 not expanded
> > > Die Groesse der bei Index entstehenden Zwischendateien richtet sich nach
> > > dem verfuegbaren Arbeitsspeicher und ist nicht einstellbar, habe ich das
> > > richtig verstanden?
> >
> >Ja. Sind diese aber sehr klein, waere das schlimm. Ca. 70-80kB sollten
> >sie normalerweise haben.
>
> Wenn ich die Groesse der .adx-Datei durch die Anzahl der ii-Dateien teile
> (aus protok), dann sieht es aus, als seien sie tatsaechlich kleiner gewesen
> (55 kB). Aber stimmt diese Rechnung?
Nein. Aber immerhin waren sie >= 55kB, was eher beruhigend ist.
> >Das nicht, aber es koennte zu grosse Datensaetze geben oder zu
> >grosse Kategorien (IMPORT hat hier m.W. andere Speicherlimits).
>
> Was waere da die Folge? Gehe ich recht in der Annahme, dass ein Vergleich
> der letzten Saetze von Ausgangs- und .alg-Datei am schnellsten klaert, ob
> hier etwas passiert ist? Die Batch-Datei kann jedenfalls nicht mit IMPORT
> abgebrochen sein, die beiden Importe kommen vor INDEX.
D.h. Sie benutzen globale Manipulation beim UPDATE,
um die bereits indexierten Titelsaetze um die Lokalinformationen
zu ergaenzen? Und die Lokalinformation kommt ggfls. aus mehreren(!),
bereits umgewandelten und in der .alg-Datei vorhandenen
Lokalsaetzen und kumuliert?
Folgende Moeglichkeiten fallen mir ein:
- Saetze werden zu gross beim kumulieren bzw. erzeugen
irgendwann zuviele Schluessel
(Testweise, falls moeglich: Datenbank mit - at 1 aufbauen,
dann update, dann neuindexieren mit - at 1 und - at 2:
ist a) viel viel schneller und b) kracht es dann evtl.
erst bei der zweiten Indexierung, da haette man dann
etwas bewiesen)
- Anwendervariable der Globalen Manipulation sind in
Konflikt mit denen aus der .api
- Unsauberkeiten in der globalen Manipulation / .api fuehren
zu nicht geloeschten Anwendervariablen, die sich zu einem
Speicherproblem aufschaukeln.
viele Gruesse
Thomas Berger
Mehr Informationen über die Mailingliste Allegro