RE: Definition of Top Class DBA

  • From: "Herring, David" <HerringD@xxxxxxx>
  • To: "" <>, "oracledbaquestions@xxxxxxxxx" <oracledbaquestions@xxxxxxxxx>
  • Date: Fri, 12 Sep 2014 17:52:21 -0500

I agree with Seth on this big time!  Covering up a screwup takes so much wasted 
energy as you either have make up a lie or spend all sorts of effort to cover 
it up.  That's WAY too complex for me.  I'd rather fess up and be done with it. 

About 5 yrs ago while supporting a client I made a change in prod, during the 
day, without proper permission.  The intention was good (we were in a 
near-critical situation) but as luck would have it the change hit a bug in 10.2 
and forced us to eventually rebuild our standby.  First thing I did was make 
sure everyone was aware that I did it and didn't have the proper approval.  
Why?  I'd like to say that I'm such a valiant person but it was a lot more 
simple to just admit it and avoid all sorts of investigation and finger 
pointing.  It's too hard to remember what you have covered up in the past - 
just point at me and be done with it, then on to fixing the problem.  BTW, last 
year I accepted an offer from this client.

An important point in asking questions like what Seth is getting at is making 
sure you don't lead the person to what you're looking for.  Ask as general 
questions as possible on the fallout to see how the person reacted and what 
they did.  Some people are very proud of things "they got away with".

Dave Herring

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Seth Miller
Sent: Thursday, September 11, 2014 11:16 AM
To: oracledbaquestions@xxxxxxxxx
Subject: Re: Definition of Top Class DBA

Really great points here. I'll add another one that is very important but 
nothing to do with knowledge.

Every one of us reading these emails has done something to disrupt business; 
dropped a production table, compressed a live data file, rm -rf on the wrong 
directory (yes I've done all of these). This is part of the learning process 
and inherent in the nature of what we do. The important part comes afterward.

The professional owns up to their mistakes, regardless of the consequences or 
even if the problem can't be traced back to them. It only takes one time of 
someone blaming a colleague, another group or just outright lying about an 
incident to make that person unreliable and untrustworthy.

There may be blowback at the beginning but people will respect someone who 
takes the more difficult path. Fortunately, this is the exception so those that 
do the right thing and own up to their mistakes stand out among their peers.

Seth Miller

On Thu, Sep 11, 2014 at 10:34 AM, Dba DBA <oracledbaquestions@xxxxxxxxx> wrote:
People often leave out something important... personality, willingness to share 
information, being articulate, and learning more than just the DB. 

I have worked with some excellent DBAs who I didn't want to even talk to. They 
cause drama and send out these emails with massive lists of people on it 
whenever they decide for someone reason they don't like anything. Cause drama. 
(its not just DBAs that do this). Really good people don't cause unnecessary 
drama. Not that many people do this... however, there is a real popular fantasy 
writer who put it like this. Patrick Rothfuss gets occasional hate mail from 
fans because he is a slow writer. Its not very often. He says its like having a 
turd in your rice crispies. You can't exactly eat around the turd. 

Willingness to share info: Sending people a link to the doc and saying RTFM is 
not real helpful. For people who are not experts reading the docs is tough. 
When I need to look at something new I actually look for blog entries first 
because someone else dissected the blogs. If people didn't do that, there would 
be no point in good DBAs writing these blogs... 

More than Just the DB: if its all the DB, then you don't know that much. One 
thing I have seen from Oak Table members is they know alot about unix and 
operating systems. Quite a few of them have clearly read algorithm books. I 
have read a few myself. I know some C (not alot) from school. I find it 
helpful. I also try to listen to the developers and sometimes I read their 
code. If you just know the DB, then developers will often blow you off, but if 
you can speak their language they are more responsive. I see alot of that from 
Oak Table members.

Articulate: It takes a lot of practice to explain technical issues to people 
who don't know it as well as you or don't know your discipline. If you are very 
good you can explain things without using oracle jargon and simplify. It takes 
alot of practice to do this... Again, I point to the Oracle blogs. Jonathan 
Lewis and others are very good at this. 

Other related posts: