RE: dba mgt woes
- From: "Goulet, Dick" <DGoulet@xxxxxxxx>
- To: <Paula_Stankus@xxxxxxxxxxxxxxx>, <matthewp@xxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 4 Aug 2005 08:22:24 -0400
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
Other related posts:
