ERROR database disk image is malformed

[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.

[Peter-Pascal]

Hallo Delphi.Narium,

Deine Erklärungen sind richtig interessant und habe ich aufmerksam gelesen.

Nach Deinen Ausführungen bin ich mir sicher, dass ein Hardware Defekt vorliegt. Was Du schreibst klingt schlüssig, zumal ich jetzt auch auf der SSD Platte eine DB angelegt habe und mit den CSV Daten gefüllt habe. Alles funkioniert ohne Probleme und in angenehmer Geschwindigkeit.

Jetzt bin ich unschlüssig, was ich mit der Platte anfangen soll, austauschen? Gibt es ein Tool das zuverlässig die Platte checken kann und defekte Sektoren markiert? Hieß es nicht Checkdsk oder so ähnlich?

Oder abwarten? Datensicherungen habe ich genug. Automatisch wird auf einer NAS gesichert und zusätzlich sichere ich noch die wichtigsten Daten auf einer externen Festplatte.

Danke für Deine umfangreichen Erläuterungen

[Delphi.Narium]

Keine Ahnung wie das bei aktuellen Windosen ist.

Kommandozeile und dann:

Code:

chkdsk c: /f /r /x /v

c: steht für den Laufwerksbuchstaben der (vermutlich) defekt(werdend)en Platte.

/v ist der "Labermodus", es werden Meldungen ausgegeben, wenn was nicht passt. Die solltest Du Dir anschauen und merken. Wichtige Meldungen sollten aber auch im Ereignisprotokoll von Windows zu finden sein. (Hast Du schonmal dort geschaut, ob es eventuell schon irgendwelche Meldungen bzgl. Hardware, Festplatte, ... dort gibt?)

Die Prüfung geht nicht unbedingt im laufenden Betrieb. Windows sollte das merken und den Befehl dann nach 'nem Neustart des Rechners als erstes ausführen. Das geschieht bevor Windows selbst richtig und vollständig geladen wird. Es läuft also quasi nur ein rudimentäres DOS und: Das kann dauern, sehr lange dauern. Ein, zwei Kaffee werden dann nicht ausreichen, ggfls. also vor Feierabend oder über Nacht oder so laufen lassen.

Was Du aber keinesfalls machen solltest: Wenn dieser Job läuft den Rechner neustarten, weil das sooooo laaange dauert. Das kann ggfls. dann das Aus für die (eventuell noch) reparierbaren Daten und Sektoren bedeuten.

Und ja, es gibt diverse Tools, die dann ggfls. auch noch helfen können, wenn Windows scheitert. Die nutze ich aber nur dann, wenn Windows scheitert. In der Mehrzahl greifen sie aber auf die gleiche API zu, die auch Windows nutzt. Also ungefähr sowas: Andere Optik für gleiche Aufgabe.

Da können wir ggfls. dann suchen gehen, wenn Du von Windows gesagt bekommst, wo denn da was hakt.

Achso: Der Hersteller hat dazu auch was zu sagen: chkdsk.
Bitte zuerst durchlesen und dann entscheiden, was für Deinen konkreten Fall am Besten geeignet erscheint. Die angegebene Lesedauer von 3 Minuten ist allerdings deutlich untertrieben

[jobo]

Einfach Dinge ausschließen, vorzugsweise grobe Entscheidungen treffen, die einfach umsetzbar sind:
Nimm irgendeinen USB Stick, pack die DB drauf und wiederhole dort den Import 10x, 100x, es ist ja offenbar nur eine kleine Datei mit einer vierstelligen Anzahl von Datensätzen.
Man kann in der Variante ohne SSD vielleicht annehmen, dass selbst ein Controller Fehler vor der SSD beim USB Stick nicht greifen würde. Ist aber auch nur geraten.
Der Zweig der fehlschlägt, wäre dann weiter zu verfolgen, aufzudröseln. Andere Disk, anderer Rechner, Importdateien halbieren, vorderere/ hintere Hälfte testen oder nach dem Split einen identischen Teil 2x hintereinander hängen, oder generierte/"genormte" Daten in großer Menge importieren.
Im Taskmanager oder besseren Tools mal nach verdächtigen Prozessen suchen (tote EXEn ..)
In der Computerverwaltung o.ä. mal die geöffneten Dateien inspizieren.
..

Datenfehler:
Dass fehlerhafte Daten zu Problemen führen (also nicht logische Probleme), kenne ich seit ca. 10-15 Jahren nicht mehr und auch da waren es schon alte, schlechte DB Treiber und der Fehler hat niemals dazu geführt, dass die DB korrupt war.

andere Fehler:
Master/Detail macht etwas hellhörig. Der Fehler ist vielleicht weniger in den Daten zu suchen, als in den Importmechnismen oder der Version der SQLite DLL (Ich habe nicht im Kopf, ob Du das hier irgendwo aufgeführt hast, welche SQLlite DLL / Delphiversion)

Vielleicht machst Du ja auch irgendwelche "kranken" Sachen im Import Code. Am Ende sind hunderte Connections zur DB offen oder Du hast irgendwo ein File Handle auf die SQLite geöffnet oder IDE (kann auch zur Designzeit die DB öffnen und offen halten) und Kompilat kommen sich in die Quere, .. es gibt viele Möglichkeiten.

Ist aber letztlich alles auch Rätselraten, wenn Dein (Import) Code hier unbekannt ist, ebenso wie die Importdaten.