Restrictions on solidDB® server in IBM InfoSphere CDC Replication deployments

The following restrictions apply to solidDB^® server when used as a source or target data server in IBM InfoSphere CDC Replication deployments.

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 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.

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.

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.

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.

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.

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.

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.

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, follow the instructions in the IBM InfoSphere CDC Management Console Administration Guide.