DatabaseTimeSpentWaiting(%)

[Alex_winf01]

Ich während des letzten Imports (waren größere Dateien) eine DatabaseTimeSpentWaiting(%) für die Class Commit bekommen. Über google hab ich herausgefunden, dass das Commit "zu häufig" kommt. Was kann ich machen? Evtl. die Redo-Log-Gruppen erweitern?

Der Import umfasste pro Datei ca. 9 Millionen Datensätze.

[carstenj]

Hi,

über welche DB redest du? Wäre interessant zu wissen. Oracle?

dass das Commit "zu häufig" kommt. Was kann ich machen? Evtl. die Redo-Log-Gruppen erweitern?

Sowas gehört eigentlich zu dem Grundlagenwissen eines DBAs.

Wenn du ein Import machst, ist das normalerweise eine Transaktion. Da findet dann eigentlich genau nur eine Commit Anweisung statt, was bei großen Importen natürlich nicht empfehlenswert ist. Dann wäre eine Maßnahme, die Redologs zu vergrößern.

Falls du aber zu viele Commits machst, ist genau das nicht nötig.

Daher müsste man nun genau wissen, um welche DB es sich handelt, und mit welchen Parametern du den Import angestartet hast.

[Alex_winf01]

@ carstenj

Sorry für die unklaren Angaben. Ich beziehe mich auf Oracle Version 10g. Den Import führe ich mit dem SQL-Loader durch.

[carstenj]

Hi,

also was natürlich sein kann, dass deine REDO-Logs zu langsam sind. Zieh doch mal einen Statspack Report oder einen AWR-Report, und stelle die Top 5 Events hier rein.

EDIT: Habt ihr denn Performanceprobleme? Nur weil das Event auftaucht, muss es ja nicht zwangsläufig Probleme verursachen.

[Alex_winf01]

@ carstenj

Woran kann das denn liegen, dass die REDO-Logs zu langsam sind?

Ein Report lohnt sich derzeit noch nicht, da wir uns noch im Rahmen einer Entwicklungsumgebung befinden und wir bisher nur die Tabellen angelegt und die Daten importiert haben.

[dr.dimitri]

DatabaseTimeSpentWaiting(%) für die Class Commit

Das sagt erstmal garnichts. Du wirst immer Waits bekommen, die Frage ist nur, wie hoch sie sind und in welchem Verhältnis sie zur Gesamtlaufzeit stehen.

Daher wäre wichtig zu sehen, wieviel % der Laufzweit wirklich darauf gewartet wurde. Bei einem Commit wird nämlich der Inhalt des Logbuffers in die REDO Logs geschrieben. Der Logbuffer wiederum ist mit ein paar MB relativ klein und wir auch unabhängig von einem Commit alle 3 Sekunden oder wenn 1MB Speicher darin belegt ist in der REDO Logs geschrieben.

Da Du anscheinen einen conventional load machst, wird die Frequenz der commits über den Parameter ROWS=xy festgelegt. Default sind 64 glaub ich.

Wenn Du die Option DIRECT=TRUE angiebst, führst Du einen sog. direct path load aus. Dabei werden zum einen keine REDO Logs geschrieben (ausser für die betroffenen Indices), und zum anderen wird der Inahlt an die Tabelle angehängt d.h. Platz, der innerhalb der Tabelle per Delete Statement frei geworden ist wird für den load nicht wieder verwendet.

9 Millionen Sätze sollten in ein paar Minuten in der DB sein, sofern Du nicht zig Indieces auf der Tabelle hast und die CPU, Platten und die Instance einigermaßen ausreichen dimensioniert sind.

Dim

[carstenj]

Hi,

z.B. langsames Dateisystem, oder ein langsames RAID, oder oder oder. Es gibt etliche Möglichkeiten. Aber wenn es keine Beeinträchtigung gibt, würde ich mich darum auch nicht weiter kümmern.

[bolleee]

Bei Commit müssen nicht nur Redo-log Dateien betroffen sein. Unter Umständen auch der Buffercache, der Undo-Tablespace oder auch die Datafiles.

Daher wäre es hilfreich, wenn du einen AWR-Report posten könntest.

[dr.dimitri]

Welche Auswirkung hat ein COMMIT auf diese drei Komponenten? Ich würde mal behaupten keine.

Dim