Wann auch immer ein INSERT oder eine Bulk Load Operation auf einer Datenbank durchgeführt werden, werden auch Redo und Undo Blöcke erstellt. Durch die NOLOGGING Option werden weniger Redo Blöcke durch die entsprechende Operation geschrieben.
Wann sind NOLOGGING Operationen sinnvoll:
- Die Performance von großen Insert Operationen zu verbessern
- Die Erstellungszeiten von großen Indizies zu verbessern
- Die Erstellungszeiten von großen Tabellen zu verbessern (CTAS)
- Die Menge von Redo I/O und in weiterer folge die Anzahl von Archivelog Dateien zu reduzieren
Welche Operationen können NOLOGGING nutzen?
Create Table As Select (CTAS)
- ALTER TABLE Operationen
- ALTER TABLE statements (add/move/merge/split partitions)
- INSERT /*+APPEND*/
- CREATE INDEX
- ALTER INDEX statements (add/move/merge/split partitions)
Beispiele von NOLOGGING Operationen
NOLOGGING ist entweder ein Objekt Parameter der auf Partition => Tabellen => LOB Storage => Index gesetzt wird oder bei der Erstellung durch ALTER oder CREATE Befehle gesetzt wird.
Die NOLOGGING Option bei einem ALTER TABLESPACE Befehl bestimmt den Default Wert der Objekte, die in diesem Tablespace erstellt werden.
SQL> create table big_emp nologging as select * from emp;
SQL> insert /*+ APPEND */ into emp select * from big_emp;
SQL> create index emp_no on emp(ename) nologging;
UNRECOVERABLE Option im SQL Loader Controlfile
Hinweis: Update Operationen können nicht mit NOLOGGING ausgeführt werden.
Warum wird trotzdem REDO erzeugt?
Eine oft getroffene Annahme ist, dass NOLOGGING Operationen keinen REDO Stream erzeugen, was aber leider nicht korrekt ist.
Oracle erzeugt trotzdem für alle Data Dictionary Änderungen REDO Blöcke, um dieses für das Media Recovery zu schützen. Weiters darf man nicht vergessen, dass die NOLOGGING Operation sich auf die Tabelle bezieht, nicht aber für Indexe die auf dem Segment angelegt sind.
Auch werden Meta Informationen (Commit Records, etc) weiter in den REDO Stream geschrieben.
REDO oder doch UNDO?
Weitere Verwirrung erzeugt das Gerücht, dass NOLOGGING auch weniger UNDO Blöcke erzeugt, was aber nicht stimmt. Wie der Name schon sagt, bezieht sich NOLOGGING auf REDO.
Richtig ist daher, dass durch Direct Path Operationen die Daten direkt in die Datendateien geschrieben werden und damit auch der UNDO umgangen wird.
Nachteile von NOLOGGING Operationen
Entwickler nutzen dieses Feature gerne um die Performance ihrer Applikation zu verbessern. Jedoch übersehen sie dabei oft, dass die Information nicht in die Redo Log Dateien geschrieben werden. Dadurch sind alle Prozesse einer Datenbank betroffen, welche auf die Redo bzw. Archivelog Dateien zugreifen.
Als Beispiel sind die betroffenen Objekte nur eingeschränkt oder gar nicht aus einem Backup wieder herstellbar. Meistens fällt dieser Umstand einem DBA erst dann auf, wenn er auf sein Backup angewiesen ist. Auch Standby Datenbanken oder Oracle Streams können diese Objekte nicht wiederherstellen bzw. replizieren. Aus diesem Grund müssen Datenbank Administratoren NOLOGGING Operationen im Auge behalten um sicher zu stellen, dass nur logisch wieder herstellbare Objekte davon betroffen sind.
Datafiles, welche NOLOGGING Objekte beinhalten und nicht logisch wieder herstellbar sind, sollten nach Abschluss der NOLOGGING Operation gesichert werden, da ein Media Recovery nur eingeschränkt möglich ist.
Verhindern von NOLOGGING Operationen
Datenbank Ebene:
Auf Datenbank Ebene kann die FORCE LOGGING Option verwendet werden.
SQL> ALTER DATABASE {NO} FORCE LOGGING;
SQL> select FORCE_LOGGING from v$database;
FORCE_LOGGING
—————————————
NO
Tablespace Ebene:
Auf Tablespace Ebene kann wie auf Datenbank Ebene die FORCE LOGGING Option verwendet werden.
SQL> ALTER TABLESPACE users {NO} FORCE LOGGING;
SQL> SELECT tablespace_name, force_logging FROM dba_tablespaces;
TABLESPACE_NAME FOR
—————————— —
SYSTEM YES
…
Objekt Ebene:
Auf Objekt Ebene wird die LOGGING Option verwendet.
SQL> ALTER TABLE emp {NO}LOGGING;
Eine FORCE LOGGING Option auf einer höheren Ebene übersteuert immer die NOLOGGING Option auf einer daraunter liegenden Ebene. So können Objekte in einem Tablespace mit FORCE LOGGING nicht mit NOLOGGING geladen werden.
NOLOGGING Operationen Überwachen
Ein einfacher Test um zu prüfen ob eine Datenbank betroffen ist, ist die v$datafile abzufragen. Ist der Datenbank Parameter DB_UNRECOVERABLE_SCN_TRACKING auf FALSE gestellt, führt dies dazu, dass Unrecoverable Informationen nicht mehr in das Controlfile geschrieben werden, was einen zusätzlichen Performance Gewinn bringt. Ist dieser Wert auf FALSE, ist auch der View v$datafile betroffen.
SELECT NAME, UNRECOVERABLE_CHANGE#,
TO_CHAR (UNRECOVERABLE_TIME,’DD.MON.YYYY HH:MI:SS‘)
FROM V$DATAFILE;
Für weiterführende Unterstützung im Bereich Oracle Datenbank Administration steht unser Remote Oracle DBA Service zur Verfügung.
