MCM SQL Server 2008 - Teil 1

By Uwe Ricken

Posted on Feb 28, 2012 von in Zertifizierung

Langsam aber beständig ist durchgesickert, daß ich mich aktuell auf die Zertifizierung zum Microsoft Certified Master SQL Server 2008 vorbereite und bis auf eine Prüfung abgeschlossen habe.

Mit diesem Blog – und den weiteren, die noch folgen werden - möchte ich meine Erfahrungen mit diesem von Microsoft initiierten Programm mitteilen und eventuell gelingt es ja, den einen oder anderen Leser dafür zu begeistern, ebenfalls eine solche Zertifizierung anzustreben.

Bevor ich jedoch mit der eigentlichen Programmbeschreibung beginne, muß ich etwas weiter ausholen und meine Entwicklung im Rahmen von SQL Server kurz dokumentieren. Dies soll der erste Teil dieser Folge werden. Nach und nach werde ich dann die MCM Zertifizierung beschreiben.

Meine erste Begegnung mit SQL Server

Mein erster ernsthafter Kontakt mit Microsoft SQL Server war im Jahre 1998, als wir den Auftrag bekamen, für ein Unternehmen in Frankfurt eine serverbasierte Datenbank zu erstellen. Da ich grundsätzlich „Microsoft lastig“ bin, war die Entscheidung, diese Lösung mit dem Microsoft SQL Server zu realisieren, relativ schnell gefallen.

So begann also mein erster Kontakt mit SQL Server in der Version 6.5 und wir legten los. Man kann sich vorstellen, daß die erste Lösung nicht gerade die optimalste Lösung war. Es gab viel zu lernen; so war mir zu Beginn nicht klar, warum ich z. B. Stored Procedures verwenden sollte; wo der Unterschied zwischen zeilenbasierten und setbasierten Aufgaben liegt. Über Indexes habe ich mir zwar Gedanken gemacht – jedoch gingen diese Gedanken lediglich soweit, um zu erkennen, daß es für eine Relation immer nur einen „Clustered Index“ geben konnte – wie man jedoch ein Datenbanksystem auch mit Indexen lahmlegen kann, war mir dato schlicht und einfach ein Rätsel.

Ich kam aus der Microsoft Access Welt und mit dem ersten Kontakt mit einer serverbasierten Datenbank begann eigentlich ein komplett neuer Lernprozeß, der auch heute noch nicht abgeschlossen ist.

Das System, daß wir 1998 entwickelt haben, betreue ich auch heute noch; nur sind die Entwicklungswerkzeuge moderner und besser geworden.

Die Version 7.0 habe ich einfach übersprungen und einer Neuentwicklung unseres – mittlerweile in drei Ländern verwendeten – Datenbanksystems wurde dann für SQL Server 2000 anvisiert und umgesetzt.

Während dieser Zeit ist natürlich der Lernprozeß in Bezug auf SQL Server so weit fortgeschritten, so daß ich dann im Dezember 2001 die erste Prüfung überhaupt in Verbindung mit Microsoft SQL Server abgelegt habe:

229: Designing and Implementing Databases with Microsoft SQL Server 2000 Enterprise Edition

Bis Mai 2007 lag mein Fokus bei Microsoft SQL Server ausschließlich auf der Entwicklungsseite. Es machte einfach nur Spaß, plötzlich durch das in vielen Jahren gewonnene Wissen eine Datenbank zu optimieren – und das schlicht und einfach nur durch Analyse von Indexes oder der Auslagerung von prozeduralem Clientcode in Stored Procedures.

Durch die Fachvorträge auf der SEK konnte ich mein Wissen ebenfalls wunderbar verbessern, da ich mich plötzlich auch mal mit Themen beschäftigen mußte, die eben nicht nur und ausschließlich mit Entwicklung zu tun hatten.

