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 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 in “Compromising transaction integrity” can occur. For instructions on enabling and disabling replication for LOB columns, see the Replication Agent Administration Guide.
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 are 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 is corrected.
