View Full Version : SQL + Datensatzsperre
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.
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
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.
Stimme Dir 100 % zu!
Meine ERP Anwendung arbeitet auch so.
Und 2 andere, die ich kenne auch.
Gruß
Robi
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.
@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.
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
... 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