-
Danke,
ich werde nun mal jemanden suchen, der mir das analysiert, warum das so extrem langsam ist.
(2. Pgm Version mit RLA dauert auch ewig,
Und das ist eigendlich ein sehr einfacher Code)
Danke Euch, ggf berichte ich!
Dietlinde Beck
-
Nur eine Idee: Habt ihr in eurer Tabelle vielleicht extrem viele gelöschte Sätze drinstehen? Dann müsste man mal ein RGZPFM machen. Wenn man sich das nicht "traut", weil man nicht weiß, wie lange es dauert,
könnte man die Tabelle vielleicht auch mal testweise erstmal umkopieren.
-
Zu obigem Hinweis:
Eine PF hat die Eigenschaft "ReuseDlt" um gelöschte Sätze mit neuen zu überschreiben.
Bei TABLE's, also SQL, ist der Default YES, bei PF's leider NO.
Wenn man die Eingangsfolge benötigt, sollte man dies über einen Timestamp oder neu, eine Identity-Column lösen, da der RGZPFM durch Angabe einer LF auch in Sortierfolge der LF umsortieren kann.
Bei deinen o.a. 40 Minuten für den Index schätze ich mal 12 Mio. aktive Sätze und mehrere 100 Mio. gelöschte Sätze.
Nach dem RGZPFM kann ein CHGPF ... REUSEDLT(*YES) nicht schaden.
-
Zitat von dibe
Danke,
ich werde nun mal jemanden suchen, der mir das analysiert, warum das so extrem langsam ist.
(2. Pgm Version mit RLA dauert auch ewig,
Und das ist eigendlich ein sehr einfacher Code)
Danke Euch, ggf berichte ich!
Dietlinde Beck
-- was habt ihr denn an Hardware, Release- und PTF-Stand?
-
Moin zusammen
ich habe mich da mal drauf geschaltet und mir das Thema mal angesehen.
@LF und 40 Minuten
Das LF hat zwar einen 'normalen' Namen, ist aber kein 'normales' LF
Es ist ein LF in dem 4 Dateien mit insgesamt > 234 Mio Sätzen zusammen gefasst sind.
Sein Name entspricht den Namensregeln einer einfachen LF, daher das Missverständnis.
Reuse ist i.d.R Verwendet, gelöscht wird (in der Anwendung) nie!
@Performance
Einer der SQL Zugriffe hat eine Schnittstellen Datei gelesen.
Der Schnittstellenpartner hat wohl Vorgaben gemacht, welche Art und welcher Länge die Felder haben sollen.
So haben 2 (Key) Felder die Definition 25A
Die zugriff Felder aus der Anwendung sind aber 7P 0 bzw 1S 0
In der Umwandlung sieht man, das die SQL generierten Felder dehnen aus der Anwendung entsprechen
(SQL_0156 7P0, SQL_0157 1S0)
Codiert war
insert into ... from ...where Feld_25A_1=:Feld_7P0 and Feld_25A_2 = :Feld1S0
Im Debug merkt man nicht, das das dauert (anders als z.b. ein clear auf eine grosse Feldgruppe)
Nach der Anpassung das auf 25A mit 25A zugegriffen war das Pgm um Faktor >200 schneller
Kunde zufrieden, wieder was gelernt ...
VG
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Da kann man mal sehen, wie wichtig bei SQL-Zugriffen die korrekte Typisierung ist.
Das hilft auch schon mal in einer Join, wenn die verbundenen Felder nicht genau passen.
Z.B.: "...on cast(fromField as ..) = ToField..."
Similar Threads
-
By wilfried in forum NEWSboard Programmierung
Antworten: 36
Letzter Beitrag: 25-08-18, 15:25
-
By FichtenElch in forum IBM i Hauptforum
Antworten: 13
Letzter Beitrag: 26-04-18, 11:50
-
By Robi in forum NEWSboard Programmierung
Antworten: 11
Letzter Beitrag: 10-11-16, 12:54
-
By JonnyRico in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 29-04-05, 10:49
-
By Kirsten Steer in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 15-04-04, 07:00
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