Mehrplatzbetrieb, kritische Aktionen

[Dr. Sibylle Koczian]

Lieber Herr Evers,
>
>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!
>
Klar. Aber Ihr Szenario beschreibt den schreibenden Zugriff, und den kann
ich leichter verhindern (wenn Sperren der Datenbank via Cockpit es nicht
bringt, dann kann ich ja zum Beispiel das Datenverzeichnis voruebergehend
auf Nur Lesen setzen). Ich bin inzwischen so weit, dass ich zumindest sicher
verhindern kann, dass zum Zeitpunkt des Sicherungs- oder
Reorganisations-Starts jemand mit der Datenbank verbunden ist. Das zweite
Problem ist aber: waehrend Sicherung oder Reorganisation laufen, faengt
anderswo jemand das Arbeiten an. Dass er schreibt, kann ich verhindern, ob
ich das Lesen verhindern kann, weiss ich im Moment noch 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 das bezieht sich auch auf den lesenden Zugriff, richtig? Hilft da
Sperren aus dem Cockpit vor Beginn des Indexierens? Wohl nicht, wenn ich
alles Vorherige richtig verdaut habe?

>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.
>
Das war das, was ich wissen wollte. Alle Update-Aufrufe werden aus eigenen
Batchdateien heraus gestartet.

Vielen Dank! Koczian
+----------------------------------------------------------------------------+
| Dr. Sibylle Koczian       Tel.: (0821) 598-5361                            |
| - Abt. Naturwiss. -                       -2404                            |
| Universitaetsbibliothek   Fax :           -5354                            |
| D-86135 Augsburg       e-mail : Sibylle.Koczian at Bibliothek.Uni-Augsburg.DE |
+----------------------------------------------------------------------------+