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.