Ist es in früheren Versionen des SQL Servers schon möglich, mittels Dynamic Managament Views (kurz: DMVs), auf die Metadateninhalte der relationalen Datenbanken zuzugreifen und diese zu analysieren, so gilt diese Möglichkeit für OLAP-Datenbanken erst seit der Version 2008. Somit werden dem Administrator und Analysten neue Möglichkeiten gegeben, verschiedenste Anforderungen und Sachverhalte auch für die Metadaten von Cubes zu untersuchen. Die Verwendung von DMVs hat den Vorteil, mittels abgesetzter SQL-Statements tabellarisch vorgefertigte Ausgaben zu erhalten. Natürlich gibt es hierfür auch externe Tools und nicht zuletzt den SQL Server eigenen Performance Monitor, aber mit dieser Möglichkeit der eigenen Zusammenstellung von Queries und Einbau in eigene Skripte, erhält der User zusätzliche Flexibilität.

Im Folgenden werden einige Mögliche Abfragen mit DMVs dargestellt.

So können beispielsweise folgende Sachverhalte geklärt werden:

• Aufzeigen der momentanen Verbindungen mit SSAS
• Verwendete Datenbanken, MDX Statements, Sessions
• Ausführungszeiten
• Auflistung der Würfelstrukturen (Hierarchien, Dimensionen)
• Verwendungshäufigkeit von Dimensionselementen und Measures in Abfragen

DMVs bezeichnen vorgefertigte Views zur Anzeige der SSAS Metadaten in Tabellenform, deren Katalog der vorhandenen Inhalte mittels SQL-Statements, aufgerufen im MDX Query Editor des SQL Management Studios, abgerufen werden kann. Eine Übersicht aller vorhandenen, möglichen DMVs erhält man somit bei einer Verbindung zu SSAS mit folgendem Statement:

SELECT * FROM $system.dbschema_tables WHERE Table_Schema = ‘$SYSTEM’ ORDER BY [TABLE_NAME]

Um solche Fragestellungen wie „wo besteht noch ein Bedarf an Aggregationen?“, „welche Indizes werden nicht mehr benutzt?“, oder „welche MDX Statements sind Langläufer?“ zu beantworten, lässt sich die Liste der DMVs zunächst einmal in drei sinnvolle Themengebiete unterteilen:

• Discover – Untersuchungsmöglichkeiten zu Memory Usage und Systemressourcen
• MDSchema – Datenbankschemarelvante Analysen
• DBSchema – Datenbankobjekte wie Dimensionen und Measures

Nun exemplarisch ein paar Beispiele und deren Ergebnisdarstellung im Bereich Discover.

Interessant ist sicherlich an erster Stelle die Möglichkeit, die SSAS Session der angemeldeten Benutzer auf der OLAP-Datenbank zu sehen.

SELECT * FROM $system.DISCOVER_CONNECTIONS

Des Weiteren die Möglichkeit der Objektaktivitäten, also die Quantität deren Verwendung:

SELECT * FROM $system.DISCOVER_OBJECT_ACTIVITY

Das vorliegende Ergebnis der Object Read und Writes liefert mögliche Aussagen darüber, welche Hierarchien/Objekte sich eventuell keiner großen Beliebtheit erfreuen und somit zur Aufräumung des Systems beitragen könnten, aber auch die Anzeige der Elemente, die wirklich an oberster Stelle stehen und somit unverzichtbar scheinen.

Mittels der Gruppe der MDSCHEMA DMVs werden nun nähere Informationen zu einzelnen Elementen, wie beispielsweise Tabellen und Hierarchien geliefert.

Liste der vorhandenen Measures:

SELECT * FROM $system.MDSCHEMA_MEASURES

Analog hierzu die gebräuchlichsten Abfragen zum Themengebiet MDSCHEMA:

select * from $system.mdschema_cubes
select * from $system.mdschema_dimensions
select * from $system.mdschema_hierarchies
select * from $system.mdschema_levels
select * from $system.mdschema_measuregroups
select * from $system.mdschema_measuregroup_dimensions
select * from $system.mdschema_measures
select * from $system.mdschema_properties
select * from $system.mdschema_members
select * from $system.mdschema_sets
select * from $system.mdschema_kpis
select * from $system.mdschema_input_datasources

Gerade auf dieser granularen Ebene mit den je nach Projekt und Datenbank sicherlich auch am meisten zurückgelieferten Datensätzen je Abfrage, steigt auch hier die Anforderung einer sinnvollen Filterungsmöglichkeit der Abfragen. Hier gibt es bei einer DMV-Abfrage Unterschiede zur herkömmlichen TSQL-Syntax, denn manche Einschränkungsmerkmale lassen sich hier nicht oder nur eingeschränkt verwenden. So ist die Möglichkeit von Joins und die Verwendung des LIKE Operators nicht gegeben.

select * from $system.mdschema_members where cube_name = ‘$Periode’ and [dimension_unique_name] = ‘[Periode]’ and [hierarchy_unique_name] = ‘[Periode].[Week]’

Zudem gibt es sogenannte „restricted DMVs“, deren Aufruf nur unter Verwendung einer vorgegebenen Einschränkung möglich ist. Hier ist unbedingt die case sensitive Schreibweise zu beachten.

Diese erkennt man auch immer daran, dass bei einem nicht vollends ausgefüllten Statement diese oder eine ähnliche Nachricht als Fehlermeldung erscheint:

Die ‘CUBE_NAME’-Einschränkung ist erforderlich, fehlt jedoch in der Anforderung. Verwenden Sie SYSTEMRISTRICTSCHEMA zur Angabe von Einschränkungen.

Hier ist unbedingt die case sensitive Schreibweise zu beachten.

SELECT * FROM SYSTEMRESTRICTSCHEMA ($SYSTEM.DISCOVER_DIMENSION_STAT, DIMENSION_NAME = ‘Produkte’, DATABASE_NAME=’Chair2008′)

Dies liefert eine Statistik über die ausgewählte Dimension:

Eine weitere denkbare Einsatzmöglichkeit wäre beispielsweise die Fragestellung, welche Partition weitere/geänderte Aggregationen benötigt.

SELECT
    OBJECT_PARENT_PATH,
    OBJECT_ID,
    OBJECT_CPU_TIME_MS,
    OBJECT_AGGREGATION_MISS
FROM
    $SYSTEM.DISCOVER_OBJECT_ACTIVITY
ORDER BY
    OBJECT_AGGREGATION_MISS DESC

Hierbei gibt die Spalte “OBJECT_AGGREGATION_MISS” Aufschluss darüber, bei wie vielen Abfragen die vorhandenen Aggregationen ungenutzt blieben, also verfehlt wurden.

Über ein linked Server bestünde nun die Möglichkeit, diese Daten aus der OLAP-Datenbank zu materialisieren und relational für jegliche Fragestellung und/oder weitere Nutzung zur Verfügung zu stellen.
Dies stellt zunächst nur einen kleinen Einblick dar. Denkbar wäre die Einbettung in DeltaMaster und vor allem liefert es hilfreiche Information über Systeme, deren Metadaten nicht per DeltaMaster Modeler erstellt wurden. In der MSDN Library (http://msdn.microsoft.com/en-us/library/ee301466.aspx) existiert eine Übersicht aller möglichen DMVs.