SQLRPGLE - Optimierung

[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!