GRID CONTROL DOES NOT COMMIT REPLICATION CHANGE ON REMOVE TRANSACTION
(Doc ID 1353914.1)
Last updated on NOVEMBER 22, 2011
Applies to:Enterprise Manager Base Platform - Version: 126.96.36.199 to 188.8.131.52 - 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
184.108.40.206 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
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document