What exactly do I mean? Many times Oracle management tools that look good on the surface are actually held together with bailing wire and duct tape underneath, in another series I read as a young sailor, a character in the book was told to walk up to a skilled Thai Monkey Boxer and just push his shoulder if he executed a particular move, of course the character did so and ended up crippling the much more experienced boxer. The moral there was knowing the way things work, you can break them pretty easily.

Of course you are all thinking where the heck is Mike going with this? If you are looking at Oracle monitoring tools, be sure you understand all of the limitations and weaknesses that are inherent in them. For example, does a tool require a Java Runtime Environment (JRE) to operate? Does it require a web service to be operating? How many potential points of failure are in its architecture? Is its agent robust? If you don’t look at these from the start you may end up with a house of cards that any stray wind, such as an automatic update of the JRE, might blow down.

Oracle management has moved from mainly a script based, command line driven world, to a GUI interface, many layers of abstraction type of world. Does this remove the responsibility of the DBA to understand all of the underpinnings? No, it does not. I tell folks that they shouldn’t provide advanced tools to a DBA until they can do the job without them. In other words, until a DBA understands the Oracle structures and mechanisms enough to handle most DBA jobs without GUI tools, they really can’t utilize the tools to their fullest potentials.

So here we are in a Brave New World of Oracle Management, but it is funny how when you look under the covers, much of the old world is staring back at you.