ALTER TABLE Statement

(back to top)

• { ENABLE | DISABLE } RLV STORE registers this table with the RLV store for real-time in-memory updates. Not supported for IQ temporary tables. This value overrides the value of the database option BASE_TABLES_IN_RLV. In a multiplex, the RLV store can only be enabled on the coordinator

• ADD column-definition [ column-constraint ]

  add a new column to the table.

  The table must be empty to specify NOT NULL. The table might contain data when you add an IDENTITY or DEFAULT AUTOINCREMENT column. If the column has a default IDENTITY value, all rows of the new column are populated with sequential values. You can also add FOREIGN constraint as a column constraint for a single column key. The value of the IDENTITY/DEFAULT AUTOINCREMENT column uniquely identifies every row in a table.

  The IDENTITY/DEFAULT AUTOINCREMENT column stores sequential numbers that are automatically generated during inserts and updates. DEFAULT AUTOINCREMENT columns are also known as IDENTITY columns. When using IDENTITY/DEFAULT AUTOINCREMENT, the column must be one of the integer data types, or an exact numeric type, with scale 0. See CREATE TABLE Statement for more about column constraints and IDENTITY/DEFAULT AUTOINCREMENT columns.

  Note The database option IDENTITY_INSERT must be set to the table name to perform an explicit insert or update into an IDENTITY/AUTOINCREMENT column. For information on identity columns, see The IDENTITY or AUTOINCREMENT Default in Administration: Database. For information on IDENTITY_INSERT, see Reference: Statements and Options.

  IQ UNIQUE constraint – Defines the expected cardinality of a column and determines whether the column loads as Flat FP or NBit FP. An IQ UNIQUE(<n>) value explicitly set to 0 loads the column as Flat FP. Columns without an IQ UNIQUE constraint implicitly load as NBit up to the limits defined by the FP_NBIT_AUTOSIZE_LIMIT, FP_NBIT_LOOKUP_MB, and FP_NBIT_ROLLOVER_MAX_MB options.

  Using IQ UNIQUE with an <n> value less than the FP_NBIT_AUTOSIZE_LIMIT is not necessary. Auto-size functionality automatically sizes all low or medium cardinality columns as NBit. Use IQ UNIQUE in cases where you want to load the column as Flat FP or when you want to load a column as NBit when the number of distinct values exceeds the FP_NBIT_AUTOSIZE_LIMIT.

  Note

  • Consider memory usage when specifying high IQ UNIQUE values. If machine resources are limited, avoid loads with FP_NBIT_ENFORCE_LIMITS='OFF' (default).

    Prior to SAP IQ 16.0, an IQ UNIQUE <n> value > 16777216 would rollover to Flat FP. In 16.0, larger IQ UNIQUE values are supported for tokenization, but may require significant memory resource requirements depending on cardinality and column width.

  • BIT, BLOB,and CLOB data types do not support NBit dictionary compression. If FP_NBIT_IQ15_COMPATIBILITY=’OFF’, a non-zero IQ UNIQUE column specification in a CREATE TABLE or ALTER TABLE statement that includes these data types returns an error.

• ALTER <column-name> column-alteration
  change the column definition:

  • SET DEFAULT <default-value> – Change the default value of an existing column in a table. You can also use the MODIFY clause for this task, but ALTER is ISO/ANSI SQL compliant, and MODIFY is not. Modifying a default value does not change any existing values in the table.
  • DROP DEFAULT – Remove the default value of an existing column in a table. You can also use the MODIFY clause for this task, but ALTER is ISO/ANSI SQL compliant, and MODIFY is not. Dropping a default does not change any existing values in the table.
  • ADD – Add a named constraint or a CHECK condition to the column. The new constraint or condition applies only to operations on the table after its definition. The existing values in the table are not validated to confirm that they satisfy the new constraint or condition.
  • CONSTRAINT <column-constraint-name> – The optional column constraint name lets you modify or drop individual constraints at a later time, rather than having to modify the entire column constraint.
  • [ CONSTRAINT <constraint-name> ] CHECK ( <condition> ) – Use this clause to add a CHECK constraint on the column.
  • SET COMPUTE (<expression>) – Change the expression associated with a computed column. The values in the column are recalculated when the statement is executed, and the statement fails if the new expression is invalid.
  • DROP COMPUTE – Change a column from being a computed column to being a non-computed column. This statement does not change any existing values in the table.

