Does Maturity Make a DBA?

I have been a DBA for about 14 years, and I have been fortunate to meet hundreds of other DBAs throughout my career, many of whom are now my friends, even though most of them live thousands of miles away from me.

While there are exceptions, most of the DBAs *I* have met seem to fit into one or more of the following categories:

  • Conservative, not necessarily in the political sense, but in how they conduct their lives.
  • Stable, dependable, and reliable.
  • Family-oriented, who puts their family first.
  • Hard-working, doing whatever it takes to get the job done, and providing for people close to them.
  • Community-minded, often helping others and volunteering their time for various community causes.
  • People of faith, participating in their chosen religion.

In other words, DBAs tend to be mature, responsible individuals, generally the kind of person that you would want as friend, or as a next door neighbor.

This has got me thinking. Are DBAs drawn to their work (as a DBA) because the nature of DBA work fits well with the characteristics described above, or is it because employers seek out such individuals with these characteristics, because they know these types of individuals will do a good job in a position of great responsibility? Of course, there’s also the possibility that their personal maturity is actually a secondary consideration to their professional maturity, and the two just happen to feed off each other. What I mean is that I think a lot of DBAs have already had first careers and are coming to this new arena later in life. It could be that employers are actually drawn to those of us who are wise in the ways of the world, and bring a longer perspective to the role.

So, what do you think? Are DBAs drawn to their work because of their maturity, or do organizations who hire DBAs tend to prefer mature employees? Or am I full of baloney, and perhaps DBAs are no different than anyone else?

Do You Need an IT or CS Degree to be a Successful DBA?

When I am making small talk with DBAs I know, one of the things I like to ask them is what their college degree is in. While Information Technology (IT) or Computer Science (CS) degrees are common responses, most DBAs I know don’t have a degree in IT or CS. In fact, the types of degrees they hold range wildly. Some of the responses I have gotten include:

  • PhD in Clinical Psychology
  • BA in Creative Writing
  • BS in Geology
  • Masters in Engineering
  • PhD in Organizational Psychology
  • Pharmacy
  • BA in Philosophy
  • BS in Hydrology
  • BA in Linguistics
  • Masters in Business Administration

Personally, I have a BA in Economics and a Masters in Business Administration, and I only took one computer-related course during my undergraduate and graduate studies.

Once I find out what degree a DBA friend has, I often follow up, asking them how they became a DBA. This provides an even more diverse set of stories, most of which are rooted in a deep interest in technology, and through some unplanned and convoluted set of events, they are now successful DBAs.

So my question to you is, what is your college degree in? And to follow up, how did you get from where you stated to where you are today? And last of all, does your college degree really make all that much difference in your success as a DBA?

Physical File Defragmentation

Do You Include Physical File Defragmentation as Part of Your SQL Server Maintenance?

Ever since I can remember, beginning with MS-DOS 1.0, physical file fragmentation has often been a problem on many systems I have used, hurting I/O performance as the disk heads have to thrash about to find all the many file fragments that make up a single physical file. Generally, using either the built-in OS defragmentation tools, or third-party tools, I have kept my physical files defragmented, so they are contiguous, helping to optimize my system’s I/O.

As technology has changed (SANs or SSD drives) physical file fragmentation has become less important. See Linchi Shea’s blog series on this topic. On the other hand, there are still a lot of servers with local storage that can be still be negatively affected by physical file fragmentation.

When I build a new physical box to run SQL Server, the new box has little or no physical file fragmentation to start with. Then, when I create my MDF and LDF files, I pre-size them to as close as I can to their final size (or at least as large as I expect them to grow in the next year or so). This way, when the MDF and LDF files are created on a new server, they are created in a contiguous manner, and there is no physical file fragmentation. Of course, if I do need to grow the MDF or LDF files, I do so in a controlled manner to minimize fragmentation. I avoid using autogrowth to grow my databases, as this can greatly contribute to file fragmentation as the MDF and LDF files grow over time.

In other cases, I have to deal with SQL Servers that have been around for a long time and have not been properly maintained. In those cases, I check for how bad fragmentation is, and if it is bad, I fix it before I create any new pre-sized MDF or LDF files. As a DBA, I prefer to be proactive and prevent physical file fragmentation from occurring in the first place.

What I would like to know is what has been your experience with physical file fragmentation on your SQL Servers? Have you experienced it? How has it affected performance? How do you fix it if you have it? What defragmentation tools do you use, and why? How do you prevent it from happening in the first place? In other words, how do you deal with physical file fragmentation on your SQL Servers?

Online T-SQL Scripts and Copyright

There are thousands of Transact-SQL scripts available on the Internet. They provide a great way to learn how other people approach and solve the same kind of problems you have and, in many cases, will save you from having to “reinvent the wheel”. When I need a new script, the first thing I always do is to check out the sizeable script libraries on SQLServerCentral.Com,Codeplex.Com, and other SQL Server-related websites. If I can’t find what I need, then I usually resort to a Google search. If that turns up nothing, only then do I resort to writing it from scratch.

