Enterprise Manager | The ORACLE-BASE Blog

Cloud Control 13.4 : Silent Installation and Silent Upgrade

A little over a week ago Enterprise Manager Cloud Control 13.4 was released. The following weekend I spent 3 days running builds constantly trying to get a clean install to work. Eventually I tweeted out in frustration and a friendly face at Oracle, who I’ve stalked on numerous occasions, put me in touch with the EM dev team.

Having had a quick look at my Vagrant build, they suggested I unset the CLASSPATH environment variable, and a working build was born. Thanks very much to the EM dev team! Without them I would have spent days looking at it and would probably still have failed.

Installation

The resulting Vagrant build and an article about the silent installation of Cloud Control 13.4 can be found here.

One thing that still irks me somewhat is the documentation about the adaptive optimizer parameters. The documentation says the following.

“If your Management Repository is using Oracle Database 12.2 or higher, none of these parameters need to be set.”

This is not true, and you always get this error message.

“ERROR:
The following prerequisite check failed because the Oracle Database, where the Management Repository will be configured, does not meet the configuration requirements. Fix the issue manually based on the recommendation offered for this prerequisite, and click OK. For more details, check the logs: /u01/app/oracle/middleware/cfgtoollogs/oui/emdbprereqs
Prereq Name Recommendation
Check if all adaptive features parameters are unset All adaptive features parameters should be unset for improved SQL performance”

I even tried a GUI installation, in case there was a difference between the GUI and silent installations. There wasn’t.

The workaround is to amend a bunch of underscore parameters that are only meant to be necessary when running a patched version of Oracle database 12.1 as the repository database.

alter system set "_optimizer_nlj_hj_adaptive_join"= FALSE scope=both sid='*'; 
alter system set "_optimizer_strans_adaptive_pruning" = FALSE scope=both sid='*';
alter system set "_px_adaptive_dist_method" = OFF scope=both sid='*'; 
alter system set "_sql_plan_directive_mgmt_control" = 0 scope=both sid='*';
alter system set "_optimizer_dsdir_usage_control" = 0 scope=both sid='*'; 
alter system set "_optimizer_use_feedback" = FALSE scope=both sid='*';
alter system set "_optimizer_gather_feedback" = FALSE scope=both sid='*'; 
alter system set "_optimizer_performance_feedback" = OFF scope=both sid='*';

It’s not a show stopper, so I can live with it, but it’s annoying, and the documentation should be altered to reflect the reality.

Upgrade

The next challenge was to work through an upgrade from a previous release. I worked through this using a starting point of 13.3. I already had a vagrant build for 13.3, but I made a few changes to bring it up to date, and add some more disk space. I also renamed the directory structure to make things a little neater.

The upgrade itself was very similar to that of the previous version. You can find the article about the silent upgrade to 13.4 and the Vagrant build I used to test the upgrade here.

Now remember, this is a simple upgrade of a totally clean 13.3 build to 13.4, so I’m not saying this is an exhaustive test, and I’m not saying this is proof it will work for you.

Next Steps

The next challenge will be to try a real upgrade at work. Work is crazy at the moment, so I’m not sure how long I will have to wait before doing this.

Most of our kit is VMware virtual machines running Oracle Linux, and the Cloud Control server is no exception, so I can get a backup of the whole VM before the upgrade, and just restore back to that in case of a disaster.

An ideal place to be is to have your build scripted, including the reconfiguration of all your targets. After a previous “issue”, I went through our existing config and built the EMCLI scripts to replace it all. I *think* I can rebuild everything from scratch if I need to. We do all new agent installations, target discovery and setup using EMCLI now, so I think all the retrofitted stuff will work too, but I have to admit I’m kind-of scared to try. 🙂

Conclusion

I don’t like to do anything at work unless I’ve already done it at home first. It’s taken me pretty much 5 full days (Fri, Sat, Sun, Fri, Sat) to get through this, but it’s done now, and I feel I can have a try at work without looking like a total fool now! 🙂

Cheers

Tim…

Enterprise Manager Cloud Control 13.3 Vagrant Build

A little short of a year ago I knocked up a Vagrant build to prepare an environment for practising Cloud Control 13.3 installations and upgrades. This just automated the creation of the environment and installation of the database, ready for me to start playing around with the Cloud Control bit. At the time I released these articles.

I didn’t mention anything about the Vagrant build as it didn’t do much more than build the database, so it didn’t seem worth mentioning. It was just a convenience for me.

More recently someone pointed it out on Twitter and I made a note to myself to “finish it off” and make it do a full silent build, then kind-of forgot again.

A few days ago I had a self-induced problem with our Cloud Control server, and I realised I didn’t have the best plan of action for a complete rebuild scenario. I had backups, so I didn’t need to do a rebuild, but that doesn’t stop me wanting to be able to do it, so I did the following things…

I scripted a silent build of the work environment we use. I put together a general article to show how to do a silent build of a simple installation too. If you’re interested you can see it here.

Oracle Enterprise Manager Cloud Control 13c Release 3 (13.3.0.0) Silent Installation on Oracle Linux 7

