Commit ausschalten, Fehler

[dibe]

Liebe Helfende,
unsere Anwendung ist, wie vermutlich die meißten iSeries Anwendungen 'gewachsen'.
Der Ursprung ist die /36, dann /38 und schließlich /400.
Monotitische riesengrosse Programme, die alles machen, das war der Anfang. Und die DB hatte so die ein oder andere Redundanz, 'weil es einfacher / schneller' war.
Kurz danach kamen /copy für wiederkerenden Programmcode. Auch Call war mal, aus performance Gründen nicht gewünscht, viele werden sich noch daran erinnern. Ich weis nicht, warum bei uns kein Commit eingesetzt wurde, aber ich bin sicher das die damaligen Platz und performance Probleme mit verantwortlich sind.
Das 'modernisieren' dieser ehemaligen Sünden ist schrittweise verhältnismäßig einfach möglich.
Intern beschriebenen Dateien wurden 'in einem Kraftakt' auf extern umgestellt. Bildschirm Verarbeitung vom Zyklus befreit. '/copy' in 'call' umgemünst und vieles anderes, größtenteils Schritt für Schritt, nebenbei. Dabei wurden Fehler gemacht und einige Wochenenden verbraucht. Comit wurde, und das meine ich ernst, bisher nicht gebraucht. Und der Aufwand, dies in die alte Anwendung ein zu bauen, wäre imens! Daten Journalisieren wir (teilweise). Aber nie um 'transaktionen' zurück zu drehen, das konnte die Software, in der von uns benötigten Form, schon immer.

Ich hoffe weiterhin auf eure Unterstützung wenn wir mal wieder ein Problem haben, viele Dank!
Dietlinde Beck

PS: Das gilt auch für Herrn Bender, der mit seiner manchmal etwas deftigen Art uns schon oft erheitert hat. Aber irgend jemand muß ja alles besser können, sonst könnte man ja niemanden mehr fragen.

[Fuerchau]

Nun, was die MongoDB und ähnliche Datenbanken angeht, so unterscheiden diese sich nur in der Speicherungsform eines Dokuments (= Zeile).
Für die Abfrageoptimierung müssen trotzdem Indizes erstellt werden, Join-Beziehungen, also Relationen, sind dort genau so möglich und auch nötig.
Auch wenn man dokumentenbasiert speichert, ist das Prinzip der Abfragetechnik zwischen relationalen DB's und Dokumenten-DB's identisch.
Dass Dokumente beliebige Schlüssel-/Wertpaare aufweisen, bedeutet doch nichts anderes, als das nicht vorhandenen Werte zu Schlüsseln wie in der relationalen Welt auch, als NULL-Ergebnis bewertet werden.
Die Speicherungsform als typlose Daten, also egal ob Zeichen oder Zahlen oder Subdukumente als XML/JSON ist bei Aggregation wiederum kontraproduktiv, da hier erst Umformatierungen von Zeichen in Zahlen erfolgen müssen und das kostet Rechenzeit. Dies mag marginal erscheinen, aber Millionen von unnötigen Berechnungen drücken sich letztendlich auch in Sekunden aus.

Wie in einem anderen Thread schon mal beschrieben, habe ich für statistische Zwecke eine relationale Tabelle mit Voraggregaten auf der IBM i erstellt. Dieser Job auf einer P9 lief zwar knapp 3 Stunden, produzierte allerdings ca. 100 Millionen Ergebniszeilen mit mehreren 100-Millionen Abfragen auf anderen Tabellen.
Ich bezweifle, dass andere Datenbanken dies ohne massive Parallelisierung über diverse Server (Skalierungen) mit entsprechendem Verwaltungsoverhead hinbekommen.

