This content has been marked as final. Show 8 replies
It sounds like you are trying to build a DR solution. If that is your objective you should follow the guidelines in the Enterprise Administrator's guide which uses Data Guard to propagate database changes to a remote site.
To a point, yes. My overall goal in this was thought to be simple. I am beginning to think the setup is not possible with my current version (OEM 12c BP1 and Database 220.127.116.11). My overall goal is this:
I have one OEM and one repository, monitoring a collection of sites. I would like a copy of that OEM on another server, and a copy of those sites. The second OEM would show everything as down, because everything would be connected (through ssh tunnels) to the first OEM. If I brought down the tunnels on the first and made tunnels on the second...then the second OEM would show the sites as UP and the first OEM would now show everything as down. It seemed like a simple implementation for a very BASIC failover scenario. I am just having a lot of issues with making sure the second OMS is pointing at its own repository. Right now, it seems like it is still pointing at the first OMS' repo, regardless of the emctl verbs I have run to reconfigure it.
When I run ./emctl config emrep -agent #####:3872 I get an error. Not eligible to move Management Services and Repository:oracle_emrep due to ORA-01403: no data found
ORA-06512: at "SYSMAN.EM_TARGET_RELOCATE", line 34
ORA-06512: at "SYSMAN.EM_TARGET_RELOCATE", line 295
ORA-06512: at line 1
No targets qualify for move from <firstOEM>:3872 to <secondOEM>:3872
And then it repeats that error for EM Management beacon on the same hosts.
Also noticed that when I perform emctl status emkey, it complains about it being corrupt or not configured properly. It says to perform an emctl config emkey -copy_to_credstore...but that fails.
See Enterprise Manager Cloud Control Administrator’s Guide: 13.6.1 Configuring the emkey.
- what is the exact message returned by emctl status emkey?
- have you backed up your emkey? emctl exportconfig includes the emkey, and the out-of-box install puts a copy
OEM has the hostname of it's OMS and repository embedded in all it's moving parts... do your machines have the same name? I think following the tested/supported HA implementation of creating a true Standby OMS would be much simpler in this case.
No, the hostname is definitely different. The problem is, with the HA implementation, it implies that the database version is 18.104.22.168. Unfortunately, we are still on 22.214.171.124 and don't think an upgrade would be a viable immediate solution.
Database version 126.96.36.199 will be fine. There is no requirement for 188.8.131.52 for an HA deployment.