GRID CONTROL DOES NOT COMMIT REPLICATION CHANGE ON REMOVE TRANSACTION
Last updated on NOVEMBER 22, 2011
Applies to:Enterprise Manager Base Platform - Version: 184.108.40.206 to 220.127.116.11 - Release: 11.1 to 11.1
Information in this document applies to any platform.
Trying to use the OMS to resolve some replication problems with some
18.104.22.168 databases. There were transactions sitting in the queue to be applied
at one site. When using the old Enterprise manager V10.2.0.0.0 we could see
the transactions, choose to retry them and apply this request. When trying to
do the same through the Enterprise manager Grid Control we could see the
transactions in the queue and retry them but the request never seems to
commit. It locks all of the required tables but never completes. We need to
kill off the process to release the locks and then retry with the old tool. we
are trying to move to using the new EM 11g Grid Control rather than the old EM
It works when we use Enterprise Manager 10.2. Grid Control just doesn't seem
to have a commit/apply button. It is like it queues up the transaction but
there is no way of telling it to commit the change.
on the Advanced Replication -> Administration: Error Transactions page
Grid Control issues a:
BEGIN DBMS_DEFER_SYS.DELETE_ERROR ( deferred_tran_id => '.......
This is a transactional operation and requires a commit, but Grid Control
never issues the commit. As a result the error transaction remains in the
deferror view and a number of exclusive locks are left in the database.
the locks are only released when you log out of the database session from
Grid Control as this finally issues a commit.
It works in older version of Grid Control/EM
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms