View Full Version : SQL MassenUpdate und Sperre
Guten Tag,
Wir haben Trigger auf Dateien um, bei einer Änderung oder Neuanlage einige Daten des Satzes in eine asyncrone Verarbeitung zu übergeben.
Da wird, u.a., ein DWH befüllt. Das läuft seit Jahren stabil.
Das DWH gilt Konzernweit und die Daten werden in seperaten Tabellen zur Verfügung gestellt.
Eine Abbildung dessen via View wollten der damalige Dienstleister nicht.
Ab und zu gibt es aus dem DWH neue Anforderungen. Nachdem diese Programmiert sind, müssen die betroffenen Sätze einmalig an das DWH übergeben werden.
dazu machen wir ein
Update Basisdatei set ChgFld = 'X' where was_auch_immer.
Das bricht leider ab und zu ab, da einzelnde Sätze im Zugriff durch die Anwender sind.
Diese Sätze brauchen nicht gekennzeichnet werden, das der SB ja im Änderungsmodus ist und der Trigger dann dadurch auslöst.
gibt es soetwas wie
with ignore_Lock oder
set ignore_Lock = *yes
Danke
Dietlinde Beck
Nur, wenn Dateien im Journal aufgezeichet werden und die betroffenen Programme mit Commit arbeiten.
Mit dem Transaktionsmodell *CHG (Read committed) werden durch eine Transaktion gesperrte Daten automatisch überlesen, so dass der Update nicht erfolgt.
Allerdings fehlen dir dann diese ja im DWH.
Ohne Commit hast du leider keine Chance.
wie ist die " maximale Satzwartezeit (WAITRCD)" bei der Basisdatei eingestellt ? *NOMAX könnte helfen.
Ich habe das zwar noch nie verwendet, klingt für mich aber nach Lösung(möglichkeit):
Seit V7R4 gibt es einen SKIP LOCKED DATA Zusatz - siehe auch >> hier << (https://www.ibm.com/docs/en/i/7.4?topic=techniques-improve-concurrency)
Update Basisdatei set ChgFld = 'X' where was_auch_immer SKIP LOCKED DATA
@robertPic
das hat sehr gut funktioniert, danke
DiBe
Diese Sätze brauchen nicht gekennzeichnet werden, das der SB ja im Änderungsmodus ist und der Trigger dann dadurch auslöst.
Dietlinde Beck
... nicht jede Sperre löst später den Trigger aus.
D*B
Die Sperre nicht, aber das 'durchtikkern' des Satzes vom Anwender.
Wenn die den Satz zum Ändern anwählen, ändern sie (i.d.R) auch.
Fürs Ansehen gib es eine andere Option, die sperrt auch nicht.
Die Sperre nicht, aber das 'durchtikkern' des Satzes vom Anwender.
Wenn die den Satz zum Ändern anwählen, ändern sie (i.d.R) auch.
Fürs Ansehen gib es eine andere Option, die sperrt auch nicht.
... mit dem Prinzip Hoffnung kommt man in der DV nicht weit.
Nun, es war eigentlich schon immer so, dass Satzsperren nie erhalten bleiben, wenn eine Usereingabe erwartet wird. Dies führt auch gerne bei anderen Programmen dann zu Problemen.
Wenn man im Änderungsdienst verhindern will, dass jemand anderes dies parallel tun kann, nutzt man einen allgemeinen BelegLock-Service.
Dieser erstellt einen logischen Lock in einer Hilfsdatei, die dann immer geprüft wird bevor eine Belegbearbeitung startet. Wenn die Jobinformation mit gespeichert ist, kann man per API, jetzt auch via SQL, prüfen ob der Job noch lebt.
Die andere Methode ist eben:
- Satz ohne Sperre lesen und in einer Variablen merken.
- User führt die Aktion durch.
- Satz nun mit Sperre lesen und mit gespeicherten Infos vergleichen.
- Wenn gleich, weiterarbeiten, Updaten und committen.
- Wenn nicht, rollback und Hinweis, dass die Datengrundlage sich inzwischen geändert hat.
Sicherlich ist diese aufwändiger, aber erheblich stabiler und sicherer.
Diese Methode ist i.Ü. in der .Net-Welt bei der Verarbeitung von Datentabellen standard.
Nun, es war eigentlich schon immer so, dass Satzsperren nie erhalten bleiben, wenn eine Usereingabe erwartet wird. Dies führt auch gerne bei anderen Programmen dann zu Problemen.
Wenn man im Änderungsdienst verhindern will, dass jemand anderes dies parallel tun kann, nutzt man einen allgemeinen BelegLock-Service.
Dieser erstellt einen logischen Lock in einer Hilfsdatei, die dann immer geprüft wird bevor eine Belegbearbeitung startet. Wenn die Jobinformation mit gespeichert ist, kann man per API, jetzt auch via SQL, prüfen ob der Job noch lebt.
Die andere Methode ist eben:
- Satz ohne Sperre lesen und in einer Variablen merken.
- User führt die Aktion durch.
- Satz nun mit Sperre lesen und mit gespeicherten Infos vergleichen.
- Wenn gleich, weiterarbeiten, Updaten und committen.
- Wenn nicht, rollback und Hinweis, dass die Datengrundlage sich inzwischen geändert hat.
Sicherlich ist diese aufwändiger, aber erheblich stabiler und sicherer.
Diese Methode ist i.Ü. in der .Net-Welt bei der Verarbeitung von Datentabellen standard.
..gut gut Deine Argumente "Methode/Aufwendigkeit" sind stimmig. Die wenigsten wissen dass es unter auch OS400-native ein Produkt gibt das diese Sperrprobleamtik, primär durch interaktive Programme ausgelöst, automatisch handelt einhergehend mit entsprechenden Ursachenmeldungen. Ein einfaches JA/NEIN Flag macht's möglich.