I wrote some EMCLI scripts to do most of the tasks I needed for a complete rebuild. We already use EMCLI for some of the stuff, like jobs, but I filled in the gaps where I had been a bit lazy. Those are all checked into a company Git repo, and they are quite specific to what we need, but there are some basic EMCLI examples available here, if you are interested in getting into EMCLI.

EMCLI : Enterprise Manager Command Line Interface

Finally, I made my Vagrant build a fully automated Cloud Control 13.3 build on Oracle database 18c. According to the certification matrix, Oracle 19c is not yet certified for the repository database (but someone on Oracle-L said this certification is imminent (See Update)). If you are interested in playing around with Vagrant, you can find it here . I’ve managed to get away with 6G of memory, but that makes it chronically slow. The more memory you can throw at it the better. 🙂

I didn’t really expect to be revisiting this stuff a year down the line, but it was born out of necessity, or at least necessity for my peace of mind. 🙂

Cheers

Tim…

Update: The OMS is now supported on Oracle database 19c.

Enterprise Manager Cloud Control 13c : Navigation and “Look and Feel”

o-enterprisemgr-13c-clr-2769481 I’ve continued to play around with Cloud Control 13c and I’m generally getting a nice vibe from it.

One of the things I really hated about Grid Control 10g and 11g was the navigation. It felt like you had to click on 50 links to get to the thing you wanted. When Cloud Control 12c came along and had a main menu it was a massive improvement. Even so, it was still a little annoying as the menu was split, with some bits on the left and some bits on the top-right.

In Cloud Control 13c, these menus have been brought together into the top-right of the screen.

If the screen size is smaller, the buttons collapse to show just the icons, which saves space.

It probably sounds really trivial, but having both menus together is a really nice touch. I can’t count the number of times I’ve been fumbling around, unable to find something, only to remember it is in that blasted menu at the top-right. Now there is no excuse. 🙂

The job scheduler navigation is also a lot nicer. In Cloud Control 12c we had a bunch of drop-downs and a “Go” button.

em12c-jobs

In Cloud Control 13c there are tiles along the top to alter the context of the output and the tree on the left allows you to quickly flip between criteria.

em13c-jobs

It is so much quicker to get the information you want this way.

So as far as I’m concerned, Cloud Control 13c is getting a big thumbs-up from a navigation perspective!

A couple of people have asked my impression about the new look and feel. If we ignore the navigation, most of the pages are quite similar to what we had before, so there is no need to panic. Overall it has a sparser, cleaner look, which is more in keeping with the way the web is these days, so I think that’s a good thing. Anyone who has used Oracle Cloud will find the look very familiar. 🙂

I guess the biggest bonus of the new look and feel is it is more responsive. On some of the old pages you had a lot of sideways scrolling to do if you have a small browser window. The new look and feel deals a lot better with that. It’s not perfect, but it is better. So I’m giving the new look and feel a big thumbs-up too!

Being the bitter old man that I am, I reserve the right to change my mind and hate it all in the future. 🙂

Cheers

Tim…

Caveat: I use a very small subset of the functionality available from Cloud Control, so my opinion is going to be based on the bits I use a lot. It might be that other areas have been adversely affected by the new navigation or look and feel, but the bits I care about are looking good.

Enterprise Manager Cloud Control 13c Upgrade

A couple of weeks ago I posted about doing a fresh installation of Enterprise Manager Cloud Control 13c (article, blog post). I’ve finally got around to doing an upgrade test from EM CC 12cR5 to 13cR1. You can see the result of that here.

Upgrade Oracle Enterprise Manager Cloud Control 12c Release 5 (12cR5) to 13c Release 1 (13cR1)

Gokhan Atil did a post about this upgrade pretty much as soon as it was released, so I’m a little late to the party compared to him. 🙂

As you’ll see from the article, the upgrade process was similar to the patches that came before it. There are of course some extra prerequisites which you can read about in either my post, Gokhan’s or the docs…

Even though the upgrade tests were fine, after discussion with our system administrators, we are probably going to go for a clean installation and migrate the monitored hosts one at a time.

Why the slash and burn approach? I’ve made some mistakes with our installations in the past and they persist with every subsequent upgrade. It would be nice to take a step back and fix stuff. We are doing a similar thing with our WebLogic installations. I was learning new stuff all the time while I was installing our WebLogic 11g infrastructure. Rather than upgrading to WebLogic 12cR2, we are going to build a new infrastructure, migrate to it and throw the old one away.

This is relatively easy for us for a few reasons.

We use virtualization for everything. We will provision the new VMs, set everything up. Start migrating stuff. When the migration is complete we will throw away the old VMs. No major hardware overhead.
We are a pretty small operation. If we had a massive amount of infrastructure, a slash and burn approach would be very time consuming and as such, very costly.
I am really anal about some things and I am willing to go the extra mile to get things right. I did the best I could at the time, but I’m happy to admit I made mistakes and I want to sort them out. This is not because I’m a company boy. It’s because those mistakes eat away at me and I want them eradicated so they will only haunt me in my memories, not in my day to day life.

If we had been going for the upgrade approach, I probably would have done it in the next couple of weeks. With clean slate approach, we’ll probably take a few more weeks to get ready for it. No point rushing in and making more mistakes. I would rather let the idea brew for a while before we start. 🙂

Cheers

Tim…