Let’s deviate a little bit from technical stuff in this blog post! I was going through few top Sports Quotes and i came across “Don’t Mistake activity with achievement“. Well, Right at that very moment i got a crazy thought and i’m amazed, how good we can make use of this Quote to relate our day to day DBA activities. I know…I know!Am obsessed with SQL Server DBA work 😀
Okay! Let me ask you something, How many times you were appreciated or received applauds from your Senior Management or your immediate manager or your peer for your work what you are doing for your organization? Out of them, how many times you really deserve those applauds?
A Classic example in DBA world is you as a DBA, participating in DR(Disaster Recovery) Drills aka BCP(Business Continuity Plan) Exercises and your DR exercise went flawless and you receive an achievement/Success/Best Player/blahblah certificate from your management! As a technology engineer, should we really consider this as an achievement? Noooooo…!! What have we done really? That’s the part of our Job as a DBA. That’s our activity, not an achievement!(YMMV) So, what can be considered as an achievement? Well, If you are talking about multiple Applications and multiple Databases involving LogShipping, Mirroring, Replication, Linked Servers and all other Dependencies and you all alone made sure that everything went well flawless, Then we can scream loud “Yes, I achieved something”. Again, if you have prepared your DR Database(s) and verified for all dependencies Just for the sake of this particular DR test, you achieved nothing and you are not a good DBA!! yes, I mean it because your environment is not ready for a real disaster until you prepared everything manually just before this test. As as good DBA, we should(at least try to) make sure that at any given point of time, if our Production Database hits a disaster, we should be able to recover from disaster with as much less amount of time as possible( Make sure, at least you are not violating your RPOs and RTO’s!) Also, I’ve seen most of the DBA’s very easily gets confused with terms “Disaster Recovery” and “High Availability” and interchange them very often. Huge Huge Mistake!!!!..
Interestingly, I’ve seen many DBA’s who’s not aware of few very critical pieces about their own Databases which they support, claiming as a Senior Engineer or even SME’s in some cases. LOL!! Typical Conversation goes like this…
Good DBA: What’s your SQL Server Version and Build number?
Bad DBA:Re: Well, I think it’s running on SQL 2005 or may be 2008, not sure about Build.
Good DBA: Assuming you are running on SQL 2005, what’s the Page_verify Option set to on your Databases?(Good DBA knows that those Databases are migrated from SQL Server 2000)
Bad DBA:Re: What is Page_verify Option?
Good DBA: Well, When was the last time you ran CheckDB against your Database?
Bad DBA:Re: I’m not Sure! Do we really need to run Checkdb? I heard that It’s a very Resource intensive Operation. I don’t want to hurt performance of my SQL Server by running CHECKDB on a regular basis.
Good DBA: Hmmmm….I heard that Application is having few performance issues while hitting few tables on your Database. At a very high level and general guide line, have you verified fragmentation of the indexes on those tables? When was the last time you de-fragmented your Indexes on that table?
Bad DBA:Re: I prefer rebuilding every Index on a given Database using a maintenance plan irrespective of the Size of the Index/Table/Database. This table is so huge, i don’t care looking at fragmentation unless Application has some serious performance Issues.Hey…. Btw, I received applauds from so and so for fixing so and so issue by restarting SQL Sevices!
Good DBA: OMG!! ROTFL!!HaHaHa…Bye! I’ve something else to do!
PS I’m not saying that I’m Good DBA and you are Bad DBA in above conversation. Not intended to hurt anyone’s feelings with this post!
There are few cases where we really should feel proud about and say that I’ve achieved something. Let’s say, there’s an issue which no one from your team could able resolve and you’ve stepped in offering help and resolved it avoiding an Outage for your application. Yes, that’s an achievement! Unfortunately there will be many cases where no one recognizes you for what you’ve done in that given situation to your organization! Well, Just keep your Fingers crossed! There’s a funny saying “Every Dog has its day”! your time comes. If you are honestly doing your job and doing 100% justice for what you are getting paid for, let me say this – that’s all you need to do 🙂
So..how can we do 100% justice for a DBA job?? It doesn’t mean that you should be expert in each and every area within SQL Server. It doesn’t mean that you have to be a Microsoft Certified Master. It doesn’t mean that you should be an SME in each and every piece of SQL Server. SQL Server is not just a simple Utility where you write bunch of lines(something like Notepad or word pad). It’s a very complex RDBMS platform and has many components and technologies embedded implicitly. Thorough understanding of all(as many as you can) the concepts and components within SQL Server, understanding how SQL Server interacts with Operating System and IO Subsystem, How SQL Server behaves when you change certain configuration options and so on, Willingness to learn something which you don’t know is the single Most Important point for becoming a good DBA, Willingness to explore SQL Server related Technologies, Willingness to help others, getting in touch with our fabulous MCM’s and MVP’s out there who are ready to help our SQL Server community, Participating in few discussions outside of your Team etc…
Don’t feel shy if you don’t know something, no one knows every thing within SQL Server, reach out to your fellow team members for help. All these makes you automatically to become a good DBA 🙂
May be out side of context, but Just want to stress again, If Being Reactive is an activity, being Proactive is a definite achievement 😀 Again….If you think Administering SQL Server is always just Running few scripts now and then, Right clicking on your Instance/DB from your SSMS and selecting some Options as needed, you are no fit for being an Admin.(No offence)