Get the Most out of your DBA

Get the Most out of your DBA - DBAs are an important asset for any organisation to own. I doubt any job these days is recession-proof but there is still something that drives the demand for good DBAs. And trends indicate that DBA expertise will continue to be valuable for many years to come.

Advances in technology, the need to eliminate the inefficiencies and increasing management and administrative costs associated with business. This existing and foreseeable demand in the database market sustains the need for a DBA.

I�ve quoted before in a few of my articles that data is perceived as the most precious asset an organisation has, and a key requirement of modern IT infrastructure is secure and timely access to and storage of that data.

How would banks survive without databases on customers and financial transactions? E-business sites use databases to track orders and inventory. Airlines, the retail industry � they all depend on databases. The organisation I work for could definitely not survive or fulfil the expectations of the public without the use of databases.

DBAs are often regarded as "those professionals who organize information in a meaningful way so it can be easily maintained, retrieved and updated".

The role of a DBA is very important in an organization � whatever its business or size. Defining that role can become a complex task; different organisations employ �DBAs� to fulfil varying job roles with completely diverse responsibilities. Whether they are production DBAs, development DBAs or simply a one-stop shop DBA who deals with everything. The difficult task for a team leader/IT manager is ensuring they get the most from their DBAs.

Now, I currently find myself sitting on the other side of the fence, I had been a DBA of some ilk for about 10 years (both SQL Server & Oracle) and all of a sudden I find myself in a position of leadership where I am now responsible for a team of DBAs � responsible for ensuring my organisation gets the best out of them, individually and together as a unit.

I find it difficult to actually define what a DBA is, in relation to my organisation. But I should know what I expect of them, I should know their strengths, weaknesses and skillsets etc � note I said �should� there!

What this article attempts to do is give advice on managing your DBAs, ensuring they are working effectively and efficiently in order for your organisations� data to produce and deliver real business value.

I will use my experience as a DBA to highlight what I believe are the core functions of a DBA, and then as managers/team leaders you (we!) can ensure that you are fully utilising the skillsets of your staff, taking advantage of enhancements in technology and ensuring your workplace is a positive, driven, and productive one.

Clearly technology is changing too. It's going to be tougher to be a dedicated DBA, responsible only for administrative tasks like backups, performance monitoring etc

Systems and database technologies are getting better at automation and the tools are taking a lot of the work out of the processes, even if you still need to understand what's happening. So straight away we have to ensure our DBAs are being used productively, that they have enough work to keep them content.

Every organisation is obviously different, having different types of DBA, differing workloads, SLAs and end user expectations.One thing we, as management, should never do � is alienate our DBAs. If we do, it is liable to lead to painful consequences. DBAs aren�t always the guys who sit there, puce in the face, staring ahead at their screens and sweating profusely. Most of the time they are proactively ensuring the company�s data is secure & accurate and that is gets delivered to end users in the right way.

A management report is one of the most frightening things a DBA can be responsible for. It has to be right. If you get a sales report wrong, it can lead to people being unfairly sacked or rewarded. If you get a profit or loss figure wrong, your management can commit huge resources to the wrong part of the business, and starve the real revenue-earners. And in my particular organisation � inaccurate reports can lead to misleading statistics and false impressions of the service being provided.

The DBA should be like a carnivorous beast, all senses honed at spotting the rats. His senses are his queries, and his database tools. Always probing, always diagnosing, tweaking here and tweaking there. Yes fire-fighting is often called for but being proactive rather than reactive is what can prevent data loss and a lot of embarrassment.

But if they�re not doing this, then we�re not getting the most from them. So what tips are there to ensure the Database team is functioning at a premium? Below are a selection of things to consider today - things that are quick and dirty and can help in managing your SQL Servers.

In a lot of cases, many DBAs inherit systems from predecessors. So a good starting point, particular for newbies is to create an inventory of where SQL Server is installed for a start! � does such a list actually exist? - use an AD/port �sniffer� to find all your SQL instances or diagnostics tools such as Idera (http://www.idera.com) .

You may find more than half of your databases are not being backed up, and that other maintenance is almost non-existent. Services are not set to restart, passwords are weak, and log files consumed disk space to the breaking point. So the first step for them is to carry out a lot of secretarial work!

Consider reviewing your maintenance plans & automated SQL jobs. Go back, look through your plans and make sure they're doing what you need and expect of them. So many people have set up maintenance plans and then never look back to make sure they're still doing what you need them to do. Make sure that you are using your best lessons learned in these plans - from reindexing operations to backups to shrinking your database (if you really have to do this) and the other options you have with these utilities. Make sure, too, that you're tracking the success and failure of these jobs. Finally, look through the execution history for the jobs. Make sure they're running without issue as you expect. You could quite easily be sitting on top of a problem without realising it � until it�s too late!

Check your file locations. This pertains to the physical location of files. From database files to log files to OS files, you want to split your major categories of files across disk spindles. This means you want to, if at all possible, put them on different physical drives (logical drives don't count).This can help with performance on your system by alleviating congestion on the disk level. Avoid having both databases and transaction logs on the same physical drive, and avoid having the operating system share a drive with your database storage. Each of these can cause contention when it comes to disk access and contention leads to poorer performance. There are various best practices out there to consult with, you as a team leader though need to ensure you are getting the best performance that is possible with your available infrastructure etc. More often than not servers/systems are inherited from previous employees and without investigating proactively you may be missing out on some serious performance gains.

Some other key things to do some quick checks on:Backups - when did they run last? Have you tested a restore? Are you seeing transaction and database backup files that you expect to see, at the time intervals you expect to see? Do a quick visual check; make sure you're seeing what you think you should be.

Your recovery process � is it documented anywhere? Have you had someone unfamiliar with it try it, or at least review it? A documented process that addresses "normal" failures (!) is a key to getting things started if key members of staff don't happen to be around. If you can have an "essentials" process that affords escalation if the plan doesn't cover the issue at hand, you'll be one step closer to not being called upon out of hours every time a re-index operation fails.

Make sure you know when your DBA is off on leave! This can be huge. You need to plan on their absence, ensure projects and requests are handled ahead of time. At the end of the day, if they�re on leave � the buck will stop with management � i.e. you!

It is easy to come to believe that a DBA's many working hours spent staring into screens was merely a ruse designed to infuriate senior managers There will be differing workloads, varied skills, and levels of dedication within your pool of DBAs. Distributing that workload, enabling knowledge-sharing amongst the team etc could prove troublesome, in terms of keeping everyone happy, but however you distribute the work, you should look after your DBAs. They're a valuable human resource, and you'll discover a world of hurt if they all up and leave at the same time.If there isn�t enough day-to-day work to go around then theres still plenty for them to do � database technologies are forever evolving � get them researching ! DBAs themselves need to ensure their skill-sets remain current � so maybe encourage certification, offer them the opportunity to improve. Give them interesting tasks to do as well. Most of them want to extend their skills in particular areas. And most firefighting DBAs may want to move on to less stressful jobs after a number of years.

Of course you�re always going to find one DBA out there who is content with what he/she is doing, with no desire to self-improve, no enthusiasm to update their DB skills etc � treat these employees with caution � as more often than not they are the guys who have been in the team the longest ! And with that comes in-house knowledge, strong & historic end-user relationships etc. He/She may not be a go-getter but is able to bring other qualities and experience to the table � make sure they are invited to the party to!

Send them on training courses, to user group meetings and to technical conferences. When I was a DBA, I would actively seek out potential seminars/conferences for me to attend both my own personal knowledge gain and to benefit my organisation. It�s a good idea t let your DBAs interact with other DBAs from other companies � enabling the sharing of knowledge and experiences etc. You never know for the sake of footing the bill for travel & hotel expenses to attend a Database Conference, your DBA will return with ideas that will revolutionise your organisation! Invest in them, keep them happy and stimulated. They're valuable assets who tend to know your data, applications, and organization very well. As I say, every team has a wide mix of personalities and different types of DBA. As managers you will know how to supervise and nurture individuals, all I m trying to do here is give pointers as to how to prise the best from them as DBAs.

To what extent must you become involved in the work performed by the DBA function? I guess this really depends on whether you�re a technical or non-technical manager � or like me a convert from tech to non-tech!You probably do not want to be always looking over their shoulder, seeing exactly what he was doing while he was trying to fix an inconsistent production database and make sure the indexing and disk space allocations were correct for the recovery run etc. Give them the responsibility for the servers; allow them if you like to become the custodians of your data. Trust them.At the end of the day it may take them twice as long to get each task done if they have to explain each step to you or other senior management people in layman's terms and disprove your (more often than not!) useless suggestions. Meanwhile, the users are jumping up and down � then as a team leader you will be accountable!

Regularly examine their checklists and discuss work in progress as often as you need to, but stay at arms length when your DBAs are fighting fires and have irate users shouting on the telephone.Its important here you, the manager to take the heat off the DBA and let him get the work done, the manager should be one to liaise with the business keeping them informed and keeping the wolves from the door, especially if its a mission critical system. Let the DBA fix the technical problem or he could end up with another problem � staying to stay calm on the phone!!

Sure, fuel them with strong coffee when the going gets rough. But let them fight the battle. They will be opportunities to debrief after the event. Then give them praise if it is due, or jump on them if need be, or, better yet, help them get more organised or better equipped if it proves necessary. Of course, another challenge is holding on to good DBAs. I�ve witnessed many times in my organisation. A DBA comes in � his work excellent�a dedicated firefighter, like no other. Knows their job, knew what they had to do, knew the DBMS inside out, and worked many late nights/weekends when users wouldn't be disturbed. They moved on to another organisation. Stimulating your DBAs can be troublesome, especially as mentioned before with the ongoing advances in automation of certain database administrative tasks.

The team I currently lead has recently acquired a development arm. This area of work is a different kettle of fish. �Development DBAs� must work closely with the application developers�preferably directly with the development teams, and under the same project management. My DBAs need to liaise with the end users, often require their manager's buy-in with this process, and require negotiation with the project managers and user representatives to establish smooth and open communication channels. So don�t necessary divide your DBAs and in-house developers. For developers, DBAs need to be a highly visible service group.

Establish a good relationship with your DBMS vendor and make sure you can rely on its support. Stay in touch with other users of the same DBMS. When I was a budding DBA I attended many user conferences, technical seminars and product demonstrations. I found them extremely useful, not only in learning about advancing technologies but sharing my knowledge and experiences with other users from different backgrounds. Send your DBAs on everything that could enhance their learning, because at the end of the day it�s you and the organisation who should benefit also.

There are also strategies for learning on company time without outlaying any cash. Last year I found myself extolling the benefits of SQL 2005 Analysis Services to my boss as a way to achieve certain project requirements. While I could articulate the benefits I had no idea how to actually implement & configure the technology. My boss got excited about the concept and before I knew it I was tasked with finding out how much end-users would/could benefit from this relatively new functionality. I had to learn how to implement Analysis Services and how much we could benefit, all with the blessing of the boss. One year later � I am the boss! Most DBAs would thrive on the chance to investigate new functionality, new improvements in future releases etc

So to conclude, your DBAs are valuable assets, they have an important role to play in the organisation and have great responsibility for your data. Treat them well, let them grow and ensure you arm them with the tools to carry out their role in a more effective and efficient manner.

Remember there is always a way to improve the service you as a team or department provides your end-customers & user community.

As a manager you should strive to

�Get the most from your DBAs�

If you like this article - Read our others

Written by Justin Hostettler-Davies on 12 June 2009