Glorf IT

Da gerade in letzter Zeit öfters Leute wegen verschiedener Performanceprobleme auf mich zu kommen, habe ich hier mal ein paar gute Links zu dem Thema gesammelt. Sie gehen von der Situation aus, dass das Kind schon in den Brunnen gefallen ist. Die Performance ist schlecht und nun geht es darum rauszufinden warum.

Eine Warnung muss ich allerdings vorwegschicken: Oft genug ist der SQL Server gar nicht der Flaschenhals. Bei einer kürzlichen Performance-Analyse stellte sich heraus, dass die Anwendung über einen bestimmten Mechanismus erreichte, das ein fachliches Objekt nur von einem Anwender gleichzeitig bearbeitet werden konnte. Das war über eine zentrale Sperrdatei am Server gelöst. Aber das gleiche Ergebnis würde es auch bringen, wenn diese Anwendungssynchronisierung über eine Tabelle gemacht würde. Ab einer bestimmten Anzahl an Benutzern wurde das System einfach langsam, weil hier die Anwendungssperren zu schlugen. In einem anderen Fall war das Performance-Bottleneck die Anwendung am Arbeitsplatz, hier dauerte das Aufbauen der Bildschirmelemente furchtbar lange, weil in den Oberflächenelementen immer alle Daten angezeigt wurden, z.B. die Liste der aller Kunden in einer Drop-Down-Box. Das wird nun man langsam, wenn das recht viele sind. Für solche Mengen war die Anwendung offensichtlich nicht ausgelegt. Um fest zustellen wo die Performance bleibt, hilft nur eine Analyse des Netzverkehrs. Dann sieht man genau auf welcher Seite des Netzes die Probleme sind, oder ob es gar das Netz selber ist…

Falls man sich dann sicher ist, das die Performance bei SQL-Server bleibt, dann empfehle ich als Einstieg das TechNet-Dokument "Troubleshooting Performance Problems in SQL Server 2008" von Sunil Agarwal und anderen. Inzwischen ist das Dokument schon fast ein Jahr erhältlich, aber immer noch aktuell.

Als Vertiefung empfehle ich das Buch "SQL Server 2008 Query Performance Tuning Distilled" von Grant Fritchey (aka ScaryDba) und Sajal Dam. Bei Google gibt es eine Vorschau. Das Buch ist aus meiner Sicht günstig für den gebotenen Stoff. Wenn es darum ginge schlechte Performance proaktiv zu vermeiden, dann würde ich eher die Bücher von Itzik Ben-Gan empfehlen.

Zuletzt empfehle ich auch immer gerne die Unterlagen von TechNet-Vorträgen. Franz Robeller und Oliver Goletz stellen auch Ihre Folien und Beispiele der TechNet-Vorträge vom November 2009 bereit. Hier der Download-Link.

Bevor die nächste Ausgabe des TechNet-Magazins erscheint, möchte ich noch auf die Tipps zur Wiederherstellung beschädigter Datenbanken, Empfehlungen zum Verkleinern von Datenbanken und mehr von Paul S. Randal hinweisen. Allerdings komme ich mit den deutschen Übersetzungen nicht so gut zurecht. Das Wort "Snapshotisolierung" könnte zwar noch schlimmer übersetzt werden, aber löst immer erst mal ein kurzes Nachdenken aus. Erst durch den Artikel erfuhr ich übrigens, dass er nun mit Kimberly (vermutlich Tripp) verheiratet ist. War wohl auch der Grund für seinen Rückzug von Microsoft… 😉

Über Klaus wurde ich auf einen durchgesickerten Life-Cycle-Plan von Microsoft-Produkten aufmerksam. Da vergaß der Microsoft-Entwickler Chris Green bei der Erstellung einer Product-Support-Life-Cycle-Übersicht offenbar die noch nicht veröffentlichten Infos rauszufiltern. Daher kann dort sehen, wie der aktuelle Stand der Planung zu verschiedenen Produkten ist. Chris nahm das Dokument inzwischen zwar aus dem Netz, aber bspw. bei Google und Softpedia.com findet man es noch. Darin findet man auch die Planung zu Windows 8 und anderen interessanten Produkten… 😉

Demnach wären für die SQL Server folgende "Product Support Life Cycles" zu erwarten:

• SQL Server 2000: Dezember 2000 bis April 2013
• SQL Server 2005: Januar 2006 bis April 2016
• SQL Server 2008: November 2008 bis Januar 2019
• SQL Server 2008 R2: Februar 2011 bis Juni 2020
• SQL Server 2011: Juli 2011 bis Juli 2021

Neu daran sind freilich nur die zum 2008-R2 und 2011er. Aber gerade die sind für mich aktuell besonders spannend. Denn warum sollte man in 2010 mit dem Umstieg auf den SQL Server 2008 R2 beginnen, der in Bezug auf den SQL-Server-Core kaum Erweiterungen bringt, wenn ein Jahr später die richtige Version kommt? Wenn wir mit der Umstellung fertig wären, dann wäre zudem die nächste Version schon längst freigegeben… Blöd ist nur, dass die Zahlen schon jetzt nicht stimmen, denn der SQL Server 2008 R2 soll ja nun doch erst im Mai kommen. Wird dann aus den genannten verkaufspolitischen Gründen die Freigabe des 2011ers auch verschoben? Das wäre schade.

Im Artikel "Introducing Microsoft Codename Denali ‘the Great One’" auf Softpedia.com tragen sie weitere Puzzle-Teile zusammen. Beispielsweise, dass der SQL Server 2011 den Codenamen "Denali" trägt. Wikipedia sagt zum Mount McKinley:

Ein alternativ verwendeter Name des Berges ist Denali, ein Wort aus dem Athapaskischen, das der Große oder der Hohe bedeutet.

Soso, der große SQL Server kommt dann nächstes Jahr. Da freue ich mich dann schon drauf… 😉

Wie ich heute sah, hat Klaus Oberdalhoff letzte Woche einen Blog gestartet: SQL-Insider.de. Darin geht es um Dinge rund um SQL Server. Bisher sind nur 2 Beiträge drin, aber es kommen sicher noch mehr. Viel Erfolg. Klaus!

Klaus ist bei uns in Franken recht bekannt, weil er seit Jahren die fränkische Regionalgruppe der SQL-PASS leitet. Durch seine freundliche, aber bestimmt Art konnte er bislang immer wieder viele hochkarätige Referenten gewinnen. Bei letzten Vortrag zum Thema Datensicherung mit SQL Server kamen beispielsweise 33 Teilnehmer.

PS: Hallo Klaus, wenn Dein Blog Kommentare erlauben würde, dann hätte ich auch dort gratuliert… 😉

Da jetzt bald wieder eine neue Version des Microsoft SQL Servers auf den Markt kommt, möchte ich auf den Artikel SQL MythBusters – "SQL Server is really a Sybase product not a Microsoft one." hinweisen. Hier beschreibt Euan Garden die Geschichte des SQL Servers aus der Sicht von Microsoft. Da würde mich doch glatt die Sicht von Sybase interessieren…

Etwas differenzierter beschreibt es Kalen Delaney in dem ersten Kapitel des vergriffenen Buches "Inside SQL Server 2000", dass freundlicherweise nun im Internet als PDF zugänglich ist.

Nachdem bei uns das Thema Deadlock wieder als Welle reinschwappt, freute ich mich über einen Einsteiger-Artikel zum Thema Deadlock-Grafen im SQL-Magazine. der Artikel ist frei zugänglich. Normalerweise muss man wenigstens registriert sein oder am besten gleich "Subscriber". Beides ist hier nicht nötig.

Wer weitere Infos zu dem Thema sucht, der findet am Ende Links auf deutlich tiefer gehende Artikel.

In dieser Woche wurde ich auf eine Werbung aufmerksam in der von virtuellen Datenbanken die Rede war. Die Idee ist ebenso einfach wie bestechend: Offenbar ist die Software in der Lage eine Backupdatei des Microsoft SQL Servers wie eine virtuelle Datenbank "anzuhängen" und zugreifbar zu machen. Das wäre schon echt klasse: Wenn bisher jemand versehentlich einen Bestand gelöscht hat, dann muss man die gesicherte Datenbank parallel zur bestehenden wiederherstellen und dann mit der Software die Daten eines Bestandes exportieren und in die aktuelle Datenbank importieren. Wenn man auf die virtuelle Datenbank nun mit der Anwendung wenigstens lesend drauf könnte, dann würde der Zwischenschritt des Wiederherstellens komplett entfallen. Das könnt die knapp 500 USD schon wert sein.

