| Autor |
Beitrag |
bbfan
      
Beiträge: 164
|
Verfasst: Fr 09.10.09 19:50
Hallo Leute,
ich kopiere über meine Software eine Datenbank der Lagersoftware alle Minute auf ein Sicherungslaufwerk.
Die Datenbank ist dabei in Benutzung. Das Kopieren klappte 2 Tage gut.
Dann kam es zum Fehler: Datei im Zugriff.
Wenn meine Software mit CopyFile gerade dabei ist die DB zu kopieren, kann dann die Lagersoftware weiterhin daraufzugreifen? Öffnet CopyFile die Datei nur im Lesezugriff?
Oder anderes herum... wenn gerade die Lagersoftware etwas in die DB schreibt, kann dann CopyFile nicht zugreifen?
Wie verhält sich das genau?
Ich habe es in einer Testumgebung alles ausprobiert und konnte den Fehler nicht reproduzieren. Selbst wenn ich die DB mit Access geöffnet hatte, konnte ich diese Kopieren.
vg
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Fr 09.10.09 20:51
bbfan hat folgendes geschrieben : | | Oder anderes herum... wenn gerade die Lagersoftware etwas in die DB schreibt, kann dann CopyFile nicht zugreifen? |
Selbst wenn es funktionieren würde, halte ich es für eine schlechte Idee die Datenbank in genau dem Moment zu kopieren, in dem schreibend auf sie zugegriffen wird. Mit etwas Glück sind nur die gerade betroffenen Datensätze korrupt oder inkonsistent, mit etwas Pech die ganze Datenbank. Deswegen stellt sich für mich die Frage gar nicht. Und alle paar Minuten eine Sicherheitskopie anlegen, ich weiß ja nicht.
|
|
bbfan 
      
Beiträge: 164
|
Verfasst: Fr 09.10.09 21:28
Wie wäre die beste Lösung?
TrueImage etc. macht ja auch Kopien von geöffneten Dateien.
Meiner Meinung kann die Lagersoftware ungehindert in die DB schreiben, da ich nur ein Lesen Zugriff habe. Ein doppeltes oder mehrfaches Öffnen sollte ja möglich sein.
Weiss denn jemand genau wie CopyFile funktioniert? Öffnet der mit fmOpenRead?
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Sa 10.10.09 04:34
bbfan hat folgendes geschrieben : | | TrueImage etc. macht ja auch Kopien von geöffneten Dateien. |
Ja, aber die machen das irgendwie über einen Snapshot. Ich weiß auch nicht wie die sicherstellen, dass die daten konsistent sind. Eventuell ist da noch ein Treiber im Spiel.
| Zitat: | | Meiner Meinung kann die Lagersoftware ungehindert in die DB schreiben, da ich nur ein Lesen Zugriff habe. Ein doppeltes oder mehrfaches Öffnen sollte ja möglich sein. |
Das ist ja nicht das Problem. Stell dir vor über einen Query werden 1.000 Datensätze geändert. Und du kopierst jetzt die Datei mitten im Query. dann hast du eine nicht konsistente Datenbank. Der Query wurde abgesetzt, das hast du noch mitbekommen, aber er hat erst 500 Datensätze geändert, das hast du nicht mehr mit bekommen. wenn du jetzt die Sicherungskopie zurück spielst, dann hast du teilweise Datensätze, die in Ordnung sind und teilweise Datensätze, die die noch nicht bearbeitet wurde. Und schlimmstenfalls ist der gerade bearbeitet Datensatz ganz unbrauchbar. So eine Sicherheitskopie kannst du wegschmeißen.
Am sichersten ist es alle Datenbankverbindungen trennen und wenn das geschehen ist, die Datenbank sichern. Dazu kannst du die Datenbank sperren, so dass kein Zugriff mehr möglich ist. Wenn das Sperren von Seiten der Datenbank nicht möglich ist, setzt du in einer Tabelle einen Flag, dieser wird vor jedem Query geprüft und ist er gesetzt, wird der Query nicht ausgeführt. Dann wartest du bis alle laufenden Query fertig sind und kannst dann die Datenbank kopieren.
|
|
bbfan 
      
