Glorf IT

Wer sich demnächst mit dem SQL-Server-2008 rumschlagen muss oder ein paar richtig gute Vorträge zu fortgeschrittenen Themen im Bereich SQL-Server besuchen will, dem empfehle ich den "Solid Quality Summit" vom 26. bis 30.5.2008 in Wien. Ich denke schon alleine die "PostConference Class" am Freitag mit Itzik Ben-Gan zum Thema "Advanced T-SQL Querying and Programming" ist die Reise auf jeden Fall wert! Ich durfte diesen Kurs in London belegen und habe damals unglaublich viel gelernt.

Hier ist die Liste der restlichen Vorträge: Course Schedule

PS: Heute werden meine Posting wohl etwas kürzer. Die Handwerker machen einen unglaublichen Radau, der sich über die Heizkörper in jedes Zimmer überträgt… Der arme Hund ist schon ganz fertig.

Was man so bei Heise-Online liest ist ja ziemlich ernüchternd. Es gibt sogar ein chinesisches Tool mit dem sich einfach eine anfällige Seite finden und übernehmen lässt. Die "Zielgruppe" ist nicht gerade eine Werbung für Microsoft:

Das Windows-Werkzeug mit chinesischer Bedienoberfläche sucht mit der Google-Suchmaschine nach verwundbaren Servern und kann dann eine SQL-Injection-Attacke ausführen, die in den aus der Datenbank generierten Webseiten einen iframe einfügt, der den Code zum Angriff auf die Webseitenbesucher nachlädt.

Der voreingestellte iframe in dem Tool enthält denselben Link, der Anfang des Jahres auf zahlreichen der manipulierten Webseiten auftauchte. Die Angriffe scheinen auf den Microsoft-SQL-Server sowie den Internet Information Server zugeschnitten zu sein. Das Werkzeug kontaktiert den Analysen des ISC zufolge vor der Nutzung auch einen weiteren Server in China, um offenbar einen Bezahlvorgang anzustoßen.

Jetzt kann Microsoft nichts dazu, dass jemand in seiner Webapplikation SQL-Injection ermöglicht, aber das hilft auch nicht weiter. Wenn man den SQL-Server im Systemkontext installiert, das wird bei der Installation als Option angeboten, dann kann der SQL-Server einfach alles – er hat schließlich Admin-Rechte.

Ruprecht (Dröge?) hat auf dem SQL-Server-FAQ-Blog alle neuen Features des SQL-Server-2008 gesammelt über die schon mal irgendwo berichtet wurde. Teilweise verlinkt er gleich auf die weiterführenden Artikel. Sehr interessante Übersicht, danke!
Sowas fand ich bei Microsoft noch nicht. Oder hab ich es nur übersehen?

Schau mal an: SQL Server 2008 – Neue Features

Hinweis: Dieser Artikel hätte eigentlich am 2.11.2007 zeitgesteuert veröffentlicht werden sollen. Das hat komischerweise nicht geklappt. Leider bemerkte ich das erst jetzt gerade als ich mal meine gesammten Postings in den MySQL-Datenbank zählte…
Weil ich den Eindruck habe, dass die Liste immer noch durch seine Vollständigkeit glänzt, habe ich den Artikel jetzt manuell veröffentlicht.

Heute wurde ich über den SQl-Server-Magazin-Newsletter darauf aufmerksam, dass Kalen Delaney plant alle ihre Schulungen auf DVD rauszubringen. Das ist in merhfacher Hinsicht ungewöhnlich:

• Leute, die von Schulungen leben wollen in der Regel, dass die Interessenten in die Schulung gehen und geben deswegen eher selten zu viele Infos raus.
• Kalen ist eine der Top-Referenten zum SQL-Server. Der Inhalt dürfte also mit Sicherheit spannend sein. Diese DVD-Serie könnte glatt zum Pflichtprogramm jedes angehenden SQL-Server-Entwicklers werden.
• Der Preis von 30 US-Dollar ist wirklich fair! Hey, wir reden hier von derzeit 19 Euro. Und wnen man sich das per Straming ansehen will, dann zahlt man in den kommenden 30 Tagen gerade mal 15 USD (also keine 10 Euro).

Die erste Folge "Lesson 1: Architecture and Metadata" ist jetzt erhältlich und behandelt die Themen:

1. Metadata in SQL Server 2005
2. Process Management
3. Memory Management
4. I/O Management
5. SQL Server 2005 Configuration Tools

Laut Brian Kelley ist der Vortrag nicht ganz 2 Stunden lang und enthält Übungen (inkl. der Skripte auf der DVD). Das ist mit Sicherheit etwas, dass ich für unsere Gruppe bestellen werde, wenn ich wieder ins Büro komme!

Wer wissen will, was da noch auf ns zukommt, der kann sich die originale Beschreibung des 5-tägigen Kurses ansehen. Die DVD behandelt das erste Modul, also den ersten halben Tag.

Passend zu dem Cebit-Leitthema "Green IT" fragte mich heute ein Kollege zu einer Meldung, die der SQL-Server gerne bei unseren Kunden wirft. Meist handelt es sich dabei um die Express-Edition, die auf einem Arbeitsplatzrechner bzw. Laptop läuft:

Error 17896
"The time stamp counter of CPU on scheduler id XY is not synchronized with other CPUs."
bzw.
"Der Timestampzähler der CPU für das Zeitplanungsmodul mit der ID XY ist nicht mit anderen CPUs synchronisiert."

Das ist eine reine Info-Message, die mit SP2 eingeführt wurde. Man kann sie nicht abschalten. Wenn man Pech hat, dann müllt einem diese Meldung nicht nur das Errorlog, sondern auch die Ereignisanzeige voll.

Die Meldungen kommen beispielsweise gerne auf Laptops, die je nach eingestelltem Energie-Schema den CPU-Takt ändern. Das mag der SQL-Server gar nicht gerne, weil sich einige interne Abläufe am CPU-Takt orientieren. In zukünftigen Versionen wollen die MSler das Verhalten ändern. Mal abwarten…
Durch das Umschalten auf das Energie-Schema "Dauerbetrieb" kann man das ändern.

Wenn man auf einem "normalen" Rechner einen Server (z.B. Peer-to-Peer) betreibt, dann sollte er sowieso generell auf "Dauerbetrieb" eingestellt sein, um ständig eine gute Zugriffszeit zu gewährleisten. Aber Achtung: angeblich ändern auch manche Tools den Prozessortakt. Da kenne ich aber keines, kann mich da jemand erleuchten?

Microsoft empfiehlt an dieser Stelle auch das feste Zuordnen von CPUs mit der Affinity-Mask. An anderen Stellen wird generell davon abgeraten. Ich schließe mich der Ablehnung an. Nur echte Experten mit dedizierten Servern für einen SQL-Server mit einer High-Performance-Datenbank sollten das einsetzen.

Hintergrund-Informationen findet man in folgenden Dokumenten:

• "SQL Server 2005 SP2 will introduce new messages to the error log related to timing activities."
• "SQL Server timing values may be incorrect when you use utilities or technologies that change CPU frequencies"

Wie ich jetzt erst bemerke, ist das kummulative Update-Paket für den SQL-Server-2005 schon letzte Woche raus gekommen. Und er bringt eine ganze Latte an Hotfixes auf die wir gewartet haben.
Hier ist eine halbwegs vollständige Liste der enthaltenen Fehlerbehebungen.

Wenn man den Hotfix haben will, dann muss man in einem Online-Formular bei Microsoft nachfragen. Mega-lästig.

Inzwischen weiß es jeder "Microsoft SQL Server 2008" kommt erst später. Weil die den Artikel von Microsoft dazu bestimmt demnächst mal suche, hier der Link zur "Microsoft SQL Server 2008 Roadmap Clarification":

Microsoft is excited to deliver a feature complete CTP during the Heroes Happen Here launch wave and a release candidate (RC) in Q2 calendar year 2008, with final Release to manufacturing (RTM) of SQL Server 2008 expected in Q3.

Das übliche Spiel ist inzwischen schon fast nicht mehr peinlich…

Jetzt steht schon der SQl-Server-2008 vor der Tür und dennoch entdecke ich am SQl-Server-2005 immer wieder Dinge von denen ich vorher noch nie gehört habe. Zum Beispiel entdeckte ich gerade einen Hotfix für die "Replay Markup Language (RML) Utilities for SQL Server".

Was ist denn die "Replay Markup Language"?