Andererseits kann ich mir nicht vorstellen, dass die Software die ganzen MS-APIs unterstützt, so heißt es aber in der Beschreibung ("Use all native and third-party tools to access virtual database"). Vermutlich kann man nur mit den Werkzeugen drauf oder denkt der SQL Server wirklich, das sei eine Datenbank? Hat schon jemand Erfahrung mit "SQL virtual database" von Idera? Das Video hat mich jedenfalls schwer beeindruckt. Leider weiß ich jetzt schon, dass es lange dauern wird, bis ich mich damit mal beschäftigen kann… 🙁

Auf sourceforge.net findet man eine Doku von sp_cursoropen. Das ist besonders dann interessant, wenn man in einem Profiler-Trace ein sp_cursoropen findet und sich fragt, was denn da wohl für ein Cursortyp dahinter steckt.

Das bedeutet beispielsweise, dass eine 16 im dritten Parameter (@scrollopt) auf den Cursortypen "Fast forward-only cursor" hinweist, was dem "Default Result Set" bzw. "Firehose Cursor" entspricht. Das ist dann der Idealfall. Alle anderen Cursortypen sind langsamer, wenn nur das Lesen der Daten im Vordergrund steht.

Mein Kollege Diethard machte mich auf einen Fehler im Microsoft SQL Server 2005/2008 aufmerksam, der bei Microsoft schon bekannt ist: Wenn man (*) als erstes nach in einem Zeilenkommentar schreibt, dann kommt ein Syntaxfehler.

Hier ein Beispiel:

--(*)

Weil das so kurz ist, hier ein hübsches Repro von Diethard:

RAISERROR('--(*)',0,0);
GO
--(*)
GO
RAISERROR('-- (*)',0,0);
GO
-- (*)
GO
/* Results
--(*)
Msg 102, Level 15, State 1, Line 1
Falsche Syntax in der Nähe von '--(*'.
-- (*)
*/
GO
RAISERROR('COUNT(1) --(*)',0,0);
GO
SELECT COUNT(1) --(*)
	FROM sys.sysobjects
GO
RAISERROR('COUNT(1) -- (*)',0,0);
GO
SELECT COUNT(1) -- (*)
	FROM sys.sysobjects
GO
/* Results
COUNT(1) --(*)
Msg 102, Level 15, State 1, Line 1
Falsche Syntax in der Nähe von '--(*'.
COUNT(1) -- (*)

-----------
1946
*/

Weil Microsoft dem so wenig Bedeutung beimisst, wird es vermutlich erst am St.Nimmerleinstag beseitigt, bemerkte ich ihm gegenüber. Daraufhin erstellte Diethard einen Algorithmus, ob der Tag schon gekommen ist:

DECLARE @AfterStNimmerlein bit;
BEGIN TRY
  EXEC('--(*)'); SET @AfterStNimmerlein = 1; 
END TRY BEGIN CATCH
  IF ERROR_NUMBER() = 102 SET @AfterStNimmerlein = 0; 
END CATCH; 
SELECT AfterStNimmerlein=@AfterStNimmerlein;

😉

Aber was uns wirklich interessieren würde: Wie kann es zu einem Syntaxfehler in einem Kommentar kommen?

Klaus – unser Regionalgruppenleiter der örtlichen SQL-PASS – wies mich auf ein paar kostenlose Webcasts zu Performance-Monitoring und -Tuning mit Microsoft SQL Server bei sqlworkshops.com hin. Sie sind als Webcasts vom Level 400 ausgeschrieben.

Wenn man sich die Seite ansieht, dann wird klar, dass die Anbieter mit dieser Maßnahme auf sich aufmerksam machen wollen. Das finde ich gut: man kann sich eine Meinung über deren Angebote bilden und muss so nicht die Katze im Sack kaufen. Ich persönlich habe immer Hemmungen Schulungen zu solchen Themen zu besuchen, weil ich schon zu oft enttäuscht wurde. Das würde mir hier nicht passieren. Jetzt müsste ich mir nur die Zeit nehmen die ersten beiden Teile anzusehen (der dritte erscheint erst noch als zeitlich befristetes Angebot).

Ich habe es so verstanden, dass es sich um den darunter erwähnten Workshop von R. Meyyappan handelt, den sowohl Lubor Kollar als Itzik Ben-Gan auch loben.

Da ich es aber noch nicht geschaut habe, ist die Info nur ohne Gewähr. Aber weil sich jeder selber eine Meinung bilden kann, sollte das kein Problem sein. Außerdem habe ich jetzt schon die Empfehlung von drei SQL-Größen, was soll da noch schief gehen?

