Glorf IT

Meine aktuellen Versuche mit WMIC wurden durch die neue ct (Ausgabe 15/2006, Softlink 0615204) angestoßen. Wer irgendwie die Chance hat den Artikel im Original zu lesen, sollte das tun, wirklich gut. Die Beispiele sind deswegen auch daraus…

Mit folgendem Befehl kann man sich alle Programme anzeigen lassen, die beim Start (alle, d.h. Autostart, Run, RunOnce, …) ausgeführt werden:
[code]wmic /output:startup.htm STARTUP list /format:htable
startup.htm
del startup.htm[/code]

Dieser Befehl kopiert die Liste der installierten Programme ins Clipboard:

[code]wmic /output:Clipboard PRODUCT list[/code]

Der hier gibt die Liste aller Drucker in der DOS-Box aus:

[code]wmic Printer get Caption[/code]

Und hiermit wird die Prozessliste sortiert in eine HTML-Datei geschrieben und angezeigt:

[code]wmic /output:process.htm Process get Caption, ProcessId, CommandLine /format:htable:"sortby=ProcessId":"datatype=number":"title=Prozessliste: "
process.htm
del process.htm[/code]

Und das ist nur die Spitze des Eisberges. Eine Liste der Möglichkeiten bekommt man mit

[code]wmic /?[/code]

PS: Habe ich schon erwähnt, dass man zur Ausführung der WMIC Admin-Rechte benötigt? Sonst kommt eine komische Fehlermeldung… 😉

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 …

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:

• Geheimnisse von Windows Management Instrumentation – Problembehandlung und Tipps
• WMI-Diagnoseprogramm

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]

Ich habe an einer Umfrage zur Bewertung des Führungsstils von Jürgen Klinsmann teilgenommen. im ersten Teil ging es darum, ob der eigene Chef Aspekte des Klinsmann'schen Führungsstils einsetzt. Im zweiten welche Aspekte man sich wünschen würde.

Hier ist die Auswertung der Worklife-Panel-Befragung zum Führungsstil von Jürgen Klinsmann.

Ergebnis: Wunschliste der Prinzipien

1. Klare Ansage der Strategie
2. Klare Kommunikation der Spielregeln
3. Fester Glaube an Mitarbeiter
4. Positive Vision vom anzustrebenden Ziel
5. Konsequenter Kurs

Das Buch Die Letzten ihrer Art. Eine Reise zu den aussterbenden Tieren unserer Erde von Douglas Adams und Mark Carwardine ist ein unheimlich witziges Buch über ein ernstes Thema.

Es ist unterhaltsam und interessant zugleich. Es ist im Prinzip eine Dokumentation zu mehreren Forschungsreisen auf der Suche nach fast ausgestorbenen Tieren. Das würde ich am liebsten zu jedem Geburtstag verschenken. Aber es ist schon etwas älter und womöglich kennt es jeder schon lange und nur ich habe es für mich erst kürzlich entdeckt.

Zu Schluss meine Lieblingspassage aus dem Buch in der Adams Verständnis für die seltsamen Brutgewohnheiten einer Vogelart ausdrückt:

Meinen Ruf als ziemlicher Technik-Freak habe ich mir schwer erarbeitet, und ich bin selten glücklicher als an jenen Tagen, die ich von morgens bis abends damit zubringe, meinen Computer auf das automatische Erledigen einer Aufgabe zu programmieren, die mich bei eigenhändiger Ausführung gute zehn Sekunden kosten würde. Zehn Sekunden, sage ich mir, sind zehn Sekunden. Zeit ist kostbar, und die Einsparung von zehn Sekunden ist es allemal wert, einen Tag fröhlicher Aktivität auf die Suche nach ihrer Einsparungsmöglichkeit zu verwenden.

Die Serie in der ich berichten welche Ursachen erfahrungsgemäß hinter Datenbank-Defekten stecken, hat mich darauf gebracht vielleicht auch ein paar Werkzeuge oder Vorgehensweisen zu beschrieben. Immerhin ist es manchmal nicht ganz einfach den SQL Server 2000 überhaupt dazu zu bringen eine korrupte Datenbank zu akzeptieren.

Wenn uns Kunden eine defekte Datenbank schicken, dann können wir relativ häufig doch noch eine ganze Menge an Daten aus den Dateien rausholen, selbst wenn der SQL Server sich weigert die Dateien auch nur als Datenbank-Dateien zu erkennen.
Leider bietet MS dazu keine Unterstützung, eine echte Lücke in die eine estländische Firma gesprungen ist.
Mit dem Werkzeug Recovery for SQL Server haben wir schon aus so mancher Kunden-Datenbank wieder etwas rausholen können. Natürlich fehlen dann die Daten aus den defekten Seiten und die Daten sind nicht mehr in sich konsistent. Sprich: Es erfordert noch eine gründliche Portion Nacharbeit, um die Daten wieder in einen halbwegs sauberen Stand zu bringen.

Nun könnte man sich auf den Standpunkt stellen: "Keine Datensicherung – selbst schuld." Wenn man bedenkt, dass die meisten unserer Kunden bei einem Totalverlust der Daten vor dem wirtschaftlichen Ruin stehen, dann versteht man warum wir das tun…. 🙂

Im ersten Teil der Serie über Ursachen für Datenbank-Defekte habe ich über ein paar sehr skurrile Ursachen von defekten Datenbanken berichtet. Heute geht es um ein sehr ernstes Thema: die Festplatten oder genauer das gesammte I/O-Subsystem.

Die ungeschlagene Nummer eins sind hierbei ungeeignete Festplatten. Es gibt immer wieder EDV-Händler, die unseren Kunden Server mit billigen EIDE-Festplatten verkaufen. (Unser Klientel hat den Ruf besonders kostenbewusst zu sein, vermutlich ist da etwas dran.) Dabei sind RAID-Systeme mit EIDE-Festplatten offenbar auch nicht viel besser. Weil die Kunden in der Regel zunächst nicht glauben, dass die Probleme durch deren Hardware verursacht werden, haben wir sogar eine Zeitlang mit unserer Software einen Batch installiert, der eine sehr große Datei erzeugte und die dann immer hin und her kopierte. Nach jedem Kopiervorgang wurden die Dateien binär verglichen. Wenn dabei Unterschiede auftreten, dann überzeugt das auch den EDV-Laien.
Leider findet man damit nur die völlig schrottigen Systeme, deswegen haben wir es dann wieder gelassen…

Warum IDE-Festplatten für Serversysteme nicht geeignet sind, beschreibt der TecChannel-Artikel "Gefahr: IDE-Festplatten im Dauereinsatz". Aus meiner Sicht gilt das gleiche für Einzelplatzsysteme auf denen der Kunde seine Daten gespeichert hat.

Knapp dahinter stehen Festplatten mit eingeschaltetem Schreibcache, das gilt auch für Raid-Systeme. Wenn der Schreibcache nicht abgesichert ist (z.B. mit einer Batterie gepuffert oder mit einer USV abgesichert), dann hat bei einem Stromausfall oder beim versehentlichen Drücken des Reset-Schalters (wie um alles in aller Welt kann das passieren?) mit sehr hoher Wahrscheinlichkeit das Transaktionslog einen irreparablen Treffer. Häufig ist auch die MDF betroffen.
Das kommt offenbar so oft vor, dass Microsoft sogar einen KB-Artikel dazu geschrieben hat: "INF: SQL Server and Caching Disk Controllers".
Leider bringt ein eingeschalteter Schreibcache aber auch wirklich spürbare Performance. Deswegen lohnt es sich an dieser Stelle etwas mehr Geld auszugeben und ein Raid-System mit SCSI-Platten (siehe oben) und abgesichertem Schrei-Cache anzuschaffen.

Diesen Punkt beschreibt Microsoft unter anderem in dem Dokument: "SQL Server 2000 I/O Basics". Ein wirkluich sehr erhellendes Dokument, dass auch noch viele andere Dinge erklärt auf die ich ein ander mal zu sprechen komme.

Zuerst dachte ich Hybrid-Festplatten, genauer "Hybrid Hard Drives with Non-Volatile Flash" (siehe auch den Vortrag "Hybrid Hard Drives with Non-Volatile Flash and Longhorn" von der WinHEC) wären dafür die Lösung, aber gestern las ich in der ct15/2006, dass eine NAND-Speicherzelle nur rund 200.000 Lösch- oder Schreibaktionen aushält. Bei der Menge an Schreiboperationen, die der SQL Server verursacht, könnte das zu einem Problem werden.

Als weiteres gibt es noch eine ganze Reihe von Probleme, die im Umfeld des I/O-Subsystems stecken können. Neben einem Fall von defektem Hauptspeicher im RAID-Controller konnten wir früher mehrfach Treiber-Probleme als Ursachen ausmachen. Der Kollege, der damals unsere internen Systeme betreute, erzählte mir dass für die RAID-Controller, die unsere Firma für den interen Einsatz anschafft, bei den Tests immer wieder Bugs in deren internem Microcode festgestellt wurden (keine Ahnung, wie die das testen). Auch hier sollte man deswegen immer die neueste Software vom Hersteller einsetzen…
Hier noch ein paar weiterführende Hinweise, die Microsoft gut verstreut hat:

• PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems
• FIX: Additional diagnostics have been added to SQL Server 2000 to detect unreported read operation failures
• PRB: Error message 823 may indicate hardware problems or system problems

