Glorf IT

Ein paar Driver (seltsamerweise werden sie mit "Treiber" übersetzt, dabei treiben sie genauso wenig wie sie fahren) kommen dieser Tage für den Microsoft SQL-Server-2005 raus:

• Download details: SQL Server 2005 JDBC Driver 1.2
• Download the SQL Server 2005 Driver for PHP (coming soon)

Wer weiß, vielleicht sind gerade die driver days…

Beim nächstes Treffen der PASS-Franken geht es um das Thema "SQL Server 2005 Integration Services". Referent ist Berthold Neumann, der zu dem Thema sogar schon Buchbeiträge geschrieben hat.

Es findet am 23. Oktober 2007 um 18:00 Uhr statt. Die letzten Treffen waren sehr ergiebig und lustig! Eine angenehme Kombination. Es waren bisher immer Leute mit sehr viel Erfahrung und Know-How dabei. Dadurch waren die Diskussionen sehr interessant. Ich freue mich schon.

Gugst Du hier…

Mein Kollege Markus machte mich auf einen brandneuen MSDN-Artikel aufmerksam, der mit Sicherheit von uns ausgelöst wurde. Wir haben einfach die Konstellation, dass der Adminstrator des File-Servers nicht auch zugleich der SysAdmin des Datenbank-Server ist. Und in der Datenbank liegen richtig sensible Daten. Leider geht Microsoft per Definition davon aus, dass es nur "den Administrator" gibt. Deswegen kann sich der Admin immer auf die eine oder andere Weise Zugang zu den Daten verschaffen, wenn es es nur möchte ("by design"). Dazu haben wir schon die eine oder andere sehr intensive Diskusision mit Microsoft geführt, gerade erst wieder im Juli/August.

Jedenfalls geht Microsoft jetzt auch in der Knowledgebase auf das Thema ein und beschreibt, wie man es einem Windows-Administrator "erschweren" kann sich Zugang zu den Daten zu verschaffen: Die Betonung liegt dabei auf "erschweren", denn verhindern kann man es nicht…

Details gibt es hier: "How to make unwanted access to SQL Server 2005 by an operating system administrator more difficult".
Das "more difficult" finde ich einfach witzig… 😀

"Damals, zu einer Zeit in der Lügen noch geholfen hat…" (so beginnen bei Kpt. Blaubär die Märchen, die er seinen Neffen erzählt) sollte es einmal ein neues Dateisystem geben, dass vollständig in den SQL-Server integriert war: WinFS sollte das Baby heißen. Aber es zeigte sich, dass das Kind nicht gewollt war und deswegen wurde das Projekt begraben. Die Entwickler der aufgelösten Arbeitsgruppe beteuerten, dass deren Erkenntnisse in den SQL-Server eingehen würden, aber niemand glaubte Ihnen. Im SQL-Server-2005 war tatsächlich nicht ein Hauch davon zu erkennen. Das wunderte indes niemanden…

Aber was hören wir da vom SQL-Server-2008? Sollten wir uns alle getäuscht haben? Das neue Kern-Feature heißt: "Filestream"

The proliferation of digital content has significant implications for the way in which organizations store and access business data. Increasingly, databases that are at the core of business applications must be integrated with unstructured data in the form of documents, images, video content, and other multimedia formats. Organizations increasingly need to be able to store and manage digital data of all formats in order to manage the information lifecycle, meet compliance requirements, and implement content management solutions.

Hier stehen mehr Infos dazu: "Managing Unstructured Data with SQL Server 2008"

Als ich heute im ".Net Briefing" las, dass man jetzt der neue Astoria September CTP verfügbar sei, musste ich erst mal nachlesen was das überhaupt ist. Der CTP kam sogar schon vor 3 Wochen raus und ging mir irgendwie durch die Lappen…

Auf der Microsoft-Seite zum Project Codename "Astoria" wird es erklärt:

The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over HTTP, and URIs are used to identify the various pieces of information available through the service. Interactions with the data service happens in terms of HTTP verbs such as GET, POST, PUT and DELETE, and the data exchanged in those interactions is represented in simple formats such as XML and JSON.

Irgendwie wird das ganze Gebiet rund um den SQL-Server immer größer und sumpfiger. Diejenigen, die da noch den Überblick haben, bewundere ich… 😉

Mein Kollege Clemens machte mich gestern auf den Artikel "Top 10 Things You Should Know About Optimizing SQL Server Performance" auf quest.com aufmerksam. Er enthält jetzt keine atemberaubend neuen Erkenntnisse, fasst aber die "üblichen Verdächtigen" sehr schön zusammen. Besonders amüsant finde ich den Titel des Kapitels "THE HORROR OF CURSORS (AND OTHER BAD T-SQL)".

