Oracle8i SQL Reference
Release 2 (8.1.6)

A76989-01

Library

Product

Contents

Index

Prev Up Next

SQL Statements (continued), 2 of 11


ALTER TABLE

Syntax



add_column_options::=


column_constraint, table_constraint, column_ref_constraint, table_ref_constraint, constraint_state: See the "constraint_clause".

LOB_storage_clause::=


LOB_parameters::=


storage_clause: See "storage_clause".

varray_storage_clause::=


nested_table_storage_clause::=


object_properties::=


physical_properties::=


partition_storage_clause::=


modify_column_options::=


move_table_clause::=


segment_attributes_clause::=


physical_attributes_clause::=


index_organized_table_clause::=


compression_clause::=


index_organized_overflow_clause::=


modify_collection_retrieval_clause::=


modify_storage_clauses::=


modify_LOB_storage_clause::=


modify_LOB_storage_parameters::=


allocate_extent_clause::=


deallocate_unused_clause::=


modify_varray_storage_clause::=


drop_constraint_clause::=


drop_column_clause::=


records_per_block_clause::=


alter_overflow_clause::=


overflow_clause::=


add_overflow_clause::=


partitioning_clauses::=


modify_default_attributes_clause::=


modify_partition_clause::=


partition_attributes::=


add_subpartition_clause::=


subpartition_description::=


modify_subpartition_clause::=


move_partition_clause::=


partition_description::=


partition_level_subpartitioning::=


hash_partitioning_storage_clause::=


move_subpartition_clause::=



add_range_partition_clause::=


add_hash_partition_clause::=


coalesce_partition_clause::=


drop_partition_clause::=


rename_partition/ subpartition_clause::=


truncate_partition_clause/truncate_subpartition_clause::=


split_partition_clause::=


merge_partitions_clause::=


exchange_partition_clause/exchange_subpartition_clause::=


row_movement_clause::=


parallel_clause::=


enable_disable_clause::=


using_index_clause::=


Purpose

To alter the definition of a nonpartitioned table, a partitioned table, a table partition, or a table subpartition.

Prerequisites

The table must be in your own schema, or you must have ALTER privilege on the table, or you must have ALTER ANY TABLE system privilege. For some operations you may also need the CREATE ANY INDEX privilege.

In addition, if you are not the owner of the table, you need the DROP ANY TABLE privilege in order to use the drop_partition_clause or truncate_partition_clause.

You must also have space quota in the tablespace in which space is to be acquired in order to use the add_partition_clause, modify_partition_clause, move_partition_clause, and split_partition_clause.

To enable a UNIQUE or PRIMARY KEY constraint, you must have the privileges necessary to create an index on the table. You need these privileges because Oracle creates an index on the columns of the unique or primary key in the schema containing the table. See "CREATE INDEX".

To enable or disable triggers, the triggers must be in your schema or you must have the ALTER ANY TRIGGER system privilege.

To use an object type in a column definition when modifying a table, either that object must belong to the same schema as the table being altered, or you must have either the EXECUTE ANY TYPE system privilege or the EXECUTE schema object privilege for the object type.

Keywords and Parameters

The clauses described below have specialized meaning in the ALTER TABLE statement. For descriptions of the remaining keywords, see "CREATE TABLE"

Note: Operations performed by the ALTER TABLE statement can cause Oracle to invalidate procedures and stored functions that access the table. For information on how and when Oracle invalidates such objects, see Oracle8i Concepts

schema 

is the schema containing the table. If you omit schema, Oracle assumes the table is in your own schema.  

table 

is the name of the table to be altered.  

 

You can modify, or drop columns from, or rename a temporary table. However, for a temporary table, you cannot:

  • Add columns of nested-table or varray type. You can add columns of other types.

  • Specify referential integrity (foreign key) constraints for an added or modified column

 

 

  • Specify the following clauses of the LOB_storage_clause for an added or modified LOB column: TABLESPACE, storage_clause, LOGGING|NOLOGGING, or the LOB_index_clause.

  • Specify the physical_attribute_clause, nested_table_storage_clause, parallel_clause, allocate_extent_clause, deallocate_unused_clause, or any of the index-organized table clauses

 

 

  • Exchange partitions between a partition and a temporary table

  • Specify LOGGING or NOLOGGING

  • Specify MOVE

 

 

Note: If you alter a table that is a master table for one or more materialized views, the materialized views are marked INVALID. Invalid materialized views cannot be used by query rewrite and cannot be refreshed. To revalidate a materialized view, see "ALTER MATERIALIZED VIEW / SNAPSHOT".

See Also: Oracle8i Data Warehousing Guide for more information on materialized views in general. 

ADD

add_column_options  

adds a column or integrity constraint. For a description of the keywords and parameters of this clause, see "CREATE TABLE".

If you add a column, the initial value of each row for the new column is null unless you specify the DEFAULT clause. In this case, Oracle updates each row in the new column with the value you specify for DEFAULT. This update operation, in turn, fires any AFTER UPDATE triggers defined on the table.

You can add an overflow data segment to each partition of a partitioned index-organized table.

You can add LOB columns to nonpartitioned and partitioned tables. You can specify LOB storage at the table and at the partition or subpartition level.

If you previously created a view with a query that used the "SELECT *" syntax to select all columns from table, and you now add a column to table, Oracle does not automatically add the new column to the view. To add the new column to the view, re-create the view using the CREATE VIEW statement with the OR REPLACE clause. See "CREATE VIEW"

 

Restrictions:

  • You cannot add a LOB column to a partitioned index-organized table. (This restriction does not apply to nonpartitioned index-organized tables.)

  • You cannot add a column with a NOT NULL constraint if table has any rows unless you also specify the DEFAULT clause.

  • If you specify this clause for an index-organized table, you cannot specify any other clauses in the same statement.

 

 

DEFAULT 

specifies a default for a new column or a new default for an existing column. Oracle assigns this value to the column if a subsequent INSERT statement omits a value for the column. If you are adding a new column to the table and specify the default value, Oracle inserts the default column value into all rows of the table.  

 

 

The datatype of the default value must match the datatype specified for the column. The column must also be long enough to hold the default value. A DEFAULT expression cannot contain references to other columns, the pseudocolumns CURRVAL, NEXTVAL, LEVEL, and ROWNUM, or date constants that are not fully specified.  

 

table_ref_constraint

column_ref_constraint

 

These clauses let you further describe a column of type REF. The only difference between these clauses is that you specify table_ref from the table level, so you must identify the REF column or attribute you are defining. You specify column_ref after you have already identified the REF column or attribute.

For syntax and description of these constraints, including restrictions, see the "constraint_clause"

 

column_constraint 

adds or removes a NOT NULL constraint to or from an existing column. You cannot use this clause to modify any other type of constraint using ALTER TABLE. See the "constraint_clause"

 

table_constraint 

adds or modifies an integrity constraint on the table. See the "constraint_clause".  

LOB_storage_clause 

specifies the LOB storage characteristics for the newly added LOB column. You cannot use this clause to modify an existing LOB column. Instead, you must use the modify_LOB_storage_clause

 

Restrictions:

  • The only parameter of LOB_parameters you can specify for a hash partition or hash subpartition is TABLESPACE.

  • You cannot specify the LOB_index_clause if table is partitioned.

 

 

lob_item 

is the LOB column name or LOB object attribute for which you are explicitly defining tablespace and storage characteristics that are different from those of the table. 

 

lob_segname 

specifies the name of the LOB data segment. You cannot use lob_segname if more than one lob_item is specified.  

 

ENABLE | DISABLE STORAGE IN ROW 

specifies whether the LOB value is stored in the row (inline) or outside of the row. (The LOB locator is always stored in the row regardless of where the LOB value is stored.)

  • ENABLE specifies that the LOB value is stored inline if its length is less than approximately 4000 bytes minus system control information. This is the default.

  • DISABLE specifies that the LOB value is stored outside of the row regardless of the length of the LOB value.

Restriction: You cannot change STORAGE IN ROW once it is set. Therefore, you can specify this clause only as part of the add_column_options clause, not as part of the modify_column_options clause. 

 

CHUNK integer 

specifies the number of bytes to be allocated for LOB manipulation. If integer is not a multiple of the database block size, Oracle rounds up (in bytes) to the next multiple. For example, if the database block size is 2048 and integer is 2050, Oracle allocates 4096 bytes (2 blocks).The maximum value is 32768 (32 K), which is the largest Oracle block size allowed. The default CHUNK size is one Oracle database block.

You cannot change the value of CHUNK once it is set. 

 

 

Note: The value of CHUNK must be less than or equal to the value of NEXT (either the default value or that specified in the storage clause). If CHUNK exceeds the value of NEXT, Oracle returns an error. 

 

PCTVERSION integer 

is the maximum percentage of overall LOB storage space used for creating new versions of the LOB. The default value is 10, meaning that older versions of the LOB data are not overwritten until 10% of the overall LOB storage space is used. 

 

LOB_index_clause 

