Omnifind, Anzahl der Indexspalten

[Rainer Ross]

Hallo Forum,

zum Thema Performance der Indexerstellung habe ich einige Tests durchgeführt, damit ich handfestes Zahlenmaterial liefern kann.

HW 720 7+ 2 Cores, SW 7.2 OmniFind 1.3

Für die Parallelisierung der Indexerstellung und der SQL-Aufrufe auf die Prozessorcores ist SMP sinnvoll: 5770SS1 Option 26. Es kann für die komplette Maschine im Systemwert QQRYDEGREE oder pro Job aktiviert werden. Bei mir ist im Systemwert QQRYDEGREE *MAX eingestellt.

SMP ist bei Systemen ab 2 Cores nützlich. Eine ausführliche Beschreibung findet sich hier:

http://www.ibm.com/developerworks/da...1milligan.html

Einige von uns wissen, dass es in-Memory auf IBM i oder AS/400 schon seit über 15 Jahren gibt und zwar über den Befehl SETOBJACC. Damit können komplette Dateien oder Programme in einen Speicherpool gelegt werden. Für die Performanceoptimierung der Datenbankzugriffe habe ich je nach Anwendung zwei Wege gefunden.

- inMemory für RPG-Programme mit native Zugriff über chain/setll/read -> SETOBJACC

- inMemory für RPG-Programme mit embedded SQL -> ab 7.1 keepinmem *yes + SMP ab 2 Cores

An dieser Stelle bin ich für weitere Ideen sehr aufgeschlossen.


Doch nun weiter mit OmniFind. Zunächst habe ich eine einfache Datei mit zwei Feldern erstellt.

 create table tsto.employp                             
       (empid   int,                                   
        skill   char(100),                          
        primary key(empid))                            
        keep in memory yes;                            
                                                       
 Label on Table  employp  is  'Datei Employee'; 

- Dann schreibe ich per beigefügtem Programm Daten hinein.

- Als nächstes erstelle ich mit dem Script den OmniFind Index. Das Script erzeugt unter anderem eine logische Datei mit Indexinformationen und drei Trigger für Einfügen, Ändern und Löschen.

 call sysproc.systs_create('tsto','employ01','tsto.employp(skill)', 
 'ccsid 1208 language en_US update frequency none update minimum 1  
  index configuration(ignoreemptydocs 1 , updateautocommit 0 )'); 

- Jetzt ist der Index noch ohne Daten. Mit folgendem Script wird der Index aufgebaut. Das könnte man bereits im vorhergehenden Script tun, aber hier habe ich mich entschieden, das Aktualisierungsintervall selbst zu bestimmen. Das Script kann auch einfach mit RUNSQLSTM im Dialog oder Batch aufgerufen werden. Es muss nur laufen, wenn im Textfeld, das für den Index herangezogen wird, Änderungen vorgenommen oder Sätze hinzugefügt oder gelöscht werden.

call sysproc.systs_update('tsto','employ01','using update minimum'); 

Beim Aufbau des Index komme ich zu folgenden Messergebnissen

100.000 Sätze 46 Sekunden
1.000.000 Sätze 8 Minuten

@Dieter - bei Problemen mit OmniFind hilft Dir das developerWork Forum gerne weiter. Ich hatte zwei Fragen gepostet, die mir innerhalb kurzer Zeit beantwortet wurden.

https://www.ibm.com/developerworks/c...&tags=omnifind

Herzliche Grüße
Rainer Ross
www.myhofi.com
Hotels finden - leicht gemacht

[dschroeder]

Hallo Rainer,
herzlichen Dank für deine Mühe!

Ich habe das ganze mal mit deiner Datei und deinen programmatisch erzeugten Daten probiert. (Allerdings ging keep in mem by mir nicht).
Ich komme etwa auf die gleichen Zeiten wie du. Ich muss jetzt mal sehen, wo die Unterschiede zwischen deinem und meinem Index sind. Meine Datei war z.B. nicht jounalisiert. Das scheint ein Problem zu sein.
Deine Tipps haben mir bereits sehr viel weitergeholfen. Anscheinend ist es kein grundsätzliches Problem unserer Omnifind-Installation.

Ich teste weiter.
Dieter

[andreaspr@aon.at]

Allerdings ging keep in mem by mir nicht

... ist eine Neuerung bei 7.2.

[Rainer Ross]

Hallo Dieter,

gern geschehen.

- die Angabe beim create table mit "keep in memory yes" ist ab 7.2 verfügbar. Man kann es auch beim CHGPF/CHGLF angeben

Siehe Seite 52 im PDF zu DB/2 7.2:
https://www-304.ibm.com/partnerworld/wps/servlet/download/DownloadServlet?id=suPLVXUxU$diPCA$cnt&attachmentName=ibm-db2-for-i-7-2-overview.pdf&token=MTQxMzgwNTg0Mzk3Mg==&locale=en_ALL_ZZ

- meine Datei ist ebenfalls nicht journalisiert, da es sich nur nur um einen Test handelt.

Viel Spaß beim Testen

Rainer

[Fuerchau]

Ich frage mich, wofür KEEPINMEM (ab V7R1) denn nun wieder gut sein soll.
Damit wird das normale Paging der AS/400 doch vollkommen unterlaufen.
Per SETOBJACC konnte ich hier auch schon entsprechend steuernd eingreifen, was aber insgesamt überhaupt nichts gebraucht hat.
Für den Moment wo ein Zugriff erfolgt werden dann jede Menge andere Seiten aus dem Pool verdrängt um eben für dieses Objekt Platz zu schaffen.
Während SETOBJACC für alle Zugriffsarten gilt, wird (laut Doku) KEEPINMEM nur von der SQE verwendet. Native-IO scheidet da also aus.
Mittels MEMORY_POOL_PREFERENCE kann ich zwar einen eigenen Pool angeben, garantiert ist dieser nicht und die SQE kann sich (laut Doku) auch anders entscheiden.
Wie lange werden die Seiten dann im Speicher vorgehalten?
Werden sie durch normales Paging wieder verdrängt?

Ich habe gelernt, dass die Seiten, die am häufigsten verwendet werden am seltensten verdrängt werden.
Wird also auf bestimmte Dateien (oder auch Programme) sehr häufig zugegriffen sind diese sowieso eher speicherresident.