SQL + Datensatzsperre

[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.

[B.Hauser]

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.

Sofern die Standard-Satzwartezeit nicht verändert wurde ist diese 60 Sekunden, d.h. bevor die Alt-Anwendung auf Satz-Sperre/Fehler läuft wird eine volle Minute versucht auf den Satz (sofern die Datei unter Update definiert ist) zuzugreifen. ... eine verdammt lange Zeit.

Es hat auch niemand gesagt, dass die Verwendung von Commitment Control einfach ist. Da muss man sich schon überlegen, wie groß eine Transaktion wird und ob man diese nicht ggf. stückeln muss, da sonst nichts mehr läuft.
So schön es auch wäre 1000 Aufträge mit jeweils 500 Posititonen in einer Transaktion auszulagern, Bewegungen und Bestände zu aktualisieren die entsprechenden Sätze für die Buchhaltung zu generieren usw. ... da läuft nichts mehr!

Jede Transaktion, die länger als ein paar Sekunden (was schon sehr hoch gegriffen ist) benötigt würde ich überdenken wollen.
Vielfach muss an solchen Stellen auch das ganze Konzept neu überdacht werden, z.B. anstatt einen Auftrag komplett in einer Transaktion zu verarbeiten, muss pro Auftrags-Position eine Transaktion erfolgen. Wenn alle Positionen ordnungsgemäß verarbeitet wurden, wird ein entsprechender Status im Auftrags-Kopf gesetzt, der besagt, dass eine Weiterverarbeitung möglich ist.

... aber wie gesagt jedem das seine!

Birgitta

[BenderD]

... doch, doch - durchaus - die Verwendung von Commit ist einfach!
Am Besten sieht man mal bei denen über den Zaun, die das am längsten machen und das sind die Mädels und Jungs von der Wassergekühlten Fraktion. Unter MVS hat man da einen Transaktionsmonitor (z.B.: CICS - gibts sogar auf der AS/400, aber keiner nimmts). Selbiger steuert dann sowohl die Bildschirme, als auch die Datenbank Operationen und sorgt dafür, dass eine Datenbanktransaktion nie länger als eine Benutzertransaktion (:= Ausgabe eines Bildschirms mit Eingabemöglichkeit für den Benutzer) dauern kann. Damit beantwortet sich auch die Frage mit den 1000 Aufträgen, wie von selber. Die Transaktion wird nie größer als 1 Auftrag werden, und wenn die Positionen einzeln eingegeben werden, nicht größer als eine Position, den Rest hast du ja schon skizziert.
Vielleicht sollte man da mal einen Workshop zu machen (ich würde da auch Sonderpreise für das Forum machen...).

D*B

Es hat auch niemand gesagt, dass die Verwendung von Commitment Control einfach ist. Da muss man sich schon überlegen, wie groß eine Transaktion wird und ob man diese nicht ggf. stückeln muss, da sonst nichts mehr läuft.
So schön es auch wäre 1000 Aufträge mit jeweils 500 Posititonen in einer Transaktion auszulagern, Bewegungen und Bestände zu aktualisieren die entsprechenden Sätze für die Buchhaltung zu generieren usw. ... da läuft nichts mehr!
Birgitta