You can use the RML Utilities for SQL Server to perform the following tasks:
• You can determine the application, the database, the SQL Server login, or the query that is using the most resources.
• You can determine whether the execution plan for a batch is changed when you capture the trace for the batch. Additionally, you can use the RML Utilities for SQL Server to determine how SQL Server performs each of these execution plans.
• You can determine the queries that are running slower than before.
After you capture a trace for an instance of SQL Server, you can use the RML Utilities for SQL Server to replay the trace file against another instance of SQL Server. If you also capture the trace during the replay, you can use the RML Utilities for SQL Server to compare the new trace file to the original trace file. You can use this technique to test how SQL Server behaves after you apply changes.

Naja, ich bin ja lernfähig. Klingt wenigstens interessant.

Jan stellte in seinem Kommentar eine sehr gute Frage, die ich hier beantworten möchte:

Dann habe ich gleich mal eine Frage an den Profi: Ab wann /bis wann ist es sinnvoll und praktikabel eine Datei in einer Datenbank zu speichern und nicht nur den Pfad der Datei im dazugehörigen Filesystem (Ist es das überhaupt?). Die Last der Datenbank ist ja um ein vielfaches höher als wenn zusätzlich über das Filesystem gelesen und geschrieben wird. Gehen wir mal von eine Fotodatenbank mit vlt. 5000 Bildern à 2MB aus, das sind wir ganz schnell bei knapp 10GB die über die DB verwaltet werden müssen (OK, große Datenmengen sollten nicht das Problem sein, nur fehlt mir da die Erfahrung.). Kennst du dazu vlt. ein paar hilfreiche Quelle bzw. eine anständige Kosten-Nutzen-Analyse?

Zunächst muss man mal sehen, in welchem Bussiness-Sektor wir uns bewegen.

Im privaten Bereich wird man vermutlich die Daten auf der Festplatte des PCs speichern (unter Windows XP oder Vista) oder ein Windows XP/Vista als Peer-Server nutzen. Dann hat man vermultich die "billige" SQL-Server-Express-Edition im Einsatz. Sie kann maximal 4 GBytes große Datenbanken bearbeiten. Dann ist Schluss und man müsste zu der nächst-höheren Standard-Edition greifen. Deswegen kommt es hier meines Erachten aus Kostengründen nicht in Frage die Bilder in die DB zu packen.

Sind wir im professionellen Bereich, dann läuft vermutlich eine SQL-Server-Standard-Edition auf einem Windows-Server-System. Hier gibt es keine Größenbeschränkung.

Performance und Ausfallsicherheit:

Meiner Erfahrung nach machen SQL-Datenbanken auf IDE- und SATA-Festplatten leichter mal schlapp als auf RAID-Systemen. Meist ist auf den PCs nämlich der Schreibcache der Festplatten bzw. deren Controllern aktiviert. Kommt es dann während eines Schreibvorgangs zu einem Stromausfall oder einem harten Reset, kann die Datenbank schon mal kaputt sein. Dann ist man unter Umständen schlecht bedient, wenn man Bilder in einer Datenbank hat. Wer hat schon eine tagesaktuelle Sicherung parat oder ist Experte in Sachen Datenbank-Reparatur?

Schaltet man den bösen Schreib-Cache aus, dann spürt man das in der Performance meistens sehr deutlich, wenn der SQL-Server das nicht mit einem großen Daten-Cache etwas ausgleichen kann. Mit der Express-Edition ist der Cache auf maximal 1 GBytes beschränkt.

Am Server gilt das nicht so stark: hier werden (hoffentlich) schnelle RAID-Systeme eingesetzt, die meist noch mit der USV (unterbrechungsfreien Stromversorgung) abgesichert sind.

Verblüffenderweise ist die Performance in beiden Fällen nicht so gravierend anders als seien die Bilder direkt auf der Platte abgelegt. Je nach API (.Net bekommt im Punkto Laufzeit hier einen Malus) reden wir von 20 bis 50% "Aufpreis". Das klingt nach viel, ich hätte aber durchaus mehr befürchtet.

Handhabung

