Note: This blog post is in German as it is about a German conference and I expect mainly German readers. Moreover I have to admit it is easier to write German early in the morning than english :-P. Anyway feel free to run it through google translate if you are non-german-speaking and interested in the content.

Wow…endlich mal wieder ein Blogeintrag nach langer Zeit. Ich finds zwar ganz gut, wenn man nicht immer was zu sagen haben muss aber zugegen die Pause war jetzt relativ lange. Ich habe das Vergnügen aktuell bei der Konferenz SQLdays in Erding zu sein. Es fühlt sich echt gut an, endlich mal wieder mit anderen gleichgesinnten Datenbegeisterten zusammenzukommen. Die bessere Verbreitung der Corona Impfungen und ein gutes Hygienekonzept machen das möglich.

Nachfolgend möchte ich euch teilen, was ich bei der Konferenz mitnehmen konnte.

Meine eigene Session über Workloadtests

2019 habe ich bei der PASS Rhein-Main und den New Stars of Data meinen ersten eigenen Vortrag gegeben. Diesen konnte ich bei einigen Gelegenheiten firmenintern und auch öffentlich wiederholen. Dies waren jedoch alles virtuelle Online-Sessions. Die Online-Präsentation hat zweifellos ihre Vorzüge: Man kann bequem aus dem Homeoffice sogar Leute in Lagos, Nigeria erreichen und vortragen. Jedoch fehlt eine wichtige Komponente: das Publikum und das Feedback. Selten schalten Zuhörer die Kamera ein und man präsentiert somit in ein Vakuum.

Es hat mega viel Spaß gemacht, bei den SQLdays wieder vor Leuten zu präsentieren. Ich war überrascht und beflügelt von der großen Resonanz…von 50 Besuchern der Konferenz hab ich über 20 in meiner Session gezählt…und das wo ich als Sprecher jetzt noch nicht so groß bekannt bin.

Als Sprecher freut man sich vor allem über Fragen. Zeigt das doch, dass die Zuhörer sich mit dem Thema beschäftigen und es verstehen (oder auch mutig nachfragen, wenn sie was nicht verstehen :-)). Aus einem vorangegangen Präsentationstraining hatte ich extra den Tipp mitgenommen, im Zweifelsfall das Eis zu brechen und eine eigene Frage zu stellen und zu beantworten im Stil von: “Wir haben jetzt noch gute 5 Minuten Zeit für Fragen. Wer hat die erste Frage?” …Stille keiner meldet sich…. “Eine Frage, die mir in diesem Zusammenhang oft gestellt wird ist ….”. Dies war aber gar nicht notwendig :-).

Gleichzeitig erlebe ich als Sprecher aber auch Dinge, an denen ich noch arbeiten kann. So war ich dankbar, als mich der Tobi (am Schnittplatz für die Übertragung der Konferenz nach Teams) drauf hingewiesen hat die Frage für den Chat zu wiederholen. Das hatte ich vorher auch geübt aber der gute Vorsatz war schnell von der Gewohnheit, direkt zu antworten, überholt. Buck Woody von Microsoft hat es in einem Präsentationstraining mal so nett vorgestellt: Jemand spricht in einem großen Saal eine Frage, die andere Teilnehmer nicht verstehen können. Der Sprecher sagt “Oh das ist aber eine interessante Frage….Ich denke die Antwort lautet Nein”. Resultat: die anderen Zuhörer haben gar nichts mitbekommen, ärgern sich im schlimmsten Fall darüber und fühlen sich ausgeschlossen.

Hier ein paar Bilder aus meiner Session:

• 

• 

• 

• 

Einführung in die Entwicklung von Power BI Embedded

Interessiert verfolge ich seit ein paar Jahren Power BI Themen. Herausforderung bei der Arbeit ist es öfter, die Zeit zu finden, hier auch erste Projekte zu verfolgen, sodass ich aktuell bei dem Thema eher von der Seitenlinie aus beobachte.

Von Klaus Blessing (Trainer und Berater bei ppedv) hab ich zum Thema Power BI Embedded folgendes mitgenommen:

• Bei Power BI Embedded geht es darum, Power BI Berichte nahtlos in eine bestehende Webapplikation einbinden zu können. Der Endebenutzer bekommt ggfs. also gar nicht mit, dass hinter einer Visualisierung Power BI steckt.
• Funktionieren tut das nur aus der Cloud heraus
• Die Preismodelle sind unterschiedlich ob eine Premium-Kapazität (beginnt ab 5 T€/Monat) in Anspruch genommen wird oder eine Lizenz von Power BI Embedded (startet bei 632 €) verwendet wird.
• Benutzer mit Zugriff müssen nicht einzeln lizensiert werden
• In der Praxis liegt die Limitierung des Benutzerzugriffs an den gebuchten Ressourcen (CPU und RAM)
  • nach Erfahrungen von Klaus Blessing reicht eine A1 Instanz (1 virtueller Kern, 3 GB Arbeitsspeicher) zum Einstiegspreis von ca. 630 € für bis zu 100 Nutzer
  • wichtig bei dieser Berechnung ist jedoch zu berücksichtigen, wieviel Benutzer gleichzeitig zugreifen (von den 100 sind typischerweise nie alle zum gleichen Zeitpunkt aktiv)
• Grundsätzlich kann die gebuchte Kapazität auch auf mehrere Power BI Embedded Arbeitsbereiche (z.B: Produktion und Test) verteilt werden. Hier sollte man jedoch auch wieder die Gesamtzahl der (gleichzeitig zugreifenden) Benutzer im Auge haben.
• Power BI Embedded unterstützt die Einbindung mittels populärer Sprachen wie C#, Java, Python und weiteren
  • der Umfang der Einbindungsoptionen ist je nach Sprache leicht unterschiedlich
  • grundsätzlich wird ein Codeprojekt generiert (in C# also bspw. alle erforderlichen Klassen mit Methoden)
  • dieser Rahmen ist dann noch anzupassen…im einfachsten Fall lediglich durch Einfügen von Workspace ID und Report ID (beides GUIDs) zum Verweis auf den Bericht der angezeigt werden soll
• Das Look and Feel des Berichts kann durch stylesheets umfassend angepasst werden. Damit ist eine nahtlose Integration in eine Webanwendung ohne Designbrüche möglich.
• In den Microsoft Docs gibt es ein Tutorial
• Im Power BI Embedded Playground kann man kostenlos und unverbindlich damit experimentieren
• Für den Zugriff richtet man einen “geheimen Clientschlüssel” über die App-Registrierung in Azure ein. Innerhalb von Power BI kann man dann Row Level Security implementieren, damit jeder Benutzer nur seine entsprechenden Daten sehen kann. Anmerkung: Hier habe ich noch einiges zu lernen…Security war aber auch berechtigterweise kein Inhalt des Vortrags.

Abfragebasics mal anders – der “richtige” Umgang mit JOINS & Co.

Von Torsten Ahlemeyer konnte ich mir in diesem Vortrag etwas Didaktik abschauen. Er hat bei arelium die schöne Aufgabe, Werksstudenten an SQL heranzuführen. Dafür hat er mit Kollegen über die Jahre einen kompletten Lernplan basierend auf dem Spiel “Schiffe versenken” erarbeitet. Arelium hat damit eine Aufgabe, die komplett für das Thema Lernen von SQL und sogar auch von Machine Learning genutzt wird….dies hat mich beeindruckt.

Ich war erst mal beruhigt, dass ich tatsächlich die Basics nach fast 15 Jahren Arbeit mit SQL gut beherrsche. Einen Schnitzer habe ich mir bei der Frage erlaubt: Führt folgende Abfrage zu einem Fehler?

SELECT 1 AS test, 2 AS test

Die Antwort: Nein. SQL Server ist es erstmal völlig egal, ob Spaltenaliase in einer Abfrage mehrfach vergeben sind. Müsste ich eigentlich wissen 🙂 aber mut zur Lücke ich hatte trotzdem für Ja votiert. Wenn eine Abfrage in eine View umgewandelt oder in einer Tabelle gespeichert werden soll gibt es jedoch einen Fehler. Warum? Ganz klar, SQL Server muss ja eindeutig zuordnen können welche Spalte mit “test” gemeint ist….und da darf es keine Mehrdeutigkeiten geben.

Wo es direkt um die Joins ging: Ich habe mir über die Zeit angewöhnt, Joinbedingung und weitere Selektionskriterien bei INNER JOINs zu trennen. Hier ein Beispiel:

USE StackOverflow2010;
/* ON-Clause enthält nur Joinbedingung; weitere Bedingungen im WHERE */
SELECT TOP 500 p.id
FROM        dbo.Posts p
INNER JOIN  dbo.Votes v ON p.id = v.PostId
WHERE 
    v.VoteTypeId = 2
ORDER BY p.id
;
/* alle Bedingungen in der ON-Clause */
SELECT TOP 500 p.id
FROM        dbo.Posts p
INNER JOIN  dbo.Votes v ON p.id = v.PostId AND   v.VoteTypeId = 2
ORDER BY p.id
;

Mein Favorit ist also das erste Codestück. Bei diesen Beispielen kommt derselbe Execution Plan heraus. Torsten wies mich in der Session drauf hin, dass die logische Ausführungsreihenfolge zuerst FROM und dann WHERE ist und er daher alle Bedingungen in den FROM-Teil nimmt, um frühzeitig Daten einzuschränken. Hört sich plausibel an…so bin ich etwas unsicher geworden und habe bei StackExchange eine Frage eingestellt. Aus der Antwort heraus lese ich, dass ich das grundsätzlich weiter so machen kann.

SQL Server auf Kubernetes

Dieser Session konnte ich leider nur kurz zuschauen. Ich musste meinen Mietwagen zurückbringen, was sich als recht zeitaufwändig herausstellte. Gelobt sei da immerhin die moderne Technik der hybriden Konferenz….während der Angestellte der Mietwagenfirma mit seinem System kämpfte konnte ich eine gute Viertelstunde der Session von Ben Weissman zu Kubernetes verfolgen. Kubernetes ist eine Bereitstellungs- und Verwaltungstechnologie für Container, die ich bereits auf dem PASS Summit in 2019 kennenlernen konnte. Bob Ward von Microsoft hatte mir damals mitgegeben: Kubernetes muss nicht jeder machen…wenn ihr es macht stellt bitte sicher, dass ihr auch ausgebildete Leute dafür habt. Definitiv ein komplexeres technisches Thema bei dem es aber Ben Weissmann gut gelungen ist, einen auf die Reise mitzunehmen und nachverfolgbare Schritte zu zeigen….sogar beim Deployment einer “Hello world” Anwendung im nginx Container…also zumindest den Teil den ich verfolgte hatte gar noch nichts mit SQL Server zu tun. Definitiv eine Session, die ich mir nochmal in Ruhe anschauen werde und es jedem empfehlen kann, der für SQL Server Infrastruktur zuständig ist.

Detect Plan Regression with Query Store

Hier hatte ich Gelegenheit zum ersten Mal eine Session von Torsten Strauss, einem ausgewiesenen SQL Server Performanceexperten zu besuchen. Hier meine Notizen:

• Bei der Verwendung von Query Store empfiehlt es sich auch regelmäßig in der DMV sys.dm_os_memoryclerks nachzuschauen
  • insbesondere die Hashmap des Query Stores wird bei vielen Ad-Hoc Plänen schnell groß
• Wichtig ist zu unterscheiden zwischen “High Variation” und “Plan Regression”
  • Eine Abfrage mit einem Ausführungsplan, die zu unterschiedlichen Zeiten deutliche Unterschiede beim Ressourcenverbrauch zeigt hat “High Variation”
  • Bei einer Abfrage mit mehreren Ausführungsplänen, bei der ein Ausführungsplan niedrigen Ressourcenverbrauch hat und ein anderer hohen Ressourcenverbrauch spricht man von “Plan Regression”
• Torsten hat zur Verdeutlichung von Planregression einen Klassiker als Demo mit skewed data verwendet: Je nachdem welcher Wert als erstes ausgewertet wurde kam ein anderer idealer Plan heraus (Nonclustered Index Seek und Nested Loop mit RID-Lookup auf Heap vs. Table Scan)
• Eine zentrale Erkenntnis hier war, dass die QueryStore Anzeige irreführend sein kann. Man sah für die Ausführung zwei Datenpunkte…einen mit wenig Ressourcenverbrauch und einen mit viel Verbrauch. Hier liegt es nahe, den Plan mit dem geringen Verbrauch zu erzwingen (force plan). Dies führt jedoch bei Ausführung mit dem anderen Spaltenfilter auf viele Datensätze zu einem deutlichen Nachteil.
• Weiter ging Torsten auf das Thema Cardinality Estimation ein. Hier gab es ja bei SQL 2014 eine neue Version des Cardinality Estimators. Dies ist die Komponente, die berechnet, wie viel Datensätze in den Operatoren eines Ausführungsplans zu erwarten sind bzw. geschätzt werden. Hier liegt klassischerweise eine Herausforderung, dass bei einer großen Fehleinschätzung der Anzahl Datensätze suboptimale Operatoren verwendet werden sowie Memory Grants nicht passen (spill to tempdb). Für mich war sehr interessant, dass Torsten die Anlage von composite statistics also benutzerdefinierten Statistiken mehrerer kombinierter Spalten in Einzelfällen empfohlen hat. Bislang habe ich mich hier an Brent Ozar gehalten, der sagte “Die Anlage einer Statistik hat mich bei der Performanceoptimierung leider noch nie über die Ziellinie gebracht”. Wichtig ist jedoch zu realisieren, dass eine solche Statistik nur bei AND-Bedingungen verwendet werden kann und nicht für OR.

Ich habe mir konkret zwei Dinge mitgenommen:

• Speichernutzung (RAM) von Query Store nachverfolgen
• Composite Statistics ausprobieren

Datenerfassung und Power BI: Wie geht das?

In diesem Vortrag von Robert Locher konnte ich zu Power BI neues hinzulernen.

• Mit der Einstellung “Direct Query” kann man eine Datenquelle so anbinden, dass sie direkt zugegriffen wird und die Daten nicht mit in das Power BI Modell mit eingehen. Dies bietet sich bei Daten aus einer relationalen Datenbank an, die regelmäßig durch Datenerfassung aktualisiert werden.
• Robert hat die Lösung Data1.io gezeigt.
  • Dies ist ein Webservice zur Datenerfassung, welcher die Einbindung von Excel Online unterstützt.
  • Darüber hinaus können Benutzer einen Workflow einstellen und Deadlines für die Pflege von Daten hinterlegen.
  • Charmant: Es gibt einen Gratiszugriff bei bis zu 20 Nutzern auf Lebenszeit
  • Konkret werden die Daten dann in einer generischen Tabelle gespeichert mit Spaltennamen wie DIM1, DIM2… gespeichert
  • Die Datenhaltung erfolgt in einer Azure SQL Database, wobei jeder Benutzer ein eigenes Schema erhält.
• Zur Einbindung in Power BI gibt es zwei Optionen
• Über PowerApps kann eine Datenpflegemaske (funktioniert auch auf Tablet und Mobiltelefon) angelegt werden. Ich habe diese Anwendung erstmals gesehen und es ist schon beeindruckend, wie man hauptsächlich durch Klicken und wenige formelartige Ausdrücke eine Webanwendung erstellen kann.
• Die PowerApp lässt sich anschließend auch direkt in Power BI integrieren.
• Eine andere Integrationsoption ist die Nutzung des custom visuals von data1.io, welches über eine Datei importiert werden kann.
  • Das Visual ist derzeit noch ein Proof of Concept und für den Präsentationsfall benutzerdefiniert durch einen namhaften Webprogrammierer entwickelt worden.

Let’s go digital: Der Weg zur digitalen Performanceoptimierung

In dieser Präsentation wurden von Daniel Caesar die Produkte im Bereich Performanceoptimierung der Firma sqlXpert vorgestellt. Auch wenn der Vortrag insgesamt neutral daher kam, war es aus meiner Sicht mehr ein Marketingvortrag. Konkrete Verbesserungen für meine Arbeit konnte ich hier nicht mitnehmen. Ganz interessant war jedoch, dass Daniel Caesar auf die Vorteile von noSQL einging und noSQL und SQL gegenüber stellte. Gerade bei der automatisierten Erstellung von Performancetuningvorschlägen für über 100 SQL Server Instanzen ist die sqlXpert mit klassischen SQL-Datenbanken wie SQL-Server an deren Grenzen gestoßen und setzt hierfür nun auf noSQL. Wesentlicher Bestandteil des neuen Produktangebots ist darüber hinaus die Integration von statistischer Analyse und Machine Learning, welches durch einen Data Scientist bei sqlXpert entwickelt wurde.

SQL Server Support

Kiril Panov hat unter diesem Titel wichtige DBA Basics präsentiert wie das Anfertigen eines Disaster Recovery Plans. Ich hatte die Gelegenheit Kiril beim Speakers Dinner vorher kennenzulernen. Er ist ein netter Typ der viel Erfahrung in der Administration mitbringt insbesondere im Bereich von großen Datenbanken. Sein Vortrag behandelte wichtige Aspekte wie die Festlegung eines Service Continuity Managers und auch eines Service Continuity Recovery Team sowie weitergehende wichtige Themen wie die Definition von RPO (wie viel Daten sind akzeptabel im Ernstfall zu verlieren?) und RTO (wie lange darf die Datenwiederherstellung längstens dauern?).

Leider schaffte es Kiril in seinem Vortrag jedoch nicht so gut, diese Themen auch rüberzubringen: Die Folieninhalte hatten meist sehr viel Text, den er öfter zu Beginn ablas um dann anschließend seine Erfahrungen und Tipps anzubringen. Dabei fühlte ich mich als Zuschauer nicht wirklich angeschaut und wahrgenommen. Anders jedoch die Antwort auf Fragen…hier gelang es ihm, den Blickkontakt aufzunehmen und diese zufriedenstellend zu beantworten. Ich wünsche Kiril, dass er seine Folien anders gestaltet und sich für die nächste Präsentation mehr auf die Vermittlung des Inhalts als den Inhalt selbst zu konzentrieren….letzteren hat er meiner Ansicht nach schon gut drauf.

Nach dem Vortrag sprach mich ein Teilnehmer an, wie ich das fand und meinte er würde sich beschweren über den schlechten Vortrag. Ich hab dazu zwei Herzen in meiner Brust: Ja, diese Konferenz kostet Geld und als bezahlender Teilnehmer kann ich erwarten gute Vorträge zu bekommen (ich hab dafür ehrlicherweise nicht bezahlt). Andererseits machen die meisten Referenten die Präsentation nicht hauptberuflich sondern als Ergänzung zu ihrer Arbeit (bei den Top Speakers oft im Bereich des Consulting für SQL Server). Daher glaube ich, man sollte niemanden von einer Konferenz ausladen sondern ihm Feedback geben, sich zu verbessern. Selbst beim PASS Summit hatte ich aus sicher 30 Sessions 2-3 dabei in denen ich mich nicht wohlfühlte….weil der Sprecher ständig etwas sagte, mit dem ich nicht einverstanden war oder weil meine Erwartungshaltung an die Session nicht erfüllt wurde. Das gehört einfach auch dazu, dass bei einer Konferenz nicht immer 100% der Vorträge genau ins Ziel treffen.

Database Scoped Configurations

Endlich war der erste Vortrag von Uwe Ricken, meinem mittlerweile guten Freund da. Es macht echt laune Uwe zuzuhören….er hat ein angeborenes Showtalent. Als eher ernsthafter Sprecher beneide ich ihn ein wenig darum, wie er zwischendurch Witze reißen kann und technische Pannen mit Tanzeinlagen und Albereien überbrücken kann. Auch seine Analogien sind immer wieder erfrischend.

In diesem Vortrag hat er die SQL Server Optionen vorgestellt, die seit SQL Server 2016 pro Datenbank eingestellt werden können. Für mich war nichts überraschend neues dabei, aber es hat dennoch Spaß gemacht ihm dabei zuzuhören.

Policy Based Management

Ein weiterer Vortrag von Uwe Ricken war für mich der krönende Abschluss der sqlDays. Ich kannte das Thema Policy Based Management schon vorher, hatte aber bisher den Eindruck, dass es sehr kompliziert und nutzlos ist (weil die Szenarien die ich hatte, damit nicht umsetzbar/verhinderbar waren). Durch Uwes genialen Vortrag habe ich meine Meinung jedoch schnell geändert.

Mit Hilfe von Policy Based Management kann man Abweichungen von gewollten Einstellungen automatisch erkennen und auch direkt beheben lassen. Ein klassisches Beispiel ist das Deaktivieren des sa-Accounts. Uwe hatte für einen Kunden die Überprüfung der SQL Server durch die Revision drastisch vereinbart: wo zuvor eine indische Firma beauftragt wurde mehrere Wochen lang für ein internes Audit 500 SQL-Server-Instanzen händisch durchzuprüfen, konnte mittels Policy Based Management die Überprüfung komplett automatisiert werden. Ausgangsbasis war der CIS Benchmark, eine Beschreibung von Security Best Practices bei Einstellungen in SQL Server. Das tolle an Policy Based Management ist, dass es gut auf etliche Server skaliert….es macht vom Setup her keinen großen Unterschied, ob man 5 Server oder 500 überprüfen möchte. Da ich bisher eher wenige Server administriert habe, gab es für mich die zwingende Notwendigkeit noch nicht….ich werde es aber nun auch bald bei “meinen Servern” einführen.

Für die Verwendung von Policy Based Management muss man vier Grundbegriffe auseinander halten:

• Facet: Kategorien für Einstellungen auf dem Server
  • Beispiel konfigurierbare Eigenschaften des SQL Servers
• Conditions:
  • Kann nur true oder false zurückliefern
  • Welchen Wert wollen wir überprüfen?
• Policy:
  • Kombination aus Facet und Condition
• Targets:
  • Gegen welche Server kann ich die Policies laufen lassen?
  • Vor allem Target Exceptions festlegen (Ausnahmen, die nicht geprüft werden)

Bei Conditions ist es besonders wichtig darauf zu achten, diese einfach zu halten und nicht zu komplex werden zu lassen. So können sie wiederverwendet und später auch miteinander kombiniert werden.

Ein interessantes Beispiel war hier beim Check des deaktivierten SA-Benutzers:

• geprüft wurde der Benutzer mit der ID 1: Warum über die ID? Weil der SA umbenannt werden kann (was tatsächlich auch ein Best Practice ist)
• eine weitere Bedingung ist IsDisabled = 1

Beim Target ist es wiederum wichtig hier nicht alle Benutzer auszuwählen sondern ebenfalls nur den sa-Account. Warum: So wird die unnötige Überprüfung anderer Benutzer (deren ID niemals 1 ist) übersprungen. Weiterhin (und noch wichtiger) wird damit verhindert, dass das Testergebnis für jeden Benutzer ausgegeben wird und so die Bedingung unübersichtlich macht.

Bei Policies, zu denen kein Facet existiert, kann stattdessen mit der Funktion ExecuteSQL gearbeitet werden, wobei der Datentyp numeric oder string angegeben werden muss. Hierbei muss genau darauf geachtet werden, dass aus dem auszuführenden SQL immer ein Wert 0 oder 1 zurückgegeben wird. 1 steht hierbei für true und damit die Erfüllung des Prüfkriteriums. Im Gegensatz zu Prüfungen auf Facets kann bei solch erweiterten Prüfungen die Behebung jedoch nicht automatisiert durch Policy Based Management erfolgen.

Mit Hilfe eines Central Management Server lassen sich die Policies dann auf mehreren Rechnern ausführen. Darüber hinaus ist das eine sehr praktische Funktion, um SQL-Befehle auf mehreren Servern gleichzeitig auszuführen. Dies war für mich auch neu und sehr interessant. Uwe zeigte noch einen Trick die Instanz hinzuzufügen, die auch den Central Management Server hält. Einfach ein INSERT in die Tabelle msdb.sysmanagement.shared.registered_servers . Dies wird aus SSMS heraus im Menü nicht angeboten aber dennoch perfekt unterstützt ;-).

Nach all diesen Schokoladenseiten von Policy Based Management sollen jedoch auch die aus meiner Sicht fehlenden Features genannt werden:

• Policies lassen sich aus SSMS heraus skripten. Das Skript ist jedoch ein XML für die Policy. Bei der Erstellung ist damit die GUI dem Skripten vorzuziehen. Darüber hinaus gibt es leider keinen Knopf, um mehrere Policies zu skripten. Hier scheint PowerShell eine mögliche Lösung zu sein….in den dbatools gibt es immerhin ein paar Skripte dazu, die ich mir aber auch noch anschauen muss. Uwe meinte auf meine Anregung “Probiers doch mit PowerShell” dann “Ist das was zum Essen?” :-).
• Policies können in SSMS mit ihrem Ergebnis schön angezeigt werden. Jedoch gibt es nur einen Export wiederum in XML und keine integrierte Möglichkeit eine nette PDF oder HTML daraus zu erzeugen. Für das Reporting von Policies muss man also selbst noch tätig werden, was im Fall von XML aber immerhin auch über eine XSLT-Transformation bei entsprechendem Knowhow gut möglich ist.