RE: dba mgt woes
- From: "Johnson, George" <GJohnson@xxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 4 Aug 2005 13:50:42 +0100
My tuppence worth.
The one thing that seems to be missing in the discussion is natural
ability. Hands up who thoroughly enjoys a rather nasty problem? Most of us,
myself included, you thrive on that will to want to get to the bottom of the
problem or task, face it you wouldn't be on this list if you didn't. How
many us come from messing with 8bit computers when we were 10 years old or a
mainframe background. Trying to get that damn C64 to run that 400 line basic
prog, without crashing and losing all that typing! We got in this "mess"
because we love technology and the challenges. I dunno, kids today!
We currently have a junior Dba/unix sa, he has bags of energy, but
he has no enthusiasm for the task of DBA/Unix SA, simply cannot grasp the
fact that most problems follow the same logical steps. To him it's just a
good living with good pay and good company benfits. Bang on 5pm, if there
are no problems to deal with, straight out the door off home! No print outs
from OTN or metalink. No conference/seminar print outs from the web. Most
definitely no manual print outs in his hand. My C64 loving colleague and I
encourage and we spend time with him going thorough concepts, we sit in on
the meetings when he is handed the smaller projects. Sadly he has no real
natural enthusiasm for the job and sooner or later the manager will have no
choice but to question his motivation.
I guess at the end of the day no matter how good your intentions,
you cannot force people to be something they are not. Regardless of how much
you encourage, people need to find their "thing" and the level they want to
get to, if that doesn't match your expectations, what can you do? I would
dearly love my little girl to go into IT, but if she'd rather be a botanist,
professional athlete or whatever then so be it! (She's only 3 so I still
plenty of time to turn her to the dark side!)
-----Original Message-----
From: Goulet, Dick [mailto:DGoulet@xxxxxxxx]
Sent: 04 Aug 2005 13:22
To: Paula_Stankus@xxxxxxxxxxxxxxx; matthewp@xxxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: RE: dba mgt woes
Paula,
As one who has had to learn to foster/mentor those less experienced,
I share your difficulty. It has been MANY a year since my first blunder in
this area, and I must admit to many many more thereafter. Those of us who
instinctively know what we want done seem to have a hard time remembering
how we figured it out in the first place and consequently have a hard time
passing on that experience. I'll try to state in as little bandwidth as
possible how I get around that personal shortcoming because I'm in the
middle of it right now.
First thing is not to try and be the dominant force in your junior
dba's life. BTDT and it came to no good. Assuming that they've had
sufficient training so that they should know what their doing encourage them
to experiment in a safe haven. This cam sometimes mean providing dedicated
hardware resources to them. He/she needs a place where they can absolutely
destroy a database without causing the company any harm. Next is to let
them destroy things. Guide, but do not direct. Yes you and I know that
dropping the system tablespace is going to cause a crash. If that's what
they want to try, let them. Then have them figure out how to clean up the
mess. Don't do it for them. When there's a low priority project that needs
doing, hand them the specs (don't really have any then create them). Ask
for a first pass resolution to the problem. Make it clear to them that
communicating with users prematurely has negative consequences. BTW, when
they do do something like that, don't rush in to fix the problem, let them
take the heat for a while. When presented with their first pass, criticize
constructively. I'm like you, I see a script and immediately want to
rewrite it in the fashion I want to use. Don't. Read it, ask questions,
point out places where you would do it differently and why. Mentoring a
junior DBA is like selling your solution to developers or end users. In
selling the ideas to the junior your imparting your thought processes and
understanding of what can be done. This is the best way to impart knowledge
to others in our business. Our latest addition to the DBA crew here asked
why I had all of the stuff there was in our login scripts. She did not
understand why I wanted the sql prompt to tell me which database I was
connected to, what version it was, and who I was logged in as. Took me
several minutes to explain it to her, which required the telling of several
OOPS's that I had done over the years. She now has just as complicated a
script as I do.
Many times I, and probably you, make assumptions on what the junior
dba knows, understands. If they've not been through the pain, they don't.
Either we allow them to experience it, or explain in excruciating detail
what it was like. It also helps to have them there when your fixing a
problem that happen. I'll give you a case in point. We were going to add a
new database instance to a production server for a new application. It was
a simple task that our junior dba had done a couple of times on a Linux
server. I assigned the task to him which he carried out, until. In the
middle of the create database command he thought he saw an error pop on the
screen, but he was not sure. Anyway Catalog.sql carried it right off the
top so it couldn't be important now could it? A minute later the first
production database crashed, nastily, and the alarms started going off. He
walked across the hallway between our cubes & stated calmly that he may have
overwritten the control files for the first instance. He had used the
scripts from building that instance as templates for the new instance. In
reality he had overwritten not only the control files, but the redo (V8.0),
temp, and system files. I asked him to call the Unix admin so that we could
get a restore started and the helpdesk so they would know that the database
was down. We then spent the next 4 hours together cleaning up the mess he
had created. He never did anything similar again, and he created several
new instances on production servers thereafter. It was a painful lesson,
but one that needed experiencing.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Paula_Stankus@xxxxxxxxxxxxxxx
Sent: Thursday, August 04, 2005 7:39 AM
To: matthewp@xxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: dba mgt woes
Thanks Matthew.
Actually this person has been through the complete round of Oracle training.
However, I think you are right - I should have said here is the problem -
put together your recommendation and how you wish to implemenet the
solution.
-----Original Message-----
From: Parker, Matthew [mailto:matthewp@xxxxxxxxxx]
Sent: Thursday, August 04, 2005 1:09 AM
To: Stankus, Paula G; oracle-l@xxxxxxxxxxxxx
Subject: RE: dba mgt woes
So you might start by not recommending a certain route and let the Junior
dba spread their wings a bit in participating in making the decision,
instead of you making it for them. It would probably short circuit the next
item ( he immediately writes the recommendation to users), since he probably
will not want to stick his neck out in front of end users until he has a
working solution. Also if they are not experienced in these areas you might
have to change your training tactics. Although you can be commended for
taking the initiative when you started out, people are different and
learning tactics that worked for you, do not always work for others.
Sometimes it is helpful to send people to training, along with periods of
work in the area after each training session to reinforce what they were
taught. I have found it useful in cases to take a complex script that you
already have and break it down into it's component parts and hand those
equivalent tasks to the Junior DBA:
Connect to database.
Execute query.
Put results from database into a file or into a variable and then perform
basic manipulations on that data set. Loops Executions of OS commands.
You might give them training pages on the web to point to, then once they
have performed some basics tasks, you can point them to already built script
and have them break it down into what is being performed and why.
If you want to teach others, then you as the teacher must make the extra
effort to bridge the gap for the student. There is also a point that you may
determine the person is not suited for this career, but that is a long way
off, after much frustration and self reflection as to why your teaching
methods are not working.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Paula_Stankus@xxxxxxxxxxxxxxx
Sent: Wednesday, August 03, 2005 8:33 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: dba mgt woes
So,
I have recently become a dba manager and I have a small issue.
I have a junior dba new to scripting, sql, plsql, oracle. This scenario has
happened a few times:
-I request him to research something and recommend a certain route -he
immediately writes the recommendation to users -he then writes me asking me
how to do it, script it.... -I assist him in finding where to go or if I
have a script I give it to him -he has trouble implementing the solution -he
comes back to me with "your process does not work" -I discover it is how he
has implemented it and correct it
It is a frustrating experience and I wonder how to get him to take on the
task and see it through to the end.
Any ideas?
When I was a junior dba I would implement something and ususally go a step
farther - I would not go back to my boss instead chosing to "figure it out
myself".
Now I know why management is called damanagement. It is the same issue as
to why children are convinced their parents are crazy. Who do you think
pushed them over the edge?
Trying to be supportive, teach how to fish but didn't figure on this
interesting personality.
Sigh.
--
//www.freelists.org/webpage/oracle-l
--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------
Teach CanIt if this mail (ID 40200015) is spam:
Spam:
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=s&i=40200015&m=a91f595a0
4ce
Not spam:
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=n&i=40200015&m=a91f595a0
4ce
Forget vote:
https://dohsmsi01.doh.state.fl.us/canit/b.php?c=f&i=40200015&m=a91f595a0
4ce
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
****************************************************************************
--
//www.freelists.org/webpage/oracle-l
Other related posts:
