View Full Version : Herausfinden, ob ein Datensatz gesperrt ist und welcher User den Satz sperrt
Wenn ich Birgitta richtig verstehe, kann es bei Verwendung von Commit Control und physischen Sperrungen zu nicht auflösbaren Deadlocks kommen?
... auch Deadlocks sind bei richtiger Vorgehensweise vermeidbar: Transaktionen müssen ihre Ressourcen in festgelegter Reihenfolge holen (siehe auch dining philosophers problem).
D*B
dschroeder
24-09-14, 17:15
Uns wurde vor gefühlten 100 Jahren schon beigebracht:
Wenn Zugriffe auf die Daten außerhalb der WaWi (heute ERP) nötig sind ist die WaWi mist!
Das können wir zwar nicht immer einhalten, finde die Grundidee abr klasse!
Was sprich gegen ein "and XXXjobnr = 0" in allen SQL's?
Erstmal Danke für die Antwort.
Mir wäre es auch lieber, wenn wir nie von außen an die Datenbanken müssten. Leider lässt sich das nicht vermeiden.
Aber zu deinem "Was spricht gegen ein "and XXXjobnr = 0" in allen SQL's?" Da könnte ich genauso gut fragen: Warum baut ihr eine Sperrlogik selber, die die Datenbank doch schon mitbringt? Ihr wollt ja sperren. Sonst würdet ihr ja keine "weichen" oder "harten" Sperren implementieren. Wenn ihr also sperren wollt: Warum wollt ihr dann, dass eine gesetzte Sperre nicht wirkt? Was anderes ist es meiner Meinung ja nicht, wenn einem eine physische Sperre "zu hart" ist. Es kann aus meiner Sicht nur einen Grund geben: Ihr wollt die gesetzte Sperre im Notfall umgehen können. Bei einer "sauberen" Anwendung dürfte das ja nie passieren. Und in einem Notfall könnte ich einen Job (i.d.R eine interaktive Sitzung), der eine physiche Sperre hält, beenden. Dann ist die physische Sperre weg.
Dieter
Erstmal Danke für die Antwort.
Mir wäre es auch lieber, wenn wir nie von außen an die Datenbanken müssten. Leider lässt sich das nicht vermeiden.
Aber zu deinem "Was spricht gegen ein "and XXXjobnr = 0" in allen SQL's?" Da könnte ich genauso gut fragen: Warum baut ihr eine Sperrlogik selber, die die Datenbank doch schon mitbringt? Ihr wollt ja sperren. Sonst würdet ihr ja keine "weichen" oder "harten" Sperren implementieren. Wenn ihr also sperren wollt: Warum wollt ihr dann, dass eine gesetzte Sperre nicht wirkt? Was anderes ist es meiner Meinung ja nicht, wenn einem eine physische Sperre "zu hart" ist. Es kann aus meiner Sicht nur einen Grund geben: Ihr wollt die gesetzte Sperre im Notfall umgehen können. Bei einer "sauberen" Anwendung dürfte das ja nie passieren. Und in einem Notfall könnte ich einen Job (i.d.R eine interaktive Sitzung), der eine physiche Sperre hält, beenden. Dann ist die physische Sperre weg.
Dieter
Es gibt da eine einfache eiserne Regel: Eine Benutzertransaktion klammert immer eine Datenbanktransaktion! Sprich: wenn der Benutzer die Steuerung an das Programm zurückgibt, gibt dieses als erstes alle Satzsperren frei. Wenn ich denn nun länger dauernde Transaktionen habe, komme ich um logische Sperren nicht drumherum (das kann man sich gut an einem Flugreserverungssystem klar machen). Bei Lichte betrachtet gibt es von letzterer Sorte nicht viele Anwendungsfälle, meist steckt da krummes Anwendungsdesign dahinter (siehe Dein Beispiel mit dem Kundensatz!).
D*B
... wenn man natürlich den Empfehlungen mancher hier folgt und bei SQL mit commit level *NONE arbeitet, dann ist Hopfen und Malz verloren...
hmm, ich kann doch nix dafür... :)
Gruß
Ronald Malz
... aber hoffentlich dagegen!
D*B
... und bei Kraut und Rüben hätte dann wohl der Herr Rübenscheid protestiert ...
dschroeder
25-09-14, 08:01
Vielen Dank an euch alle!
Es hat sich ja eine interessante Diskussion entwickelt. Wir werden die gelieferten Erkenntnisse hier im Haus diskutieren und mal sehen, was wir da machen. Wir haben hier ein bestehendes, gewachsenes System, das wir natürlich nicht von Grund auf neu durchstylen können. Wir müssen deshalb Lösungen finden, die bei neuen Programmen und Programmerweiterungen besser sind als die alten Sperrverfahren. Aber trotzdem müssen wir kompatibel bleiben.
Nochmals vielen Dank.
Dieter
Genau diese Kompatibilität ist ja ein Problem.
Arbeitet die alte Anwendung ohne Journalisierung kann man sie nicht oder nur unter größten Schwierigkeiten darauf umstellen.
Dies habe ich auch schon festgestellt.
Das betrifft dann ebenso die Sperrverfahren solange man ja an die alten Dateien auch dranmuss (was ja schon vorkommen soll;)).
Für neue Dateien und losgelöste Erweiterungen sollte man durchaus auf Journale und Commit zurückgreifen um es eben besser zu machen, wobei gerade das "Besser" sehr unterschiedliche betrachtet wird.
Spätestens wenn man alt und neu mischen muss fangen die Probleme erst richtig an.
Hier muss man sich dann Konstrukte über getrennte ACTGRP's einfallen lassen damit es funktioniert.
Bei ODBC/JDBC geht das wieder nicht innerhalb einer Verbindung (SQL kann erst mal nur 1 ACTGRP), hier benötigt man dann 2 Verbindungen und Framework-Methoden (Offline Resultsets) sowie Connection-Pools bleiben dann erst mal außen vor.
Wir haben vor ein paar Jahren mal ein paar wenige Dateien einer Anwendung journalisiert ohne Commit zu aktivieren. Das Ergebnis war 10GB / Stunde an Journalen neben ein paar Performanceeinbußen!
Wir haben vor ein paar Jahren mal ein paar wenige Dateien einer Anwendung journalisiert ohne Commit zu aktivieren. Das Ergebnis war 10GB / Stunde an Journalen neben ein paar Performanceeinbußen!
Das müssen aber dann Dateien mit riesigem Transaktionsvolumen gewesen sein und die Platten extrem langsam. Ich habe vor circa 20 Jahren angefangen nach Möglichkeit alle Dateien zu journalisieren (wg. Nachvollziehbarkeit und effektiver Fehleranalyse). Die Performance Auswirkungen waren stets kaum messbar und in der Tendenz wurde es eher minimal schneller (Die Datenbank schreibt die sequentiellen Journale forciert und die Dateien, wenn es ihr langweilig ist). Solche Horrorstories machen immer wieder die Runde, sind aber in den meisten Fällen nicht verifizierbar.
Ich kann nur empfehlen das auszuprobieren und zu messen. Journalisierung hat man in einer Stunde eingerichtet und in 10 Minuten deaktiviert - und an den laufenden Anwendungen ist kein Änderungsbedarf, die merken das nicht einmal!
D*B
dschroeder
25-09-14, 08:49
Es freut mich, dass ich mit meinen "Alltagsproblemen" nicht ganz allein dastehe. Eine theoretisch perfekte Lösung geht meist nur, wenn man auf einer grünen Wiese neu beginnen kann.
Vielen Dank.:p
Nun ja, die ERP-Anwendung arbeitet aus Sicherheitsgründen (da ja kein Journal läuft) auf jeder Datei mit FRCRATIO(1)!
Bei einigen Batchprogrammen konnte ich Laufzeiten von mehreren Stunden auf wenige Minuten reduzieren in dem ich einfach auf FRCRATIO(*NONE) gestellt hatte.
Bei RAID-Platten macht FRCRATIO(1) auch wenig Sinn.
Die Filehandler arbeiten beim "Lesen ohne Lock" mit CHAIN/UPDATE anstelle mit CHAIN(N), also ob die Programmierer damals (ca. 15 Jahre) das CHAIN(N) nicht kannten.
Batch-Programme, die wenig ändern lesen die Dateien mittels Filehandler mit CHAIN->UPDATE USER/JOBNAME->CHAIN löschen USER/JOBNAME um eben eine logische Sperre zu setzen um vielleicht eine Änderung durchzuführen. Dies führt natürlich zu hohem Journalaufkommen obwohl keine relevanten Daten geändert werden. Auf diese Weise werden komplette Stammdaten zum Teil mehrfach am Tag "geändert" ohne tatsächliche Änderungen durchzuführen.
Diese ERP-Anwendung ist nicht zu modernisieren (Never Change ...) und führt eben zu diesen gigantischen Journalen.
Auch das Datenbankmodell ist natürlich nicht optimiert. So enthalten Stammdatentabellen auch Bewegungsdaten (z.B. Lagerbestand). Hier muss natürlich intensiv über Sperren nachgedacht werden da sich Bestände am häufigsten ändern.
Wie gesagt, alte Anwendung die aber stabil läuft.