Datenbank unbemerkt defekt

Hallo!

Heute habe ich eine unschöne Entdeckung gemacht. Meine wichtigste DT Datenbank ist defekt und zeigt mit bei den meisten Dateien die älter als ca. 1 Jahr sind an, dass die Datei nicht vorhanden ist.

Starten der Reparatur hat über 900 fehlende Dateien gefunden. Allerdings hat das nichts an der Lage geändert. Daraufhin habe ich versucht ein Backup mittels Arq zurück zu spielen. Dabei viel mir auf, dass das letzte intakte Backup ohne dieses Problem aus März ist. Alles danach ist defekt.

Glücklicherweise konnte ich das Problem beheben, indem ich die Datenbank aus dem Syncstore neu importiert habe. Danach war alles wieder gut. (Habe ich Nachteile wenn die Datenbank aus dem Syncstore kommt?)

Der “Neuaufbau” Button in der aktuellen DT3 Beta hat keinerlei Funktion. Ich kann auch nicht direkt die Beta für den Fehler verantwortlich machen, da der Fehler in den Backups schon vor DT3 aufgetreten ist.

Meine Daten sind wieder da, daher erstmal alles gut. Allerdings frage ich mich, wie sowas in Zukunft verhindert werden kann. Wäre es nicht hilfreich wenn DT regelmäßig eine Überprüfung starten würde die auf ein Problem hinweisen würde? Dann hätte ich bereits im März das letzte funktionierende Backup nutzen können, statt Monate zu verlieren…

Oder muss ich schlicht selber dran denken regelmäßig die Datenbank überprüfen zu lassen?
Und die Sync Funktion ist ja laut diverser Hinweise auch kein Backup :wink:

Danke für ein paar Hinweise dazu…

Gruß

Michél

2 Likes

Das ist richtig. Sync ist kein Backup, auch wenn es manchmal im Notfall verwendet werden kann.

Wie bei Backups liegt die Datenbankpflege in der Hand des Einzelnen. Schauen Sie sich diesen Blog-Post über die Gesundheit der Datenbank an:

