SQLRPGLE - Optimierung

[Fuerchau]

Das Problem ist, dass jeder LIKE keinen Zugriffspfad verwenden kann sondern einen Tablescan erfordert.
Optimierungen kann man nur bei Zugriffswegen erreichen, wenn Operatoren wie =, >=, between verwendet werden.
Das selbe gilt auch bei "where coalesce".

Auch UPPER kann keinen Zugriffspfad verwenden. Ggf. kann man mittels SRTSEQ auf einer LF sprachunabhängig arbeiten.

Vielleicht hilft hier auch dynamisches SQL per Prepare um den SQL zu verkürzen, wenn nicht alle Begriffe verwendet werden müssen.

Ist wirklich LEFT JOIN erforderlich ?
Wenn nein, kannst du dir coalesce schon mal sparen.

Auch ein CommonTableExpression kann helfen:

with
xArt as (
select ... from ARTIKELMERKMAL
where ...)

select ...
inner join xART on ...

Aber wie gesagt, die Hauptprobleme sind UPPER und LIKE.

[cicero22]

Schonmal besten Dank Ihr Beiden!

Ja - der Left outer Join ist erfoderlich - denn wir wollen die Artikel auch finden wenn sie im Artikelstamm sind aber kein Lagerbestand hierfür da ist. (gleiches gilt auch für die Artikelmerkmaldatei!)

Was uns so "schwer" fällt - ohne dieses "recht große" Artikelmerkmaldatei geht die Suche super super flott (500 ms) - erst wenn die Verknüfung auf die Artikelmerkmaldatei erfolgt fällt die Suche auf ca. 4-5 Sekunden ab! (pro Artikel können bis zu 20-30 Merkmale vorhanden sein)

Noch eine Idee - könnte es vielleicht noch etwas bringen wenn wir diese Artikelmerkmale pro Artikel alle in "einen Satz (ein Feld)" bringen (so das wir eben maximal dort soviel Sätze haben wir im Artikelstamm?)

[KM]

Ich weiß nicht, ob das für Dich eine Option ist, aber falls bei Euch ein wenig Java Skills vorhanden sind, dann schau Dir mal die Suchmaschine LUCENE an. Damit habe ich die Suche für unseren Web-Shop programmiert. Ist zwar ein wenig aufwendiger als "nur" ein RPG-Programm zu schreiben. Dafür hat man aber sämtliche Vorteile dieser sehr guten Suchmaschine. Du kannst dann z.B. im Suchbegriff komplexe Konstrukte angeben, wie z.B.

(FeldA = "X" AND FeldB = "Y") OR FeldC = "Z"

Die Antwortzeiten sind enorm schnell.

Gruß,
KM

[B.Hauser]

Nur um sicherzugehen, dass es daran nicht liegen kann:
Existiert ein Index oder eine geschlüsselte logische Datei über die Artikelmerkmalsdatei mit F2 asl 1. Key-Feld?

Wenn nicht auf alle Fälle anlegen. Dadruch müsste ein Table Scan oder eine Table Probe verhindert werden und ein Index verwendet werden. (Eine weitere Möglichkeit wäre statt eines normalen Indices einen Encoded Vector Index anzulegen, je nach extrahierter Datenmenge kommt dieser dann zum Zug, wenn ein normaler Index nicht mehr greift.)

Solltet Ihr bereits auf Release 6.1 sein, kannst Du auch einen Index (Binary Radix oder EVI) über F2 und UPPER(Artikelmerkmal) bilden, wodurch m.E. zumindest der Konvertierungsaufwand reduziert werden sollte.


Birgitta

[cicero22]

Nur um sicherzugehen, dass es daran nicht liegen kann:
Existiert ein Index oder eine geschlüsselte logische Datei über die Artikelmerkmalsdatei mit F2 asl 1. Key-Feld?

Wenn nicht auf alle Fälle anlegen. Dadruch müsste ein Table Scan oder eine Table Probe verhindert werden und ein Index verwendet werden. (Eine weitere Möglichkeit wäre statt eines normalen Indices einen Encoded Vector Index anzulegen, je nach extrahierter Datenmenge kommt dieser dann zum Zug, wenn ein normaler Index nicht mehr greift.)

Solltet Ihr bereits auf Release 6.1 sein, kannst Du auch einen Index (Binary Radix oder EVI) über F2 und UPPER(Artikelmerkmal) bilden, wodurch m.E. zumindest der Konvertierungsaufwand reduziert werden sollte.


Birgitta

Hallo Brigitta -

ja - diesen Index auf F2 haben wir angelegt.
Oh - das mit dem EVI oder Binary Radix (und gleich dem UPPER(ARTIKELMERKMAL) ) - das hört sich gut an - wir haben V6R1 - wie lege ich den an? Im grünen Bildschirm mit CREATE INDEX finde ich das nicht....


Übrigens - nach einem ersten Test dieses ganzen Artikelmerkmale in jeweils einen Satz pro Artikel zu bringen machen wir gerade super super Fortschritte! Das könnte eine "Zwischenoptimierungslösung" für uns sein!

[Fuerchau]

Manchmal sind die Anzahl Datensätze eben entscheidender als die Anzahl Felder.
Dynamischer SQL ist insbesonders dann hilfreich, wenn eben nicht alle Suchfelder gefüllt sind.
Dies ist gerade bei LIKE-Suchen entscheidend.

[BenderD]

... nur damit ihr euch keine unnötige Arbeit macht:
- sobald in der Where Klausel in einem Vergleich ein UPPER(Feld) oder ähnliches auftaucht (selbst abweichende CCSID reicht), hilft ein Index nichts mehr.
- sobald in einem Suchmuster eines like Vergleiches eine Wildcard auftaucht, steigt jeder Index aus; steht die Wildcard am Anfang hilft er nix.
- EVI könnte nur vorteilhaft (habe ich in Praxis noch nie - in Worten: nie - gesehen) sein, wenn hinter den 2,5 Millionen Sätzen in der Artikelmerkmaldatei viele Artikel mit wenigen verschiedenen Merkmalen stehen, dann kann man das Ganze auch Datenbanktechnisch lösen (falls die Datenbank EVI immer noch nicht richtig kann), mit einer Merkmaledatei, die hat dann wenige Sätze und in der Artikelmerkmaldatei stehen dann die Verknüpfungen zwischen Merkmal und Artikel.
Die Abfrage kann dann als select from Artikel where ...
and Merkmal in (select ... from MerkmalDatei where merkmal like '%text%') und der innere Subselect verliert seinen Schrecken, weil er nur noch auf Merkmale geht.
BTW: letzteres kann noch ein Versuch sein, sprich einen Index nur über die Merkmale anlegen und dann den like Vergleich in einen Subselect zu schieben.

D*B

Hallo Brigitta -

ja - diesen Index auf F2 haben wir angelegt.
Oh - das mit dem EVI oder Binary Radix (und gleich dem UPPER(ARTIKELMERKMAL) ) - das hört sich gut an - wir haben V6R1 - wie lege ich den an? Im grünen Bildschirm mit CREATE INDEX finde ich das nicht....


Übrigens - nach einem ersten Test dieses ganzen Artikelmerkmale in jeweils einen Satz pro Artikel zu bringen machen wir gerade super super Fortschritte! Das könnte eine "Zwischenoptimierungslösung" für uns sein!