Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

15. Juli 2006 um 20:11

Ursachen für Datenbank-Defekte (Teil 3)

Nach den eher skurrilen Gründen im ersten Teil der Serie über Ursachen für Datenbank-Defekte und den Festplatten im zweiten Teil, geht es heute um Datenverluste durch eine defekte Datensicherung.

Natürlich führt die Datensicherung selber nur sehr selten zu Problemen, aber es kam durchaus schon bei unseren Kunden vor. Als wir noch den Sybase SQL Server einsetzten kam es mehrfach vor, dass wir sehr seltsame Effekte bei Kunden feststellten, die vermutlich auf die Datensicherung zurückzuführen waren. Die meisten davon traten allerdings unter Novell NetWare (Friede seiner Asche) auf.
Unter Windows 2000 hatten wir einmal einen Fall bei dem im Errorlog des "Sybase SQL Anywhere" jede Menge Informationen aus dem Sicherungsprotokoll der Sicherungssoftware standen. Das hat mich damals sehr gewundert, weil der SQL-Anyhwere-Dienst die ganze Zeit lief und die Errorlog-Datei exklusiv geöffnet hatte. Ich hatte bis dahin gedacht, dass sich ein Prozess nicht so einfach Zugang zu anderen Dateien verschaffen kann. Den Trick mit den Hooks habe ich erst später gelernt.
In einem anderen Fall wurden die Datenbanken vor dem nächtlichen Backup geprüft (keine Fehler), dann wurde der Dienst gestoppt, die Dateien gesichert und der Dienst wieder gestartet. Am nächsten Morgen konnte man mit einer der Datenbanken nicht mehr arbeiten. Hier war es so, dass man mit dem Hex-Editor erkennen konnte, dass einfach Schrott in der Datenbank stand. Für mich sahen es wie Fragmente eines Word-Dokumentes aus. Als ob da jemand etwas durcheinander gebracht hätte… Aber wir konnten nie beweisen, dass es die Sicherungssoftware war. Deswegen nenne ich auch keine Namen.

Aber viel öfter machte die Rücksicherung bei Kunden Ärger. Deswegen würde ich empfehlen die Rücksicherung nie in das originale Verzeichnis zu machen oder wenn schon, dann das Original wenigstens vorher umzubenennen. Am besten man macht vor der Rücksicherung eine Datensicherung. 😉

Hintergrund ist, dass wir schon so oft den Fall hatten, dass die zurückgesicherten Dateien fehlerhaft waren.

  • Häufig genug hatten die Kunden beim Backup kein "Verify" eingestellt ("Das dauert dann so lange!").
  • Der SQL-Server-Dienst wurde nicht gestoppt, die Datenbank-Dateien waren im Zugriff und wurden nicht gesichert. Das Protokoll nicht kontrolliert.
  • Es wurden immer die gleichen (kaputten) Bänder genommen.
  • Beim Sichern waren die Daten noch OK, während der (sachgemäßen?) Lagerung ruderten die DVDs rüber.

Und warum machen die überhaupt eine Rücksicherung? Na, z.B. weil ein Mitarbeiter versehentlich etwas zu viel gelöscht hat…

Naja, und wenn man dann die kaputte Dateien über die Originale geschrieben werden, dann ist das Jammern groß. Komischweise sind das dann auch die Kunden, die keine weitere Sicherung haben… Vielleicht mache ich mal eine Serie zum Thema Datensicherung. Aber das Lesen ja doch bloß die, die schon eine Sicherung machen: der Pfarrer predigt immer nur vor den Frommen!

Demnächst geht es weiter …

15. Juli 2006 um 09:28

Tipp, wenn WMIC nicht klappt

Ich bin gerade dabei die Tiefen von WMI mittels wmic.exe zu erforschen. Dabei klappte es bei mir einfach nicht:
[code] wmic /output:startup.htm STARTUP list /format:htable [/code]

Das lieferte beim ersten Aufruf folgende Meldung:

[code]Warten Sie, während WMIC installiert wird.
MOF-Datei wird verarbeitet: C:\WINDOWS\system32\wbem\Cli.mof(Phasenfehler – 3)
Kompilierer hat folgenden Fehler zurückgegeben: 0x80041001[/code]

Und beim zweiten Mal:

[code]Please wait while WMIC compiles updated MOF files.
MOF-Datei wird verarbeitet: C:\WINDOWS\system32\wbem\Cli.mof(Phasenfehler – 3)
Kompilierer hat folgenden Fehler zurückgegeben: 0x80041001[/code]

Ich habe daraufhin viele nützliche Links gefunden, die mir aber letztlich nicht weiterhalfen. Aber zwei die wirklich viele gute Informationen enthalten, gebe ich mal weiter:

Die echte Ursache war natürlich trivial: es fehlten einfach die Rechte. Ich hatte vergessen, dass ich mir neulich aus Sicherheitsgründen selber die Adminrechte entzogen habe…

Kaum führte ich den Befehl als Admin aus, schon klappte es:

[code] runas /user:Administrator "wmic /output:startup.htm STARTUP list /format:htable"[/code]

|