Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Should DBA have access to sar and top?

Re: Should DBA have access to sar and top?

From: Joel Garry <>
Date: 29 Mar 2004 14:07:53 -0800
Message-ID: <>

Daniel Morgan <> wrote in message news:<1080524456.343073_at_yasure>...
> Tim Barkley wrote:
> > I came to a new shop as a DBA recently and discovered I am not allowed to
> > use either sar or top on a Unix server where Oracle database is installed.
> > Unix system administrator gave me some explanation why DBA is not allowed
> > to have access to sar and top, but to me it sounds ridiculous, to put it
> > modestly. I can't see how can one be expected to do serious Oracle
> > performance tuning and troubleshooting without those tools. I'm curious if
> > any of you ever ran into similar nonsense and how have you handled it.
> > Here's what I've was told:
> >
> > "SAR and Top are system administrator tools and are therefore not required
> > by any other users. System performance monitoring is an expressed function
> > of the systems administrator. It is clearly stated in our job descriptions
> > as being part of our responsibilities. This responsibility is not
> > indicated in the job description of DBA's.
> >
> > Additionally, these tools inflict an overhead of system resources, which
> > could compromise the running of a server if not controlled properly. SAR
> > especially utilizes a great number of resources (especially if all of the
> > parameters are used). Currently TNG is running performance monitoring (SAR
> > in the background) and we run performance metrics as well. If other users
> > also run these same monitors it would be a gross and unnecessary misuse of
> > server resources and undermine the integrity of the system with which we
> > are charged to maintain. Systems administrators are responsible for the
> > monitoring of all applications on the platform (Oracle, Unicenter, FTP
> > etc.) DBA's are responsible for the performance of their own individual
> > application and as such may use the dedicated OEM and statsback utilities."
> >
> > Any comments are appreciated.
> >
> Gads another one that posts to every usenet group with the word Oracle
> in its name. What does this inquiry have to do with 3 of the 4?
> I'm in agreement with Hans. Keep pushing your resume out until you
> find a job where they are more interested in quality of performance
> than rules.
> Also be advised that a job interview is a two way street. I never, make
> that NEVER EVER, take on a project without inquiring as to whether
> essential tools will be given to me or whether I will need to fight for
> them. The last time, during an interview, someone said to me that such
> tools would not be available I terminated the interview got up and
> walked out the door. The look on their faces was priceless. I
> understand that the person that got the project ... also got the tools.

Sounds like that person had the people skills to do the job. :-)

But seriously, many large organizations are as Hans described, and taking a hard line up front simply isn't the correct approach. Yes, there obviously is turf-protection and CYA and explicit written denial of necessary tools. But does this mean it is an untenable situation? No. Well, it might, so in that case the walkout _is_ the correct answer. More likely, it is an organization, with all the frailties, discordancies and schizophrenia that implies. It is a collection of problems, which means the person with solutions can prosper.

Specifically, you must first lay low and collect intelligence. You have a brief period of time to "prove" yourself and fit into the organization, with some latitude for being the newby. Identify weakness, opponents, possible mentors and allies, a brief list of problems that can be solved quickly and visibly, and longer range important goals. Treat everyone as if they will be your boss someday.  Especially, be nice to the jerk sysadmins, you will likely find out soon enough who has what opinion of them, and to whom it matters. It is entirely possible that managers don't really understand what their own DBA staff does, and that is probably where the silly job description came from. This is more of an advantage than it seems, because if you can show management how you can make whatever is important to them better by giving you what you need, you can eventually ask to rewrite it to your own specs. As far as the SA's, you might suggest a tool that allows you to run whatever they allow you to run with tracking and accountability (like sudo on unix). See, now you've minimized their work without alienating them, and they even may think they have increased power over you with more CYA for themselves. If they are too paranoid even for that, propose a testing project where they have to do stuff to monitor your testing - then either they will learn to work with you, or show everyone how useless they are.

Or just sit back and do whatever your job description says all day until you find a better place. Physical device performance tuning shouldn't really take up too much of a DBA's time, eh?

I don't think I've had a computer job yet that is exactly as described beforehand.


-- is bogus.
Received on Mon Mar 29 2004 - 16:07:53 CST

Original text of this message