Excerpts

Preface I originally conceived this book as a means of getting Microsoft support engineers to write down the many things they had learned from supporting SQL Server over the years. When I joined Microsoft, I was surprised to learn that much of the practical knowledge related to supporting the product (what those in epistemology refer to as "domain knowledge") that had been acquired by the support people was not written down anywhere. It was often communicated verbally and passed down from person to person via oral traditions. This, of course, led to people not knowing how to do their jobs unless someone was kind enough to show them the way. It was also extremely error prone. And it led to some of the most important knowledge about supporting the product being concentrated among just a handful of individuals--which worked out nicely for them, but not so well for the rest of the support group. I had been a fulltime software developer for over twenty years before joining Microsoft. Much to my surprise, I discovered that the upper ranks of the support organization consisted mostly of people who had at one time been developers themselves. Often, they had something in the neighborhood of three to five years of experience as developers before becoming support engineers. As a career developer, it was difficult for me to imagine finding support work truly fulfilling on a long-term basis. Support work, it seemed to me, was something akin to the janitor's job of the software development world. Someone had to clean up after all those messy developers, and that task often fell to the support staff. Although I knew it was important work, I could not personally envision being really happy pursuing support work as a career. Nevertheless, here were several former developers who evidently were. This mystified me. I began to think about how to level the playing field and make the knowledge possessed by the upper echelon of the support group available to everyone. It seemed to me that the deep understanding of how to support the product, the domain knowledge so prized by the folks on Mount Olympus, should be available to everyone in the organization. Everyone who supported the product should have equal access to it. My initial thought was that I would document how to troubleshoot the product in the book I was working on at the time, The Guru's Guide to SQL Server Architecture and Internals. However, it soon became evident to me that developing software or understanding it from a developer's perspective differs substantially from troubleshooting it. They are really two different disciplines. Although some overlap certainly exists, there is enough that is specific to troubleshooting the product that it warrants exploration and coverage of its own. When I finally finished my architecture book, I returned to this idea of somehow documenting the many low-level details and insights the support group had learned from years of troubleshooting the product--details not so much about how the product worked, but about how to solve tough problems relating to it. I began to discuss the idea with some of the support engineers to gauge their interest in it. I suggested that we do a multi-author project wherein they could codify their hard-won troubleshooting knowledge in print--not only for their fellow support engineers, but also for their customers. Many had never been published before, and I felt that potentially seeing their words in print might motivate some of them to finally put down in writing what had thus far only been divulged to a select few within the company. Responses ranged from tepid to enthusiastic, depending on the support engineer. After running down the roster of who was and was not interested in working on the project, it became obvious that I needed more authors to round out the book. There simply were not enough in the support organization who were willing and able to join the project. I could have gone outside the support group to Microsoft Consulting Services or completely outside the company to MVPs and the like, but I really wanted to limit the author corps to those who had seen the SQL Server source code. There is no substitute for having access to the source code and being able to step through it under a debugger. By studying the product's source, you can come to understand the SQL Server technology at a depth and to a degree that would otherwise be impossible. So, still in need of additional authors, I decided to extend an invitation to some of the top developers on the product team. Although completely distinct from the support group within Microsoft and focused on developing products, not supporting them, I knew many of these people personally and knew that they had spent a fair amount of their time debugging and troubleshooting complex problems with the product, particularly the parts they had built. You cannot write complex code without having to debug it occasionally, and I felt confident that they would augment the book's coverage of practical troubleshooting in novel and interesting ways. The response from my colleagues in the product group was roundly enthusiastic, and several of the top developers from the SQL Server team agreed to join the project. I was able to enlist the talents of the very people who wrote the code to talk about how to troubleshoot both complex and commonplace problems with it. You will not find this in any other book, and I am excited to have been a part of making it available to you. My architecture book tells you how SQL Server works. This book tells you what to do when something goes wrong with it. The former is generally applicable, regardless of what you might be doing with the server. The latter is, hopefully, an edge case (because the product does not break that often), but is something that can make the difference between a SQL Server application meeting customer needs and it going down in flames. Hopefully, you won't have problems with SQL Server. If you do, this book is a good place to begin your troubleshooting expedition. My thanks go out to my fellow developers on the SQL Server product team who wrote portions of this book: August Hill, Cesar Galindo-Legaria, Sameer Tejani, Santeri (Santtu) Voutilainen, Slava Oks, and Wei Xiao. I also want to thank the support engineers who lent their voices to the project: Bart Duncan, Bob Ward, and Cindy Gross. These people all have their own unique ways of thinking (and writing!), but you could not ask for a better cast of characters to accompany you as you tackle the practicalities of SQL Server 2005 troubleshooting. Ken Henderson August 21, 2006 (c) Copyright Pearson Education. All rights reserved. Excerpted from SQL Server 2005 Practical Troubleshooting: The Database Engine by Ken Henderson All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.