ODBC und Journaling

[Neptun]

Hallo,

was ist, wenn Du Deinen SQL-Statement WITH NC (NC = No Commit) hinzufügst?

Also etwa so:

Insert into MySchema.MyTable
values(.....)
With NC 

Vielleicht hilfts ja!

Birgitta

@B. Hauser
Leider wird die SQL-Syntax für Befehle wie den INSERT komplett vom Tool generiert ... Jetzt bitte nicht schreien "Das ist aber sicher nicht optimal" oder so ... das wissen wir
Aber so ist momentan leider Stand der Dinge. Ich kann zusätzlich SQL-Befehle an die AS/400 schicken, welche kein Ergebnis liefern, also z.B. kann ich keinen SELECT machen (ist eine undokumentierte Funktion, durch Zufall herausgefunden). Theoretisch könnte ich auch den INSERT etc. darüber laufen lassen, aber dieser Ansatz (könnte man wohl als Embedded SQL bezeichnen) ist momentan erstmal nicht gewollt.

Trotzdem danke für den Tip, kann vielleicht mal nützlich sein


@Fuerchau
Tja, ich warte noch auf Antwort vom Hersteller. Ich wäre wirklich verwundert wenn die das nicht bedacht hätten...


Gruß
Neptun

[BenderD]

Hallo,

warum haben eigentlich im AS400 Umfeld so viele Leute was gegen Commit - das ist Stand der Technik und wer es nicht einsetzt, riskiert unnötig (juristisch: grob fahrlässig!) inkonsistente Daten.
Dass das Tool die SQL Statements generiert ist doch völlig in Ordnung, das verhindert eher Unfug.

@B. Hauser
Leider wird die SQL-Syntax für Befehle wie den INSERT komplett vom Tool generiert ... Jetzt bitte nicht schreien "Das ist aber sicher nicht optimal" oder so ... das wissen wir
Aber so ist momentan leider Stand der Dinge. Ich kann zusätzlich SQL-Befehle an die AS/400 schicken, welche kein Ergebnis liefern,
Neptun

Das senden von SQL Anweisungen ohne Rückgabe reicht doch völlig:
wen die Transaktion erfolgreich war, schickt man ein Commit hinterher, war es nix, dann eben ein Rollback.
Wenn man nun tatsächlich den Unfug bevorzugt Commit abzuschalten, dann sendet man halt einmal zu Beginn "SET TRANSACTION ISOLATION LEVEL *NONE" und ab dann kann die Anwendung auch kaputte Transaktionen permanet in die Datenbank schreiben: welchen Sinn das allerdings haben soll, entzieht sich meiner Kenntnis!!!

mfg

Dieter Bender

[Fuerchau]

Für neue Anwendungen ist das ja auch in Ordnung. Leider muss man manchmal Client-Programme auf existierenden ERP-Datenbanken entwickeln die häufig nicht journalisiert werden. Und dann steht man halt mit solchen "Tools" etwas im Regen.

[BenderD]

@Baldur: ich kann da keinen Regen erkennen. Es stellt überhaupt kein Problem dar eine Datenbank einer vorhandenen Anwendung zu journalisieren (wer hier an Platte spart, kann nicht wirklich rechnen). Ich bin zu meinen Zeiten als (Teil)Verantwortlicher noch einen Schritt weiter gegangen und habe grundsätzlich alles journalisiert, obwohl keine einzige Anwendung Commit verwendet hat - alleine die zusätzlichen Möglichkeiten bei Fehleranalyse lassen das sinnvoll erscheinen.

mfg

Dieter Bender

Für neue Anwendungen ist das ja auch in Ordnung. Leider muss man manchmal Client-Programme auf existierenden ERP-Datenbanken entwickeln die häufig nicht journalisiert werden. Und dann steht man halt mit solchen "Tools" etwas im Regen.

[Neptun]

Hallo!

Mir geht es beim Abschalten vom Journaling vor allem um die Performance. Ich denke mal, dass die Zugriffe um einiges zügiger ablaufen ohne Journaling, oder?
Ich spreche hier von Massenzugriffen, also sehr viele Befehle welche an die Datenbank übergeben werden.
Wieviel Prozent Performanceeinbuße hat man durch das Journaling, gibt es da Erfahrungswerte?

Gruß
Neptun

[Fuerchau]

Fast gar keine !
Immerhin ist das Netz, dass diese Insert/Updates durchführt ja langsamer als die AS/400. Selbst 10.000 Transaktionen/Sekunde sind keine Seltenheit, dabei wird durchaus mehr als 1 Datei journalisiert.
Einzig der Rollback kann dann etwas dauern.

[Neptun]

Fast gar keine !
Immerhin ist das Netz, dass diese Insert/Updates durchführt ja langsamer als die AS/400. Selbst 10.000 Transaktionen/Sekunde sind keine Seltenheit, dabei wird durchaus mehr als 1 Datei journalisiert.
Einzig der Rollback kann dann etwas dauern.

Wow, da hatte ich etwas anderes vermutet. Aber gut, mit dieser Aussage lässt sich arbeiten.

Ich hatte ja das Journaling im Auge wegen der unterirdischen Performance ... Denn eine andere Anwendung welche die SQL-Befehle mittels ODBC direkt im COBOL-Programm per API-Call's macht (und kein Journaling hat) ist wesentlich schneller.


Gruß
Neptun

[BenderD]

Hallo,

it depends on, wie so oft!
- journalisierung muss pro update sequentiell was schreiben, das kostet (fast) keinen Strom, wenn man dafür einen extra ASP oder ausreichend viele Zugriffsarme hat
- es kostet wenige Prozent mehr CPU, gerechnet auf die Database Workload
- jegliches forcierte schreiben wird abgeschaltet (Dateien sind ja jetzt redundante Daten!)
Summa summarum kommt dabei raus, dass bei gesund dimensionierter Hardware die Unterschiede unter der Messbarkeitsschwelle liegen. Wenn man den Overhead bei Fehlersuche und "Reparatur" dazunimmt, dann wird man schneller!!!
Bei schwach dimensionierter Hardware, kann allerdings ein Tropfen an zusätzlicher Workload ein Fass zum überlaufen bringen, dann liegt das natürlich (gerade bei heutigen Hardwarepreisen) an sparen am falschen Ende.
- eine Ausnahme ist mir bekannt: grosse SQL Bulkscripte (ala Update xxx set yyy = 2 * yyy) mit zig Millionen betroffenen Sätzen könnten nach deaktivierung von Journalisierung signifikant schneller laufen.
- ebenfalls ungünstig sind Riesentransaktionen (Batchjob einmal am Ende Commit) Sperren kosten was und viele Sperren können dann bremsen.
Wie so oft in der Welt bekommt man nix geschenkt, aber eine Abwägung von Hardwareaufwand und Vorteilen spricht für Journalisierung. Hier bekommt man viel für wenig Aufwand und wenn man diesen denn treibt (sprich: die erforderliche Hardware hat), dann gibt es keinerlein Performance Einbußen.

mfg

Dieter Bender

Hallo!

Mir geht es beim Abschalten vom Journaling vor allem um die Performance. Ich denke mal, dass die Zugriffe um einiges zügiger ablaufen ohne Journaling, oder?
Ich spreche hier von Massenzugriffen, also sehr viele Befehle welche an die Datenbank übergeben werden.
Wieviel Prozent Performanceeinbuße hat man durch das Journaling, gibt es da Erfahrungswerte?

Gruß
Neptun

[Fuerchau]

Wenn eine Anwendung ohne Commit schneller ist als mit Commit, dann ist das meist ein Design-Problem.
Wenn du AutoCommit aktiv hast, wird natürlich bei jedem Insert eine Commit durchgeführt, was natürlich dauert.
Steuere das Commit selber und mach den Commit genau dann wenn er aus Datensicht notwendig ist. Im Zweifel halt mit dem letzten Insert/Update/...

Die andere Anwendung kann ich dann stark ausbremsen, wenn ich die zu schreibende Datei mit FORCE(1) ändere.
Mein Anwendung mit Journal läuft dann erheblich schneller !!!

[Neptun]

Der Lesezugriff ist leider verdammt lahm ... ich habe mir mal das ODBC.log angeguckt. Mir wurde ganz anders ... Ich vermute mittlerweile, dass das Journaling nicht die Quelle des Performance-Übels ist.

In meinem Testbeispiel sind ein paar hundert Sätze zu lesen, jeweils mit ca. 250 Spalten. Es werden natürlich alle Felder schön artig mit SQLBindColumn gebunden. Allerdings nicht nur einmal, sondern bei jedem (!) SQLFetch (es war klar das SQLFetchScroll [ganzen Block direkt in eine Tabelle lesen] vom Tool nicht verwendet wird, dazu müsste man die Anwendung ja auch stärker umprogrammieren; mal gnz abgesehen davon, dass das Tool dies gar nicht unterstützt, *lol*). Es gibt zwar einen START, für den man auch die WHERE-Klausel beeinflussen kann, aber dennoch wird für jeden SQLFetch wieder 250 mal SQLBindColumn gemacht. Aaaahhhh, ich brauche jetzt jemanden zum Erwürgen


Gruß
Neptun

[BenderD]

Hallo,

bevor du würgst, solltest du vielleicht mal den Database Monitor konsultieren, da siehst du was die Datenbank draus macht - möglicherweise sind da auch Probleme im Spiel, die man auf Ebene der Datenbank bessern kann (fehlende Indexe). BTW: bei Lesezugriffen ist Journaling aussen vor, Commit level könnte natürlich dennoch eine Rolle spielen (so ab Repeatable Read im Sinne von ANSI SQL)

mfg

Dieter Bender

Der Lesezugriff ist leider verdammt lahm ... ich habe mir mal das ODBC.log angeguckt. Mir wurde ganz anders ... Ich vermute mittlerweile, dass das Journaling nicht die Quelle des Performance-Übels ist.

In meinem Testbeispiel sind ein paar hundert Sätze zu lesen, jeweils mit ca. 250 Spalten. Es werden natürlich alle Felder schön artig mit SQLBindColumn gebunden. Allerdings nicht nur einmal, sondern bei jedem (!) SQLFetch (es war klar das SQLFetchScroll [ganzen Block direkt in eine Tabelle lesen] vom Tool nicht verwendet wird, dazu müsste man die Anwendung ja auch stärker umprogrammieren; mal gnz abgesehen davon, dass das Tool dies gar nicht unterstützt, *lol*). Es gibt zwar einen START, für den man auch die WHERE-Klausel beeinflussen kann, aber dennoch wird für jeden SQLFetch wieder 250 mal SQLBindColumn gemacht. Aaaahhhh, ich brauche jetzt jemanden zum Erwürgen


Gruß
Neptun

[Fuerchau]

Das könnte auch an irgendeiner fehlenden PREPARED-Einstellung liegen.
Wenn der SQL im Programm nicht statisch ist, kann kein Prepare verwendet werden und somit ist das Binden immer neu erforderlich.
Scheinbar arbeitet dein Tool nicht mit Prepared und ist somit für Massendaten nicht geeignet sondern ist wohl ausschließlich für Dialoge konzipiert.