You are hereLOGGING oder NOLOGGING, das ist die frage - Teil 1

LOGGING oder NOLOGGING, das ist die frage - Teil 1


By jeiworth - Posted on 04 July 2008

Einführung

Die an mich meistgestellte Frage über NOLOGGING ist: Wenn ich eine Tabelle mit NOLOGGING erstelle, bedeutet das dass “Redo niemals erstellt wird” oder nur dass bei der Initialisierung kein Redo erstellt wird aber DML weiter hinten im Workflow Redo erstellt? Wie und wann kann man NOLOGGING implementieren?

Redo ist ein lebenswichtiger Bestandteil des Oracle Recovery-Mechanismus. Ohne Redo kann eine abgestürtzte Instanz sich nicht erholen und kann keine Datenkonsistenz gewährleisten. Übermäßig viele Redo-Aufrufe sind das Ergebnis ausgiebiger Last auf der Datenbank.

Diese Abhandlung beschäftigt sich mit der Reduzierung von Redo-Aufrufen mittels der LOGGING- und NOLOGGING-Optionen, deren Unterschiede, wie es funktioniert, wie man es reduziert und wann man es benutzt.

Ebenfalls enthalten sind Beispiele und Tipps zu beiden Optionen.

Die Hauptmerkmale für die NOLOGGING-Option laut des Oracle Database Administrator's Guide 10g Release 2 sind:

• Speicherplatzbedarf des Redo-Logs wird reduziert
• Zeit zur Generierung einer Tabelle wird reduziert
• Leistungszuwachs bei gleichzeitiger Generierung großer Tabellen

“Eine besonders wichtige Regel im Umgang mit Daten ist, sich niemals in eine nicht wiederherstellbare Lage zu versetzen. Die Wichtigkeit dieser Richtlinie kann nicht genug betont werden, aber sie bedeutet nicht dass man keine zeitsparenden oder leistungsverbessernden Optionen benutzen darf.”

Was ist ein Redo?

Lassen Sie uns den Redo-Prozess kurz zusammenfassen: Wenn Oracle-Blöcke geändert werden, einschließlich Undo-Blöcke, speichert Oracle die Änderungen in Form von Änderungsvektoren welche als Redo-Einsprünge oder Redo-Einträge bezeichnet werden. Die Änderungen werden von der Serverinstanz in den Redo-Log-Puffer im SGA geschrieben. Der Redo-Log-Puffer wird dann vom LGWR (LoGWRiter) in beinahe Echtzeit in die Online-Redo-Logs geleert. (siehe Abb. 1)

Der LGWR schreibt in die Redo-Logs wenn:
• Wenn ein User ein COMMIT sendet.
• Wenn der Log-Buffer zu 1/3 voll ist.
• Wenn die Menge an Redo-Einträge 1MB übersteigt
• Alle drei Sekunden.
• Wenn ein Datenbank-Checkpoint läuft. Die Redo-Einträge werden vor dem Checkpoint geschrieben um Wiederherstellbarkeit zu gewährleisten.

“Ist der Log-Puffer zu klein sieht man während häufigen Redo-Operationen Wartemeldungen bezüglich Log-Puffer-Speicherplatz (log buffer space wait). Je nachdem würde der LGWR den Redo aber nicht schreiben bis der log io size-Grenzwert überschritten ist (per Default 1/3 des Log-Puffers oder 1MB Redo-Einträge, was davon zuerst eintritt) und der Rest des Log-Puffers könnte gefüllt sein bevor der LGWR zu Ende geschrieben hat um im Puffer wieder Speicherplatz freigeben zu können.

Idealerweise sollte der Log-Puffer groß genug sein um mit allen Häufungen an Redo-Operationen fertig zu werden komplett ohne log buffer space waits.

Allgemein treten die schwersten Häufungen an Redo-Operationen direkt nach einem Log-Wechsel auf, wenn Redo-Erstellung längere Zeit deaktiviert war und ein Backlog vorhanden ist welches Speicherplatz im Log-Puffer anfordert.” von Steve Adams.

