SQL-Performance gibt es eine Alternative ?

[fabax]

Hallo Forum
vielleicht hat einer von euch eine Alternative für mich.

Ich "darf" auf einer 520 ein neues ERP Testsystem aufbauen (Basis sind Livedaten), dabei muss ich in ca. 390 Mio Datenrecords die Firmennummer abändern. Bei durchschnittlich 14ooRec/sec mit embedded SQL geht mir da natürlich voraussichtlich das Wochende aus .
Die Maschine dümpelt zwar nur mit 27% Prozent in der Gegend rum, aber über diese 1400 Rec komm ich nun mal nicht drüber. ( um die Frage gleich zu beantworten, nein kein paral...SQL Feature! ).

Was passiert..
Die Routine ermittelt dynamisch Datei und Feldname und erzeugt einen angepassten SQL Updatebefehl der dann submitted wird. Die größte Datei (52 Mio) benötigte dann fasst 19 Stunden.
Das Verteilen auf paralelle Jobs half natürlich auch nicht. ( ganz einfach -> 1400/sec durch Anzahl der Jobs ).

Mein Plan ist nun, diese Langläufer durch ein RPG Programm mit READ-UPDAT zu ändern, was (hoffentlich) deutlich schneller sein sollte. Das Problem ist aber das fixe Satzformat in RPG.

Idee 1 (RPG): Neue Programmhülle..
a) Dateiname, Satzformat und Feldname ermitteln.
b) mit diesen Werten eine nue freeRPG Source automatisch anpassen.
c) Das Programm automatisch compilieren lassen.
d) neues Program submitten...
e) und weiter mit a)---

/free
read $FILE$;
dow not %EOF();
$FELD$ = $WERT$;
update $FORMAT$;
read $FILE$;
enddo;
*INLR = *on;
/end-free

Idee 2 : (immer noch RPG ) Wer kennt noch WRKDBF? Ich hab mich schon immer gefragt wie die das realisiert haben. Denn offensichtlich exitieren kein SQLRPG... Programme in dessen Bibliothek. Also gibt es vielleicht einige passende API's von IBM ?

Idee 3 : Wenn ich diese Dateien mit dem AS400 C oder C++ Compiler angreife, habe ich da vielleicht eine Möglichkeit die festen Formate zu umgehen?

Idde 4 : Java habe ich erst gar nicht in Erwägung gezogen. Da benütze ich JTOpen und das ist ja wieder SQL ?

Gibt es noch eine andere Möglichkeiten ?

Der Ideentopf ist eröffnet.
Lösungen und Vorschläge sind herzlich willkommen

[B.Hauser]

Egal wie Du vorgehst ...
... Du solltest vor dem Update alle Zugriffswege (logische Dateien und SQL Indices) löschen und erst nach dem Update wieder aufbauen.
... Vor dem Update (nach dem Löschen der Zugriffswege) sollten die physischen Dateien reorganisiert werden, damit gelöschte Sätze physisch entfernt werden.

1400 Sätze/Sec erscheint mir auch bei einer schwachen Maschine ein bisschen wenig.

Birgitta

[fabax]

Danke Brigitta,

ja das dachte ich auch, selbst das verlagern in verschieden HSP Pools hat da nicht wirklich geholfen.

erstmals Danke für deine schnelle Antwort..

Das würde für mich bedeuten ca. 3000 logische Files automatisiert zu löschen und dann wieder automatisch aufzubauen.

Diese Hiobsbotschaft muss ich erst noch verdauen

[B.Hauser]

Das würde für mich bedeuten ca. 3000 logische Files automatisiert zu löschen und dann wieder automatisch aufzubauen.

Das dürfte mit DSPDBR (Display Database Relations) und Ausgabe in eine Datei oder besser mit API QDBLDBR (List Database Relations) kein Problem sein.

Vielleicht könnte man in diesem Zug gleich nicht benötigte logische Dateien entsorgen. Ich weiß jetzt nicht von wievielen physischen Dateien Du redest, aber 3.000 logische sind schon heftig.

Birgitta

[fabax]

Hallo Brigitta,

Es handelt sich hier um eine RPG MOVEX Version insgesamt sind das 610 betroffene PF's mit durchschnittlich 4-8 LF's. Wobei die meisten Dateien mit Records < 1 Mio keine Rolle spielen, da würde ich alles beim Alten lassen. Hier ein Auszug aus meinem IFS Logfile.

