Qualität per Deklaration - das Declarative Management Framework bei SQL Server 2008

Qualität per Deklaration - das Declarative Management Framework bei SQL Server 2008von Jens Süßmeier (Microsoft Deutschland) Um die Qualität einer Arbeit auf einem hohen und nachvollziehbaren Niveau zu halten sind sowohl Prozesse als auch Richtlinien hilfreich. Mit letzterem beschäftigt sich eine der neuen Funktionen des SQL Server 2008, dem Declarative Management Framework, kurz DMF. Durch den Einsatz von Richtlinien, der so genannten Policies, vereinfacht es die Verwaltung als auch die Überwachung von Datenbankobjekten um vorzeitig z.B. im Unternehmen festgelegten Standards Genüge zu tragen.Das DMF besteht aus drei Hauptkomponenten:1) Richtlinienverwaltung: Das Management Studio des SQL Server 2008 unterstützt den Anwender beim Anlegen und Ändern von Richtlinien2) Explizite Administration: Legt fest welche und Ziele, wie Server und Objekte durch die Richtlinien überprüft werden sollen.3) Automatisierte Administration: Legt fest wie und wann die Richtlinien auf die Objekte angewendet werden sollen und welche Auswirkungen ein Verstoß gegen die Richtlinien hat.Um eine kurze Einführung in die Begrifflichkeiten des Frameworks zu geben, werden im nachfolgenden die Schlüsselbegriffe, die sich bei der Erstellung einer Richtlinie wiederfinden mit einem kurzen Beispiel anhand einer altbekannten aber dennoch manchmal missachteten Best-Practice erklärt. Diese besagt, dass keine Prozedurnamen mit dem PreFix "SP_" erstellt werden sollten [1]. Richtlinienverwaltung per Designer Das Erstellen einer neuen Policy bedarf keiner tieferen Programmierkenntnisse und kann durch eine neue Funktion im SQL Server Management Studio 2008 mittels eines Designers durchgeführt werden. (Abbildung 1).Abbildung 1: Die Designeroberfläche des Management Studios für Policies Für das Erstellen benötigt man zunächst eine Condition (Abbildung 2, (2)) die den Zustand beschreibt der eine Überprüfung einer Policy einleitet. Bedingungen werden durch sog. Facets festgelegt. Ein Facet ist eine Sammlung von Eigenschaften eines Objektes, die für das Erstellen einer Richtlinie verwendet werden können. Sie stehen in großer Zahl für die wichtigsten Aufgaben zur Verfügung. Die Anzahl der Eigenschaften hängen vom jeweiligen Typ des Objektes ab, welches man verwenden will. So beinhaltet ein Backup-Facet die Eigenschaften eines Backups wie Name, Ort des Backups und Art des Backups, ein Prozedur-Facet Eigenschaften wie Objektname und Schemaname. Abbildung 2: Eine Condition beschreibt den Zustand der überprüft werden sollFür dieses Beispiel wird die Eigenschaft "Name" des Stored Procedure Facets verwendet. Durch den Designer können die Bedingungen, hier die Einschränkung auf den Namen festgelegt werden (Abbildung 3, (1)). Diese Bedingung ist nicht an die erstellte Policy gebunden, sondern kann auch bei anderen Policies jederzeit wiederverwendet werden.Explizite Administration für granulare AusführungWurde die Bendingung erstellt, können durch eine Einschränkung die Subset-Objekte, auf welche die Policy angewendet werden soll, eingeschränkt werden. Standardmäßig werden alle Objekte (hier alle Stored Procedures) auf allen Datenbanken des aktuellen Servers selektiert. Durch weitere Conditions kann man den Bereich weiter einschränken (wie beispielweise alle nicht-Systemdatenbanken [2] und nur alle Prozeduren eines bestimmten Schemas) (Abbildung 3, (2)). Abbildung 3: Die Administrationssicht auf eine Policy Automatisierte Administration nach WunschNachdem festgelegt wurde was und wo überprüft werden soll, muss jetzt nur noch definiert werden wann die Überprüfung stattfinden soll und welche Auswirkungen die Überprüfung hat. Dies wird mit dem Evaluation Mode einer Policy eingestellt (Abbildung 3, (3)). Hierzu gibt es mehrere mögliche Optionen:1) On demand: Dies ist die Standardeinstellung einer Policy, diese wird nur gespeichert und für eine spätere (adHoc) Verwendung gespeichert.2) On Schedule: Mittels eines Zeitplanes können Policies zyklisch überprüft und reported werden. Hierzu wird die SQL Server Agent Job Engine verwendet.3) On Change Log Only: Sofort bei der Erstellung / Änderung eines Objektes wird die Policy überprüft. Mittels einer Warnmeldung wird festgehalten und dem Ersteller ausgegeben, dass eine Verletzung der Policy eingetreten ist.4) On Change Log Only: Sofort beim Erstellen/Ändern eines Objektes wird die Policy überprüft. Falls die Policy verletzt wurde, wird die durchgeführte Änderung verhindert. Somit kann sichergestellt werden, dass Änderungen nicht durchgeführt werden.Die letzten beiden Optionen, die Änderungen sofort bei der Ausführung überprüfen, werden mittels eines in der Version SQL Server 2005 eingeführten Funktion des DDL Triggers durch das Framework implementiert. Da nicht alle über die Policies möglichen abfragbaren Objekte (wie z.B. Backups) und Serverversionen (wie z.B. SQL Server 2000) DDL Aktionen unterstützen steht diese Option nicht immer zur Verfügung.Eine manuelle (ah-hoc) Überprüfung ist auch direkt über das Management Studio möglich. Hierzu selektiert man die entsprechende Policy und wählt die Option "Evaluate". Damit wird innerhalb des definierten Fokus (Server und Datenbank) die Policy überprüft. Auch die einzelnen Objekte bieten die Möglichkeit direkt die Policies zu testen. Eine neue Menüoption macht dies auf jedem überprüfbaren Objekt möglich. Im Management Studio zeigt ein Verlauf an, welche Objekte von einer Verletzung betroffen sind. (Abbildung 4) . Abbildung 4: Verstösse gegen Richtlinien im Management Studio werden eingeblendet Alle Verstöße, die bei einer Prüfung gemeldet wurden, werden in ein Protokoll zur weiteren Analyse geschrieben. Eine rückwirkende Auswertung um z.B. Compliance Richtlinien Genüge zu tun ist somit gegeben.Neue Erstellen oder bestehendes nutzen - Reverse Policy(ing)Falls die bestehenden Objekte bereits durch Best Practices erstellt wurden und man daher ein "Reverse Engineering" der Einstellungen in neue Policies durchführen, wird dies auch durch die Erweiterung im Management Studio ermöglicht. Die Menüoption "Facet" auf den Objekten bietet die Möglichkeit, die Einstellungen direkt in eine Policy oder auch in eine Condition zu exportieren. Diese können somit auch bei weiteren Policies verwendet werden. Die einmal erstellten Policies (die im Hintergrund in der Systemdatenbank Msdb gespeichert werden) können exportiert und damit auch für andere Server bzw. Umgebungen eingesetzt werden.Hohe Standards erzwingen und haltenMit dem Policy Based Management ist es bei SQL Server 2008 für Administratoren und Entwickler möglich, nicht gewünschte Änderungen zu verhindern und somit die Wartbarkeit einer Datenbanklösung zu vereinfachen und die Qualität der Artefakte auf dem gewünschten Niveau zu halten. Die erstellten Richtlinien und deren Ausführungsprotokolle können in vielen Unternehmen der Erfüllung und Nachweisbarkeit benötigter Compliance Standards dienen.Links&Literatur[1] Should I Use the sp_ Prefix for Procedure Names?- http://www.sqlmag.com/Article/ArticleID/23011/sql_server_23011.html[2] Get all system databases of a serverhttp://blogs.msdn.com/jenss/archive/2008/07/16/get-all-system-databases-of-a-server.aspxAutoreninfoJens Süßmeier arbeit bei der Microsoft GmbH in Deutschland als technischer Evangelist für den Bereich SQL Server.Peter Monadiemi