|
Usually these types of performance problems are fingered through the same mechanisms that normal performance problems are identified. Monitor the execute_error transaction as you would any other slow processing transaction.
That said, there are a couple of replication-specific areas to look at. I would walk through these, in order.
- Be sure you are not running into any locking scenarios related to the normal execution of distributed transactions against your master table. In other words, verify you aren't doing a refresh or a push at the same time you are trying to re-execute the error.
- Reorganize the master table.
- Apply the transaction manually and delete the error from the queue using the dbms_defer_sys.delete_error package. There is no rule that says your deferred transaction has to be applied through your replication architecture. In fact, unless I have many errors queued (in which I use dynamic SQL to re-execute each one) I usually correct the error, apply the data transaction myself and then do a simple execute behind it for all the queued transactions that haven't fired yet.
I hope this helps.
|
