Unsupported Datatypes

Owned by Copy Space for Confluence
Last updated: Oct 26, 2017 by Vijayganesh Sivaprakasam
Unsupported datatypes are:
  • TIMESTAMP WITH TIMEZONE (TZR) and (TZD)*
  • UROWID
  • ANYDATA
  • ANYTYPE
  • ANYDATASET
  • URITYPE
  • SDO_GEOMETRY
  • SDO_GEORASTER
  • SDO_TOPO_GEOMETRY
  • ORDDICOM
  • Some SECUREFILE LOBs operations (see below)
  • identity columns (Oracle 12c)


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


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 Replicate versions 2.8 and earlier, 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 is supported starting from Replicate version 2.9. Therefore, ROWID can 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.

Unsupported NOT NULL constraints on CLOB, BLOB, NCLOB datatypes.

  •  If Target database is Oracle and if any of the LOB columns have a NOT NULL constraint because of internal implementation we advise alter the constraint as deferred on the target table columns so it will be checked at the end of the transaction after update of LOB instead of beginning. The alternative is to disable the NOT NULL constraint on the target table columns. If you do not do either you may have a conflict due to the way we insert LOBS into the target.