Additional Restrictions on the ATTACH Clause
User-defined routines and references to fields of a ROW-type column are not valid. You cannot attach a fragmented table to another fragmented table.
All of the dbspaces that store the fragments must have the same page size.
An ATTACH operation on two nonfragmented tables cannot produce a surviving table that is fragmented by interval or by list. (If you want to attach two nonfragmented tables, use the INIT option of ALTER FRAGMENT to define an interval or list fragmentation scheme for one of the nonfragmented tables, and then use the ATTACH option to attach the second table to it.)
For surviving tables that are fragmented
by interval, the following restrictions apply:
- Because the database server determines the ordinal position of interval fragments, BEFORE and AFTER specifications are not valid.
- You cannot attach a fragment whose expression matches an existing interval fragment expression.
- While you attach fragments above the transition value, the upper limit of the fragment being attached must align at an interval fragment boundary. That is, the upper limit of the fragment must equal the transition value plus an integer multiple of the interval value.
For fragmented tables that are protected by a security policy,
attaching a fragment to the table fails if any of the following conditions
are not satisfied:
- The source table and the target table are both protected by the same security policy;
- Both tables have the same protection granularity (either row-level, or column-level, or both row-level and column-level);
- In both tables, the same set of protected columns is protected by the same security labels. If there is more than one protected column, there can be more than one security label in each table, but the same label must protect the same column in both tables.
Only a user who holds the DBSECADM role can reference a protected table in the ALTER FRAGMENT statement.