My 12c Cloud Control was already in 12c release 2 (18.104.22.168.0) so I just followed the procedure in Oracle official documentation available at:
I used the One System Upgrade approach…
My Oracle Management Server (OMS) is installed on a Red Hat Enterprise Linux Server release 5.4 (Tikanga) server…
I started by downloading the needed 6GB zip files (!!):
- em12103p1_linux64_disk1.zip (1,783,676,290 bytes)
- em12103p1_linux64_disk2.zip (1,689,422,062 bytes)
- em12103p1_linux64_disk3.zip (2,606,016,969 bytes)
All files are available on the official web page under Oracle Enterprise Manager Cloud Control 12c Release 3 Plug-in Update 1 (22.214.171.124) New! paragraph.
My repository back-end database is 126.96.36.199 so as stated in documentation I had to install generic patch 11061801. I also took the opportunity to put latest OPatch release by downloading patch 6880880.
The upgrade went very well and I have no issue to report (yessss) while using graphical upgrade…
As I have installed my Cloud Control on a NFS mount point I re-applied the modification described below with, to be honest, no real tangible behavior modification:
- 12c Cloud Control Performance: Rendering of Cloud Console Pages is Very Slow when OMS is Installed on NFS (Doc ID 1404077.1)
I have also tried to follow with again no real changes:
- Some 12c Cloud Control Database Pages Hang Or Are Very slow (Doc ID 1471643.1)
- 12c Cloud Control Performance: OMS Installed on a NetApp Filer with NFS Takes a Long Time to Startup (Doc ID 1385539.1)
Remain a big part that is to upgrade all agents to latest 188.8.131.52 release but fortunately 184.108.40.206 agents are compatible with 220.127.116.11 OMS…
Same as for Oracle Enterprise Manager Cloud Control 12c release 2 (18.104.22.168) upgrade I used the trick to move the agent from old Middleware home to new one. But this time when adding back the repository database I go the below error message:
Duplicate database system name found. Two databases cannot belong to the same database system, unless they both are primary and standby databases that belong to the same Data Guard Configuration.
When selecting direclty on repository database I noticed I still had my repository instance (emrep) listed as target type oracle_dbsys but not listed with same target name and oracle_database target type like for other target databases (and of course my repository database was not visible under Cloud Control):
SQL> SET lines 200 SQL> SET pages 100 SQL> col target_name FOR a50 SQL> SELECT target_name,target_type FROM sysman.mgmt_targets WHERE target_name LIKE '%server1%'; TARGET_NAME TARGET_TYPE -------------------------------------------------- ---------------------------------------------------------------- . . server1.domain.com_emrep oracle_dbsys . . 13 ROWS selected.
So I concluded the issue was generated while using below command:
emcli delete_target -name="server1.domain.com:3872" -type="oracle_emd" -delete_monitored_targets
I solved it using:
[oragc@server1 ~]$ emcli delete_target -name="server1.domain.com_emrep" -type="oracle_dbsys" Target "server1.domain.com_emrep:oracle_dbsys" deleted successfully
The Fusing Middleware home add went well using weblogic (and password) account and specifying 7101 secure port…
- Oracle Enterprise Manager Cloud Control Upgrade Guide 12c Release 3 (22.214.171.124)
- 12c: How to Delete Agent/Targets Using EMCLI Delete Verb. (Doc ID 1459204.1)
- Application Continuity (AC) for Java – JDBC HA – part 6 - September 13, 2018
- Transaction Guard (TG) for Java – JDBC HA – part 5 - August 27, 2018
- Fast Connection Failover (FCF) – JDBC HA – part 4 - August 7, 2018
- Fast Application Notification (FAN) – JDBC HA – part 3 - July 27, 2018
- Transparent Application Failover (TAF) – JDBC HA – part 2 - July 16, 2018
- JDBC client high availability features – JDBC HA – part 1 - July 5, 2018