Glorf IT

Mein Kollege Hans machte mich gestern auf das Dokument "Description of using disk drive caches with SQL Server that every database administrator should know" von Microsoft aufmerksam. Der Hintergrund sind weitgehend unbekannte oder besser ignorierte Ursachen für zerstörte Datenbanken. Tatsächlich sollte jeder Admin über die Risiken Bescheid wissen, denen man bei der Default-Konfiguration von PCs und Servern ausgesetzt ist.

Konkret geht es um die verschiedenen Caches, die so ein Datensatz durchlaufen muss, bis er endlich echt auf der Platte gesichert wurde. Treue Leser werden bei mir auch schon den einen oder anderen Hinweis dazu gelesen haben… 😉

Schön finde ich, dass hier endlich mal alle Dokument zu einem zusammengefasst werden.

PS: In der (automatischen) deutschen Übersetzung lautet der Titel übrigens "Mit SQL Server zwischenspeichert Beschreibung von Verwenden von Laufwerk dass jeder Datenbank-Administrator kennen sollte". Noch Fragen?

Das kommt darauf an. SQL an sich ist schon immer case-insensitiv, d.h. ob man die SQL-Schlüsselwörter groß oder klein schreibt ist allein eine Frage des Geschmackes oder der Konvention. Das bin ich jetzt seit 18 Jahren so gewohnt, ich finde klein praktischer. Dennoch schreibe ich in letzter Zeit auf häufigen Wunsch eines einzelnen Kollegen in meinen dienstlichen Beispielen und Musterlösungen immer alle SQL-Schlüsselwörter groß. Ich versuche es wenigstens…

Das gilt aber nicht für die Datenbank-Objekte. Hier bestimmt die Collation, die beim Anlegen der Datenbank angegeben wurde, ob die Namen der Tabellen, Views, Procedures, User, etc. case-sensitiv oder -insensitiv sind. Wurde hier eine case-sensitive Collation angegeben, dann werden die Systemtabellen mit dieser Collation angelegt. Die Folge ist, dass alle Objektnamen exakt richtig geschrieben werden müssen.
Aber selbst wenn man eine case-insensitive Collation gewählt hat, dann ist es schlau immer auf die richtige Schreibweise zu achten, damit man die Collation später mal einfach ändern kann.

Wem das zu viel Stress ist, der kann das auch einfach ignorieren und auf die Schreibweise pfeifen. Wenn er die Collation später mal ändern will, dann muss er einfach die Datenbank mit einer case-insensitiven Collation anlegen, aber dann beim Anlegen der Tabellen für jedes einzelne String-Feld (varchar, char, text, mit und ohne n) die "richtige" case-sensitive Collation angeben. Dann sind die Systemtabellen case-insensitiv, die eigenen Tabellen hingegen case-sensitiv.

Variablen und Cursornamen sind übrigens immer case-insensitiv.

Gestern fühlte ich mich wie in einem der alten Sierra-Adventures. Ein Kollege benötigte just dann meine Unterstützung als ich eigentlich zum Zug aufbrechen wollte. Hinterher hatte ich noch 20 Minuten bis zum Nächsten und wollte die Gelegenheit nutzen, um ein paar Dinge auf DVD zu archivieren.

Als ich bei unserem Brennerrechner (anderes Gebäude) ankam, musste ich feststellen, dass mein geheimes Versteck, in dem ich drei DVD-Rohlinge gebunkert hatte, offensichtlich aufgeflogen war. Jedenfalls war kein Rohling mehr da. Das ist natürlich kein Problem: im Sekretariat (anderes Stockwerk) haben wir ja normalerweise jede Menge davon. Als ich dann vor der verschlossenen Tür stand, dämmerte mir schon, dass es um diese Uhrzeit nicht mehr so einfach werden würde.

Aber ich weiß ja, dass in dem Schlüsselkasten im Büro eines Kollegen (anderes Stockwerk) für solche Fälle ein Schlüssel für das Sekretariat hängt. Und ich hatte Glück, jemand war dort, der Schlüsselkasten offen und der Schlüssel da. Das half mir aber auch nicht weiter, weil die Schränke im Sekretariat ebenfalls verschlossen waren. Die Schlüssel hängen natürlich im dortigen Schlüsselkasten zu dem sonst niemand einen Schlüssel hat.

OK, nächster Anlauf: Rumfragen, ob mir einer einen Rohling geben kann. Meine Kollegin Beate machte mich schließlich auf den Brenner im Testraum aufmerksam. Im nahe gelegenen Testraum war auch tatsächlich noch ein freundlicher Kollege, der sofort im Schrank nachschauen wollte. Aber der Schrank war verschlossen, der Schlüsselkasten auch schon. Kein Problem, er machte sich sofort auf den Weg zu seinem (nicht so nahe gelegenen) Büro, um den Schlüssel zu holen. Als er wiederkam hatte er nicht wie von mir erwartet den Schlüsselkastenschlüssel geholt, sondern einen Schrankschlüssel, der aber nicht passte.

Bei einem echten Sierra-Adventure hätte ich jetzt einen Kollegen finden müssen, der mir beibringt, wie man mit einer Büroklammer Schränkschlösser öffnet, wenn ich für ihn einen Quest löse. Aber um den nächsten Zug nicht auch noch zu verpassen, dankte ich ihm und gab auf… Heute früh stellte sich übrigens heraus, dass im Sekretariat auch keine Rohlinge mehr waren, nur noch ein paar DVD+RWs.

Ich weiß schon, warum ich in der Firma so ungerne Dinge auf DVD archiviere. 😉