-
WRKOBJLCK
Hallo Gemeinde,
jetzt werden evtl. 95% der Leser lachen, aber ich kapier's nicht!
Von unserem ERP-System werden immer mehr Daten von anderen Anwendungen / Usern ueber SQL geladen. Bisher war das auch kein Problem, nun passiert es aber immer oefter, das manche Tabellen fuer andere Anwendungen (auch fuer das ERP System) geblockt sind. Das hatte gestern z.B. zur Folge das keine Ausdrucke mehr moeglich waren. Ich kann zwar feststellen, welche Tabelle betroffen ist, aber ich kann nicht mit Sicherheit sagen wer die Tabelle blockiert.
Wenn ich da mit WRKOBJLCK rangehe, dann sehe ich einen ganzen A.... von Anwendungen / Usern die auf die Tabelle zugreifen, aber wer ist fuer den Lock verantwortlich?
Daher dieser Beitrag mit der eigentlichen Frage:
Wie bzw. Wo erkennt man / ich, welcher User die Tabelle sperrt?
Zumal ich eigentlich dachte (falsch gedacht) das die Tabellen alle den Modus *SHRRD haben, diese gar nicht gelockt werden koennten.
Vielleicht ist ja jemand von euch so freundlich und erklaert mir das nach dem Motto WRKOBJLCK fuer Dummies! Dann versteh ich das evtl. :-)
Oder kann ich das auch per SQL rausfinden? und wenn ja wie? :-D
Vielen Dank
Gruss
Manfred
-
Guten Morgen.
Der Job der z. B. die Ausdrucke erstellt geht dann nicht in ein MSGW Status ?
Wenn doch dann sollte im Jobprotokoll des aktiven "Ausdruck" Jobs stehen welcher
Job hier das Problem verursacht.
Gruß,
Ralf
-
Hallo Ralf,
nein, der Job welcher die Ausdrucke bearbeitet, ist ein Java Job des ERP Systems, diesen sieht man in der TN5250 gar nicht. Wir haben ein Webinterface, dort sieht man den Job mit der Meldung das Tabelle xxxx einen READLOCK hat. Unser ganzes ERP-System läuft in Java :-(
Ich kann natürlich auch die Jobs killen, welche im ERP-System betroffen sind, aber damit bekomme ich die Ursache nicht raus. Ich möchte den User erwischen der für das / die Problem verantwortlich ist. Das sind eben die SQL Jobs.
-
Der WRKOBJLCK zeigt dir die Jobs/User die gerade auf das File zugreifen.
Das muss aber nicht heisen, das die auch einen Satz sperren.
Versuche es mal mit DSPRCDLCK
Gruß
Ronald
-
... da ist kein User für verantwortlich, sondern ein Programmierer, der sein Handwerk nicht versteht! Hat denn die Java Anwendung wenigstens einen Logging Mechanismus? Üblicherweise ist das dann konfigurierbar.
D*B
-
@ Ronald, danke werde ich versuchen sobald das Prob. wieder auftaucht, wird wohl nicht lange dauern :-(
@ BenderD, Solange niemand von aussen auf das ERP-System zugreift (SQL) hatte ich das Problem nicht, aber mit dem Programmierer gebe ich dir recht. Getreu nach dem Motto: Das Problem sitzt eine halben Meter vor dem Bildschirm :-)
-
Zitat von malzusrex
Der WRKOBJLCK zeigt dir die Jobs/User die gerade auf das File zugreifen.
Das muss aber nicht heisen, das die auch einen Satz sperren.
Versuche es mal mit DSPRCDLCK
Gruß
Ronald
... das liefert dann den Serverjob (QZDAxxx o.ä. je nach Treiber), der die Sperre hat, was meist nicht viel weiterhilft.
-
Da mit Java wohl auf die Datenbank nur mit SQL zugegriffen wird (ich glaube nicht dass hier per API ein RLA-Zugriff erfolgt), sollte sich die Sperre von Datensätzen eher in Grenzen halten.
Beim Lesen werden (im Modus *CHG bzw. Read Committed) keine Sperren gesetzt und gesperrte Daten trotzdem gelesen.
Table-Locks kann ich mir da nun überhaupt nicht vorstellen.
Es kann also nur sein, dass Transaktionen nicht vernünftig committed werden, somit offen bleiben und weitere Updates verhindern.
Mit der Grundaussage "Keine offene Transaktion über eine Userinteraktion hinaus", die man beherzigen sollte, dürfte das Problem überhaupt nicht auftreten.
Mit der Defaultsatzwartezeit von 60 Sekunden (je Lock!) gibt es auch kein Problem, da vernünftigerweise Transaktionen so lange gar nicht dauern dürften.
-
Zitat von Fuerchau
Es kann also nur sein, dass Transaktionen nicht vernünftig committed werden, somit offen bleiben und weitere Updates verhindern.
Und da komme ich wieder mit der Frage:
Wie kann ich herausfinden, Wer die Tabelle / Satz im Zugriff hält. :-)
-
Zitat von Fuerchau
Table-Locks kann ich mir da nun überhaupt nicht vorstellen.
...
Mit der Grundaussage "Keine offene Transaktion über eine Userinteraktion hinaus", die man beherzigen sollte, dürfte das Problem überhaupt nicht auftreten.
Mit der Defaultsatzwartezeit von 60 Sekunden (je Lock!) gibt es auch kein Problem, da vernünftigerweise Transaktionen so lange gar nicht dauern dürften.
... commit level serialized setzt table locks!
Fehler im Transaktionsverhalten (lang andauernde Sperren) sind geradezu ein Kennzeichen, an dem man erkennt, wenn sich RPG Programmierre an Java versuchen.
Mit dem Waitrecord lässt sich kaum was anfangen, da der falsch programmierte Zugriff nicht abgebrochen wird, sondern der, der es richtig macht!!!
D*B
-
Zitat von Mr-Ferret
Und da komme ich wieder mit der Frage:
Wie kann ich herausfinden, Wer die Tabelle / Satz im Zugriff hält. :-)
... falls eine schreibende Transaktion die Sperre hält, über das Journal.
-
Hallo Manfred,
zuerst sollte man herausfinden welchen commit status die Javajobs benutzen
Werden Tabellen gesperrt ? oder nur Sätze in den Tabellen ?
Nachzulesen ist das sehr schön im STRSQL und F13 Commit Steuerung
PHP-Code:
COMMIT-Steuerung - Hilfetext Die Art der COMMIT-Steuerung auswählen. Gültige Werte sind: ..............................
Gruß
Michael
Tags for this Thread
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