Michael Mukovskiy

Eine verbreitete Meinung lautet: Writeback ist lediglich performant bei einer kleinen Anzahl von Usern.

Unsere Erfahrung hat uns jedoch etwas anderes gelehrt: Die Performance des Writebacks ist vor allem davon abhängig, wie die Architektur und allgemeine Performance des Cubes aussieht, und wie genau die User mit dem Writeback arbeiten (wie oft die COMMITs erteilt werden). Eigentlich sind diese drei Faktoren in der Regel beeinflussbar. Auch bezüglich der Arbeitsweise kann man den Usern empfehlen wo möglich mehr UPDATEs unter einem COMMIT sammeln.

Wir lassen jetzt aus dem Scope die Writeback-Szenarien auf den höheren Cube-Ebenen, die unvermeidbar zur großen granularen Verteilungen führen. In solchen Fällen ist es logisch, dass die großen Ressourcen für die Verteilung der Werte erst bei UPDATE im Session-Cache, dann bei COMMIT für Bulk Insert in die Tabelle der Writeback-Partition und anschließend für die Aktualisierungen in anderen Sessions benötig werden.

Bei Writebacks nah zur Faktengranularität (Leaves) sind diese Aufwände an sich eher bescheiden.

Das Hauptproblem des Writebacks ist, dass der COMMIT technisch als Cube-Prozessierung angesehen werden kann und zwar mit üblichen Problemen bei Prozessierungen: Sperrungen der AS-Datenbank, Cache-Verluste und Abbrüche der langlaufenden Abfragen. Alle diese Downsides kommen nicht in etwas vom “suboptimalen Design” des Analysis Services, sondern sind als normales “Tradeoff” innerhalb eines Systemes anzusehen, in welchem Lese- sowie Schreiboperationen zeitgleich vorkommen.

Da in der Regel bei mehreren parallel arbeitenden Writeback-Usern die Anzahl der COMMITs steigt, sinkt im Umkehrschluss die allgemeine Cube-Performance spürbar. Dies spiegelt sich zudem in der User Akzeptanz wieder.

Anbei betrachten wir eine Standardsituation, bei welcher während einer langen MDX-Abfrage ein COMMIT in die gleiche AS-Datenbank kommt:

image

Der COMMIT wartet bis 30 Sekunden (Defaulteinstellung) auf langlaufende Abfragen. Innerhalb dieses Zeitfensters ist die ganze AS-Datenbank für alle weiteren Aktivitäten gesperrt.

Dies betrifft nicht nur die Abfragen, sondern auch die UPDATEs, die ansonsten schnell sind, die aber hier als Teil eines „langsamen Writebacks“ wahrgenommen werden. Dass die Langläufer nach 30 Sekunden abgebrochen werden – bringt eine zusätzliche negative Erfahrung bei Usern.

Und das ist genau unsere Beobachtung: die langlaufenden Abfragen auf die gleiche Datenbank verursacht meistens die Probleme mit Writebacks.

Eine weitere Downside: Die Abfragen bei Writeback-Usern zwischen UPDATE und COMMIT laufen genauso langsam wie mit einem “kalten” Cache, da die “normalen” Cube-Daten jetzt mit den Writeback-Deltas aus dem Session-Cache zusammengeführt werden müssen!

Die Hauptmaßnahmen lauten also: den Cube und Abfragen für die Performance so optimieren, dass die Abfragen auch mit “kaltem” Cache maximal nur wenige Sekunden laufen, und möglichst Cube(s) in separate AS-Datenbanken splitten um die breiten Locks zu vermeiden.

Für die Problemdiagnostik reicht normalerweise im Profiler die AS- und SQL-Instanz zu beobachten.

Noch ein Hinweis: man muss sicherstellen, dass die relationalen Writeback-Tabellen von INSERTs und DELETEs nicht zu fragmentiert sind, was zur unnötigen Verschwendung der Ressourcen bei einfachen Operationen führen kann. Hier schadet ein regelmäßiges TRUNCATE TABLE nicht.