Dienstag, 19. Mai 2009

Rückblick

Hatte in den letzten Tagen viel um die Ohren, daher hier mal eine kleine Zusammenfassung der letzten Erlebnisse..

Zuerst ein kleiner Aufruf an alle Entwickler da draußen, welche den SQL Server für ihre Anwendungen einsetzen (wollen):

Eine Datenbank ist mehr als nur ein doofes Datengrab! Glaubt mir! Und wenn Ihr mehr als nur 300/3.000/30.000/300.000/3.000.000/30.000.000 Sätze in einer Tabelle habt und es läuft nicht mehr so schnell wie am Anfang, dann ist eigentlich fast nie die eigentliche Datenbank schuld! Datenbanken wie der SQL Server sind für Datenmengen im GB und TB Bereich gedacht. Wenn Ihr mehr darüber wissen wollt, dann steigt ruhig in die sehr gute Doku ein oder besucht mal eine Regionalgruppe des PASS Deutschland e.V. Da wird Euch geholfen! Versprochen!

Und Optimierung von Queries heißt nicht nur unten auf die Ausführungszeit schauen. Query Plan rules!

Nicht zu vergessen ein Lob an alle Entwickler und deren Arbeitgeber, welche das erkannt und sich entsprechend Unterstützung bei uns (PSG) gesucht haben!

Kommen wir zu was Schönem:

Es gibt ein SQL Server 2008 Developer Training Kit! Das Kit beinhaltet einige Präsentation, Demos und Hands-on Labs. Themen wie Spatial, Filestream, SQL CLR usw. werden behandelt.

Und woher weiß ich davon? Es gibt einen neuen Blog am Webhimmel. Das deutsche SQL Server Team schreibt ab sofort unter http://blogs.technet.com/sqlteamgermany. Dahinter verbergen sich so wohlbekannte Namen wie Ralph Kemperdick, Martin Vach, Markus Thomanek, Oliver Goletz, Markus Fischer und Georg Urban. Ich hoffe auf viele interessante Artikel!

Hierarchien muss es einfach geben, deswegen hatten wir dieses Thema beim letzten Treffen der Regionalgruppe Hamburg des PASS e.V.

Wir hatten den Gastredner Christoph Hanser, welcher uns die Grundlagen über die Abbildung von Hierarchien innerhalb des SQL Servers nahe brachte. Vielen Dank dafür! Mich hat das Ganze ein wenig ins Grübeln gebracht, weil ich erkannte, dass ich bisher eigentlich keine wirklichen Lasttests zu dem Thema durchgeführt habe. Das werde ich in Kürze mal nachholen müssen. Da ich gerade in mehreren Projekten mit Nested Sets zu tun habe, sollte das kein Problem sein. :o)

Und nochmal ein paar Worte an Architekten und Entwickler:

Unter- bzw. überschätzt nicht die Replikation des SQL Servers! Ob genau dieser Dienst des SQL Server was für Euer Projekt ist, nun ja, it depends… :o)

Drei kleine Beispiele:

Dem einen Team musste ich die Merge Replikation wirklich ausreden, weil diese völlig überdimensioniert war für das Anwendungsszenario. Nun ja, die von mir vorgeschlagene Architektur ist nun weitaus weniger komplex, dafür gab's Abzüge in der B-Note. Aber sie wurde von jedem am Tisch verstanden und kann auch von einem Teilzeit-DBAs gepflegt werden.

In einem anderen Workshop musste ich wirklich Überzeugungsarbeit leisten, dass sich die Entwickler an die SQL Server Replikation ran trauen und nicht alles selbst entwickeln.

Und in einem weiteren Projekt ist es uns (PSG) gelungen, ein Management Framework zu entwerfen und zu entwickeln, welches für die Steuerung (Init, Recovery, Change Management, Selbstheilung, Agent Monitoring usw.) einer Replikation mit knapp 1000 SQL Servern gedacht ist. Das Framework basiert auf einem Repository, welches mit Meta Daten über die eigentliche Topologie gefüllt ist. Des Weiteren haben wir noch ein paar äußerst nette zusätzliche Ebenen in das Replikationsmodell des SQL Servers gezogen, damit es sich in einer echten Enterprise Umgebung problemlos pflegen und nutzen lässt. Damit das Ganze nicht zu einfach war, sind die Server auch noch auf mehreren Kontinenten verteilt. Es ist selbst für uns immer wieder erstaunlich wie leistungsfähig der SQL Server und seine Erweiterbarkeit ist!