SQL + Datensatzsperre

[BenderD]

@Journalisierung: auch wieder so ein Mythos, habe ich bei keiner einzigen Kiste seit RISC Zeiten verifizieren können, nicht einmal bei meiner 150 oder 170 und auf keiner einzigen Kundenmaschine je ein Problem damit gefunden. Meine Erfahrung ist, dass man den Vorschlag Journalisierung mit entsprechendem Nachdruck versehen, meist durchbekommt.

@lesen/schreiben: ohne Commit Steuerung (und damit Journalisierung) gibt es den Mechanismus mit sicherem lesen/schreiben nur bei positioned updates - lesen mit Cursor und dann update .... where current of ... Ansonsten muss man mit Sperrfreien Verfahren operieren (Versionsnummer mit in die where clause aufnehmen, o.ä.)

Ansonsten ist die Konsequenz tatsächlich: keine Schreiboperationen mit SQL!!!

PS: da droht nicht nur das Handbuch, sondern auch Haftung (von wegen Stand der Technik und so...)

D*B

Bitte nicht erschlagen ...

Soweit ich weis geht commit/rollback nur bei Journalisierung.

Wustest du nicht, das das die Maschine sooooooooooo langsam macht ?
(Jedenfals bei meinen Kunden )

ok, kein Sql mehr
Danke
Robi

[Robi]

@Fuerchau,
Na das ist ja schon was.

Mein Problem ist halt, das ich in 7-8 Mio Datensätzen bestimmte Sätze kennzeichnen muß.
Irgend ein Satz war gesperrt und ab da wurde kein Satz mehr gekennzeichnet.
So hilft mit die Anzahl Sätze, die er gemacht hat, auch nicht.
(es sei denn ich zähl vorher, alles eine Frage der Zeit !)
Ist die Reihenfolge in der ein Update durchgeführt wird immer die des PF ? Oder ggf. die keyfolge des PF?

@Dieter
wenn dieser Job dann, z.B. weil der letzte Satz gesperrt war
alle updates zurück dreht ist mir auch nicht geholfen.

Robi

[Fuerchau]

Nun ja, das mit der nachträglichen Journalisierung in Alt-Anwendungen stellt sich m.U. nicht ganz so einfach dar.
Je nach ERP-Anwendung laufen mir die Platten innherhalb kürzester Zeit ziemlich voll.

Bei einer mir bekannten ERP-Anwendung werden z.B. Satzsperren über Flag-Felder (User/Jobname) geführt und damit wird sehr extensiv umgegangen.
Ein Programm macht da innerhalb kürzester Zeit mehrere 1000 Updates, die natürlich journalisiert werden.

Ausserdem hilft Journalisierung dann nicht wirklich, wenn man nicht alle betroffenen Programme unter Commit-Steuerung stellt und in ihrer Logik an dieses Verhalten anpasst.
Aber wer hat da schon Zeit für.

Für neue Programme arbeite ich inzwischen gerne mit SQL, ins besonders aus Performancegründen, da mir SQL bei komplizierteren Abfragen doch erheblich schnellere Ergebnisse liefert.
Die Programme (auch wenn ich dann erschlagen werde ;-)) bestehen aus einem Mix von SQL und RLA.

[Fuerchau]

Der Update wird wie auch der Select über die Where-Klausel zugriffsoptimiert.

Wenn du natürlich einen Update für mehrere Sätze durchführst, bricht der SQL bei der ersten Sperre ab.

Hier hilft ggf. tatsächlich ein vorheriger "select ... for update of" mit anschließendem "update ... where current of".
Das mag zwar etwas langsamer sein, aber wenn du beim FETCH die Satzsperre ggf. nicht erhalten kannst (SQLCODE < 0), kannst du mit einem FETCH RELATIVE den Satz überspringen und ggf. später wieder bearbeiten.

[Robi]

Das mit den 'Soft' sperren kenn ich auch so.
Update dann über schreib/lese Pgm, nur Felder die sich tatsächlich geändert haben. Kleiner Pgm-Generator der alle automatisiert (und ein wenig verlangsamt) und solche Porbleme treten nicht auf.
Ist hier aber nunmal anders.

Wenn ich das Pgm umstelle und selber 'Fetche' ist mir das vorgehen klar. Nur, von der lesbarkeit für andere, ist dan ein
Read / Update mit RPG besser.
Um den Sourccode klein zu halten (und für alle lesbar) habe ich halt o.a. Stmt verwendet.

Danke an alle
Robi

[BenderD]

