Re: OT - Getting fired for database oops

From a DBA point of view, if I or a coworkes keeps screwing up, they should
be considered for lay off. Let's say I screw up a database, and need help to
bring it up. Then the next week the same thing happens again. There comes a
point where I become more of a liablity than a helping hand, and for the
sake of the team, I should be moved somewhere else.

I've had a few coworkers that were more of an annoyance than help. They
wouldn't do *any* task alone without asking, and they had semi-senior posts
(with the according salaries) while most of the Junior DBAs would do most of
those things without asking how to do them. Of course, procedures require
authorization and everything, and we all follow procedures, but there's a
difference between asking for authorization (usually not from a teammate)
and asking technical questions to which you should know the answer... or be
able to look them up. I think it all comes down to attitude and how useful
you are to the team.

That being said, I think that nobody should be fired over one isolated
incident (not having backups excluded).

On the other hand, from the management point of view, if a dba screws up
once, and takes responsability, then he won't he fired. If he's a jerk and
tries to blame someone else, then he will be put in the black list.

One thing that cannot be forgiven of any DBA, no matter how great they are,
is not having a valid backup of the database. And this is ONLY assuming that
he asked for the right tools to back up the DB and got them. If he didn't
ask them then he is at fault. If he did ask them and didn't get them
(management decision, as usual), then he cannot be held accountable for lack
of backups.

that's just my opinion though.
Alan Bort
Oracle Certified Professional


On Fri, May 15, 2009 at 8:12 PM, Mike Haddon <m.haddon@xxxxxxxxx> wrote:

> Not a DBA but same concept,
>
> I was a director in a previous life and had a Unix System Admin that,
> against specific directions not to use expect with root privileges, did so.
> He came into my office and explained to me that he screwed up using the
> command to change the root password
> on all of our database servers and some application servers and the shadow
> file got corrupted. This included servers in 4 countries.
>
> Now - in this scenario the systems still run fine but you cannot get root
> privileges on them and you will eventually be in a pickle.
> I called a team meeting and we came up with a plan to correct the problem.
> These were SUN Solaris servers and the internal boot disks were being
> mirrored.
> So, the entire team, with cooperation at each data center from local
> operators that worked for the company went system by system and to make a
> long story short we fixed the shadow file and got each and every server back
> into our control. I sent this administrator to the local data center and he
> spent the night doing the grunt work while we controlled the process
> remotely. This took almost 14 hours to complete.
>
> The next morning this person came into the office, profusely thanked
> everyone for their help and handed out a six pack of each person's favorite
> for their understanding and help. Then he came into my office and was ready
> to take the consequences of his actions.
>
> I told him that I wasn't going to fire him for two main reasons. First he
> was a good admin, got along very well with the team, a very hard worker and
> just had a bad brain fart. Second was that he was adult enough to come into
> my office to admit his mistake so we could address the issue on our own
> terms and internal to the production team, also I was sure he would never
> make that mistake again.
>
> He turned out to be a very integral part of the team. I do admit I had one
> of the best teams anyone could ask for.
>
> Mike
>
>
> Newman, Christopher wrote:
>
>> A colleague and I were just discussing DBA's getting fired for screwing
>> something up/failing to do something (Not for being generally poor
>> employees like showing up late, etc).  Neither of us had heard any
>> stories of either scenario.  I know we sometimes have slightly off topic
>> discussions on the list, so I was wondering if anyone would share any
>> stories.
>>
>> Chris Newman
>> Database Specialist
>> AITS, University of Illinois
>> 217-333-5429
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>>
>>
>>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

Other related posts: