Schnelle Datenzwischenspeicherung im Trigger

[pwrdwnsys]

Hallo liebes Forum,

habe eine Frage zur Performance in Triggern. Muss einen READ-Trigger implementieren, der jeden gelesenen Datensatz auswertet (Kommt jetzt bitte nicht mit Datenschutz......)

Den Trigger habe ich in RPG realisiert, das funzt auch ohne gewaltige performanceeinbrüche. Das Problem: Die Daten muss ich ja irgendwie speichern. Und da bricht die Performance der darüber liegenden Anwendung natürlich ein. Es reicht, wenn ich Bibliothek/Datei und relative Satznummer irgendwo ablegen kann. Speichern in Dateien oder Journaleinträgen bedeutet die etwa 20...30 fache Verarbeitungszeit eines Lesezugriffes. Und das ist inakzeptzabel. Eine Idee wäre, die Daten in einem temporären Job-Objekt (DTAQ, USRSPC etc.) wegzuschreiben und durch einen parallelen Thread abzuarbeiten. Geht so etwas ? Und wenn ja wie ? Jemand Erfahrung mit einer performanten Datenzwischenspeicherung ?

Danke für Eure Tips
Karsten

[Fuerchau]

Nun ja, wenn ein Lese-Trigger auch noch schreiben muss, wird auch eine DTAQ nicht so wirklich viel helfen.
Da Daten sehr häufig auch unsinnig gelesen werden (Selektion per Programm und nicht per SQL) ergibt sich zwangsläufig ein hohes Datenaufkommen.

Auch ist die Auswertung ggf. an der Realität vorbei da eben auch Daten gelesen werden, die ggf. der User gar nicht sieht (eben programmintern).

Du kannst sicherlich die Daten in eine DTAQ schieben, wobei diese auf 16MB beschränkt ist. Wenn also das abnehmende Programm nicht schnell genug ausliest, läuft die DTAQ voll und der QSNDDTAQ bricht mit Fehler ab.

Dem kann man entgegenwirken, wenn genug abnehmende Programme die DTAQ auslesen.

Das zu erwartende Datenaufkommen kann gewaltig werden und dein System schnell über 90% bringen !!!

PS:
Das Schreiben in eine DTAQ kann ggf. langsamer sein als das Schreiben in eine Datei.
Der QSNDDTAQ muss nämlich die DTAQ immer erst mal suchen (vielleicht optimiert er das ja intern), wobei die Zieldatei ja bereits geöffnet ist.
Performancegewinn ergibt sich ggf. bei der PF mit FRCRATIO(*NONE).

[BenderD]

Hallo,

puffern heißt das Zauberwort, sprich immer n Aufrufe sammeln, dann im Block wegschreiben, der Finale Puffer wird dann per ILE Exit Handler (CEE4RAGE) geleert.

mfg

Dieter Bender

Hallo liebes Forum,

habe eine Frage zur Performance in Triggern. Muss einen READ-Trigger implementieren, der jeden gelesenen Datensatz auswertet (Kommt jetzt bitte nicht mit Datenschutz......)

Den Trigger habe ich in RPG realisiert, das funzt auch ohne gewaltige performanceeinbrüche. Das Problem: Die Daten muss ich ja irgendwie speichern. Und da bricht die Performance der darüber liegenden Anwendung natürlich ein. Es reicht, wenn ich Bibliothek/Datei und relative Satznummer irgendwo ablegen kann. Speichern in Dateien oder Journaleinträgen bedeutet die etwa 20...30 fache Verarbeitungszeit eines Lesezugriffes. Und das ist inakzeptzabel. Eine Idee wäre, die Daten in einem temporären Job-Objekt (DTAQ, USRSPC etc.) wegzuschreiben und durch einen parallelen Thread abzuarbeiten. Geht so etwas ? Und wenn ja wie ? Jemand Erfahrung mit einer performanten Datenzwischenspeicherung ?

Danke für Eure Tips
Karsten

[DVE]

@FUERCHAU zu *DTAQ

bei Rel 5.3 kann die *DTAQ 2 GB haben.
Außerdem gibt es den Parameter
Automatisches Zurückfordern (AUTORCL)

Auszug aus dem Hilfetext
"*YES
Der für die Datenwarteschlange zugeordnete Speicherbereich wird
freigegeben, wenn die Datenwarteschlange leer ist. Der
Speicherbereich für die anfängliche Anzahl an Einträgen bleibt
jedoch zugeordnet."

Gruß
DVE

[pwrdwnsys]

Hallo,

puffern heißt das Zauberwort, sprich immer n Aufrufe sammeln, dann im Block wegschreiben, der Finale Puffer wird dann per ILE Exit Handler (CEE4RAGE) geleert.

mfg

Dieter Bender

Na das isses doch... Manchmal sieht man den Wald vor lauter Bäumen nicht. Hätt ich eigentlich selbst drauf kommen müssen....

Danke für die Tips!

[Fuerchau]

Aber Achtung:
Wird ein Job abgebrochen, kann es vorkommen, dass dieser Puffer dann nicht mehr geleert wird, da die Exit-Routinen nicht mehr aufgerufen werden !!!

Im Normalbetrieb geht ja alles i.O.
Nicht umsonst haben einige ERP-Anwendungen ihre PF's mit FRCRATIO(1) definiert.
Damit wird jedwede interne Pufferung ausgeschaltet um ja keine Daten verloren gehen zu lassen.
Insbesonders bei RPG-O-Dateien wird somit das RPG-interne Blocken abgeschaltet, was ja sonst tatsächlich zu Datenverlusten führt.

[BenderD]

Hallo,

ein mit CEE4RAGE registrierter Exit wird auch bei Abbruch von der Runtime aufgerufen, deswegen macht man das ja.

mfg

Dieter Bender

Aber Achtung:
Wird ein Job abgebrochen, kann es vorkommen, dass dieser Puffer dann nicht mehr geleert wird, da die Exit-Routinen nicht mehr aufgerufen werden !!!

Im Normalbetrieb geht ja alles i.O.
Nicht umsonst haben einige ERP-Anwendungen ihre PF's mit FRCRATIO(1) definiert.
Damit wird jedwede interne Pufferung ausgeschaltet um ja keine Daten verloren gehen zu lassen.
Insbesonders bei RPG-O-Dateien wird somit das RPG-interne Blocken abgeschaltet, was ja sonst tatsächlich zu Datenverlusten führt.