aviette
Goto Top

Chkdsk Ergebnisse nicht zu finden. In Ereignisanzeige-Anwendung auch nicht

Hallo liebe Administrator Gemeinde,

es geht um Windows Server 2003 SP2,
RAID1 (500GB+500GB) SATA,
2 Partitionen C: (30GB mit Windows) und D: (450GB mit Datenbank und anderen Kramm)
Kiste von DELL, 19'', 6 Jahre Alt

Eigenschaften von Laufwerk D: -> Extras -> Fehlerüberprüfung -> Jetzt prüfen -> Alle Checkboxen anklicken -> Starten.
Nach Rechner Neustart Chkdsk prüft ordentlich die Festplatte D: durch.

Die Ergebnisse sind nirgendwo danach zu finden:
  • in Ereignisanzeige\Anwendung - nicht
  • Datei C:\checkdisk.log D:\checkdisk.log gibt es auch nicht

Die gleiche Überprüfung von Laufwerk C: schreibt seine Ergebnisse ordentlich in Ereignisanzeige\Anwendung\wininit (!!!)

Die Überprüfung von D: dauert ca. 2,5 Stunden
Ob es tatsächlich bis zu Ende läuft, kann ich nicht sagen, da diese 2 Sekunden mit Ergebnisse konnte ich nicht fangen.

Hat jemand eine Idee
a) was es seien kann?
b) und wo sind die Ergebnisse?

Lieben Dank

Content-Key: 163095

Url: https://administrator.de/contentid/163095

Ausgedruckt am: 29.03.2024 um 13:03 Uhr

Mitglied: Snowman25
Snowman25 22.03.2011 um 09:21:43 Uhr
Goto Top
Hallo @aviette,

Du müsstest in deinen Anwendungslogs (eventvwr.msc) ein winlogon-Event haben, welches zu der Zeit erstellt wurde, nachdem der chkdsk-Vorgang abgeschlossen war. In diesem sollten alle benötigten Informationen stehen.

Gruß
Snow
Mitglied: aviette
aviette 22.03.2011 um 09:53:58 Uhr
Goto Top
Hallo Snowman25

du hast Recht: inter "winlogon" sind die Ergebnisse von "chkdsk C:" zu finden.
Aber die Ergebnisse von "chkdsk D:" sind auch nicht da. "winlogon" Eintrag fehlt.
Ich habe alle Ereignisse unter Katalog "System" und "Anwendung" innerhalb von Zeit des Rechnerstart überprüft. Kein Erfolg.

Es bleibt wahrscheilich die Festplatte auszubauen, an einen PC anschliesse und auf Fehler überprüffen lassen.
Aber ich habe hier viel Bedenken:
es geht um keinen echten RAID1 sondern einen gestrickten Software RAID1 with BIOS Config von DELL (PowerEdge SC-1425),
wo erste Platte ist Master und die Zweite ist Slave.
Z.B. Rechner ohne Masterplatte startet nicht.
Und wenn ich dort separte Fehlerüberpüfung lasse dann habe ich später Kopfschmerzen und ca. 5 verlorene Stunden mit Syncronisierung.
Mitglied: Snowman25
Snowman25 22.03.2011 um 10:10:59 Uhr
Goto Top
Wie wäre is mit einer online-Defragmentierung? Immerhin ist die Platte ja nicht die Bootplatte.
Einfach in der Konsole folgendes eingeben:
chkdsk D: /F /V /R /X
Unter Umständen musst du erst die Auslagerungsdatei auf D: deaktivieren.
Hierzu öffnest du
  1. Eigenschaften von System (Win-Taste + Pause)
  2. Reiter "Erweitert"
  3. Systemleistung Einstellungen
  4. Reiter "Erweitert"
  5. Virtueller Arbeitsspeicher Ändern.

Da stells du den vArbeitsspeicher für D: auf "Keine Auslagerungsdatei" (mit Festlegen bestätigen) und setzt den von C: auf automatisch oder die gleichen Werte wie vorher von D:.
Danach musst du dein System neu starten. Du solltest die Festplatte jetzt über die Konsole per chkdsk prüfen können.
Nach dem erfolgreichen chkdsk kannst du die Einstellungen wieder rückgängig machen.

Gruß
Snow
Mitglied: aviette
aviette 22.03.2011 um 10:42:52 Uhr
Goto Top
Hallo Snowman25
danke für Turbotipps.