... das kann man so nicht stehen lassen: Was das 'volllaufen' der Platten angeht, man kann die Größe der Receiver begrenzen und automatisch löschen lassen (wenn man wil, vorher auf Band ziehen lassen). Journalisierung erfordert keine Commit Steuerung (das gilt nur umgekehrt) und hat auch schon Wert an sich, man hat im Fehlerfall einfach mehr Informationen und zusätzlich kann man in "kritischen" Programmen Commit einsetzen und für Schreibzugriffe die Satzsperrmechanismen steuern - alles Maßnahmen, die mehr Zeit einsparen als kosten.
Bei der Kennzeichnung kann man natürlich das Kennzeichen mit in die Where clause nehmen und dann probieren, bis alle gekennzeichnet sind, aber Eleganz ist was anderes...

D*B

Nun ja, das mit der nachträglichen Journalisierung in Alt-Anwendungen stellt sich m.U. nicht ganz so einfach dar.
Je nach ERP-Anwendung laufen mir die Platten innherhalb kürzester Zeit ziemlich voll.

Bei einer mir bekannten ERP-Anwendung werden z.B. Satzsperren über Flag-Felder (User/Jobname) geführt und damit wird sehr extensiv umgegangen.
Ein Programm macht da innerhalb kürzester Zeit mehrere 1000 Updates, die natürlich journalisiert werden.

Ausserdem hilft Journalisierung dann nicht wirklich, wenn man nicht alle betroffenen Programme unter Commit-Steuerung stellt und in ihrer Logik an dieses Verhalten anpasst.
Aber wer hat da schon Zeit für.

Für neue Programme arbeite ich inzwischen gerne mit SQL, ins besonders aus Performancegründen, da mir SQL bei komplizierteren Abfragen doch erheblich schnellere Ergebnisse liefert.
Die Programme (auch wenn ich dann erschlagen werde ;-)) bestehen aus einem Mix von SQL und RLA.

[Fuerchau]

Wie gesagt, bei dieser ERP-Software ist der Einsatz von Journalen illusorisch da einfach die Kapazitäten nicht ausreichen. So viele Bänder, wie da pro Tag anfallen kann man gar nicht anschaffen und wer kann schon in Millionen Pseudoupdates (Flagfelder) genau den Verursacher der Fehler finden ins besonders wenn man Tage allein zum Zurückladen und durchsuchen der Journale benötigt.

Für Neuanwendungen bzw. Ergänzungen mit eigenen Tabellen (ohne Bezug zu bestehenden Daten) macht das durchaus Sinn.
Da aber leider doch immer Abhängigkeiten zur Anwendung bestehen lassen sich auch hier die neuen Tabellen nicht sinnvoll unter Commit stellen, da ja die alten Tabellen nicht journalisiert sind.

Aber ich glaube, hier unterscheiden sich halt die Meinungen gravierend.

[B.Hauser]

Wie gesagt, bei dieser ERP-Software ist der Einsatz von Journalen illusorisch da einfach die Kapazitäten nicht ausreichen. So viele Bänder, wie da pro Tag anfallen kann man gar nicht anschaffen und wer kann schon in Millionen Pseudoupdates (Flagfelder) genau den Verursacher der Fehler finden ins besonders wenn man Tage allein zum Zurückladen und durchsuchen der Journale benötigt.

Für Neuanwendungen bzw. Ergänzungen mit eigenen Tabellen (ohne Bezug zu bestehenden Daten) macht das durchaus Sinn.
Da aber leider doch immer Abhängigkeiten zur Anwendung bestehen lassen sich auch hier die neuen Tabellen nicht sinnvoll unter Commit stellen, da ja die alten Tabellen nicht journalisiert sind.

Aber ich glaube, hier unterscheiden sich halt die Meinungen gravierend.

Das würde ich so nicht unterschreiben!

Man kann jederzeit mit Journaling und Commitment Control auf JEDER Maschine anfangen.
Zu Beginn kann man durchaus mit "Schmalspur"-Journaling verwenden, d.h. alle Dateien werden aufgezeichnet, die JournalReceiver (relativ) klein gehalten und sofort nach dem Abhängen gelöscht (geht automatisch mit der entsprechenden Einstellung).

Da eine Transaktion nicht über mehrere Journal-Receiver verteilt wird, kann Commitment Control für neue Programme (und alte Dateien) eingesetzt werden, während die bestehenden Programme sich verhalten wie zuvor.

Auch wenn in diesem Statium ein Nachfahren nicht möglich ist, wird dennoch (zumindest bei den neuen Programmen) Transaktions-Sicherheit gewährleistet werden.

Später kann man dann das Ganze immernoch so ändern, dass die Receiver vor dem Löschen auf Band gezogen oder für Hochverfügbarkeit auf eine andere Maschine übertragen werden. Dann kann Journaling auch wirklich dazu verwendet werden im Falle eines Crashs entweder alles Nachzufahren oder auf die andere Maschine zu switchen.

Birgitta

[Fuerchau]

Bei einem Test mit Journalisierung auf eine einzige Stamm-Datei ergab sich ca. 1GB pro Stunde an Journal !
Bei einer Hochrechnung über mehrere 100 Dateien ergaben sich hier 30-50 GB je Stunde !
Hier müsste also die Journalgrenze bereits sehr niedrig angesetzt werden, eine Aufzeichnung auf Band geht schnell an Kapazitätsgrenzen.

Wenn nun ein neues Programm mit Transaktionssicherheit entwickelt wird und hier entsprechende Satzsperren durch Updates entstehen, kann es sein, dass der Rest der Anwendung Probleme bekommt, da diese grundsätzlich nicht mit Satzsperren rechnet und deshalb dort zu Fehlverhalten führt wenn eine Satzsperre auftritt (keine Bezugszahl für Satzsperre, Programmabruch mit CPF-Meldung).

Diese ERP-Anwendung rechnet an keiner Stelle mit einer Satzsperre, da diese, wie gesagt, über Flagfelder (mittels Filehandler-Programmen) bearbeitet werden.
Es gibt bestimmt noch andere Anwendungen die ein ähnliches konzeptionelles Verhalten verwenden.

Wie gesagt, wir haben es getestet und bezüglich dieser Anwendung für unmöglich befunden.

[Robi]

Stimme Dir 100 % zu!
Meine ERP Anwendung arbeitet auch so.
Und 2 andere, die ich kenne auch.
Gruß
Robi

[Fuerchau]

Achja, das Thema Hochverfügbarkeit wurde auch mal angetestet, aber auch hier scheiterte man am Datenvolumen, dass einfach nicht durchs Netz zu bekommen ist.

Man begnügt sich mit einer Ausfallsicherheit von 24 Stunden, d.h. die letzte Sicherung vom Vortag wird als Wiederherstellungspunkt akzeptiert.

Ein Systemausfall ist in den letzten 15 Jahren absolut nicht vorgekommen.

Und wenn der Betrieb mal brennt ...
na dann.

[BenderD]

@Volumen: na und???
@Grenze: die Grenze für die Receiver hat nix mit der aufzuzeichnenden Menge zu tun, sondern hängt nur vom verfügbaren Plattenplatz ab.
@Plattenplatz: ein ungesicherter ASP mit 4 Platten für die Receiver kostet fast nix, der Gewinn an Performance und Sicherheit ist immens.
@Record locks: bei korrektem Design der Neufunktionen (das ist kein Hexenwerk, da gibt es einfache Regeln!!!) gibt es von vornherein keine Probleme mit record locks, da diese immer (in Worten: immer) kürzer als der Record wait der Datei dauern.
@Birgitta: HA hat mit Journalisierung erst mal nix zu tun, da würde ich Hardware basierte Ansätze Software Placebos gegenüber immer den Vorzug geben.

D*B

Bei einem Test mit Journalisierung auf eine einzige Stamm-Datei ergab sich ca. 1GB pro Stunde an Journal !
Bei einer Hochrechnung über mehrere 100 Dateien ergaben sich hier 30-50 GB je Stunde !
Hier müsste also die Journalgrenze bereits sehr niedrig angesetzt werden, eine Aufzeichnung auf Band geht schnell an Kapazitätsgrenzen.

Wenn nun ein neues Programm mit Transaktionssicherheit entwickelt wird und hier entsprechende Satzsperren durch Updates entstehen, kann es sein, dass der Rest der Anwendung Probleme bekommt, da diese grundsätzlich nicht mit Satzsperren rechnet und deshalb dort zu Fehlverhalten führt wenn eine Satzsperre auftritt (keine Bezugszahl für Satzsperre, Programmabruch mit CPF-Meldung).

Diese ERP-Anwendung rechnet an keiner Stelle mit einer Satzsperre, da diese, wie gesagt, über Flagfelder (mittels Filehandler-Programmen) bearbeitet werden.
Es gibt bestimmt noch andere Anwendungen die ein ähnliches konzeptionelles Verhalten verwenden.

Wie gesagt, wir haben es getestet und bezüglich dieser Anwendung für unmöglich befunden.