-
Das Standardverhalten ist "Beim Lesen werden (im Modus *CHG bzw. Read Committed)..."
Wer Serializable verwendet, merkt sowas i.d.R. schon bei der Entwicklung, da fast grundsätzlich keine parallelen Transaktionen mehr möglich wären.
Was das Feststellen des Users angeht, so ist das tatsächlich ein Problem, da alle ODBC-Jobs (QZDASOINIT) mit dem Namen QUSER verheiratet sind.
Erst SQL setzt den tatsächlichen User per API (QSYSETPH), was über einen Joblog-Eintrag festgehalten wird.
Nun müsste man also nach dem Laden der Sperrinformationen (anderer Thread) per SQL, aus jedem Sperrjob das Joblog auslesen und nach dieser Nachricht (die ich im Moment jetzt nicht parat habe) scannen, die den User benennt.
Aber Achtung: Da QZDA-Jobs von anderen Verbindungen wiederverwendet werden, muss man diesbezüglich den letzten Eintrag im Joblog suchen.
Wenn man aber von der Anwendung sich mit einem sog. "App-User" anmeldet, hat man diesbezüglich leider verloren.
@Dieter
Seit wann werden Locks im Journal aufgezeichnet?
Na gut, bei offenen Transaktionen fehlt noch der Commit-Eintrag, also ist von einer Sperre auszugehen.
-
Zitat von Fuerchau
Wenn man aber von der Anwendung sich mit einem sog. "App-User" anmeldet, hat man diesbezüglich leider verloren.
@Dieter
Seit wann werden Locks im Journal aufgezeichnet?
Na gut, bei offenen Transaktionen fehlt noch der Commit-Eintrag, also ist von einer Sperre auszugehen.
... AppUser und Connection Pool wäre eigentlich Standard, das Problem sieht für mich aber eher nach Java Anwendung in RPG Denke aus...
Wenn man den Zeitpunkt kennt, sieht man im Journal sehr schön, welche Transaktionen offen waren. Ein anderer Einstieg wäre, die Journaleinträge nach CommitCycle ID, begin und end Einträgen auszuwerten (Ausgabe in outfile und SQL) und die lang andauernden Transaktionen zu suchen.
D*B
-
Ich möchte mich erst mal bei allen für die Antworten bedanken!
Soweit ich das jetzt beurteilen kann, liegt es nicht an unserer ERP Anwendung, sondern an den vielen Schnittstellen. Es ist leider so, das es eine Menge an anderen Produkten bei uns gibt, ich sag nur BI, DWH, SER, ...., die alle Daten aus der ERP Anwendung bzw. von den Platten saugen. Dann gibt es noch User die mit SQL drauf zugreifen. Ich möchte jetzt nicht behaupten das die Leute immer wissen was sie tun, im Gegenteil. Wir werden wohl in den nächsten Tagen Schritte einleiten damit diese Fälle weniger werden. In manchen Fällen konnte ich auch schon im Log sehen wer eine Tabelle gesperrt hat.
Von daher noch mal vielen Dank an alle.
Gruß
Manfred
-
Also Tabellensperren bei reinen Lesevogängen (User-Abfragen, Query, BI, DWH) halte ich für ein Gerücht oder schwere konzeptionelle Fehler.
Bei Schnittstellen mit Updatefunktion dürften i.d.R. auch keine Sperrfunktionen über die Standardwartezeit hinaus auftreten.
Und normale User dürften gar keine Updates außerhalb der ERP-Anwendung durchführen.
Ich habe bei einem Kunden bestimmt schon an die 100 Schnittstellen über die letzten 20 Jahre geschrieben, wovon der größte Teil auch noch aktiv ist. Hier gibt es in keinster Weise irgendein Problem mit Tabellensperren.
Die auftretende Fälle, wie du sie nennst, würden mich da schon mal interessieren.
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