5 Secretes to Become a Successful Database Administrator (DBA)

Every body wants to be success, so do I. You might have seen people as very successful Database
Administrator (DBA) around you. I have been working as DBA for around 7 years and got a chance to
work with very good people in this field. Though your definition of successful Database
Administrator could be different than mine, but I believe If you are happy at home and work place
and does not carry work stress to home, then you are a Successful DBA. This is because only a happy
person can be in good state of mind and think of something new or an alternate way of doing
something which eventually boils down to growth in career.

As you know database is the most crucial information for any organization and depending on industry
if Database is down it can led to huge financial loses like banking or disaster as well like aviation
industry. Even then there are few activities which needs planed outage. So DBA has huge
responsibilities on his shoulders.

5 Secretes to Become a Successful Database

Administrator (DBA)
In this post, I will not tell you success mantra, but for sure few small-2 habits which can avoid some
blunders and help you to get appreciations at your work place. Here I will suggest dos and don't as a
DBA. Let's start

1. Make a Plan on Paper: Though Now a days, Paper is replaced with MS Office Word
file. But my intension is to tell you how important is making plan for each and every activity. I have
seen very good technical DBAs red faced during Production Implementation activities due to lack of
proper action plan.

Let's take a situation, Suppose you are going to upgrade production database and you have done
upgrade 100 times so you are confident about your upgrade technique. But when you did upgrade on
your test machine it was only database to take care without any application connected to it. Since, this
is production environment you have to inform application support team to stop application or to re
route it.

When production activity will start your focus will be on database part only, so there are fair chances
that you miss informing application team. For you this could be a small mistake but this can have huge
impact on business.

So, I would suggest to note down all steps with database technical commands as below:

A. Pre database technical: This could not be related to database but having a small detail about
application can help you to understand database activity and its impact in a better way.

B. Database technical: Record each and every smallest to biggest command at a place, so that you
don't find them here and there at time of actual activity. I will strongly recommend to avoid any new
command or alternate at time of production activity even though you are very confident about
it.
C. Post database technical: Suppose your production upgrade activity is down successfully, but
application is still not able to connect to database then there could be problem at application side or
database side. To avoid that kind of situation have a small test case with you to check every thing is
working fine at next level. Though it's not your responsibility but it can save you from so many
troubles.

2. Thoroughly Test you Plans: No matter, How good Plan you have made, there could
be small variations at your test environment and production environment. So this gap can only be
covered by through testing of your plan. Try to replicate your test enviromnet as much as possible with
prod environment. Think about as much as possibilities you can and test your plan with all
possibilities. Make sure you test your plan two or three times and record out come of each testing to
verify with last one to find variations and improve your plan accordingly.

One very good approach to test you action plan is, ask some other DBA to execute your action plan
and see the result. Second person will have a different thought process and will look your plan by his
point of view and can give you very good inputs.

However, When you are confident about your skills and knowledge testing seems to be a useless thing
to do, but trust me this is very important to do. Once you will do it you will realize it's worth and your
confidence will be at next level. So make a strong test plan and validate your action plan.

3. Strong Backup and Rollback in Place: As you are confident with your plans, so
sometimes you don't take backup and rollback option very seriously. But anytime technology can go
wrong or you can see some unexpected situations like Hard ware failure, OS issue etc. So if DBA
don't have a backup and recovery option this could be troublesome for him.
This rule applies to every action plan like changing a small database parameter to big upgrade or
migration activity. So make sure you have take backup of database, table, parameter file you are going
to change. I would also suggest to test backup and rollback option as well.

4. Keep Some Spare Time: I have seen DBA doing things in hurry on Production
environment, While what I think is DBA has to execute commands on production in a peaceful
manner. This is because of shortage of time to complete the activity.

Suppose Database Administrator is going to upgrade production environment on weekend and upgrade
take around 4 hours. So, I would suggest to make an action plan considering upgrade time as 6 Hrs. In
this way if some mistake has happened or you miss something, this can be easily recovered. On the
other side if you have asked for only 4 hrs you are always in hurry and chances of doing a mistake are
quite high.So always keep some spare time when plan for production environment activities.

5. Get Ready for Unexpected Situations: Though Database Administrator have

followed all the suggestion given in this post and then start production task. Suppose something
unexpected happened Like "Add node" script in RAC fail with some "ORA-600" error. In this case
don't panic and stay calm, don't try any command or option which was not there in action plan.

Get your oracle Support user name and password ready and open an Service request at
support.oracle.com according to situation. Like if this is an complete outage open a severity 1 request
, if loss in server open severity 2 request and ask for immediate assistance from Oracle Support and
move on.

Though above give suggestion also apply to real life as well but more specific to DBA profile. This
list could be very huge in size depending upon experiences we have gone through. I would request
readers to add few more points into this to make it a perfect guide for DBA's to follow in achieving
their carrier goals.