Analysis Services auf dem SQL-Server: Full Process vs Process Update

Heute möchte ich mal wieder aus dem Nähkästchen plaudern und eine aktuelle Herausforderung aus dem Bereich Analysis Services auf dem SQL-Server (SSAS) erläutern. Es wird also wieder technisch.

Das Thema multidimensionale Datenbanken haben wir ja bereits im Detail behandelt. Dabei gibt es stets die Aufteilung in einen Cube, der die eigentlichen Daten beinhaltet und die beschreibenden Dimensionen darum herum.
Wenn eine Dimension überdimensional groß ist, dauert ein Update oder eine Veränderung entsprechend lange. Dabei gibt es verschiedene Verarbeitungsmethoden. Beim Full Process wird immer alles verarbeitet, egal was mit den Daten passiert ist und was aktualisiert wurde. Bei einem Process Update wird hingegen geprüft, was geändert oder zugefügt wurde und nur das wird aktualisiert.

In einem aktuellen Kundenprojekt haben wir den Fall, dass wir einen sehr großen Cube mit zum Teil auch überdurchschnittlich großen Dimensionen haben. Bisher haben wir zur Aktualisierung der Dimensionen die Methode Process Update genutzt, in der Erwartung, dass es die schnellere Methode ist.
Für den Cube ist das Processing so gestaltet, dass immer nur die Partitionen verarbeitet werden, welche vorab über eine Anwendung definiert wurden (auf Monatsebene). Somit werden nur die Daten aktualisiert, welche geändert oder neu hinzugekommen sind. Alle bestehenden Daten außerhalb dieser Partition bleiben unberührt.

Aktuell kam jedoch die Diskussion auf, ob die Performance für das Verarbeiten der Dimensionen so tatsächlich besser ist, oder ein Full Process wider Erwarten schneller sein kann. Daher haben wir die Methode umgestellt und Full Process eingeführt. Die Umstellung in der Dimension brachte jedoch den unschönen Nebeneffekt mit sich, dass im Cube nur noch die aktuell zu verarbeitende Partition verfügbar war. Alle anderen (historischen Partitionen) waren nicht mehr verfügbar bzw. unprocessed. Wenn man das ganze einmal genauer betrachtet, ist dieser Fall auch durchaus logisch. Dadurch dass sich die Dimension insgesamt verändert hat, muss theoretisch auch jede (historische) Partition neu verarbeitet werden, um die Veränderungen der Dimension mitzubekommen.

Unsere „Lesson learned“ ist also, dass man sich vorab sehr genau überlegen sollte, welche Änderungen man an einem Cube vornimmt. Vor der Umsetzung der vermeintlichen Verbesserung sollte immer geprüft werden, in wie fern hier Auswirkungen auf den Cube bzw. dessen Verfügbarkeit entstehen.
Nachdem die Process-Methode der Dimension wieder zurück auf Process Update geändert wurde, funktionierte wieder alles problemlos.

Datenzugang beschränken bei Analysis Services auf dem SQL-Server

Heute möchte ich ein aktuelles Beispiel aus einem Kundenprojekt vorstellen, da sicher einige Analysten vor einer ähnlichen Herausforderung stehen. Dazu entführe ich Sie kurz in die technischen Abgründe der Analysis Services auf dem Microsoft SQL-Server, genauer gesagt in die Row-Level-Security.

Im laufenden Projekt ergab sich die Anforderung, dass Daten für bestimmte User erst ab einem bestimmten Zeitpunkt im Cube sichtbar sein dürfen, nämlich wenn sie explizit freigegeben sind. Eine definierte Gruppe (z.B. beteiligte Analysten und Datenlieferenten) soll die Daten zuerst sehen und prüfen können, bevor diese z.B. auch von der Geschäftsführung und dem Management einsehbar sind. So wird verhindert, dass Verwirrungen entstehen oder falsche Entscheidungen getroffen werden.

So weit so gut, ich habe – wie schon in anderen Projekten auch – alles vorbereitet, um die Row-Level-Security für den Cube zu implementieren.
Nachdem die Vorbereitungen auf der relationalen Ebene abgeschlossen waren, bin ich im Cube hergegangen und habe die entsprechenden Rollen angelegt. Eine Superuser-Rolle, deren Mitglieder alles sehen darf und die User Rolle, welche nur die speziellen Daten sehen darf.
Die Superuser-Rolle war schnell erledigt, da diese gänzlich ohne Row-Level-Securtiy auskommt.

Als ich dann die User-Rolle angelegt hatte und die entsprechenden Attribute mit den MDX-Statements zur Securtiy versehen hatte, bekam ich beim Browsen im Cube die Fehlermeldung: „Das Attribut ‘XXX’ in der Dimension ‘YYY’ hat einen generierten Dimensionssicherheitsausdruck, der nicht gültig ist.“ (The ‘XXX’ attribute in the ‘YYY’ dimension has a generated dimension security expression that is not valid).

Nach einiger Recherche und Analyse stellte ich fest, dass die Security nicht in der Cube-Dimension, sondern auf der Datenbankdimension hinterlegt war. Die Datenbankdimensionen werden in der Darstellung zuerst angezeigt, anschließend erst die Cube Dimensionen, was mir hier zum „Verhängnis“ wurde.
Die Cube Dimension ist eine Instanz der Datenbank Dimension in einem speziellen Cube. Die Datenbank Dimension kann in mehreren Cubes oder in einem Cube mehrfach (Role-Playing Dimension) verwendet werden.

Die Darstellung in Visual Studio ist also etwas ungünstig. Teilweise hat man so viele Dimensionen in Einsatz, dass die Darstellung unübersichtlich wird und die zuunterst dargestellten leicht übersehen werden können.
Es gilt unbedingt zu beachten, die Row-Level-Security immer auf Cube-Ebene und nicht auf Datenbankebene zu setzen.

Es handelt sich hierbei zwar um ein recht triviales Problem, aber wie sooft ist die Fehlermeldung nicht sonderlich hilfreich, sodass man nicht sofort darauf kommt, dass die Sicherheit auf der falschen Ebene gesetzt wurde.