The unsupported Unsupported datatypes are:
- BINARY_FLOAT
- BINARY_DOUBLE
- TIMESTAMP WITH TIMEZONE (TZR) and (TZD)*
- ROWID
- UROWID
- ANYDATA
- ANYTYPE
- ANYDATASET
- XMLTYPE
- URITYPE
- SDO_GEOMETRY
- SDO_GEORASTER
- SDO_TOPO_GEOMETRY
- ORD_DICOM
- Some SECUREFILE LOBs operations (see below)
- 32K VARCHAR identity columns (Oracle 12.112c)
*TIMESTAMP with TIMEZONE expressed as offsets are supported.
If SOURCE tables are created & configured with Oracle Basic Compress option (including at the tablespace level) replication is unsupported for these objects.
A SQL query can be run to determine if there are any datatypes that will not be supported by Dbvisit Replicate.
| Note |
|---|
The unsupported datatypes can be excluded from replication if not needed. The steps to excluding columns are discussed in more details here: Excluding columns from replication A few notes when excluding a ROWID column: - If a table consists of a ROWID column which is unsupported in 2.8 and earlier versions, the column can be excluded from replication straight away.
- If the ROWID column happens to be a PK too, excluding ROWID from replication is not enough. The PK constraint must be disabled first on target database prior to excluding ROWID. Otherwise, the conflict will still occur on target database as the ROWID PK column expects a value and cannot be null.
- If the table that has ROWID is IOT table, disabling PK constraint is not possible. Therefore, here are the options left:
- Option 1: ROWID will be supported in the upcoming release (2.9). Upgrading Replicate version to 2.9 (once released publicly) should allow ROWID to be included in replication.
- Option 2: Re-create the table on target as non-IOT tables so constraint can be disabled. It is possible however, that there could be performance issue as IOT provides faster access to table rows by the PK.
- Option 3: Exclude the tables that contains ROWID entirely from replication if feasible.
|