This clause is deprecated as of Oracle8i. Oracle generates an index for each LOB column. The LOB indexes are system named and system managed, and reside in the same tablespace as the LOB data segments.

It is still possible for you to specify this clause in some cases. However, Oracle Corporation strongly recommends that you no longer do so.

For information on how Oracle manages LOB indexes in tables migrated from earlier versions, see Oracle8i Migration. 

varray_storage_clause 

lets you specify separate storage characteristics for the LOB in which a varray will be stored. In addition, if you specify this clause, Oracle will always store the varray in a LOB, even if it is small enough to be stored inline.

Restriction: You cannot specify the TABLESPACE clause of LOB_parameters as part of this clause. The LOB tablespace for a varray defaults to the containing table's tablespace. 

nested_table_storage_clause 

enables you to specify separate storage characteristics for a nested table, which in turn enables you to define the nested table as an index-organized table. You must include this clause when creating a table with columns or column attributes whose type is a nested table. (Clauses within this clause that function the same way they function for parent object tables are not repeated here.) 

 

Restrictions:

  • You cannot specify the parallel_clause.

  • You cannot specify TABLESPACE (as part of the segment_attributes_clause) for a nested table. The tablespace is always that of the parent table.

 

 

nested_item 

is the name of a column (or a top-level attribute of the table's object type) whose type is a nested table. 

 

storage_table 

is the name of the table where the rows of nested_item reside. The storage table is created in the same schema and the same tablespace as the parent table.  

partition_storage_clause 

lets you specify a separate LOB_storage_clause or varray_storage_clause for each partition. You must specify the partitions in the order of partition position.

If you do not specify a LOB_storage_clause or varray_storage_clause for a particular partition, the storage characteristics are those specified for the LOB item at the table level. If you also did not specify any storage characteristics at the table level for the LOB item, Oracle stores the LOB data partition in the same tablespace as the table partition to which it corresponds.

Restriction: You can specify only one list of partition_storage_clauses per ALTER TABLE statement, and all LOB_storage_clauses and varray_storage_clauses must precede the list of partition_storage_clauses. 

MODIFY

modify_column_options 

modifies the definition of an existing column. If you omit any of the optional parts of the column definition (datatype, default value, or column constraint), these parts remain unchanged.

  • You can change a CHAR column to VARCHAR2 (or VARCHAR) and a VARCHAR2 (or VARCHAR) to CHAR only if the column contains nulls in all rows or if you do not attempt to change the column size.

  • You can change any column's datatype or decrease any column's size if all rows for the column contain nulls.

  • You can always increase the size of a character or raw column or the precision of a numeric column, whether or not all the columns contain nulls.

 

 

Restrictions:

  • You cannot modify the datatype or length of a column that is part of a table or index partitioning or subpartitioning key.

  • You cannot modify the definition of a column on which a domain index has been built.

  • If you specify this clause for an index-organized table, you cannot specify any other clauses in the same statement.

 

 

column 

is the name of the column to be added or modified.

The only type of integrity constraint that you can add to an existing column using the MODIFY clause with the column constraint syntax is a NOT NULL constraint, and only if the column contains no nulls. To define other types of integrity constraints (UNIQUE, PRIMARY KEY, referential integrity, and CHECK constraints) on existing columns, using the ADD clause and the table constraint syntax.  

 

datatype 

specifies a new datatype for an existing column.

You can omit the datatype only if the statement also designates the column as part of the foreign key of a referential integrity constraint. Oracle automatically assigns the column the same datatype as the corresponding column of the referenced key of the referential integrity constraint.

If you change the datatype of a column in a materialized view container table, the corresponding materialized view is invalidated. To revalidate a materialized view, see "ALTER MATERIALIZED VIEW / SNAPSHOT"

 

 

Restrictions:

  • You cannot specify a column of datatype ROWID for an index-organized table, but you can specify a column of type UROWID.

  • You cannot change a column's datatype to LOB or REF.

 

MODIFY CONSTRAINT constraint 

modifies the state of an existing constraint named constraint. For a description of all the keywords and parameters of constraint_state, see the "constraint_clause"

move_table_clause

 

For a heap-organized table, use the segment_attributes_clause of the syntax. The move_table_clause lets you relocate data of a nonpartitioned table into a new segment, optionally in a different tablespace, and optionally modify any of its storage attributes.

You can also move any LOB data segments associated with the table using the LOB_storage_clause. (LOB items not specified in this clause are not moved.) 

 

For an index-organized table, use the index_organized_table_clause of the syntax. The move_table_clause rebuilds the index-organized table's primary key index B*-tree. The overflow data segment is not rebuilt unless the OVERFLOW keyword is explicitly stated, with two exceptions:

  • If you alter the values of PCTTHRESHOLD or the INCLUDING column as part of this ALTER TABLE statement, the overflow data segment is rebuilt.

  • If any of out-of-line columns (LOBs, varrays, nested table columns) in the index-organized table are moved explicitly, then the overflow data segment is also rebuilt.

The index and data segments of LOB columns are not rebuilt unless you specify the LOB columns explicitly as part of this ALTER TABLE statement. 

 

ONLINE 

specifies that DML operations on the index-organized table are allowed during rebuilding of the table's primary key index B*-tree.

Restrictions:

  • You can specify this clause only for a nonpartitioned index-organized table.

  • Parallel DML is not supported during online MOVE. If you specify ONLINE and then issue parallel DML statements, Oracle returns an error.

 

 

compression_clause 

enables and disables key compression in an index-organized table. 

 

 

  • COMPRESS enables key compression, which eliminates repeated occurrence of primary key column values in index-organized tables. Use integer to specify the prefix length (number of prefix columns to compress).

    The valid range of prefix length values is from 1 to the number of primary key columns minus 1. The default prefix length is the number of primary key columns minus 1.

    Restrictions:

    - You can specify this clause only for an index-organized table.

    - You can specify compression for a partition of an index-organized table only if compression has been specified at the table level.

 

 

 

  • NOCOMPRESS disables key compression in index-organized tables. This is the default.

 

 

TABLESPACE 

specifies the tablespace into which the rebuilt index-organized table is stored. 

 

Restrictions:

  • If you specify MOVE, it must be the first clause. For an index-organized table, the only clauses outside this clause that are allowed are the physical_attribute_clause and the parallel_clause. For heap-organized tables, you can specify those two clauses and the LOB_storage_clauses.

  • You cannot MOVE an entire partitioned table (either heap or index organized). You must move individual partitions or subpartitions. See "move_partition_clause" and "move_subpartition_clause".

 

 

Notes regarding LOBs:

For any LOB columns you specify in this clause:

  • Oracle drops the old LOB data segment and corresponding index segment and creates new segments, even if you do not specify a new tablespace.

  • If the LOB index in table resided in a different tablespace from the LOB data, Oracle collocates the LOB index with the LOB data in the LOB data's tablespace after the move.

 

physical_attributes_clause 

changes the value of PCTFREE, PCTUSED, INITRANS, and MAXTRANS parameters and storage characteristics. See the PCTFREE, PCTUSED, INITRANS, and MAXTRANS parameters of "CREATE TABLE" and the "storage_clause".

Restriction: You cannot specify the PCTUSED parameter for the index segment of an index-organized table. 

 

WARNING:

  • For a nonpartitioned table, the values you specify override any values specified for the table at create time.

  • For a range- or hash-partitioned table, the values you specify are the default values for the table and the actual values for every existing partition, overriding any values already set for the partitions. To change default table attributes without overriding existing partition values, use the modify_default_attributes_clause.

  • For a composite-partitioned table, the values you specify are the default values for the table and all partitions of the table and the actual values for all subpartitions of the table, overriding any values already set for the subpartitions. To change default partition attributes without overriding existing subpartition values, use the modify_default_attributes_clause with the FOR PARTITION clause.

 

modify_collection_retrieval_clause 

changes what is returned when a collection item is retrieved from the database. 

 

collection_item 

is the name of a column-qualified attribute whose type is nested table or varray. 

 

RETURN AS 

specifies what Oracle returns as the result of a query.

  • LOCATOR specifies that a unique locator for the nested table is returned.

  • VALUE specifies that a copy of the nested table itself is returned.

 

modify_storage_clauses

modify_LOB_storage_clause 

modifies the physical attributes of the LOB lob_item. You can specify only one lob_item for each modify_LOB_storage_clause.

Restrictions:

  • You cannot modify the value of the INITIAL parameter in the storage_clause when modifying the LOB storage attributes.

  • You cannot specify both the allocate_extent_clause and the deallocate_unused_clause in the same statement.

 

modify_varray_storage_clause 

lets you change the storage characteristics of an existing LOB in which a varray is stored.

Restriction: You cannot specify the TABLESPACE clause of LOB_parameters as part of this clause. The LOB tablespace for a varray defaults to the containing table's tablespace. 

drop_constraint_clause 

drops an integrity constraint from the database. Oracle stops enforcing the constraint and removes it from the data dictionary. You can specify only one constraint for each drop_constraint_clause, but you can specify multiple drop_constraint_clauses in one statement. 

 

PRIMARY KEY 

drops the table's PRIMARY KEY constraint. 

 

UNIQUE 

drops the UNIQUE constraint on the specified columns. 

 

CONSTRAINT 

drops the integrity constraint named constraint

 

CASCADE 

drops all other integrity constraints that depend on the dropped integrity constraint. 

 

Restrictions:

  • You cannot drop a UNIQUE or PRIMARY KEY constraint that is part of a referential integrity constraint without also dropping the foreign key. To drop the referenced key and the foreign key together, use the CASCADE clause. If you omit CASCADE, Oracle does not drop the PRIMARY KEY or UNIQUE constraint if any foreign key references it.

  • You cannot drop a primary key constraint (even with the CASCADE clause) on a table that uses the primary key as its object identifier (OID).

  • If you drop a referential integrity constraint on a REF column, the REF column remains scoped to the referenced table.

  • You cannot drop the scope of the column.

 

drop_column_clause 

lets you free space in the database by dropping columns you no longer need, or by marking them to be dropped at a future time when the demand on system resources is less. 

 

SET UNUSED 

marks one or more columns as unused. Specifying this clause does not actually remove the target columns from each row in the table (that is, it does not restore the disk space used by these columns). Therefore, the response time is faster than it would be if you execute the DROP clause. 

 

 

You can view all tables with columns marked as unused in the data dictionary views USER_UNUSED_COL_TABS, DBA_UNUSED_COL_TABS, and ALL_UNUSED_COL_TABS. For information on these views, see Oracle8i Reference

 

 

Unused columns are treated as if they were dropped, even though their column data remains in the table's rows. After a column has been marked as unused, you have no access to that column. A "SELECT *" query will not retrieve data from unused columns. In addition, the names and types of columns marked unused will not be displayed during a DESCRIBE, and you can add to the table a new column with the same name as an unused column. 

 

 

Note: Until you actually drop these columns, they continue to count toward the absolute limit of 1000 columns per table. However, as with all DDL statements, you cannot roll back the results of this clause. That is, you cannot issue SET USED counterpart to retrieve a column that you have SET UNUSED.

Also, if you mark a column of datatype LONG as UNUSED, you cannot add another LONG column to the table until you actually drop the unused LONG column.

See Also: "CREATE TABLE" for more information on the 1000 column limit. 

 

DROP 

removes the column descriptor and the data associated with the target column from each row in the table. If you explicitly drop a particular column, all columns currently marked as unused in the target table are dropped at the same time. 

 

 

When the column data is dropped:

  • All indexes defined on any of the target columns are also dropped.

  • All constraints that reference a target column are removed.

  • If any statistics types are associated with the target columns, Oracle disassociates the statistics from the column with the FORCE option and drops any statistics collected using the statistics type.

See Also: "DISASSOCIATE STATISTICS" for more information on disassociating statistics types. 

 

 

Note: If a constraint also references a nontarget column, Oracle returns an error and does not drop the column unless you have specified the CASCADE CONSTRAINTS clause. If you have specified that clause, Oracle removes all constraints that reference any of the target columns. 

 

DROP UNUSED COLUMNS 

removes from the table all columns currently marked as unused. Use this statement when you want to reclaim the extra disk space from unused columns in the table. If the table contains no unused columns, the statement returns with no errors. 

 

column 

specifies one or more columns to be set as unused or dropped. Use the COLUMN keyword only if you are specifying only one column. If you specify a column list, it cannot contain duplicates. 

 

CASCADE CONSTRAINTS 

drops all referential integrity constraints that refer to the primary and unique keys defined on the dropped columns, and drops all multicolumn constraints defined on the dropped columns. If any constraint is referenced by columns from other tables or remaining columns in the target table, then you must specify CASCADE CONSTRAINTS. Otherwise, the statement aborts and an error is returned. 

 

INVALIDATE 

Note: Currently, Oracle executes this clause regardless of whether you specify the keyword INVALIDATE

 

 

Oracle invalidates all dependent objects, such as views, triggers, and stored program units. Object invalidation is a recursive process. Therefore, all directly dependent and indirectly dependent objects are invalidated. However, only local dependencies are invalidated, because Oracle manages remote dependencies differently from local dependencies.

An object invalidated by this statement is automatically revalidated when next referenced. You must then correct any errors that exist in that object before referencing it.

See Also: Oracle8i Concepts for more information on dependencies. 

 

CHECKPOINT 

specifies that a checkpoint for the drop column operation will be applied after processing integer rows; integer is optional and must be greater than zero. If integer is greater than the number of rows in the table, Oracle applies a checkpoint after all the rows have been processed. If you do not specify integer, Oracle sets the default of 512.  

 

 

Checkpointing cuts down the amount of undo logs accumulated during the drop column operation to avoid running out of rollback segment space. However, if this statement is interrupted after a checkpoint has been applied, the table remains in an unusable state. While the table is unusable, the only operations allowed on it are DROP TABLE, TRUNCATE TABLE, and ALTER TABLE DROP COLUMNS CONTINUE (described below).

You cannot use this clause with SET UNUSED, because that clause does not remove column data. 

 

DROP COLUMNS CONTINUE 

continues the drop column operation from the point at which it was interrupted. Submitting this statement while the table is in a valid state results in an error. 

 

Restrictions on the drop_column_clause:

  • Each of the parts of this clause can be specified only once in the statement and cannot be mixed with any other ALTER TABLE clauses. For example, the following statements are not allowed:

    ALTER TABLE t1 DROP COLUMN f1 DROP (f2);

    ALTER TABLE t1 DROP COLUMN f1 SET UNUSED (f2);

    ALTER TABLE t1 DROP (f1) ADD (f2 NUMBER);

    ALTER TABLE t1 SET UNUSED (f3)

    ADD (CONSTRAINT ck1 CHECK (f2 > 0));

 

 

  • You can drop an object type column only as an entity. Dropping an attribute from an object type column is not allowed.

  • If you drop a nested table column, its storage table is removed.

  • If you drop a LOB column, the LOB data and its corresponding LOB index segment are removed.

 

 

  • If you drop a BFILE column, only the locators stored in that column are removed, not the files referenced by the locators.

  • You can drop a column from an index-organized table only if it is not a primary key column. The primary key constraint of an index-organized table can never be dropped, so you cannot drop a primary key column even if you have specified CASCADE CONSTRAINTS.

 

 

  • You can export tables with dropped or unused columns. However, you can import a table only if all the columns specified in the export files are present in the table (that is, none of those columns has been dropped or marked unused). Otherwise, Oracle returns an error.

  • You cannot drop a column on which a domain index has been built.

 

 

You cannot use this clause to drop:

  • A pseudocolumn, clustered column, or partitioning column. (You can drop nonpartitioning columns from a partitioned table if all the tablespaces where the partitions were created are online and in read-write mode.)

  • A column from a nested table, an object table, or a table owned by SYS

 

allocate_extent_clause 

explicitly allocates a new extent for the table, the partition or subpartition, the overflow data segment, the LOB data segment, or the LOB index.

Restriction: You cannot allocate an extent for a range- or composite-partitioned table. 

 

SIZE 

specifies the size of the extent in bytes. Use K or M to specify the extent size in kilobytes or megabytes. If you omit this parameter, Oracle determines the size based on the values of the STORAGE parameters of the table's overflow data segment or of the LOB index.  

 

DATAFILE 

specifies one of the datafiles in the tablespace of the table, overflow data segment, LOB data tablespace, or LOB index to contain the new extent. If you omit this parameter, Oracle chooses the datafile.  

 

INSTANCE 

makes the new extent available to the freelist group associated with the specified instance. If the instance number exceeds the maximum number of freelist groups, the former is divided by the latter, and the remainder is used to identify the freelist group to be used. An instance is identified by the value of its initialization parameter INSTANCE_NUMBER. If you omit this parameter, the space is allocated to the table, but is not drawn from any particular freelist group. Rather, the master freelist is used, and space is allocated as needed. Use this parameter only if you are using Oracle with the Parallel Server option in parallel mode.

See Also: Oracle8i Concepts  

 

Explicitly allocating an extent with this clause does affect the size for the next extent to be allocated as specified by the NEXT and PCTINCREASE storage parameters.  

deallocate_unused_clause 

explicitly deallocates unused space at the end of the table, partition or subpartition, overflow data segment, LOB data segment, or LOB index and makes the space available for other segments in the tablespace. You can free only unused space above the high water mark (that is, the point beyond which database blocks have not yet been formatted to receive data). 

 

Oracle credits the amount of the released space to the user quota for the tablespace in which the deallocation occurs.

Oracle deallocates unused space from the end of the object toward the high water mark at the beginning of the object. If an extent is completely contained in the deallocation, then the whole extent is freed for reuse. If an extent is partially contained in the deallocation, then the used part up to the high water mark becomes the extent, and the remaining unused space is freed for reuse.

The exact amount of space freed depends on the values of the INITIAL, MINEXTENTS, and NEXT parameters (as described in "storage_clause"). 

 

KEEP 

specifies the number of bytes above the high water mark that the table, overflow data segment, LOB data segment, or LOB index will have after deallocation.  

 

 

  • If you omit KEEP and the high water mark is above the size of INITIAL and MINEXTENTS, then all unused space above the high water mark is freed. When the high water mark is less than the size of INITIAL or MINEXTENTS, then all unused space above MINEXTENTS is freed.

  • If you specify KEEP, then the specified amount of space is kept and the remaining space is freed. When the remaining number of extents is less than MINEXTENTS, then MINEXTENTS is adjusted to the new number of extents. If the initial extent becomes smaller than INITIAL, then INITIAL is adjusted to the new size.

  • In either case, NEXT is set to the size of the last extent that was deallocated.

 

CACHE 

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

 

As a parameter in the LOB_storage_clause, CACHE specifies that Oracle places LOB data values in the buffer cache for faster access.

Restriction: You cannot specify CACHE for an index-organized table. However, index-organized tables implicitly provide CACHE behavior. 

NOCACHE 

for data that is not accessed frequently, specifies 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.  

 

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

Restriction: You cannot specify NOCACHE for index-organized tables. 

CACHE READS 

applies only to LOB storage. It specifies that LOB values are brought into the buffer cache only during read operations, but not during write operations.

  • When you add a new LOB column, you can specify the logging attribute with CACHE READS, as you can when defining a LOB column at create time.

  • When you modify a LOB column from CACHE or NOCACHE to CACHE READS, or from CACHE READS to CACHE or NOCACHE, you can change the logging attribute. If you do not specify the LOGGING or NOLOGGING, this attribute defaults to the current logging attribute of the LOB column.

 

For existing LOBs, if you do not specify CACHE, NOCACHE, or CACHE READS, Oracle retains the existing values of the LOB attributes. 

MONITORING 

specifies that Oracle can collect modification statistics on table. These statistics are estimates of the number of rows affected by DML statements over a particular period of time. They are available for use by the optimizer or for analysis by the user.

See Also: Oracle8i Designing and Tuning for Performance for more information on using this clause. 

NOMONITORING 

specifies that Oracle will not collect modification statistics on table.

Restriction: You cannot specify MONITORING or NOMONITORING for a temporary table. 

LOGGING| NOLOGGING 

specifies whether subsequent Direct Loader (SQL*Loader) and direct-load INSERT operations against a nonpartitioned table, table partition, all partitions of a partitioned table, or all subpartitions of a partition will be logged (LOGGING) or not logged (NOLOGGING) in the redo log file.

When used with the modify_default_attributes_clause, this clause affects the logging attribute of a partitioned table. 

 

LOGGING|NOLOGGING also specifies whether ALTER TABLE...MOVE and ALTER TABLE...SPLIT operations will be logged or not logged. 

 

For a table or table partition, if you omit LOGGING|NOLOGGING, the logging attribute of the table or table partition defaults to the logging attribute of the tablespace in which it resides.  

 

For LOBs, if you omit LOGGING|NOLOGGING,

  • If you specify CACHE, then LOGGING is used (because you cannot have CACHE NOLOGGING).

  • If you specify NOCACHE or CACHE READS, the logging attribute defaults to the logging attribute of the tablespace in which it resides.

NOLOGGING does not apply to LOBs that are stored inline with row data. That is, if you specify NOLOGGING for LOBs with values less than 4000 bytes and you have not disabled STORAGE IN ROW, Oracle ignores the NOLOGGING specification and treats the LOB data the same as other table data. 

 

In NOLOGGING mode, data is modified with minimal logging (to mark new extents invalid and to record dictionary changes). When applied during media recovery, the extent invalidation records mark a range of blocks as logically corrupt, because the redo data is not logged. Therefore, if you cannot afford to lose this table, it is important to take a backup after the NOLOGGING operation.  

 

If the database is run in ARCHIVELOG mode, media recovery from a backup taken before the LOGGING operation will restore the table. However, media recovery from a backup taken before the NOLOGGING operation will not restore the table. 

 

The logging attribute of the base table is independent of that of its indexes.  

 

See Also: Oracle8i Parallel Server Concepts for more information about the logging_clause and parallel DML. 

RENAME TO  

renames table to new_table_name

 

Note: Using this clause will invalidate any dependent materialized views.  

 

See Also: "CREATE MATERIALIZED VIEW / SNAPSHOT" and Oracle8i Data Warehousing Guide for more information on materialized views. 

records_per_block_clause 

determines whether Oracle restricts the number of records that can be stored in a block. This clause ensures that any bitmap indexes subsequently created on the table will be as small (compressed) as possible.

Restrictions:

  • You cannot specify either MINIMIZE or NOMINIMIZE if a bitmap index has already been defined on table. You must first drop the bitmap index.

  • You cannot specify this clause for an index-organized table or nested table.

 

 

MINIMIZE 

instructs Oracle to calculate the largest number of records in any block in the table, and limit future inserts so that no block can contain more than that number of records.

Restriction: You cannot specify MINIMIZE for an empty table. 

 

NOMINIMIZE 

disables the MINIMIZE feature. This is the default. 

alter_overflow_clause 

modifies the definition of an index-organized table. Index-organized tables keep data sorted on the primary key and are therefore best suited for primary-key-based access and manipulation. 

 

Note: When you alter an index-organized table, Oracle evaluates the maximum size of each column to estimate the largest possible row. If an overflow segment is needed but you have not specified OVERFLOW, Oracle raises an error and does not execute the ALTER TABLE statement. This checking function guarantees that subsequent DML operations on the index-organized table will not fail because an overflow segment is lacking. 

 

PCTTHRESHOLD integer 

specifies the percentage of space reserved in the index block for an index-organized table row. Any portion of the row that exceeds the specified threshold is stored in the overflow area. PCTTHRESHOLD must be a value from 1 to 50.

Restrictions:

  • You cannot reduce the value of PCTTHRESHOLD so much that the primary key will not fit.

  • You cannot specify PCTTHRESHOLD for individual partitions of an index-organized table.

 

 

INCLUDING column_name 

specifies the column at which to divide an index-organized table row into index and overflow portions. All non-primary-key columns that follow column_name are stored in the overflow data segment. The column_name is either the name of the last primary key column or any subsequent non-primary-key column.

If you use the drop_column_clause to drop (or mark unused) a column defined as an INCLUDING column, the column stored immediately before this column will become the new INCLUDING column. 

 

overflow_clause 

specifies the overflow data segment physical storage and logging attributes to be modified for the index-organized table. Parameters specified in this clause are applicable only to the overflow data segment.

Restriction: You cannot specify OVERFLOW for a partition of a partitioned index-organized table unless the table already has an overflow segment.

See Also: "CREATE TABLE"

 

add_overflow_clause 

adds an overflow data segment to the specified index-organized table.

For a partitioned index-organized table:

  • If you do not specify PARTITION, Oracle automatically allocates an overflow segment for each partition. The physical attributes of these segments are inherited from the table level.

  • If you wish to specify separate physical attributes for one or more partitions, you must specify such attributes for every partition in the table. You do not specify the name of the partitions, but you must specify their attributes in the order in which they were created.

    You can find the order of the partitions by querying the PARTITION_NAME and PARTITION_POSITION columns of the USER_IND_PARTITIONS view.

If you do not specify TABLESPACE for a particular partition, Oracle uses the tablespace specified for the table. If you do not specify TABLESPACE at the table level, Oracle uses the tablespace of the partition's primary key index segment. 

partitioning_clauses 

The following clauses apply only to partitioned tables. You cannot combine partition operations with other partition operations or with operations on the base table in one ALTER TABLE statement. 

 

Note: If you drop, exchange, truncate, move, modify, or split a partition on a table that is a master table for one or more materialized views, existing bulk load information about the table will be deleted. Therefore, be sure to refresh all dependent materialized views before performing any of these operations.  

modify_default_attributes_clause 

specifies new default values for the attributes of table. Partitions and LOB partitions you create subsequently will inherit these values unless you override them explicitly when creating the partition or LOB partition. Existing partitions and LOB partitions are not affected by this clause.

Only attributes named in the statement are affected, and the default values specified are overridden by any attributes specified at the individual partition level. 

 

FOR PARTITION 

applies only to composite-partitioned tables. This clause specifies new default values for the attributes of partition. Subpartitions and LOB subpartitions of partition that you create subsequently will inherit these values, unless you override them explicitly when creating the subpartition or LOB subpartition. Existing subpartitions are not affected by this clause. 

 

Restrictions:

  • The PCTTHRESHOLD, COMPRESS, physical_attributes_clause, and overflow_clause are valid only for partitioned index-organized tables.

  • You cannot specify the PCTUSED parameter for the index segment of an index-organized table.

  • You can specify COMPRESS only if compression is already specified at the table level.

 

modify_partition_clause  

modifies the real physical attributes of the partition table partition. Optionally modifies the storage attributes of one or more LOB items for the partition. You can specify new values for any of the following physical attributes for the partition: the logging attribute; PCTFREE, PCTUSED, INITRANS, or MAXTRANS parameter; or storage parameters. 

 

If table is composite-partitioned:

  • If you specify the allocate_extent_clause, Oracle will allocate an extent for each subpartition of partition.

  • If you specify deallocate_unused_clause, Oracle will deallocate unused storage from each subpartition of partition.

  • Any other attributes changed in this clause will be changed in subpartitions of partition as well, overriding existing values. To avoid changing the attributes of existing subpartitions, use the FOR PARTITION clause of the modify_default_attributes_clause.

 

 

Restriction: If table is hash partitioned, you can specify only the allocate_extent and deallocate_unused clauses. All other attributes of the partition are inherited from the table-level defaults except TABLESPACE, which stays the same as it was at create time. 

 

add_subpartition_clause 

adds a hash subpartition to partition. Oracle populates the new subpartition with rows rehashed from the other subpartition(s) of partition as determined by the hash function.

Oracle marks UNUSABLE, and you must rebuild, the local index subpartitions corresponding to the added and to the rehashed subpartitions. 

 

 

If you do not specify subpartition, Oracle assigns a name in the form SYS_SUBPnnn

If you do not specify TABLESPACE, the new subpartition will reside in the default tablespace of partition

 

COALESCE SUBPARTITION 

specifies that Oracle should select a hash subpartition, distribute its contents into one or more remaining subpartitions (determined by the hash function), and then drop the selected subpartition.

Local index subpartitions corresponding to the selected subpartition are also dropped. Oracle marks UNUSABLE, and you must rebuild, the index subpartitions corresponding to one or more absorbing subpartitions. 

 

UNUSABLE LOCAL INDEXES clause 

The next two clauses modify the attributes of local index partitions corresponding to partition.  

 

 

UNUSABLE LOCAL INDEXES marks UNUSABLE all the local index partitions associated with partition

 

 

REBUILD UNUSABLE LOCAL INDEXES rebuilds the unusable local index partitions associated with partition

 

 

Restrictions:

  • You cannot specify this clause with any other clauses of the modify_partition_clause.

  • You cannot specify this clause for partitions that are subpartitioned.

 

modify_subpartition_clause 

lets you allocate or deallocate storage for an individual subpartition of table.

Restriction: The only modify_LOB_storage_parameters you can specify for subpartition are the allocate_extent_clause and deallocate_unused_clause

 

UNUSABLE LOCAL INDEXES marks UNUSABLE all the local index subpartitions associated with subpartition

 

REBUILD UNUSABLE LOCAL INDEXES rebuilds the unusable local index subpartitions associated with subpartition

rename_partition/ subpartition_clause 

renames a table partition or subpartition current_name to new_name. For both partitions and subpartitions, new_name must be different from all existing partitions and subpartitions of the same table. 

move_partition_clause  

moves table partition partition to another segment. You can move partition data to another tablespace, recluster data to reduce fragmentation, or change create-time physical attributes. 

 

If the table contains LOB columns, you can use the LOB_storage_clause to move the LOB data and LOB index segments associated with this partition. Only the LOBs named are affected. If you do not specify the LOB_storage_clause for a particular LOB column, its LOB data and LOB index segments are not moved. 

 

If partition is not empty, MOVE PARTITION marks UNUSABLE all corresponding local index partitions and all global nonpartitioned indexes, and all the partitions of global partitioned indexes.

When you move a LOB data segment, Oracle drops the old data segment and corresponding index segment and creates new segments even if you do not specify a new tablespace. 

 

The move operation obtains its parallel attribute from the parallel_clause, if specified. If not specified, the default parallel attributes of the table, if any, are used. If neither is specified, Oracle performs the move without using parallelism.

The parallel_clause on MOVE PARTITION does not change the default parallel attributes of table

 

Note: For index-organized tables, Oracle uses the address of the primary key, as well as its value, to construct logical rowids. The logical rowids are stored in the secondary index of the table. If you move a partition of an index-organized table, the address portion of the rowids will change, which can hamper performance. To ensure optimal performance, rebuild the secondary index(es) on the moved partition to update the rowids.

See Also: Oracle8i Concepts for more information on logical rowids. 

 

Restrictions:

  • If partition is a hash partition, the only attribute you can specify in this clause is TABLESPACE.

  • You cannot move a partition of a composite-partitioned table. You must move each subpartition separately with the move_subpartition_clause.

  • You cannot specify this clause for a partition containing subpartitions. However, you can move subpartitions using the move_subpartition_clause.

 

move_subpartition_clause 

moves the table subpartition subpartition to another segment. If you do not specify TABLESPACE, the subpartition will remain in the same tablespace.

Unless the subpartition is empty, Oracle marks UNUSABLE all local index subpartitions corresponding to the subpartition being moved, as well as global nonpartitioned indexes and partitions of global indexes. 

 

If the table contains LOB columns, you can use the LOB_storage_clause to move the LOB data and LOB index segments associated with this subpartition. Only the LOBs named are affected. If you do not specify the LOB_storage_clause for a particular LOB column, its LOB data and LOB index segments are not moved. 

 

When you move a LOB data segment, Oracle drops the old data segment and corresponding index segment and creates new segments even if you do not specify a new tablespace. 

add_range_partition_clause 

adds a new range partition partition to the "high" end of a partitioned table (after the last existing partition). You can specify any create-time physical attributes for the new partition. If the table contains LOB columns, you can also specify partition-level attributes for one or more LOB items.

You can specify up to 64K-1 partitions. For a discussion of factors that might impose practical limits less than this number, refer to Oracle8i Administrator's Guide. 

 

Restrictions:

  • If the first element of the partition bound of the high partition is MAXVALUE, you cannot add a partition to the table. Instead, use the split_partition_clause to add a partition at the beginning or the middle of the table.

  • The compression_clause, physical_attributes_clause, and OVERFLOW are valid only for a partitioned index-organized table.

  • You cannot specify the PCTUSED parameter for the index segment of an index-organized table.

  • You can specify OVERFLOW only if the partitioned table already has an overflow segment.

  • You can specify compression only if compression is enabled at the table level.

 

 

VALUES LESS THAN (value_list

specifies the upper bound for the new partition. The value_list is a comma-separated, ordered list of literal values corresponding to column_list. The value_list must collate greater than the partition bound for the highest existing partition in the table. 

 

partition_level_subpartitioning 

is permitted only for a composite-partitioned table. This clause lets you specify particular hash subpartitions for partition. You specify composite partitioning in one of two ways: 

 

 

  • You can specify individual subpartitions by name, and optionally the tablespace where each should be stored, or

  • You can specify the number of subpartitions (and optionally one or more tablespaces where they are to be stored). In this case, Oracle assigns partition names of the form SYS_SUBPnnn. The number of tablespaces does not have to equal the number of subpartitions. If the number of subpartitions is greater than the number of tablespaces, Oracle cycles through the names of the tablespaces.

 

 

 

The subpartitions inherit all their attributes from any attributes specified for new_partition, except for TABLESPACE, which you can specify at the subpartition level. Any attributes not specified at the subpartition or partition level are inherited from table-level defaults. 

 

 

This clause overrides any subpartitioning specified at the table level.

If you do not specify this clause but you specified default subpartitioning at the table level, new_partition_name will inherit the table-level default subpartitioning (see "CREATE TABLE"). 

add_hash_partition_clause 

adds a new hash partition to the "high" end of a partitioned table. Oracle will populate the new partition with rows rehashed from other partitions of table as determined by the hash function.

You can specify a name for the partition, and optionally a tablespace where it should be stored. If you do not specify new_partition_name, Oracle assigns a partition name of the form SYS_Pnnn. If you do not specify TABLESPACE, the new partition is stored in the table's default tablespace. Other attributes are always inherited from table-level defaults.

See Also: "CREATE TABLE" and Oracle8i Concepts for more information on hash partitioning. 

 

parallel_clause 

lets you specify whether to parallelize the creation of the new partition. 

coalesce_partition_clause 

applies only to hash-partitioned tables. This clause specifies that Oracle should select a hash partition, distribute its contents into one or more remaining partitions (determined by the hash function), and then drop the selected partition. Local index partitions corresponding to the selected partition are also dropped. Oracle marks UNUSABLE, and you must rebuild, the local index partitions corresponding to one or more absorbing partitions. 

drop_partition_clause  

applies only to tables partitioned using the range or composite method. This clause removes partition partition, and the data in that partition, from a partitioned table. If you want to drop a partition but keep its data in the table, you must merge the partition into one of the adjacent partitions. See the merge_partitions_clause of this statement.  

 

If the table has LOB columns, the LOB data and LOB index partitions (and their subpartitions, if any) corresponding to partition are also dropped.

  • Oracle drops local index partitions and subpartitions corresponding to partition, even if they are marked UNUSABLE.

  • Oracle marks UNUSABLE all global nonpartitioned indexes defined on the table and all partitions of global partitioned indexes, unless the partition being dropped or all of its subpartitions are empty.

  • If you drop a partition and later insert a row that would have belonged to the dropped partition, Oracle stores the row in the next higher partition. However, if that partition is the highest partition, the insert will fail because the range of values represented by the dropped partition is no longer valid for the table.

 

 

Restriction: If table contains only one partition, you cannot drop the partition. You must drop the table. 

truncate_partition_clause

truncate_subpartition_clause 

PARTITION removes all rows from partition or, if the table is composite-partitioned, all rows from partition's subpartitions. SUBPARTITION removes all rows from subpartition.

If the table contains any LOB columns, the LOB data and LOB index segments for this partition are also truncated. If the table is composite-partitioned, the LOB data and LOB index segments for this partition's subpartitions are truncated. 

 

If the partition or subpartition to be truncated contains data, you must first disable any referential integrity constraints on the table. Alternatively, you can delete the rows and then truncate the partition. 

 

For each partition or subpartition truncated, Oracle also truncates corresponding local index partitions and subpartitions. If those index partitions or subpartitions are marked UNUSABLE, Oracle truncates them and resets the UNUSABLE marker to VALID. In addition, if the truncated partition or subpartition, or any of the subpartitions of the truncated partition are not empty, Oracle marks as UNUSABLE all global nonpartitioned indexes and partitions of global indexes defined on the table. 

 

DROP STORAGE 

deallocates space from the deleted rows and makes it available for use by other schema objects in the tablespace. 

 

REUSE STORAGE 

keeps space from the deleted rows allocated to the partition or subpartition. The space is subsequently available only for inserts and updates to the same partition or subpartition. 

split_partition_clause  

from an original partition partition_name_old, creates two new partitions, each with a new segment and new physical attributes, and new initial extents. The segment associated with partition_name_old is discarded.

Restriction: You cannot specify this clause for a hash-partitioned table. 

 

AT (value_list) 

specifies the new noninclusive upper bound for split_partition_1. The value_list must compare less than the original partition bound for partition_name_old and greater than the partition bound for the next lowest partition (if there is one). 

 

INTO 

describes the two partitions resulting from the split. 

 

partition_description, partition_description 

specifies optional names and physical attributes of the two partitions resulting from the split. If you do not specify new partition names, Oracle assigns names of the form SYS_Pn. Any attributes you do not specify are inherited from partition_name_old.

Restriction:

  • You can specify the compression_clause, physical_attributes_clause, and OVERFLOW only for a partitioned index-organized table.

  • You cannot specify the PCTUSED parameter for the index segment of an index-organized table.

 

 

parallel_clause 

parallelizes the split operation, but does not change the default parallel attributes of the table. 

 

If you specify subpartitioning for the new partitions, you can specify only TABLESPACE for the subpartitions. All other attributes will be inherited from the containing new partition.

If partition_name_old is subpartitioned, and you do not specify any subpartitioning for the new partitions, the new partitions will inherit the number and tablespaces of the subpartitions in partition_name_old

 

Oracle also splits corresponding local index partitions, even if they are marked UNUSABLE. The resulting local index partitions inherit all their partition-level default attributes from the local index partition being split.

If partition_name_old was not empty, Oracle marks UNUSABLE all global nonpartitioned indexes and all partitions of global indexes on the table. (This action on global indexes does not apply to index-organized tables.) In addition, if any partitions or subpartitions resulting from the split are not empty, Oracle marks as UNUSABLE all corresponding local index partitions and subpartitions. 

 

If table contains LOB columns, you can use the LOB_storage_clause to specify separate LOB storage attributes for the LOB data segments resulting from the split. Oracle drops the LOB data and LOB index segments of partition_name_old and creates new segments for each LOB column, for each partition, even if you do not specify a new tablespace. 

merge_partitions_clause 

merges the contents of two adjacent partitions of table into one new partition, and then drops the original two partitions.

The new partition inherits the partition-bound of the higher of the two original partitions.

Any attributes not specified in the segment_attributes_clause are inherited from table-level defaults.  

 

If you do not specify new_partition_name, Oracle assigns a name of the form SYS_Pnnn. If the new partition has subpartitions, Oracle assigns subpartition names of the form SYS_SUBPnnn.

If either or both of the original partitions was not empty, Oracle marks UNUSABLE all global nonpartitioned global indexes and all partitions of global indexes on the table. In addition, if the partition or any of its subpartitions resulting from the merge is not empty, Oracle marks UNUSABLE all corresponding local index partitions and subpartitions. 

 

Restriction: You cannot specify this clause for an index-organized table or for a table partitioned using the hash method. 

 

partition_level_partitioning 

specifies hash subpartitioning attributes for the new partition. Any attributes not specified in this clause are inherited from table-level defaults.

If you do not specify this clause, the new merged partition inherits subpartitioning attributes from table-level defaults. 

 

parallel_clause 

specifies that the merging operation is to be parallelized. 

exchange_partition_clause

exchange_subpartition_clause 

lets you exchange the data and index segments of

  • a hash or range partition (or subpartition) with a nonpartitioned table

  • a hash-partitioned table with a range partition of a composite-partitioned table

The default behavior is EXCLUDING INDEXES WITH VALIDATION. You must have ALTER TABLE privileges on both tables to perform this operation.

This clause facilitates high-speed data loading when used with transportable tablespaces. For information on this topic, see Oracle8i Administrator's Guide. 

 

If table contains LOB columns, for each LOB column Oracle exchanges LOB data and LOB index partition or subpartition segments with corresponding LOB data and LOB index segments of table

 

All statistics of the table and partition are exchanged, including table, column, index statistics, and histograms. The aggregate statistics of the table receiving the new partition are recalculated.

The logging attribute of the table and partition is also exchanged. 

 

Restriction: Both tables involved in the exchange must have the same primary key, and no validated foreign keys can be referencing either of the tables unless the referenced table is empty. 

WITH TABLE table 

specifies the table with which the partition will be exchanged. 

INCLUDING INDEXES 

specifies that the local index partitions or subpartitions should be exchanged with the corresponding table index (for a nonpartitioned table) or local indexes (for a hash-partitioned table). 

EXCLUDING INDEXES 

specifies that all index partitions or subpartitions corresponding to the partition and all the regular indexes and index partitions on the exchanged table are marked UNUSABLE

WITH VALIDATION 

specifies that if any rows in the exchanged table do not map into partitions or subpartitions being exchanged, Oracle should return an error. 

WITHOUT VALIDATION 

specifies that the proper mapping of rows in the exchanged table is not checked. 

EXCEPTIONS INTO  

specifies a table into which Oracle places the rowids of all rows violating the constraint. If you omit schema, Oracle assumes the exceptions table is in your own schema. If you omit this clause altogether, Oracle assumes that the table is named EXCEPTIONS. The exceptions table must be on your local database. 

 

You can create the EXCEPTIONS table using one of these scripts:

  • UTLEXCPT.SQL uses physical rowids. Therefore it can accommodate rows from conventional tables but not from index-organized tables. (See the Note that follows.)

  • UTLEXPT1.SQL uses universal rowids, so it can accommodate rows from both conventional and index-organized tables.

 

 

If you create your own exceptions table, it must follow the format prescribed by one of these two scripts. See Oracle8i Migration for compatibility issues related to the use of these scripts. 

 

Note: If you are collecting exceptions from index-organized tables based on primary keys (rather than universal rowids), you must create a separate exceptions table for each index-organized table to accommodate its primary-key storage. You create multiple exceptions tables with different names by modifying and resubmitting the script.

For information on the SQL scripts, see the DBMS_IOT package in Oracle8i Supplied PL/SQL Packages Reference. For information on eliminating migrated and chained rows, see Oracle8i Designing and Tuning for Performance

 

Restrictions on EXCEPTIONS INTO clause:

  • This clause is not valid with subpartitions.

  • The partitioned table must have been defined with a UNIQUE constraint, and that constraint must be in DISABLE VALIDATE state.

 

 

If these conditions are not true, Oracle ignores this clause.

See Also: The "constraint_clause" for more information on constraint checking. 

Restrictions on exchanging partitions:

When exchanging between a hash-partitioned table and the range partition of a composite-partitioned table, the following restrictions apply:

  • The partitioning key of the hash-partitioned table must be identical to the subpartitioning key of the composite-partitioned table.

  • The number of partitions in the hash-partitioned table must be identical to the number of subpartitions in the range partition of the composite-partitioned table.

  • Oracle marks UNUSABLE all global indexes on both tables.

 

For partitioned index-organized tables, the following additional restrictions apply:

  • The source and target table/partition must have their primary key set on the same columns, in the same order.

  • If compression is enabled, it must be enabled for both the source and the target, and with the same prefix length.

  • An index-organized table partition cannot be exchanged with a regular table or vice versa.

  • Both the source and target must have overflow segments, or neither can have overflow segments.

 

row_movement_clause 

determines whether a row can be moved to a different partition or subpartition because of a change to one or more of its key values.

Restriction: You can specify this clause only for a partitioned table. 

 

ENABLE 

allows Oracle to move a row to a different partition or subpartition as the result of an update to the partitioning or subpartitioning key.

Restriction: You cannot specify this clause if a domain index has been built on any column of the table. 

 

 

WARNING: Moving a row in the course of an UPDATE operation changes that row's rowid. 

 

DISABLE  

returns an error if an update to a partitioning or subpartitioning key would result in a row moving to a different partition or subpartition. This is the default. 

parallel_clause 

changes the default degree of parallelism for queries and DML on the table. For additional information, see the Notes to the parallel_clause of "CREATE TABLE"

 

NOPARALLEL 

specifies serial execution. This is the default. 

 

PARALLEL  

causes 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. 

 

PARALLEL integer 

specifies the degree of parallelism, which is the number of parallel threads used in the parallel operation. Each parallel thread may use one or two parallel execution processes. Normally Oracle calculates the optimum degree of parallelism, so it is not necessary for you to specify integer

 

Restriction: If table contains any columns of LOB or user-defined object type, subsequent INSERT, UPDATE, and DELETE operations on table are executed serially without notification. Subsequent queries, however, will be executed in parallel. 

 

Note: If you specify the parallel_clause in conjunction with the move_table_clause, the parallelism applies only to the move, not to subsequent DML and query operations on the table. 

enable_disable_clause 

lets you specify whether Oracle should apply an integrity constraint. For a complete description of this clause, including notes and restrictions that relate to this statement, see the enable_disable_clause of "CREATE TABLE"

ENABLE TABLE LOCK 

enables DML and DDL locks on a table in a parallel server environment.

See Also: Oracle8i Parallel Server Concepts. 

 

Note: DML table locks are not acquired on temporary tables. 

DISABLE TABLE LOCK 

disables DML and DDL locks on a table to improve performance in a parallel server environment.

See Also: Oracle8i Parallel Server Concepts. 

ENABLE ALL TRIGGERS 

enables all triggers associated with the table. Oracle fires the triggers whenever their triggering condition is satisfied. See "CREATE TRIGGER".

To enable a single trigger, use the enable_clause of ALTER TRIGGER. See "ALTER TRIGGER"

DISABLE ALL TRIGGERS 

disables all triggers associated with the table. Oracle will not fire a disabled trigger even if the triggering condition is satisfied. 

Examples

Nested Table Example

The following statement modifies the storage characteristics of a nested table column PROJECTS in table EMP so that when queried it returns actual values instead of locators:

ALTER TABLE emp MODIFY NESTED TABLE projects RETURN AS VALUE; 
PARALLEL Example

The following statement specifies parallel processing for queries to the EMP table:

ALTER TABLE emp
   PARALLEL;
ENABLE VALIDATE Example

The following statement places in ENABLE VALIDATE state an integrity constraint named FK_DEPTNO in the EMP table:

ALTER TABLE emp
   ENABLE VALIDATE CONSTRAINT fk_deptno
   EXCEPTIONS INTO except_table;

Each row of the EMP table must satisfy the constraint for Oracle to enable the constraint. If any row violates the constraint, the constraint remains disabled. Oracle lists any exceptions in the table EXCEPT_TABLE. You can also identify the exceptions in the EMP table with the following statement:

SELECT emp.*
   FROM emp e, except_table ex
   WHERE e.row_id = ex.row_id
      AND ex.table_name = 'EMP'
      AND ex.constraint = 'FK_DEPTNO';
ENABLE NOVALIDATE Example

The following statement tries to place in ENABLE NOVALIDATE state two constraints on the EMP table:

ALTER TABLE emp
   ENABLE NOVALIDATE UNIQUE (ename)
   ENABLE NOVALIDATE CONSTRAINT nn_ename;

This statement has two ENABLE clauses:

In this case, Oracle enables the constraints only if both are satisfied by each row in the table. If any row violates either constraint, Oracle returns an error and both constraints remain disabled.

DISABLE Example

Consider a referential integrity constraint involving a foreign key on the combination of the AREACO and PHONENO columns of the PHONE_CALLS table. The foreign key references a unique key on the combination of the AREACO and PHONENO columns of the CUSTOMERS table. The following statement disables the unique key on the combination of the AREACO and PHONENO columns of the CUSTOMERS table:

ALTER TABLE customers
   DISABLE UNIQUE (areaco, phoneno) CASCADE;

The unique key in the CUSTOMERS table is referenced by the foreign key in the PHONE_CALLS table, so you must use the CASCADE clause to disable the unique key. This clause disables the foreign key as well.

CHECK Example

The following statement defines and disables a CHECK constraint on the EMP table:

ALTER TABLE emp
   ADD (CONSTRAINT check_comp CHECK (sal + comm <= 5000) )
   DISABLE CONSTRAINT check_comp;

The constraint CHECK_COMP ensures that no employee's total compensation exceeds $5000. The constraint is disabled, so you can increase an employee's compensation above this limit.

Triggers Example

The following statement enables all triggers associated with the EMP table:

ALTER TABLE emp
   ENABLE ALL TRIGGERS;
DEALLOCATE UNUSED Example

The following statement frees all unused space for reuse in table EMP, where the high water mark is above MINEXTENTS:

ALTER TABLE emp
    DEALLOCATE UNUSED;
DROP COLUMN Example

This statement illustrates the drop_column_clause with CASCADE CONSTRAINTS. Assume table T1 is created as follows:

CREATE TABLE t1 (
   pk NUMBER PRIMARY KEY,
   fk NUMBER,
   c1 NUMBER,
   c2 NUMBER,
   CONSTRAINT ri FOREIGN KEY (fk) REFERENCES t1,
   CONSTRAINT ck1 CHECK (pk > 0 and c1 > 0),
   CONSTRAINT ck2 CHECK (c2 > 0)
);

An error will be returned for the following statements:

ALTER TABLE t1 DROP (pk); -- pk is a parent key
ALTER TABLE t1 DROP (c1);  -- c1 is referenced by multicolumn
                           constraint ck1

Submitting the following statement drops column PK, the primary key constraint, the foreign key constraint, RI, and the check constraint, CK1:

ALTER TABLE t1 DROP (pk) CASCADE CONSTRAINTS;

If all columns referenced by the constraints defined on the dropped columns are also dropped, then CASCADE CONSTRAINTS is not required. For example, assuming that no other referential constraints from other tables refer to column PK, then it is valid to submit the following statement without the CASCADE CONSTRAINTS clause:

ALTER TABLE t1 DROP (pk, fk, c1);
Index-Organized Table Examples

This statement modifies the INITRANS parameter for the index segment of index-organized table DOCINDEX:

ALTER TABLE docindex INITRANS 4;

The following statement adds an overflow data segment to index-organized table DOCINDEX:

ALTER TABLE docindex ADD OVERFLOW;

This statement modifies the INITRANS parameter for the overflow data segment of index-organized table DOCINDEX:

ALTER TABLE docindex OVERFLOW INITRANS 4;
ADD PARTITION Example

The following statement adds a partition P3 and specifies storage characteristics for three of the table's LOB columns (B, C, and D):

ALTER TABLE pt ADD PARTITION p3 VALUES LESS THAN (30)
   LOB (b, d) STORE AS (TABLESPACE tsz)
   LOB (c) STORE AS mylobseg;

The LOB data and LOB index segments for columns B and D in partition P3 will reside in tablespace TSZ. The remaining attributes for these LOB columns will be inherited first from the table-level defaults, and then from the tablespace defaults.

The LOB data segments for column C will reside in the MYLOBSEG segment, and will inherit all other attributes from the table-level defaults and then from the tablespace defaults.

SPLIT PARTITION Example

The following statement splits partition P3 into partitions P3_1 and P3_2:

ALTER TABLE pt SPLIT PARTITION p3 AT (25)
   INTO (PARTITION p3_1 TABLESPACE ts4
            LOB (b,d) STORE AS (TABLESPACE tsz),
         PARTITION p3_2 (TABLESPACE ts5)
            LOB (c) STORE AS (TABLESPACE ts5);

In partition P3_1, Oracle creates the LOB segments for columns B and D in tablespace TSZ. In partition P3_2, Oracle creates the LOB segments for column C in tablespace TS5. The LOB segments for columns B and D in partition P3_2 and those for column C in partition P3_1 remain in original tablespace for the original partition P3. However, Oracle creates new segments for all the LOB data and LOB index segments, even though they are not moved to a new tablespace.

User-Defined Object Identifier Example

The following statements create an object type, a corresponding object table with a primary-key-based object identifier, and a table having a user-defined REF column:

CREATE TYPE emp_t AS OBJECT (empno NUMBER, address CHAR(30));

CREATE TABLE emp OF emp_t (
   empno PRIMARY KEY)
   OBJECT IDENTIFIER IS PRIMARY KEY;

CREATE TABLE dept (dno NUMBER, mgr_ref REF emp_t SCOPE is emp);

The next statements add a constraint and a user-defined REF column, both of which reference table EMP:

ALTER TABLE dept ADD CONSTRAINT mgr_cons FOREIGN KEY (mgr_ref)
   REFERENCES emp;
ALTER TABLE dept ADD sr_mgr REF emp_t REFERENCES emp;
Add Column Example

The following statement adds a column named THRIFTPLAN of datatype NUMBER with a maximum of seven digits and two decimal places and a column named LOANCODE of datatype CHAR with a size of one and a NOT NULL integrity constraint:

ALTER TABLE emp 
   ADD (thriftplan NUMBER(7,2),
        loancode CHAR(1) NOT NULL); 
Modify Column Examples

The following statement increases the size of the THRIFTPLAN column to nine digits:

ALTER TABLE emp
   MODIFY (thriftplan NUMBER(9,2)); 

Because the MODIFY clause contains only one column definition, the parentheses around the definition are optional.

The following statement changes the values of the PCTFREE and PCTUSED parameters for the EMP table to 30 and 60, respectively:

ALTER TABLE emp 
    PCTFREE 30
    PCTUSED 60; 
ALLOCATE EXTENT Example

The following statement allocates an extent of 5 kilobytes for the EMP table and makes it available to instance 4:

ALTER TABLE emp
  ALLOCATE EXTENT (SIZE 5K INSTANCE 4); 

Because this statement omits the DATAFILE parameter, Oracle allocates the extent in one of the datafiles belonging to the tablespace containing the table.

DEFAULT Examples

This statement modifies the BAL column of the ACCOUNTS table so that it has a default value of 0:

ALTER TABLE accounts
  MODIFY (bal DEFAULT 0); 

If you subsequently add a new row to the ACCOUNTS table and do not specify a value for the BAL column, the value of the BAL column is automatically 0:

INSERT INTO accounts(accno, accname)
  VALUES (accseq.nextval, 'LEWIS'); 

SELECT * 
    FROM accounts
    WHERE accname = 'LEWIS'; 

ACCNO  ACCNAME BAL 
------ ------- ---
815234  LEWIS     0 

To discontinue previously specified default values, so that they are no longer automatically inserted into newly added rows, replace the values with nulls, as shown in this statement:

ALTER TABLE accounts
   MODIFY (bal DEFAULT NULL);

The MODIFY clause need only specify the column name and the modified part of the definition, rather than the entire column definition. This statement has no effect on any existing values in existing rows.

Drop Constraint Examples

The following statement drops the primary key of the DEPT table:

ALTER TABLE dept 
    DROP PRIMARY KEY CASCADE; 

If you know that the name of the PRIMARY KEY constraint is PK_DEPT, you could also drop it with the following statement:

ALTER TABLE dept
    DROP CONSTRAINT pk_dept CASCADE; 

The CASCADE clause drops any foreign keys that reference the primary key.

The following statement drops the unique key on the DNAME column of the DEPT table:

ALTER TABLE dept 
    DROP UNIQUE (dname); 

The DROP clause in this statement omits the CASCADE clause. Because of this omission, Oracle does not drop the unique key if any foreign key references it.

LOB Examples

The following statement adds CLOB column RESUME to the EMPLOYEE table and specifies LOB storage characteristics for the new column:

ALTER TABLE employee ADD (resume CLOB)
  LOB (resume) STORE AS resume_seg (TABLESPACE resume_ts);

To modify the LOB column RESUME to use caching, enter the following statement:

ALTER TABLE employee MODIFY LOB (resume) (CACHE); 
Nested Table Examples

The following statement adds the nested table column SKILLS to the EMPLOYEE table:

ALTER TABLE employee ADD (skills skill_table_type)
    NESTED TABLE skills STORE AS nested_skill_table;

You can also modify a nested table's storage characteristics. Use the name of the storage table specified in the nested_table_storage_clause to make the modification. You cannot query or perform DML statements on the storage table. Use the storage table only to modify the nested table column storage characteristics.

The following statement creates table VETSERVICE with nested table column CLIENT and storage table CLIENT_TAB. Nested table VETSERVICE is modified to specify constraints:

CREATE TYPE pet_table AS OBJECT
   (pet_name VARCHAR2(10), pet_dob DATE);

CREATE TABLE vetservice (vet_name VARCHAR2(30),
                         client   pet_table)
  NESTED TABLE client STORE AS client_tab;

ALTER TABLE client_tab ADD UNIQUE (ssn);

The following statement adds a UNIQUE constraint to nested table NESTED_SKILL_TABLE:

ALTER TABLE nested_skill_table ADD UNIQUE (a);

The following statement alters the storage table for a nested table of REF values to specify that the REF is scoped:

CREATE TYPE emp_t AS OBJECT (eno number, ename char(31)); 
CREATE TYPE emps_t AS TABLE OF REF emp_t; 
CREATE TABLE emptab OF emp_t; 
CREATE TABLE dept (dno NUMBER, employees emps_t) 
   NESTED TABLE employees STORE AS deptemps; 
ALTER TABLE deptemps ADD (SCOPE FOR (column_value) IS emptab); 

Similarly, to specify storing the REF with rowid:

ALTER TABLE deptemps ADD (REF(column_value) WITH ROWID); 

In order to execute these ALTER TABLE statements successfully, the storage table DEPTEMPS must be empty. Also, because the nested table is defined as a table of scalars (REFs), Oracle implicitly provides the column name COLUMN_VALUE for the storage table.

See Also:

 

REF Examples

In the following statement an object type DEPT_T has been previously defined. Now, create table EMP as follows:

CREATE TABLE emp 
   (name VARCHAR(100), 
    salary NUMBER,
    dept REF dept_t); 

An object table DEPARTMENTS is created as:

CREATE TABLE departments OF dept_t; 

The DEPT column can store references to objects of DEPT_T stored in any table. If you would like to restrict the references to point only to objects stored in the DEPARTMENTS table, you could do so by adding a scope constraint on the DEPT column as follows:

ALTER TABLE emp 
    ADD (SCOPE FOR (dept) IS departments); 

The above ALTER TABLE statement will succeed only if the EMP table is empty.

If you want the REF values in the DEPT column of EMP to also store the rowids, issue the following statement:

ALTER TABLE emp 
   ADD (REF(dept) WITH ROWID);
Add Partition Example

The following statement adds partition JAN99 to tablespace TSX:

ALTER TABLE sales 
  ADD PARTITION jan99 VALUES LESS THAN( '970201' ) 
  TABLESPACE tsx; 
Drop Partition Example

The following statement drops partition DEC98:

ALTER TABLE sales DROP PARTITION dec98;
Exchange Partition Example

The following statement converts partition FEB97 to table SALES_FEB97 without exchanging local index partitions with corresponding indexes on SALES_FEB97 and without verifying that data in SALES_FEB97 falls within the bounds of partition FEB97:

ALTER TABLE sales 
   EXCHANGE PARTITION feb97 WITH TABLE sales_feb97 
   WITHOUT VALIDATION;
Modify Partition Examples

The following statement marks all the local index partitions corresponding to the NOV96 partition of the SALES table UNUSABLE:

ALTER TABLE sales MODIFY PARTITION nov96 
   UNUSABLE LOCAL INDEXES;

The following statement rebuilds all the local index partitions that were marked UNUSABLE:

ALTER TABLE sales MODIFY PARTITION jan97
   REBUILD UNUSABLE LOCAL INDEXES;

The following statement changes MAXEXTENTS and logging attribute for partition BRANCH_NY:

ALTER TABLE branch MODIFY PARTITION branch_ny 
   STORAGE (MAXEXTENTS 75) LOGGING;
Move Partition Example

The following statement moves partition DEPOT2 to tablespace TS094:

ALTER TABLE parts 
  MOVE PARTITION depot2 TABLESPACE ts094 NOLOGGING;
Rename Partition Examples

The following statement renames a table:

ALTER TABLE emp RENAME TO employee;

In the following statement, partition EMP3 is renamed:

ALTER TABLE employee RENAME PARTITION emp3 TO employee3;
Split Partition Example

The following statement splits the old partition DEPOT4, creating two new partitions, naming one DEPOT9 and reusing the name of the old partition for the other:

ALTER TABLE parts
   SPLIT PARTITION depot4 AT ( '40-001' )
   INTO ( PARTITION depot4 TABLESPACE ts009 STORAGE (MINEXTENTS 2),
         PARTITION depot9 TABLESPACE ts010 )
   PARALLEL (10);
Truncate Partition Example

The following statement deletes all the data in the SYS_P017 partition and deallocates the freed space:

ALTER TABLE deliveries
   TRUNCATE PARTITION sys_p017 DROP STORAGE;
Additional Examples

For examples of defining integrity constraints with the ALTER TABLE statement, see the "constraint_clause".

For examples of changing the value of a table's storage parameters, see the "storage_clause".


Prev Up Next
Oracle
Copyright © 1999 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index