Sniffer 2.02

[Matthias Evers]

Hallo Frau Koczian,

> ich bekomme bei der Untersuchung unserer Datenbank mit SNIFFER Ergebnisse,
> die mir in sich nicht konsistent zu sein scheinen, ausserdem
> Fehlermeldungen, bei denen ich nicht weiss, wie ich die Fehler beheben kann.
> 
> Inkonsistenz: die Pruefung der Datendateien meldet manchmal auffaellig
> viele Datensaetze als gesperrt, Pruefung der Satztabelle gleich
> anschliessend nur ganz wenige. 

Die Pruefung der Satztabelle checkt nur die aktuellen Datensaetze in 
der Datenbank (die, die in der TBL verzeichnet sind). Die Pruefung 
einer Datendatei checkt hingegen die Datendatei, OHNE sich um die 
Satztabelle zu kuemmern. 
Hierzu ein krasses Beispiel:
Sie haben eine einwandfreie Datenbank mit den Datendateien kat_1, 
kat_2 und kat_5. Irgendjemand kopiert eine defekte Datei 
kat_4 die ueberhaupt nicht zur Datenbank gehoert mit in dieses 
Verzeichnis. Checken Sie das Verzeichnis (die Datenbank) via 
Satztabellenpruefung, so ist alles okay, denn die kat_4 gehoert ja 
nicht dazu. Checken sie die kat_4 alleine durch, so erzeugt sie 
jede Menge Fehler.
...und indexieren Sie neu (inkl. kat_4), dann haben sie "neue" 
Datensaetze ohne eigene Eingabe in Ihrer Datenbank.

> Einzelfallpruefung in der Datenbank ergibt
> bei so vielen lt. Datendatei-Pruefung gesperrten Saetzen keinen derartigen
> Befund, dass es nicht mehr durch das normale Arbeiten mehrerer Leute zu
> erklaeren ist (wenn z.B. zehn Leute schreibend auf die Datenbank zugreifen,
> dann duerften doch hoechstens zehn Saetze bei der Pruefung gesperrt und
> hinterher beim Nachsehen entsperrt sein - jedenfalls nicht
> Groessenordnungen von 1-200?). 

Bei WinNT habe ich es schon erlebt, dass ploetzlich ab einem bestimmten 
Punkt nur noch gesperrte Datensaetze bei der Kontrolle gemeldet 
wurden. Leider laesst sich das nicht reproduzieren und ist von dem 
freien Arbeitsspeicher in der DOS-Box abhaengig. Man kann relativ 
einfach sehen, ob man so einem Phantom aufgesessen ist, denn die 
gesperrten Saetze folgen in der Datenbank aufeinander (nicht unbedingt 
die Satznummern, sondern ihre Lage in der Datei).

> Fehlerbehebung unklar: "Fehlertyp: Satzlaenge / Datenschrott", keine
> Satznummer angegeben, und bei den meisten Saetzen dieser Art auch kein
> Inhalt (der angezeigte Teil des Satzes besteht im Wesentlichen aus
> ASCII-Nullen und Zeilenvorschueben, endet mit 
> 09 00 0D 0A).

Nur durch Neuindexieren laesst sich dies beseitigen. Danach darf das 
nicht mehr auftreten.

> Oder: Satznummer zu hoch, Kennbyte: 1, und der angezeigte
> Teil des Satzes sieht genauso aus. Wie kriegt man denn sowas aus der
> Datenbank heraus?

Jeder Datensatz hat eine Satznummer, die sich aus der Position in der 
Satztabelle ergibt. Am Anfang des Datensatzes selbst ist diese Nummer 
zusaetzlich nochmals gespeichert. Sniffer checkt, ob die beiden 
Satznummern uebereinstimmen. Abhilfe kann ebenfalls nur durch 
Neuindexieren erfolgen. Der Fehler darf danach nicht mehr auftreten.

Bis dann,
Matthias Evers
--
Matthias Evers             Universitaetsbibliothek
M.Evers at tu-bs.de           Pockelsstr. 13
                           38106 Braunschweig
                           Tel:(0531)391-5032  FAX: -5836