Shadow tables are replication-maintained, column-organized materialized query
tables (MQTs). Shadow tables handle analysis queries within an online analytical
processing (OLAP) transactional environment to accelerate query response. Shadow
tables are also known as row-organized materialized query tables in DB2
environments.
Restrictions
Shadow tables have the following restrictions:
- Shadow tables must be based on a single table or the rows from a
single table. The base table cannot be referenced by other shadow
tables.
- If you want to create a column-organized shadow table, you must
specify that setting in the General tab of the
Properties view of the table. Because shadow
tables are a form of MQT, you work in the
Properties view to define the properties of
those tables. If you create an MQT in the workbench with the table
organization set to Default for database, the
ORGANIZE BY clause is not declared. The default organization setting
for MQTs is row-organized, so you must explicitly specify the table
organization.
- These tables are not supported in database partitioning feature or
pureScale environments.
- Shadow tables or their base tables cannot be any of the following
types of tables:
- Range-partitioned tables
- Tables with multidimensional clustering enabled
- Resource control tables
- Temporal tables
- The base table of a shadow table must be row-organized and maintained
by replication.
- Columns in shadow tables cannot use the LONG VARCHAR or LONG
VARGRAPHIC data types.
- Shadow tables do not support fine-grained access control, row and
column access control, or label-based access control.
The primary keys used in shadow tables have the following restrictions:
- Column-organized shadow tables can create primary keys.
- The primary key column of the shadow table must correspond to the
primary key column of the base table.
- Primary keys must be enforced.