From the Oracle9i Data Warehousing Guide manual:

[NO]LOGGING Clause
The [NO]LOGGING clause applies to tables, partitions, tablespaces, and indexes.
Virtually no log is generated for certain operations (such as direct-path INSERT) if
the NOLOGGING clause is used. The NOLOGGING attribute is not specified at the
INSERT statement level but is instead specified when using the ALTER or CREATE
statement for a table, partition, index, or tablespace.
When a table or index has NOLOGGING set, neither parallel nor serial direct-path
INSERT operations generate undo or redo logs. Processes running with the
NOLOGGING option set run faster because no redo is generated. However, after a
NOLOGGING operation against a table, partition, or index, if a media failure occurs
before a backup is taken, then all tables, partitions, and indexes that have been
modified might be corrupted.
Note:
Direct-path INSERT operations (except for dictionary updates) never generate undo
logs. The NOLOGGING attribute does not affect undo, only redo. To be precise,
NOLOGGING allows the direct-path INSERT operation to generate a negligible
amount of redo (range-invalidation redo, as opposed to full image redo).
For backward compatibility, [UN]RECOVERABLE is still supported as an alternate
keyword with the CREATE TABLE statement. This alternate keyword might not be
supported, however, in future releases.
At the tablespace level, the logging clause specifies the default logging attribute for
all tables, indexes, and partitions created in the tablespace. When an existing
tablespace logging attribute is changed by the ALTER TABLESPACE statement, then
all tables, indexes, and partitions created after the ALTER statement will have the
new logging attribute; existing ones will not change their logging attributes. The
tablespace-level logging attribute can be overridden by the specifications at the
table, index, or partition level.
The default logging attribute is LOGGING. However, if you have put the database in
NOARCHIVELOG mode, by issuing ALTER DATABASE NOARCHIVELOG, then all
operations that can be done without logging will not generate logs, regardless of the
specified logging attribute.
Creating Indexes in Parallel
Multiple processes can work together simultaneously to create an index. By dividing
the work necessary to create an index among multiple server processes, Oracle can
create the index more quickly than if a single server process created the index

sequentially.
Parallel index creation works in much the same way as a table scan with an ORDER
BY clause. The table is randomly sampled and a set of index keys is found that
equally divides the index into the same number of pieces as the DOP. A first set of
query processes scans the table, extracts key-rowid pairs, and sends each pair to a
process in a second set of query processes based on key. Each process in the
second set sorts the keys and builds an index in the usual fashion. After all index
pieces are built, the parallel coordinator simply concatenates the pieces (which are
ordered) to form the final index.
Parallel local index creation uses a single server set. Each server process in the set
is assigned a table partition to scan and for which to build an index partition.
Because half as many server processes are used for a given DOP, parallel local
index creation can be run with a higher DOP.
You can optionally specify that no redo and undo logging should occur during index
creation. This can significantly improve performance but temporarily renders the
index unrecoverable. Recoverability is restored after the new index is backed up. If
your application can tolerate a window where recovery of the index requires it to be
re-created, then you should consider using the NOLOGGING clause.
The PARALLEL clause in the CREATE INDEX statement is the only way in which you
can specify the DOP for creating the index. If the DOP is not specified in the parallel
clause of CREATE INDEX, then the number of CPUs is used as the DOP. If there is no
PARALLEL clause, index creation is done serially.
Note:
When creating an index in parallel, the STORAGE clause refers to the storage of
each of the subindexes created by the query server processes. Therefore, an index
created with an INITIAL of 5 MB and a DOP of 12 consumes at least 60 MB of storage
during index creation because each process starts with an extent of 5 MB. When the
query coordinator process combines the sorted subindexes, some of the extents
might be trimmed, and the resulting index might be smaller than the requested 60
MB.
When you add or enable a UNIQUE or PRIMARY KEY constraint on a table, you
cannot automatically create the required index in parallel. Instead, manually create
an index on the desired columns, using the CREATE INDEX statement and an
appropriate PARALLEL clause, and then add or enable the constraint. Oracle then
uses the existing index when enabling or adding the constraint.
Multiple constraints on the same table can be enabled concurrently and in parallel if
all the constraints are already in the ENABLE NOVALIDATE state. In the following

example, the ALTER TABLE ... ENABLE CONSTRAINT statement performs the table
scan that checks the constraint in parallel:
CREATE TABLE a (a1 NUMBER CONSTRAINT ach CHECK (a1 > 0) ENABLE
NOVALIDATE)
PARALLEL;
INSERT INTO a values (1);
COMMIT;
ALTER TABLE a ENABLE CONSTRAINT ach;