Und zuletzt einer der wichtigsten Hinweise: Microsoft bietet zum Test des I/O-Substems ein wunderbares Werkzeug an, dass die Zugriffe des SQL Servers simuliert und dann einen Statusbericht abgibt: SQLIOStress.exe.
Damit kann man ziemlich akurat die meisten aller I/O-Probleme nachweisen.

Demnächst mehr an dieser Stelle…

Es passiert ja zum Glück selten, aber ab und an erleben wir, dass der SQL Server sich bei Kunden aus dem Tritt bringen lässt und sich einfach verabschiedet.
Dann gibt es zwei Dinge zu tun: erstens den SQL-Server-Dienst schnellstens neu starten und zweitens die Ursache finden.

Da ein Admin normalerweise auch bloß 9 von 24 Stunden an 5 von 7 Tagen im Büro ist, der Chef aber auch mal spät abends oder am Wochenende drin ist, sind die Chancen groß, dass es dann passiert wenn der Admin gerade sonstwo ist. Hier hilft ein ganz nettes Feature des Dienstemanagers: Er kann den Dienst sofort wieder starten oder erst nach 1 oder 2 oder 3 … Minuten:

Wenn es wieder passiert, dann kann man sich auch lieber eine Mail schicken lassen oder ein anderes Programm aufrufen. Das finde ich echt nützich.

Vor vier Jahren hat es mir mein Chef schon mal geliehen, aber da war das Thema für mich noch nicht so aktuell. Gelesen habe ich es deswegen erst jetzt:
Fish! Ein ungewöhnliches Motivationsbuch von Lundin, Paul und Christensen. Es ist recht kurz und unterhaltsam. Es erzählt eine Geschichte und versucht dabei ein paar Grundprinzipien der Motivation rüber zu bringen. Man könnte die locker auf zwei Seiten zusammenstellen. Aber dann würde man wahrscheinlich nicht so darüber nachdenken und sich dabei noch amüsieren…

Hier geht es darum, wie man es schaffen kann ein leistungsfähiges Team aufzubauen, deren Mitglieder gut zusammenarbeiten und gute Arbeit leisten. Die wichtigsten Dinge sind dabei die Mitarbeiter dazu zu bringen die Arbeit gut zu finden, dabei viel Spaß zu machen/haben, für andere da zu sein und aufmerksam zu sein.
Interessant finde ich, dass hier ganz allgemeine dinge in den Vordergrund gestellt werden. Und eben nicht die Dinge wie Bezahlung, Freiheit des Einzelnen und Verantwortung. Die gehören für mich schon auch dazu, aber aus eigener Erfahrung trägt tatsächlich die eigene Einstellung maßgeblich dazu bei, ob ich einen guten Tag habe oder nicht. Wenn ich dann auch noch Gelegenheiten schaffe an denen ich lachen oder Quatsch machen kann, dann kann es schon gar nicht mehr so dick kommen…

Außerdem: es ist angenehm zu lesen, dünn und billig.

Bei "flow|state" fand ich kürzlich einen sehr guten, kurzen Artikel (schon vom letzten Jahr) über Oberflächendialoge: "Avoiding unnecessary questions in command UI".

Ich finde er bringt es einfach gut rüber: viele Nachfragen können durch einen anderen Workflow vermieden werden.

In der Ausgabe Juni 2006 des “Harvard Business Manager” wird im Artikel "Das Ende der Standard-Filiale" beschrieben, wie die Giganto-Ketten, wie Wal-Mart oder McDonalds, davon weg gehen jede Filiale genau gleich zu machen. Eine ganze Zeit lang wurde versucht alles gleich zu machen (in Neusprech: "die Prozesse zu optimieren"):

• gleiches Sortiment
• gleicher Grundriss
• gleiche Artikelverteilung in den Regalen
• gleiche Sonderangebote

Wer seinen Umsatz weiter steigern wil, der muss jetzt stärker auf lokale Bedürfnisse und Besonderheiten eingehen. Plattes Beispiel: Ein Supermarkt in der Innenstadt hat eine große Auswahl an Fertigprodukten, um den gestressten Berufstätigen auf dem Heimweg eine gute Auswahl zu bieten. Der Supermarkt, der typischerweise mit dem Auto angefahren wird, bietet alles für die typische "Familie" mit Hausfrau und Kindern, also viele große Packungen und mehr Dinge zum "selber kochen".

Durch die moderne EDV wird in den USA inzwischen sogar der örtliche Geschmack berücksichtigt: Je nach Gegend werden andere Chillis oder Ketchups angeboten. Damit das trotzdem noch billig ist, werden diese Supermärkte bzw. deren Sortiment nach dem Baukasten-System zusammengestellt. Damit haben sie beim Einkauf den Effekt der großen Zahl und können dennoch lokale Besonderheiten berücksichtigen.

Ich bin mal gespannt, wann ALDI sein Programm regionalisiert. Was gibt es dann hier in Erlangen außer den Nürberger Würstchen als regionale Besonderheit? Fahrradersatzteile?

