Indexunterstützung bei der Bestimmung von Objektnummern
Bei der Einbuchung von Belegen in die Ergebnisrechnung muß zu der gerade vorliegenden Kombination von Merkmalswerten eine Ergebnisobjektnummer bestimmt werden. Dabei ist es außerordentlich wichtig, daß diese Bestimmung so schnell als möglich erfolgt, da andernfalls der Gesamt-Durchsatz bei einer Sammelfaktura oder bei Fremddatenübernahmen (also wenn viele Ergebnisobjekte gleichzeitig bebucht werden sollen) deutlich zurückgehen kann.
Im folgenden werden technische Aspekte bei der Bestimmung der Objektnummer und mögliche Probleme beschrieben. (Diese Informationen gelten Release-unabhängig ab 2.1A.)
Datenstruktur der Objekttabelle
Die Objekttabelle CE4xxxx enthält als wesentliche Bestandteile eine eindeutige Ergebnisobjektnummer im Key sowie im Datenteil alle Merkmale Ihrer Ergebnisrechnung. Die Tabelle CE4xxxx hat den folgenden Aufbau:
Feldname |
Key |
Bemerkung |
MANDT |
X |
Mandant |
AKTBO |
X |
enthält zur Zeit immer 'X' |
PAOBJNR |
X |
Ergebnisobjektnummer |
PASUBNR |
X |
enthält zur Zeit immer '0001' |
KNDNR |
Kundennummer | |
ARTNR |
Materialnummer | |
FKART |
Fakturaart | |
weitere feste Merkmale | ||
beim Customizing in den Ergebnisbereich aufgenommene Merkmale | ||
weitere technische Felder | ||
Es besteht also eine eindeutige Beziehung zwischen der Ergebnisobjektnummer einerseits und der im Datenteil spezifizierten Kombination von Merkmalswerten andererseits.
Selektion der Objekttabelle zur Bestimmung der Objektnummer
Bei der Buchung eines Beleges in die Ergebnisrechnung (z.B. bei einer Faktura, Auftragsabrechnung oder Fremddatenübernahme) muß anhand der gerade vorliegenden Kombination von Merkmalswerten die zugehörige Ergebnisobjektnummer bestimmt werden. Dazu wird eine Selektion auf die Objekttabelle mit voll spezifiziertem Datenteil wie folgt durchgeführt:
SELECT * FROM CE4xxxx
WHERE AKTBO = 'X'
AND KNDNR = ...
AND ARTNR = ...
AND FKART = ...
AND (alle weiteren Merkmale ebenfalls spezifiziert)
Implizit wird bei dieser Selektion durch das ABAP-Laufzeitsystem zusätzlich eine Mandantenbedingung spezifiziert.
Der ausgelieferte Sekundärindex
Die Effizienz dieser Ergebnisobjektnummernbestimmung aus der Objekttabelle ist außerordentlich wichtig für die Gesamt-Performance bei Sammelfakturen, bei der Fremddatenübernahme und bei der Kontierung auf Ergebnisobjekte (Auftragsabrechnung, Direktkontierung auf Ergebnisobjekt in der Finanzbuchhaltung usw.).
Der Primärindex (Indexkennung 0) über den Key der Objekttabelle ist bei der Durchführung der beschriebenen Selektion ungeeignet. Daher versucht SAP, den Zugriff durch einen geeigneten Sekundärindex (Indexkennung 1) zu unterstützen. In der Standard-Auslieferung enthält dieser Index eine Auswahl aus den festen Merkmalen, die in jedem Ergebnisbereich enthalten sind:
Verwendung von Indizes für Suchfragen
Ein Index enthält eine Kopie einiger weniger Felder der Datensätze einer Datenbanktabelle, die - im Gegensatz zur Ablage der Daten in der Tabelle selbst - sortiert vorgehalten werden. Dadurch kann sehr effizient auf die Daten im Index zugegriffen werden. Zusätzlich ist in jedem Index-Eintrag ein "Zeiger" auf den "zugehörigen" Datensatz in der Tabelle enthalten.
Werden nun bei einer Suchfrage Bedingungen an in einem Index enthaltene Felder gestellt, so kann ein Teil der Suchfrage lediglich unter Verwendung der im Index enthaltenen Daten abgearbeitet werden. Gewisse Indexeinträge - und damit die zugehörigen Datensätze - können also bereits ohne direktes Lesen der Tabelle ausgeschieden werden.
Für die verbleibenden Indexeinträge müssen dann die zugehörigen Datensätze aus der Tabelle gelesen werden. Erst dann kann überprüft werden, ob ein Datensatz auch dem Rest der Suchfrage genügt, also zur Treffermenge gehört oder nicht. Dieses Lesen vollständiger Datensätze ist - verglichen mit dem Lesen des Index - teuer.
Man versucht daher, den Index so zu definieren, daß die Anzahl der aus der Tabelle zu lesenden Datensätze nicht viel größer ist, als die Anzahl der Treffer (d.h. derjenigen Sätze, die die Suchbedingung erfüllen). Man spricht dann von einem selektiven Index, da er die selektierende Wirkung der Suchfrage bereits zu einem hohen Grad abbildet.
1: Ergebnisrechnung auf der Ebene Kunde / Artikel
Wird die Ergebnisrechnung mit den Merkmalen Kunde und Artikel betrieben, so werden die Daten von Fakturen im SD in dieser Detaillierung in die Ergebnisrechnung übernommen. Wird nun das zu einer Fakturaposition gehörige Ergebnisobjekt bestimmt, so sind in der Select-Anweisung oben KNDNR und ARTNR nicht leer. KNDNR und ARTNR haben überdies in der Objekttabelle sehr viele verschiedene Werte (sie sind selektive Felder in der Objekttabelle). Der Sekundärindex MANDT, AKTBO, KNDNR, ARTNR, BUKRS, WERKS, VTWEG ist also ebenfalls selektiv und die Bestimmung der Ergebnisobjektnummer ist effizient möglich.
2: Ergebnisrechnung auf höherer Ebene
Betrachten wir alternativ eine Installation, bei der im Menüpunkt "Merkmalsverwendung" die Merkmale Kunde und Artikel von der Ergebnisrechnung ausgeschlossen wurden (siehe dazu das Kapitel Strukturen ® Merkmale der Ergebnisobjekte festlegen (Merkmalsverwendung) im Customizing).
Die Sätze in der Objekttabelle CE4xxxx enthalten nun in den Feldern KNDNR und ARTNR stets den Wert ‘SPACE’ (leer). Der oben angegebene Index ist also nicht selektiv. Die Selektion zur Bestimmung der Ergebnisobjektnummer lautet in diesem Fall:
SELECT * FROM CE4xxxx
WHERE AKTBO = 'X'
AND KNDNR = ' '
AND ARTNR = ' '
AND FKART =
fester WertAND
(alle weiteren Merkmale ebenfalls spezifiziert)
Ein Problem entsteht nun dadurch, daß die selektiven unabhängigen Felder (in diesem Fall vielleicht Kundengruppe und Sparte) zwar bei der Selektion spezifiziert werden, aber in dem verwendeten Sekundärindex nicht vorkommen. Demgegenüber sind die vergleichsweise wenig selektiven Felder MANDT (in der Regel ein Wert), AKTBO (immer 'X'), KNDNR und ARTNR (immer SPACE), BUKRS, WERKS und VTWEG (in der Regel wenige verschiedene Merkmalswerte) im Sekundärindex enthalten. Beim Zugriff über diesen Index (index range scan) müssen also alle Sätze der Objekttabelle mit den angegebenen Werten für MANDT, AKTBO, KNDNR, ARTNR, BUKRS, WERKS, VTWEG gelesen werden. Unter ungünstigen Umständen können dies alle Sätze der Objekttabelle sein. Der Zugriff wird dann äußerst ineffizient und kann die Laufzeit der Faktura dominieren.
Anhand dieser Beispiele kann man folgende Regel ableiten:
Regel:
Ein Sekundärindex ist zur Unterstützung der Bestimmung der Ergebnisobjektnummer geeignet, wenn er gerade die logisch unabhängigen, selektiven Merkmale aus der Objekttabelle enthält. Damit das Datenbanksystem nicht den Primärindex vorzieht, müssen die Felder MANDT und AKTBO als erste Felder des Sekundärindex verwendet werden.
3: Geeigneter Sekundärindex
Wird etwa mit den Merkmalen Kunde/Artikel gearbeitet, so ist gemäß obiger Regel ein Index über MANDT, AKTBO, KNDNR, ARTNR angebracht. Sind dagegen Kunde und Artikel ausgeblendet und sind nun Kundengruppe (KDGRP) und Sparte (SPART) die unabhängigen Merkmale, so wäre ein Index über MANDT, AKTBO, KDGRP, SPART wesentlich sinnvoller. Für die Zusammenstellung eines geeigneten Sekundärindex ist es also erforderlich, sich Kenntnisse über die logische Hierarchie der Merkmale des Ergebnisbereichs zu verschaffen.
Buchungen auf mehreren Hierarchieebenen
Mit dem in der obigen Regel vorgeschlagenen Sekundärindex ist die Bestimmung der Ergebnisobjektnummer für die Faktura performant möglich. Allerdings ergibt sich ein weiteres Problem, wenn aus anderen Transaktionen Buchungen auf einer weiteren Hierarchieebene vorgenommen werden.
3.1: Fremddatenübernahme auf hoher Ebene in die Planung
Wir betrachten nun eine Ergebnisrechnung auf Ebene Kunde/Artikel, wobei die Planung auf der Ebene Kundengruppe (KDGRP) und Sparte (SPART) erfolgen soll. Für die Übernahme von Fakturadaten ist der oben beschriebene Sekundärindex MANDT, AKTBO, KNDNR, ARTNR geeignet.
Bei der Erfassung von Plan-Belegen auf höherer Ebene kann sich ein Performance-Problem bei der Bestimmung der Ergebnisobjektnummern für diese ergeben: Zur Bestimmung der Ergebnisobjektnummer müssen alle Objekttabellensätze mit dem Wert SPACE in den Feldern KNDNR und ARTNR gelesen werden. Ist eine nennenswerte Anzahl solcher Sätze vorhanden, verschlechtert sich die Performance erheblich.
3.2: Buchhalterische Ergebnisrechnung
Wenn die kalkulatorische Ergebnisrechnung auf Ebene Kunde/Artikel durchgeführt wird, diese Merkmale aber für die buchhalterische Ergebnisrechnung ausgeblendet sind, entsteht ein ähnliches Problem.
Die oben aufgestellte Regel bedarf also einer Verfeinerung. Es sollten nicht nur die im Ergebnisbereich unabhängigen Merkmale in den Sekundärindex aufgenommen werden. Es gilt folgendes:
Regel:
Ein "optimaler" Index zur Unterstützung der Bestimmung der Ergebnisobjektnummer enthält (nach MANDT und AKTBO) gerade die logisch unabhängigen, selektiven Merkmale für alle vorkommenden Ergebnisobjektnummern-Bestimmungen (auch auf höheren Ebenen).
Anmerkungen
4: Optimaler Sekundärindex
Im obigen Beispiel einer der Ergebnisrechnung auf Ebene Kunde/Artikel und Planung auf Ebene Kundengruppe/Sparte wäre ein Sekundärindex über MANDT, AKTBO, KNDNR, ARTNR, KDGRP, SPART geeignet. Werden Ergebnisobjekte auf weiteren, hierarchisch höher liegenden Ebenen (etwa als Ergebnis von Kostenstellenumlagen) benötigt, so muß dieser Index nochmals entsprechend erweitert werden.
Es ist übrigens nicht sinnvoll, statt der Erweiterung des ersten Sekundärindexes weitere Indizes anzulegen, etwa Index 1 über MANDT, AKTBO, KNDNR, ARTNR und Index 2 über MANDT, AKTBO, KDGRP, SPART ! Da die Selektionsbedingung zur Bestimmung der Ergebnisobjektnummer in allen Fällen voll spezifiziert ist, wird immer derselbe Index verwendet.
An dieser Stelle empfehlen wir ausdrücklich, den von SAP ausgelieferten Sekundärindex mit Indexkennung 001 durch einen auf Ihre spezielle Umgebung optimierten Sekundärindex zu ersetzen.
Sie können mit Hilfe der Transaktion SQL-Trace und der Drucktaste Explain SQL überprüfen, daß der von Ihnen neu angelegte Sekundärindex bei der Bestimmung der Ergebnisobjektnummer auch tatsächlich verwendet wird. Siehe dazu
Die Funktion Explain SQL erläutert die Zugriffstrategie der Datenbank bei der Abarbeitung eines SELECT Statements. Sie müssen dazu in der Listansicht des SQL Trace ein OPEN- oder REOPEN-Statement auf die Tabelle CE4xxxx suchen. Anhand der dort angegebenen Zeit (die deutlich unter 100 Millisekunden liegen sollte) können Sie sich auch ein Bild von der absoluten Effizienz des gewählten Zugriffspfades machen.