This content has been marked as final. Show 4 replies
I have seen the exact same behavior. For many reasons, I cannot and do not wish to utilize the deployment procedure mentioned in the Oracle document. Upon further studying it anyways, it does the same things:
1) check the file system for the SW library
2) upload the plugins
3) creates a backup OMS with omsca
4) imports the config from the initial OMS
So I did a SW only install, with 220.127.116.11 and OEM 12c BP1 both 32-bit and 64-bit. I also get the error on two OS fresh installs of both my primary and secondary OMS. In my server logs (emoms.trc) I have seen missing cn=SYSMAN "LDAP" errors. It seems the SYSMAN_APM schema or something like that has errors under 18.104.22.168.
The curious thing, I have done this procedure twice with 22.214.171.124, patched to PSU2 and it worked like a charm. I am thinking [but cannot explain why] that it is an Oracle database bug.
I installed my primary OMS and added some custom plugins we have. I also added an agent. I installed DB 126.96.36.199 on both my primary and backup. Then I used omsca -nostart, emctl importconfig, pluginca to create and configure a standby OMS. It worked.
Can you re-try your procedure with 188.8.131.52 ?
I was unable to use the DP because of several things.
I do not, and will not be able to have a mirrored storage for the SW library. This secondary OMS is meant to be the passive OMS in an active passive setup, where we may migrate to it in case of the primary site going down.
The DP procedure did some sort of test to verify whether we had the shared storage so I could not proceed on it. It alerted me to an error.
We also had bandwidth limitations, the operational network has capped our usage to a rate that would be impossible to copy the software installers across the WAN. We do have the bandwidth for an initial bootstrap (omsca, pluginca, importconfig) but not shipping database and OEM 12c install binaries or files across the network.
We were also depending on a very quick deployment time, currently our customer gives us very short deployment and maintenance windows. With our model, we deploy the software to disks, which ship out to the field, as configured as possible. We already had SW installs of OEM 12c and Oracle Database.
While I think Oracle's DP is nice, it should not be advertised as the ONLY way to create a secondary OMS. We found the sequence of 'omsca, pluginca, importconfig' to work.
With 184.108.40.206 I get the ADFC error, but with 220.127.116.11 it works correctly, so I am wondering if there is a bug in 18.104.22.168 database that causes some Repository configuration actions to silently fail.