Oacle 의 nologging

공식 적 으로 이렇게 말 했다.
Controlling the Writing of Redo Records
For some database operations, you can control whether the database generates redo records. Without redo, no media recovery is possible. However, suppressing redo generation can improve performance, and may be appropriate for easily recoverable operations. An example of such an operation is a  CREATE TABLE...AS SELECT  statement, which can be repeated in case of database or instance failure.
Specify the  NOLOGGING  clause in the  CREATE TABLESPACE  statement to suppress redo when these operations are performed for objects within the tablespace. If you do not include this clause, or if you specify  LOGGING  instead, then the database generates redo when changes are made to objects in the tablespace. Redo is never generated for temporary segments or in temporary tablespaces, regardless of the logging attribute.
The logging attribute specified at the tablespace level is the default attribute for objects created within the tablespace. You can override this default logging attribute by specifying  LOGGING  or  NOLOGGING at the schema object level--for example, in a  CREATE TABLE  statement.
If you have a standby database,  NOLOGGING  mode causes problems with the availability and accuracy of the standby database. To overcome this problem, you can specify  FORCE LOGGING  mode. When you include the  FORCE LOGGING  clause in the  CREATE TABLESPACE  statement, you force the generation of redo records for all operations that make changes to objects in a tablespace. This overrides any specification made at the object level.
If you transport a tablespace that is in  FORCE LOGGING  mode to another database, the new tablespace will not maintain the  FORCE LOGGING  mode.
Conventional and Direct-Path INSERT
You can use the  INSERT  statement to insert data into a table, partition, or view in two ways: conventional  INSERT  and direct-path  INSERT . When you issue a conventional  INSERT  statement, Oracle Database reuses free space in the table into which you are inserting and maintains referential integrity constraints. With direct-path  INSERT , the database appends the inserted data after existing data in the table. Data is written directly into data files, bypassing the buffer cache. Free space in the existing data is not reused. This alternative enhances performance during insert operations and is similar to the functionality of the Oracle direct-path loader utility, SQL*Loader. When you insert into a table that has been created in parallel mode, direct-path  INSERT  is the default.
The manner in which the database generates redo and undo data depends in part on whether you are using conventional or direct-path  INSERT :

Conventional  INSERT  always generates maximal redo and undo for changes to both data and metadata, regardless of the logging setting of the table and the archivelog and force logging settings of the database.

Direct-path  INSERT  generates both redo and undo for metadata changes, because these are needed for operation recovery. For data changes, undo and redo are generated as follows:

Direct-path  INSERT  always bypassesundo generation for data changes.

If the database is not in  ARCHIVELOG  or  FORCE   LOGGING  mode, then no redo is generated for data changes, regardless of the logging setting of the table.

If the database is in  ARCHIVELOG  mode (but not in  FORCE   LOGGING  mode), then direct-path  INSERT  generates data redo for  LOGGING  tables but not for  NOLOGGING  tables.

If the database is in  ARCHIVELOG  and  FORCE   LOGGING  mode, then direct-path SQL generate data redo for both  LOGGING  and  NOLOGGING  tables.

Direct-path  INSERT  is subject to a number of restrictions. If any of these restrictions is violated, then Oracle Database executes conventional  INSERT  serially without returning any message, unless otherwise noted:

You can have multiple direct-path  INSERT  statements in a single transaction, with or without other DML statements. However, after one DML statement alters a particular table, partition, or index, no other DML statement in the transaction can access that table, partition, or index.

Queries that access the same table, partition, or index are allowed before the direct-path  INSERT  statement, but not after it.

If any serial or parallel statement attempts to access a table that has already been modified by a direct-path  INSERT  in the same transaction, then the database returns an error and rejects the statement.

The target table cannot be of a cluster.

The target table cannot contain object type columns.

Direct-path  INSERT  is not supported for an index-organized table (IOT) if it is not partitioned, if it has a mapping table, or if it is reference by a materialized view.

Direct-path  INSERT  into a single partition of an index-organized table (IOT), or into a partitioned IOT with only one partition, will be done serially, even if the IOT was created in parallel mode or you specify the  APPEND  or  APPEND_VALUES  hint. However, direct-path  INSERT  operations into a partitioned IOT will honor parallel mode as long as the partition-extended name is not used and the IOT has more than one partition.

The target table cannot have any triggers or referential integrity constraints defined on it.

The target table cannot be replicated.

A transaction containing a direct-path  INSERT  statement cannot be or become distributed.

You cannot query or modify direct-path inserted data immediately after the insert is complete. If you attempt to do so, an  ORA-12838  error is generated. You must first issue a  COMMIT  statement before attempting to read or modify the newly-inserted data.
See Also:

Oracle Database Administrator's Guide for a more complete description of direct-path  INSERT

Oracle Database Utilities for information on SQL*Loader

Oracle Database Performance Tuning Guide for information on how to tune parallel direct-path  INSERT

요약:
1. Nologging 은 대상 의 속성 입 니 다. 이 대상 에 대해 서 만 Nologging 또는 Logging 속성 을 설정 할 수 있 습 니 다. 한 문 구 를 동적 으로 설정 할 수 없 을 때 Nologging 또는 Logging 을 사용 합 니 다. Nologging 은 DATABASE 등급 일 수도 있 고 TABLESPACE 등급 일 수도 있 으 며 TABLE 등급 일 수도 있 습 니 다. "CREATE DATABASE", "CREATE TABLESPACE", "CREATE TABLE"동시에 이 속성 을 지정 할 수 있 지만 이 속성의 최종 작용 대상 은 table 또는 index 입 니 다.
2. Force Logging 속성 이 열 리 면 다른 속성 이 덮어 쓰 이 며, 이 때 REDO 정 보 를 강제로 씁 니 다.
3. Nologging 의 최종 역할 대상 은 table 또는 index 입 니 다. 최종 적 으로 효과 가 나타 나 는 작업 은 "Direct - Path insert" 입 니 다. 다른 작업, 예 를 들 어 "update, delete" 는 모두 유효 하지 않 습 니 다.