In this document, all columns that contain large object (LOB) datatypes are referred to as LOB columns, regardless of the actual datatype name used by the primary database vendor. To replicate transactions that affect a LOB column, replication must be enabled for that column.
You must enable replication for each LOB column you want to replicate, in addition to marking and enabling replication for the table that contains the LOB column.
If the value of the pdb_dflt_column_repl parameter is true, replication is enabled automatically for all LOB columns in a table at the time the table is marked.
If the value of the pdb_dflt_column_repl parameter is false, replication is not enabled automatically for any LOB columns in a table at the time the table is marked.
For more information on marking a table for replication see “Marking and unmarking tables”.
When a table is marked for replication and replication is enabled for that table but not for a LOB column in that table, any part of a transaction that affects the LOB column is not replicated. The portion of a transaction that affects all other non-LOB columns is replicated if the table is marked for replication and replication is enabled for the table.
When replication is enabled for a LOB column, Replication Agent makes an entry in the prefixBLOB_COLUMNS_ table to support replication for that column.
When Replication Agent triggers process a transaction that affects a LOB column, the LOB data is not stored in the transaction log because of its possible size. Instead, the Replication Agent Log Reader component reads the LOB data directly from the primary database at the time it processes the transaction.
Because of the way Replication Agent processes the LOB column data when replicating transactions, it is possible to compromise transaction integrity. For example, if two transactions change the data in a LOB column and the Log Reader does not process the first transaction until after the second transaction has been committed, when the LOB data is read from the primary database, the value of that data is the result of the second transaction. In this event, the value of the LOB data in the first transaction is never sent to the replicate database. After the second transaction is processed by the Log Reader, the primary and replicate databases will be synchronized again, but for a period of time between processing the first and second transactions, the replicate database contains data that does not match the originating transaction.
This problem occurs only when a LOB column is changed more than once by a sequence of transactions. The period of time over which the problem exists could be significant if the replication system throughput is slow or if a replication system component fails. As soon as the last transaction that changes the LOB column is processed at the replicate site, the problem will be corrected.
In contrast, Oracle logs all LOB data (except for BFILE datatypes) in the Oracle redo log. This allows the Replication Agent to apply each individual LOB change. However, for BFILE data, the same technique is used as for the trigger-based solution and the same limitation exists—BFILE data is not logged but read from the database at the time the rest of the transaction is processed. If two consecutive transactions modify the same bfile, the same inconsistency described previously can occur.
For more information on LOB handling for Oracle, see the Replication Agent Primary Database Guide.
