CACHE
For data that is accessed frequently, this clause indicates that the blocks retrieved for this table
are placed at the most recently used end of the least recently used (LRU) list in the buffer cache when
a full table scan is performed. This attribute is useful for small lookup tables.

NOCACHE
For data that is not accessed frequently, this clause indicates that the blocks retrieved for this table
are placed at the least recently used end of the LRU list in the buffer cache when a full table scan is
performed. NOCACHE is the default for LOB storage.

As a parameter in the LOB_storage_clause, NOCACHE specifies that the LOB value either is not brought into
the buffer cache or is brought into the buffer cache and placed at the least recently used end of the LRU
list. The latter is the default behavior.

The number of lists maintained on a table that can be
used to identify a block available for insert. Set this to 1 on all tables except those
receiving very large numbers of simultaneous inserts. When a process requests a free list,
it uses a 'hashing' function to select which free list based on the process id. Using
a prime number with such mechanisms usually reduces the number of collisions that occur if
the input is randomly distributed. Therefore, if you need more than one free list make the
number of lists a prime number (for example 1, 2, 3, 5, 7, 11, 13, 17, 19, 23, .... for
optimal performance).

Oracle ignores a setting of FREELISTS if the tablespace in which the object resides is in automatic segment-space management mode.

The number of groups of free lists for the database object you are creating. The database uses the instance number of Oracle Real Application Cluster instances to map each instance to one free list group.

This parameter is ignored for objects created in locally managed tablespaces with segment space management specified as AUTO.

In a tablespace that is specified as EXTENT MANAGEMENT LOCAL. The database uses the value of INITIAL in conjunction with the extent size for the tablespace to determine the initial amount of space to reserve for the object. For example, in a uniform locally managed tablespace with 5M extents, if you specify an INITIAL value of 1M, then the database must allocate one 5M extent, because that is the uniform size of extents for the tablespace. If the extent size of the tablespace is smaller than the value of INITIAL, then the initial amount of space allocated will in fact be more than one extent.
INITIAL <integer> <K | M | G>

Specifies the number of DML transaction entries for
which space is initially reserved in the data block header. Space is reserved in the
headers of all data blocks in the associated segment.

Oracle uses control information stored in the data block to indicates which rows in the
block contain committed and uncommitted changes. In a sense, the block contains a recent
history of transactions that affected each row in the block. The amount of history that is
retained is controlled by the INITRANS parameter of CREATETABLE and ALTERTABLE.

Under some circumstances, Oracle can have insufficient history information to determine
whether a row has been updated by a "too recent" transaction. This can occur
when many transactions concurrently modify the same data block, or do so in a very short
period. You can avoid this situation by setting higher values of INITRANS for tables that
will experience many transactions updating the same blocks. Doing so enables Oracle to
allocate sufficient storage in each block to record the history of recent transactions
that accessed the block.

Specify whether the creation of the table and of any indexes required because of constraints, partition, or LOB storage characteristics will be logged in the redo log file (LOGGING) or not
(NOLOGGING). The logging attribute of the table is independent of that of its indexes.

This attribute also specifies whether subsequent direct loader (SQL*Loader) and direct-path INSERT operations against the table, partition, or LOB storage are logged (LOGGING) or not logged
(NOLOGGING).

Once the space reserved by INITRANS is depleted,
space for additional transaction entries is allocated out of the free space in a block, if
available. Once allocated, this space effectively becomes a permanent part of the block
header. The MAXTRANS parameter limits the number of transaction entries that can
concurrently use data in a data block. Therefore, you can limit the amount of free space
that can be allocated for transaction entries in a data block using
MAXTRANS.

The total number of extents to be allocated when the
segment is created. This allows for a large allocation of space at creation time, even if
contiguous space is not available.

In a tablespace that is specified as EXTENT MANAGEMENT LOCAL, MINEXTENTS is used only to compute the initial amount of space that is allocated. The initial amount of space that is allocated and is equal to INITIAL * MINEXTENTS. Thereafter it is set to 1 for these tablespaces. (as seen in the DBA_SEGMENTS view).

Specify PARALLEL if you want Oracle to select a degree of parallelism equal to the number of CPUs available on all participating instances times the value of the PARALLEL_THREADS_PER_CPU initialization parameter.

Specify NOPARALLEL, the default, for serial execution.

<PARALLEL | NOPARALLEL>

For this to be optimally effective
the table should be distributed among multiple datafiles.

Determines when a used block is removed from the list
of available blocks. When a block is removed from the list ... no more data is written to
it so that when records are updated there is room for the data in the block ... thus no
chained rows.

Tables on which there are no updates should have PCTFREE set to 0. The default value of 10
leaves 90% of each block empty.

Determines when a used block is re-added to the list
of available blocks. When deletes take place and the room available in a block falls below
this value ... the block is made available for new inserts to take place.

Tables on which there are no updates should have PCTUSED set to 99. The default value is
40% which means that blocks are available for insertion when they are less than 40% full.

Row chaining occurs when a row can no longer fit into its original block. If
the entire row can fit in a new block, the row is moved completely, leaving only a forwarding pointer - this is known as
row migration. If the row has grown so large that it may not fit in a single block then the row is split into two or more
blocks - row chaining. When Oracle is forced to split a row into pieces, it often splits indiviDUAL columns into one or
more pieces.

This clause lets you specify whether table will use row-level dependency
tracking. With this feature, each row in the table has a system change number (SCN) that represents a time greater than
or equal to the commit time of the last transaction that modified the row. You cannot change this setting after table is created.

The row_movement_clause specifies whether the database can move a table row. It is possible for a row to move, for example, during table compression or an update operation on partitioned data.
The default is to disable row movement.

The table_compression clause is valid only for heap-organized tables. Use
this clause to instruct the database whether to compress data segments to reduce disk use. This clause is especially
useful in environments such as data warehouses, where the amount of insert and update operations is small. The COMPRESS
keyword enables table compression. The NOCOMPRESS keyword disables table compression. NOCOMPRESS is the default.

When you enable table compression, Oracle Database attempts to compress data during direct-path INSERT operations when
it is productive to do so. The original import utility (imp) does not support direct-path INSERT, and therefore cannot
import data in a compressed format. You can specify table compression for the following portions of a heap-organized table.

For an entire table, in the physical_properties clause of relational_table or object_table

For a range partition, in the table_partition_description of the range_partitioning clause

For a list partition, in the table_partition_description of the list_partitioning clause

For the storage table of a nested table, in the nested_table_col_properties clause

Table compression saves disk space and
reduces memory use in the buffer cache, and is completely transparent to
applications. Compression ratios as high as 3.5 : 1 can be achieved.
Table compression can also speed up query execution during reads. There
is, however, a cost in CPU overhead for DML.

Valid only for segments in tablespaces with automatic segment management.
Row movement must be enabled.

COMPACT defragments the segment space and compacts the table rows for subsequent release.
COMPACT does not readjust the high water mark and does not release the space immediately.
CASCADE performs the same operations on all dependent objects.