Reprinted from my editorial in Database Weekly.

I know a lot of DBAs who make SQL Server the focus of their life. In many ways, if you want to be an exceptional DBA, and stand out from the crowd, you don’t have a lot of choice about devoting a lot of time to your career. There are many reasons for this. For example, the nature of the DBA’s job often requires working long hours, working weekends, and being on call 24/7. Then there is the need to continually increase your knowledge, especially as SQL Server continues to become more bloated with features with every new release. And if you are involved in volunteering for the SQL Server community, time commitments can be huge.

Of course, there are many careers other than being a DBA that consume a lot of time, so the question I want to pose to you applies to many different careers. And the question is: "Are you focusing too much time on your career to the exclusion of doing other important things in your life?" For example, is it more important to attend a SQL Saturday, or go to the park with your family? Is it more important to keep up reading the latest blog posts, or to relax and watch a good movie? Is it more important to download SQL Server 2012 on your home computer and learn it than working on a hobby that you enjoy? These are all difficult questions that DBAs make on a daily basis.

In the SQL Server community, I know of a handful of DBAs who seem to be able to do it all. They are exceptional DBAs who excel at whatever they do, and at the same time, they also seem to have a non-SQL Server-related life that they enjoy. They have the best of both worlds. In other cases, I have seen DBAs who work very hard, devoting virtually all their time to their career, shining brightly, but only briefly, before burning out, and you never hear from them again.

Of course, most of us fall between these two extremes, and we are constantly trying to figure out how to best balance our career with our life. But this is not an easy task, Because of this, I thought it would be interesting to ask for advice on how you balance your career and your life. Share with us the problems you have faced with this balancing act, and how you have successfully resolved them. Or, perhaps if you are still figuring out how to balance everything, and you haven’t figured it out, feel free to share your problems so that perhaps others may offer advice. I know that I still have a lot to learn about this topic, and I am eager to learn from you.

This editorial was originally published in Database Weekly.

The November 2011 edition of Popular Science magazine was devoted to data. In fact, the special issue was called “Data is Power: How Information is Driving the Future”. The focus of the issue was how we can use data to transform the world. According to the magazine, in 2010, there was about 1.2 zetabytes of data, and that by the end of 2011 there will be about 1.8 zetabytes (a zettabyte is a trillion gigabytes). That’s a lot of hard drive space. And just think of the hard drives required to back all of this data. I think I am going to invest in some hard drive company stock right away.

While these are impressive numbers, raw data is worthless. For data to be useful, it must be analyzed and interpreted. While storing data is easy, putting data to good use can be very difficult. But this is not stopping organizations from around the world from trying.

For example, Google is in the process of collecting every word published since the year 1500, about 500 billion words so far. While this data will benefit many different areas of study, it has already created an entirely new field of study called culturomics, which is the study of human behavior and cultural trends though the analysis of digitized texts, which some people are using to predict general trends about the future. It reminds me a lot of Isaac Asimov’s Foundation book series, where a science he calls psychohistory, can predict the future. What psychohistory does is to combine the knowledge of history, sociology and mathematical statistics to make general predictions about the future, which is what culturomics essentially does. It is an interesting parallel between science fiction and science fact.

Today, as DBAs, we are mostly tasked with the management of data, but I don’t think most DBAs really fully understand the power that data has. In fact, most DBAs focus on their daily tasks and leave the application of the data to others. This gets me thinking. What if over the next 10, 25, 50 years or so the role of DBA evolves from its current role as essentially caretakers of data, to a more interesting role, such as those who interpret it for the good of society. For example, instead of just managing data, DBAs could evolve to become more like the scientists who study culturomics (or psychohistory).

As technology advances, the routine tasks of the DBA may slowly go away. So is the natural evolution of the DBA to become more of an interpreter of the data, or will the administrative role of the DBA eventually fade away, just as horse and carriages gave away to automobiles? Perhaps we need to use some culturomics to find out?

So what do you think? Will the role of the DBA evolve over time (think 10 or more years in the future), or will it eventually die, a forgotten role that only existed for a few decades as technology marched on and made it obsolete? By the way, while the November issue of Popular Science focused on data, there was nary a word about the role of the DBA in the magazine. Is this a sign that DBAs are already becoming less important, or is it because the current role of the DBA is not fully understood or appreciated?

Reprinted and amended from my editorial at Database Weekly.

For nearly 11 years now, one of the most common questions people e-mail me about is what SQL Server books do I recommend for the novice DBA. A decade ago, there were many, many titles available, and it was easy for me to recommend books. I had several favorites for many generic categories: “Introduction to SQL Server Administration”, “Introduction to Transact-SQL”, “SQL Server Certification”, and “Advanced SQL Server”.

However, over the past 11 years, as each new version of SQL Server has been released, there have been fewer and fewer SQL Server titles published. This is in spite of the fact that the number of DBAs has grown significantly. So why are there fewer SQL Server books being published?

There are many reasons. Some of them include:

• A huge amount of SQL Server content is freely available on the Internet;
• Higher book prices;
• Poorly written books put together in haste that harm the reputation of all technical books;
• Pirated copies of books available on the Internet;
• Authors generally don’t earn enough money from writing technical books to make it worth their time.

In fact, I believe that the biggest reason why fewer books are being published is because many of the good authors have given up writing entirely, which means that there are fewer good books to choose from. Of course, there are a number of top writers who still do persevere and write books.

While it is true that there is a lot of free SQL Server content available on the Internet, I am still one of those people who like to curl up with a real, physical book, and read it from beginning to end. And based from the e-mails I get, I am not the only one who feels this way.

Today, because of the lack of a wide selection of quality SQL Server titles, when I get questions about my favorite books, I have a much more difficult time recommending SQL Server books, especially those designed for novices (although there are a number of advanced titles that I regularly recommend).

So my question to you is this: what SQL Server titles have you read that you can highly recommend to novice DBAs? Share with us your favorite SQL Server books, and why you recommend them.

Reprinted from my editorial in Database Weekly.

In early 2000, I started a new DBA job with a large organization, as their first full-time SQL Server DBA. My first job was to clean up the mess left by several accidental DBAs who had gone before me, and who had implemented several SQL Server instances without really knowing what they were doing.

I was still a relative novice myself at the time, so I began researching a set of recommended best practices that could be adopted on all of the SQL Server instances that I managed. The problem I ran into was the scarcity of online SQL Server resources; I compiled my SQL Server Best Practices document almost exclusively from Books Online, a few published books, the occasional conference presentation, and what I learned from my own experience. I made the rather naïve assumption that everything I read was essentially "correct". Of course, I soon learned the hard way that this is not always the case.

Now jump ahead to 2011. There is now a vast amount of SQL Server information and ‘best practice’ advice available on the Internet, in the form of innumerable blogs, community sites and forums. Finding an answer to your question is much easier now than it was in 2000, but finding the right (or best) answer is harder than ever. Not only is there a huge amount of information to sift through, but the quality of that information ranges from top notch all the way down to very bad.

For novice DBAs, this is a tremendous problem. Even experienced DBAs still need to rely on the advice of others, in areas outside their realm of expertise. So, how do we separate the wheat from the chaff? I am fortunate in that I’ve been involved with the SQL Server community for a long time, and I’ve built up a strong network of people, blogs, and websites that I trust and to which I turn first when I need help. Even given this, however, I am smart enough now to know that not every best practice fits every situation, so I always test the advice, even of those I trust, just to be sure that it works well in my environment.

So my questions to you are these: where do you go to find best practice advice? What books, websites, blogs, and other sources do you trust the most, and why? Do you ever take this advice at face value, or do you always test it to ensure that it works well in your environment? Share with us you experiences so that we can all learn from it.

Reprinted from my editorial in Database Weekly.

When I was a junior DBA many years ago (even before the company I work for now, Red Gate Software existed), I ran across some third-party software for SQL Server that I thought could really benefit my productivity and save my organization money. I presented my case, proving how the new software would be beneficial to the company. My boss agreed with that the new software would indeed boost my productivity, he refused my request. When I asked why, he answer was “We are a 100% Microsoft shop, and I don’t want to introduce any third-party software into the mix.” He continued to say, “If we should every have any problem with the third-party software, then Microsoft and the third-party software company would point fingers at each other, and the problem would never get solved.”

I understood that my manager was being extremely conservative and didn’t want to risk any potential data corruption, but I thought he was just a bit too conservative.  Time actually proved my point. The particular product soon became a market leader, and I have never heard one time ever where the product ever caused data to be lost.
 
What reminded me of this old conversation was a recent discussion I overhead where one DBA said that he would never take any risk his data to any third-party product that interacted directly with SQL Server data. He seemed to an incarnation of my old boss. The other person in the conservation said that as long as the product was thoroughly tested, and proved safe, that why shouldn’t it be used.
 
So here’s my question to you this week. Do you fall into the camp of very conservative DBAs that don’t want any non-Microsoft product to touch their SQL Server data, or do you fall into the camp that if a product is proved safe, that it should be used if it can boost productivity and save your organization money? Share with us your opinion, and tell us why you believe the way you do.

• Internals and Performance
• Performance Tuning
• High Availability and Disaster Recovery
• Security, PowerShell, and Development Support

I attended the Internals and Performance class in Dallas, and I will also attend the Performance Tuning class in March, also held in Dallas. While these classes can be used to help you prepare for the MCM, they are designed to be taken by any DBA who wants to deepen their understanding of SQL Server. In fact, only a handful of the 29 attendees at the Internals and Performance tuning class were interested in pursuing the MCM. Most of them, like me, just wanted to gain a deeper level of understanding of SQL Server.

While his session was held in Dallas, only about a half dozen were from the Dallas area, with attendees coming from all across the United States and Canada. There was even one attendee from New Zealand. Most of the attendees were experienced senior DBAs or developers from a wide variety of small and large organizations. While I had meet a couple of the students before, most of them were new to me.

This week’s training was taught by Paul and Kimberly, with Kimberly doing about two thirds of the training. (Other training weeks may include different guest speakers.) One advantage of both of them teaching was that if whoever was teaching at the time wasn’t able to answer the question, the other one looked up the answer and provided it to the class. Great husband and wife teamwork.

The training was mostly lectured-based, with a lot of time spent using a whiteboard and PowerPoint slides, explaining the various topics. I like whiteboards, as this adds a visual component to the learning, which is good, as I am more of a visual learner than a verbal learner. Lectures were followed up with demos as needed. One thing the class did not include was labs, although we were given a DVD that had a VHD of Windows 2003 and SQL Server 2008 with about 60 hours of hands on labs that we could do on our own. I would have liked to have spent some lab time in class to help reinforce the learning, as I am not sure I will be able to find time to go through them on my own. On the other hand, the sessions were so information-packed I am not sure where any extra time could be found to do the labs in class, unless some of the existing content was removed, or the sessions last into the evening.

I have been a SQL Server DBA for over 16 years, and over the years I have attended many Microsoft Certified SQL Server Training classes, third-party training classes, one-day seminars, and more conferences than I can keep track of. This is on top of a lot of self-study and on-the-job experience. While I have learned a lot over the years, the learning has been fragmented, meaning that it has been hard for me to put everything into perspective.

The main reason I wanted to attend the SQL Server Immersion training was to help me review what I have learned in the past, to learn SQL Server at a deeper level, and get all this information in a concentrated form so that I could view it more holistically. This past week has met my expectations very well. While I was familiar with about 80% or so of the content, reviewing it as a whole has not only helped me to remember what I already know, but to help put many things into a better perspective than the fragmented knowledge I already had.

In many ways, the training reminded me of when I attended graduate school. Graduate school content was similar to what I had learned as an undergraduate, but it provided a greater depth of knowledge, and helped me to see the bigger picture. It also provided me with new knowledge and tools in my area of study. This same is true of the SQL Server Immersion Training. While I already had a great base of knowledge in SQL Server, the training has helped me to better understand SQL Server from a new perspective.

In many ways, the following paraphrased quote, which Paul said on the first day of training, I think does a great job of summarizing the benefits of attending the SQL Server Immersion training.

“My goal is not to tell you the exact answer, but to teach you how to determine what the best answer is for your situation. This is because most recommendations are generalizations, and don’t apply to all situations. Best practices are good starting points, but you have to determine for yourself what is best for your own systems.” –Paul Randal

If you want to raise your DBA career up to a new level, I highly recommend you attend the SQLSkills SQL Server Immersion training. The benefits from the training will begin to accrue immediately, and will help you throughout your entire DBA career.

From my Database Weekly editorial.

Most of us DBAs don’t work in a standard 40-hour a week job. We often have to work late, work weekends, and be on call just in case a problem arises. If you’ve been a DBA for a really long time, you still remember the days before the Internet, VPN connections, and cell phones. Back then, many DBAs carried a pager when on call, or took phone calls over a land line. In many cases, the only way to resolve the problem was to physically go into the office and check out the problem in person, no matter what time of the day it was.

Today, with modern conveniences such as the Internet, VPN connections, smart phones and, more recently, tablet computers, how we work when we are not at work has changed. For example, if we get an e-mail or phone call that a database or server has a problem, we can generally connect directly to the server and, in many cases, resolve the problem remotely, saving us the trouble and hassle of going into work.

So my first question to you is, when you are away from work and a database-related problem occurs, how are you generally notified? Do you still carry a pager? Do you receive an e-mail message? Does someone give you a call on your cell phone or land line?

Secondly, once you’ve been alerted, how do you generally connect to your servers to see what is going on? Do you use a smartphone, a tablet computer, a netbook/laptop/desktop computer?

And third, how often can you typically resolve the problem remotely, and how often do you still have to come into the office to fix things?

I have spoken to many DBAS and have heard many different answer these questions, but I’m always interesting in hearing more. So please, share with us how you work when you are not a work; I imagine we can all learn a lot from your experiences.

This is a reprint of my editorial in Database Weekly.

Scenario One: The new third-party application, purchased by your company without your involvement, is performing poorly on SQL Server. As the DBA, you are getting a lot of flak from users and management, but your hands are severely tied as to what you can do to fix the problem.

Scenario Two: The IT budget has been cut, one DBA position has been lost, and the money promised to replace your aging hardware is nowhere to be seen. And, by the way, you now have to take over all the duties that the laid off DBA used to do.

When faced with difficult times such as these, what do you do? Do you:

• Tell management, "If you had only listened to me in the first place"?
• Whine and complain to anyone who will listen?
• Keep quiet, but seethe with internalized anger and resentment?
• Get back at the company by doing something professionally unethical?
• Look for counseling with friends, co-workers, or even professionals, to get you through the tough times?
• Start looking for a new job?
• Accept the world for what it is and plough ahead, doing the best you can with what you’ve got?

At one time or another, everyone has been dealt an unfair hand, and life is just not fair. Sometimes the problems are small, like not getting the new server you wanted, or having to work overtime. In most cases, minor issues can be brushed aside because they are just small bumps in the road.

On the other hand, as in the scenarios described above, the problems can be major and can significantly affect how you feel about yourself and others, often shaking your self-confidence, maybe even leading to depression.

So my question to you is this: When you have been placed, through no fault of your own, in a really bad situation at work, how do you deal with it? What has worked for you, and what hasn’t?