SQL Server 2005 Practical Troubleshooting The Database Engine

  • ISBN13:


  • ISBN10:


  • Edition: 1st
  • Format: Paperback
  • Copyright: 2006-12-08
  • Publisher: Addison-Wesley Professional
  • Purchase Benefits
  • Free Shipping On Orders Over $35!
    Your order must be $35 or more to qualify for free economy shipping. Bulk sales, PO's, Marketplace items, eBooks and apparel do not qualify for this offer.
  • Get Rewarded for Ordering Your Textbooks! Enroll Now
List Price: $59.99 Save up to $2.40
  • eBook
    Add to Cart


Supplemental Materials

What is included with this book?

  • The eBook copy of this book is not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.


The ultimate SQL Server 2005 reference book - Learn to troubleshoot and diagnose problems, from the creators of SQL Server 2005.

Author Biography

The authoring team is a mix of developers from the SQL Server development team and support professionals from Microsoft’s Customer Support Services organization. Seven developers from the SQL Server development team and three support professionals from Microsoft CSS contributed to this book.


SQL Server Development Team


August Hill has been a developer for more than 30 years. For the past six years he has been a member of the SQL Server Service Broker team. He’s made a number of contributions to the product in the area of supportability. When he’s not developing software he can be found playing guitar or tasting Washington wines. He can be reached at august.hill@microsoft.com.


Cesar Galindo-Legaria is the manager of the Query Optimizer group in SQL Server. He received a Ph.D. in computer science (databases) from Harvard University in 1992. After working for a graphics company in the Boston area, he went back to databases, doing post-doctoral visits in European research centers. In 1995 he joined Microsoft to work on a new relational query processor, first shipped with SQL Server 7.0, which introduced a fully cost-based query optimizer, a rich set of execution algorithms, and a number of auto-administration features. He has been working on query processing for SQL Server ever since. He holds several patents on query processing and optimization, and has published a number of research papers in that area.


Ken Henderson has been a developer for more than 25 years. He has worked with SQL Server since 1990 and has built software for a number of firms throughout his career, including H&R Block, the Central Intelligence Agency, the U.S. Navy, the U.S. Air Force, Borland International, JP Morgan, and various others. He joined Microsoft in 2001 and is currently a developer in the Manageability Platform group within the SQL Server development team. He is the creator of SQL Server 2005’s SQLDiag facility and spends his days working on SQL Server management tools and related technologies. He is the author of eight books on a variety of computing topics, including the popular Guru’s Guide series of SQL Server books available from Addison-Wesley. He lives with his family in the Dallas area and may be reached via email at khen@khen.com.


Sameer Tejani, originally from Arusha, Tanzania, has spent the past 10 years working at Microsoft in the SQL Server group. His work has exposed him to different areas of the SQL Server Engine, including the T-SQL execution framework, Open Data Services (ODS), connection management, User Mode Scheduler (UMS), and other areas. He is solely responsible for the infamous “non-yielding scheduler” error messages that support professionals have come to abhor! He is currently a software development lead in the SQL Server Security team. In his spare time, Sameer enjoys being outdoors and going on long bike rides. He lives with his wife Farhat in the Seattle area.


Santeri Voutilainen, better known as Santtu, has been a software design engineer in SQL Server storage engine team since 1999. He has worked closely on page allocation, latches, and the lock manager. A graduate of Harvard University, he is in the final stages of a master’s degree in computer science from the University of Washington. Although he calls Seattle home, Santeri was born in Finland and spent most of his young life in Nepal. He is an avid traveler and outdoorsman and spends his free time exploring the Pacific Northwest with his wife and one-year-old son. Santtu can be reached at sqlsanttu@vode.net.


Slava Oks is a software architect for the Storage Engine and Infrastructure team in SQL Server. He has been with Microsoft for more than nine years. During the SQL Server 2005 development, project he worked on architecture and implementation of SQLOS. He’s made a number of contributions to the product in the area of performance, scalability, supportability, and testability. He is also the author of a popular SQL Server’s blog located at blogs.msdn.com/slavao. When he’s not developing software he can be found playing sports or having fun with friends and family.


Wei Xiao worked on the design of the SQL Server Storage Engine in Microsoft from 1996 to April 2006. His main areas of focus are access methods, concurrency control, space management, logging, and recovery. He also worked on SQL Server performance monitoring and troubleshooting. He has spoken at several industry conferences, including Microsoft Tech Ed and SQL PASS. He is currently working on a Microsoft internal data storage project.


Microsoft Customer Support Services


Bart Duncan has worked with SQL Server and related technologies for about 10 years. He is currently an escalation engineer in the SQL Server product support group. Bart lives in Dallas, Texas, where he is fortunate to share a home with his wonderful wife, Dr. Andrea Freeman Duncan.


Bob Ward is a senior escalation engineer in Microsoft Customer Service and Support (CSS) based in the Microsoft Regional Support Center in Irving, Texas. He has worked with Microsoft for 13 years and has now supported every release of Microsoft SQL Server from 1.1 for OS/2 to SQL Server 2005. His background in the computer industry spans 20 years and includes database development projects with companies like General Dynamics, Harris Hospital, and American Airlines. Bob graduated with a bachelor’s degree in computer science from Baylor University in 1986. He currently lives in North Richland Hills, Texas, with his wife Ginger and two sons, Troy and Ryan. Bob spends his spare time coaching youth sports, cheering for the local professional sports teams, and sharpening his golf game for a dream of playing on the PGA Legends Tour.


Cindy Gross has been a member of the Texas Microsoft PSS support team for SQL Server and Analysis Services since 2000. Cindy has taken on many roles during this time, including support engineer, content lead, and Yukon readiness lead. Before joining Microsoft, Cindy was a SQL Server DBA for seven years, working on SQL Server versions 1.11 and later. She is an avid reader of science fiction and fantasy, with a special love for books starring women as fighters. Her favorite non-technical author is Sheri S. Tepper. Cindy spends many weekends racing her dirt bike–currently a 2004 Honda CRF250X. You may contact Cindy from her website http://cindygross.spaces.live.com/.

Table of Contents

Waiting and blocking issuesp. 1
Data corruption and recovery issuesp. 47
Memory issuesp. 137
Procedure cache issuesp. 183
Query processor issuesp. 225
Server crashes and other critical failuresp. 273
Service broker issuesp. 331
SQLOS and scheduling issuesp. 369
Tempdb issuesp. 411
Clustering issuesp. 425
Table of Contents provided by Blackwell. All Rights Reserved.


Preface 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 boo

Rewards Program

Write a Review