Hier nun der zweite Teil des Interviews mit Buck Woody. Diesmal geht es um verschiedene Ansätze des SQL Server Management, um Powershell, Berichte, Templates und Bucks Lebensweg
Gruß,
Steffen
Du arbeitest nun in SQL Manageability. Kannst Du uns einen kurzen Überblick geben, was alles darunter fällt? Denn nach meiner Erfahrung gibt es verschiedene Arten von SQL Kunden. Es gibt den Vollzeit-DBA, der mit nichts als SQL Server arbeitet. Auf der anderen Seite gibt es sehr viele, sowohl auf der Softwarehersteller als auch auf der Kundenseite, für die SQL Server nur ein Teil der Lösung ist und die sich am liebsten so wenig wie möglich um SQL Server kümmern wollen. Was bedeutet SQL Manageability für all diese verschiedenen Arten von Anwendern?
Für uns gibt es kleine, mittlere und große Anwender. Und dabei geht es nicht darum, wir groß die Firma ist oder wie groß die Datenbank ist sondern wie komplex die Umgebung ist. Ein kleiner Kunde kann eine sehr komplexe Umgebung mit sehr großen Datenbanken haben. Das wäre für uns ein großer Anwender weil er große Managementanforderungen hat. Der mittlere Anwender ist der, der viel mit der Datenbank arbeitet aber auch andere Dinge tut. Für kleine Anwender ist es meist so, dass sie sich mit der Datenbank möglichst wenig beschäftigen wollen weil diese Anwender noch viele andere Dinge zu tun haben. Am besten steht der Server irgendwo in der Ecke und macht möglichst wenig Arbeit. Und in großen Firmen gibt es oft alle diese Typen von Anwendern.
Für uns gibt es zwei oder drei wesentliche Ansätze für Manageability. Der erste ist die grafische Umgebung, die gut geeignet ist wenn man nicht allzu viel über das System weiß und neue Dinge finden will. Man kann rechtsklicken, Dialoge öffnen und so weiter. Für solche Kunden haben wir Assistenten, Hilfe, Tutorials, direkt aus Management Studio.
Dann haben wir Kommandos und T-SQL für Anwender, die sich mit dem Objektmodell gut auskennen und die möglichst schnell arbeiten oder neue Software entwickeln wollen. Für diese Kunden haben wir im Abfragefenster von Management Studio neue Features wie Intellisense und den T-SQL Debugger hinzugefügt.
Für die Anwender, die den Server am liebsten in die Ecke stellen und sich damit nicht mehr beschäftigen wollen gibt es vor allem die Möglichkeit des Scripting in Management Studio. Sie erstellen mit den Assistenten in der GUI einmal ihre Wartungsaufgaben, lassen sich das Skript dazu ausgeben und automatisieren das dann zum Beispiel mit dem SQL Server Agent. Die meisten Assistenten und Dialoge in Management Studio erlauben dieses Scripting. In SQL Server 2008 kann man diese Skripte zum Beispiel auch mit PowerShell ausführen.
Powershell ist ein gutes Stichwort. Viele Leute fragen sich, warum es das eigentlich gibt, denn mit T-SQL hat SQL Server ja bereits eine ehr mächtige Skriptsprache. Warum gibt es jetzt also so etwas wie Powerhell in SQL Server?
Es gibt ein paar Gründe dafür, warum wir es getan haben, und ein paar Gründe, warum wir PowerShell so implementiert haben wie es ist. Wir haben nicht nur einen PowerShell Provider implementiert, das ist ein Satz von DLLs die sich in PowerShell integrieren, wir haben auch eine Minishell (sqlps) erstellt. Diese Minishell kann man starten und ist gleich in der SQL Server Umgebung. Man muss nicht erst die SQL Server Provider zu PowerShell hinzufügen. Aber warum nun überhaupt Powershell. Der Hauptgrund für Powershell sind die Administratoren, die nicht nur SQL Server betreuen. Sie haben Exchange, Windows und so weiter. PowerShell kennt all diese Sachen. Ein Beispiel für diese Zusammenarbeit wäre: Ich kann in SQL Server herausfinden wie groß meine Datenbank ist und dann Windows fragen, welche Laufwerke genügend Platz haben. Dann kann ich ein Backup-Kommando in SQL Server ausführen. In SQL Server 2008 kann Backup von sich aus komprimieren, aber PowerShell kann auch auf SQL Server 2005 und 2000 zugreifen. Es könnte also nach dem SQL Server Backup ein Kompressionsprogramm wie zip ausführen. Man kann also in einem PowerShell Skript leicht zwischen den Umgebungen wechseln. Der Punkt ist, dass ich nur eine Skriptsprache lernen muss und damit alle meine Systeme über die gesamte Plattform verwalten kann.
Das andere neue ist, dass wir in PowerShell einen Provider implementiert haben der es erlaubt, SQL Server wie einen Laufwerksbuchstaben zu navigieren. Wir alle kennen cd, das Change Directory Kommando. Dasselbe Paradigma gibt es jetzt in SQL Server 2008. Man kann zur Instanz navigieren, dann zur Datenbank, dann den Tabellen. Man kann dir tippen und bekommt eine Liste der Tabellen. Dabei gelten immer die Berechtigungen des Benutzers. All das verwendet Server Management Objects (SMO), ein API das auch von Management Studio verwendet wird. Die Berechtigungen sind also dieselben.
Wir haben auch die Möglichkeit geschaffen, aus PowerShell auf unser neues Policy-based Management (PBM) zuzugreifen. Dadurch kann man zum Beispiel auch Policies gegen SQL Server 2005 oder 2000 automatisieren, obwohl diese Versionen gar kein PBM kennen.
Gibt es etwas in SQL Server Management von dem Du denkst, dass die Kunden es kennen sollten, was die meisten aber nicht kennen?
Ja, so etwas gibt es. Ich habe in meinem Blog (http://blogs.msdn.com/buckwoody/archive/tags/Standard+Reports) eine Serie über die Standardberichte in Management Studio. Dort habe ich über 50 dieser Standardberichte gebloggt. Diese Berichte haben verblüffend viele Informationen über die Serverkonfiguration, Performance, Locking, Deadlocking, Benutzeraktivität, Hauptspeicher, alles. Man kann dort die letzten Backups finden, wie lange sie gedauert haben. Die meisten Benutzer wissen nicht, wie viele Informationen diese Standardberichte enthalten. Wir haben aus diesen Berichten 
sogar einen Rechtsklick-Menüeintrag gemacht damit sie für die Administratoren besser zu finden sind. Und glaube mir, das Rechtsklick-Menü ist heilig. Darüber wird zwischen den Teams viel verhandelt. Jeder will sein Feature darin sichtbar haben. Aber wir wollen das Rechtsklickmenü klein halten damit es übersichtlich bleibt. Aber die Berichte sind da. Und Administratoren haben auch die Möglichkeit, eigene Beichte hinzuzufügen.
Hast Du auch ein Feature für uns von dem Du glaubst, dass die Kunden es nicht richtig benutzen?
Ich glaube, ein solches Feature ist der Vorlagen (Templates) Bereich. Der Template Explorer ist ein tolles Feature das sehr viel hervorragenden T-SQL-Code enthält. Die meisten Leute erkennen aber nicht, dass man da seine eigenen Vorlagen (Templates) hinzufügen kann. Sie werden in einem anderen Verzeichnis gespeichert, damit die Standardvorlagen nicht überschrieben werden. Ich denke, solche Vorlagen sollten viel mehr weitergegeben und für die Community verfügbar gemacht werden. Auch kann man so innerhalb eines Teams mehr Standardisierung erreichen.
So, jetzt noch zu Dir persönlich. Du bist erst seit 2 Jahren bei Microsoft. Was hast Du vorher gemacht und wie bist Du hierher gekommen?
Ich habe mit 18 angefangen mit Technologie zu arbeiten. Damals bin ich zum Militär gegangen und habe dort im administrativen Bereich gearbeitet. Da habe ich mich schon für Computer interessiert, und kleine Computer fingen gerade an bedeutend zu werden. Dadurch wurde ich so etwas wie ein Computer Consultant. Ich habe also Computer installiert, Dinge automatisiert und so. Von Anfang an habe ich mit Datenbanken gearbeitet. Ich habe mit einem Produkt namens Vulcan gearbeitet, das war der erste Vorläufer von dBase. Als dann dBase herauskam und an die Regierung und das Militär verkauft wurde habe ich angefangen mich damit zu beschäftigen. Dann kamen für mich die Mainframes. So habe ich zum Beispiel Oracle auf einem VAXcluster betreut, dann Oracle auf HP9000. Dann habe ich mich mit Sybase beschäftigt und dann kam SQL Server und ich habe ein wenig mit DB2 gespielt. Das war auf einer AS/400 unter OS/400, einem Betriebssystem das selbst eine Datenbank ist. Das ist sozusagen eine Datenbank, die ein Betriebssystem beinhaltet statt andersrum. Ich habe sogar mit MySQL gearbeitet als das erschien. Ich habe für verschiedene Firmen als DBA, Datenbankentwickler, Architekt, Datenbank-Consultant gearbeitet. Es ging fast immer um Datenbanken. Ich war auch mal Systemadministrator für UNIX und Windows, habe Exchange und Web Server betreut. Ich habe ein paar Bücher über SQL Server geschrieben. Ich schreibe auch für http://informit.com und bin dort die SQL Person. Ich schreibe dort jede Woche einen Artikel, seit etwa 5 Jahren. In meiner vorigen Firma schließlich war ich ein Datenarchitekt. Nicht nur für Datenbanken, sondern auch für Dine wie SAP, Anwendungsdaten, Word-Dokumente, Excel Dateien – die weltgrößte Datenbank heißt ja Excel. Und Microsoft war dann für mich der nächte logische Schritt. Ich habe dann ein Jahr in der User Education Group gearbeitet. Das Team erstellt Books Online und viele der technischen Whitepaper. Das kam also von meiner Erfahrung im Schreiben. In diesem Jahr habe ich an der Sicherheitsdokumentation für SQL Server gearbeitet, Verschlüsselung und so. Dann wurde eine Position in der Manageability-Gruppe ausgeschrieben, und da ich so lange DBA war erschien mir das als passend. Ich bin kein Entwickler, obwohl ich einen im Fernsehen gespielt habe. Ich bin auch kein Tester, obwohl ich auch das im Fernsehen gespielt habe, daher fand ich die Program Manager Rolle am passendsten, und hier bin ich.
Und warum Microsoft und nicht eins der vielen anderen Systeme mit denen Du gearbeitet hast?
Nun, ich hatte mal ein Bewerbungsgespräch bei Oracle um zu sehen, wie es da so zugeht. Ich war mir da nicht sicher ob die Firmenkultur mir zusagt. MySQL war damals noch nicht im Besitz eines anderen Konzerns. Und da ich es mag, bezahlt zu werden war das keine Option. Und obwohl ich vor vielen Jahren mal für einen IBM-Partner gearbeitet habe hatte ich mit DB2 die wenigste Erfahrung. Hier bei Microsoft hatte ich den Eindruck, dass ich am meisten bewegen kann. Und ich mag auch die Gegend um Seattle, und meine Familie war bereit umzuziehen und somit war dies der richtige Ort.
Danke Buck