Vom Level her würde ich sagen: 200. Also eher für leicht Fortgeschrittene TSQL-Entwickler.

Weil ich demnächst wieder eine Feierabend-Schulung zum Thema XML im SQL-Server halte, habe ich mir die neuen XML-Features im SQL-Server-2008 mal angelesen. Wie es aussieht, ist kein großer Wurf dabei, eher Detailpflege und Verbesserungen bestehender Features. Der große Wurf an dieser Stelle kam eindeutig mit dem SQL-Server-2005. Das kommt mir sehr gelegen, weil ich mit dem SQL-Server-2008 noch weiter nichts gemacht habe… 😉

• Erweiterungen rund um das Schema und neue Deklarationsmöglichkeiten, z.B. eine "laxe" Validierung und den List-Typ
• XQuery-Erweiterungen, wie z.B. "let" für Variablen. Bisher fehlte das "L" in "FLOWR". Das war nicht schön, aber ging auch.
• im XML-Insert können jetzt Variablen benutzt werden.

Wen das Thema interessiert, der findet Details im Dokument "What's New for XML in SQL Server 2008".

In der Serie “Vorschläge zur Datensicherung mit SQL-Server” gab es bisher folgende Beiträge:

1. Teil – Informationen zum Umfeld und zum Verständnis
2. Teil – Vorgehen beim Offline-Backup
3. Teil – Online-Vollsicherung
4. Teil – differentielle bzw. inkrementelle Online-Sicherung

In diesem letzten – längst überfälligen – Artikel aus der Serie stelle ich die “Snapshot”-Sicherung vor. Es gibt zwei Arten einen Datenbank-Snapshot zu erzeugen, mir geht es primär um die zweite:

• Eine Online-Kopie im laufenden Betrieb, die einen "Snapshot" der Datenbank erstellt. Dazu werden interne Mechanismen des SQL-Servers verwendet.
• Ein Backup-Programm zieht im laufenden Betrieb eine Kopie der Datenbank-Dateien. Das Backup-Programm nutzt dazu den "Volume Shadow Copy Service" (VSS), der sich mit dem SQL-Server koordiniert.

SQL-Server-Snapshot-Backup

Ab der Version 2005 kann die Enterprise-Edition des SQL-Servers im laufenden Betrieb eine Kopie der Datenbank ziehen, die dann für rein lesende Zugriffe genutzt werden kann. Das ist natürlich auch so eine Art von Sicherung, die aber dann doch auf der gleichen Kiste gespeichert wird, wie das Original. Daher fällt das für mich eher in die Kategorie "schnelle Verfügbarkeit".

Wer sich für das Thema interessiert dem empfehle ich den Artikel "SQL Server 2005 Snapshots" von Andrew Calvett oder SQL Server 2005: When and how to use Database Snapshots von Greg Robidoux.

Volume Shadow Copy Service (VSS)

Im laufenden Betrieb können Datenbank-Dateien auf Datei-Ebene nicht kopiert werden. Die Dateien sind vom SQL-Server exklusiv geöffnet. Daher kann eine normale Sicherung die Dateien nicht kopieren. Das führt in der Vergangenheit dazu, dass die Datenbank-Dateien gerne vergessen wurden. Ich erlebe es leider regelmäßig, dass Kunden zwar fleißig die Bänder wechseln, aber nicht das Sicherungslog ansehen und daher gar nicht wissen, dass deren SQL-Server-Datenbanken nicht gesichert werden konnten. Bis zu mir oder meinen Kollegen kommen die Kunden übrigens nur dann, wenn deren Datenbanken defekt sind. Dann ist es natürlich schon zu spät…

Um dem Kunden das Leben zu erleichtern führte Microsoft mit Windows 2003 den schicke "Volume Shadow Copy Service" (VSS) ein. Dieser Dienst ermöglicht das Kopieren von geöffneten Dateien der SQL-Server-Datenbanken. Dazu muss man in der Regel nichts weiter tun, das Bindeglied zwischen dem SQL-Server und dem VSS kommt bereits bei der Installation mit: der VSS-Writer. Jede moderne Sicherungssoftware sollte das Feature bereits unterstützen.

