A GUI Might Not Be An Oracle DBA’s Best Friend

Oracle DBAs should know how Oracle behaves and should also be able to address issues without the aid of a flashy graphical user interface (or GUI). Unfortunately there are those who work as DBAs who seem to be lost without applications like Oracle Enterprise Manager/Cloud Control, TOAD or any of a number of other, similar programs. Relying on such a program to execute tasks necessary to extend a datafile, create a tablespace, alter a user or put a database into archivelog mode (to name a few) does a disservice to the DBA and to his or her employer. Such a dependency can also open the door to everything from minor mistakes (‘Ooops, altered the wrong user.’) to major catastrophes (such as dropping a production database). Not knowing what those ‘buttons’ are supposed to do behind the scenes sets up a DBA for possible failure.

I will admit to being “ancient” and remembering the ‘good old days’ when the command-line was the only tool to use (honestly there wasn’t any other choice). Being ‘older than dirt’ does have its advantages as I had to learn how to create a database, a tablespace, a user, set up a database in archivelog mode (I started with Oracle 6 so that was a new feature, believe it or not), grant a user privileges on database objects, size the rollback and TEMP tablespaces and a number of other tasks that can now be automated or executed through graphical tools.

Don’t get the wrong idea, I like having tools like OEM to make monitoring multiple databases fast and, well, user-friendly. It’s when a DBA becomes dependent on such tools to do his or her work that causes a issue, so much so that describing how to add a user to a database involves directions on how to navigate to the right screen to get to the right button to perform a task that the DBA may not know how to otherwise do. Should that flashy tool somehow be unavailable I fear that some DBAs may be left unable to do their jobs, and that’s a problem regardless of how anyone looks at it. Yes, typing can be tedious, what with all of those characters to remember and those keys to press but it can teach a DBA how Oracle does things and what steps need to be taken to get a task completed.

Sadly it appears that some DBAs are slaves to tools rather than masters of the database, and that’s a shame.

Looking from another angle, how many people would want someone to work on their car or truck who had no idea how it works mechanically? In this age of autonomous automobiles, it’s still a bit strange to think that a vehicle with an engine could be cruising down your street without a person operating it. Yes, it’s programmed, but programmers can make mistakes, even with training and experience behind the wheel. Who would want someone performing surgery with the latest robotic gadgets who has no medical degree or training? A carpenter with the latest power tools could be a disaster waiting to happen if he or she knows little or nothing about how those tools should be used. I certainly wouldn’t want to be anywhere near someone who has no knowledge of the power nailer, circular saw or power drill when they are using them.

Yet, in an effort to make database administration less tedious, vendors have made tasks so easy in some cases that learning how to do them ‘the hard way’ (with a keyboard, fingers and thought) becomes almost unthinkable. That is not exaggeration as I’ve been involved in hiring interviews where the candidate actually mapped out a path to the desired ‘window’ and ‘button’ and thought the answer was complete. A few were so lost without the tool that when asked how to perform the task at the command line their faces went blank.

I have colleagues that don’t fall into this category. although they do use OEM and other graphical tools to allow them to get more done. It’s not the tools that I mind, it’s the mindset of those who rely exclusively on the tools to perform database administration tasks. There is absolutely nothing wrong with using OEM, TOAD and other such tools as long as they are no more than tools to get a job done. When they become the only way for some to administer a database, then that is a problem.

Being a DBA is not an easy job; it takes knowledge, patience, thought and skill to successfully navigate the ins-and-outs of the occupation. Again, tools can help unless they become the crutch holding the DBA up; one false step, one rushed task can send a database to its grave very quickly. Such mistakes can send a DBA looking for a new employer just as quickly.

It is easy to learn almost anything online, including how to be a DBA. Good training courses provide hands-on experience with both the command-line and the GUI being used. Understanding what the tool does ‘behind the screen’ is just as important as understanding how to use the tool itself. Tools are not foolproof (because, as my grandmother used to tell me, ‘Fools are so ingenious.’) and in these modern times the malicious and malevolent can invade almost any system and wreak havoc. That button that will add space to a tablespace may one day be altered to actually drop the entire database and, if the DBA can’t add space without that wonderful GUI, the company may soon be absent important production data, and absent a DBA.

We won’t let doctors, lawyers or dentists practice without years of training and a license. We won’t let teachers into schools who have no college degree, we do not want ‘shade-tree mechanics’ working on any modern car or truck. It appears, however, that there is no governing body to ensure that DBAs have the required training and skills. Yes, vendors have implemented certifications and many of those certifications can ensure that those who are certified have met certain standards for training and experience.

There are ways, though, to make an ‘end-run’ around actually gaining knowledge and understanding by using what are referred to as ‘brain dumps’. It can be difficult to prove someone has used such a method to attain certification as many of these rely solely on test scores. Oracle has stepped up the game in some ways by offering the Oracle Certified Master program, a program where candidates must complete several days of hands-on work to prove their knowledge and understanding. Such programs prevent candidates from memorizing someone else’s answers to ‘slide by’ and get certified, which is good as it proves that the recipient actually earned the honor.

Being a DBA is not easy — there are long and thankless hours when things go horribly wrong, followed by the immense satisfaction one can only achieve from a job well done. Graphical tools can help considerably, but only if the DBA has an understanding of the underlying task that needs to be performed. The DBAs who I know, would not think of taking shortcuts or attempting a task that they didn’t understand. If a DBA is only good when he or she has the latest and greatest GUI then, in my mind, they really aren’t a DBA; they’re nothing more than an operator of their tool of choice. Not many fall into that category, thankfully, but some do get by because of what the tools can do. Learning the ‘hard way’ isn’t really that hard and knowing how to perform tasks without the glitzy tools only makes a DBA stronger.

Knowledge and understanding pave the way for experience and those who take shortcuts to the former often have little of the latter. The DBA should control the tool, not the other way around. I don’t think that’s too much to ask. What do you think? 

David Fitzjarrell
David Fitzjarrell
David Fitzjarrell has more than 20 years of administration experience with various releases of the Oracle DBMS. He has installed the Oracle software on many platforms, including UNIX, Windows and Linux, and monitored and tuned performance in those environments. He is knowledgeable in the traditional tools for performance tuning – the Oracle Wait Interface, Statspack, event 10046 and 10053 traces, tkprof, explain plan and autotrace – and has used these to great advantage at the U.S. Postal Service, American Airlines/SABRE, ConocoPhilips and SiriusXM Radio, among others, to increase throughput and improve the quality of the production system. He has also set up scripts to regularly monitor available space and set thresholds to notify DBAs of impending space shortages before they affect the production environment. These scripts generate data which can also used to trend database growth over time, aiding in capacity planning. He has used RMAN, Streams, RAC and Data Guard in Oracle installations to ensure full recoverability and failover capabilities as well as high availability, and has configured a 'cascading' set of DR databases using the primary DR databases as the source, managing the archivelog transfers manually and montoring, through scripts, the health of these secondary DR databases. He has also used ASM, ASMM and ASSM to improve performance and manage storage and shared memory.

Latest Articles