OED 12c

Yeah...    Aka: Oracle Enterprise Damager...

For those who might not know - yes indeed, a few of the so-called "cognoscenti" are not all-knowing! - we've been engaged in using grid control to monitor all our db servers for quite a while.

That's both MSSQL and Oracle RDBMS servers.  For 4 years now!

In a nutshell and to cut a very long story short:

 - we started with 10g.  The lesser said about that one, the better. It didn't work, period!

- then went up to 11g grid control in the hope of finding something in the product that actually worked. That was mostly it: just hope.  Slightly better for the basics but a total disaster in any advanced functionality including host and MSSQL monitoring.

- finally about a year ago, we got 12c and after the usual bunfight about where to run it and licensing issues, ended up doing so in RH under a vm.

Pete Sharman - the product manager for this product - planted enough earworms on me about how much better this particular release was. And he was absolutely RIGHT!

OEM 12c compared to what preceded is like a breath of fresh air. True "night and day" stuff!
(yes, I used the word "stuff"- why, got a problem? Tough! :) )

Far from perfect, mind you.  But sooo much better than the nonsense that GC was before, there is simply no comparison.

All this to introduce the main subject of this post.

As part of the effort to monitor and manage our dbs with this product, we have been investigating and actively using its features.

A lot of them. Both for monitoring and for managing dbs.

As in: "real life" work.  Not just "powerpointing" and "blogging" about how great it is and how it's gonna replace boiled water and all dbas while producing heaps of vapor clouds.  Like others do...

 And of course, as such, we've hit problems.  Which mostly we've tried to work around as much as possible rather than just get stumped or wait for patches that may never arrive.

Why?

You see: we actually have to deliver finished projects, measured MONTHLY by agile sprints.  Not just powerpoint presentations and travel and chinwag time.

Treating every obstacle as insurmountable is not an option in such a framework.

So, we have to think and apply past experience to resolve these problems or find workarounds.
And quickly!

One happened just a few days ago and it got us stumped.

It's easy as pie to reproduce, if you have access to OEM 12c:

1. Create a super-admin login, and add to it a group with a chart.
2. Logged in as that, go to the chart display page and using the right-top menu with the name of the login, pick option 2 to make that screen the default startup screen for that user.
3. Now, logout and login again to confirm that indeed you end up in that screen. 
4. After this, go to the main menus and get rid of that group altogether, then logout.
   Note that you did not change the default startup screen for that user.
5. So now, login again and watch what happens. 

Yeah!  Blank screen, no menus anywhere!

One would think that in a well thought out - and well tested - product there would be an admin option somewhere to assign a default screen to any login, via SYSMAN.  Or at the very least to stop us from deleting something that is used somewhere else as a default!

Nup, no way. Too easy! Gotta make life hard for all those "bad dbas" out there, ain't it?

So, in came Support.  And one of the most exemplar and stellar lateral thinking workarounds I've had the luck of witnessing!


Indeed!  A perfect example of lateral thinking by someone genuinely interested in helping resolve a problem, rather than pontificating or worse yet - patronizing others.

It's simple.  Goes like this:

1. Login with the affected user and get the blank screen in one browser.
2. Login to SYSMAN in ANOTHER browser (not page, another browser! I use both Firefox and Chrome, so this is dirt easy).
3. In the second (working) browser, go to a screen that you know the first login can access.  Click on the browser's url area, copy the url to the clipboard.
4. Then simply go back to the first browser with the blank page, paste the url and hit Enter.

And Bob's a close relative of your mother!  The screen now displays properly in the first login's browser. Then it's simply a matter of picking a suitable screen and assigning it as a new default via the now existing and operational top-right menu.

It is indeed a brilliant workaround, making full use of the web-based nature of the OEM UI.

I've left it to the support person to decide if the root cause of the problem should be passed on as a bug or as an enhancement.


To my way of thinking, it should be reported as a bug as it can leave a login non-operacional, with possible dire consequences if that is a super-admin.

But adding an option to the security section to add any given page as the default one for any given login is most definitely an enhancement. Not a bug fix.

Couldn't make up my mind on which way to go, so I left it to the good judgement of the support person to decide.

Here is hoping that someone with a brain somewhere in the OEM dev team actually gets this, understands its importance and finds a solution. We lost a full day of work fiddling to try and get a solution/workaround.  Until I decided to go straight to Support and get them to resolve the issue or provide us with a workaround.


Still: here it is with all its gory details, hoping it might be of use for anyone at some stage.

All's well that ends well!


But indeed there is still a lot to be done to make OEM a truly reliable and usable product.

For EVERYONE.

Not just for those who pretend to know a lot about it but rely instead entirely on direct access to developers to resolve any problems. Dirt easy that way...

And that's about it for the time being, folks.
Catchyalata!