Wenn ich im Kopf so die Liste der Dinge durchgehe, die wir schon als Ursachen für Datenbank-Defekte ausmachen konnten, dann gibt es so viele potentielle Ursachen, dass ich wohl eine Reihe daraus machen muss. Irgendwie drängt es mich mit den Hauptursachen anzufangen, aber die kennt Ihr ja bestimmt schon. Deswegen fange ich mit den verrückten Sachen an.

Wetter
Das Wetter habe ich ja schon genannt… 😉

Zipper
Als ich 1993 in meiner Firma anfing, hatten wir gerade eine Serie von Datenbank-Problemen. Wie sich zeigte arbeitete der von uns damals (noch unter OS/2 eingesetzte) PKZIP nicht korrekt. Es betraf komischerweise fast ausschließich Datenbank-Devices. Der Test war zum Glück einfach: Datei zippen, entzippen und binär mit dem Original vergleichen. Die Trefferquote war so hoch, das wir sogar eine neue Version bekamen.
Ich meine mich zu erinnern, dass wir vor gar nicht allzulanger Zeit ähnliche Probleme mit dem Entpacken von ZIPs hatten, die größer als eine bestimmte Grenze waren (war es 2 GBytes oder 4 GBytes?). Das betraf die letzte FreeWare-Version des PowerArchivers. Dann musste die kostenpflichtige angescaft werden. Allerdings traf uns das im Zusammenhang mit VMWare-Images.

Mails
Kollegen kommen immer wieder auf die Idee mir Datenbank-Dateien per Mail zu schicken. Ende der 90er kam es da häufiger vor, dass die Datenbank defekt in meinem Outlook ankam, obwohl die Datei beim Absender OK war. Komischerweise machen das einige Kollegen immer noch, aber dabei ist schon länger keine DB mehr rübergerudert.

CD/DVD-Brennprogramme
Immer wieder senden Kunden Ihre Daten zu uns ein, damit die Kollegen in den Fachabteilungen bestimmte Probleme oder Effekte nachvollziehen können. Dabei kommen unregelmäßig nur schrottige Datenbanken bei uns an. Neben den ganz normalen CRC-Fehlern (hat Kunde nicht bemerkt, weil beim Brennen kein Verify durchgeführt wurde) kommen auch ganz leere Dateien bei uns an. Sie haben die richtige Größe, bestehen von vorne bis hinten aber aus Hex00.
Immer wieder schaffen es Kunden die Datenbank-Dateien zu brennen ohne den SQL-Server-Dienst zu beenden. Bei bisher ungeklärten Umständen stehen dann "leere" Dateien auf der DVD/CD. Fast alle Betroffenen hatten Nero im Einsatz, aber ich konnte es noch nicht reproduzieren.
Daher schaue ich mir die Datenbank-Dateien immer als erstes mal im Hex-Editor an. Das geht mit dem Programm XVI32 ganz prima. Es arbeitet auch mit sehr großen Dateien noch gut.

Nur mal als Randnotiz: Wir hatten auch mal einen Kunden, der eine Datenbank gebrannt hat, dabei den SQL Server nicht stoppte und dessen Datenbank danach so richtig im Eimer war. Er behauptet sie sei vorher völlig in Ordnung gewesen. Das konnte mein Kollege natürlich nicht kontrollieren, wir wissen nur, dass sie hinterher so kaputt war, dass sie sich nicht mehr reparieren ließ.

WordPad
Ein Kunde hatte mal Netz-Probleme und konte sich mit der Anwendung nicht zum Datenbank-Server verbinden. Weil er nicht auf den Kopf gefallen war, hat er erst mal in der Datenbank nachgeschaut und die Sybase-SQL-Anywhere-Datebank mit dem Notepad aufgemacht. Natürlich sah er nur Nonsense und komische Zeichen. Daraufhin rief er an und beschwerte sich. Es stellte sich heraus, dass die Datenbank wirklich defekt war. Aber nur, weil die Datei für den Notepad zu groß war und deswegen im WordPad geöffnet wurde. Als er das Programm schloss wurde er gefragt, ob er speichern will. Er schaute sich den Dialog nicht groß an, sondern drückte nur auf die Leertaste. Beim Speichern wurde die Datei um ein paar WordPad-Stuerzeichen ergänzt, z.B. ein schöner langer Datei-Header, ein paar Hex00 wurden entfernt und Sonderzeichen ersetzt.
Im Ergebnis war die Datenbank nur noch Schrott.
Habe ich schon erwähnt, dass der Anwendersupport die Kunden nur zu uns durchgestellt, wenn es keine Datensicherung gibt und wir die letzte Hoffnung sind? Das war eine bittere Pille für den Mann…

Bald kommt noch mehr zum gleichen Thema.