-
 Zitat von Robi
Nachtrag:
der fetch im Rpg, aufgelöst als call sql...
braucht sowohl beim fetch first als auch beim den weiteren fetch next endlos lange
daher vermute ich, das auch ein optimize for 1 row nix hilft
... hast Du da eine stored procedure mit Resultset gemacht? Schmeiß den Penner raus, das führt, ähnlich wie UDTFs zu einem optimize for all rows, der einen Hang zum full table scan hat - je mehr Tabellen gejoined werden, umso mehr tendiert das (fatalerweise) zum full table scan.
Wenn Du sicher bist, dass das resultiernde ResultSet klein ist, kannst Du auch versuchen in der stored procedure die hohen Selektivitäten vorzuziehen und temp tables zu verjoinen.
D*B
Similar Threads
-
By malzusrex in forum NEWSboard Programmierung
Antworten: 5
Letzter Beitrag: 09-06-16, 12:36
-
By KingofKning in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 28-06-15, 01:32
-
By Toschie in forum IBM i Hauptforum
Antworten: 12
Letzter Beitrag: 02-02-15, 15:28
-
By Bernstein in forum NEWSboard Server Job
Antworten: 0
Letzter Beitrag: 05-08-14, 18:34
-
By Günther in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 20-03-03, 14:51
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