Wann werden Änderungen vorgenommen?

Question

Mit Orakel 10g, Zugriff über Perl DBI, habe ich eine Tabelle mit ein paar Dutzend Millionen Zeilen aktualisiert einige Male pro Sekunde, während viel häufiger aus einem anderen Prozess gelesen werden.

Bald wird die Update-Frequenz um eine Größenordnung (vielleicht zwei) zunehmen. Jemand hat vorgeschlagen, dass die Durchführung von N Updates statt nach jedem Update die Leistung verbessert.

Ich habe ein paar Fragen:

• dass schneller sein oder langsamer oder es hängt (Planung, sobald beide Weg zur Benchmark als eine ordentliche Simulation des neuen Last bekommen)
• Warum wird es helfen/behindern die Leistung.
• Wenn "es abhängt ...", auf was?
• Wenn es hilft, was ist der beste Wert von N?
• Warum kann mein lokaler DBA keine hilfreiche direkte Antwort haben, wenn ich eine brauche?
  (Eigentlich weiß ich die Antwort auf diese ein) :-)

EDIT:

@codeslave: Danke, btw Uncommited Änderungen zu verlieren ist kein Problem, ich nicht löschen kann Originaldaten verwendet für die Aktualisierung, bis ich sicher, dass alles am in Ordnung ist, btw Dame Reinigung tat den Server unplugs, zWEIMAL :-)

Einige googeln zeigte, dass es helfen könnte weil von Problem im Zusammenhang mit Rollback Segmente, aber ich weiß immer noch nicht eine Faustregel für N alle paar Zehner? Hunderte? tausend ?

@diciu: Tolle Infos, werde ich auf jeden Fall Blick in das.

Answer 1

Ein Commit führt dazu, dass Oracle Daten auf die Festplatte schreibt - d. H. In die Redo-Log-Datei, so dass die getätigte Transaktion bei einem Stromausfall usw. wiederhergestellt werden kann. Das Schreiben in eine Datei ist langsamer als das Schreiben in den Speicher. Daher wird ein Commit langsamer ausgeführt, wenn es für viele Operationen in einer Zeile ausgeführt wird, anstatt für eine Reihe von verbundenen Aktualisierungen.

In Oracle 10g gibt es eine asynchrone begehen, dass es viel schneller, aber weniger zuverlässig macht: PS https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html

ich sicher weiß, dass in einem Szenario, das ich in einer bestimmten Anwendung gesehen haben, die Anzahl der verschmolzenen Updates zu ändern von 5K bis 50K macht es um eine Größenordnung schneller (10-mal schneller).

Answer 2

Schneller/langsamer?

Es wird wahrscheinlich ein wenig schneller sein. Allerdings führen Sie ein höheres Risiko in Deadlocks läuft, unbestätigte Änderungen zu verlieren, sollte etwas Katastrophales passiert (-Putzfrau unplugs den Server), FUD, Feuer, Brimstone usw.

Warum würde es helfen?

Offensichtlich weniger begehen Operationen, was wiederum bedeutet, dass weniger die Platte schreibt, usw.

DBA und klare Antworten?

Wenn es einfach war, brauchen Sie keins.

Answer 3

Die Reduzierung der Häufigkeit von Commits wird sicherlich die Dinge beschleunigen, aber beim Lesen und Schreiben dieser Tabelle gibt es häufig das Potenzial für Sperren. Nur Sie können die Wahrscheinlichkeit bestimmen, dass dieselben Daten gleichzeitig aktualisiert werden. Wenn die Wahrscheinlichkeit gering ist, legen Sie alle 50 Reihen fest und beobachten Sie die Situation. Versuch und Irrtum habe ich Angst :-)

Answer 4

Wenn Sie "die ursprünglichen Daten nicht löschen, die für die Aktualisierung verwendet werden, bis [Sie sind] sicher, dass alles in Ordnung ist", dann entfernen Sie alle diese inkrementellen Commits in zwischen und Rollback, wenn ein Problem auftritt? Es hört sich so an, als hätten Sie effektiv ein Transaktionssystem neben Transaktionen aufgebaut.

Answer 5

@CodeSlave Ihre Ihre Fragen werden von @stevechol beantwortet, wenn ich alle inkrementellen Commits entfernen wird es Sperren geben. Ich nehme an, wenn nichts Besseres kommt, werde ich seinem Rat folgen, eine zufällige Zahl wählen, die Last überwachen und entsprechend anpassen. Während der Anwendung @diciu twaks.

PS: die Transaktion oben auf der Transaktion ist nur zufällig, ich bekomme die Dateien für Updates per FTP und anstatt sie sofort zu löschen, setze ich einen Cron-Job, um sie eine Woche später zu löschen (wenn niemand die Anwendung hat beschwert), das bedeutet, wenn etwas schief geht habe ich eine Woche, um die Fehler zu fangen.

Answer 6

Neben der Verringerung der Festschreibungshäufigkeit sollten Sie auch Bulk-Aktualisierungen statt einzelner durchführen.