First of all, let me be clear that I’m not a fan of GUI tools. That’s not based on a misguided macho opinion that somehow you need to be able to struggle with a command line interface to prove that you’re a good DBA but because :-
- I’m a contractor who works at a large number of different client sites – usually a couple per year. Unless everyone uses the same GUI tools, it’s just more to learn at each new site that probably won’t be usable when I go to the next site. The single biggest advantage of SQL*Plus for me is that I know it will *always* be there, regardless of Oracle version or operating system. (Interestingly, even RMAN is not used universally, so it can be a struggle to keep those skills up to date)
- I’m probably a bit of a control freak when it comes to my work and I like to be able to see everything that I’ve done and control every step.
- When you’re a production DBA, much of the time you need to work through change control procedures that require detailed implementation plans. It’s simply easier to produce a series of SQL commands than explain which particular buttons you’re going to press and in what order. It’s also easier to log actions into a single log file, develop repeatable scripts and so on.
- Up until now, I’ve found that the majority of GUI DBA tools have achingly slow, buggy or just clumsy interfaces. They don’t improve when used over a dial-up connection when you’re on-call!
- By implication, GUI tools reduce what I can do. There is always some minor option or detail that the GUI doesn’t support. It may be a bit more difficult to do things with a CLI, but it will support everything I need to do.
- Actually, there are probably quite a few other reasons that I can’t think of right now. In summary, I’m not married to command line utilities, but I need to be convinced that a GUI tool can be better.
Now, having got that out of the way, I have to say that I’m extremely impressed by OEM in 10gR2. I remember when OEM started moving to the web-style interface because I was involved in developing a course for App Server 9i, which used it. However I always found that interface painfully slow and buggy.
I emphasise that I haven’t used it in anger yet and (I think this could be important) I’m working as a single user on a 4-CPU / 3.5Gb RAM server, but the performance analysis functionality is particularly impressive (partly of course because the underlying information has been improved). There have been a few times already when I’ve dipped into the GUI because it showed me more detail more quickly. I’m shocked by how impressed I am. All the guys at work think I’m losing my touch because I’ve been raving about it 😉
However, it still has that learning curve problem for me but as it’s an Oracle supplied tool (if expensive), it’s more likely to appear at the various companies I work for so the initial work is more likely to pay off.
I’d been vaguely aware of Chris Foot discussing this tool in a series of blog entries, but had never bothered to read them too much because I hate GUI tools 😉 However, I’ve started to work through them and you might want to take a fresh look at OEM yourself.
I am, of course, interested in any negative comments because my anti-GUI bias is lurking in the background, waiting to be satisified!
Horses for courses. I think typing in great wads of DBMS_ADVISOR or DBMS_SQLTUNE is just plain ridiculous, and the syntax is disgusting. The GUI wins big time. Same thing for DBMS_RESOURCE_MANAGER. I think creating a user, a tablespace, assigning a role, performing a shutdown or altering a paramter is a lot easier in the command line.
My real gripe with OEM is (a) the appalling interface (apply buttons, OK buttons, radio buttons, check boxes bestrewn all over the place, with no apparent thought to ergonomic application design. If you have a drop-down box containing options such as ‘create like’ or ‘delete’, why is there a atandalone EDIT button?! It’s an interface designed by a committee!!
And I meant to add (b) the licensing.
For me a big problem is how do you do ‘pre-change’ change control with a GUI process. At least I can use OEM to show the SQL it is going to do and use that to document the proposed change and to ensure it happens the same way on the live system as it did on test.
“yoqkix” is that a health drink – perhaps Tim Hall would know
Pete_S:
It’s the offspring of nematode, that when blended with milk and asorted fruit, makes a cracking health drink 🙂
Doug:
Take a look at the Grid Control. It also includes some nice stuff, but licenses and learning curve apply here also. I both like, and am worried by, mass deployments and firing one-off host commands on each server from the central grid control.
Cheers
Tim…
I like the change control point you make, though of course you can (and probably should) use OEM as a scheduling tool – so those changes should still be scripted and scheduled rather than attempting to describe ahead of time which buttons you’ll press when.
GUI’s are excellent at conveying information – the performance graphs for example even when displaying no more information than a script output make diagnosis easier and quicker. Take a look at http://oraperf.sourceforge.net/presentations/Tuning_w_grahics_dallas.ppt for example for some further ideas here.
The licensing is terrible, abysmal and disastrous.
I entirely agree about the interface – Oracle really, really need to recruit some good GUI designers and then do user interface testing big time.
I’m afraid I’m also sceptical of a tool that can’t reliably tell whether the database is up or not though.
Thanks for all of the comments, folks. I’ve been using this for a very short time and I was interested in hearing others experiences. To reply to a couple of specific points :-
Howard….
“Horses for courses. I think typing in great wads of DBMS_ADVISOR or DBMS_SQLTUNE is just plain ridiculous, and the syntax is disgusting. The GUI wins big time. Same thing for DBMS_RESOURCE_MANAGER. I think creating a user, a tablespace, assigning a role, performing a shutdown or altering a paramter is a lot easier in the command line.”
>> Fair comment. I was looking at performance in particular at the time and still had a couple of sqlplus sessions open all the time for the straight DBA tasks. I had such low expectations that I was surprised that I touched the GUI interface at all.
“And I meant to add (b) the licensing.”
>> I thought you might 😉 I have to say I’m very p*ssed off about this, too. I may be reading this incorrectly but the warnings I received would indicate that I can’t use the performance functionality unless I buy a licence. It’s bad enough that companies will pay through the nose but is Oracle really suggesting that I can’t play around with it at home and write about it without forking out some serious cash? I think that would hurt them in the long run.
Tim …
“Take a look at the Grid Control …”
I’ll do that. After the Hotsos paper is done, the new app at work has gone live, I’ve finished off Jonathan’s book …. (you know the script!) Thanks for the tip. though.
Niall
“I like the change control point you make, though of course you can (and probably should) use OEM as a scheduling tool – so those changes should still be scripted and scheduled rather than attempting to describe ahead of time which buttons you’ll press when.”
Yeah, I don’t expect to write a change request that says ‘Then I’ll click …” and was just pointing out that scripts work best for some things. There are times when you want to run it command-by-command too, to check the response to each command before you proceed. I’m sure you, me and most DBAs have run a clever-clever script and watched the first command go wrong and the rest tumble in on itself!! 😉
“GUI’s are excellent at conveying information – the performance graphs for example even when displaying no more information than a script output make diagnosis easier and quicker. Take a look at http://oraperf.sourceforge.net/presentations/Tuning_w_grahics_dallas.ppt for example for some further ideas here.”
Thanks, I’ll take a look at that. You’re right about GUI tools occupying a specific place (erm, or as Howard said at the start – ‘horses for courses’). I suppose the situation remains fundamentally the same for me – some tasks suit the command line / script approach and some don’t. I suppose where I’ve changed on this is that I think I could see me using OEM more often during the analysis stage. It’s not just a bunch of graphs any more and I feel that more of the detail is exposed.
“The licensing is terrible, abysmal and disastrous. “
Tell me about it. Oracle come up with something that impresses me, I want to sell it to my managers … and then I have to get round to explaining how expensive it’s going to be (if I can!).
“I entirely agree about the interface – Oracle really, really need to recruit some good GUI designers and then do user interface testing big time. “
That wasn’t an impression I took away from using it but I suspect that Howard and you are right and I just have very low expectations! No doubt I’ll be moaning about it in a couple of weeks time.
“I’m afraid I’m also sceptical of a tool that can’t reliably tell whether the database is up or not though.”
😉 That’s one of the main reasons why I gave up on it in the past, but I haven’t seen that yet on the version I’m using.
Cheers,
Doug
I very much agree with what has been said about change management and pre-change management. In addition I think a GUI process would prove to be a major waste of time especially if you not only consider production DBAs but also what I usually refer to as “project or application DBAs”.
In our setup for example the production DBA applies upgrade patches to pre-production and production. The application DBA has to apply the patches to several development databases, the user acceptance testing environment and the system testing environment. In addition they have to keep their development systems up to date with any changes put in production while still in development.
I am not sure this is a normal setup but being an application DBA in such an environment (and I do like this setup) I wouldn’t get any work done if I had to do this number of rollouts.
Given this I still think that for some tasks using a GUI tool might be a good idea, namely when it provides more detailed information in a faster and easier way.
Sorry, didn’t want to post anonymously … (A mistake due to using a GUI 😉 ? )
It’s bad enough that companies will pay through the nose but is Oracle really suggesting that I can’t play around with it at home and write about it without forking out some serious cash? I think that would hurt them in the long run.
I didn’t read it that way, the license warnings AIUI apply to systems that are licensed under the paid for licenses (i.e stdone,std and ee). The OTN license I think covers the ‘playing around at home’ scenario.