Some restrictions apply to using the IBM Infosphere CDC technology to replicate data between solidDB® and other data servers.
Restrictions on solidDB® server in Universal Cache deployments
The following restrictions apply to solidDB® server when used as a source or target data server in Universal Cache deployments.
Referential integrity
▪Referential integrity (solidDB® as a source and target)
For continuous mirroring, referential integrity constraints (foreign keys) are allowed both on the source and target. The mandatory requirement is that the referential integrity associations are to be confined within the subscription; no foreign keys may point to tables outside the subscription. If this rule is violated, referential integrity errors can happen on the target during the mirroring, which ends the replication subscription.
Referential integrity is not supported with automatic creation of tables.
▪Primary key constraints (solidDB® as a source)
Primary keys are recommended but not mandatory. If no primary key is defined on a table, the execution of inserts and updates is less efficient than with primary keys. Primary key updates are restricted in the following way:
– If the primary key is defined over a single column, no multi-row updates of the primary key are allowed.
– In the case of multicolumn primary keys, multi-row updates are allowed if they affect a part of the primary key only.
If any of the above rules are violated, an error is produced and replication on the subscription (mirroring) ends.
Datatype support restrictions
▪LOB data types are not supported in D-tables (solidDB® as a source)
The large-size LOBs (maxiLOB, up to 2 GB) in D-tables (disk-based tables) are not supported in the source. If you attempt to write a maxiLOB into a D-table that is part of a log reader partition, the write fails and an error is returned to the application.
All LOBs maintained in M-tables (in-memory tables) that are within the available size limits (miniLOBS) are allowed. The size limit depends on the row size and the block size. With an assumption of a single LOB per row, the size limit is close to the block size. If the block size is set to 32 KB, a practical miniLOB size limit is about 30 KB.
▪Limited LOB support (solidDB® as a target)
If a LOB is written into an M-table and exceeds the miniLOB size limit, an error is returned and replication on the subscription ends.
TRUNCATE
In subscriptions where solidDB® is a source, the TRUNCATE TABLE statement is not allowed on tables which are part of a subscription. If this rule is violated, an error is returned to the application.
Transient and temporary tables
Because non-persistent (transient and temporary) tables are not logged, if solidDB® is a source datastore, transient and temporary tables cannot be part of a subscription. Transient and temporary tables can be used in a subscription where solidDB® is the target datastore.
Multiple NULLs in UNIQUE columns
In subscriptions where solidDB® is a target, there can be at most one NULL instance in a column defined as UNIQUE. An effort to propagate insertion of an additional NULL results in the UNIQUE constraint violation and replication on the subscription (mirroring) ends.
Data and workload partitioning using multiple cache databases
Multiple solidDB® servers can be used for data and workload partitioning; the backend data can be distributed (partitioned) over several cache databases. However, each cache database is autonomous and processes the application requests only within the partition it holds, without accessing data in any of the other cache databases (partitions).
Referential integrity constraints apply also; the partition cannot contain tables which are referencing or referenced outside the partition.
DDL changes for tables included in IBM Infosphere CDC subscriptions
solidDB® does not restrict renaming of tables that are part of an IBM Infosphere CDC subscription.
If you rename a table that is part of a subscription, the solidDB® server might shut down unexpectedly, for example, when the IBM Infosphere CDC for solidDB® instance is restarted.
If you need to rename or make other DDL changes to a table that is part of the IBM Infosphere CDC replication schema, see the IBM InfoSphere CDC Management Console Administration Guide.
Restrictions on IBM Infosphere CDC in Universal Cache deployments
The following features that may be available in the IBM Infosphere CDC components for other data servers are not supported in IBM Infosphere CDC for solidDB®.
▪Fast load for refresh
IBM Infosphere CDC for solidDB® does not support the fast load for refresh feature.
▪Automatic creation of target tables
If the tables meant to be mirrored are associated with referential integrity constraints, you cannot use the option of creating target tables automatically (Create new target tables), while defining a new subscription. Instead, use the option Map to existing tables. If this rule is violated, the subscription will not be created.
This restriction applies to all configurations, also with other DBMS products.
▪Row filtering
Row filtering (horizontal partitioning) is fully functional only if primary keys are defined on the source tables.
▪Dropping and re-creating tables when solidDB® is the source datastore
If you need to drop and re-create tables in subscriptions where solidDB® is the source datastore, you need to reconfigure the table mappings.