OMS 12.1.0.4 was recently announced. This is a record of my attempt to upgrade from OMS 12.1.0.3.2 (which I had patched in 13 Patch OMS to 12.1.0.3.2) to 12.1.0.4.
Followed the procedure in 4.1 Upgrading Enterprise Manager in a Single-OMS Non-HA Environment.
According to 2.3 CPU, RAM, and Hard Disk Space Requirements for Oracle Management Repository, I am going to have difficulty running the OMR on GRIDCTRL because I am limited to 4GB and unable to give the necessary 6GB of RAM needed for a small deployment.
Used the WebLogic console at https://cronulla.yaocm.id.au:7102/console to stop the BI Publisher server (BIP).
According to 6.3 Prerequisites, I would seem to be okay as I have an existing OMS deployment, and the OMR has been patched to 11.2.0.4.2 (See 12 Apply PSU 11.2.0.4.2 to REPOS).
No snapshots were found for the SYSMAN user in the REPOS database.
Since the REPOS database has been patched to 11.2.0.4.2 See 12 Apply PSU 11.2.0.4.2 to REPOS), no extra patches are needed.
I used the following command to backup the OMS configuration to the home directory of the oracle user:
${OMS_HOME}/bin/emctl exportconfig oms -sysman_pwd ${PW} -dir /home/oracle
The result is:
Oracle Enterprise Manager Cloud Control 12c Release 3 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. ExportConfig started... Machine is Admin Server host. Performing Admin Server backup... Exporting emoms properties... Exporting secure properties... Export has determined that the OMS is not fronted by an SLB. The local hostname was NOT exported. The exported data can be imported on any host but resecure of all agents will be required. Please see the EM Advanced Configuration Guide for more details. Exporting configuration for pluggable modules... Preparing archive file... Backup has been written to file: /home/oracle/opf_ADMIN_20140615_190427.bka The export file contains sensitive data. You must keep it secure. ExportConfig completed successfully!set|gre
After downloading the software into the shared folder called "Software", I had to use the root user to perform the following commands to unpack the software so that it can be used by the oracle user:
mkdir -p /opt/app/oracle/software/oms.12.1.0.4.0 unzip -qo /media/sf_Software/em12104_linux64_disk1.zip -d /opt/app/oracle/software/oms.12.1.0.4.0 unzip -qo /media/sf_Software/em12104_linux64_disk2.zip -d /opt/app/oracle/software/oms.12.1.0.4.0 unzip -qo /media/sf_Software/em12104_linux64_disk3.zip -d /opt/app/oracle/software/oms.12.1.0.4.0 chown -R oracle:oinstall /opt/app/oracle/software/oms.12.1.0.4.0
Since the upgrade to 12.1.0.4 is an out-of-place upgrade, I have to create a new directory for the middleware software through the oracle user:
mkdir -p /opt/app/oracle/em/middleware2
As recommended by 4.1 Upgrading Enterprise Manager in a Single-OMS Non-HA Environment, I used the following command to copy the key into the repository:
${OMS_HOME}/bin/emctl config emkey -copy_to_repos -sysman_pwd ${PW}
I used the following command to shutdown the OMS:
${OMS_HOME}/bin/emctl stop oms
As recommended by 4.1 Upgrading Enterprise Manager in a Single-OMS Non-HA Environment, I used the following command to shut down the agent monitoring the OMS on CRONULLA:
${AGENT_INSTANCE}/bin/emctl stop agent
Following the procedure in 5.1 Upgrading Oracle Management Service and Oracle Management Repository in Graphical Mode, I used the following command to start the installation:
cd /opt/app/oracle/software/oms.12.1.0.4.0 ./runInstaller
Since I use OMS to automatically check for software updates, I declined to provide my e-mail address as show below:
Click Next.
Click Yes.
At this stage, I decided to skip checking for software updates as shown below:
Click Next.
All of the prerequisite checks were passed as shown below:
Click Next.
I chose to do a one system upgrade as shown below:
Click Next.
Choose /opt/app/oracle/em/middleware2
as the Middleware Home as shown below:
Click Next.
Click Next.
The following warning appears:
I clicked OK because the OMR is patched to 11.2.0.4.2.
I now get the following three (3) errors:
I clicked Yes to allow the installer to fix these problems.
Now, I get the following three (3) warnings:
I clicked OK to promise that I will fix these problems after the installation has completed.
The following screen appears:
Click Next.
The following screen appears:
No new plug-ins were selected.
Click Next.
The following screen appears:
Left all values as is, and entered the weblogic password.
Click Next.
The following screen appears:
Click Install.
The following screen appears:
Click Install.
The terminal ouput has been captured as 16 Install.log.
After a while, the following screen appears:
I run the following script as the root user;
/opt/app/oracle/em/middleware2/oms/allroot.sh
The result is:
Starting to execute allroot.sh ......... Starting to execute /opt/app/oracle/em/middleware2/oms/root.sh ...... Running Oracle 11g root.sh script... The following environment variables are set as: ORACLE_OWNER= oracle ORACLE_HOME= /opt/app/oracle/em/middleware2/oms Enter the full pathname of the local bin directory: [/usr/local/bin]: The file "dbhome" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y Copying dbhome to /usr/local/bin ... The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y Copying oraenv to /usr/local/bin ... The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n) [n]: y Copying coraenv to /usr/local/bin ... Entries will be added to the /etc/oratab file as needed by Database Configuration Assistant when a database is created Finished running generic part of root.sh script. Now product-specific root actions will be performed. /etc exist /opt/app/oracle/em/middleware2/oms Finished execution of /opt/app/oracle/em/middleware2/oms/root.sh ......
I click OK.
The following screen appears:
Click Close.
Since the OMS is still down, I used the following command to start the OMS before doing anything else:
/opt/app/oracle/em/middleware2/oms/bin/emctl
Used the procedure described in 6.4 Upgrade Procedure to upgrade the agents. I had to download new agent software for GRIDCTRL because it has a different operating system (Linux-x86 32-bit) to CRONULLA (Linux-x86 64-bit).