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
Zitat Zitat von 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