Mehrplatzbetrieb, kritische Aktionen

[Matthias Evers]

Hallo Frau Koczian,

> Bis jetzt ist die Datenbank winzig, so dass schlichtes Kopieren auf eine
> Diskette es noch tut. Solange das Sichern verweigert und nicht kommentarlos
> falsch gemacht wird (incl. Vermurksen der Originaldaten), geht's ja noch ...
> muss ich also mal mit irgendwelchen Spieldaten ausprobieren.

Denken Sie sich einfach mal ne grosse Datenbank mit ca. 300 MB (Index, 
STL, TBL und etwa 20 Datendateien). Jetzt faengt Ihre Sicherung an und 
sichert z.B. die Indexdatei, die TBL und zwei Datendateien (in 
welcher Reihenfolge weiss man ja nie). DANACH gibt ein Nutzer einen 
neuen Datensatz ein, d.h., dass Indexdatei und TBL GARANTIERT anders 
aussehen. Die zugehoerende Datendatei ist dummerweise eine, die erst 
danach auf s Band kommt, entspricht also bereits dem neuesten Stand. 
Damit haben Sie auf Ihrem Sicherungsband eine inkonsistente Version, 
die Sie aber immerhin per Neuindexierung wieder in Ordnung bekommen. 
Steckte der neu eingegebene Datensatz aber in einer der beiden 
bereits gesicherten Datendateien, so ist er auch per Neuindexierung 
nicht wieder herstellbar.
Bei kleineren Dateien ist man natuerlich leicht in Versuchung die 
Datensicherung mal eben zwischendurch zu machen "wird schon keiner 
was eingeben in der Zeit", aber sicher ist das nicht!

> >> - Was passiert eigentlich bei Verstoessen? 
> Nein, Sicherung oder INDEX laeuft, obwohl gerade jemand an der Datenbank
> arbeitet.

Sicherung s.o., Index zieht dem Nutzer die Fuesse weg, da es als erste 
Aktion den Index loescht. Kommt es da nicht dran, so ist das Ergebnis 
entweder unbrauchbar, oder der neue Index als NEWINX in dem 
Datenbankverzeichnis drin. In keinem Fall wuerde ich eine 
Neuindexierung bei laufendem Betrieb versuchen, das ist wirklich 
keine gute Idee.

> Und gleich noch ein Zusatzproblem: UPDATE soll ja im Mehrplatzbetrieb
> laufen, auch wenn an der Datenbank gearbeitet wird, und ich glaube doch,
> auch gleichzeitige UPDATE-Laeufe von verschiedenen lokalen PC's aus sollten
> kein Problem geben. Jetzt hab' ich aber schon zum dritten Mal mehrfach
> vergebene Nummern aus cg/ci erwischt, wie kann denn das passieren? 

Update kann in der Tat problemlos von mehreren Rechnern aus 
gleichzeitig laufen. Warum es bei Ihnen zu doppelten Nummern gekommen 
ist, entzieht sich meiner Kenntnis. Fragen Sie mal Herrn Eversberg 
dazu, evtl. weiss er was dazu. Es muesste ja schliesslich bei mehreren 
Nutzern aufgetreten sein, da fast alle inzwischen ein Netzwerk haben.

> Wie ist das mit -S? In den UPDATE-Befehlen kommt das mit Sicherheit nicht
> vor, in cp.bat bin ich auch zu 99% sicher, aber eben doch nur zu 99%. Was
> geht denn vor?

Das Cockpit startet eine ccc.bat an, in der die 
Voreinstellungen uebergeben werden. Damit ist es voellig unabhaengig von 
Ihrem UPDATE Befehl. Genau betrachtet erstellt Cockpit nur eine 
Batchdatei, die abgearbeitet wird, naemlich die ccc.bat.
 Waehlen Sie im Cockpit den Menuepunkt UPDATE an, so gilt Ihre 
Einstellung in der cp.bat incl. evtl. vorhandenem -S. 
Waehlen Sie allerdings im Cockpit eine "eigene Routine", hinter der 
Ihre eigene Batchdatei steckt, so greift ein in cp.bat vorhandenes -S 
nicht, denn in Ihrer Batchdatei ist ja, wie Sie schreiben, im Update 
Aufruf KEIN -S vorhanden. Die ccc.bat enthaelt in diesem Fall ja nur 
einen Verweis auf Ihre Batchdatei
"call myupdate.bat"
oder so aehnlich. Den Schalter -S kriegt das Cockpit nicht in Ihre 
Batchdatei rein.

Beste Gruesse,
Matthias Evers
*****************************************************************
    Matthias Evers               Universitaetsbibliothek
    Netzwerkmanager              Pockelsstr. 13
                                 38106 Braunschweig
Email: M.Evers at tu-bs.de          Tel:(0531)391-5032  FAX: -5836
*****************************************************************