Der Artikel "13 Things You Should Know About Statistics and the Query Optimizer bei Simple-Talk ist ein sehr guter Einstieg in die Grundlagen zum Optimizer und Statistiken am Microsoft SQL Server. Alle grundlegenden Begriffe werden erklärt und damit auch welche Indexe der Optimizer gerne aufgrund welcher Statistiken auswählt.

Ergänzend dazu eignet sich die Artikel "Column Statistics Give the Optimizer an Edge"
und "Making the Most of Automatic Statistics Updating" beim "SQL Server Magazine". Hier erklärt Kalen Delaney die Feinheiten bzgl. der leider nicht immer aktuellen Statistiken.

Wer das ganz lieber bei Microsoft nachlesen will, der wird in den Books Online fündig.

Wenn man eine SQL-Server-Datenbank auf einem Festplattensystem mit einer Sektor-Größe von 512 Bytes, das ist die derzeit übliche Größe, angelegt hat, dann kann man diese Datenbanken nicht einfach dateiweise auf eine Festplatte mit einer anderen Sektorgröße verschieben und dann dort erneut anhängen.

Disclaimer: Ich meine hier nicht die "logische" Cluster-Size, die beim Formatieren der Laufwerke angegeben wird, sondern die physische Sector-Size, die vom Hersteller festgelegt wird.

Bisher hatten Festplatten eigentlich immer eine Sektor-Größe von 512 Bytes. Aber das wird sich bald ändern, weil bestimmte Größen damit nicht mehr machbar sind. Angekündigt sind die neuen Festplatten von der IDEMA ja schon lange. Aber heute las ich erstmals von Festplatten, die nun tatsächlich mit der neuen Sektor-Größe von 4096 Bytes produziert werden. Bisher hatte man nur mit SAN und manchen NAS die Möglichkeit eine andere Sektor-Größe zu konfigurieren.

Wo ist nun das Problem?

In den Dateien der SQL-Server-Datenbank ist festgehalten mit welcher Sektor-Größe die Datenbank angelegt wurde. Verschiebt man die Dateien auf eine Festplatte mit der Sektor-Größe 4096, dann weiter sich der SQL-Server die Datenbank anzuhängen. Fällt also beispielsweise die Festplatte aus und dann führt auf einer Neuen (mit abweichender Sektor-Größe) eine Rücksicherung durch, dann kann man die Datenbanken nicht mehr in Betrieb nehmen. Es gibt laut Microsoft keine Möglichkeit die Daten da wieder herauszuholen.

Das gilt leider auch, wenn man eine Sicherung mittels BACKUP anlegte, weil der RESTORE die Seiten genauso wiederherstellt. Daher hat die so wiederhergestellte Datenbank wieder eine Sektorgröße von 512 Bytes. Microsoft empfiehlt von irgendwoher eine alte Platte zu besorgen, die Datenbank dort anzuhängen, eine neue Datenbank auf der neuen Platte (leer) anzulegen und die Daten dann von der alten in die neue zu kopieren. Die Datenbanken erhalten den Stempel beim Anlegen und behalten ihn auf Lebenszeit. Die Sektor-Size wird dabei von der des Festplattensystem bestimmt. Das ist leider nicht konfigurierbar.

Der umgekehrte Fall ist hingegen unproblematisch: Wurde eine Datenbank auf einer Festplatte mit 4K Sektor-Größe angelegt, dann kann sie einfach auf Festplatten mit 512Bytes betrieben werden. Microsoft kennt das Problem und hat daher schon beim SQL Server 2005 die Systemdatenbanken mit der Sektor-Größe 4096 Bytes angelegt.

Warum muss der der SQL Server diese Infos speichern? Ich fand bisher nur konkrete Hinweise darauf, dass das Transaktionslog sektorweise geschrieben wird. Die Datenseiten werden immer gemeinsam behandelt, hier wäre das daher vermutlich nicht nötig, aber ich fand noch keinen Weg das zu umgehen. Das leigt aber vermutlich auch daran, dass ich noch kein Festplattensystem mit 4096 Bytes habe. Details zum Hintergrund finden sich im Artikel "Microsoft SQL Server I/O subsystem requirements for the tempdb database".

Zu dem Thema gäbe es noch viel zu sagen, falls Interesse besteht bitte einen Kommentar reinstellen…