I have been closely involved in the upgrade discussion of my current customer’s Enterprise Managers setup from an engineering point of view. The client uses OEM extensively for monitoring, alerts generated by it are automatically forwarded to an IBM product called Netcool.
Now some of the management servers are still on 10.2.0.5 in certain regions, and for a private cloud project I was involved in an 11.1 system was needed.The big question was: wait for 12.1 or upgrade to 11.1?
So to cut a long story short I have been very keen to get to the OEM 12c beta programme, but unfortunately wasn’t able to make it. Also, I wasn’t at Open World this year which means I didn’t get to see any of the demos. You can imagine I was quite curious to get my hands on it, and when it has been released a few days ago I downloaded it to my lab machine. I created a new domU for the database-126.96.36.199 plus latest PSU and another one for the management server. I assigned 2 CPUs each, the database server got 2G of memory while the OMS received 8.Don’t take this as a recommendation though, it’s only for lab use! I wouldn’t use less than 24G of memory for a production management server, and it would obviously follow the MAA recommendations and be installed behind an enterprise grade load balancer etc. Needless to say I’d use RAC+Data Guard for the repository database.
The installation software comes in the form of 2 zip files which you download from OTN as usual, totalling some 5.5G for x86-64. Unzip them to a favourite location.
I decided to use Oracle Linux 5.7 as the OMS host since the documentation links were broken when I tried to figure out which platforms were supported, and a more conventional setup can sometimes be less painful. Additionally, I could use the oracle-validated RPM to set up the necessary system parameters although it later turned out that I was setting some that weren’t needed for OEM. It didn’t hurt either.
Even when using OEM purely in your lab it’s always a good idea to register your domUs in DNS. Not only do I have to do so because of the SCANs in RAC 11.2, but also want to ensure that naming resolution between OMS and targets works without problems.
One of the important things to remember though is to deactivate/modify the IPTables service and to set SELinux to permissive or lower. I had a failed “omsca” run because of firewall rules in place I didn’t spot.
I set 20G of space aside for my /u01 mount point, created as a LVM from a dedicated oracle volume group. Again, that’s not enough for production ;)
With all the prep work done I started a vncserver process on the OMS machine and started runInstaller from the unzipped file location. Spot the difference here? That is really it, you don’t have to
- Get an ancient, potentially bug ridden JVM from the sun archives and deploy it to your machine
- Get a very old version of Weblogic and install it separately
- Ask Oracle support for patch WD7J because the not-so-smart update can’t get it for you
This is a huge step into the right direction, but one wonders why it has taken Oracle so long to make a convoluted install process better. But then you might argue that you install only a few of them so it might be a bit of an IKEA experience (but without a lot of the fun).
After runInstaller has started, it greets you in its usual friendly way. As it is case these days with Oracle software, it prompts you for your My Oracle Support credentials-I usually skip this step.
I also opted to skip software updates on this next screen:
Since my 20G LVM is mounted to /u01, it was only natural to use /u01/app/oraInventory as the inventory location. I choose oinstall to own the software.
Funny enough, just by having applied the oracle-validated RPM plus its dependencies I managed to pass all the tests! What I didn’t know at this time was that the IPtables and SELinux settings weren’t detected-again, make sure you have set SELinux to permissive and modified/deactivated the firewall. Otherwise the omsca will fail trying to start the EMGC_OMS1 (sp?) server for deployment of the actual Grid Control software. The only warning I got was about swap space which I have a habit of ignoring. And honestly, I was only 1 M off…
Next I chose the “advanced” installation with a middleware home set to /u01/gc12.1. As it turned out the leading slash in the print screen wasn’t needed, and you shouldn’t use it.
Select the plug-ins you want on the next screen, bearing in mind that you might run into dependency problems until you have selected all relevant items from the screen.
On this screen you have the option to assign passwords to various users needed for weblogic. Also note the double // in the path-this is not recommended and a result of my previous setting of the middleware home location. I actually redid the installation for said IPtables problem and removed the trailing slash but don’t have print screens for it.
Enter the credentials and connection information for your repository database on this screen. Mine was 188.8.131.52.3, check the online documentation for required patches to your database home.
On this screen you define the repository details, a screen which is fairly self-explanatory. OUI then goes off and runs a number of checks against your database, mainly to see if certain init.ora parameters are matching the recommended standard. Interestingly AMM wasn’t recommended, instead OUI asked me to increase the values for sga_target and pga_aggregate_target. This hasn’t changed much from the OEM GC 11.1 days-ensure that you are happy with the settings, and bounce the instance if needed for them to take effect.
Towards the end of the OUI session you can make a choice of port ranges; experience told me that these are best left at their defaults.
Finally! The summary screen shows what you decided to do, it’s on two different print screens shown here:
Now it’s time for a coffee or two, the installation process on my lab took about 1 hour. The interesting part is that you can actually correct errors if they occur. The only MOS note for OEM 12.1 I found describes the location of the log files and should be your first port of call in case of problems.
Luckily there weren’t problems so I went on to run the root scripts which didn’t take any time at all to execute.
Step 9-success! I now have an Enterprise Manager 12.1 system!
I will need to spend some time experimenting with it to see what changed-I assume a lot. Should I find some more time I’ll create a few new posts about installing agents on the machines I’d like to monitor and other bits and bobs.