Redo Log-Dateien speichern Änderungen der Datenbank als Folge von Transaktionen und Oracle-internen Serveroperationen. (Eine Transaktion ist eine logische Arbeitseinheit bestehend aus einem oder mehreren SQL-Statements die von einem User ausgeführt werden.) Redo Log-Dateien schützen die Datenbank vor Integritätsverlust durch Systemversagen hervorgerufen durch Stromausfälle, Versagen einer Festplatte, u.s.w.

Redo Log-Dateien müssen reduntant gespeichert werden um sicher zu stellen dass die Information welche sie beinhalten nicht selbst durch z.B. Einen Festplattenausfall verloren gehen. Das Redo-Log besteht aus Gruppen von Redo Log-Dateien. Eine Gruppe besteht aus einer Redo Log-Datei und ihren reduntanten Kopien. Jede identische Kopie ist ein Mitglied dieser Gruppe und jede Gruppe wir über eine Nummer identifiziert. Der LGWR-Prozess schreibt Redo-Einträge aus dem Redo Log-Puffer an alle Mitlgieder einer Redo Log-Gruppe bis die Datei voll ist oder eine Log-Wechsel-Operation angefordert wird. Dann wechselt er und schreibt in die Log-Dateien der nächsten Gruppe. Redo Log-Gruppen setzt man rotierend ein. (siehe Abb. 2)

Best practice Tipp:

Oracle empfiehlt dass jede Redo Log-Gruppe aus mindestens 2 Dateien besteht und diese Dateien auf mindestens zwei separaten Festplatten oder Controller verteilt werden so daß kein einzelner Hardwareausfall eine gesamte Log-Gruppe zerstören kann.

Der Verlust einer ganzen Log-Gruppe ist eine der gravierendsten Versagen der Speichermedien da es Datenverlust zur Folge haben kann. Der Verlust eines einzelnen Mitglieds einer Log-Gruppe ist dagegen trivial und stört den Datenbankbetrieb weiter nicht, außer einem Eintrag im Alert-Log.

Beachten Sie dass Redo Logs großen Einfluß auf die Datenbank-Performance haben da ein Commit so lange nicht abgeschlossen werden kann bis die Transaktions-Informationen in die Log-Dateien geschrieben wurden. Man sollte daher die Redo Log-Dateien auf die schnellsten Platten der schnellsten Controller die man zur Verfügung hat verteilen und falls möglich keine weiteren Datenbankbezogenen Dateien auf denselben Platten speichern.

Da gleichzeitig immer nur für eine einzelne Log-Gruppe geschrieben wird kann man ohne weiteres Mitglieder mehrerer Gruppen auf der gleichen Platte haben.

Um zu vermeiden Informationen zu verlieren welche für die Wiederherstellung der Datenbank von Bedeutung sein könnten hat Oracle einen Archiv-Hintergrundprozess (ARCn) welcher Redo Log-Dateien archiviert sobald sie voll sind. Dennoch, es sei hier erwähnt dass dieser Prozess nicht bei jeder Oracle-Datenbank aktiv sein muss. Eine Instanz mit aktivierter Archivierung befindet sich im ARCHIVELOG Modus und eine Instanz mit deaktivierter Archivierung befindet sich im NO ARCHIVELOG Modus.

Man kann den Modus einer Instanz erfahren indem man den Wert für den LOG_ARCHIVE_START-Parameter in der Instanz-Parameter-Datei (pfile oder spfile – Dieser Parameter ist in Version 10g veraltet) überprüft, indem man eine SQL Query an v$database sendet (“ARCHIVELOG” bedeutet Archivierung ist aktiviert und “NOARCHIVELOG” bedeutet Archivierung ist deaktiviert) oder über den Befehl SQL ARCHIVE LOG LIST.

SQL> Select log_mode from v$database;
LOG_MODE
-------------------
ARCHIVELOG

SQL> archive log list
Database log mode             Archive Mode
Automatic archival            Enabled
Archive destination           USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence    8
Next log sequence to archive  10
Current log sequence          10

Warten Sie folgendes Teil, ich spricht Redo Erzeugung und Regenerierbarkeit: wie, wenn und warum.

Subscribe in a reader


Syndicate

Syndicate content

Follow DatabasesLA on Twitter

Who's online

There are currently 0 users and 1 guest online.

Estadisticas

Locations of visitors to this page

hidden hit counter