Meinen D: hat keine Auslagerungsdatei aber hat MSSQL DB. Ich versuche die Zeit zu finden um das SQL Dienst zu stoppen und dann müsste(?) Laufwerk für online Überprüfung frei sein.

Außerdem ich habe es gerade probiert:

1) mit "vrfydsk d: /v" - vrfydsk.exe stürtzt mit Exception ab.

2) mit "chkdsk d: /v" wärend Betribsystem läuft.
Hier sieht man schon die mögliche Problematikquellen:
a) Von Schritt zu Schritt hat chkdsk das Prozentindikator nicht geändert(!)
b) ab und zu erscheinen die 13 bis 14 -Stellige(!) Nummern wie "10305696305696"

Unten sind die Ergebnisse:

Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet DATA.

WARNUNG! Der Parameter F wurde nicht angegeben.
CHKDSK wird im schreibgeschtzten Modus ausgefhrt.

CHKDSK berprft Dateien (Phase 1 von 3)...
0 Prozent abgeschlossen. (0 von 305696 Datens„tzen verarbeitet)
0 Prozent abgeschlossen. (5000 von 305696 Datens„tzen verarbeitet)
...
9 Prozent abgeschlossen. (300127 von 305696 Datens„tzen verarbeitet)
9 Prozent abgeschlossen. (305127 von 305696 Datens„tzen verarbeitet)
10305696305696
305696 Datens„tze verarbeitet. Dateiberprfung beendet.
10 Prozent abgeschlossen. (1 von 4561 groáen Datens„tzen verarbeitet)
1045614561
4561 groáe Datens„tze verarbeitet. 1000
0 ungltige Datens„tze verarbeitet. 1000
0 E/A-Datens„tze verarbeitet. 1000
0 Analysedatens„tze verarbeitet.
CHKDSK berprft Indizes (Phase 2 von 3)...
10 Prozent abgeschlossen. (511 von 883640 Indexeintr„gen verarbeitet)
10 Prozent abgeschlossen. (1023 von 883640 Indexeintr„gen verarbeitet)
...
92 Prozent abgeschlossen. (882697 von 883640 Indexeintr„gen verarbeitet)
92 Prozent abgeschlossen. (883197 von 883640 Indexeintr„gen verarbeitet)
92883640883640
883640 Indexeintr„ge verarbeitet. Indexberprfung beendet.
Es wurden kleinere Inkonsistenzen auf dem Laufwerk festgestellt. Es handelt sich dabei nicht um eine Besch„digung.
9255
5 nicht indizierte Dateien verarbeitet.
CHKDSK berprft Sicherheitsbeschreibungen (Phase 3 von 3)...
92 Prozent abgeschlossen. (5000 von 305696 Beschreibungen verarbeitet)
92 Prozent abgeschlossen. (10000 von 305696 Beschreibungen verarbeitet)
...
99 Prozent abgeschlossen. (296313 von 305696 Beschreibungen verarbeitet)
99 Prozent abgeschlossen. (301313 von 305696 Beschreibungen verarbeitet)
99305696305696
305696 Sicherheitsbeschreibungen verarbeitet. šberprfung der Sicherheitsbeschreibungen beendet.
1001348713487
13487 Datendateien verarbeitet.
457418713 KB Speicherplatz auf dem Datentr„ger insgesamt
388115040 KB in 143703 Dateien
71028 KB in 13489 Indizes
37904 KB in fehlerhaften Sektoren
386145 KB vom System benutzt
65536 KB von der Protokolldatei belegt
68808596 KB auf dem Datentr„ger verfgbar

4096 Bytes in jeder Zuordnungseinheit
114354678 Zuordnungseinheiten auf dem Datentr„ger insgesamt
17202149 Zuordnungseinheiten auf dem Datentr„ger verfgbar
Mitglied: Snowman25
Snowman25 22.03.2011 um 11:07:47 Uhr
Goto Top
nochmals Hallo @aviette,

Mach dir um die Zahlen keinen Kopf. Das kommt durch die umgeleitete Ausgabe in eine Datei.
Was mich hier vorallem stört ist das:
37904 KB in fehlerhaften Sektoren
Das sind 37 MB in kaputten Sektoren(!)
Du solltest möglichst bald chkdsk D: /V /F /R ausführen. Dann werden die Fehlerhaften Sektoren mit dem bad_sector-Flag gekennzeichnet und der Inhalt auf frische, funktionstüchtige Sektoren geschrieben.
Nach Möglichkeit sollte die Platte danach bald getauscht werden.

