Show TOC

Pruning von Queries auf MultiProvidernLocate this document in the navigation structure

Wenn ein MultiProvider aus sehr vielen InfoProvidern besteht, dann ist es sinnvoll, Pruning für diesen MultiProvider zu nutzen. Die Query wird dann in mehrere Teil-Queries aufgeteilt und damit verteilt sich auch die Last auf dem System. Durch Prüfungen, ob ein beteiligter InfoProvider überhaupt Daten für den Selektionsbereich enthält, wird die Abfragelast weiter reduziert. Nicht relevante InfoProvider werden dann erst gar nicht abgefragt.

Dann wird beim Ausführen einer Query geprüft, ob ein beteiligter InfoProvider Daten für den Selektionsbereich enthält. Wenn nicht, dann wird er nicht abgefragt.

Es gibt verschiedene Möglichkeiten, Pruning für Queries zu nutzen:

  • basierend auf der Definition einer Konstanten

  • basierend auf einer Einschränkung der Metadaten:

    • semantisch partitionierte Objekte

    • Pruning basierend auf den beteiligten InfoProvidern

  • basierend auf den gebuchten Daten: Teil-Queries auf InfoCubes über RRKMULTIPROVHINT

Basierend auf der Definition einer Konstanten

Wenn ein Merkmal auf konstant gesetzt wird, dann kann dies mit dem Selektionsbereich in der Query abgeglichen werden. Wenn der Selektionsbereich den Wert der Konstante nicht beinhaltet, dann kann dieser InfoProvider beim Ausführen der Query übersprungen werden.

Weitere Informationen: Zusätzliche Funktionen bei der InfoCube-Pflege

Basierend auf einer Einschränkung der Metadaten

Das Pruning basierend auf Metadaten kann für MultiProvider eingesetzt werden und wird automatisch für semantisch partitionierte Objekte eingesetzt. CompositeProvider und die Transaktion LISTCUBE nutzen diese Art des Pruning auch.

Für semantisch partitionierte Objekte:

Das Pruning für semantisch partitionierte Objekte (sowohl auf InfoCubes als auch auf DataStore-Objekten) wird automatisch genutzt. Beim Anlegen von semantisch partitionierten Objekten wird bereits definiert, wie die Daten in die einzelnen Partitionen verteilt werden. Diese Information wird in den Tabellen RSLPOPART und RSLPOPARTRANGE gespeichert. Beim Ausführen einer Query werden diese Tabellen überprüft und mit dem Selektionsbereich der Query abgeglichen. InfoProvider, die nicht in den Selektionsbereich fallen, werden dann nicht abgefragt.

Die Konsistenz zwischen dem Selektionsbereich und den gebuchten Daten wird dabei über den entsprechenden Filter im DTP garantiert.

Für MultiProvider, basierend auf den beteiligten InfoProvidern:

Für MultiProvider kann dasselbe Prinzip wie für semantisch partitionierte Objekte angewandt werden. Dabei werden InfoCubes und DataStore-Objekte unterstützt, vom Typ Standard und SAP-HANA-optimiert. Im Gegensatz zum semantisch partitionierten Objekt, wo die Partitionskriterien bei der Definition festgelegt werden, definieren Sie diese erst später in der Tabelle RSIPRORANGE und passen diese evtl. an, wenn sich der Bereich durch Datenladen geändert hat.

Wenn ein semantisch partitioniertes Objekt komplett im MultiProvider enthalten ist, dann werden die Partitionskriterien aus der Tabelle RSLPOPARTRANGE beim Ausführen der Query gelesen. Einschränkungen, die in der Tabelle RSIPRORANGE definiert wurden, werden für komplette semantisch partitionierte Objekte nicht herangezogen.

Wenn nur Teile eines semantisch partitionierten Objekts im MultiProvider verwendet werden, dann werden die Partitionskriterien aus der Tabelle RSLPOPARTRANGE beim Ausführen der Query nicht gelesen. In diesem Fall müssen Sie die Einschränkungen manuell in der Tabelle RSIPRORANGE definieren. Sie können für jedes in den InfoProvidern enthaltene InfoObject Einschränkungen definieren und diese Einschränkungen müssen nicht mit den Partitionskriterien des semantisch partitionierten Objekts übereinstimmen.

Weitere Informationen: Pruning für MultiProvider administrieren

Berücksichtigung der Zeithierarchie

Für InfoCubes kann dabei für Einschränkungen auf einem Zeitmerkmal eine Konvertierung auf ein anderes Zeitmerkmal, das in der Query verwendet wird, erfolgen. Beispielsweise wird eine Einschränkung auf 0CALYEAR in eine entsprechende Einschränkung auf 0CALMONTH umgewandelt und dann wird das Pruning durchgeführt.

Dabei werden allerdings nicht alle Kombinationen von Zeitmerkmalen konvertiert, sondern nur für solche, die schnell berechnet werden können. Insbesondere können keine Konvertierungen zwischen 0CAL- und 0FISC-Zeitmerkmalen erfolgen.

Folgende Zeitmerkmale werden unterstützt: 0CALDAY, 0CALMONTH, 0CALQUARTER, 0CALYEAR 0FISCPER, 0FISCYEAR.

Basierend auf den gebuchten Daten

Das Pruning basierend auf gebuchten Daten ist schon seit BW 3.x verfügbar, es hat allerdings die Einschränkung, dass es nur für InfoCubes als beteiligte InfoProvider verfügbar ist.

Sie können das Pruning auf gebuchten Daten über einen Eintrag in der Tabelle RRKMULTIPROVHINT aktivieren. Dann führt das System eine Vor-Query mit einem vorgegebenen Selektionsbereich für die InfoObjects aus, die in der Tabelle RRKMULTIPROVHINT gespeichert sind. Das Ergebnis wird zwischengespeichert.

Für weitere Informationen lesen Sie How to Create Efficient MultiProvider Queries im SAP Community Network unter http://scn.sap.com/docs/DOC-15981Auf SAP-Site veröffentlichte Informationen.

Hinweis

Wenn Sie diese Lösung verwenden, dann können Sie sie weiter nutzen. Aber die neue Methode des Prunings basierend auf Metadaten ist vielfältiger einsetzbar und Sie sollten prüfen, ob sie für Ihren Anwendungsfall nicht geeigneter ist.

Wenn Sie eine SAP-HANA-Datenbank im Einsatz haben, dann sollten Sie statt des Prunings auf gebuchten Daten das Pruning basierend auf Metadaten verwenden. Denn da bei Verwendung einer SAP-HANA-Datenbank keine Dimensionen mehr existieren, müsste die Vor-Query auf die Faktentabelle gehen, und das würde zu einer langen Laufzeit der Vor-Query führen.