SQL-Performance gibt es eine Alternative ?

[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