1. 10:32:04 ...> info : Copy 413419 Records to file ODHEAD.UACONO
2. 10:38:27 ...> SQL: update MVXCDTACPY/ODHEAD set UACONO = 200 where UACONO = 100
   10:38:27 . : 10373329 von 384043936 in 6842 Sekunden kopiert=1516records /sec
   10:38:27 . : voraussichtliches Ende 2010-11-20-02.13.27.161000 10:38:27 ===> File : OINVOH 364 of 834 remaining
   10:38:27 ...> CHGPF FILE(MVXCDTACPY/OINVOH) SIZE(2480000 30000 10)
   10:38:27 ...> CPYF FROMFILE(MVXCDTACPY/OINVOH) TOFILE(MVXCDTACPY/OINVOH) MBROPT(*REPLACE) CRTFILE(*YES)
   10:38:27 ...> info : Copy 414113 Records to file OINVOH.UHCONO
   10:43:15 ...> SQL: update MVXCDTACPY/OINVOH set UHCONO = 200 where UHCONO = 100
   10:43:16 . : 10787442 von 384043936 in 7131 Sekunden kopiert=1512records /sec
   10:43:16 . : voraussichtliches Ende 2010-11-20-01.40.16.028000
3. 10:43:16 ===> File : OOHEAD 363 of 834 remaining
4. 10:43:16 ...> CHGPF FILE(MVXCDTACPY/OOHEAD) SIZE(1480000 30000 10)
5. 10:43:16 ...> CPYF FROMFILE(MVXCDTACPY/OOHEAD) TOFILE(MVXCDTACPY/OOHEAD) MBROPT(*REPLACE) CRTFILE(*YES)
   10:43:16 ...> info : Copy 429752 Records to file OOHEAD.OACONO

Probleme bereiten die Buchhaltungsdateien, das sind Dinos mit 50 - 30 - 20 Mio's. Für diese werde ich mir was einfallen lassen müssen. Probleme bereiten mir noch dynamisch erzeugte LF's da hab ich die (Quell)Sourcen nur temporär, der tatsächliche Aufbau steht dann in x ERP Tabellen.

[fabax]

Hallo Brigitta,

Es handelt sich hier um eine RPG MOVEX Version insgesamt sind das 610 betroffene PF's mit durchschnittlich 4-8 LF's. Wobei die meisten Dateien mit Records < 1 Mio keine Rolle spielen, da würde ich alles beim Alten lassen. Hier ein Auszug aus meinem IFS Logfile.

1. 10:32:04 ...> info : Copy 413419 Records to file ODHEAD.UACONO
2. 10:38:27 ...> SQL: update MVXCDTACPY/ODHEAD set UACONO = 200 where UACONO = 100
   10:38:27 . : 10373329 von 384043936 in 6842 Sekunden kopiert=1516records /sec
   10:38:27 . : voraussichtliches Ende 2010-11-20-02.13.27.161000 10:38:27 ===> File : OINVOH 364 of 834 remaining
   10:38:27 ...> CHGPF FILE(MVXCDTACPY/OINVOH) SIZE(2480000 30000 10)
   10:38:27 ...> CPYF FROMFILE(MVXCDTACPY/OINVOH) TOFILE(MVXCDTACPY/OINVOH) MBROPT(*REPLACE) CRTFILE(*YES)
   10:38:27 ...> info : Copy 414113 Records to file OINVOH.UHCONO
   10:43:15 ...> SQL: update MVXCDTACPY/OINVOH set UHCONO = 200 where UHCONO = 100
   10:43:16 . : 10787442 von 384043936 in 7131 Sekunden kopiert=1512records /sec
   10:43:16 . : voraussichtliches Ende 2010-11-20-01.40.16.028000
3. 10:43:16 ===> File : OOHEAD 363 of 834 remaining
4. 10:43:16 ...> CHGPF FILE(MVXCDTACPY/OOHEAD) SIZE(1480000 30000 10)
5. 10:43:16 ...> CPYF FROMFILE(MVXCDTACPY/OOHEAD) TOFILE(MVXCDTACPY/OOHEAD) MBROPT(*REPLACE) CRTFILE(*YES)
   10:43:16 ...> info : Copy 429752 Records to file OOHEAD.OACONO

