MyEM

"Everbody can play on a good piano. You 
must learn to play well on a bad piano."

The Art of Scripting
Write your own Enterprise Manager - why that?

The history of Oracle's Enterprise Manager is long and not straightforward. It reflects the often controversial development trends that have occurred not only in Oracle's steadily growing ecosystem, but  above in the paradigm changes of the IT industry.

The first instance, I can remember, was the Enterprise Manager Java Console, a standalone solution, but not bad at all for that time when Oracle 9i was published. All of a sudden it was withdrawn and we, the DBAs, had to fall back to our own framework of more or less sophisticated scripts. We used to borough heavily from Donald K. Burleson - our grandmaster, long before Tom Kyte, Steven Feuerstein and the other gurus appeared on the scene.

To cut edges: the next releases were not very lucky and nobody of us really relied on them. And with all due respect, what I see since a couple of years does not make my heart leap for joy. One can almost feel, that Oracle is in a fix here, not because they have bad programmers and directors, but because the situation is simply disgusting. The market demands "big solutions for gratuity" and the IT staff, decimated and overloaded, demands efficient tools for the daily doing. What we have now, shows the problem: on one hand the gigantic Enterprise Manager Cloud Control, one the other hand the standalone EM Express. They seem to me like "Queen Mom and Cindarella", but keep in mind, that it was Cindarella who married the Prince.

Enough ! I had to do my daily and nightly work as  troubleshooting DBA. Frankly spoken: I had no nuts to wait for the administrators to grant access to me, a freelancer, to use the different releases of the Enterprise Manager.  Besides, they were awfully set up, slow, useless for me.  

How that?  They simply did not exist respectively had no agents running on the servers, where people called me out to troubleshoot their databases.

All my colleagues had collections of SQL-Scripts, more ore less useful.  Some even had PL/SQL-Scripts - Hear ye, hear, ye!. But in a given emergency situation they had no idea, which script applied to the concrete problem - they had to guess and use "grep" through the jungle of their scripts. No doubt - I needed a framework. There existed frameworks, some based on an ADMINDB, some on Perl, some on Java. But again: they did not exist on or had access to the servers of my daily duty.

So what to do in the face of server farms with more than thousand servers, equipped with different Unix distributions, patch levels, hosting different Oracle Releases, some of them very, very old. The only script language, capable for such frameworks and omnipresent on all different Unix systems, was and still is the good old Korn Shell, together with the old, indispensable tools like sed, awk, etc. Hence I had to go without "that modern stuff like OO - features", but I needed a sort of GUI anyway, which I found in the combination of the "select"-feature and the terminfo database.

So, in the course of the years, there was built a comprehensible, structured framework of some hundreds scripts, tied together in a zipped tar-archive, which was quickly to copy to the remote server.

It looks like that (click on the pictures to enlarge) :















Here it is running inside a Virtual Box with different Oracle Releases.






















This is the menu of functions.
                                                                                                                                                                 
























This is a submenu demonstrating that one ist not limited to watch, but can rather work on the database.

Conclusion
I want to encourage young colleagues to learn the art of scripting for their frameworks. For that end I plan an open source project on github.

This is cumbersome and even old DBAs moan and try to decieve themselves. Some of them told me: "You are right, all that should go quicker. But I have no time."

This reminds me of the story about that lumberjack, trying to saw a tree with a blunt saw, heavily transpiring. A wise man came along and advised him to sharpen his saw, but the lumberjack grumbled anoyed: "No time ..."

No comments: