ERROR database disk image is malformed

[dummzeuch]

Auf die Windows Datenträgerprüfung würde ich mich nicht verlassen. Selbst wenn Windows nichts findet, kann der Datenträger einen defekten Sektor haben, der in der Datei verwendete wird. Einfacher Test dafür: Die Datei kopieren.

[Peter-Pascal]

danke für die Antwort
Die Datei habe ich kopiert und lief anscheinend problemlos.

[jobo]

Ich habe noch nie mit Reparaturprogrammen für SQLite gearbeitet. Macht man ja nicht ohne Not. Ich setze das nur für Tests usw. ein. Da kann ich nichts Brauchbares liefern. Ein Hilfstool wurde schon genannt. Angeblich gibt es ja einige. Wenn die Datei selbst kopierbar ist, würden Nerds vielleicht mit dem Hexeditor dran gehen. Wenn das Problem halbwegs reproduzierbar bei einem Import auftritt, alles immer weiter annähern indem nur noch diese Tabellen überhaupt in der DB angelegt / genutzt werden, dann die Importmenge immer halbieren oder Sleeps einbauen zwischen den Inserts oder oder.
Wenn es eh Importdaten sind (und Backups existieren) würde ich mir die Mühe auch gar nicht machen, Daten aus der defekten Datei zu rekonsturieren.
Ich bleibe bei dem Punkt: Woran liegt es?

Falls SQLite wirklich ein Problem mit massiven Inserts hat, würde ich es nicht mehr anpacken. Habe ich aber noch nicht festgestellt bis jetzt.

Neulich habe ich einen Rechner aufgesetzt, der nur für ca. halbe Tage lief und dann sehr merkwürdiges Verhalten zeigte. Diagnose aus den Fehlern: SSD defekt (der gesamte Rechner war aus Neuteilen aufgebaut). Beim Einbau der Ersatz-SSD (M.2) habe ich dann festgestellt, dass die mit einer zu langen Schraube fixiert war, die vor dem Fixieren anschlug. Und das hat vermutlich das Problem verursachte, die M.2 SSD war nur lose verbunden, Temperaturschwankungen reichen dann vielleicht schon für diese Effekte.

Wie gesagt, wiederhole die Problemfunktion mit wechselnden Parametern, z.B. anderer Rechner usw. und finde heraus, woran es liegt.

Was mir noch einfällt: SQLite erlaubt das Attachen von "fremden" DB Files (Datenbanken) an eine "Haupt"- DB. GGf kommt man darüber etwas näher an die kritschen Punkte einer defekten SQLite DB. Wie gesagt, das würde ich nur untersuchen, wenn ich kein Backup habe und keine andere Wiederherstellungsmöglichkeit. (Bliebe noch die Frage, ob es an speziellen Daten liegt, aber das wäre schon sehr schräg und würde auch bei dem Test oben irgendwann auffallen- Importmenge immer halbieren)

[Peter-Pascal]

Hallo Jo,
Du hast Dir wirklich sehr viel Mühe gegeben, mir zu helfen. Vielen Dank dafür. Gerade weil es viele Vorschläge sind, komme ich der Sache näher.

Offensichtlich gibt es zwei Tabellen, die defekt sind. Es sind Master-Detail. Ich habe mir zwei Tools aus dem Internet geladen und zusätzlich noch das Delphi hauseigene Tool. Bei allen immer das gleiche Ergebnis: Es werden ca. 600 Datensätze geladen und auch angezeigt, aber dann bringen alle Tool disk image is malformed und lesen nicht mehr weiter. Offensichtlich hängt der Fehler mit dem Disk I/O Error zusammen. Mögicherweise zeigen beide Fehler einen HD defekt. Es fehlen noch ca. 200 Datensätze.

Die Daten in der DB sind nicht so wichtig, ich möchte nur verstehen und wissen, wie ich diesen Fehler vermeiden kann und was ich tun kann. Falls mal jemand anders mein Programm nutzt, möchte ich eine Lösung parat haben. Und sei es, dass ich regelmäßige Backups einbaue.

Ob es an den Daten liegt, kann ich nicht ausschließen. Es wird eine CSV Datei mit Bankumsätzen eingelesen. Starmoney hat die CSV erstellt. Interessant ist nur, das es mal klappt und mal nicht.

Beim Einlesen der CSV habe ich eine eigene Routine, die die Daten in die DB schreibt. Beim kopieren von einer DB in einer anderen DB nutze ich FDTableZiel.CopyDataSet(FDTableQuelle, [coStructure, coRestart, coAppend]); Bei beiden Vorgänge erscheint der Fehler.

Interessant ist nur, von 10 mal einlesen, geht es 2 mal schief.

Ich werd mich wohl intensiv mit Backups beschäftigen und eine Serie von Backups anlegen, auf die dann Zugegriffen werden kann.

Danke und Gruß Peter

