Verarbeitung von Queries 

Eine Query kann vom System in Teil-Queries zerlegt werden. Die Zerlegung findet unter folgenden Umständen statt:

●      Die Query enthält Zellen mit konstanter Selektion oder anderen Definitionen, die nicht mit einem logischen Lesevorgang gelesen werden können.

●      Die Query ist auf einem MultiProvider definiert, und aufgrund der  Selektionsbedingungen müssen die Daten mehrerer InfoProvider gelesen werden. Siehe dazu Zerlegung einer MultiProvider-Query in Teil-Queries.

●      Die Query enthält komplexe Selektionen, wie z.B. berechnete oder eingeschränkte Kennzahlen, möglicherweise mit Hierarchiebedingungen. Dann werden die Selektionen in mehrere Zugriffe aufgespaltet, etwa, um bei InfoCubes deren Aggregate nutzen zu können.

●      Die Query ist auf einem InfoCube definiert, beide Faktentabellen enthalten Daten und es wird nicht von dem Datenbank-View über beide Faktentabellen gelesen.

Wenn diese Zerlegung zu mehr als einer Teil-Query führt, wird der Lesevorgang  standardmäßig parallel ausgeführt.

Parallele Verarbeitung

Zur parallelen Ausführung von Queries werden mehrere Dialog-Workprozesse benötigt. Der maximale Grad der der Parallelität legt fest, wieviel Workprozesse maximal pro Query verwendet werden. Standardmäßig ist dieser Wert auf 6 beschränkt. Dieser Maximalwert kann durch den Eintrag QUERY_MAX_WP_DIAG in der Tabelle RSADMIN in einen Wert zwischen 1 und 100 geändert werden.

Der tatsächliche Grad der Parallelausführung richtet sich nach der aktuellen Systemauslastung und liegt zwischen 1 (sequentielle Ausführung) und dem Maximalwert. Ist die Anzahl der Teil-Queries größer als die maximale Parallelität, so werden alle vorhandenen Teil-Queries auf die durch den Grad der Parallelität festgelegten Workprozesse aufgeteilt.

An einem Synchronisationspunkt werden die Ergebnisse aller Teil-Queries gesammelt und zum Gesamtergebnis vereinigt.

Bei einer sequentiellen Verarbeitung werden die Teil-Queries nacheinander verarbeitet. Das Teilergebnis wird dabei sofort an die Analytic Engine weitergereicht.

Sequentielle Verarbeitung

In folgenden Fällen wird vom System eine sequentielle (nicht-parallele) Verarbeitung gewählt:

●      In der Tabelle RSADMIN existiert ein Eintrag QUERY_MAX_WP_DIAG mit dem Wert (Spalte VALUE) 1.

●      Die gesamte Query besteht nur aus einem Teilzugriff.

●      Die Query läuft in einem Batch-Prozess.

●      Die Query wurde über den Querymonitor (Transaktion RSRT) unter Anwendung diverser Debug-Optionen (Anzeigen der SQL Queries, Anzeigen der Ausführungspläne u.ä.) gestartet. Siehe dazu Zerlegung einer MultiProvider-Query in Teil-Queries.

●      Es handelt sich um eine Query, die Bestandskennzahlen abfragt.

●      Zum Ausführungszeitpunkt gibt es zu wenige freie Dialogprozesse; diese sind für eine parallele Verarbeitung notwendig.

●      Die Query ist für nicht-paralle Verarbeitung konfiguriert.

●      Das Ergebnis der Query soll in einer Datei oder einer Tabelle gespeichert werden.

Das System ist ab Release SAP Netweaver 7.0 in der Lage, auch große Zwischenergebnisse der parallelen Abarbeitung gut zu verwalten. Das System bricht nicht mehr, wie in den vorigen Releases, bei Erreichen einer bestimmten Zwischenergebnisgröße ab und liest nochmals sequentiell. Der in vorigen Releases verwendete RSADMIN-Parameter für nicht-paralleles Lesen eines MultiProviders wird deshalb nicht mehr verwendet.

Teilweise parallele Verarbeitung

Queries auf Bestands-InfoCubes können wegen ihres hohen Speicherverbrauchs nicht parallel verarbeitet werden. Deshalb werden alle Queries auf Bestands-InfoCubes unter den Teil-Queries von den übrigen Teil-Queries separiert; die „normalen“ Teil-Queries werden zuerst parallel verarbeitet, danach werden die Teil-Queries, die Bestände betreffen, sequentiell abgearbeitet.