Replication Server Support for Compressed Data

Replication Server does not perform any decompression and replicates the compressed LOB columns from the primary Adaptive Server database, in compressed format, and without decompressing the text values.

Replication support for compressed data between Adaptive Server databases depends on whether the data is in-row or off-row and whether the datatype is LOB:
You must specify the compressed LOB column as image datatype in your replication definitions. For example:
create replication definition pubs_copy_rep
with primary at TOKYO_DS.pubs2
with primary table named 'publishers'
with replicate table named joe.'pubs_copy' 
(pub_id, pub_name as pub_name_set, au_photo image)
primary key (pub_id)

If you have set LOB compression on for the LOB columns in existing tables, do not enable high-volume adaptive replication (HVAR) if sp_configure "enable compression" is set to 0.

Updates do not replicate correctly when you change large object compression on a table and you:
  1. Initially mark the column as compressed in Adaptive Server.
  2. Use sp_setrepcol with the always_replicate parameter to enable replication of a compressed LOB column in your table replication definition.
  3. Perform some inserts, and
  4. Mark the column as not compressed in Adaptive Server.

To ensure updates replicate correctly, use sp_setrepcol with the replicate_if_changed parameter to enable replication of the LOB column in your table replication definition.

To prevent corrupt data in the stable queues, use sp_setrepcol to disable replicating off-row compressed LOB columns if the primary and replicate Adaptive Server databases do not have identical LOB schema, character set, endian architecture, version, and page size, or if all Replication Servers in the route have site versions earlier than 15.7.1:
sp_setrepcol table_name, lob_column_name, ‘do_not_replicate’
If you do not do this, you must drain corrupted data from the queues.