EM12c, Damage Control

I love EM12c, don’t get me wrong.  I wouldn’t post about it so much in my blog, tweet about it, working on two Apress books in support of the product if I didn’t.  The features, the broad range of support it provides the future of the database and development arena for Oracle is something that many have only dreamed about.  The problem is, some would say, is that some dreamed a bit too much and forgot to dot their i’s and cross their t’s.  Then when offered a work around to an i that wasn’t dotted or a t uncrossed, a choice to offer no better answers than a politician in the last election is offered.

The main EM12c product, in it’s initial release, possessed the main features that functioned quite well and with a bit of help from EMCLI, (Enterprise Manager Command Line Interface) commands, a DBA could use the newer main features for almost any environment.

In the main components, very few bugs existed, and as a few of us braved this new world,  we were offered work-arounds and a couple simple patches.  As news of advanced features and capabilities were broadcasted, folks started to explore them and that was when, in my opinion,  the “damage” started.

The features-  everything from auto deployment to synthetic monitoring to administration groups, required:

1.  The administrator to relearn how to perform management tasks that they had previously known how to easily deploy or configure in previous versions of Enterprise Manager.

2.  The previous versions of how these features worked had often been removed from the the new EM12c product offering to ensure that the replacement feature would be used.

3.  The new version of these previous features often experienced bugs hindering them from being deployed or configured as documented, requiring the administrator to open and SR with Oracle Support.

Oracle then chose to take the stance, “Apply BP1, (Bundle Patch1) which was supposed to correct most of these problems.  It is an involved process that requires not just a standard backup of the database, but the OMS home and other components.  It requires a downtime that for some, is considerable and difficult to commit to due to their reliance on the EM12c features.  The largest problem was, upon applying the BP1, there were still a large amount of bugs that existed, along with new ones that were introduced by the sheer quantity of patches included in BP1.

Now, the downtime complaint, Oracle addressed by creating a “recommended high availability” white paper with RAC, but at that point, having an EM12c environment without licensing, offered as part of your Enterprise Licensed production environment goes out the window and that wasn’t a great marketing message to many companies where the administrator had to sell how important having a monitoring system was in the first place.

For me, I have a number of clients that are only allocated 30-70 hours of my time a month.  They worked very hard to allocate project hours through their company to have me implement an EM12c environment for them after I convinced them it was the way to go, (and I still feel it is!)  Now, for me to approach those customers and tell them that after the work I did for them to set up their EM12c environment, patch it to BP1, (if that was required for bugs they’ve experienced…) to now correct the other bugs, plus the bugs that were implemented as part of BP1, (Enterprise Manager Cloud Control 12.1.0.1 Bundle Patch 1 Known Issues [ID 1395640.1]) by upgradng to release 2 because I was instructed to in an Oracle Support SR or on my blog or in an email chain, etc?

This product came out just over one year ago.  I believe in this product.  I tell peers, “EM12c is the best way to monitor your database environment, but ensure you are going release 2.”  I do get a lot of complaints directed my way as folks know how much I work with this product.  Even if I don’t have the answer other than, “Oracle says this is fixed in release 2…” they know I will at least understand when they say a feature is not designed as user friendly as it might have liked or there is a bug that requires an EMCLI command or a bug that hinders a feature from working.  I too often give an optimistic response that “..this product is offering a whole new world of features at the administrator’s fingertips and yes, there are still some things that may need working out.  Yes, you will need to become familiar with EMCLI, it is a must with EM12c…” that it is a response that is burned into my brain.

Oracle, no matter how much release 2 was needed, I find that a second release after one year of a product shows a disconnection from the business and that of the needs of the administrators who are working with the Enterprise Manager product.  To have a release 2 of a product that has been on the market for just a year, again, is not a strong marketing strategy with your customers.  Wouldn’t it have been smarter to offer the main components and then release the ones that weren’t ready, one at a time after you had perfected them?

And… if I offer a fix for an earlier release on my blog or in an email, I would advise not commenting how it’s fixed in release 2.  That’s just insulting to the folks who are in the front lines, working with a feature that was released before it was ready.