Today I attended four regular sessions, plus a special lunch session for Microsoft MVPs. The sessions I attended varied a lot in quality, although there were two sessions that stood out. Both of these sessions were by the same speaker, Sunil Agarwal, a Program Manager in the Microsoft SQL Server Storage Engine Group. His first session was on “Strategies to Get Maximum Concurrency for Your Workload in Microsoft SQL Server” and his second was on “Microsoft SQL Server Data Compression: Experience and Changes”.

While I am familiar with both topics, I still learned new things. For example, I finally understood the difference between the read committed isolation and snapshot isolation levels that were introduced in SQL Server 2008. Sunil’s examples made it much easier for me to understand how they worked and when to use them.

In Sunil’s data compression session, I learned that SQL Server 2008 R2 now supports row compression on Unicode data types, which was not the case with the original SQL Server 2008. This new engine feature can really improve data compression in any database that uses Unicode. While row and page compression can benefit many companies, it is only available in the Enterprise and Data Center editions of SQL Server 2008 R2.

During lunch I had in interesting conversation with an attendee whose main job was desktop support. We talked a little about his work, and I finally got around to telling him that I was a DBA. Then he chimed in, telling me that he was the “DBA” of several SQL Server instances in his organization. While desktop support was his main task, he fell into the category of the “accidental DBA,” which seems to becoming more and more common among IT staff, especially within smaller organizations.

I was a little curious about how he maintained his servers as he didn’t appear to have a lot of SQL Server experience, so I asked him several basic questions about how he handled his DBA duties. Essentially, he didn’t do anything with the SQL Servers, except take daily backups, which were stored locally on the SQL Server hardware itself. He performed no other maintenance, didn’t store the backups offsite, or really had any knowledge of what it meant to be a SQL Server DBA. I treaded carefully, not wanting to hurt his feelings, but I briefly mentioned that he might want to consider taking a more active role as the DBA, but he wasn’t really interested in learning more. He said that it was no big deal if the SQL Server instances went down or if any data was lost. He was also making the assumption that if a database became corrupt that he could perform a restore. He neglected to consider the possibility that the hardware might crash and his backups disappear. In addition, I doubt if he had the knowledge of even how to properly restore a backup.

Up to this point, he has been lucky and has never experienced any data loss, which I think make him feel overconfident. He has yet to learn the lesson that there are only two kinds of DBAs: those that have lost data, and those who will eventually lose data.

I felt a little sorry for the guy, as he has been forced into being a DBA without any training or direction. What I wonder is if the organization he works for realizes the predicament they are in? While he says the SQL Server’s data isn’t all that important, is this his own personal opinion, or the opinion of the organization he works for? I would imagine that if an organization invests in software and hardware that needs SQL Server, that the data may be more important than he thinks it is. I didn’t want to say much more, other than mentioning that he might want to consider looking into learning more about SQL Server, as I didn’t think it was my place to tell him how to do his job.

This got me thinking some more, and I wonder many thousands, if not tens of thousands, of SQL Server instances are being maintained (actually, not being maintained) in this same way, and what the significance this is to these organizations. I imagine (at least hope) that if the owners or managers of these organizations better understood the implications of poor SQL Server management, that most of them would take the necessary action to ensure that their SQL Server instances were better maintained or protected. The problem is how do we, as professional DBAs, educate organizations of the importance of taking proper care of their data. I don’t have a good answer, but perhaps you might have some suggestions that you can add to the comments section below.