Free eBook: “Protecting SQL Server Data”

SQL Server security expert, John Magnabosco, has just authored the new book, Protecting SQL Server Data, the first book of its kind to be devoted to the protection of SQL Server data using encryption.

Covering both SQL Server 2005 and SQL Server 2008, the book handholds the reader, step-by-step, throughout this entire topic, from beginning topics, all the way to the most advanced.

image

Below is a list of the chapters from the book:

Chapter 1: Understanding Sensitive Data
Chapter 2: Data Classification and Roles
Chapter 3: Schema Architecture Strategies
Chapter 4: Encryption Basics for SQL Server
Chapter 5: Cell-level Encryption
Chapter 6: Transparent Data Encryption
Chapter 7: One-way Encryption
Chapter 8: Obfuscation
Chapter 9: Honeycombing a Database
Chapter 10: Layering Solutions

If you have been shying away from learning about SQL Server encryption because of a lack of any good sources to learn about it, now you don’t have any excuse, especially since the book is available as a free eBook from Simple Talk Publishing and Red Gate Software.

Help Design a New SQL Server Monitoring Tool

image

In an experiment in SQL Server community involvement, the members of Red Gate Software’s software development usability team have created a new website called www.thefutureofmonitoring.com. This team, among other teams at Red Gate Software, are working Version 2 of its popular SQL Response software.

The goal of the new website is to get your input on what you would like to see in a SQL Server monitoring tool. For example, what do you dislike about software installers, or what memory counters do you think are the most important? In fact, you can even help the usability team design a new dashboard.

Whatever you think about SQL Server monitoring tools, feel free to share those thoughts with the usability team at their new website. In fact, I have already given the team my input on the next version of SQL Response, and they would really like to hear from you too.

Backup to the Cloud – No Excuses

I used to work at a multi-billion dollar organization and, like most organizations that big, they kept backups of all their databases offsite in case some major catastrophe destroyed the data center. There was only one problem with their otherwise excellent plan; the offsite location for the backup tapes was the building next door, a mere 50 yards from the data center. Any disaster spectacular enough to take out the data center would most probably have damaged or leveled the building next door. Continue reading

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?