| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> 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_at_vicr.com]
Sent: 04 Aug 2005 13:22
To: Paula_Stankus_at_doh.state.fl.us; matthewp_at_amazon.com;
oracle-l_at_freelists.org
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Paula_Stankus_at_doh.state.fl.us
Sent: Thursday, August 04, 2005 7:39 AM
To: matthewp_at_amazon.com; oracle-l_at_freelists.org
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_at_amazon.com]
Sent: Thursday, August 04, 2005 1:09 AM
To: Stankus, Paula G; oracle-l_at_freelists.org
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Paula_Stankus_at_doh.state.fl.us
Sent: Wednesday, August 03, 2005 8:33 PM
To: oracle-l_at_freelists.org
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.
--
http://www.freelists.org/webpage/oracle-l
--
BEGIN-ANTISPAM-VOTING-LINKS
--
http://www.freelists.org/webpage/oracle-l
Received on Thu Aug 04 2005 - 07:52:51 CDT
 |
 |