Commit ausschalten, Fehler

[BenderD]

... auch das ist Unfug. Commit fördert asynchrones schreiben, was ein positiver Faktor ist. Davon abgesehen wird Leistung an anderen Stellen verbrannt und am teuersten sind Fehler, die in die Datenbank eingebrannt werden.

D*B

[Fuerchau]

Also Journalisierung und Commit-Steuerung war noch nie ein Performanceproblem.
Eher sind viele Indizes beim Insert ein Problem, wobei hier zwischen Unique-/Nicht-Unique noch unterschieden wird.
Unique-Indizes werden sofort geprüft und gepflegt, Nicht-Unique-Indizes werden verzögert gewartet.
Deshalb sollte man nicht so viele Unique-Indizes verwenden.
Allerdings habe ich auch bei 30 - 50 Indizes bei der AS/400 noch nie Probleme bekommen.
Da hat der SQL-Server schon eher dran zu knacken.

[BenderD]

Also Journalisierung und Commit-Steuerung war noch nie ein Performanceproblem.

... bei Georgs Elektroheizung vielleicht, bei der /38 sicher. Das ist aber schon 38 Jahre her und hängt der AS/400 heute noch an - kein Wunder, dass das System als altmodisch verschrien ist, obwohl es die Anwender und Protagonisten sind und die Büchse nix dafür kann. Manch eine*r meint, wenn man den neuesten Namen für die AS/400 kennt und verwendet, sei man auf dem Stand der Technik.

D*B

[holgerscherer]

Manch eine*r meint, wenn man den neuesten Namen für die AS/400 kennt und verwendet, sei man auf dem Stand der Technik.

D*B

Heute gehört: "Wir aktualiseren unser IBM i bald, sind noch auf V6R1"

*keuch*

Ich erlebe das häufiger, daß wichtige Funktionen deaktiviert werden wg angeblicher Performance-Sorgen. Und später erinnert sich keiner und es heißt, "das Ding kann das nicht".
Schaut Euch nur immer die Fragen an: "Wie kann ich ohne Audit-Journal herausfinden, wer XYZ gemacht hat?"...

-h

[Fuerchau]

Also für das Audit-Journal muss auf jeden Fall der Betriebsrat herangezogen sowie die Vereinbarkeit zum DSGVO geprüft werden. Immerhin werden hier massiv personenbezogene Daten gesammelt.
Das ist zwar nicht schlimm, allerdings darf dies nicht personenbezogen ausgewertet werden.
Hier gilt das Prinzip: Man muss den Täter auf frischer Tat erwischen, eine Überwachung darf nur von der Staatsanwaltschaft bei begründetem Verdacht angeordnet werden.
Außerdem ist die Erhebung der Daten auf genuau die verdächtigte Person einzuschränken.
Die Fragestellung "Wer hat XYZ gemacht" darf so gar nicht erst gestellt werden, da generell die Unschuldsvermutung gilt.

[Andreas_Prouza]

Merkt ihr eigentlich, dass ihr durch solche "ihr macht alles falsch" Postings, die Leser dazu demotiviert Fragen ins Forum zu stellen?!?
Bei div. Veranstaltungen höre ich immer wieder, dass sie keine Lust haben hier was zu Posten, weil man gleich als Volldepp abgestempelt wird.
Wir sollten hier helfen und nicht immer gleich alles kritisieren.
Was aber nicht heißen soll, dass man keine Tipps geben soll wie man es besser machen kann bzw. was nicht so optimal ist.
Aber ein Minimum an Respekt für den Bereich außerhalb des eigenen Tellerrands wäre hilfreich.

Zitat Einstein: "Der Horizont vieler Menschen ist ein Radius gleich null und das nennen sie ihren Standpunkt"

[camouflage]

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.

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

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