• ADD table-constraint add a constraint to the table.

  You can also add a foreign key constraint as a table constraint for a single-column or multicolumn key. If PRIMARY KEY is specified, the table must not already have a primary key created by the CREATE TABLE statement or another ALTER TABLE statement. See CREATE TABLE Statement for a full explanation of table constraints.

  Note

  You cannot MODIFY a table or column constraint. To change a constraint, DELETE the old constraint and ADD the new constraint.

• DROP <drop-object>
  drops a table object:

  • DROP <column-name> – Drop the column from the table. If the column is contained in any multicolumn index, uniqueness constraint, foreign key, or primary key, then the index, constraint, or key must be deleted before the column can be deleted. This does not delete CHECK constraints that refer to the column. An IDENTITY/DEFAULT AUTOINCREMENT column can only be deleted if IDENTITY_INSERT is turned off and the table is not a local temporary table.
  • DROP CHECK – Drop all check constraints for the table. This includes both table check constraints and column check constraints.
  • DROP CONSTRAINT <constraint-name> – Drop the named constraint for the table or specified column.
  • DROP UNIQUE ( <column-name, ...> ) – Drop the unique constraints on the specified column(s). Any foreign keys referencing the unique constraint (rather than the primary key) are also deleted. Reports an error if there are associated foreign-key constraints. Use ALTER TABLE to delete all foreign keys that reference the primary key before you delete the primary key constraint.
  • DROP PRIMARY KEY – Drop the primary key. All foreign keys referencing the primary key for this table are also deleted. Reports an error if there are associated foreign key constraints. If the primary key is unenforced, DELETE returns an error if associated unenforced foreign key constraints exist.
  • DROP FOREIGN KEY <role-name> – Drop the foreign key constraint for this table with the given role name. Retains the implicitly created non-unique HG index for the foreign key constraint. Users can explicitly remove the HG index with the DROP INDEX statement.
  • DROP [ PARTITION ] – Drop the specified partition. The rows in partition P1 are deleted and the partition definition is dropped. You cannot drop the last partition because dropping the last partition would transform a partitioned table to a non-partitioned table. (To merge a partitioned table, use an UNPARTITION clause instead.) For example:

    	CREATE TABLE foo (c1 INT, c2 INT)
    		PARTITION BY RANGE (c1)
    		(P1 VALUES <= (100) IN dbsp1,
    		 P2 VALUES <= (200) IN dbsp2,
    		 P3 VALUES <= (MAX) IN dbsp3
    		) IN dbsp4);
    	LOAD TABLE ….
    	ALTER TABLE DROP PARTITION P1;

• RENAME <rename-object> renames an object in the table:
  • RENAME <new-table-name> – Change the name of the table to the <new-table-name>. Any applications using the old table name must be modified. Also, any foreign keys that were automatically assigned the same name as the old table name do not change names.
  • RENAME <column-name> TO <new-column-name> – Change the name of the column to <new-column-name>. Any applications using the old column name must be modified.
  • RENAME [ PARTITION ] – Rename an existing partition.
  • RENAME <constraint-name> TO <new-constraint-name> – Change the name of the constraint to <new-constraint-name>. Any applications using the old constraint name must be modified.

• MOVE clause moves a table object. A table object can only reside in one dbspace. Any type of ALTER MOVE blocks any modification to the table for the entire duration of the move.
  Note You cannot move objects to a cache dbspace.

  • MOVE TO – Move all table objects including columns, indexes, unique constraints, primary key, foreign keys, and metadata resided in the same dbspace as the table is mapped to the new dbspace. The ALTER Column MOVE TO clause cannot be requested on a partitioned table.

    Note You cannot use the MOVE TO clause on a DAS dbfile.
    A BIT data type column cannot be explicitly placed in a dbspace. The following is not supported for BIT data types:

    ALTER TABLE t2 alter c1_bit MOVE TO iq_main; 

  • MOVE TABLE METADATA – Move the metadata of the table to a new dbspace. For a partitioned table, MOVE TABLE METADATA also moves metadata that is shared among partitions.

  • MOVE PARTITION – Move the specified partition to the new dbspace.

    Note You cannot use the MOVE PARTITION clause on a DAS dbfile.

