-
Wir hatten einen Fachmann im Haus, der Performanceanalysen gemacht hat und einige Einstellungen gemacht hat. Wir machen sehr viele SQL Zugriffe. Nur ganz ganz wenige davon benutzen die klassische SQL Engine. Wir möchten das System einfach sauber haben und nur noch die SQE benutzen. Die Performance des Programms selber ist gar nicht das Problem. Das Problem ist, dass sehr oft ein (temporärer) Index erzeugt wird. Das möchten wir gerne beseitigen. Ich habe als erste Maßnahme schon mal die Optimierung für das OPNQRYF auf *FIRSTIO gestellt. Das hat schon etwas gebracht.
Zu deiner Anmerkung: Das Log sagt nicht, dass Zugriffspfade fehlen. Da wir eine Like-Abrage machen (suche alle Kunden, in deren Namensfelder "meier" vorkommt), kann das System wahrscheinlich keinen permanenten Pfad vorhalten.
Danke für den Hinweis.
Dieter
-
Für einen Like wird auch kein temporärer Pfad erstellt.
Ggf. sind ja noch weitere Felder im Where bzw. Order By, für die kein Index vorhanden ist.
Prüfe den Zugriff mal als SQL und schau dir dann die Diagnose bzgl. Indizes an, manchmal hilft das auch für die CQE.
-
Gute Idee. Ich versuche das mal.
Danke.
-
Hallo.
So wie ich das verstanden habe schreibt euer OPNQRYF das Ergebniss in eine PF Datei. Diese besitzt dann eine oder mehrere logische Files. Wenn dann der Parameter FRCRATIO für die physische Datei auf 1 stehen sollte wird dies quälend langsam von statten gehen, vor allem bei grossen Datenmengen.
Guck doch da mal nach ...
Gruß,
Ralf
-
Nein. Das Ergebnis des OPNQRYF wird direkt verarbeitet. Es wird keine physische Datei geschrieben. Das einzige Problem, das wir haben, ist, dass OPNQRYF anscheinend die CQE benutzt. Wir würden aber gerne alles einheitlich über die SQE laufen lassen.
Dieter
-
Wenn das Ergebnis des OPNQRYF nur sequentiell bearbeitet wird, hilft dir ggf. auch folgender Trick (mache ich im Moment bei einem Kunden mit V5R2 :
create table qtemp/xxmytable as (
select ...
where ...
order by ...) with data
ovrdbf myfile qtemp/xxmytable
Ggf. die Ergebnismenge mit "fetch first nn rows" einschränken, da der User im Zweifel sowieso nicht alles ansieht.
Alternativ kann man auch einen QM-Query mit Parametern schreiben und diesen dann per "STRQMQRY ... OUTPUT(*OUTFILE) ... " laufen lassen.
Ist die Tabellenstruktur dann identisch kann man im OVRDBF noch den LVLCHEK rausnehmen.
Ggf. reicht auch nur die Umwandlung des Programmes mit Bezug auf die neue Datei.
Möglichkeiten gibts da viele.
-
Nochmals danke für die Tipps.
Dieter
Similar Threads
-
By tarkusch in forum NEWSboard Programmierung
Antworten: 5
Letzter Beitrag: 09-11-13, 14:08
-
By Matthias.Hayn in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 15-07-02, 07:03
-
By Newbie in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 04-07-02, 08:19
-
By delphix in forum IBM i Hauptforum
Antworten: 8
Letzter Beitrag: 11-02-02, 09:37
-
By Kent in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 19-06-01, 10:45
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks