When encrypting a VARCHAR2 datatype using Oracle's dbms_obfuscation_toolkit, it is observed that the target column may have a value that is different from the source's value.
Encryption and decryption on a VARCHAR2 field is not supported by Shareplex because there may be changes in the width of the content on the target.
Theoretically, SharePlex should be able to support this feature. A value is obfuscated (encrypted) using one of a set of encryption measures that are offered by Oracle (MD5, DES3, etc.); data is encrypted using a [private] key, resulting in what for all practical purposes is a RAW quantity. SharePlex should be able to transport this quantity to the target, where it gets posted in its encrypted form; anyone desirous of extracting this value from the target database should decrypt the obfuscated quantity using the same key with which it was encrypted on the source.
The problem comes from the fact that Shareplex has to post VARCHAR column values encoded as RAW quantities. Moreover, when encrypting the VARCHAR2 content to raw and then decrypting the raw back to VARCHAR2 datatype, the size of the value can change which can result in the target column receiving a value different than that on source. So you may see that the target row is out of sync with source.
The row cannot be sync'd with compare or Oracle Export/Import. A temporary workaround is to use Oracle's dblink to fix the target row. But any replicating table undergoing this type of encryption will face out of sync issues when dealing with VARCHAR 2 columns.
See attachment for extract from Oracle's Metalink document
