ORA-23313: object group is not mastered at

DISCLAIMER:

Solution presented below is a last resort solution. Official Oracle stand is that you should NEVER ever make any change in data dictionary. Always double check and make notes and backups. Use on your own risk.

One of our customers made a copy of production database (11.2.0.4) to test environment. Administrator also made all necessary changes to environment and database. When I wanted to drop our master replication group, I’ve got following error:

begin DBMS_REPCAT.DROP_MASTER_REPGROUP('MYREPGROUP'); commit; end; Error report: ORA-23313: object group "PUBLIC"."MYREPGROUP" is not mastered at MYDB.MYNEWDOMAIN.COM ORA-06512: at "SYS.DBMS_SYS_ERROR", line 105 ORA-06512: at "SYS.DBMS_REPCAT_UTL4", line 2870 ORA-06512: at "SYS.DBMS_REPCAT_MAS", line 2662 ORA-06512: at "SYS.DBMS_REPCAT", line 635 ORA-06512: at line 2 23313. 00000 -  "object group \"%s\".\"%s\" is not mastered at %s"

I queried dba_db_links and everything looked fine. So I checked database domain and global name:

SELECT * FROM GLOBAL_NAME; GLOBAL_NAME           ---------------------- MYDB.MYNEWDOMAIN.COM show parameter domain; NAME        TYPE        VALUE           ----------- ----------- ----------------- db_domain   string      mynewdomain.com

Changes he made also (unfortunately) included change of database domain and global name.

Usual solution would be to revert changes by:

alter system set db_domain='mydomain.com' scope=spfile;
alter database rename global_name to MYDB.mydomain.com;

Then bounce database, drop master replication group, change database domain and global name back and bounce database.

Unfortunately I was not able to implement this solution since database bounce was not possible because of running tests.

In the end I had to do following change in data dictionary to be able to drop master replication group:

alter table system.REPCAT$_REPSCHEMA disable constraint REPCAT$_REPSCHEMA_DEST;
update system.REPCAT$_REPSCHEMA set dblink='MYDB.MYNEWDOMAIN.COM' where sname='MYREPGROUP';
update SYSTEM.DEF$_DESTINATION set dblink='MYDB.MYNEWDOMAIN.COM' where dblink='MYDB.MYDOMAIN.COM';
alter table system.REPCAT$_REPSCHEMA enable constraint REPCAT$_REPSCHEMA_DEST;

I encourage you to study impacted tables very carefully and make backup copy before making any change. Triple check any change you are about to make. Don’t forget about remote sites which you should try to handle before dropping master site. Principle is the same, but usually change in database link is sufficient.

Presented change was done with knowledge that we WILL drop whole replication group and recreate it from scratch. We were not concerned with any delayed transactions.