Glorf IT

Bei heise online steht, dass deutsche Unternehmen den Datenschutz vernachlässigen und Kundendaten unerlaubt für interne Anwendungstests einsetzen:

Der Befragung zufolge nutzen 64 % der Entscheidungsträger echte Kundendaten für Anwendungstests, was laut Bundesdatenschutzgesetz – Stichwort Zweckbindung – nicht erlaubt ist.

Das kann ich nicht ganz nachvollziehen. Es ist doch sehr einfach sich von den betreffenden Kunden das Einverständnis einzuholen seine Daten zum Testen nehmen zu dürfen (muss m.E. schriftlich sein, aber formlos genügt, darun muss eine Frist enthalten sein). In unserer Firma ist das ganz gängig. Die meisten Kunden sind damit einverstanden, etliche bieten es auch von sich aus an (nachdem ein Problem nur mit deren Datenkonstellation auftrat).
Allerdings können sie sich auch darauf verlassen, dass sie vertraulich behandelt werden… Um diese "Echtdaten" wird bei uns schon ein ganz schöner Wirbel veranstaltet: Sie dürfen nur in abgeschotteten Testnetzen installiert werden, die Rechner stehen in gesonderten Testräumen, Zutritt haben nur die eingetragenen Tester usw. 🙁

Den Artikel im CIO Weblog zum Thema Web 2.0: Wovor die CIOs Angst haben finde ich sehr erhellend. Tatsächlich habe ich bei uns in der Firma auch erhebliche Unsicherheit auf der Führungsebene erlebt: Darf da jeder schrieben was er will? Muss man sich dabei an all die Richtlinien für interne Veröffentlichungen halten? Darf da auch jemand etwas zu Themen schreiben für die er nicht zuständig ist?

Aber meiner Erfahrung nach sind jegliche Befürchtungen völlig unbegründet. Die aktive Beteiligung ist verschwindend gerung. Die Zugrffszahlen dagegen beträchtlich. In dem Zusammenhang finde ich die 1:100-Regel (hatte schon davon gelesen, der Link ist aus live.hackr) bemerkenswert. dazu hat der Guardian ein paar gute Infos veröffentlicht:
Es scheint normal zu sein, dass sich die überwiegende Mehrheit passiv verhält und nur konsumiert. Auf 100 Leser kommt üblicherweise ein Schreiber. Ganz schön enttäuschend. Aber genauso ist es bei uns in der Firma in Bezug auf Newsgroups und Wiki-Beteiligung.

Gestern habe ich festgestellt, dass ich in diesem Jahr meine Quote für die Aktion "Mit dem Rad zur Arbeit" schon erfüllt habe: Man muss an 20 Tagen mit dem Rad komplett bis zur Arbeit oder als Pendler zum Bahnhof fahren und schon hat man die Bedingungen erfüllt.

Ich bin schon auf die Urkunde gespannt. Seit dem Beginn wurden die Urkunden immer "billiger":

Wir haben an "schlechten" Tagen täglich mit Datenbank-Defekten unseren Kunden zu tun, was sicher auch damit zu tun hat, dass wir diese Reparaturen bis vor kurzem meistens kostenfrei durchführten. Für den Microsoft SQL Server 2000 möchte ich ein paar Tipps geben, die ich immer wieder gerne versuche, wenn sich herausstellen sollte, dass die einfachen Mittel (dbcc checkdb) nicht mehr helfen….

Im ersten Teil geht es um Probleme, wenn die Datenbank nicht angehängt werden kann.

Wie kann das passieren?
Der Kunde meldet sich bei der Hotline und beklagt, dass die Datenbank defekt ist. Dann führen die Jungs und Mädels ein paar Standard-Dinge durch. Manchmal kommen sie zu dem Schluss, dass man vor Ort einfach nichts mehr machen kann und holen die Daten in die Firma. Um sie dann im Hause untersuchen zu können, muss man die Datenbank erst mal an einen SQL-Server anhängen. Wenn das mit Bordmitteln nicht mehr geht, dann ist das ein ganz schlechtes Zeichen. Aber meist kann man da noch etwas machen. Das Anhängen geht meistens dann noch über einen Dummy:

1. Ich lege eine neue leere Datenbank irgendwo an. Die Datenbank muss mit so vielen Dateien angelegt werden, wie das anzuhängende Original. Um es einfacher zu haben, liegen bei mir dann immer alle Dateien im gleichen Verzeichnis.
2. Dann stoppe ich den SQL-Server.
3. Löschen der Dateien der neuen leeren Datenbank.
4. Die originalen Dateien der defekten Datenbank dorthin kopieren.
5. SQL Server starten.
   Weil die Datenbank sich nicht einfach öffnen lässt, wird sie beim Starten als suspekt markiert.
6. Jetzt kann man die Datenbank in den Emergency-Mode setzen.
7. Dann muss man den SQL-Server nochmals stoppen ud starten. Dabei wird für die Datenbank kein Recovery versucht.
8. Und schon kann man die eigentliche Analyse bzw. Reparatur beginnen.

So setzt man die Datenbank beim SQL-Server-2000 in den Bypass- bzw. Emergency-Mode:

exec sp_configure 'allow updates', 1
reconfigure with override
GO
update sysdatabases set status = status | 32768 where name = "myDB"
go
exec sp_configure 'allow updates', 0
reconfigure with override

Quelle: Das habe ich aus den Books-Online. Ich finde aber gerade nicht die Stelle. Bitte nach der Reparatur nicht vergessen den Status zurückzusetzen… 😉

Beim SQL-Server-2005 ist das deutlich einfacher:

alter database myDB set emergency

Demnächst geht es weiter…

Anbei die Links zu der Serien mit den Ursachen von Datenbank-Defekten:

• skurrile Gründe im ersten Teil
• Probleme mit Festplatten im zweiten Teil
• Datenverluste durch eine defekte Datensicherung im dritten Teil
• systemnahe Programme, die den I/O umbiegen, im viertel Teil
• defekter Hauptspeicher im fünften Teil

Gestern feierte unser Freund Stefan seinen 40ten Geburtstag. Aber nicht einfach nur so, wie der Rest der Welt es macht, er organisierte ein Happening von ungeahnten Dimensionen: große Halle, 100 Gäste (oder mehr) und eine 11-Mann-Band, die auch schon Rado kam.

Die Amberger Truppe Los Dos y Compañeros spielte auf und sorgte trotz erdrückender Hitze für Party-Stimmung. Auf Ihrer Homepage kann man auch Kostproben als MP3s und die Texte zum nachlesen runterladen. Das ist wichtig, denn die Text sind in der oberpfälzer Mundart und daher nur von echten Einheimischen zu verstehen… (Stefan kommt aus Amberg.)
Tipp: Wer sie live erleben will hat bei Nürnberger Bardentreffen am 29.7.2006 auf dem Hauptmarkt (16:00 Uhr) dazu Gelegenheit.

Von diesem Geburtstag werde ich noch meinen Enkeln erzählen… 😉

Neben dem Problem mit dem Safe wandte sich auch mal ein anderer verzweifelter Kunde an uns.

Ihm waren seine Rechner aus dem Geschäft geklaut worden. Meiner Erinnerung nach hatte er noch seine Sicherungsbänder. Aber weil er den SQL-Server-Dienst während der Datei-Sicherung nicht gestoppt hatte, waren alle Datenbank-Dateien im Zugriff und konnten nicht gesichert werden.
In diesem Fall konnten wir nicht mehr helfen… 🙁

PS: Ich halte nichts von dem erhobenen Zeigefinger: So und so muss Dein Backup aussehen. Das interessiert einen meist ja doch erst, wenn man betroffen ist: "Der Pfarrer predigt nur vor den Frommen!"
Aber vielleicht inspiriert dieser tragische Fall ja doch jemanden die ernste Seite des Themas zu erkennen und sein Sicherungskonzept zu kontrollieren?

Die Witzen- und Wundershöhlen waren meine bevorzugten "Kinderhöhlen". Den Durchgang zwischen den beiden habe ich nie begangen, obwohl Rahel die Stelle vermutlich schon mal gefunden hat.
Für die meisten Leute dürfte die Herausforderung darin bestehen erst mal auf den Berg raufzustiegen. Das ist schon ein nettes, steiles Stückchen. Auf dem Weg durch die Oswaldhöhle kann man die jüngeren schon mal einstimmen, bevor es richtig los geht. Ich glaube ich war dort 3 mal und das dürfte schon viel sein… 😉

Die Höhlen waren bestimmt mal schön, sind jetzt aber schon ziemlich zerstört. Aber da sie nicht wirklich schwierig sind, ist es eine gute Anfänger-Tour. Anbei wieder ein paar nette Links:

• Beschreibung und Höhlenkarte bei Cave-Climbers
• Beschreibung und drei Bilder zur Wundershohle bei Cave-Seekers
• amüsante Beschreibung von Peter Kolesch
• Glücklose Vermisstensuche in der Witzenhöhle
  Besonders cool finde ich den angeforderten Retter, der einfach wie geplant in die Schönsteinhöhle gegangen ist, angeblich um dort zu suchen. Klar, ohne Jeans läuft man erst mal 3km den Wald bevor man sich in eine Höhle "stürzt"… 😉
• Abschnitt zur Witzenhöhle aus Bechsteins Deutsches Sagenbuch. Hier wird der Name erklärt.

Siehe auch Links zur Bismarckgrotte, zur Schönsteinhöhle und zum Alfelder Windloch.

Inspiriert durch die Serie zu den Ursachen von Datenbank-Defekten mag ich noch ein paar Fallstricke bei der Datensicherung loswerden. Beispielsweise fand ich persönlich den Fall eines Kunden besonders tragisch, der eigentlich alles richtig gemacht hat.

Ein Kunde machte gewissenhaft tägliche nächtliche Sicherungen nach einem Generationenprinzip und legte sie in den Safe.

Das Problem kam mit dem Hochwasser im letzten Jahr: Dem Schlamm fielen die Rechner zum Opfer. Die Bänder leider auch, denn der Safe stand ebenfalls im Keller.

Wenn ich mich richtig erinnere konnte die beauftragte Rettungsfirma noch vergleichsweise viele Dateifragmente "retten". Aber für eine Datenbank-Rettung reichen üblicherweise Fragmente nicht…

Update: Ich halte nichts von dem erhobenen Zeigefinger: "So und so muss Dein Backup aussehen." Das interessiert einen meist ja doch erst, wenn man betroffen ist: "Der Pfarrer predigt nur vor den Frommen!" 😉
Aber vielleicht inspiriert dieser tragische Fall ja doch jemanden die ernste Seite des Themas zu erkennen und sein Sicherungskonzept zu kontrollieren?

Im SQL-Team-Weblog hat MLaden einen Performancevergleich von verschiedenen Datenimport-Methoden aus Dateien veröffentlicht:

SSIS – FastParse ON = 7322 ms
SSIS – FastParse OFF = 8387 ms
Bulk Insert = 10534 ms
OpenRowset = 10687 ms
BCP = 14922 ms

Dabei war alles auf einem Testgerät installiert: Datei, SQL-Server und Client. Ich hatte nicht erwartet, dass OpenRowSet mit Bulk-Insert in der gleichen Liga spielt. Das der SSIS noch so viel schneller ist, hatte ich auch nicht erwartet.

In unserer Firma steht für jeden Mitarbeiter ein Telefonlogbuch (Siemens HiPath) zur Verfügung. Da kann man alle Telefonaktionen sehen: wer hat angerufen, hat er mich erreicht, hat ein anderer den Anruf übernommen (wer), wen habe ich angerufen usw.
Bis vor kurzem durften wir eine ausgezeichnete Eigenentwicklung eines Kollegen nutzen, aber nun müssen wir uns mit der offiziellen Schmalspurversion begnügen, die vom Hersteller kommt. Schade, aber wir sind ja dankbar, dass wir sowas jetzt auch endlich haben… 😉

