Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

Search

XML Feeds

Google Ads

« Troubleshooting Performance Problems in SQL Server 2008 White Paper ReleasedAdd Report Wizard Layout Style (Standard Company Style) »
comments
Rate Post:
submit to reddit Digg!FacebookDotnetkicks

As promised from topic http://forum.lessthandot.com/viewtopic.php?f=17&t=4735&start=0&st=0&sk=t&sd=a&hilit=DBA I'm making a blog entry on my expectations of a DBA.

My reply to the question

DBA in my eyes and how I perform the job is...

  • Mid to Sr level TSQL abilities in order to fulfill business requirements in data access not directly available to developers. Personally don't think a DBA is much if they don't have at least mid-career skills in TSQL. They should be the ones telling the developers what not to write and how to write it. It will hurt them if they can't.
  • Proactive monitoring of all resources including any instances currently installed in the environment. This includes development and test. Be able to fix them!!!
  • Proactive monitoring of performance bottlenecks. Blocking, deadlocks, memory pressure, load balancing due to pressure, index, statistics, usage of these. Load balancing references things like pushing reporting off main databases to prevent issues etc..
  • Create a stable security landscape. Schemas, user roles etc... and maintain it! If someone knows sa then they failed.
  • Knowledge and ability to install and configure "PROPERLY" any SQL Server service. SSRS, SSIS, SSAS etc.. If you are titled SQL Server DBA then you better know it's not just a DB Service and know how to maintain and configure them all.
  • Ability to communicate high level DB Server issues to peers in less technical manner. Can you explain a deadlock and actually have a manager understand it? Important! You won't get hardware upgrades without it.
  • Document everything. Landscape, security, service configurations
  • Ability to setup and configure a stable and trustworthy disaster recovery model.
  • Achieve at least a 98% up time goal during open and critical business transactions.

Finally, I think any DBA should show what they do in no less than a monthly report to upper management. I say upper sense typically this is where they report to. Monthly I send the directors a comprehensive report of performance of the production system. This including known issues and tasks open and or closed. Also contains project lists. The reason for this is one to show the business your worth and two, in order to maintain your db server landscape and have the ability to request upgrades and or scaling out you need to show and sell it. These reports can be critical to that IMO. If they can't provide you with the current state of the database servers then they don't know it and there is a point of failure.
***end reply***

I thought of rewriting my reply but to be honest it sounds good as is. Copy/Paste went to work! I would like to add that a DBA shouldn't be the type of DBA that corporate America typically brands them as. That is, people typically see a DBA as the quiet guy that has little to no interaction with the business. We're all here for a reason and that's to help business grow. Be more proactive in participating in that business and groups within it. Aspire to be more than a name on a paycheck. Be an asset!

About the Author

Ted Krueger is a SQL Server MVP and has been working in development and database administration for 13+ years. Specialties range from High Availability and Disaster / Recovery setup and testing methods down to custom assembly development for SQL Server Reporting Services. Ted blogs and is also one of the founders of LessThanDot.com technology community. Some of the articles focused on are Backup / Recovery, Security, SSIS and working on SQL Server and using all of the SQL Server features available to create stable and scalable database services. @onpnt
Social SitingsTwitterLinkedInLTD RSS Feed
1353 views
submit to reddit Digg!FacebookDotnetkicks

Comments and Feedback

5 comments

Comment from: chrissie1 [Member] Email
In my business, we want less business.
15/04/09 @ 07:41
Comment from: SQLDenis [Member] Email
*****
>>Can you explain a deadlock and actually have a manager understand it?

sure....:-)

Here is how you do it; tell your manager to grab the phone, next you grab his hand and squeeze it real hard, now ask him to try making a phone call....he won't be able to since you are locking him...now you can't use the phone because your manager has it, your manager can't use it unless you release his hand.


BTW this actually happened to me when I asked a person to explain a deadlock to me and he told me to grab the phone, he then proceeded to grab my hand


No, he did not get the job
15/04/09 @ 08:26
Comment from: kermit [Member] Email
*****
As long as the person grabs your hand.. ahem.

Excellent post and btw your reply made headway in my project and has prompted for a thorough review of how we manage our databases starting with some work tasks I have identified for said project.

I think the above model applies to other roles as well, it's easy to be boxed into a typical profile but if you do not aspire to rise above your responsibilities and get involved with the business community you will not be heard.
15/04/09 @ 08:54
Comment from: SQLDenis [Member] Email
*****
Here are a couple of things I think can help someone

Knowledge and the ability to quickly find the solution.

Read, read, read, listen to podcast, setup all the good sql blogs in your RSS reader and bookmark the really good posts on delicious
Get involved with newsgroups, if you don't know the answers then lurk in the beginning after a while you will see that the same questions keep coming back and back, memorize those....sooner or later you will get into a similar situation and it will be nice to know the answer
Read all the white papers for your SQL product, watch all the webcasts/netcasts/screencasts
read at least a tech book a month

you need to have a library of scripts that you can use
Wizards are nice but they don't cut it especially when you have to log into sql from the command line. This is also one of the reasons I place code on the wiki here.


Get some tools
yeah you can roll your own SQL Compare but red gate has been doing this for years and their product is more robust, faster and netter than your scripts...it is also not expensive

Train and practice
make sure that you know how to do a backup and restore, i still remember a person who posted that instead of a backup she did a restore with a year old copy and destroyed the database since that was the only backup they had :-( The advice she got was to update her resume...don't let this happen to you

Be proactive
Don't wait for stuff to happen, monitor everything you can so that you know before it happens, CheckDb exists there for a reason
15/04/09 @ 10:02
Comment from: Atif Shehzad [Visitor] Email · http://blog.DBDigger.com
****-
I liked your article for the fact that a broad view is presented for DBA responsibilities and domain. Along with learning and implementing the skills it is also same important to always be aware of authority and responsibility of your profession.
15/04/09 @ 21:41

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)