Beiträge: 164
|
Verfasst: Sa 10.10.09 08:43
Auf die Lagersoftware selbst habe ich keinen Einfluss.
Kann man denn sicher sein, dass max. die Kopie eventuell beschädigt ist und nie die org. Datei?
Ich habe einen weiteren Test gemacht. Datenbankgröße 130MB, es werden 10.0000 Datensätze verschlüsselt.
Während der Verschlüsselung wurde die DB 2 mal kopiert. Und es war tatsächlich so, dass die kopierte DB zum Teil verschlüsselt und unverschlüsselte Daten hatte.
Die DB selbst ist noch intakt und weisst keine Fehler auf. Sie zeigt "nur" einen Misch-Datenbestand an. Die DB selbst ist nicht defekt und lässt sich sauber öffenen.
Kann man davon ausgehen, dass die org. DB immer unangetastet bleibt?
|
|
Narses
      

Beiträge: 10185
Erhaltene Danke: 1261
W11x64
TP3 .. D7pro .. D10.2CE
|
Verfasst: Sa 10.10.09 09:51
Moin!
bbfan hat folgendes geschrieben : | | TrueImage etc. macht ja auch Kopien von geöffneten Dateien. |
Die benutzen den Schattenkopiedienst (hört sich das auch Deutsch komisch an...  ) von Windows, damit kann man das Dateisystem anweisen, einen temporären Snapshot zu machen, auf den man dann zugreift, auch wenn bereits die Anwendungen die Daten verändern. Soo genau kenne ich mich damit auch nicht aus, aber MSDN sicherlich.
cu
Narses
_________________ There are 10 types of people - those who understand binary and those who don´t.
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Sa 10.10.09 12:50
bbfan hat folgendes geschrieben : | | Kann man denn sicher sein, dass max. die Kopie eventuell beschädigt ist und nie die org. Datei? |
Es ging immer nur um die Kopie. Was willst du mit einer inkonsistenten Sicherungskopie?
| Zitat: | Ich habe einen weiteren Test gemacht. Datenbankgröße 130MB, es werden 10.0000 Datensätze verschlüsselt.
Während der Verschlüsselung wurde die DB 2 mal kopiert. Und es war tatsächlich so, dass die kopierte DB zum Teil verschlüsselt und unverschlüsselte Daten hatte. |
Siehst du. Was willst du mit so einer Sicherheitskopie?
| Zitat: | | Kann man davon ausgehen, dass die org. DB immer unangetastet bleibt? |
Denke schon.
|
|
bbfan 
      
Beiträge: 164
|
Verfasst: Sa 10.10.09 13:26
Hallo,
danke für euren Antworten.
ich habe jetzt folgenden Ablauf gewählt:
- progi legt lokale Kopie an
- dann MD5 Hash Vergleich zwischen Kopie und Org.
- wenn Vergleich OK dann bewege Kopie auf Serverlaufwerk
So hat man als erstes eine kurze Zugriffszeit auf die DB, da die Kopie erst einmal lokal angelegt wird.
Mit dem Hash Vergleich garantiert man, dass nur eine gültige Datei kopiert wird.
Was ist eure Meinung?
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Sa 10.10.09 13:59
Das bringt nichts. Was bringt dir der Hash einer inkonsistenten Datenbank? Und wenn sich was zwischen Kopie und Hash erstellen ändert, was machst du dann? Kopierst und hashed du so lange bis du endlich mal eine konsistente Kopie hast?
|
|
Tryer
      
Beiträge: 226
Erhaltene Danke: 7
|
Verfasst: Sa 10.10.09 14:08
Ich bin nicht sonderlich bewandert in der Arbeit mit Datenbanken, aber die regulären Zigriffsfunktionen auf den Datenbestand sollten doch die Konsistenz der Daten sicherstellen. Das können sie allerdings nur unter der Vorraussetzung das alle Zugriffe auf die Daten über diese Schnittstelle stattfinden.
- neue Datenbank anlegen auf welche nur Du zugreifst
- über reguläre Abfrage die Daten in diese neue Datenbank übernehmen.
- neue Datenbank schliessen und Datenbankdateien exklusiv öffnen damit wirklich nix mehr passieren kann
- sichern
Grüsse, Dirk
|
|
bbfan 
      
Beiträge: 164
|
Verfasst: Sa 10.10.09 15:09
@Tryer: ich habe keine Zugriff auf die DB per SQL etc. Kann nur extern Datei kopieren.
@Luckiy: Ja, letzendlich wird dadurch gewartet, bis die DB gerade nicht verwendet wird. Dies ist die meiste Zeit der Fall.
In dem Moment, wo sie nicht verwendet wird, stimmt der Hash und wird die Datei wird gesichert. In wie fern bring das nichts? Wie meinst du das?
|
|