第24学时排错

第24学时：排错
有时在你作为一名SQL Server数据库管理员的生涯中，会碰上这样的头疼事情—你的一
个用户数据库瘫痪掉了。问题不在于是否发生，而在于什么时候发生。这将是一个令人感到
厌烦的时刻。你的用户会问什么时候能解决，同时管理部门将查问发生了什么和谁是责任者，
而你也会问自己现在该做些什么。在这学时里，我将讲解你要用到的基本排错步骤和工具。
排错是一项很复杂的工作，而掌握它的唯一途径是实践。
本学时的要点包括：
• “全完了！”
• 排错步骤
• SQL Server信息资源
• SQL Server错误信息
• 处理损坏的信息库
• Database Consistency Checker
• 使用跟踪标志
• 其他信息源
24.1 “全完了！”
对许多SQL Server的数据库管理员来说，第一份问题报告是由用户提出的。通常他会敲
开你的门，叫到“服务器坏掉了”或是“全完了”。这瞬间你会感到恐慌，你在猜想哪儿出了
毛病，可能需要花几个不眠之夜来修复它。就像我先前提到的，这是一个非常令人厌烦的时
刻。这时，你头脑中会一片空白。这些都说明了排错的重要性。虽然修复SQL Server可能会
很难，但是收集信息和查找故障的步骤却不太难。
24.2 排错步骤
排错过程只有很少的几步。这些步骤适用于任何服务器，而不是仅限于SQL Server。这
些步骤包括：首先，收集故障信息；其次，通过数据分析故障原因；然后，试着修复；最后
检测故障是否已排除。
24.2.1 文档准备
无论你是否相信，排错的第一步是文档准备，你应该在问题发生之前就在这上面花大量
时间。你要记录你对该服务器所做的一切。一个办法就是为每个服务器建立一个登记本。不
管你做了什么无关紧要的改动，都应该记在本子上。这包括从创建新用户登录到改变许可，
以及应用一个最新的服务包等任何事。这样在发生错误时，你就可以查找该登记本中的信息，
来追踪在问题发生前曾有过那些改动。
还有两个重要的原因也使你需要很仔细地为排错准备各方面的文档资料。首先，是为了
在走了弯路后能退回到起点。比如，在解决一个特定的问题时，你试图修复，但没起作用。
虽然这些操作看起来是次要的，但很可能是它们导致服务器陷入一种未知的状态。你可以使
用记录你的工作的文档信息，使服务器返回到启始状态。其次是为了重复利用。如果你解决
了某个问题并把解决的方法记录在案，那么再次碰到这类问题时就很容易了。
24.2.2 弄清情况
正如几乎与其他各种服务器遇到的问题一样，每次第一份问题报告总来自于用户。这既
是一件好事也是一件坏事。好的一面是几乎所有故障一发生你就可以知道，坏的一面是多数
情况下故障被误报或夸大了。这并不意味着你要漠视用户告诉你的一切；相反，你更应该有
保留地听取他们的报告。
比如，以B o b为例。B o b是坚持用分类账本和计算尺来做会计活的那种人。我们都认识像
B o b那样的用户。某个下午， B o b去你办公室告诉你会计服务器瘫痪了，大家无法工作。一个
错误信息说是违反了什么东西。但是，他想最好能清除错误，所以来找你。
当你完全平静下来之后，就可以开始检查一下你所知道的东西。你从B o b的叙述中知道他
遇到了故障，并且他登录进了会计服务器。那么，现在干什么？你该开始进行调查工作了。
当务之急你应该去会计部门获取第一手资料。当你到了会计部门，发现其他人工作都很正常。
当你去B o b的工作间，会发现他正在输入新的卖主，然后要他把在你来之前做的重做一遍。他
拿起一张卖主名单，并打印了所有相关的信息。当他点击了“ O K”按钮之后，就有一条错误
信息出现在屏幕上。这条信息是“ Violation of PRIMARY key Constraints‘P K _ Ve n d o r’：
Attempt to insert duplicate key into object‘Ve n d o r s’.”。哈！现在你找到了错误所在。这条错
误很容易修复，至少你应该知道它是什么。
那么，如果你站在那里的时候，用户无法让错误再现怎么办？你应该告诉用户，在错误
发生时，他们要记下所有相关信息，包括所有有关的数据，然后报告给你。
24.2.3 判定问题
既然你已经知道了用户得到的错误信息，就应该找到背后的问题是什么。在B o b的例子中，
他仅仅是试图多次输入同一个卖主到系统中。有时候，这也许会是个很麻烦的问题。原因是
开发者并不总是把服务器生成的那个错误信息返回给用户，而是仅返回他们自己设计的错误
信息和代码。这样做，他们可能不会告诉用户在SQL Server上发生的一切。
有两种基本的方法来确定用户遇到的确切错误。首先是启动用户的应用程序并尝试重复
错误。虽然这可能不会明确告诉你错误是什么，但能帮助你发现错误所在。除此之外，你还
可以使用SQL Query Analyzer来对数据库执行相同的操作。该操作可以帮助你确定准确的错
误信息。第二种用于确定问题的方法是研究SQL Server错误日志和Windows NT事件浏览器。
几乎所有要求D B A处理的错误信息都被写入错误日志。
24.2.4 试图修复
当你确定了用户遇到的错误，就该着手去进行修复。大多数情况下，解决简单问题的措
2 3 2 SQL Server 7 24学时教程
下载
施可以查看SQL Server Books Online或Microsoft Te c h N e t。如果在这两个地方都找不到解决方
案的话，最好打电话给你主要的技术支持商或微软技术支持部门。特别是和微软打交道，他
们通常都能解决你能遇到的几乎所有问题。
24.3 SQL Server信息资源
当你查找有关SQL Server及其所发生错误的信息时，可以使用多个资源。而在排除任何
SQL Server故障时，你都应该查询它们，看看有没有你用得着的信息。
24.3.1 SQL Server 错误日志
错误日志用来记录启动信息、错误消息以及日常操作中产生的信息消息。该文件是能在
文本编辑器或在SQL Enterprise Manager中浏览的文本文件。该文件的位置由注册表决定，错
误日志的缺省路径是C：\ M S S Q L 7 \ L O G S \ E R R O R L O G。SQL Server每次重新启动时都要新建
一个错误日志。先前的6个错误日志用扩展编号1到6来保存。在排错时，你需要查看错误日志。
最简单的方法是在SQL Enterprise Manager中进行，以下步骤教你在SQL Enterprise Manager中
浏览SQL Server错误日志：
1) 启动SQL Enterprise Manager，然后连接到你想要查看错误日志的服务器上。
2) 点击服务器名称旁边的加号，展开树。
3) 点击“Error Logs”项目旁边的加号，它将展开并列出当前错误日志条目，也就是先前
的六项。
4) 你可以通过点击列表中的名称来选择要浏览的错误日志。当你选中其中一个，该日志
中的内容就会在右边面板上显示出来，如图2 4 - 1所示。
5) 如果内容太长无法在窗口中显示，你可以通过双击一条消息来弹出一个包含全部文本
的对话框，如图2 4 - 2所示。
第2 4学时排错2 3 3
下载
图24-1 选中一个错误日志
后，该日志中的内
容就会在右边面板
上显示出来
24.3.2 Windows NT事件日志
另一个关于SQL Server的有用信息源是Windows NT应用程序日志。它不仅包括有关S Q L
S e r v e r的信息，还包括有关Windows NT服务器及其他运行在服务器上的应用程序的信息。特
别是在有外部事件或事件序列影响SQL Server时，这将非常有用。下面步骤教你浏览Wi n d o w s
N T应用程序日志。
1) 点击“S t a r t”按钮，到“P r o g r a m s”，然后进入“ Administrative To o l s ( C o m m o n )”，并
选择“Event Vi e w e r”。这样就打开了Windows NT Event Vi e w e r，如图2 4 - 3所示。
2) 从“L o g”菜单点击“ A p p l i c a t i o n”。这将改变屏幕上显示的内容为只显示服务器上运
行的应用程序的信息，而不显示服务器自身的信息。
3) 要想了解有关事件的更多信息，双击该事件，这将打开包含事件描述的“ Event Detail”
窗口，如图2 4 - 4所示。
在浏览Windows NT事件日志时，你会发现许多信息，很难分辨出哪些来自SQL Server，
哪些不是。你可以通过过滤事件信息源来仅显示关于SQL Server事件的信息。下面步骤将教
你过滤Windows NT应用程序日志以便仅显示SQL Server的事件。
1) 打开Windows NT Event Vi e w e r，然后按前面的方法查看应用程序日志。
2 3 4 SQL Server 7 24学时教程
下载
图24-2 你可以通过双击一
条消息来弹出一个
包含全部文本的对
话框
图24-3 Windows NT Event
Vi e w e r包含了服务
器上运行的所有应
用程序以及服务器
自身的信息
2) 从“Vi e w”菜单中选择“Filter Events”选项。就会弹出如图2 4 - 5所示的“F i l t e r”对话框。
3) 在“S o u r c e”下拉列表框中，选择“ M S S Q L S e r v e r”。这将会过滤掉所有事件，只保留
来自M S S Q L S e r v e r服务的事件。
4) 在“ C a t e g o r y”框中，你可以进一步过滤事件为不同的类别如B a c k u p、N e t w o r k
L i b r a r i e s以及Server events。
5) 选择完源和类别后，假如你根据类别来选择过滤，就点击“ O K”按钮。应用程序日志
就会被过滤，如图2 4 - 6所示，仅显示出你所选择的事件。
第2 4学时排错2 3 5
下载
图24-4 “Event Detail”窗
口提供给你包含事
件描述的更多信息
图24-5 “F i l t e r”对话框允
许你选择浏览的事
件源
图24-6 过滤了应用程序日
志后，分辨哪些事
件来自于SQL Serv
e r变得更容易了
24.4 SQL Server错误信息
当SQL Server遇到故障，它要么将错误信息写进错误日志或反馈给用户，要么根据严重
性等级同时进行这两项工作。每一个SQL Server错误信息都包括以下内容：
• 信息唯一标识码。
• 错误严重性等级标识码。
• 错误来源标识码。
• 有关错误及其修复建议的信息。
所有的错误信息都存放在m a s t e r数据库的s y s m e s s a g e s表中。要浏览完整的错误信息列表，
运行程序清单2 4 - 1中的查询。
程序清单24-1 运行以下查询你可以得到完整的错误信息列表
24.4.1 严重性等级
每一个SQL Server的错误信息都包括一个严重性等级用于指示SQL Server遇到问题的类型
以及问题有多严重。错误信息可分为两类：致命的和非致命的。
24.4.2 非致命错误
非致命错误严重性等级为0和1 0 ~ 1 8。通常，非致命错误是用户可更正的错误。这些错误
不会导致到SQL Server的连接中断。表2 4 - 1中给出了一些非致命错误的例子。
表24-1 SQL Server非致命错误
严重性等级定义例子
0或1 0 这些信息不是错误信息。它们不要求Msg2528, Level 10, State 1.
用户去更正D B C C执行完毕。如果D B C C打印出错误信
息，去找你的系统管理员
11 - 1 6 这些错误是用户可更正的。通常，这Msg109, Level 15, State 1.
些都是由S Q L语句中出现的语法和逻辑I N S E RT子句中的列数多于VA L U E S子句中所
错误造成的指定值的数目。VA L U E S子句中值的数目必须
匹配列的数目
1 7 指明SQL Server已用尽一些资源。它M s g 1105,Level 17, State 1.
们可能是物理资源，如硬盘空间；也可因为系统日志段已满，无法为p u b s数据库中
能是可配置资源，如锁的S Y S L O G S对象分配空间。如果你用尽了系
统日志的空间，就需要清理事务日志。否则，
要用A LTER DATA B A S E命令或s p e x t e n d s e g -
m e n t过程来增大这个段的空间
1 8 指明一个内部错误导致S Q L无法完成Msg1521, Level 18 State 1.
该语句，但与服务器的连接尚未中断因为t e m p d b数据库中用于处理查询的一个表
遇到一个坏的数据页面数，排序失败。t e m p d b
表应该还未被损坏
2 3 6 SQL Server 7 24学时教程
下载
24.4.3 致命错误
致命错误是指那些严重等级为1 9或更高的错误。当致命错误产生时，用户到SQL Server
的连接中断。更正这些错误通常需要使数据库离线并且由S Q L管理员来处理。表2 4 - 2中给出
了一些致命错误的例子。
表24-2 SQL Server致命错误
严重性等级定义例子
1 9 这些错误表明已达到一个不可更改的Msg422, Level 19, State 1.
内部限制。这样的错误很少发生太多的嵌套表达式或逻辑操作符需要编译。
尝试分解查询或限制A N D和O R
2 0 这些错误表明错误正出现在当前的进Msg405, Level 20, State 1.
程中，数据库可能尚未损坏无法发送查询结果—查询的内部表达故障
2 1 这些错误表明已发生的问题影响到当M s g 6 11, Level 21, State 1.
前数据库的所有进程。数据库可能尚未尝试结束空闲的或更新中的一个事务
损坏
2 2 表明一个表的完整性存在问题，等级Msg904, Level 22, State 1.
的错误很少见在S y s d a t a b a s e s中无法找到m a s t e r数据库行。
无法打开m a s t e r数据库
2 3 表明整个数据库的完整性存在问题， Msg277, Level 23, State 1.
该错误很少见在t e m p d b中进行更新操作的存储过程所启动
的一个事务仍在活动中。这导致t e m p d b的损坏，
并使它残留在服务器上直到重启系统。所有
BEGIN TRAN 和END TRAN 必须有匹配的
C O M M I T和R O L L B A C K
2 4 表明某种介质故障。可能需要重新更Msg902, Level 24, State 1.
换硬件并重新装载数据库读取pubs数据库的逻辑页面24145，虚拟页面
340782时，侦测到硬件错误
2 5 表明某种SQL Server内部的系统错误Msg3508, Level 25, State 1.
因为使用数是2，尝试设置p u b s数据库为单用
户模式失败。确保没有用户正在使用这个数据
库并且重新运行检查点
研究发生的所有致命错误是重要的。这经常涉及到使数据库脱离服务器并进行诊断。一
些致命错误可能产生，然后在诊断中却又不产生了。最好在你首次发现错误的时候就去研究，
不要让它们变得更糟。
24.5 处理损坏的数据库
有时，在你开始进行排错后，会发现你遇到的不是设置上的问题或用户培训的问题，而
是真正的数据库瘫痪。发现这种情况后，下一步你必须考虑如何下手。做决定时，你要考虑
到数据库停止工作的时间、查找故障的时间和修复数据库的时间。有时从一个好的最新备份
中恢复数据库是最佳的选择。记住，即使在SQL Server标记一个数据库为无法存取的情况下，
微软也有办法得到数据。如果这样，你可能需要向微软求助。下面我要讲到的几部分是较高
层次的内容。作为SQL Server的新手，刚开始的时候，你应该考虑给微软技术支持部门或当
地的顾问公司打电话，以便得到帮助使你的数据库尽快恢复工作。
第2 4学时排错2 3 7
下载
24.5.1 修复损坏的用户表
在处理损坏的用户表时，要记住的非常重要的事情是，尽管表里包含了用户收集的全部
信息，但可用两种较容易的方法来修理。
修理坏表的第一步是对当前状态的数据库进行完整备份。该备份应该做上清楚的标记并
放在安全的地方。该备份有两个目的：第一，它是数据库中错误情况的记录。在以后你有空
的时候，它可以用于研究数据库中到底出了什么问题。第二，当你修复的努力失败以后，它
可用于恢复数据库。
第二步是搞清表中的问题出在哪里。如果问题出在表的索引上，删除和重建索引经常可
以解决这个问题。当问题出在表本身时，你将需要删除并重建该表。
删除并重建一个表并不像听起来那么容易。在删除该表之前，你要考虑如何处理表中包
含的数据。根据数据库上次备份的时间和使用频率，你也许可以从备份中恢复信息。不幸的
是该选择不一定每次都行得通。如果数据库使用频率不高，你也许可以通过让用户重新输入
来重建数据。否则，你需要用批拷贝程序( B C P )来处理数据。
在你从坏表中弄出数据后，最后一步是删除和重建该表。完成后，你要将数据装回到该
表中，还应该在数据库上运行D B C C来确保没有别的错误。
24.5.2 修复损坏的系统表
尽管系统表中不包含有用户数据，但损坏了的系统表是最难修复的。系统表中包含有支
持数据库中其他表工作的所有数据。如果系统表瘫痪了，后果简直就是灾难的。
第一步是在它不工作状态下作一个备份。就同损坏的用户表一样，当你开始排错时，需
要这个备份作为数据库所处状态的记录。
下一步，给你主要的支持商或微软技术支持部门打电话。还有许多未列入文档的D B C C命
令和跟踪标志可能会帮助你修复数据库。
接下来，重新恢复一个以前的备份，然后运行D B C C检验它。系统表的损坏往往并不是一
发生就可以明显察觉到的。如果每天使用D B C C的话，你可在问题发生时检测到它。否则，以
前备份也同样出现问题就不足为奇了。
作为最后的恢复，你可能需要用B C P从用户表中导出全部数据。数据导出后，你应该
删除这个数据库及其所在的设备，然后重建这个数据库。数据库重建好后，用B C P导回数
据。
24.6 Database Consistency Checker
Database Consistency Checker(DBCC)本来是用来检查数据库一致性的。随着时间的推移，
微软在D B C C上添加了一些可用于排查SQL Server故障的功能。
在用于分离和修复数据库故障时， D B C C是一个功能最强大工具。除了支持D B C C的命令
外，许多其他功能都未列入文档，微软也不提供帮助。遇到类似问题时，最好慎用并且是在
与你主要的支持商联系之后才能用。在修复一个错误时，某些D B C C命令由于其他潜在的问题
可能导致你的数据库发生更多的错误。
要想获得有关使用D B C C的更多信息，可查询SQL Server Books Online。
2 3 8 SQL Server 7 24学时教程
下载
24.7 使用跟踪标志
在为公开发行SQL Server而进行的编码中，微软采用了默认的功能和错误记录以满足大
多数人的日常需要。但有些时候S Q L管理员需要的不止这些。通过使用跟踪标志，微软提供
了一种方法用于增加更多的功能。诸如D B C C的跟踪标志有很多，许多都未列入文当中。要想
获得有关跟踪标志的更多信息，可查询SQL Server Books Online。
24.8 其他信息源
当你在排查SQL Server的问题时，可以从许多地方获取信息。正常情况下，你应该查看
的第一个地方是SQL Server Books Online。但是，SQL Server Books Online是随SQL Server
同时发布的。这就意味着当你需要信息时，它包含的信息是几个月或几年前的，已经过时了。
另外几处信息来源可用于协助你排错。
24.8.1 微软在线支持
当你在排查SQL Server的问题时，微软在线支持是最好的可以免费利用的资源之一。该
资源经常更新和维护良好。在这个网站上，你能访问到所有最新的补丁程序及使用、维护、
修理技巧。你可以到h t t p : / / w w w.microsoft.com/support 访问这网站。
24.8.2 微软新闻组
另一个重要的信息源是微软的可公开访问的新闻组。可以设置你的新闻阅读器为： m s n e w s .
m i c r o s o f t . c o m。有数百个讨论组可供你通过邮件提问。要记住的是某些回答你提问的人并不总
是知道正确结果。换言之，要有保留地听取他们的意见。
24.8.3 MSDN和TechNet
M S D N和Te c h N e t都是你能得到的有价值的订阅信息。它包括文章、白皮书和基于所有微
软产品的知识。M S D N以季度为单位更新，主要是为开发人员服务的。Te c h N e t是为管理人员
服务的，每月更新。为了得到更多的关于M S D N或Te c h N e t的信息，你可以访问h t t p : / / w w w.
m i c r o s o f t . c o m / m s d n或h t t p : / / w w w. m i c r o s o f t . c o m / t e c h n e t。
24.8.4 微软技术支持
当你已经试过你所知道的每一途径并用尽这些资源时，还有最后一个选择。该选择就是
所谓技术支持。关于给微软技术支持打电话的重要一点是：尽管他们也许不总能知道所有答
案，但他们有一些别人没有的优势—接近开发人员。他们将能够帮助你在SQL Server上使用
许多未公开的修理方法和特性，这些通常是你得不到的。
24.9 课时小结
排错可能是一个你不得不去做的最难处理的事情。排错的好处是你在其中学到的要比在
正常使用过程中多得多。在排错过程中，你要盯住目标，记住别心慌。
第2 4学时排错2 3 9
下载
24.10 专家答疑
问题：当用户数据库不能使用时，我的最好选择是什么？
解答：通常，最好的选择是从最新的备份中恢复数据库。
问题：我有一个损坏了的SQL Server，我公司的经理们想知道什么时候能恢复正常。我
应该告诉他什么？
解答：通常，首先你应保持头脑清醒。应该告诉经理们，你一旦查清了错误并决定如何
修复时就给他们答复。还有一个办法是，将你估计的时间夸大几倍，以免出现意外时没法交
代。
24.11 课外作业
这些思考题和练习题是供你加深理解用的。答案可以在附录“答案”中找到。
24.11.1 思考题
1) 一个用户打电话给你，说他的屏幕上显示一个错误。你应该让他做什么？
2) 一个用户打电话给你，报告她得到了一个严重等级为2 4的错误。该错误意味什么？
3) 你能找到有关SQL Server的信息的两个重要地方在哪儿？
4) 即使在你的服务器出问题之前，你也应该经常做的一件事情是什么？
5) 咨询微软公众新闻组后，在你尝试别人告诉你的方法时，你应牢记什么？
6) 你能得到的最好的免费资源是什么？
7) 当其他努力都失败并且用尽资源时，你应该做什么？
24.11.2 练习题
开始把所有服务器的情况都跟踪记录在案，并仔细查看Windows NT事件日志和S Q L
S e r v e r应用程序日志。在问题发生前逐渐熟悉它们并知道如何使用它们。

附录答案