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 additional errors if subsequent transactions depend on 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 create a separate stable queue, called the materialization or dematerialization queue. You cannot use resume connection to explicitly skip transactions in this queue. However, transactions may 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 resume connection to skip the request, the replicate database has the effects of the previously committed transactions, where some of the transactions in the queue were applied to the replicate database although the materialization or dematerialization request was skipped after the failure.
Because of these implications, skip transactions only after exhausting other means of correcting the error. After skipping a transaction, determine what you must do to bring the replicated data back to a state of consistency.