Commit ausschalten, Fehler

[BenderD]

Wir arbeiten OHNE Commitment!

Das ist der Fehler! Wer hat euch denn so einen Unfug eingeredet?

D*B

[holgerscherer]

Das ist der Fehler! Wer hat euch denn so einen Unfug eingeredet?

Vielleicht ein Performance-Berater? Man hört ja so einiges den lieben langen Tag...

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