Datenbankintegrit"at

[Thomas Berger]

Heinrich Allers wrote:
> 
> Robert Fischer Berlin <rfb at mail.blinx.de> schrieb
> am Thu, 07 Jan 1999 13:14:56 +0100 (MET) unter dem
> "Subject: Re: Aurora-Editor + Edit von ALD":
> 
> > ...
> > Im Grunde gehoert dies in das von mir gelegentlich
> > angesprochene Thema des Datenbank-TUEVs, der m.E. alle
> > Jahre fuer aktive DBs noetig ist und der eine weitreichende
> > Fehlerdiagnose und Fehlerbeseitigung beinhaltet.
> 
> Das ist eine starke Aussage (von der ich denke, daß auch die
> Entwicklungsabteilung dazu noch ein Wort sagt).

Dieser Aussage moechte ich mich aber anschliessen:

Es ist fuer viele Anwender eine ziemliche Erleichterung,
wenn nach ein paar Jahren ein allegrologe vorbeischneit,
diverse Tests ausfuehrt und zum Schluss sagen kann:
100% in Ordnung, nur weiter so.

Allegro ist so robust, dass ich Faelle erlebt habe, wo
durch Serverabstuerze die Datenbank stark zerstoert war,
aber _jahrelang_ noch weiter hineinkatalogisiert werden
konnte.

 
> Als Betreuer von vielen Anwendungen paßt sie mir nicht, weil
> ich meinen "Subanwendern" ein Werkzeug anbiete, das per se
> und schon im Normalbetrieb Fehlerchen ins Produkt einstreut,
> die man dann ab und zu mal ausjäten muß.
> 
> Ich sage bisher immer den Anwendern, daß Allegro prinzipiell
> ordentlich arbeitet, und daß es externe Gründe hat, wenn eine
> Datenbank doch einmal so korrumpiert ist, daß eine
> Reorganisation keine Abhilfe schafft: Stromausfälle,
> ungepflegte Festplatte, Bedienungsfehler (z.B. mit Word 'ne
> .ALD-Datei öffnen).
> 
> Ist dieser Optimismus, was Allegro angeht, falsch?

Nein. Er sollte aber durch den Pessimismus ergaenzt werden,
dass im Laufe der Jahre die Wahrscheinlichkeit eines solchen
externen Ereignisses ziemlich hoch ist. [NB: Es hat natuerlich
durchaus schon internen Fehlfunktionen der Allegro-Module 
gegeben, die fehlerhafte Daten produziert haben]

In solchen Situationen sollte ein Systembetreuer in der Tat 
Werkzeuge haben, die ihm helfen. Aus meiner Praxis weiss ich 
aber, dass man zunaechst sehr umfassend und geduldig mittels 
Interviews die Historie von Fehlern ergruenden muss, bevor
man eingreifen kann: Jeder Fall erfordert seine eigene
Reparaturstrategie, Werkzeuge koennen hier nur helfen und 
sind nicht zu verwechseln mit einem Knopfdruck-
Datenbankanalysator und -reintegrator.

Fuer Anwender sollte es immer heissen: "Finger weg" sobald
etwas unerklaerliches passiert. Fast alle nicht 100%
erfolgreiche Reparaturen haben ihren Grund darin gehabt,
dass Anwender zunaechst selbst repariert haben und damit
eine starke verschlimmerung erreichten, stellenweise ohne
es direkt zu bemerken.

 
> > Ein weiteres, gut programmiertes Tool
> 
> Über SNIFFER hinaus?
> 

ich biete: sneezer.pl (nunja, Tool ja, weiteres ja, gut programmiert
naja). Scherz beiseite: SNIFFER kann nur Datenbanken untersuchen,
d.h. .cLD-Dateien und .TBL-Dateien auf falsche Zeichen und
Falsche Kategorien untersuchen. Es ist ziemlich ungeeignet
in dem Fall, wo nur noch Fragmente vorhanden sind oder 
Binaerschrott in Datenbanken eingesprengselt wurde. Hier gibt
es in einigen Fallen nur die trivialste aller Information: Wenn 
SNIFFER crasht, ist wohl etwas wirklich nicht in Ordnung. In
anderen Faellen merkt SNIFFER garnix und andere Module crashen.


> > Ich weis schon, dass sich das meiste durch Parametrierung loesen laesst.
> 
> Ja, so ist's! Welcher Anwender übernimmt's also, erst einmal
> einige der hier genannten Prüfroutinen zu parametrieren, um
> sie dann im großen Kreis anzubieten oder gar in die
> offizielle Allegro-Distribution aufzunehmen? Das
> Parametrieren allein wäre ja nicht das Schlimmste, das hat
> der eine oder andere Anwender ja schon für seine Zwecke
> gemacht: Die Frage ist, wer sich die Mühe macht, die
> Parametrierung derart allgemein und einstellbar zu gestalten,
> daß sie für einen größeren Kreis von Anwendern übernehmbar
> ist, ohne selbst erst wieder anfangen zu müssen,
> Restparametrierungsarbeit zu leisten?

Halte ich fuer unrealistisch.
1.) viele Inkonsistenzen lassen sich auch online aufdecken,
    durch nachschauen in den richtigen Randbereichen der
    Register, durch Einstellen von Haeufigkeitsschwellen
    etc.
2.) Was darueberhinausgeht, erfordert vermutlich starke
    individuelle Anpassungen, hier hat Herr Allers recht.
3.) Konsistenztests sollten schon beim Design der Anwendung
    mitbedacht und mitprogrammiert werden, hier hat Herr
    Fischer recht.
4.) Die besten Tests sind unabhaengige, d.h. es sollten auf
    moeglichst primitive Art Rohdaten aus Allegro exportiert
    und mit externen Mitteln weiterverarbeitet werden.
    
 
> > Ein BUG-Info-Pool, in dem man auch in Bezug auf Bugfixes
> > nachlesen kann, waere auch nicht schlecht.
> 
> So etwas gab es mal oder gibt es noch, von Thomas Berger
> gepflegt, war es damals zumindest gepflegt.

Wurde am 31.7.1996 eingestellt.


> > und
> > wuerde zu einer, wenn auch kleinen Entlastung der Braunschweiger stets
> > geduldig am Telefon beratenden Fachleute fuehren.
> 
> Ruft dort etwa noch mit derartigen Problemen jemand an, der
> E-Post-Anschluß hat?

Mir geht es so: Gerade wenn mir die Nerven durchbrennen, greife 
ich zum Telefon...


viele Gruesse
Thomas