Im September 2008 hatte ich das große Glück, in einem Projekt mit Fachleuten zusammenzuarbeiten, in dem ich auch heute noch tätig bin. Seit Oktober 2008 arbeite ich u. a. bei der Deutschen Bank in Frankfurt am Main als dba und bin dort für die Einhaltung der Sicherheitsrichtlinien sowie die Bewertung von zu implementierenden T-SQL-Codes zuständig.

Ich betrat – obwohl ich ja auch schon SQL Server für unsere Datenbanken eingerichtet habe – komplettes Neuland. Ich mußte mich plötzlich mit Security innerhalb und außerhalb von SQL Server auseinandersetzen; Hochverfügbarkeitslösungen wie Cluster, Mirroring, Log Shipping wurden plötzlich zum täglichen Brot und nach und nach verlagerten sich meine reinen Entwicklungstätigkeiten zu einem „gesunden“ Gemisch aus Entwicklung und Administration – die erste Hürde für weitere – erforderliche - Zertifizierungen war damit genommen.

Ab September 2009 begann die Idee zu reifen, mein Wissen nicht nur innerhalb der Bank zu beweisen sondern auch mittels entsprechender Zertifikate meinem Anspruch gerecht zu werden, mein Wissen anderen gegenüber durch entsprechende Nachweise zu belegen.

Insgesamt hat es bis 2009 gedauert, um mit einem guten Gewissen in die Prüfungen zu gehen. Ich habe bisher ALLE Prüfungen ohne irgendwelche Vorbereitungskurse oder Trainings abgeschlossen. Warum ich nichts von Kursen halte, erzähle ich im nächsten Teil.

Herzlichen Dank für’s Lesen

Dieser Eintrag wurde eingetragen von und ist abgelegt unter Zertifizierung. Tags: ,

4 Kommentare

Benutzerwertungen
5 Stern:
 
(1)
4 Stern:
 
(0)
3 Stern:
 
(1)
2 Stern:
 
(0)
1 Stern:
 
(0)
2 Bewertungen
Durschn. Benutzerwertung:
(4.0)

Kommentar von: Christian

Christian
Hallo Uwe, das ist ein interessanter Artikel. Viel Erfolg bei der Prüfung! Mit welchen Tools arbeitet ihr bei der der Deutschen Bank im Bezug auf den SQL Server? - Deployment (Change Skripte) - Datenmodellierung - Entwicklung (IDE oder SSMS?) Über eine Antwort würde ich mich freuen. MfG Christian
28.02.12 @ 13:32
Hallo Christian, grundsätzlich gibt es Richtlinien, daß nur "supported" Tools verwendet werden dürfen. Also SSMS, BI-Studio :) Implementierungen erfolgen streng nach ITIL - das wäre ev. einen separaten Blog wert und würde hier deutlichst zu weit führen. Ich kann jedoch soviel sagen, daß KEINE Implementierungen in eine Produktion gehen, die nicht im Vorfeld bereits durch eine UAT/Pre Prod geprüft wurden.
28.02.12 @ 15:15
Hallo Uwe, Gratulation erst einmal für das Erreichte und viel Glück für das, was noch ansteht! Du hast Recht, dass Implementierungen und das ganze Release Management eigene weite Themen sind. Nur eine Frage: Mit was für einem Development- /Releasezyklus arbeitet ihr? Alle 6 Monaten, alle 2 Wochen...?
28.02.12 @ 22:11
Hallo Frank, der "Releasezyklus" wird durch das Business bestimmt. Jedoch gilt, daß in UAT-Umgebungen jederzeit und in PROD-Systeme erst nach bestätigten Tests aus der UAT implementiert werden darf. RFC für PROD-Systeme dürfen nur an Wochenenden durchgeführt werden (sofern es sich nicht um einen Incident handelt) Aber ich werde Releasemanagement und ITIL-Verfahren für SQL Server nach meinen "Masterergüssen" etwas genauer beleuchten :)
03.03.12 @ 22:16


Formular wird geladen...