(Übersetzt mit https://deepl.com)

Hallo Michél,

nutzt Du Timebackup, um Deine Daten vom Mac zu sichern? In dem Fall werden Deine Datenbanken ja mit gesichert. Hilfreich ist auch, dass das Protokollfenster automatisch anzuzeigen, sollte etwas komisch sein. Hier gehst Du zu Fenster-Protokoll - und ganz unten aktivierst Du “Protokoll automatisch anzeigen”. Weiterhin ist es natürlich sicherer, wenn beim SyncStore das Häkchen “Hochgeladene Objekte prüfen” aktiviert ist - auch unter IOS.

Sollte dann eine Inkonsistenz in Deinen Daten sein, meldet sich das Prokollfenster - somit hast Du gleich eine Warnung und kannst Deine Datenbanken entweder reparieren oder ggf. neu indizieren lassen.

Hoffe, das hilft Dir weiter.

Viele Grüße,

Steffi

1 Like

Hallo zusammen!

Danke für die Hinweise!

Natürlich läuft auch Time Machine im Hintergrund mit. Das bringt mir aber alles nichts, wenn der Fehler in der Datenbank erst nach Wochen bemerkt wird. Je nach Lage kann die Aufarbeitung von mehreren Wochen extrem zeitaufwendig sein. Das Protokollfenster nutze ich natürlich auch bereits, allerdings ist mir dort nichts aufgefallen. Das Verschwinden von über 900 Dokumenten ist dort jedenfalls nicht ersichtlich gewesen.

Wäre es nicht sinnvoll, wen Devonthink automatisch beispielsweise einmal wöchentlich die Datenbank prüft? Oder kann ich das gegebenenfalls irgendwie automatisieren? Das ist ja wie mit einem Backup… Wenn man es manuell machen muss, vergisst man es. Daher nutzen wir ja auch Tools wie Arq oder Time Machine. Bei der Konsitenzprüfung der Datenbank bin ich dann aber offensichtlich wieder von mir selbst abhängig…

Vielleicht wäre das ein nettes Feature für DT3…

Warum läuft Verify & Repair nicht standardmässig im Hintergrund, und benachrichtigt den User über Fehler in der Datenbank? Ich würde so eine automatisierte Funktion auch begrüssen (ähnlich wie das z.B. bei Backup-Programmen auch passiert, um die gesicherten Dateien zu prüfen).

das dürfte wohl die Performance signifikant verschlechtern. Besser wäre da schon ein Scheduler, der je nach Wunschzeitraum, einen Check der DB´s durchführt.

2 Likes

Der Meinung bin ich nicht. Feststellen lässt sich das durchaus recht einfach. So bin ich zumindest damals auf meine Sync-Problematik gekommen.

Rechte Maustaste auf die Datenbank - Informationen und dann mal einen Screenshot von beiden Informationsfenstern gemacht. Da war dann der eine und der andere Rechner unterschiedlich. Wenn man da nun bei der Synchronisation eine Überprüfung einbaut ob beide Statistiken identisch sind, wäre glaube ich schon mal die halbe Miete. Und falls das unterschiedlich ist, obwohl keine weiteren Dateien im Upload/Download gewesen sind, dass das Programm dann Alarm schlägt und warnt das die beiden Datenbanken nicht mehr identisch sind. Somit kann man vielleicht auch mehr auf die Fehlersuche eingehen wann und warum das ab und zu auftritt.

Abhilfe schafft auf jedenfall folgendes Workaround:

1.) In den Einstellungen Sync den Synchronisationsort auswählen
2.) dann die betroffene Datenbank auf beiden Rechnern den Haken entfernen
3.) Dann den rechte Maustaste auf die Datenbank machen (in den Sync-Einstellungen!!!) und auf Datenbank leeren gehen, die Datenbank wird im Anschluss im Sync-Ort gelöscht (Dropbox, Webdav, whatever) - muss nur auf einem Rechner gemacht werden :wink:
4.) ist das leeren Erfolgreich gewesen (siehe Protokoll), dann
5.) kann mit Rechner Nr. 1 die Synchronisation im Sync-Ort wieder gestartet werden, wenn der Rechner Nr. 1 fertig ist, dann
6.) kann der Rechner Nr. 2 wieder Synchronisiert werden, im Anschluss sind dann beide Datenbanken wieder identisch (Check Datenbank-Informationen - müssten das gleiche Ergebnis liefern)

Auch wenn das jetzt nicht genau zu dem Thema von darkbrain85 passt, aber zumindest etwas in die Richtung für HaubenTaucher.

Das was darkbrain85 beschreibt ist mir auch schon passiert, und ich konnte das auch schnell beheben weil ich es gleich in der Sekunde bemerkt hatte.

Und zwar ist mir das passiert, als ich eine große Menge an Dateien von einer Datenbank in die andere Datenbank geschoben habe. Devonthink hat mir die Daten dann schon in der neuen Datenbank angezeigt, und ich habe dann die alte Datenbank ab diesem Zeitpunkt gelöscht. Und da war das Chaos dann… Devonthink hat mir den Kopiervorgang optisch als fertig angezeigt, aber im Aktivitätsprotokoll liefen noch die Kopiervorgänge als ich die alte Datenbank gelöscht habe, plötzlich konnte er nichts mehr kopieren und ich hatte in der neuen Datenbank nur noch den Dateinamen und einen DT-Link zu der Datei, welche aber in der Datenbank fehlt, weil diese nicht mehr kopiert werden konnte.

Zum glück katte ich Backups am Start, konnte also beide Datenbanken wieder zurücksetzen, und den Verschiebevorgang erneut starten. Dann habe ich das Aktivitätsprotokoll im Auge behalten ob nun wirklich alle Verschiebe-Vorgänge abgeschlossen waren, und danach dann die Ursprungs-Datenbank gelöscht. Hier fehlt leider ebenso eine Art ALARM, das der Kopiervorgang noch nicht abgeschlossen ist, und daher die Datenbank nicht gelöscht werden kann. (Nur mal so am Rande für die Entwickler!!!)

Ich hoffe ich konnte euch etwas beschreiben was ich schon erlebt habe. Vielleicht können auch die Entwickler hier und da noch ein paar Ansätze umsetzen.

Dies klingt nach einem Bug der Version 3.0, da erst diese im Hintergrund verschiebt. Beta 4 sollte dies korrigieren.

1 Like