Wann sollten Änderungen festgeschrieben werden?

Question

Wenn ich Oracle 10g verwende und über Perl DBI darauf zugreife, habe ich eine Tabelle mit einigen zehn Millionen Zeilen, die einige Male pro Sekunde aktualisiert wird, während sie viel häufiger aus einem anderen Prozess gelesen wird.

Bald wird die Aktualisierungshäufigkeit um eine Größenordnung (vielleicht zwei) steigen.Jemand hat vorgeschlagen, dass die Leistung verbessert wird, wenn alle N Updates statt nach jedem Update festgeschrieben werden.

Ich habe ein paar Fragen:

• Wird das schneller oder langsamer sein oder hängt es davon ab (es ist geplant, einen Benchmark in beide Richtungen durchzuführen, sobald eine anständige Simulation der neuen Last möglich ist)?
• Warum wird es die Leistung verbessern/behindern?
• Wenn „es kommt darauf an ...“, worauf dann?
• Wenn es hilft, was ist der beste Wert von N?
• Warum kann mein lokaler DBA keine hilfreiche, klare Antwort haben, wenn ich eine brauche?
  (Eigentlich kenne ich die Antwort darauf) :-)

BEARBEITEN:

@codeslave:Vielen Dank, dass es kein Problem ist, ungewöhnliche Änderungen zu verlieren. Ich lösche die ursprünglichen Daten nicht, die zum Aktualisieren verwendet werden, bis ich sicher bin, dass alles in Ordnung ist. Übrigens, die Reinigungsdame hat den Server zweimal abgeschlossen :-)

Einige Googeln zeigten, dass es aufgrund des Problems im Zusammenhang mit Rollback -Segmenten hilfreich sein könnte, aber ich kenne immer noch keine Faustregel für N alle paar Zehnte?Hunderte?tausend ?

@diciu:Tolle Infos, ich werde das auf jeden Fall dazu schauen.

Answer 1

Ein Commit führt dazu, dass Oracle Dinge auf die Festplatte schreibt – d. h.in der Redo-Log-Datei, sodass alles, was die festgeschriebene Transaktion getan hat, im Falle eines Stromausfalls usw. wiederhergestellt werden kann.Das Schreiben in eine Datei ist langsamer als das Schreiben in den Speicher, daher ist ein Commit langsamer, wenn es für viele Vorgänge hintereinander ausgeführt wird, statt für eine Reihe zusammengeführter Aktualisierungen.

In Oracle 10g gibt es einen asynchronen Commit, der es viel schneller, aber weniger zuverlässig macht: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html

PS: Ich weiß mit Sicherheit, dass in einem Szenario, das ich in einer bestimmten Anwendung gesehen habe, die Änderung der Anzahl zusammengeführter Updates von 5.000 auf 50.000 die Geschwindigkeit um eine Größenordnung (zehnmal schneller) erhöht.

Answer 2

Die Reduzierung der Commits-Häufigkeit wird die Dinge sicherlich beschleunigen, aber da Sie häufig in diese Tabelle lesen und schreiben, besteht die Möglichkeit von Sperren.Nur Sie können die Wahrscheinlichkeit bestimmen, dass dieselben Daten gleichzeitig aktualisiert werden.Wenn die Wahrscheinlichkeit dafür gering ist, führen Sie einen Commit alle 50 Zeilen durch und überwachen Sie die Situation.Versuch und Irrtum, fürchte ich :-)

Answer 3

Sie sollten nicht nur die Commit-Häufigkeit reduzieren, sondern auch die Durchführung von Massenaktualisierungen anstelle einzelner Aktualisierungen in Betracht ziehen.

Answer 4

Wenn Sie „die für die Aktualisierung verwendeten Originaldaten erst dann löschen, wenn Sie sicher sind, dass alles in Ordnung ist“, warum entfernen Sie dann nicht alle dazwischen liegenden inkrementellen Commits und führen ein Rollback durch, wenn ein Problem auftritt?Es hört sich so an, als hätten Sie praktisch ein Transaktionssystem auf der Basis von Transaktionen aufgebaut.

Answer 5

@CodeSlave Ihre Fragen werden von @stevechol beantwortet. Wenn ich ALLE inkrementellen Commits entferne, wird es Sperren geben.Ich denke, wenn sich nichts Besseres ergibt, werde ich seinem Rat folgen, eine Zufallszahl auswählen, die Last überwachen und entsprechend anpassen.Beim Anwenden von @diciu Twaks.

PS:Die Transaktion zusätzlich zur Transaktion ist einfach ein Zufall. Ich erhalte die für Aktualisierungen verwendeten Dateien per FTP und anstatt sie sofort zu löschen, stelle ich einen Cron-Job ein, der sie eine Woche später löscht (wenn sich niemand, der die Anwendung verwendet, beschwert hat), das heißt, wenn etwas geht schief. Ich habe eine Woche Zeit, um die Fehler zu erkennen.

Answer 6

Schneller/langsamer?

Es wird wahrscheinlich etwas schneller gehen.Es besteht jedoch ein größeres Risiko, dass es zu Deadlocks kommt, nicht festgeschriebene Änderungen verloren gehen, wenn etwas Katastrophales passiert (Putzfrau zieht den Server aus), FUD, Feuer, Brimstone usw.

Warum sollte es helfen?

Offensichtlich weniger Festschreibungsvorgänge, was wiederum weniger Schreibvorgänge auf die Festplatte usw. bedeutet.

DBAs und klare Antworten?

Wenn es einfach wäre, brauchen Sie keins.