AW: FWD: Ein GAU: schon wieder doppelte Satzschluessel (presto)

[Gerhard Englert]

Lieber Herr Eversberg,

danke fur Ihre Antwort. Ich versuche zwischen Ihrem Text zu beantworten.


> -----Ursprungliche Nachricht-----
> Von: Maiser at buch.biblio.etc.tu-bs.de
> [mailto:Maiser at buch.biblio.etc.tu-bs.de]Im Auftrag von Bernhard
> Eversberg
> Gesendet: Montag, 25. November 2002 11:12
> An: Diskussionsliste Allegro-C
> Betreff: Re: FWD: Ein GAU: schon wieder doppelte Satzschluessel (presto)
>
>
>
> Kollege Englert:
>
> > ein absolut brennendes Problem:
> >
> > Das Unmoegliche ist wieder passiert. Presto hat automatisch im
> > Abstand von
> > Sekunden bis Minuten!! den gleichen Satzschluessel vergeben. Da
> > wir jede
> > Nacht in ein SQL-System exportieren und ueber die #00 auf URLs
> > verlinken,
> > ist das der Super-GAU. Ein doppelter Satzschluessel ___darf___
> > einfach
> > nicht vorkommen.
> >
> Bitte nicht gleich solche masslosen Uebertreibungen! Ein
> Super-GAU waere das
> unrettbare Zerstoeren der ALD-Dateien, nichts anderes.

Rote Ohren... Da haben Sie ein wenig Recht. Ich drucke mich oft etwas zu
blumig aus. Auf Beamtendeutsch wurde es etwa so lauten: Wir haben ein
kleines technisches Problem, das die weitere Verwendung von Allegro an der
FAL sehr gefahrdet, wenn es nicht schnell und nachhaltig zufriedenstellend
gelost werden kann.
Die Daten sind davon zugegebenermassen nicht betroffen.
Wir schon. Insofern bezieht sich GAU eher auf unser
"Wir-sind-Allegrologen-in-Gefahr-Gefuhl"



> Nachfrage: standen die identischen Schluessen auch sofort beide
> im Index oder
> erst spaeter nach Neu-Indexierung?

Da gab es zwei Falle:

Die Fehler wurden immer erst beim Absturz des Imports der Daten in eine
SQL-Datenbank entdeckt:
Dann
1. Sie waren dann beim Nachsehen im Index zu finden. (Erste Mail ...presto)
4 Fehler in 4 Wochen
2. Sie waren nur mit einem Editor und Volltextsuche in der ALD zu finden
(Zweite Mail ... srch) Bisher ein einziger bekannter Fall. Dafur noch
allarmierender, weil wir 2 Tage gesucht haben, bis wir drauf gekommen sind,
wer/was da den SQL-Import so spurlos abgeschossen hat.
>
> Was passieren koennte: Jemand speichert einen neuen Satz, dabei
> bleibt's haengen
> bevor die Indexeintraege gespeichert werden koennen. Der Satz
> jedoch ist bereits
> gepsichert, das passiert vorher. Jemand gibt die TBL wieder frei,
> ohne erst neu
> zu indexieren, weil die Sache zunaechst nicht auffiel. noch
> jemand speichert
> abermals einen neuen Satz - der kriegt dann dieselbe Nummer, weil
> die Eintragung
> im Index ja noch nicht da ist.
>
An der TBL-Datei manipulieren (free) wir sehr selten. Das wurde einen Fehler
im Jahr erklaeren, nicht 4 in 4 Wochen. Es muss schon an irgendwelchen
subtileren Ursachen liegen.
Gefuhlmaessig auffallig ist, dass die Haufigkeit der doppelten #00-Eintrage
in eine Periode starker Netzproblem fallt. Lange Pausen beim Speichern, so
dass man schon meint, alles ist wieder mal abgesturzt, sind dafur das
auffaelligste Symptom.


> Ansonsten kann es an Cache-Funktionen von Novell oder Samba liegen, die
> faelschlich nicht deaktiviert wurden. So koennte jemandes PC beim
> Speichern eines
> Satzes einen nicht mehr aktuellen Indexabschnitt auswerten...

Gibt es einen genaueren Hinweis, welcher Cache da in Frage kommen konnte?
Ich nehme an, es geht um die auf dem PC. Dort aber greifen wir Laien nie
ein. Alles steht (glauben wir wenigstens) immer auf Default.

>
> Abhilfe: haendisch die Nummer des zweiten Satzes aendern, evtl.
> damit verknuepfte
> Untersaetze gleichfalls.

Tja, das machen wir schon, aber der Aufwand ist auf Dauer nicht zu vertreten
und den EDV-Leuten nicht zu erklaren.

Taglich:

Lebende Datenbank wegkopieren
Neu indexieren
Prufung uber den Index laufen lassen
Gggfls Dublette bereinigen
Export starten

puhh, genau hier setzt die Diskussion an, die fur Allegro so gefahrlich
wird.

>
> MfG B.E.
>


Mit freundlichen Gru?en

G. Englert
Informations- und Datenzentrum

Tel 0531-596 1534