Als wichtigestes Kriterium würde ich aber heranziehen, wie mit den Bildern gearbeitet werden soll. Wenn man beispielsweise mit einem beliebigen Programm darauf zugreifen will, dann muss man tief in die Trickkiste greifen, wenn sie in einer Datenbank liegen. Im Normalfall kann man weder im Explorer, noch im Bildverarbeitungsprogramm die Bilder sehen, bearbeiten oder speichern, die in einer Datenbank liegen. Ich nutze beispielsweise gelegentlich eine Software, die doppelte Bilder erkennt und dann löscht.
Will man das mit seiner Anwendung erreichen, dann muss man sich in den Explorer "einklinken" und die Bilder so anzeigen als seien sie in einem Dateisystem. Das habe ich noch nicht gemacht und halte es deswegen für nicht so einfach. Gute Dokumenten-Management-Systeme können das aber.
Wahrscheinlich ist es sau schwer, sonst sähe man das öfter… 😉

Aus Gründen der Handhabung würde ich die privaten Bilder deswegen gar nicht in der Datenbank speichern.

Weiterführende Quellen (oder eine Kosten-Nutzen-Analyse) fallen mir gerade nicht ein. Meist wird nur thematisiert wie man Bilder als BOLBs schreibt oder liest. Falls ich noch etwas finde, dann schiebe ich den Link nach.

Alles neu macht der Mai:

Ab dem SQL-Server-2008 wendet sich übrigens das Blatt. Der kennt als neuen Datentyp FileStreams. Da liegen die Dateien "normal" auf der Platte, die Daten werden vom SQL-Server aber mit verwaltet als seien es seine eigenen. Ich denke, dass ist das Vermächtnis des WinFS.
Jetzt müssen wir noch die Daumen halten, dass dies Feature wegen zu vieler Fehler nicht aus der Liste purzelt, sondern wirklich in der Freigabeversion drin ist… 😉

Der SQL-Server-2008 enthält unter anderem die neuen Datentypen GEOGRAPHY und GEOMETRY. Eine sehr lesenswerte Einführung findet man bei Codeproject.com: "Schiffe versenken" in SQL.

Schau mal da: "SQL-Battleship 2008"

Nachdem der CTP5 des SQL-Servers-2008 frisch draußen ist, kommt mir der Artikel von Laurentiu Cristofor über eines der ganz großen Features ganz gelegen: "Transparent data encryption".

Dazu muss man lediglich pro Datenbank festlegen, dass die Datenbank verschlüsselt werden soll und schon muss man sich um weiter nichts kümmern. Naja, fast nichts…

ALTER DATABASE SET ENCRYPTION [ON | OFF].

Sehr schade, dass das nicht schon im SQL-Server-2005 drin war…

Update: Mein Kollege Markus machte mich darauf aufmerksam, dass dieses schicke Feature nur in der Enterprise-Edition (und der Developer-Edition) verfügbar sein soll. Echt schade.

Bei einer Sache bin ich in den letzten Monaten böse reingefallen. Ich beschreibe das mal hier, vielleicht erspare ich anderen damit Kummer…

Beim SQL-Server-2005 kann man sich für einen oder mehrere SQL-Batches, die man in einem Query-Fenster hat mit einem Klick auf "Include actual query plan" den Zugriffsplan anzeigen lassen. Wenn es mehrere Zugriffspläne sind, dann bekommt man pro Query/Zugriffsplan jeweils oben den Wert "Query cost (relative to the batch)" angezeigt. Leider sind die angegebenen Prozentwerte nicht das, was ich erwartet hatte.

Nehmen wir mal an, es seien 3 Queries, für die jeweils die Werte 49%, 42% und 9% angezeigt werden. Dann muss man wissen, dass diese Prozentwerte auf den geschätzen Kosten des Optimizers beruhen. Die echten Zeiten werden nicht gemessen.
Die Prozentwerte beruhen auf den jeweiligen "Estimated Subtree Costs" des obersten Knotens des jeweiligen Ausführungsplanes.
Im Beispiel waren das die Werte 0.266, 0.225 und 0.046.

Wegen des Namens "Query cost" dachte ich, es seien die echten Kosten. Es sind aber die geschätzten Kosten auf denen der Optimizer seinen Zugriffsplan aufbaut.

Und tatsächlich musste ich erst nachmessen: Die tatsächlich gemessenen Zeiten waren in meinem Beispiel 220ms (estimated 49%), 140ms (estimated 42%) und 343ms (estimated 9%).

Resümee: Die als "Query cost" angegebenen Werte darf man nur als Hinweis nehmen, wie der Optimizer damit umging ("estimated"). Man kann daraus keine Performanceaussagen "der unterste ist der Beste" ableiten…

Wer mehr darüber erfahren will, wird auf dem Blog vom SQL Server Query Processing Team fündig.