This is a reprint of my editorial at SQLServerCentral.com. There is a lively discussion at the SSC forum on this topic, or feel free to comment here.

While being a DBA has many benefits, it can also be a job with many stressful drawbacks. Some of them that come to mind include:

• As the organization’s protector of the data, DBAs often have great responsibility. A careless mistake could potentially cost your organization thousands, if not hundreds of thousands of dollars (and your job).
• Many DBAs don’t work typical 40 hour weeks. Many work weeknights, weekends, and holidays, all without any overtime pay.
• Getting called at home in the middle of the night or on weekends, and often having to come into the office to fix a problem.
• While one crisis at a time is enough for anyone, there are often situations where multiple crises occur at the same time, creating a very hectic environment.
• Getting blamed for problems that are beyond your control, such as the poor performance of a badly-designed, mission-critical application.
• Being told to do one thing by one manager, but then being told to do something different by another manager.
• Being assigned a project without the necessary resources and time to complete it successfully.
• Having developers give you a bad time because you are trying to enforce best practices and to protect the integrity of the organization’s data.
• As a DBA, you often see a bigger picture of how IT works than others, giving you a great perspective on how to make things better, but only to have your ideas for improvements ignored.
• And on and on.

While you may not have experience all of these drawbacks, I am sure you have experienced some of them. So my question to you is: What’s the best way to deal with the inevitable stress of being a DBA? Are you the type of individual who thrives on stress, do you just tough it out, do you take action to reduce stress as much as possible, or do you have other ways of relieving stress? Please share with us how you cope with the stress of being a DBA.

This is a reprint of chapter 11 of my book, How to Become an Exceptional DBA, 2nd Edition, which is available as a free e-book here.

Physicians, attorneys, accountants, engineers, realtors, and many other professionals have written guidelines designed to discourage misconduct and illegal activity, and to promote the ethical conduct of their members. In fact, according to the Sarbanes-Oxley act, all public companies in the United States are required to create and follow their own code of conduct.

However, despite the fact that DBAs are essentially protectors of an organization’s knowledge, and privy to much confidential information, there is no clearly defined set of rules, values, standards, and guidelines to help govern and guide their behavior.

Continue reading →

"You can have everything in life that you want if you will just help enough other people get what they want."
– Zig Ziglar

Early in my career, I read a lot of books by self-help gurus, seeking advice on how to make my career successful. While I learned a lot of useful information, the one insight that has stuck with me the longest is the quote from Zig Ziglar you can see above. While this quote might be promising more than it can deliver, it still rings true with me in most cases. I find this advice particularly helpful when I am faced with situations where helping someone else might be inconvenient to me. Let’s look at one example…

Continue reading →

Over the years, I have dealt with a lot of third-party applications (and their vendors) that use SQL Server as their back-end databases. It has often been an uneasy relationship, fraught with pain and tribulation. The overriding feeling I have gotten from most of these vendors is that they could care less about the DBAs who have to install and manage their application’s databases.

Whatever excuse third-party vendors have for ignoring the DBAs who tend to their product’s databases, I think it is time that DBAs begin to fight back, and not take their uncaring attitude any more. Below, I have proposed a DBA Manifesto, a list of demands that we need enforce among all the third-party vendors we work with. If we stick together, and take the same stance, then perhaps we can get these vendors to be more helpful and cooperative.

Here are our demands to these third-party vendors:

Given the thousands, tens-of-thousands, or hundreds-of-thousands of dollars we spend on your product, please document how it works. Don’t force us to take the time to figure it out for ourselves through trial and error (we are already too busy), or to call tech support to get answer that could have easily been included in the documentation.

When we call tech support, have somebody available who not only thoroughly knows your application, but understands how it interacts with SQL Server. When I call up, complaining about a query executed by your application that is missing a WHERE clause and is returning over a million rows to a list box on a user’s screen, I expect that person to understand what I am talking about.

Don’t charge us $1,000+ a day, plus expenses, to install your software, when all we really need is decent documentation.

If you do force a consultant down our throat (as part of the total “sales package” for your application), have the decency to send one who knows your product, and SQL Server. More often than not, the expensive consultants who have shown up at my door barely understand how their product works, let along know anything about SQL Server. I have seen many consultants spend their entire onsite time on the phone, having someone step them through the installation process of their own application. Hey, if that’s all it takes, I can talk to the same person and my company doesn’t need to waste money on consulting fees.

Don’t tell us that only “your consultant” has the ability to configure SQL Server for your application on our hardware. Your consultant is not touching my SQL Server. They can instruct, and watch, but not touch. My former manager actually threw a consultant out from the building once because he demanded to be the one who performed the SQL Server configuration side of the installation.

Have a real SQL Server DBA on your staff who can guide your developers so they write properly optimized code, and so that if we have a question, we can speak to someone who really understands SQL Server.

Help us size the hardware needed to run your software. Give us some guidelines so we don’t end up under-sizing or over-sizing the hardware we buy to run your application.

Please ensure you have tested your software so that it meets our load requirements. On more than one occasion, I have found out that we were the vendor’s largest customer, and that they had never load tested their software for a company of our size.

Don’t blame SQL Server or Microsoft for slow running code. You are the company who has written the application.

Don’t tell us that your application requires SA access to run.

Use a properly normalized database design, write optimized queries, and include appropriate indexes.

Write your code so that it is optimized for SQL Server, not written generically so that it can also run with other databases. This almost always hurts performance.

Don’t ever tell me I can’t add indexes or security to your database. I have had vendors tell me that if I make any change in their database, that it will void our support contract. Those are fighting words to me. The only reason I have to do this is because you don’t know what you are doing, and I have to fix your mistakes.

When it’s time to upgrade, provide a clear migration path, and perform the database migration automatically. Don’t expect me to manually port the data from your old schema to your new schema.

Do you agree with these demands? Do you have other demands? Will you try to enforce these upon your vendors? Tell me what you think. DBAs, we must unite against the tyranny of third-party vendors!