Oracle8i SQL Reference Release 2 (8.1.6) A76989-01 |
|
SQL Statements (continued), 9 of 11
relational_table:
object_table:
relational_properties::=
object properties::=
physical_properties::=
table_properties::=
subquery::= See "SELECT and Subqueries".
table_constraint, column_constraint, table_ref_constraint, column_ref_constraint, constraint_state: See the "constraint_clause"
storage_clause: See the "storage_clause".
index_organized_table_clause::=
index_organized_overflow_clause::=
LOB_parameters::=
nested_table_storage_clause::=
composite_partitioning_clause::=
partition_level_subpartitioning::=
hash_partitioning_storage_clause::=
global_partition_clause::=
To create a relational table, the basic structure to hold user data.
To create an object table or a table that uses an object type for a column definition. An object table is a table explicitly defined to hold object instances of a particular type.
You can also create an object type and then use it in a column when creating a relational table.
Tables are created with no data unless a query is specified. You can add rows to a table with the INSERT
statement. After creating a table, you can define additional columns, partitions, and integrity constraints with the ADD
clause of the ALTER
TABLE
statement. You can change the definition of an existing column or partition with the MODIFY
clause of the ALTER
TABLE
statement.
See also:
Oracle8i Application Developer's Guide - Fundamentals and "CREATE TYPE" for more information about creating objects. |
To create a relational table in your own schema, you must have system privilege. To create a table in another user's schema, you must have CREATE
ANY
TABLE
system privilege. Also, the owner of the schema to contain the table must have either space quota on the tablespace to contain the table or UNLIMITED
TABLESPACE
system privilege.
In addition to the table privileges above, to create a table that uses types, the owner of the table must have the EXECUTE
object privilege in order to access all types referenced by the table, or you must have the EXECUTE
ANY
TYPE
system privilege. These privileges must be granted explicitly and not acquired through a role.
Additionally, if the table owner intends to grant access to the table to other users, the owner must have been granted the EXECUTE
privileges to the referenced types with the GRANT OPTION
, or have the EXECUTE
ANY
TYPE
system privilege with the ADMIN OPTION
. Without these privileges, the table owner has insufficient privileges to grant access on the table to other users.
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 Also:
|
|
specifies that the table is temporary and that its definition is visible to all sessions. The data in a temporary table is visible only to the session that inserts the data into the table.
A temporary table has a definition that persists the same as the definitions of regular tables, but it contains either session-specific or transaction-specific data. You specify whether the data is session- or transaction-specific with the See Also: Oracle8i Concepts for more information on temporary tables. |
|
|
Restrictions: |
|
|
||
|
|
|
schema |
is the schema to contain the table. If you omit schema, Oracle creates the table in your own schema. |
|
table |
is the name of the table (or object table) to be created. |
|
|
explicitly creates an object table of type object_type. The columns of an object table correspond to the top-level attributes of type object_type. Each row will contain an object instance, and each instance will be assigned a unique, system-generated object identifier (OID) when a row is inserted. If you omit schema, Oracle creates the object table in your own schema. See Also: "CREATE TYPE" for more information about creating objects. |
|
|
Objects residing in an object table are referenceable. See Also: "User-Defined Type Categories", "User-Defined Functions", "Expressions", "CREATE TYPE", and Oracle8i Administrator's Guide for more information about using REFs. |
|
column |
specifies the name of a column of the table.
If you also specify |
|
|
The absolute maximum number of columns in a table is 1000. However, when you create an object table (or a relational table with columns of object, nested table, varray, or |
|
attribute |
specifies the qualified column name of an item in an object. |
|
datatype |
is the datatype of a column. Oracle-supplied datatypes are defined in "Datatypes". Restrictions: |
|
|
You can omit datatype:
|
|
|
specifies a value to be assigned to the column if a subsequent
Restriction: A |
|
column_ref_constraint |
These clauses let you further describe a column of type For syntax and description of these constraints, see the "constraint_clause". |
|
column_constraint |
defines an integrity constraint as part of the column definition. See the syntax description of column_constraint in the "constraint_clause".
You can create |
|
table_constraint |
defines an integrity constraint as part of the table definition. See the syntax description of table_constraint in the "constraint_clause". |
|
|
Note: You must specify a |
|
segment_attributes_clause: |
||
physical_attributes_clause |
specifies the value of the |
|
|
|
|
|
specifies the percentage of space in each data block of the table, object table OID index, or partition reserved for future updates to the table's rows. The value of |
|
|
|
|
|
specifies the minimum percentage of used space that Oracle maintains for each data block of the table, object table OID index, or index-organized table overflow data segment. A block becomes a candidate for row insertion when its used space falls below |
|
|
|
|
|
|
|
|
The sum of |
|
|
specifies the initial number of transaction entries allocated within each data block allocated to the table, object table OID index, partition, LOB index segment, or overflow data segment. This value can range from 1 to 255 and defaults to 1. In general, you should not change the |
|
|
Each transaction that updates a block requires a transaction entry in the block. The size of a transaction entry depends on your operating system. |
|
|
This parameter ensures that a minimum number of concurrent transactions can update the block and helps avoid the overhead of dynamically allocating a transaction entry. |
|
|
The |
|
|
specifies the maximum number of concurrent transactions that can update a data block allocated to the table, object table OID index, partition, LOB index segment, or index-organized overflow data segment. This limit does not apply to queries. This value can range from 1 to 255 and the default is a function of the data block size. You should not change the |
|
|
If the number of concurrent transactions updating a block exceeds the |
|
|
The |
|
storage_clause |
specifies the storage characteristics for the table, object table OID index, partition, LOB storage, LOB index segment, or index-organized table overflow data segment. This clause has performance ramifications for large tables. Storage should be allocated to minimize dynamic allocation of additional space. See the "storage_clause". |
|
|
specifies the tablespace in which Oracle creates the table, object table OID index, partition, LOB storage, LOB index segment, or index-organized table overflow data segment. If you omit |
|
|
For heap-organized tables with one or more LOB columns, if you omit the However, for an index-organized table with one or more LOB columns, if you omit TABLESPACE, the LOB data and index segments are created in the tablespace in which the primary key index segment of the index-organized table is created. |
|
|
For nonpartitioned tables, the value specified for |
|
|
See Also: "CREATE TABLESPACE" for more information on tablespaces. |
|
|
specifies whether the creation of the table (and any indexes required because of constraints), partition, or LOB storage characteristics will be logged in the redo log file.The logging attribute of the table is independent of that of its indexes.
This attribute also specifies that subsequent Direct Loader (SQL*Loader) and direct-load |
|
|
For a table or table partition, if you omit |
|
|
For LOBs, if you omit
|
|
|
For nonpartitioned tables, the value specified for |
|
|
In |
|
|
The size of a redo log generated for an operation in
If the database is run in |
|
|
See Also: Oracle8i Concepts and Oracle8i Administrator's Guide for more information about logging and parallel DML. |
|
|
These keywords are deprecated and have been replaced with |
|
|
Restrictions: |
|
|
specifies that the data rows of table are stored in no particular order. This is the default. |
|
|
specifies that table is created as an index-organized table. In an index-organized table, the data rows are held in an index defined on the primary key for the table. |
|
index_organized_table_clause |
specifies that Oracle should maintain the table rows (both primary key column values and non-key column values) in a B*-tree index built on the primary key. Index-organized tables are therefore best suited for primary key-based access and manipulation. An index-organized table is an alternative to |
|
|
Restrictions: |
|
|
Note: You must specify a primary key for an index-organized table, because the primary key uniquely identifies a row. The primary key cannot be |
|
|
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 segment. Restriction: |
|
|
specifies that index-organized table data rows exceeding the specified threshold are placed in the data segment listed in this clause. |
|
|
|
|
|
specifies a column at which to divide an index-organized table row into index and overflow portions. Oracle moves all primary key columns of an index-organized table to the beginning of the table (in their key order). column_name can be either the last primary-key column or any non-primary-key column. All non-primary-key columns that follow column_name are stored in the overflow data segment. Restriction: You cannot specify this clause for individual partitions of an index-organized table. |
|
compression_clause |
enables or disables key compression. |
|
|
|
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.
Restriction: At the partition level, you can specify |
|
|
disables key compression in index-organized tables. This is the default. |
LOB_storage_clause |
specifies the storage attributes of LOB data segments. |
|
|
||
|
|
|
|
|
|
|
|
|
|
Restriction: You cannot specify the LOB_index_clause if table is partitioned. |
|
|
See Also:
|
|
|
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. Oracle automatically creates a system-managed index for each lob_item you create. |
|
lob_segname |
specifies the name of the LOB data segment. You cannot use lob_segname if you specify more than one lob_item. |
lob_parameters |
|
specifies that the LOB value is stored in the row (inline) if its length is less than approximately 4000 bytes minus system control information. This is the default.
Restriction: For an index-organized table, you cannot specify this parameter unless you have specified an |
|
|
specifies that the LOB value is stored outside of the row regardless of the length of the LOB value. |
|
The LOB locator is always stored in the row regardless of where the LOB value is stored. You cannot change the value of |
|
|
|
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 (32K), 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. Oracle names and manages the LOB indexes internally. Although it is still possible for you to specify this clause, 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. The storage table is created in the same tablespace as its parent table (using the default storage characteristics) and stores the nested table values of the column for which it was created. 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. For a nonpartitioned table, the storage table is created in the same schema and the same tablespace as the parent table. For a partitioned table, the storage table is created in the default tablespace of the schema. |
|
|
Restriction: You cannot partition the storage table of a nested table. |
|
|
You cannot query or perform DML statements on storage_table directly, but you can modify its storage characteristics by specifying its name in an |
|
|
specifies what Oracle returns as the result of a query. |
|
|
Note: The locator is scoped to the session and cannot be used across sessions. Unlike a LOB locator, the collection locator cannot be used to modify the collection instance. |
|
If you do not specify the segment_attributes_clause or the LOB_storage_clause, the nested table is heap organized and is created with default storage characteristics. |
|
|
specifies that the table is to be part of cluster. The columns listed in this clause are the table columns that correspond to the cluster's columns. Generally, the cluster columns of a table are the column or columns that make up its primary key or a portion of its primary key. See Also: "CREATE CLUSTER". |
|
|
Specify one column from the table for each column in the cluster key. The columns are matched by position, not by name.
A clustered table uses the cluster's space allocation. Therefore, do not use the |
|
|
Restriction: Object tables cannot be part of a cluster. |
|
|
can be specified only if you are creating a temporary table. This clause specifies whether the data in the temporary table persists for the duration of a transaction or a session. |
|
|
|
specifies that the temporary table is transaction specific (this is the default). Oracle will truncate the table (delete all its rows) after each commit. |
|
|
specifies that the temporary table is session specific. Oracle will truncate the table (delete all its rows) when you terminate the session. |
OID_clause |
lets you specify whether the object identifier (OID) of the object table should be system generated or should be based on the primary key of the table. The default is Restrictions: |
|
|
Note: A primary key OID is locally (but not necessarily globally) unique. If you require a globally unique identifier, you must ensure that the primary key is globally unique. |
|
OID_index_clause |
This clause is relevant only if you have specified the OID_clause as |
|
|
index |
is the name of the index on the hidden system-generated object identifier column. If not specified, Oracle generates a name. |
hash_partitioning_clause |
specifies that the table is to be partitioned using the hash method. Oracle assigns rows to partitions using a hash function on values found in columns designated as the partitioning key. See Also: Oracle8i Concepts for more information on hash partitioning. |
|
|
column_list |
is an ordered list of columns used to determine into which partition a row belongs (the partitioning key). |
|
|
Restrictions: |
|
Note: If your enterprise has or will have databases using different character sets, use caution when partitioning on character columns. The sort sequence of characters is not identical in all character sets. See Also: Oracle8i National Language Support Guide for more information on character set support. |
|
|
You can specify hash partitioning in one of two ways:
|
|
|
Note: The only attribute you can specify for hash partitions (or subpartitions) is Tablespace storage specified at the table level is overridden by tablespace storage specified at the partition level, which in turn is overridden by tablespace storage specified at the subpartition level. |
|
range_partitioning_clause |
|
specifies that the table is partitioned on ranges of values from column_list. For an index-organized table, column_list must be a subset of the primary key columns of the table. |
|
column_list |
is an ordered list of columns used to determine into which partition a row belongs (the partitioning key).
Restriction: The columns in column_list can be of any built-in datatype except |
composite_partitioning_clause |
specifies that table is to be first range partitioned, and then the partitions further partitioned into hash subpartitions. This combination of range partitioning and hash subpartitioning is called composite partitioning. |
|
|
subpartition_clause |
specifies that Oracle should subpartition by hash each partition in table. The subpartitioning column_list is unrelated to the partitioning key, but is subject to the same restrictions. |
|
|
specifies the default number of subpartitions in each partition of table, and optionally one or more tablespaces in which they are to be stored. The default value is 1. If you do not specify the subpartition_clause here, Oracle will create each partition with one hash subpartition unless you subsequently specify the partition_level_hash_subpartitioning clause. |
partition_definition |
|
specifies the physical partition attributes. If partition is omitted, Oracle generates a name with the form |
|
Notes:
|
|
|
|
specifies the noninclusive upper bound for the current partition. |
|
value_list |
is an ordered list of literal values corresponding to column_list in the partition_by_range_clause. You can substitute the keyword
Specifying a value other than |
|
|
Note: If table is partitioned on a See Also:
|
|
LOB_storage_clause |
lets you specify LOB storage characteristics for one or more LOB items in this partition. If you do not specify the LOB_storage_clause for a LOB item, Oracle generates a name for each LOB data partition. The system-generated names for LOB data and LOB index partitions take the form |
|
varray_storage_clause |
lets you specify storage characteristics for one or more varray items in this partition. |
|
partition_level_subpartitioning |
lets you specify hash subpartitions for partition. This clause overrides the default settings established in the subpartition_clause. Restriction: You can specify this clause only for a composite-partitioned table. |
|
|
|
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 during an update operation. 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. |
|
|
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 |
causes creation of the table to be parallelized, and sets the default degree of parallelism for queries and DML on the table after creation. |
|
|
|
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 servers. 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, this statement as well as subsequent |
|
|
Notes
|
|
|
See Also: Oracle8i Designing and Tuning for Performance, Oracle8i Concepts, and Oracle8i Parallel Server Concepts for more information on parallelized operations. |
|
enable_disable_clause |
lets you specify whether Oracle should apply a constraint. By default, constraints are created in Restrictions:
See Also: "constraint_clause" for more information on constraints. |
|
|
specifies that the constraint will be applied to all new data in the table.
|
|
|
If you place a primary key constraint in |
|
|
|
|
|
|
|
|
Restriction: You cannot enable a foreign key that references a unique or primary key that is disabled. |
|
|
disables the integrity constraint. Disabled integrity constraints appear in the data dictionary along with enabled constraints. If you do not specify this clause when creating a constraint, Oracle automatically enables the constraint. |
|
|
|
|
|
If the unique key coincides with the partitioning key of the partitioned table, disabling the constraint saves overhead and has no detrimental effects. If the unique key does not coincide with the partitioning key, Oracle performs automatic table scans during the exchange to validate the constraint, which might offset the benefit of loading without an index. |
|
|
|
|
|
||
|
enables or disables the unique constraint defined on the specified column or combination of columns. |
|
|
enables or disables the table's primary key constraint. |
|
|
enables or disables the integrity constraint named constraint. |
|
using_index_clause |
specifies parameters for the index Oracle creates to enforce a unique or primary key constraint. Oracle gives the index the same name as the constraint.
You can choose the values of the |
|
|
Restriction: Use these parameters only when enabling unique and primary key constraints. |
|
|
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 |
|
|
You can create the
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 |
|
|
disables any integrity constraints that depend on the specified integrity constraint. To disable a primary or unique key that is part of a referential integrity constraint, you must specify this clause.
Restriction: You can specify |
|
|
for data that will be 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 clause is useful for small lookup tables. |
|
|
As a parameter in the LOB_storage_clause,
Restriction: You cannot specify |
|
|
for data that will not be 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. This is the default. |
|
|
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. |
|
|
specifies that modification statistics can be collected on this 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.
Restriction: You cannot specify |
|
|
specifies that the table will not have modification statistics collected. This is the default.
Restriction: You cannot specify |
|
|
inserts the rows returned by the subquery into the table upon its creation. See "SELECT and Subqueries". Restrictions:
|
|
|
If you specify the parallel_clause in this statement, Oracle will ignore any value you specify for the |
|
|
Oracle derives datatypes and lengths from the subquery. Oracle also follows the following rules for integrity constraints: |
|
|
||
|
||
|
If all expressions in subquery are columns, rather than expressions, you can omit the columns from the table definition entirely. In this case, the names of the columns of table are the same as the columns in subquery. |
|
|
You can use subquery in combination with the |
|
|
Note: If subquery returns (in part or totally) the equivalent of an existing materialized view, Oracle may use the materialized view (for query rewrite) in place of one or more tables specified in subquery. See also: Oracle8i Data Warehousing Guide for more information on materialized views and query rewrite. |
|
|
order_by_clause |
orders rows returned by the statements. See also: "SELECT and Subqueries" for more information on the order_by_clause. |
|
|
Note: When specified with |
|
For object tables, subquery can contain either one expression corresponding to the table type, or the number of top-level attributes of the table type. |
To define the EMP
table owned by SCOTT
, you could issue the following statement:
CREATE TABLE scott.emp (empno NUMBER CONSTRAINT pk_emp PRIMARY KEY, ename VARCHAR2(10) CONSTRAINT nn_ename NOT NULL CONSTRAINT upper_ename CHECK (ename = UPPER(ename)), job VARCHAR2(9), mgr NUMBER CONSTRAINT fk_mgr REFERENCES scott.emp(empno), hiredate DATE DEFAULT SYSDATE, sal NUMBER(10,2) CONSTRAINT ck_sal CHECK (sal > 500), comm NUMBER(9,0) DEFAULT NULL, deptno NUMBER(2) CONSTRAINT nn_deptno NOT NULL CONSTRAINT fk_deptno REFERENCES scott.dept(deptno) ) PCTFREE 5 PCTUSED 75;
This table contains eight columns. The EMPNO
column is of datatype NUMBER
and has an associated integrity constraint named PK_EMP
. The HIRDEDATE
column is of datatype DATE
and has a default value of SYSDATE
, and so on.
This table definition specifies a PCTFREE
of 5 and a PCTUSED
of 75, which is appropriate for a relatively static table. The definition also defines integrity constraints on some columns of the EMP
table.
The following statement creates a temporary table FLIGHT_SCHEDULE
for use in an automated airline reservation scheduling system. Each client has its own session and can store temporary schedules. The temporary schedules are deleted at the end of the session.
CREATE GLOBAL TEMPORARY TABLE flight_schedule ( startdate DATE, enddate DATE, cost NUMBER) ON COMMIT PRESERVE ROWS;
To define the sample table SALGRADE
in the HUMAN_RESOURCE
tablespace with a small storage capacity and limited allocation potential, issue the following statement:
CREATE TABLE salgrade ( grade NUMBER CONSTRAINT pk_salgrade PRIMARY KEY USING INDEX TABLESPACE users_a, losal NUMBER, hisal NUMBER ) TABLESPACE human_resource STORAGE (INITIAL 6144 NEXT 6144 MINEXTENTS 1 MAXEXTENTS 5 );
The above statement also defines a primary key constraint on the GRADE
column and specifies that the index Oracle creates to enforce this constraint is created in the USERS_A
tablespace.
The following statement creates a table using an optimum number of parallel execution servers to scan SCOTT.EMP
and to populate EMP_DEPT
:
CREATE TABLE emp_dept PARALLEL AS SELECT * FROM scott.emp WHERE deptno = 10;
Using parallelism speeds up the creation of the table because Oracle uses parallel execution servers to create the table. After the table is created, querying the table is also faster, because the same degree of parallelism is used to access the table.
The following statement creates a table serially. Subsequent DML and queries on the table will also be serially executed.
CREATE TABLE emp_dept AS SELECT * FROM scott.emp WHERE deptno = 10;
The following statement creates the DEPT
table, defines a primary key constraint, and places it in ENABLE VALIDATE
state:
CREATE TABLE dept (deptno NUMBER (2) PRIMARY KEY, dname VARCHAR2(10), loc VARCHAR2(9) ) TABLESPACE user_a;
The following statement creates the DEPT
table and defines a disabled primary key constraint:
CREATE TABLE dept (deptno NUMBER (2) PRIMARY KEY DISABLE, dname VARCHAR2(10), loc VARCHAR2(9) );
The following example creates the ORDER_EXEPTIONS
table to hold rows from an index-organized table ORDERS
that violate integrity constraint CHECK_ORDERS
:
CREATE TABLE orders (ord_num NUMBER PRIMARY KEY, ord_quantity NUMBER) ORGANIZATION INDEX; EXECUTE DBMS_IOT.BUILD_EXCEPTIONS_TABLE ('SCOTT', 'ORDERS', 'ORDER_EXCEPTIONS'); ALTER TABLE orders ADD CONSTRAINT CHECK_ORDERS CHECK (ord_quantity > 0) EXCEPTIONS INTO ORDER_EXCEPTIONS;
To specify an exception table, you must have the privileges necessary to insert rows into the table. To examine the identified exceptions, you must have the privileges necessary to query the exceptions table.
See Also:
|
The following statement creates relational table EMPLOYEE
with a nested table column PROJECTS
:
CREATE TABLE employee (empno NUMBER, name CHAR(31), projects PROJ_TABLE_TYPE) NESTED TABLE projects STORE AS nested_proj_table( (PRIMARY KEY (nested_table_id, pno)) ORGANIZATION INDEX) RETURN AS LOCATOR;
The following statement creates table LOB_TAB
with two LOB columns and specifies the LOB storage characteristics:
CREATE TABLE lob_tab (col1 BLOB, col2 CLOB) STORAGE (INITIAL 256 NEXT 256) LOB (col1, col2) STORE AS (TABLESPACE lob_seg_ts STORAGE (INITIAL 6144 NEXT 6144) CHUNK 4000 NOCACHE LOGGING);
In the example, Oracle rounds the CHUNK
up to 4096 (the nearest multiple of the block size of 2048).
The following statement creates an index-organized table:
CREATE TABLE docindex ( token CHAR(20), doc_oid INTEGER, token_frequency SMALLINT, token_occurrence_data VARCHAR2(512), CONSTRAINT pk_docindex PRIMARY KEY (token, doc_oid) ) ORGANIZATION INDEX TABLESPACE text_collection PCTTHRESHOLD 20 INCLUDING token_frequency OVERFLOW TABLESPACE text_collection_overflow;
The following statement creates a table with three partitions:
CREATE TABLE stock_xactions (stock_symbol CHAR(5), stock_series CHAR(1), num_shares NUMBER(10), price NUMBER(5,2), trade_date DATE) STORAGE (INITIAL 100K NEXT 50K) LOGGING PARTITION BY RANGE (trade_date) (PARTITION sx1992 VALUES LESS THAN (TO_DATE('01-JAN-1993','DD-MON-YYYY')) TABLESPACE ts0 NOLOGGING, PARTITION sx1993 VALUES LESS THAN (TO_DATE('01-JAN-1994','DD-MON-YYYY')) TABLESPACE ts1, PARTITION sx1994 VALUES LESS THAN (TO_DATE('01-JAN-1995','DD-MON-YYYY')) TABLESPACE ts2);
For information about partitioned table maintenance operations, see the Oracle8i Administrator's Guide.
This statement creates a partitioned table PT with two partitions P1 and P2, and three LOB columns, B, C, and D:
CREATE TABLE PT (A NUMBER, B BLOB, C CLOB, D CLOB) LOB (B,C,D) STORE AS (STORAGE (NEXT 20M)) PARTITION BY RANGE (A) (PARTITION P1 VALUES LESS THAN (10) TABLESPACE TS1 LOB (B,D) STORE AS (TABLESPACE TSA STORAGE (INITIAL 20M)), PARTITION P2 VALUES LESS THAN (20) LOB (B,C) STORE AS (TABLESPACE TSB) TABLESPACE TSX;
Partition P1
will be in tablespace TS1
. The LOB data partitions for B
and D
will be in tablespace TSA
. The LOB data partition for C
will be in tablespace TS1
. The storage attribute INITIAL
is specified for LOB columns B
and D
; other attributes will be inherited from the default table-level specification. The default LOB storage attributes not specified at the table level will be inherited from the tablespace TSA
for columns B
and D
and tablespace TS1
for column C
. LOB index partitions will be in the same tablespaces as the corresponding LOB data partitions. Other storage attributes will be based on values of the corresponding attributes of the LOB data partitions and default attributes of the tablespace where the index partitions reside.
Partition P2
will be in the default tablespace TSX
. The LOB data for B
and C
will be in tablespace TSB
. The LOB data for D
will be in tablespace TSX
. The LOB index for columns B
and C
will be in tablespace TSB
. The LOB index for column D
will be in tablespace TSX
.
This statement creates a table partitioned by hash on columns containing data about chemicals. The hash partitions are stored in tablespaces TBS1
, TBS2
, TBS3
, and TBS4
:
CREATE TABLE exp_data ( d DATE, temperature NUMBER, Fe2O3_concentration NUMBER, HCl_concentration NUMBER, Au_concentration NUMBER, amps NUMBER, observation VARCHAR(4000)) PARTITION BY HASH (HCl_concentration, Au_concentration) PARTITIONS 32 STORE IN (tbs1, tbs2, tbs3, tbs4);
This statement creates a composite-partitioned table. The range partitioning facilitates data and partition pruning by sale date. The hash subpartitioning enables subpartition elimination for queries by a specific item number. Most of the partitions consist of 8 subpartitions. However, the partition covering the slowest quarter will have 4 subpartitions, and the partition covering the busiest quarter will have 16 subpartitions.
CREATE TABLE sales (item INTEGER, qty INTEGER, store VARCHAR(30), dept NUMBER, sale_date DATE) PARTITION BY RANGE (sale_date) SUBPARTITION BY HASH(item) SUBPARTITIONS 8 STORE IN (tbs1, tbs2, tbs3, tbs4, tbs5, tbs6, tbs7, tbs8) (PARTITION q1_1997 VALUES LESS THAN (TO_DATE('01-apr-1997', 'dd-mon-yyyy')), PARTITION q2_1997 VALUES LESS THAN (TO_DATE('01-jul-1997', 'dd-mon-yyyy')), PARTITION q3_1997 VALUES LESS THAN (TO_DATE('01-oct-1997', 'dd-mon-yyyy')) (SUBPARTITION q3_1997_s1 TABLESPACE ts1, SUBPARTITION q3_1997_s2 TABLESPACE ts3, SUBPARTITION q3_1997_s3 TABLESPACE ts5, SUBPARTITION q3_1997_s4 TABLESPACE ts7), PARTITION q4_1997 VALUES LESS THAN (TO_DATE('01-jan-1998', 'dd-mon-yyyy')) SUBPARTITIONS 16 STORE IN (tbs1, tbs3, tbs5, tbs7, tbs8, tbs9, tbs10, tbs11), PARTITION q1_1998 VALUES LESS THAN (TO_DATE('01-apr-1998', 'dd-mon-yyyy')));
Consider object type DEPT_T
:
CREATE TYPE dept_t AS OBJECT ( dname VARCHAR2(100), address VARCHAR2(200) );
Object table DEPT
holds department objects of type DEPT_T
:
CREATE TABLE dept OF dept_t;
The following statement creates object table SALESREPS
with a user-defined object type, SALESREP_T
:
CREATE OR REPLACE TYPE salesrep_t AS OBJECT ( repId NUMBER, repName VARCHAR2(64)); CREATE TABLE salesreps OF salesrep_t;
The following statement creates relational table EMPLOYEE
with a nested table column PROJECTS
:
CREATE TABLE employee (empno NUMBER, name CHAR(31), projects PROJ_TABLE_TYPE) NESTED TABLE projects STORE AS nested_proj_table;
The following example creates object type DEPT_T
and object table DEPT to store instances of all departments. A table with a scoped REF
is then created.
CREATE TYPE dept_t AS OBJECT ( dname VARCHAR2(100), address VARCHAR2(200) ); CREATE TABLE dept OF dept_t; CREATE TABLE emp ( ename VARCHAR2(100), enumber NUMBER, edept REF dept_t SCOPE IS dept );
The following statement creates a table with a REF
column which has a referential constraint defined on it:
CREATE TABLE emp ( ename VARCHAR2(100), enumber NUMBER, edept REF dept_t REFERENCES dept);
This example creates an object type and a corresponding object table whose OID is primary key based:
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;
You can subsequently reference the EMP
object table in either of the following two ways:
CREATE TABLE dept (dno NUMBER mgr_ref REF emp_t SCOPE IS emp); CREATE TABLE dept ( dno NUMBER, mgr_ref REF emp_t CONSTRAINT mgr_in_emp REFERENCES emp);
CREATE TYPE address AS OBJECT ( hno NUMBER, street VARCHAR2(40), city VARCHAR2(20), zip VARCHAR2(5), phone VARCHAR2(10) ); CREATE TYPE person AS OBJECT ( name VARCHAR2(40), dateofbirth DATE, homeaddress address, manager REF person ); CREATE TABLE persons OF person ( homeaddress NOT NULL UNIQUE (homeaddress.phone), CHECK (homeaddress.zip IS NOT NULL), CHECK (homeaddress.city <> 'San Francisco') );
The following statement creates a table using 10 parallel execution servers, 5 to scan SCOTT.EMP
and another 5 to populate EMP_DEPT
:
CREATE TABLE emp_dept PARALLEL (5) AS SELECT * FROM scott.emp WHERE deptno = 10;
|
![]() Copyright © 1999 Oracle Corporation. All Rights Reserved. |
|