LOGGING/NOLOGGING hilft bei der Verwaltung der Aktivierung von Direktpfadschreibvorgängen, um die Erzeugung von REDO und UNDO zu reduzieren. Dies ist eine von mehreren Möglichkeiten, das empfindliche Gleichgewicht zwischen Wiederherstellbarkeit und Leistung zu kontrollieren.
Hintergrundinformationen zur Oracle-Architektur
WIEDERHOLEN So sorgt Oracle für Haltbarkeit, das „D“ in ACID. Wenn eine Transaktion festgeschrieben wird, werden die Änderungen nicht notwendigerweise ordentlich in den Datendateien gespeichert. Das hält die Dinge schnell und lässt Hintergrundprozesse einen Teil der Arbeit erledigen. REDO ist eine Beschreibung der Änderung. Es wird schnell auf mehreren Platten in einem "dummen" Protokoll gespeichert. Änderungen sind schnell und wenn der Server eine Mikrosekunde nach der Rückgabe des Commit ausfällt, kann Oracle die REDO-Protokolle durchgehen, um sicherzustellen, dass die Änderung nicht verloren geht.
RÜCKGÄNGIG hilft Oracle, Konsistenz zu schaffen, das "C" in ACID. Es speichert eine Beschreibung, wie die Änderung rückgängig gemacht werden kann. Diese Informationen werden möglicherweise von einem anderen Prozess benötigt, der die Tabelle liest und wissen muss, was der Wert benutzt hat zu einem älteren Zeitpunkt sein.
Direkter Pfad schreibt Überspringen Sie REDO, UNDO, den Cache und einige andere Funktionen und ändern Sie Datendateien direkt. Dies ist in vielen Umgebungen eine schnelle, aber potenziell gefährliche Option, weshalb es so viele verwirrende Optionen gibt, um sie zu steuern. Direkte Pfadschreibvorgänge gelten nur für INSERTS und nur in den unten beschriebenen Szenarien.
Wenn Sie nichts tun, ist die Standardoption die sicherste, LOGGING.
Die vielen Möglichkeiten, Direct Path Writes zu kontrollieren
LOGGING/NOLOGGING ist eine von mehreren Optionen, um Schreibvorgänge im direkten Pfad zu steuern. Sehen Sie sich diese Tabelle von an FragTom um zu verstehen, wie die verschiedenen Optionen zusammenarbeiten:
Table Mode Insert Mode ArchiveLog mode result
----------- ------------- ----------------- ----------
LOGGING APPEND ARCHIVE LOG redo generated
NOLOGGING APPEND ARCHIVE LOG no redo
LOGGING no append ARCHIVE LOG redo generated
NOLOGGING no append ARCHIVE LOG redo generated
LOGGING APPEND noarchive log mode no redo
NOLOGGING APPEND noarchive log mode no redo
LOGGING no append noarchive log mode redo generated
NOLOGGING no append noarchive log mode redo generated
FORCE LOGGING kann alle diese Einstellungen außer Kraft setzen. Es gibt wahrscheinlich noch einige andere Schalter, die ich nicht kenne. Und natürlich gibt es die vielen Einschränkungen, die den direkten Pfad verhindern – Trigger, Fremdschlüssel, Cluster, indexorganisierte Tabellen usw.
Noch restriktiver sind die Regeln für Indizes. Ein Index wird immer REDO während DML-Anweisungen generieren. Nur DDL-Anweisungen wie CREATE INDEX ... NOLOGGING oder ALTER INDEX ... REBUILD auf einem NOLOGGING-Index generiert kein REDO.
Warum gibt es so viele Möglichkeiten? Weil die Wiederherstellbarkeit unglaublich wichtig ist und verschiedene Rollen unterschiedliche Ansichten zu dieser Angelegenheit haben können. Und manchmal müssen die Entscheidungen einiger Leute andere außer Kraft setzen.
Entwickler Entscheiden Sie auf der Anweisungsebene "Einfügemodus". Mit einem /*+ APPEND */ können viele seltsame Dinge passieren Hinweis und Entwickler müssen sorgfältig auswählen, wann sie ihn verwenden.
Architekten Entscheiden Sie sich auf Objektebene für den „Tabellenmodus“. Einige Tabellen müssen immer wiederherstellbar sein, unabhängig davon, wie schnell ein Entwickler sie einfügen möchte.
Datenbankadministratoren Entscheiden Sie sich für den Datenbank- oder Tablespace-Modus, "Archive log" und FORCE LOGGING. Vielleicht kümmert sich die Organisation einfach nicht darum, eine bestimmte Datenbank wiederherzustellen, also setzen Sie sie auf den NOARCHIVELOG-Modus. Oder vielleicht hat die Organisation eine strenge Regel, dass alles wiederherstellbar sein muss, also setzen Sie den Tablespace auf FORCE LOGGING.
