SQL Server 求生秘籍(SQL Server故障排除圣经)
基本信息
- 作者: (美)Ken Henderson 微软SQL Server开发小组和支持部门 [作译者介绍]
- 译者: 若启 一辉 瞿杰
- 丛书名: 图灵程序设计丛书.数据库系列
- 出版社:人民邮电出版社
- ISBN:9787115191113
- 上架时间:2009-2-5
- 出版日期:2009 年2月
- 开本:16开
- 页码:342
- 版次:1-1
- 所属分类:
计算机 > 数据库 > SQL Server
编辑推荐
微软SQL Server内部技术资料大曝光.
来自SQL Server开发小组和支持部门的梦之队打造..
SQL Server故障排除圣经...
推荐阅读
内容简介回到顶部↑
本书帮助你解决众多数据库引擎方面的问题,每一章从关键的sql server 组件入手,然后探讨用户遇见的常见问题,并给出解决方案。本书的主要内容包括等待和阻塞、数据毁坏和恢复、内存、过程缓存、查询进程等。本书的作者都是来自微软公司sql server 开发团队和客户支持服务部门的支持专家。在你的sql server 系统遇到问题时,本书将变得不可或缺。
本书适合数据库管理员和数据库开发人员阅读。
作者简介:
ken henderson(1967-2008)sql sewer世界级权威。生前供职于微软sql sewer开发组。以guru's guide系列经典著作和sqldiag等工具享誉业界。
创作团队 来自sql server开发小组的7位开发人员和来自微软客户支持服务机构的3位支持专家,他们都有丰富的开发经验,熟悉sql sewer源代码。
本书适合数据库管理员和数据库开发人员阅读。
作者简介:
ken henderson(1967-2008)sql sewer世界级权威。生前供职于微软sql sewer开发组。以guru's guide系列经典著作和sqldiag等工具享誉业界。
创作团队 来自sql server开发小组的7位开发人员和来自微软客户支持服务机构的3位支持专家,他们都有丰富的开发经验,熟悉sql sewer源代码。
作译者回到顶部↑
本书提供作译者介绍
本书的创作团队由来自SQL Server开发小组的开发人员以及来自微软的客户支持服务机构的支持专家组成。其中7位来自SQL Server开发小组,3位来自微软的客户支持服务部门。.
SQL Server开发小组
August Hill是一位具有30多年开发经验的开发人员。在过去的6年里,他一直是SQL Server Service Broker小组中的一员。他为该产品在可支持性方面做出了许多贡献。在业余时间里他喜欢弹吉他以及品味华盛顿葡萄酒。他的联系方式是august.hill@microsoft.com。
Cesar Galindo-Legaria是SQL Ser.. << 查看详细
SQL Server开发小组
August Hill是一位具有30多年开发经验的开发人员。在过去的6年里,他一直是SQL Server Service Broker小组中的一员。他为该产品在可支持性方面做出了许多贡献。在业余时间里他喜欢弹吉他以及品味华盛顿葡萄酒。他的联系方式是august.hill@microsoft.com。
Cesar Galindo-Legaria是SQL Ser.. << 查看详细
目录回到顶部↑
第1章 等待和阻塞
1.1 等待类型
1.2 对阻塞问题进行故障排查
1.3 识别阻塞
1.3.1 通过sys.dm_os_waiting_tasks来识别阻塞
1.3.2 从统计上识别阻塞
1.4 确定阻塞的原因
1.4.1 当前的语句和计划
1.4.2 阻塞模式
1.4.3 阻塞链
1.5 资源类型的细节
1.5.1 闩锁
1.5.2 锁
1.5.3 外部等待类型
1.5.4 计时器和队列等待类型
1.5.5 io操作的等待类型
1.5.6 其他等待类型
1.6 死锁
1.7 监视阻塞
1.7.1 等待的统计信息
1.1 等待类型
1.2 对阻塞问题进行故障排查
1.3 识别阻塞
1.3.1 通过sys.dm_os_waiting_tasks来识别阻塞
1.3.2 从统计上识别阻塞
1.4 确定阻塞的原因
1.4.1 当前的语句和计划
1.4.2 阻塞模式
1.4.3 阻塞链
1.5 资源类型的细节
1.5.1 闩锁
1.5.2 锁
1.5.3 外部等待类型
1.5.4 计时器和队列等待类型
1.5.5 io操作的等待类型
1.5.6 其他等待类型
1.6 死锁
1.7 监视阻塞
1.7.1 等待的统计信息
前言回到顶部↑
原本我想在本书中让微软技术支持工程师撰写多年来在SQL Server的技术支持工作中所学到的知识。当我加入微软后,令我惊奇的是,技术支持工程师们并没有把关于产品支持的实践知识(在认识论中叫作“领域知识”)记录下来。这些知识仅仅停留在口口相传的状态。.
当然,这导致了一个问题:人们并不知道如何做好工作,除非有热心人来向他们展示该如何做。这也是一种非常容易犯错误的方式,会导致一些最重要的产品支持知识集中在少数人手中——这些经验被他们充分利用,但其他的支持团队却不了解这些知识。
加入微软之前,我做全职软件开发工程师已经20多年了。令我十分惊讶的是,原来支持部门的高端人群都是些曾经做过开发的人。通常,在成为技术支持工程师之前,他们都有3~5年的开发或相关工作经验。作为一名职业开发人员,我很难想象技术支持也可以做长工。对于我来说,支持工作似乎与软件开发世界中的看门人类似。他们不得不帮那些编写乱糟糟代码的开发者“擦屁股”的人。虽然我知道这很重要,但是私下里还是觉得把技术支持工作作为职业并不是一件开心的事。尽管如此,确实有好几个程序员前辈呆在技术支持部门,这让我感到迷惑。
于是,我开始思考如何创造人人机会均等的局面,让原本只有技术支持的上层梯队才能拥有的知识可以传达给每个人。奥林匹斯山上的家伙们对拥有产品支持的全面知识和领域知识引以为豪,对于我来说,这些知识应该分享给组织中的每个人。每一个做产品支持的人都应该有相同的权限来了解它们。
我最初打算在我写的The Guru’s Guide to SQL Server Architecture and Internals一书中加入如何对产品进行故障排查的内容。然而,我很快意识到,开发软件或从开发人员的角度理解软件与故障排查有本质上的不同。可以说,它们是两种完全不同的领域知识。虽然有些部分是重叠的,但对产品故障排查而言,肯定有一些属于它自己特有的东西。
在我最终完成那本关于架构的书后,开始回过头来思考这个问题——如何把支持组在多年里学到的关于产品故障排查的许多低层次的细节和洞察记录下来,并不会有很多关于产品如何运行的详细信息,而是如何解决与产品有关的问题的详细信息。于是我开始与一些支持工程师探讨这个想法,并试探他们对此的兴趣。我建议做一个多作者的项目,在该项目中他们可以把一些难得的故障排查经验发表出来——这不仅仅是为了那些做技术支持的同事们,也为了客户。许多东西还从未被出版过,我感到,如果他们可以看到自己的文字出现在出版物中,最终会激励他们投身于写一些可能只有微软内部的少数人知道的东西。..
什么样的回应都有,从不太热情到很热情。在翻遍了关于哪些人感兴趣和哪些人不感兴趣的花名册之后,我发现,很明显,我需要更多的作者加入到本书的写作队伍中来。在支持部门中,愿意并能够投身到该项目中的人寥寥无几。
我本可以抛开支持组,而跑到微软咨询服务部门,或干脆去找那些最有价值专家(MVP)和类似的人选,但其实我很想把作者队伍限制在那些看过SQL Server源代码的人之中。访问过源代码并一步一步调试过,这种经历是不可替代的。通过研究产品代码,可以更深地理解SQL Server技术,从一定意义上讲,其他方法是做不到这一点的。
因此,我们还需要多引入一些作者,我决定向产品组的一些顶级开发人员发出邀请。虽然微软的产品组与支持组截然不同,他们关注的是开发产品,而不是提供技术支持,但我私下认识他们中的许多人,并知道他们已经花了大量的时间来调试和解决产品中的一些复杂问题,特别是对他们自己所创建的那部分。如果你从不调试代码,是写不出复杂代码的。我相信他们肯定会觉得新颖且有趣,愿意为本书增加一些实际的故障排查知识。
产品组的同事给我的答复都很热情,有好几个来自SQL Server组的顶级开发人员同意参加这个写作项目。我终于成功邀请到了真正写代码的人来探讨如何进行复杂且常见的问题的故障排查。在其他书中,你是找不到这些的,作为参与者,能够让你看到这些内容让我感到激动。
我那本讲架构的书告诉你SQL Server是怎样运转的,这本书则告诉你SQL Server要是不转了怎么办。前一本书,不管你要处理SQL Server的哪一块,都用得上。而现在这本,按说只用于极端情形(因为SQL Server这个产品并不会经常挂掉),然而你的SQL Server应用是一直能让用户满意呢,还是会随时引起用户的怒火,有没有本书差别可就大喽。当然我希望你不会在使用SQL Server时遇到问题。如果遇到了,本书将是你开始故障排查征程的起点。
在此,我要感谢SQL Server产品组中那些做开发的同事们,他们为本书提供了不少内容,分别是:August Hill, Cesar Galindo-Legaria, Sameer Tejani, Santeri (Santtu)Voutilainen, Slava Oks和Wei Xiao;我也要感谢几位技术支持工程师,是他们为这个项目提出了宝贵意见:Bart Duncan, Bob Ward和Cindy Gross。他们都有自己独特的思考(和写作!)方式,但帮助你处理SQL Server故障排查中的一些实际问题,这帮人再合适不过了。...
Ken Henderson
当然,这导致了一个问题:人们并不知道如何做好工作,除非有热心人来向他们展示该如何做。这也是一种非常容易犯错误的方式,会导致一些最重要的产品支持知识集中在少数人手中——这些经验被他们充分利用,但其他的支持团队却不了解这些知识。
加入微软之前,我做全职软件开发工程师已经20多年了。令我十分惊讶的是,原来支持部门的高端人群都是些曾经做过开发的人。通常,在成为技术支持工程师之前,他们都有3~5年的开发或相关工作经验。作为一名职业开发人员,我很难想象技术支持也可以做长工。对于我来说,支持工作似乎与软件开发世界中的看门人类似。他们不得不帮那些编写乱糟糟代码的开发者“擦屁股”的人。虽然我知道这很重要,但是私下里还是觉得把技术支持工作作为职业并不是一件开心的事。尽管如此,确实有好几个程序员前辈呆在技术支持部门,这让我感到迷惑。
于是,我开始思考如何创造人人机会均等的局面,让原本只有技术支持的上层梯队才能拥有的知识可以传达给每个人。奥林匹斯山上的家伙们对拥有产品支持的全面知识和领域知识引以为豪,对于我来说,这些知识应该分享给组织中的每个人。每一个做产品支持的人都应该有相同的权限来了解它们。
我最初打算在我写的The Guru’s Guide to SQL Server Architecture and Internals一书中加入如何对产品进行故障排查的内容。然而,我很快意识到,开发软件或从开发人员的角度理解软件与故障排查有本质上的不同。可以说,它们是两种完全不同的领域知识。虽然有些部分是重叠的,但对产品故障排查而言,肯定有一些属于它自己特有的东西。
在我最终完成那本关于架构的书后,开始回过头来思考这个问题——如何把支持组在多年里学到的关于产品故障排查的许多低层次的细节和洞察记录下来,并不会有很多关于产品如何运行的详细信息,而是如何解决与产品有关的问题的详细信息。于是我开始与一些支持工程师探讨这个想法,并试探他们对此的兴趣。我建议做一个多作者的项目,在该项目中他们可以把一些难得的故障排查经验发表出来——这不仅仅是为了那些做技术支持的同事们,也为了客户。许多东西还从未被出版过,我感到,如果他们可以看到自己的文字出现在出版物中,最终会激励他们投身于写一些可能只有微软内部的少数人知道的东西。..
什么样的回应都有,从不太热情到很热情。在翻遍了关于哪些人感兴趣和哪些人不感兴趣的花名册之后,我发现,很明显,我需要更多的作者加入到本书的写作队伍中来。在支持部门中,愿意并能够投身到该项目中的人寥寥无几。
我本可以抛开支持组,而跑到微软咨询服务部门,或干脆去找那些最有价值专家(MVP)和类似的人选,但其实我很想把作者队伍限制在那些看过SQL Server源代码的人之中。访问过源代码并一步一步调试过,这种经历是不可替代的。通过研究产品代码,可以更深地理解SQL Server技术,从一定意义上讲,其他方法是做不到这一点的。
因此,我们还需要多引入一些作者,我决定向产品组的一些顶级开发人员发出邀请。虽然微软的产品组与支持组截然不同,他们关注的是开发产品,而不是提供技术支持,但我私下认识他们中的许多人,并知道他们已经花了大量的时间来调试和解决产品中的一些复杂问题,特别是对他们自己所创建的那部分。如果你从不调试代码,是写不出复杂代码的。我相信他们肯定会觉得新颖且有趣,愿意为本书增加一些实际的故障排查知识。
产品组的同事给我的答复都很热情,有好几个来自SQL Server组的顶级开发人员同意参加这个写作项目。我终于成功邀请到了真正写代码的人来探讨如何进行复杂且常见的问题的故障排查。在其他书中,你是找不到这些的,作为参与者,能够让你看到这些内容让我感到激动。
我那本讲架构的书告诉你SQL Server是怎样运转的,这本书则告诉你SQL Server要是不转了怎么办。前一本书,不管你要处理SQL Server的哪一块,都用得上。而现在这本,按说只用于极端情形(因为SQL Server这个产品并不会经常挂掉),然而你的SQL Server应用是一直能让用户满意呢,还是会随时引起用户的怒火,有没有本书差别可就大喽。当然我希望你不会在使用SQL Server时遇到问题。如果遇到了,本书将是你开始故障排查征程的起点。
在此,我要感谢SQL Server产品组中那些做开发的同事们,他们为本书提供了不少内容,分别是:August Hill, Cesar Galindo-Legaria, Sameer Tejani, Santeri (Santtu)Voutilainen, Slava Oks和Wei Xiao;我也要感谢几位技术支持工程师,是他们为这个项目提出了宝贵意见:Bart Duncan, Bob Ward和Cindy Gross。他们都有自己独特的思考(和写作!)方式,但帮助你处理SQL Server故障排查中的一些实际问题,这帮人再合适不过了。...
Ken Henderson
媒体评论回到顶部↑
“本书的内容是其他任何博客、网站和图书都没有的。系统出问题时,它将成为你的救命稻草。”.
——Pinal Dave,微软MVP
“此书写得非常好,涵盖了对大量复杂问题进行故障排查的详细解析。我认为每一位优秀的MSSQL DBA都应该拥有。”...
——Amazon.com评论
——Pinal Dave,微软MVP
“此书写得非常好,涵盖了对大量复杂问题进行故障排查的详细解析。我认为每一位优秀的MSSQL DBA都应该拥有。”...
——Amazon.com评论







点击看大图






加载中...