Probleme bereiten die Buchhaltungsdateien, das sind Dinos mit 50 - 30 - 20 Mio's. Für diese werde ich mir was einfallen lassen müssen. Probleme bereiten mir noch dynamisch erzeugte LF's da hab ich die (Quell)Sourcen nur temporär, der tatsächliche Aufbau steht dann in x ERP Tabellen.

"bevor hier der Einwand kommt mit CPYF. Da Ziel und Quelle identisch sind wird diese Option nicht ausgeführt. Dann arbeitet nur der SQL-Update...für mich ist nur die Uhrzeit interessant"

[Fuerchau]

Es geht noch einfacher.
Man kann LF's deaktivieren in dem man per CHGLF die Maintenance auf "Zugriff" stellt, dann die PF's updated und anchliessend die Mainenance wieder auf Immed.

Desweiteren würde ich mal auf den PF's den FRCWRITE überprüfen, ggf. steht der nämlich auf 1! Das machen nämlich viele ERP's die nicht journalisieren.
Setze den mal auf *NONE während des Updates.

Ansonsten wird der SQL-Update mit Sicherheit die schnellste Variante sein.

Wenn du auf dem selben System kopierst, kannst du natürlich auch folgenden Befehl stricken:

insert into ZTable
select 'NewMandant', F1, F2, ..., 'Newmandant', ... Fx, Fy, ...
from QTable

Damit sparst du dir den nachträglichen Update.
Parallel dazu eben FRCWRITE und Maintenance der LF's abschalten.

[fabax]

Es geht noch einfacher.
Man kann LF's deaktivieren in dem man per CHGLF die Maintenance auf "Zugriff" stellt, dann die PF's updated und anchliessend die Mainenance wieder auf Immed.

Desweiteren würde ich mal auf den PF's den FRCWRITE überprüfen, ggf. steht der nämlich auf 1! Das machen nämlich viele ERP's die nicht journalisieren.
Setze den mal auf *NONE während des Updates.

Ansonsten wird der SQL-Update mit Sicherheit die schnellste Variante sein.

Wenn du auf dem selben System kopierst, kannst du natürlich auch folgenden Befehl stricken:

insert into ZTable
select 'NewMandant', F1, F2, ..., 'Newmandant', ... Fx, Fy, ...
from QTable

Damit sparst du dir den nachträglichen Update.
Parallel dazu eben FRCWRITE und Maintenance der LF's abschalten.

"das mitt CHGLF scheint mir ein guter Weg zu sein, den Parameter kannte ich noch nicht, allerdings welches Setting meinst du mit "Zugriff"

Zugriffspfadwartung (MAINT )
*SAME
*IMMED
*REBLD
*DLY

grüße Franz

[BenderD]

vorher maint(*delay) nachher maint(*immed) (parallelisiert)
Cache Battery macht Einträge beim IPL und check mal DSPLOG und DSPMSG QSYSOPR

D*B

"das mitt CHGLF scheint mir ein guter Weg zu sein, den Parameter kannte ich noch nicht, allerdings welches Setting meinst du mit "Zugriff"

Zugriffspfadwartung (MAINT )
*SAME
*IMMED
*REBLD
*DLY

grüße Franz

[andreaspr@aon.at]

Das würde für mich bedeuten ca. 3000 logische Files automatisiert zu löschen und dann wieder automatisch aufzubauen.

Diese Hiobsbotschaft muss ich erst noch verdauen

Hi,
das sollte eigentlich keine große Sache sein. Mit der Systemtabelle QSYS/QADBXREF kannst du dir eine Liste aller Logischen Files des Systems, Lib oder Tabelle ausgeben lassen.

[fabax]

Hallo Andreas,
das Ermitteln ist keine grosse Sache. Das Problem beginnt dann wenn ich die LF's wieder erstellen muss, denn wo ist die Quelle ? You Know
Franz

[BenderD]

... hört sich nach I/O als Bottleneck an, wie war denn die CPU Belastung bei der parallelen Variante. ?

Das mit den Indexen könnte auch was bringen, löschen würde ich die nicht, sondern mit CHGLF die maintenance abhängen und am Ende parallel wieder mit CHLF auf *IMMED stellen.

Bist du sicher, dass die Cache Batterie keinen Schuss hat?


D*B

Hallo Forum
Das Verteilen auf paralelle Jobs half natürlich auch nicht. ( ganz einfach -> 1400/sec durch Anzahl der Jobs ).

Gibt es noch eine andere Möglichkeiten ?

Der Ideentopf ist eröffnet.
Lösungen und Vorschläge sind herzlich willkommen