| 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
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
 |
 |