In my blog post
about the release of EM12c R2, I told that I will test to upgrade my
current EM12c, so here’s the blog post I promised: As you may know,
Oracle offers only the 1-system upgrade method for EM12c R2. I started
with backing up my EM12c R1 (+ BP1) environment (DB, OMS), then I downloaded EM12c R2 installation files.
I created a directory, moved the installation files there and then unzipped the files:
I logged in as SYSMAN to repository database and checked if the tables in the Management Repository do not have any snapshots created:
As you see there were no snapshots. According to the upgrade document, if there are snapshots, I should drop them. While my OMS is still running, I run the following command to copy EMKEY to repository database:
It asked SYSMAN password, and then warned me that this operation will cause the EMKey to become unsecure. I have checked again to be sure that EMKey is configured properly:
Then I shutdown OMS and management agent that monitors the OMS and Repository DB:
Although it’s not mentioned in upgrade documents, I wanted to remove EM jobs from repository database, so I logged in as SYSMAN and run:
I run the installer in /u01/setup: ./runInstaller
I have unchecked the option to receiving security email notifications, and then accepted the warning about how important it is. On next screen, I entered my MoS credentials and checked if any updates available. Luckly, there was nothing.
I haven’t got any warning or failure on this screen, and I recommend you to satisfy all prerequisite checks.
I chose the one system upgrade (so my current OMS became selectable), then I selected it.
I entered the new location of Oracle Middleware (it should be an empty directory).
On next screen, I entered the SYS and SYSMAN passwords. When you click Next, the installer will check the DB connection and also DB settings (such as redolog sizes, shared_cursors etc) like it does in regular installation. The installer can fix some of them (it will ask you if you’re agree), but some of the warnings should be fixed by you. It’s possible to ignore these warnings but I recommend you to fix them. After this step, you’ll see “plug-in upgrade” screen, just click “next button”.
You may add new plug-ins but I recommend you to not to do it when upgrading. You can do it after upgrade.
I entered the weblogic password, and entered a directory name for OMS. After this step, you review the settings and then start installation.
It took about 2 hours on my virtual server. Now we’re ready to re-enable EM jobs (yes I know it was not necessary) and check if there are any invalid objects in EM repository. I also set “job_queue_processes” to 1000 (The installer set it to 0):
Now it’s time to upgrade agents! EM12c R2 has a great utility called “Upgrade Agents Console”.
Logged in to EM12c R2 console, after regular warnings about “security certificate”, I clicked “Setup”, then “Manage Cloud Control” (this is a new menu item), then click on “Upgrade Agents”. I added agents I want to be upgraded and then click submit. If you have not set privlidge delegation settings for your hosts, the user running Management Agent can not switch to root user. In this case, you should run the root.sh script as root, after the upgrade job is done:
I’m really impressed! All upgrade process completed without any problems
I created a directory, moved the installation files there and then unzipped the files:
I logged in as SYSMAN to repository database and checked if the tables in the Management Repository do not have any snapshots created:
As you see there were no snapshots. According to the upgrade document, if there are snapshots, I should drop them. While my OMS is still running, I run the following command to copy EMKEY to repository database:
It asked SYSMAN password, and then warned me that this operation will cause the EMKey to become unsecure. I have checked again to be sure that EMKey is configured properly:
Then I shutdown OMS and management agent that monitors the OMS and Repository DB:
Although it’s not mentioned in upgrade documents, I wanted to remove EM jobs from repository database, so I logged in as SYSMAN and run:
I run the installer in /u01/setup: ./runInstaller
I have unchecked the option to receiving security email notifications, and then accepted the warning about how important it is. On next screen, I entered my MoS credentials and checked if any updates available. Luckly, there was nothing.
I haven’t got any warning or failure on this screen, and I recommend you to satisfy all prerequisite checks.
I chose the one system upgrade (so my current OMS became selectable), then I selected it.
I entered the new location of Oracle Middleware (it should be an empty directory).
On next screen, I entered the SYS and SYSMAN passwords. When you click Next, the installer will check the DB connection and also DB settings (such as redolog sizes, shared_cursors etc) like it does in regular installation. The installer can fix some of them (it will ask you if you’re agree), but some of the warnings should be fixed by you. It’s possible to ignore these warnings but I recommend you to fix them. After this step, you’ll see “plug-in upgrade” screen, just click “next button”.
You may add new plug-ins but I recommend you to not to do it when upgrading. You can do it after upgrade.
I entered the weblogic password, and entered a directory name for OMS. After this step, you review the settings and then start installation.
It took about 2 hours on my virtual server. Now we’re ready to re-enable EM jobs (yes I know it was not necessary) and check if there are any invalid objects in EM repository. I also set “job_queue_processes” to 1000 (The installer set it to 0):
Now it’s time to upgrade agents! EM12c R2 has a great utility called “Upgrade Agents Console”.
Logged in to EM12c R2 console, after regular warnings about “security certificate”, I clicked “Setup”, then “Manage Cloud Control” (this is a new menu item), then click on “Upgrade Agents”. I added agents I want to be upgraded and then click submit. If you have not set privlidge delegation settings for your hosts, the user running Management Agent can not switch to root user. In this case, you should run the root.sh script as root, after the upgrade job is done:
I’m really impressed! All upgrade process completed without any problems
No comments:
Post a Comment