• PARTITION BY divides large tables into smaller, more manageable storage objects. Partitions share the same logical attributes of the parent table, but can be placed in separate dbspaces and managed individually. SAP IQ supports several table partitioning schemes:
  • hash-partitions
  • range-partitions
  • composite-partitions
  A partition-key is the column or columns that contain the table partitioning keys. Partition keys can contain NULL and DEFAULT values, but cannot contain:

  • LOB (BLOB or CLOB) columns
  • BINARY, or VARBINARY columns
  • CHAR or VARCHAR columns whose length is over 255 bytes
  • BIT columns
  • FLOAT/DOUBLE/REAL columns

• PARTITION BY RANGE partitions rows by a range of values in the partitioning column. Range partitioning is restricted to a single partition key column and a maximum of 1024 partitions. In a range-partitioning-scheme, the partition-key is the column that contains the table partitioning keys:

  range-partition-decl:
    <partition-name> VALUES <= ( {<constant-expr> |  MAX } [ , { <constant-expr> |  MAX }]... ) 
      [ IN <dbspace-name> ]

  The partition-name is the name of a new partition on which table rows are stored. Partition names must be unique within the set of partitions on a table. The partition-name is required.
  • VALUE specifies the inclusive upper bound for each partition (in ascending order). The user must specify the partitioning criteria for each range partition to guarantee that each row is distributed to only one partition. NULLs are allowed for the partition column and rows with NULL as partition key value belong to the first table partition. However, NULL cannot be the bound value.

    There is no lower bound (MIN value) for the first partition. Rows of NULL cells in the first column of the partition key will go to the first partition. For the last partition, you can either specify an inclusive upper bound or MAX. If the upper bound value for the last partition is not MAX, loading or inserting any row with partition key value larger than the upper bound value of the last partition generates an error.

  • Max denotes the infinite upper bound and can only be specified for the last partition.
  • IN specifies the dbspace in the partition-decl on which rows of the partition should reside.
  These restrictions affect partitions keys and bound values for range partitioned tables:

  • You can only range partition a non-partitioned table if all existing rows belong to the first partition.
  • Partition bounds must be constants, not constant expressions.
  • Partition bounds must be in ascending order according to the order in which the partitions were created. That is, the upper bound for the second partition must be higher than for the first partition, and so on.

    In addition, partition bound values must be compatible with the corresponding partition-key column data type. For example, VARCHAR is compatible with CHAR.

  • If a bound value has a different data type than that of its corresponding partition key column, SAP IQ converts the bound value to the data type of the partition key column, with these exceptions:
  • Explicit conversions are not allowed. This example attempts an explicit conversion from INT to VARCHAR and generates an error:

    CREATE TABLE Employees(emp_name VARCHAR(20)) 
    PARTITION BY RANGE(emp_name)
    (p1 VALUES <=(CAST (1 AS VARCHAR(20))), 
    p2 VALUES <= (CAST (10 AS VARCHAR(20)))

  • Implicit conversions that result in data loss are not allowed. In this example, the partition bounds are not compatible with the partition key type. Rounding assumptions may lead to data loss and an error is generated:

    CREATE TABLE emp_id (id INT) PARTITION BY RANGE(id) (p1 VALUES <= (10.5), p2 VALUES <= (100.5))

  • In this example, the partition bounds and the partition key data type are compatible. The bound values are directly converted to float values. No rounding is required, and conversion is supported:

    CREATE TABLE id_emp (id FLOAT)
    PARTITION BY RANGE(id) (p1 VALUES <= (10), 
    p2 VALUES <= (100))

  • Conversions from non-binary data types to binary data types are not allowed. For example, this conversion is not allowed and returns an error:

    CREATE TABLE newemp (name BINARY)
    PARTITION BY RANGE(name) 
    (p1 VALUES <= ("Maarten"), 
    p2 VALUES <= ("Zymmerman")

  • NULL cannot be used as a boundary in a range-partitioned table.
  • The row will be in the first partition if the cell value of the 1st column of the partition key evaluated to be NULL. SAP IQ supports only single column partition keys, so any NULL in the partition key distributes the row to the first partition.

• PARTITION BY HASH maps data to partitions based on partition-key values processed by an internal hashing function. Hash partition keys are restricted to a maximum of eight columns with a combined declared column width of 5300 bytes or less. For hash partitions, the table creator determines only the partition key columns; the number and location of the partitions are determined internally.
  In a hash-partitioning declaration, the partition-key is a column or group of columns, whose composite value determines the partition where each row of data is stored:

  hash-partitioning-scheme: 
    HASH  ( partition-key [ , partition-key, … ] )

  • Restrictions
    • You can only hash partition a base table. Attempting to partitioning a global temporary table or a local temporary table raises an error.
    • You can only hash partition a non-partitioned table that is empty.
    • You cannot add, drop, merge, or split a hash partition.
    • You cannot add or drop a column from a hash partition key.
• PARTITION BY HASH RANGE subpartitions a hash-partitioned table by range. In a hash-range-partitioning-scheme declaration, a SUBPARTITION BY RANGE clause adds a new range subpartition to an existing hash-range partitioned table:

  hash-range-partitioning-scheme:                
  PARTITION BY HASH  ( partition-key [ , partition-key, … ] )
      [ SUBPARTITION BY RANGE  ( range-partition-decl [ , range-partition-decl ... ] ) ]

  The hash partition specifies how the data is logically distributed and colocated; the range subpartition specifies how the data is physically placed. The new range subpartition is logically partitioned by hash with the same hash partition keys as the existing hash-range partitioned table. The range subpartition key is restricted to one column.
  • Restrictions
    • You can only hash partition a base table. Attempting to partitioning a global temporary table or a local temporary table raises an error.
    • You can only subpartition a hash-partitioned table by range if the the table is empty.
    • You cannot add, drop, merge, or split a hash partition.
    • You cannot add or drop a column from a hash partition key.
    Note

    Range-partitions and composite partitioning schemes, like hash-range partitions, require the separately licensed VLDB Management option.

• MERGE PARTITION merge <partition-name-1> into <partition-name-2>. Two partitions can be merged if they are adjacent partitions and the data resides on the same dbspace. You can only merge a partition with a lower partition value into the adjacent partition with a higher partition value. Note that the server does not check CREATE privilege on the dbspace into which the partition is merged. For an example of how to create adjacent partitions, see CREATE TABLE Statement examples.

• RENAME PARTITION rename an existing PARTITION.

• UNPARTITION remove partitions from a partitioned table. Each column is placed in a single dbspace. Note that the server does not check CREATE privilege on the dbspace to which data of all partitions is moved. ALTER TABLE UNPARTITION blocks all database activities.

• ALTER OWNER change the owner of a table. The ALTER OWNER clause may not be used in conjunction with any other [alter-clause] clauses of the ALTER TABLE statement.
  • [ PRESERVE | DROP ] PERMISSIONS – If you do not want the new owner to have the same privileges as the old owner, use the DROP privileges clause (default) to drop all explicitly-granted privileges that allow a user access to the table. Implicitly-granted privileges given to the owner of the table are given to the new owner and dropped from the old owner.
  • [ PRESERVE | DROP ] FOREIGN KEYS – If you want to prevent the new owner from accessing data in referenced tables, use the DROP FOREIGN KEYS clause (default) to drop all foreign keys within the table, as well as all foreign keys referring to the table. Use of the PRESERVE FOREIGN KEYS clause with the DROP PERMISSIONS clause fails unless all referencing tables are owned by the new owner.
  The ALTER TABLE ALTER OWNER statement fails if:

  • Another table with the same name as the original table exists and is owned by the new user.
  • The PRESERVE FOREIGN KEYS and PRESERVE PERMISSIONS clauses are both specified and there is a foreign key owned by a user other than the new table owner referencing the table that relies on implicitly-granted privileges (such as those given to the owner of a table). To avoid this failure, explicitly grant SELECT privileges to the referring table's original owner, or drop the foreign keys.
  • The PRESERVE FOREIGN KEYS clause is specified, but the PRESERVE PERMISSIONS clause is NOT, and there is a foreign key owned by a user other than the new table owner referencing the table. To avoid this failure, drop the foreign keys.
  • The PRESERVE FOREIGN KEYS clause is specified and the table contains a foreign key that relies on implicitly-granted privileges (such as those given to the owner of a table). To avoid this failure, explicitly GRANT SELECT privileges to the new owner on the referenced table, or drop the foreign keys.
  • The table contains a column with a default value that refers to a sequence, and the USAGE privilege of the sequence generator relies on implicitly-granted privileges (such as those given to the owner of a sequence). To avoid this failure, explicitly grant USAGE privilege on the sequence generator to the new owner of the table.
  • Enabled materialized views that depend on the original table exist.