Der interne Ablauf ist etwa so: Die Sicherungsoftware wendet sich an den VSS und sagt, dass bitte alle Dienste (die das unterstützen) die Daten sichern sollen. Der VSS schaut daraufhin seine Liste der registrierten "VSS-Writer" durch und benachrichtigt sie. Der VSS-Writer des SQL-Servers weist den SQL-Server an eine Kopie der Datenbanken zu erstellen. Das geht vergleichsweise schnell, weil genaugenommen nur die Unterschiede in den Dateien (eine Art DIFF) seit der letzten Sicherung rausgeschrieben werden. Intern speichert der VSS in seinen "shadow copy cache" maximal 64 Snapshots, aber auch nur, wenn auf dem Laufwerk genug Platz bereitgestellt wurde.

Die genauen Abläufe werden sehr detailliert im MSDN-Artikel "SQL Writer in SQL Server 2005: A Guide for SQL Server Backup Application Vendors" beschrieben. Das Handbuch ist auch ganz gut.

Vorteile

• Diese Methoden sind sehr schnell.
• Diese Methoden ermöglichen einen 7×24-Stunden-Betrieb.
• Jede normale Sicherungssoftware unterstützt das Verfahren.
• Die Rücksicherung ist einfach.

Risiken und Nebenwirkungen

• Für diese Sicherungsmethode muss man erst mal den VSS konfigurieren.
• Man benötigt Windows Server 2003.
• Der SQL-Server muss so konfiguriert sein, dass jeder im System-Kontext laufende Dienst SysAdmin-Rechte hat. Das ist allerdings nach der Default-Installation sowieso der Fall und stört vermutlich nur die wenigen, die besonders viel Wert auf Sicherheit legen.

Mein persönliches Resümee:

Diese Sicherungsmethode eignet sich vor allem für professionelle Nutzer, die viel Wert auf eine aktuelle Datensicherung legen. Man kann damit den Rund-um-die-Uhr-Betrieb realisieren und kann den Standard-Ablauf der gängigen Datensicherungssoftware nutzen.

Heute schickte mir ein Kollege eine ganze Reihe von SQL-Statements und bat um Unterstützung. Dabei handelte es sich um vergleichsweise komplizierten Code mit mehreren Joins, derived-Tables usw. Besonders interessant war, dass er pro SQL-Statement genau eine Zeile benötigte.

Nun bin ich schon so lange im Geschäft, dass ich mich noch gut daran erinnere, dass es früher mal C-Programmierer gab, die ihren ganzen Ehrgeiz darein legten möglichst den ganzen Algorithmus in eine Zeile C-Code zu packen. Aber auch damals gehörte ich schon zu denjenigen, die so einen Code nicht lesen konnten. Also machte ich mich heute daran die Befehle zu verhübschen (Zeileneinschübe, Tabs einfügen, …). Das hielt ich immerhin 4 Statements lang durch (danach benötigten die Befehle meist 20-25 Zeilen). Es lohnte sich immerhin, weil mir danach sofort ein paar Ungereimtheiten auffielen, aber spaßig war das nicht.

Deswegen fand ich nach kurzer Suche einen Online-Dienst, der einem dabei hilft. Es handelt sich um ein Java-Applet, dass komplett am Browser ausgeführt wird. Es wird also kein Code an einen Server geschickt. Ich persönlich finde das Ergebnis prima – kein Vergleich zu dem Spaghetti-Code…

Hier ist er: SQL Formatter

Das JAR-File kann man auch downloaden und lokal nutzen. Das habe ich aber noch nicht ausprobiert. Ein API ist in Vorbereitung.

Eine andere Alternative findet man unter SQL-Parser (ebenfalls online und als Desktop-Version, lezeres ebenfalls nicht von mir ausprobiert).

Für alle, die letzten Dienstag auf dem PASS-Treffen in Nürnberg waren: Wir rätselten, wie man für eine Sperre feststellen kann, welche Ressource betroffen ist. Es geht hier um die Info, die z.B. mit sp_lock angezeigt wird.

Ich fand dazu doch keine Info im SQL-Server-Magazine. Aber das ist recht gut und ausführlich in den Books-Online bei "sys-dm_tran_locks" beschrieben. Wenn man die View abruft, dann kann man anhand der Datenbank–ID und der Ressource-ID (steht in "resource_description") feststellen, welches Objekt genau gesperrt wurde. Dazu benötigt man noch die Datenbank-ID (siehe unten) und ggf. die ID der übergeordneten Ressource (resource_associated_entity_id ), die enthält z.B. meist die "heap or b-tree ID" falls eine Seite gesperrt wurde.
Wegen der vielfältigen Möglichkeiten ist es nicht ganz unaufwändig dafür eine allgemeine Interpretationsfunktion zu schreiben.

