Skipping transactions that cause errors forces the Data Server Interface (DSI) to resume applying transactions to the database. However, this method has important implications for the database.
Replicate data may become inconsistent with primary data.
If an asynchronous transaction originates in a replicate database, and the transaction is skipped at the primary data server, the primary database is not updated.
The inconsistency caused by skipping a transaction may result in even more errors if subsequent transactions depend upon the unapplied actions of the skipped transaction.
Subscription materialization and dematerialization requests are special types of transactions. If you skip a subscription materialization request, it may invalidate the subscription and must be dropped.
A subscription materialization or dematerialization request may cause Replication Server to create a separate stable queue, called the materialization or dematerialization queue. You cannot explicitly skip transactions in this queue using the resume connection command. They can, however, be skipped due to data server errors that are assigned the log or retry_log action.
If a subscription materialization or dematerialization request is skipped, all transactions in the corresponding queue may be skipped. However, if a DSI is suspended in the middle of applying the transactions in a materialization or dematerialization queue, some of the transactions in the queue may already have been committed while others may not. Later, if you use the resume connection command to skip the request, the replicate database will have the effects of the previously committed transactions.
Because of these implications, you should skip transactions only after other means of correcting the error have been exhausted. After skipping a transaction, determine what you must do to bring the replicated data back to a state of consistency.