Wenn ich in einer Besprechung war und ich die Zeit dafür habe, dann schaue ich gerne in mein Telefonlogbuch. Heute rief ich wieder mal zwei Kollegen zurück, die vergeblich versucht hatten mich zu erreichen.
Dabei passiert es immer wieder, dass einige ganz platt sind, wenn ich sage: "Sie haben ja heute um 12:33 Uhr versucht mich zu erreichen. Ist das noch aktuell, kann ich Ihnen noch helfen?" . . . (Magie? Gedankenübertragung? Aah, der ist vorhin einfach nicht rangegangen!)
Das Werkzeug kennt eben noch nicht jeder… 😉

Seitdem wir das Logbuch haben kam es imerhin auch nicht mehr vor, dass jemand behauptet, er hätte dann und dann den ganzen Tag vergeblich versucht mich zu erreichen…
So eine Telefonanlage verbessert doch ungemein das Betriebsklima. Obwohl Klima bei der Hitze eigentlich das falsche Stichwort ist.

Mit diesem Posting schließe ich die Serie über die Ursachen für Datenbank-Defekte (vorerst?) ab.

Die letzte potentiele Ursache ist unter Umständen schwierig festzustellen. Defektes RAM führt gerne zum Fehlermeldungen im Errorlog des SQL-Servers und zum SQL-Dumps. Wenn es aber nur wenige defekte Speicherzellen sind, dann äußert sich das eher sporadisch und wird auch nicht gleich bemerkt.
Früher oder später werden dann auch im Buffer des SQL-Servers Seiten verbogen. Sind nur wenige Bytes betroffen, dann bemerkt der SQL-Server-2000 das nicht. Und sobald diese Seiten in die Datenbank-Dateien zurückgeschrieben werden, hat auch die Datenbank einen "Treffer". In einem Fall hatten wir mal Probleme, weil in der Systemtabelle in der die Tabelleninformationen gespeichert werden, für eine Tabelle "plötzlich" ein falscher Name drin stand: Anstelle von "u_anl_…" stand dort "u_bnl_…". Das kann eigentlich nur sowas gewesen sein.

Am SQL-Server-2005 werden von den Seiten Checksummen gebildet und kontrolliert. Mir ist aber nicht bekannt, wann die Checksummen berechnet und kontrolliert werden. Als positiver Mensch gehe ich davon aus, dass die Checksumme gleich mit der Änderung der Seite berechnet wird. In diesem Fall könnten auch Probleme im Hauptspeicher bemerkt werden.

Der EDV-Partner eines Kunden hat einmal nach einem Datenbank-Defekt so lange alles geprüft bis er feststellte, dass der Hauptspeicher vom Raid-Controller einen Schlag hatte. Ich habe keine Ahnung, wie er das festgestellt hat, aber es hat mich schwer beeindruckt.

Zuletzt noch ein Hinweis von Microsoft, den ich in der Praxis selber noch nicht erlebt habe:
You may notice unpredictable behavior on a multiprocessor computer that is running SQL Server 2000 and has the Physical Addressing Extensions (PAE) specification enabled.

Hast Du weitere Ursachen ausmachen können? Dann hinterlasse bitte einen Kommentar.

Vorherige Postings zu Ursachen von Datenbank-Defekten:

• skurrile Gründe im ersten Teil
• Probleme mit Festplatten im zweiten Teil
• Datenverluste durch eine defekte Datensicherung im dritten Teil
• systemnahe Programme, die den I/O umbiegen, im viertel Teil

Zufälle gibts schon manchmal… Heute früh habe ich einen Ordner mit alten Artikel von den Achtzigern bis zu den frühen Neunzigern aussortiert und fast alle weggeworfen. Dabei fiel mir der Artikel "Real Programmers Don't Use Pascal" besonders auf. Den fand ich schon immer klasse! Ich frage mich, ob das auch Entwickler der letzten Generation witzig finden…

Und gerade eben finde ich bei pd.blog (Danke Patrick) den Link auf eine Übersicht über die Popularität einer Programmiersprache. Und Pascal liegt sogar auf Position 16. Unglaublich!

Vielleicht bin ich ja morgen vor der Putzfrau im Büro und kann den Artikel noch retten… 😉