While these T-SQL script archives are a wonderful resource, they also have a few drawbacks. The issue of variable code quality has been well-discussed and you should always carefully evaluate and test any online scripts before using them. A lesser known, but equally important issue, is the one of copyright. Sometimes the situation is clear-cut. I have seen a few scripts that carry a copyright notice explicitly stating that you can’t use the script without first obtaining permission from the author. In a few, ideal, cases the script author will have included some form of notice stating that the code has been published with a free public license, such as the one described at www.fsf.org. In this case, you will know that using the code won’t get you into any potential legal trouble.

However, in the vast majority of cases, the scripts are published without any form of copyright notice. Most people assume, incorrectly, that these scripts are freely available for reuse. In the United States, by law, any creative work is automatically copyrighted by its author, even if the author does not specifically include a copyright notice within the work. In other words, you need to get express permission from the author to use their script.

In theory, if you reuse a script that does not have any copyright notice, you leave yourself, and the organization you work for, open to potential legal action from the script author, or from whoever owns the copyright for the script. Furthermore, making a small modification to a script does not necessarily protect you from copyright issues. If you base the code you write on someone else’s code, you still may be violating copyright law.

The issue of copyright can get particularly sticky if the script author does not actually “own” the script. For example, it is not uncommon, especially at larger organizations, for employee contracts to stipulate that any creative work that an employee produces, while on the job, belongs to the organization. Any DBA subject to such an agreement should not share scripts on the Internet without specific permission from their organization. The problem is that, in the absence of a clear copyright statement, there is no way of telling who owns the script or even if the script author had permission to post it.

Because there are so many grey areas in copyright law, I would like to encourage all T-SQL script writers to:

  1. Verify that you own the code you write and, if not, that you have permission to share it.
  2. Include a free public license with any code you publish.

This way, people using your script can rest assured they are complying with copyright laws. I’d like to hear what you think. What is the best source of online scripts? How do you deal with the dilemma of scripts without any form of copyright notice? Do you think T-SQL script writers should include a free public license with the code they share?

Do You Verify Your Database Backups?

In the past, I have written and spoken a lot about SQL Server “best practices”. One that I emphasize over and over again is the need for DBAs to verify, regularly, the integrity of their database backups. However, I sometimes feel my advice is falling on deaf ears. When giving a presentation, I often ask how many DBAs in the audience regularly verify their backups. Invariably, few hands are raised. When I visit a SQL Server shop to review their database maintenance plans, I always ask the same question. Very few even know what I am talking about.

Why is this? Do some DBAs have a false belief that database backups are always perfect? Perhaps these DBAs don’t know the mechanics of to how to verify a backup? Maybe, they just don’t have the time to perform the verification? Most likely, they haven’t even given the issue any thought because they have not – yet – had a restore fail, and had to explain to an irate manager why their data is lost.

Backup verification is a vital part of a well-designed database maintenance plan. Fortunately, I learned this lesson very early in my career. Back in 1982, a time before hard disks were available for desktop computers, I worked for a computer retail store that performed its accounting on a desktop computer, storing the data on floppy disks. Every day, the owner of the company would religiously make backups of the floppy disks and then sit these backups on the floor, next to her desk. Also, every night, she would vacuum her office, keeping it nice and tidy to meet with customers. One day, one of the main floppy disks became corrupted, so she went to her backup floppy disks in order to restore her data. The only problem was that backup floppy disks had all been corrupted by the vacuum cleaner’s strong magnetic field. None of her backups were good. She had to start from scratch, reentering all of the lost data by hand.

It was a very painful lesson and ever since then I have been a fanatic when it comes to making lots of backups, and regularly verifying that I can restore them if needed.

I’d be interested to hear how regularly people here test the integrity of your database backups, how often you’ve encountered environments where test restores were never performed, and what excuses were given for this.

Do You Run Antivirus Software on Your SQL Servers?

I have been to some IT departments where the standard procedure is to install antivirus/antispyware software on all servers, no matter what applications are running on it. In addition, the default settings are left untouched, which means that virtually every byte of data is examined, in real time, before it is read or written to disk. This virus checking is in addition to any regularly scheduled scans of most of the files on the server’s drives.

If you have ever examined the amount of memory, CPU, and disk I/O resources used by antivirus/antispyware software, you will know that it is a performance hog and, on a busy SQL Server, can cause huge performance issues for your users.

So what do you do? Depending on your situation, you have one of three options:

  1. Run the AV software using its default settings, and buy big enough hardware to overcome any resource contention issues.
  2. Remove the AV software entirely, but take other measures to help ensure that viruses can’t affect your server.
  3. Compromise. Some DBAs remove the AV software from their SQL Servers, but remotely scan it from another server on a scheduled basis, and during a time when the server is not too busy. Other DBAs leave the AV software on their SQL Servers, but change the default settings so that the scans exclude .mdf, .ldf, .ndf, .bak, .trn, full-text catalog files, and any folders that include Analysis Services data.

If your SQL Server is running on a web server that is accessible from the Internet, then the first option might be the right choice. If your SQL Server is running on a closed network, then the second option might work fine. If your SQL Server is in a mixed environment, combined with other servers and end-users connected to the same network, then the third option might be best.

So, here’s my question to you. Have you given any serious thought as to the level of antivirus/antispyware protection you need for your SQL Server instances, and to the performance implications of the strategy you have chosen? If you have, tell us what you have done, and why you have made the choices you did.