Oracle8i SQL Reference Release 2 (8.1.6) A76989-01 |
|
SQL Statements (continued), 2 of 11
column_constraint, table_constraint, column_ref_constraint, table_ref_constraint, constraint_state: See the "constraint_clause".
LOB_parameters::=
storage_clause: See "storage_clause".
nested_table_storage_clause::=
object_properties::=
physical_properties::=
segment_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::=
modify_varray_storage_clause::=
modify_default_attributes_clause::=
partition_attributes::=
subpartition_description::=
partition_description::=
partition_level_subpartitioning::=
hash_partitioning_storage_clause::=
rename_partition/ subpartition_clause::=
truncate_partition_clause/truncate_subpartition_clause::=
exchange_partition_clause/exchange_subpartition_clause::=
using_index_clause::=
To alter the definition of a nonpartitioned table, a partitioned table, a table partition, or a table subpartition.
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.
The clauses described below have specialized meaning in the |
||
Note: Operations performed by the |
||
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: |
|
|
|
|
|
||
|
Note: If you alter a table that is a master table for one or more materialized views, the materialized views are marked See Also: Oracle8i Data Warehousing Guide for more information on materialized views in general. |
|
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 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 " |
|
|
Restrictions:
|
|
|
|
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 |
|
|
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 |
|
|
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 |
|
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: |
|
|
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. |
|
|
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.)
Restriction: You cannot change |
|
|
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
You cannot change the value of |
|
|
Note: The value of |
|
|
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 |
|
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: |
|
|
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 |
|
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.
|
|
|
Restrictions:
|
|
|
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 |
|
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: |
|
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". |
|
|
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
The index and data segments of LOB columns are not rebuilt unless you specify the LOB columns explicitly as part of this |
|
|
|
specifies that DML operations on the index-organized table are allowed during rebuilding of the table's primary key index B*-tree. Restrictions: |
|
compression_clause |
enables and disables key compression in an index-organized table. |
|
|
|
|
|
|
|
|
specifies the tablespace into which the rebuilt index-organized table is stored. |
|
Restrictions:
|
|
|
For any LOB columns you specify in this clause:
|
|
physical_attributes_clause |
changes the value of
Restriction: You cannot specify the |
|
|
WARNING:
|
|
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. |
|
|
specifies what Oracle returns as the result of a query. |
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: |
|
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 |
|
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. |
|
|
|
drops the table's |
|
|
drops the |
|
|
drops the integrity constraint named constraint. |
|
|
drops all other integrity constraints that depend on the dropped integrity constraint. |
|
Restrictions:
|
|
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. |
|
|
|
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 |
|
|
You can view all tables with columns marked as unused in the data dictionary views |
|
|
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 " |
|
|
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
Also, if you mark a column of datatype See Also: "CREATE TABLE" for more information on the 1000 column limit. |
|
|
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:
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 |
|
|
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 |
|
|
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 |
|
|
Note: Currently, Oracle executes this clause regardless of whether you specify the keyword |
|
|
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. |
|
|
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
You cannot use this clause with |
|
|
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:
|
|
|
||
|
|
|
|
|
|
|
You cannot use this clause to drop: |
|
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 |
|
|
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. |
|
|
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 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 |
|
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 |
|
|
|
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. |
|
|
|
|
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,
Restriction: You cannot specify |
|
|
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,
Restriction: You cannot specify |
|
|
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.
|
|
For existing LOBs, if you do not specify |
||
|
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. |
|
|
specifies that Oracle will not collect modification statistics on table.
Restriction: You cannot specify |
|
|
specifies whether subsequent Direct Loader (SQL*Loader) and direct-load When used with the modify_default_attributes_clause, this clause affects the logging attribute of a partitioned table. |
|
|
|
|
|
For a table or table partition, if you omit |
|
|
For LOBs, if you omit
|
|
|
In |
|
|
If the database is run in |
|
|
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. |
|
|
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: |
|
|
|
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 |
|
|
disables the |
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 |
|
|
|
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. Restrictions: |
|
|
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 |
|
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 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 |
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 |
|
|
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. |
|
|
|
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:
|
|
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; |
|
|
If table is composite-partitioned:
|
|
|
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 |
|
|
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 |
|
|
If you do not specify subpartition, Oracle assigns a name in the form SYS_SUBPnnn
If you do not specify |
|
|
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 |
|
|
The next two clauses modify the attributes of local index partitions corresponding to partition. |
|
|
|
|
|
|
|
|
Restrictions: |
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. |
|
|
|
|
|
|
|
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, 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 |
|
|
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:
|
|
move_subpartition_clause |
moves the table subpartition subpartition to another segment. If you do not specify
Unless the subpartition is empty, Oracle marks |
|
|
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:
|
|
|
|
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: |
|
|
|
|
|
The subpartitions inherit all their attributes from any attributes specified for new_partition, except for |
|
|
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 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 |
|
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.
|
|
|
Restriction: If table contains only one partition, you cannot drop the partition. You must drop the table. |
|
truncate_subpartition_clause |
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 |
|
|
|
deallocates space from the deleted rows and makes it available for use by other schema objects in the tablespace. |
|
|
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. |
|
|
|
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). |
|
|
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 Restriction: |
|
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 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
If partition_name_old was not empty, Oracle marks |
|
|
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
If either or both of the original partitions was not empty, Oracle marks |
|
|
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_subpartition_clause |
lets you exchange the data and index segments of
The default behavior is 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. |
|
|
specifies the table with which the partition will be exchanged. |
|
|
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). |
|
|
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 |
|
|
specifies that if any rows in the exchanged table do not map into partitions or subpartitions being exchanged, Oracle should return an error. |
|
|
specifies that the proper mapping of rows in the exchanged table is not checked. |
|
|
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: |
|
|
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 |
|
|
Restrictions on EXCEPTIONS INTO clause: |
|
|
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:
|
||
For partitioned index-organized tables, the following additional restrictions apply:
|
||
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. |
|
|
|
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 |
|
|
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". |
|
|
|
specifies serial execution. This is the default. |
|
|
causes Oracle to select a degree of parallelism equal to the number of CPUs available on all participating instances times the value of the |
|
|
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 |
|
|
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". |
|
|
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. |
|
|
disables DML and DDL locks on a table to improve performance in a parallel server environment. See Also: Oracle8i Parallel Server Concepts. |
|
|
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 |
|
|
disables all triggers associated with the table. Oracle will not fire a disabled trigger even if the triggering condition is satisfied. |
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;
The following statement specifies parallel processing for queries to the EMP
table:
ALTER TABLE emp PARALLEL;
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';
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:
ENAME
column in ENABLE
NOVALIDATE
state.
NN_ENAME
in ENABLE NOVALIDATE
state.
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.
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.
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.
The following statement enables all triggers associated with the EMP
table:
ALTER TABLE emp ENABLE ALL TRIGGERS;
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;
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);
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;
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.
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.
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;
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);
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;
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.
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.
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.
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);
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:
|
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);
The following statement adds partition JAN99
to tablespace TSX
:
ALTER TABLE sales ADD PARTITION jan99 VALUES LESS THAN( '970201' ) TABLESPACE tsx;
The following statement drops partition DEC98
:
ALTER TABLE sales DROP PARTITION dec98;
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;
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;
The following statement moves partition DEPOT2
to tablespace TS094
:
ALTER TABLE parts MOVE PARTITION depot2 TABLESPACE ts094 NOLOGGING;
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;
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);
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;
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".
|
![]() Copyright © 1999 Oracle Corporation. All Rights Reserved. |
|