DeltaMaster ist ein sensationelles Planungswerkzeug. Dies hat uns kürzlich wieder ein Partnerunternehmen bestätigt, welches schon mit vielen anderen Frontends gearbeitet hat. Die Schwachstelle in SQL-Server-basierten Planungssystemen ist aktuell eher im Backend zu finden. Die Analysis Services sind zwar großartig im Verdichten, Verteilen und Vorhalten der Daten. Im Gegensatz zu dem relationalen Teil des SQL-Servers mag es die OLAP-Komponente allerdings überhaupt nicht, wenn Anwender gleichzeitig lesend und schreibend auf sie zugreifen. Unter gewissen Umständen kommt es dabei zu ernsthaften Zugriffsproblemen, bei denen der OLAP-Server in der Folge jegliche Kommunikationsversuche beharrlich verweigert. Wie es zu dieser Situation kommt und wie man sie umgeht, lesen Sie im nachfolgenden Blogbeitrag.
Nichts geht mehr
Man könnte meinen, dass Datenbank-Server, egal ob OLAP oder relational, mit gleichzeitigen Lese- und Schreiboperationen hinreichend gut umgehen können. Leider weit gefehlt. Mit relativ einfachen Mitteln kann man die Microsoft Analysis Services derart aus dem Tritt bringen, dass das komplette System nicht mehr antwortet. Man benötigt: zwei Clients, eine aufwändige Leseabfrage und eine Schreiboperation. Diese wenigen Zutaten reichen (leider) schon für den System-Supergau aus. Und Sie können sich vorstellen, dass diese Konstellation durchaus häufiger in einem Kundensystem anzutreffen ist. Folgendes Schaubild zeigt die problematische Situation:
Abb. 1: Schematische Darstellung der Problemsituation
Zunächst muss ein Anwender eine Abfrage mit einer längeren Laufzeit starten. Dies passiert in einem OLAP-System durchaus öfter, insbesondere wenn Anwender viele Dimensionen in die Zeilen einer Pivottabelle schachteln oder aufwendige Berechnungen durchführen. Gibt nun während der Laufzeit dieser Abfrage ein anderer Anwender (oder derselbe Anwender über ein zweites DeltaMaster-Fenster) eine Zahl ein, ist das Kind bereits in den Brunnen gefallen. Versucht man nun in irgendeiner Form auf den OLAP-Server zuzugreifen, bekommt man keinerlei Rückmeldung mehr. Das Dramatische daran ist, dass wirklich keine Anfrage mehr beantwortet wird; man kann sich weder an der Datenbank anmelden noch den Dimensionsbrowser öffnen, geschweige denn einen Bericht aktualisieren.
Wie kommt es zu dieser Situation? Die Antwort hat beim ersten Feststellen des Problems Microsoft selbst geliefert. Wenn den OLAP-Server eine Schreiboperation erreicht, versucht diese einen Database-Lock auf der Datenbank zu erstellen (ja, Sie haben sich nicht verlesen – tatsächlich einen Lock auf der gesamten DATENBANK). Dieser Lock kann aufgrund der laufenden Leseabfrage natürlich nicht erstellt werden, also reiht sich die Schreiboperation in die Warteschlange ein. Jede weitere Anfrage, die nun an die Datenbank gestellt wird, bekommt die Information, dass auf der Datenbank gerade ein sogenannter „Write-Lock-Request“ gesetzt ist und eine Schreiboperation auf Abarbeitung wartet. Die Anfragen bekommen keine Antwort bis die Schreiboperation ausgeführt werden konnte. Folglich warten alle Prozesse auf die Abarbeitung der initialen Leseabfrage. Dies ist natürlich auch der Fall, wenn die Leseabfrage sehr kurz ist, dann ist der Zeitraum aber so gering, dass die Problematik kaum ein Anwender bemerkt.
Warum eine Schreiboperation die ganze Datenbank sperren muss, ist nach wie vor verborgen geblieben. Es würde wohl ein Cube- oder MeasureGroup-Lock auch ausreichen. Laut Auskunft von Microsoft ist dieses Verhalten allerdings so tief im Rechenkern des Servers verankert, sodass eine Änderung nicht zu erwarten ist. Der zuletzt veröffentlichte SQL Server 2012 verhält sich ebenfalls noch identisch.
Aus eins mach zwei
Wie geht man nun in einem Planungssystem mit dieser Problematik um? Man sucht sich das kleinste Objekt, auf dem die Sperre gesetzt wird und versucht dies parallel zugänglich zu machen. In unserem Fall ist dies also die ganze OLAP-Datenbank. Wir kämen nicht in die oben geschilderte Situation, wenn sich beide Abfragetypen nie auf der gleichen Datenbank begegnen. Folglich bauen wir heute in der Regel zwei OLAP-Datenbanken in unseren Planungssystemen auf; eine zum Lesen und eine zum Schreiben. Da die OLAP-Datenbanken eigentlich nur die Inhalte der zugrundeliegenden relationalen Datenbank widerspiegeln, ist dies weitestgehend unproblematisch. Es müssen lediglich beide OLAP-Datenbanken mit der identischen relationalen Datenbank verbunden werden. Im einfachsten Fall ist also lediglich ein Backup der erstellten OLAP-Datenbank zu erstellen und unter anderem Namen wiederherzustellen. In DeltaMaster verbinden wir dann einfach die Planungsanalysesitzung mit der Schreibdatenbank und die Sitzungen für die (freie) Datenanalyse mit der Lesedatenbank. Die Architektur sieht dann ungefähr so aus:
Abb. 2: Möglicher Architekturvorschlag
Damit hat man schon fast alle Schritte für eine Behelfslösung hinter sich. Lediglich ein kleines Problem bleibt noch. Die Lesedatenbank bekommt es im Standard nicht mit, dass eine Usereingabe erfolgt ist. Folglich sieht der Leser nach einer Eingabe nicht unmittelbar, was durch einen anderen User in der Schreibdatenbank eingegeben wurde, obwohl beide auf den gleichen Tabellen arbeiten. Dies liegt am Caching der (Lese-)OLAP-Datenbank. Während sich der Cache der Schreibdatenbank durch die Eingabe aktualisiert, bleibt der Lese-Cache unverändert. Allerdings ist auch dieses Problem nicht allzu schwer zu lösen. Es gibt gleich zwei Lösungsalternativen:
- Regelmäßiges Löschen des Caches der Lesedatenbank
Mit einem kleinen XMLA-Befehl kann man über den Job-Agent den Cache der Lesedatenbank regelmäßig leeren. Vorteil an der Lösung: Man kann gezielt den Cache einer MeasureGroup löschen, ohne die anderen Objekte zu beeinflussen. Nachteil: Die Idee der Pufferspeicherung wird gänzlich ausgehebelt und das für alle anderen Partitionen einer MeasureGroup, egal ob MOLAP, ROLAP oder HOLAP.
Folgenden Befehl benötigt man zum Löschen des Caches:
2. Lesen mit Real-Time-OLAP
Bei der Verbindung mit der OLAP-Datenbank kann man konfigurieren, dass alle ROLAP-Partitionen (in unserem Fall also alle Rückschreibtabellen) direkt und ohne Cache gelesen werden sollen. Das Stichwort für dieses Verhalten ist „Real-Time-OLAP“. Vorteil: Nur die ROLAP-Partitionen werden direkt und ohne Cache gelesen, andere Speichertypen sind nicht betroffen. Nachteil: Der Parameter gilt immer für alle ROLAP-MeasureGroups, nicht nur für die benötigte. Um Real-Time-OLAP nutzen zu können, muss lediglich im DeltaMaster-Anmeldedialog eine erweiterte Option eingetragen werden:
Abb. 3: Einstellung im DeltaMaster-Anmeldedialog
Anschließend sind beide Datenbanken synchron und die Abfragen kommen sich nicht mehr in die Quere.
Ein Restrisiko bleibt allerdings auch bei der neuen Architektur. Auch die Planungsberichte in der Planungsanalysesitzung können prinzipiell eine hohe Abfragelast auf dem Server erzeugen. Je nach Aufbau der Berichte und abgefragter Datenmenge kann die Ladedauer auch hier so lang werden, dass man sich in oben beschriebenem Dilemma wiederfindet. Aber auch hierfür gibt es einen Ausweg.
Der weiß-blaue Ritter eilt zu Hilfe
Seit DeltaMaster Version 5.5.4 kann man über eine versteckte Option das Rückschreiben in eine fremde OLAP-Datenbank erzwingen. In unserem Szenario würden wir uns also beim Aufbau der Analysesitzung ganz normal mit der Lese-OLAP-Datenbank verbinden und in den neuen DeltaMaster-Parameter unsere Schreib-OLAP-Datenbank eintragen. Im Ergebnis werden alle (wirklich alle) Leseabfragen gegen die Lesedatenbank abgesetzt und nur die Schreibvorgänge (UPDATE CUBE) werden auf der Schreibdatenbank ausgeführt. Das Beeindruckende an dieser Technik ist, dass bei dem auf den Schreibvorgang folgenden Lesevorgang auch tatsächlich die zuvor eingegebenen Werte schon sichtbar sind. Und das, obwohl beide teilweise nur Millisekunden auseinander liegen. Für die Nutzung der Option muss zunächst folgender Registry-Key gesetzt werden:
[HKEY_CURRENT_USER\Software\Bissantz & Company\DeltaMiner 5.0] "EnableWritebackDatabase"=dword:00000001
Anschließend kann unter Extras – Optionen – Dateneingabe eine OLAP-Datenbank zum Rückschreiben per Freitexteingabe konfiguriert werden:
Abb. 4: Optionen für OLAP-Datenbank zum Rückschreiben
Damit die DeltaMaster-Logik funktioniert, müssen zwei Bedingungen auf Datenbankebene erfüllt sein. Zum einen muss auf der OLAP-Lesedatenbank das oben beschriebene Real-Time-OLAP eingeschaltet (und kein proaktives Caching aktiv) sein. Zum anderen muss auf der relationalen Rückschreibdatenbank die sogenannte Snapshot-Isolation eingeschaltet werden. Dies ist notwendig aufgrund des quasi-gleichzeitigen Lesens und Schreibens des gleichen Datensatzes. Die Snapshot-Isolation ermöglicht dies dadurch, dass dem Leser bis zum Abschluss des Schreibvorgangs eine Art Schattenkopie des ursprünglichen Datensatzes gezeigt wird. Zum Einschalten der Snapshot-Isolation muss folgender Befehl auf der relationalen Rückschreibdatenbank ausgeführt werden:
ALTER DATABASE SET ALLOW_SNAPSHOT_ISOLATION ON
Anschließend kann die beschriebene Technik vollumfassend verwendet werden.
Ein wichtiger Hinweis allerdings noch zum Schluss. Bei der Nutzung der Snapshot-Isolation muss man bezüglich der Anwenderanzahl auf dem System vorsichtig sein, da diese auf die Performance der Datenbank drückt. Bereits ab niedrigen zweistelligen Nutzerzahlen sollte man genau prüfen, ob die Planungsperformance insgesamt noch ausreichend ist. Sollte dies nicht gegeben sein, muss man ggfs. doch auf Alternative 1 ausweichen.