Gruß
Snow
Mitglied: aviette
aviette 23.03.2011 um 11:58:36 Uhr
Goto Top
Hallo Snowman25

37904 KB in fehlerhaften Sektoren

ich dachte sind das die schon als "Bad" markiert und deswegen hier als "fehlerhaften Sektoren" angezeigt.
Mitglied: Lionborg
Lionborg 18.07.2011 um 03:16:48 Uhr
Goto Top
...

Das Problem wird ja längst gelöst sein. Ich hatte sogar mal selbes Problem und ChkDsk machte es nur noch schlimmer. Dies passierte zwar schon vor einigerr Zeit.

Inzwischen habe ich einen Post gelesen, welcher sich auf ChkDsk und Raid bezieht. Darin heisst es, dass man bei Raids mit ChkDsk vorsichtig sein sollte. Sobald eine Festplatte angeschlagen ist, kann u.U. ChkDsk u.U. auf eine einzelne Festplatte zugreifen und dort erheblichen Schaden hinterlassen. (Ob sich das auch auf Raid1 bezieht, weiss ich jetzt nicht.

Dies nur als Tip zur Vorsicht. Wobei ich ja schon annehme, dass wichtige Daten ja bereits vorgängig gesichert wurden.

Ich dachte bislang auch nicht, dass ChkDsk sogar destruktiv sein kann, aber ich hab's eben gelesen. Ich habe vor Kurzem Probleme mit meinem Raid0 gehabt. Und da auch ChkDsk im Spiel war und eine defekte HD, dachte ich, ich geb des hier weiter.


Zitat:

Um Missverständnisse zu vermeiden, hier ein Nachtrag zu unsere Meldung: Nein, es ist kein Unfug, bei einem RAID chkdsk auszuschalten. Bei einem 100% einwandfrei funktionierenden RAID sieht chkdsk tatsächlich keine einzelnen Platten und kann auch keinen Schaden anrichten. Ist aber eine Festplatte ausgefallen oder wird vom Raidkontroller als korrupt gemeldet, z.B. auf Grund zu vieler defekter Sektoren, wird es durch den BootExecute-Eintrag autocheck* richtig gefährlich für die Daten. In einem beschädigten RAID erkennt chkdsk eine oder mehrere Einzelplatten und versucht ein Dateisystem zu rekonstruieren, im besten Fall nur auf der ersten Platte des RAIDs, manchmal auch auf mehreren. Das Ergebnis sind viele korrupte Files und ein RAID das so weit zerstört ist, dass es auch nach dem Austausch der ursprünglich beschädigten Platte nicht mehr wiederaufgebaut werden kann. Die auf den Platten verteilten Daten müssen mit ziemlichem Aufwand rekonstruiert werden. Ein Problem, das vielleicht mit dem Tausch einer Platte und dem Rebuild des RAIDs hätte gelöst werden können, wird auf diese Weise zu einem anspruchsvollen Datenrettungsjob.
Conrad Heinicke
CBL Datenrettung GmbH

Zitat Ende...


Es gibt ja auch nicht umsonst Raidfestplatten, bei welchen gewisse Fehlerkorrekturen seitens der Festplatte selbst deaktiviert sind, weil diese ansonsten mit der Fehlerkorrektur des Raidkontrollers konkurrieren können. Heute machen ja viele EigenPC Bauer ein Raid, verwenden aber herkömmliche Festplatten dazu. Es muss nicht zu einem Fehler kommen, es kann aber. "Tler", (Time limited Error Recovery), heisst das bei Western Digital.

Hier mehr dazu > http://wdc.custhelp.com/app/answers/detail/a_id/1397/session/L3RpbWUvMT ...

Und hier zum Tler > http://wdc.custhelp.com/app/answers/detail/a_id/1478/session/L3RpbWUvMT ...


PS. Nebenbei... Das ist doch gleichwohl ein Hardware Raid. Auch wenn der Prozessor seine Arbeit leisten muss. Ich hab auch mal den Ausdruck Firmwareraid gelesen. Was ist nun richtig. Oder sind nur Raids auf Raidcontroller mit eigenem Prozessor und Arbeitsspeicher Hardwareraids?

...