[himitsu]

Wenn es ein Hardwaredefekt ist, dann bringt es nicht viel, wenn die Backups auch auf der selben Platte liegen,

außer diese Backups werden auch ab und an nochmal woanders hin kopiert/gesichert ... nur neue Backup-Dateien kopieren (veränderte Dateien, welche nun defekt sein könnten, in dem anderen Backup auch zu überschreiben, wäre etwas kontraproduktiv)

[Peter-Pascal]

Da hast Du Recht Himitsu,

ich hoffe auch, dass die Platte keinen Defekt hat und werde eine DB auf eine andere Platte legen und dort testen. Im PC ist noch eine SSD. Bislang hatte ich bei der SATA-Platte (glaube so hießt die) keine Fehlermeldungen bekommen.

Bin gespannt, ob da die gleichen Probleme auftauchen. Wenn es das gleiche ist, dann kann nur mein Programm das Problem sein, und es bewahrheitet sich wieder: Das Problem sitzt meistens vor der Tastatur.

[Delphi.Narium]

CSV kracht "unmotiviert" beim Einlesen in Datenbank.

Da könnte eventuell mal ein "einfaches" Öffnen mit Excel oder OpenOffice, ... helfen.

Ist die CSV "schrottig", wird das Officeprogramm auch Fehler melden oder die Daten irgendwie, aber nicht mehr der CSV-Struktur entsprechend, anzeigen.
Mit ein bisserl Glück kannst Du dann sogar erkennen, bei welcher Zeile, welchem Datensatz, etwas nicht so ganz in Ordnung ist.

So kannst Du quasi eine Gegenprobe machen, ob das Problem eher auf der Seite der Quelldaten oder eher bei SQLite liegt.

Befremdlich ist allerdings eher dashier:

Zitat:

Interessant ist nur, von 10 mal einlesen, geht es 2 mal schief.

Sowas lässt darauf schließen, dass die Hardware anfängt defekt zu werden. Sie ist noch nicht defekt genug, damit Prüfsoftware den Defekt erkennt, aber schon defekt genug, dass vereinzelt Lese- und/oder Schreibfehler auftreten.

Problem bei Hardwaretests ist halt: Die Hardware selbst hat eine Fehlerkorrektur, die versucht den Fehler zu beheben. Das kann beim Lesen und Schreiben mal mehr, mal weniger gut funktionieren.
Bei mehr wird der Fehler behoben und die Prüfsoftware merkt nix von dem/den Fehlern.
Bei weniger versucht sie es mehr oder weniger oft nochmal, so dass die Hardware noch ein paar Versuche zusätzlich bekommt, den Fehler zu beheben / vertuschen. Wenn ausreichend Versuche der Hardware die Möglichkeit geben, den Fehler zu beheben, bekommt die Prüfsoftware weiterhin nix mit.

Was aber klar auf eine derartige Situation hinweist:

Zitat:

Dann habe ich den Eindruck, dass bei einem frisch gebooteten System kein Disk I/O Error auftritt, als wenn das System schon einige Zeit lief. Möglicherweise ist der Eindruck subjektiv.

Auch das lässt auf einen "schleichenden" Defekt schließen. So quasi: Da bahnt sich was an, das erste Kratzen im Hals vor 'ner Erkältung, wobei es nicht zwingend in eine Erkältung ausarten muss.

Ein weitere Hinweis auf einen schleichenden Hardwaredefekt wäre: Mal geht das Lesen-/Schreiben problemlos schnell, mal problemlos aber arg langsam, mal garnicht.

In "grauer Vorzeit" konnte man in so einer Situation wunderbar das Neupositionieren der Schreib-/Leseköpfe der Festplatte hören. Ein wiederholtes Klicken und längere Wartezeiten beim Lesen bzw. Schreiben waren da die ersten Hinweise auf einen "zukünftigen" Hardwaredefekt.

Zitat:

Selbst wenn Windows nichts findet, kann der Datenträger einen defekten Sektor haben, der in der Datei verwendete wird.

Das ist so leider richtig und zwar weil:

Wird etwas gelesen und der entprechende Sektor ist defekt, versucht zuerst die Hardware die Daten in einen intakten Sektor zu retten. Solange das gelingt, ist das für das Betriebssystem nicht erkennbar. Erst wenn das nicht gelingt, wird das Betriebssystem entsprechend informiert.
Problem dabei: Die Hardware meint die Daten hardwareseitig richtig gerettet zu haben, dass heißt aber nicht immer zwingend, das sie auch inhaltlich (also auf binärer Ebene) korrekt gerettet wurden. Passiert zwar nur extrem selten, kann aber nicht absolut ausgeschlossen werden.
Allerdings sollte das Problem nach so einer hardwareseitigen Rettung dann behoben sein und nicht (mehr oder weniger) sporadisch erneut bei den gleichen Daten auftreten.