RE: dba mgt woes
- From: "Bellows, Bambi" <bbellows@xxxxxxx>
- To: <GJohnson@xxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 4 Aug 2005 10:50:41 -0500
Bang on!
I always said there are people in this field because they love the
technology and there are people in this field because it's an easy way
to make a nice living. I'm in the first category and naturally think
the people in the second are a shallow bunch of twits. The folks in the
second category naturally think that I am a nerd and not fit to teach
their children how to dress.
Twits.
Best wishes,
Bambi.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Johnson, George
Sent: Thursday, August 04, 2005 7:51 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: dba mgt woes
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