Auch die Erweiterbarkeit der DB2 for i lässt keine Wünsche offen.
Solange man (wie bei anderen DB's auch) sich ausschließlich im SQL-Bereich aufhält, lassen sich Tabellen jederzeit erweitern, mittels View und Instead-Of-Triggern sogar programmneutral vollkommen umbauen.
Für ERP-Zwecke ist eine relationale Datenbank wie die DB2 for i, in meinen Augen, unschlagbar.

Übrigens:
NoSQL steht für "Not only SQL". Dies sieht man dann auch an den Abfragekonstrukten, die zwar nicht wie SQL aussehen, sich aber 1:1 in SQL umsetzen lassen.

[Andreas_Prouza]

Ich weis nicht, warum bei uns kein Commit eingesetzt wurde, aber ich bin sicher das die damaligen Platz und performance Probleme mit verantwortlich sind.

Hier hat Dieter schon richtig gesagt, dass Performance kein Nachteil bei Commit ist sondern vielmehr ein Vorteil.
Die Gründe liegen meist darin, dass es einfacher war auf die schnelle ein Programm zu entwickeln und sich kein Konzept für Commitment Control überlegen musste.
* Dauer der Satzsperren
* Wer darf wann ein COMMIT bzw. ROLLBACK durchführen
usw.

Am Besten sieht man es wenn man 100.000 INSERT INTOs absetzt.
Ohne Commit 40-50 Sekunden
Mit Commit ein paar Sekunden.

[BenderD]

Comit wurde, und das meine ich ernst, bisher nicht gebraucht. Und der Aufwand, dies in die alte Anwendung ein zu bauen, wäre imens! Daten Journalisieren wir (teilweise). Aber nie um 'transaktionen' zurück zu drehen, das konnte die Software, in der von uns benötigten Form, schon immer.

Commit ist nicht nur Transaktionssteuerung sondern steuert auch die Satzsperren beim Einsatz von SQL und SQL Programmierung ist mit Commit wesentlich einfacher als ohne. Wenn Programme mit commitlevel *none gewandelt werden, werden bei SQL Operationen ohne cursor Sätze nicht gesperrt, was beim Vergleich record level access mit SQL Probleme schafft. Ersetze ich chain / update durch select into / update, kann der Satz bei der SQL Variante zwischen lesen und update von anderen Benutzern geändert werden, was nicht gewollt sein kann.
Nun gibt es (fast) immer mehrere Wege nach Rom, commit ist hierbei der einfachste!
- Programme mit commitlevel *change (ist eh' default) wandeln, select into mit Sperrlevel repeatable read (kann man beim Statement mit with Klausel angeben), zur Freigabe der Sperre commit. Der gesamte Bereich der vorhandenen Anwendung ist davon nicht betroffen, für alles, was mit RLA gemacht wird, ändert sich nichts.
Was sich ändert ist, dass die betreffenden Dateien journalisiert werden müssen, was ich ohnehin für alle Dateien empfehlen würde - das ist bei jeglicher Fehlersuche Gold wert.

D*B

PS: noch etwas zu meiner "Art": es gibt keine dummen Fragen, sondern nur dumme Antworten, vielleicht sollte ich den Adressaten kritisch scharfer Antworten künftig deutlicher benennen. In dem Sinne entschudige ich mich bei dibe.

[holgerscherer]

Andreas,
das kannst Du auch in anderen Foren so erleben. Spannend finde ich auch, wenn aus einem Maus-Problem plötzlich eine Ideologiefrage wird. Soviel Platz muss auch sein. Und abgesehen davon überkommt mich mittlerweile das kalte Grausen, wenn ich mir die Strategie von IBM anschaue, von wegen Cloud und so.

Ausserdem habe ich immer mehr Gefallen an NoSQL Datenbanken, wie z.B. MongoDB, wer braucht denn das relationale Geschwurbel heute noch - eh alles von gestern.

Ideologie ist in unser Branche leider schon immer weit verbreitet - manche leben sogar davon. Das grundsätzliche Problem löst sich aber nicht von selbst (sprich: aussitzen). Gerade läuft die POW3R, und da hört man in Vorträgen und von Teilnehmern auch immer wieder das gleiche: bloss nix ändern, wenn es läuft. Und für zaghafte Versuche parallel hat auch niemand Zeit. Es läuft gerade in der IT momentan einiges heiss.

Zum Thema Cloud und IBM - da kann ich Dir nur Recht geben. Hersteller wie IBM (und viele Dienstleister) haben nur noch die großen Kunden im Auge, auch was die Konzeptionierung betrifft. Einen kleinen Kunden mit 30-50 Anwendern erschlägt man nicht nur durch das Angebot sondern auch die Technik drumherum. Der Kunde will nur "seinen Laden am laufen halten". Dafür sind dann drei Mitarbeiter und 5 Dienstleister notwendig - das überblickt doch keiner mehr. Und warum? (Antwort bitte hier einfügen)

DiBe macht eigentlich alles richtig - den Laden am laufen halten. Bitte nicht von mehr oder weniger spitzen Antworten gleich vertreiben lassen. Der Ton ist rauh, weil Wunsch und Wirklichkeit zu oft aufeinander prallen.

So, das wars von meiner Seite. Ich kümmere mich nun wieder darum, daß eine EDV läuft. Von IT habe ich für heute genug.

[Fuerchau]

Auch andere kochen nur mit Wasser und das Thema "Ändere kein laufendes System" habe ich aktuell mit einem Microsoft-ETL-Prozess via SSIS-Pakete.
Da SSIS native den SQLBulkCopy nicht unterstützt, wird halt quasi mittels "Insert into ... Select * from" über 2 Verbindungen kopiert.
Analyse des Microsoft-Teams: Der SQL-Server hat kaum was zu tun.
Anaylse des IBM-Teams: Die IBM i wartet ständig nur auf die Abholung.
Resultat: Macht auf jeden Fall die IBM i schneller, denn bei Microsoft ist noch Luft nach oben.

Analogie:
Der F1-Fahrer fährt mit 100 Km/h auf der Strecke. Meldung an das Team: Der Motor zeigt noch keine Belastungserscheinungen, alles i.O., aber macht mal die Strecke etwas breiter damit ich schneller vorwärts komme.