Dabei muss man beachten, dass die Objekt-IDs jeweils auf eine Datenbank bezogen sind. Aber das kann man mit einem neuen Feature des SQL-Servers-2005 lösen. Während man früher für die Funktion "object_name()" immer sicherstellen musste, dass man in der richtigen DB war, kann man heutzutage die relevante Datenbank angeben.

Bisher (geht immer noch):

use northwind
select object_name(21575115);
–> Orders
go
use Adventureworks
select object_name(21575115);
–> uspLogError

Jetzt möglich:
use master
select object_name(21575115, db_id('Northwind'));
–> Orders

Damit kann man eine Auswertung schreiben, die neben der internen Angabe der Sperren auch das Objekt im Klartext nennt: Fleißige vor…

In der September-Ausgabe von TecChannel-Compact (04/2007) ist ein sehr interessanter Test über die Zuverlässigkeit von externen Festplatten.
Der gleiche Artikel findet sich auch online unter dem Titel "Sicherheitsrisiko: Externe Festplatten im Test" (http://www.tecchannel.de/storage/komponenten/451265/).

Insgesamt schneiden die externen Platten gar nicht so schlecht ab, aber in Punkto Hitze wurden sehr bedenkliche Werte gemessen. Laut Datenblättern laufen die Festplatten im Bereich von 5 bis 35Grad Celsius einwandfrei. Darüber erhöht sich die Ausfallrate erheblich, ab etwa 60Grad ist dann auf jeden Fall Sense. Vermutlich steigt ihnen die Hitze zu Kopf. 😉
In dem Artikel wurden einige externe Platten bei verschiedenen Umgebungstemperaturen betrieben und deren Temperatur gemessen. Dabei kamen schon bei 30Grad Umgebungstemperatur etliche Festplatten an oder über die magische 60Grad-Grenze.
Mein Resümee war bei externen Platten für die Datensicherung auf Geräte mit Gehäuselüfter zu setzen…

Im SQL-Server-2005 wird zwischen Sessions und Connections unterschieden. Als ich das in dieser Woche bemerkte, musste ich ziemlich lange suchen bis ich den Unterschied bzw. die Zusammenhänge verstand:

Eine Session in SQL-Server-2005 ist das, was "früher" der System-Prozess war, den man in der Systemtabelle "sysprocesses" beobachten konnte. Jede Session hat eine Session-ID, die exakt dem entspricht, was bisher die SPID (system process ID) war. Neben den Session, die von Benutzern kommen, gibt es auch eine ganze Reihe von Sessions, die vom SQL-Server zur internen Verwaltung genutzt werden ("internal tasks"). Wie bisher sind sie daran erkennbar, dass deren Session-ID kleiner als 50 ist.
Informationen über Sessions kann man aus der Dynamic-Management-View (DMV) sys.dm_exec_sessions erfahren. Darin stehen neben den "bisherigen" Infos auch jede Menge Eigenschaften der Session, z.B. die aktuell gesetzten Werte der einschlägigen Settings, z.B. den Isolation-Level oder den Lock-Timeout. Sehr praktisch!

Jede Verbindung, die von "außen" zum SQL-Server aufgebaut wird, ist eine "Connection". Jeder Connection ist genau eine Session zugeordnet. Ich habe lange rumgerätselt, ob eine Session auch mehrere Connections haben kann, das ist zwar laut Doku möglich, ich fand aber keinen Hinweis darauf in welchen Fällen das wie gehen soll. Aber es scheint so zu sein, dass eine Connection nacheinander mehrere Sessions haben kann. Das scheint bei SOAP-Verbindungen relevant zu sein.
Connection-Informationen stehen in der DMV sys.dm_exec_connections. Hier finden sich dann auch die Netzadresse des Clients, das Login und solche Dinge. Schick ist, dass es pro Connection eine eindeutige unique ID gibt. Damit hat man endlich eine brauchbare ID, die nicht nach Beenden der Connection sofort wieder verwendet wird, wie das bei der SPID ist.

Daneben gibt es übrigens auch noch den Request. Jede Session kann mehrere Request ausführen. Darin wird das auszuführende SQL-Statement hinterlegt, die Transaktion, der Zugriffsplan usw.
Diese Infos stehen unter sys.dm_exec_requests. Neben den oben genannten Dingen stehen hier auch Status, Blockierungsinformationen und I/O-Informationen.

Für weitere Infos zu dem Thema empfehle ich den Artikel "Dynamic Management Views" auf SQLTeam.com.