Sekundärindex zieht nicht

Sekundärindex zieht nicht

Hi,

wir haben einen Sekundärindex auf der MARA liegen, die das Feld NORMT betrifft.

Scheinbar wird der von den vorhandenen Matchcodes gezogen, von meinem Programm aber nicht. Soweit ich weiß, muss man beim Datenbankzugriff nicht sagen "nimm den Sekundärindex", sondern das entscheidet der Datenbankoptimizier.

Die Laufzeit des entsprechenden Programmes, das das Feld NORMT in der WHERE-Bedingung des MARA-Selects hat, ist grauenvoll (es steht NUR das Feld NORMT in der WHERE-Bedingung, das ist auch explizit so gewollt).


Ralf *hilflos in die Runde guckt

Re: Sekundärindex zieht nicht

ralf.wenzel hat geschrieben:Die Laufzeit des entsprechenden Programmes, das das Feld NORMT in der WHERE-Bedingung des MARA-Selects hat, ist grauenvoll (es steht NUR das Feld NORMT in der WHERE-Bedingung, das ist auch explizit so gewollt).

Das ist aber schon seit Jahren Unsinn.
Früher war es mal nötig, den Optimizer auszutricksen, als Oracle in Kombination mit SAP R/3 noch so konfiguriert war, dass statt des Cost Based Optimizers der Rule Based Optimizer verwendet wurde.

Wie sieht das SELECT-Statement genau aus?
Wie ist der Index genau definiert, wie viele Einträge hat die MARA? Wie viele verschiedene Werte für NORMT (bzw. für die Kombination von Feldern des Sekundärindex) gibt es in der MARA?
Wann wurde die Statistik zuletzt aktualisiert?
Was sagt Oracle bezüglich Selektivität des Sekundärindex?

Fragen über Fragen.
Ohne ein paar mehr Infos kann man nur im Nebel stochern.
Wenn der Matchcode-Zugriff im Gegensatz zu Deinem Programm effizient ist, musst Du noch irgendetwas falsch machen.

Re: Sekundärindex zieht nicht

ralf.wenzel hat geschrieben:

Frank Dittrich hat geschrieben:Das ist aber schon seit Jahren Unsinn.

Was genau ist Unsinn an der von dir zitierten Aussage?

An der hoffentlich gar nichts.
Unsinn ist in den meisten Fällen, nur einen Teil der bekannten Einschränkungen in der WHERE-Klausel anzugeben und den Rest dann im ABAP-Programm per CHECK ... zu prüfen.
Und genau so habe ich

es steht NUR das Feld NORMT in der WHERE-Bedingung, das ist auch explizit so gewollt

verstanden.

Früher war es mal nötig, den Optimizer auszutricksen, als Oracle in Kombination mit SAP R/3 noch so konfiguriert war, dass statt des Cost Based Optimizers der Rule Based Optimizer verwendet wurde.

Irgendwie ist Dein Quoting durcheinandergeraten.
Das war meine Aussage, trifft aber ziemlich sicher kaum für Dein Problem zu. Oder was wolltest Du mir damit sagen?

Frank Dittrich hat geschrieben:Wie sieht das SELECT-Statement genau aus?
Wie ist der Index genau definiert, wie viele Einträge hat die MARA? Wie viele verschiedene Werte für NORMT (bzw. für die Kombination von Feldern des Sekundärindex) gibt es in der MARA?
Wann wurde die Statistik zuletzt aktualisiert?
Was sagt Oracle bezüglich Selektivität des Sekundärindex?

Weia, du kannst Fragen stellen. Ich muss wohl mal die Datenbankexperten an das Thema schmeißen...

Wie viele verschiedene Werte für NORMT es ungefähr gibt, wirst Du ja hoffentlich wissen, wenn Du einen Sekundärindex anlegst.
Ebenso, wie der Sekundärindex denn nun definiert ist.
Wie viele Einträge die Tabelle hat, sollte auch leicht zu ermitteln sein.
Den Rest der nötigen Informationen findet man über die ST05.

Frank Dittrich hat geschrieben:Wenn der Matchcode-Zugriff im Gegensatz zu Deinem Programm effizient ist, musst Du noch irgendetwas falsch machen.

Nein, das Programm ist ineffizient, nicht der Matchcode-Zugriff.

Genau das habe ich doch gesagt.

Folgefrage: Ist es richtig, dass ich KEINE besonderen Vorkehrungen im Programm treffen muss um einen bestimmten Index zu wählen, sondern dass automatisch anhand der zu selektierenden Daten der Index automatisch ausgewählt wird?

Normalerweise findet der DB-Oprtimizer den günstigsten Zugriffspfad (Voraussetzung: DB-Statistik halbwegs aktuell ...).

Per %_HINTS der DB etwas anderes vorschreiben zu wollen bringt oft nicht viel.
Es ist nicht so leicht, smarter als der DB-Optimizer zu sein.
Und spätestens wenn in dem SELECT SELECT-OPTIONS vorkommen, die der User füllt, hat man sowieso kaum noch eine Chance, den besten Zugriffspfad zu erraten.

Frank