演示文稿和示范脚本

1、.TNQ 400-13演示文稿和示范脚本SQL Server 7.0 最常见的10个技术支持问题演讲者：Sean Campbell欢迎来参加“SQL Server 7.0 最常见的10个技术支持问题”讲座。我是Sean Campbell，是微软认证系统工程师（MCSE）、微软认证数据库管理员（MCDBA）、微软认证教师（MCT），以及Three Leaf Solutions的讲师和拥有者。下一张幻灯片：参加此次讲座应该预先具备的知识参加本次讲座应该预先具备的知识如下。本次讲座假设你们有过使用Windows NT 4.0和Windows 2000的经验。还要求你们有过安装SQL Server 7

2、.0的经验，以及熟悉和SQL Server相关的数据库管理任务。这是一个难度级别为300的讲座。下一张幻灯片：“最常见的10个 SQL Server 7.0 问题”讲座议程本次讲座所要进行的主题都是直接和SQL Server产品支持问题相关的，这些问题由微软产品支持小组所提供。第一个问题是执行无人值守的安装。这将是我们要进行的第一个示范。在“DTS包的权限”一小节中我们将讨论DTS包的权限以及安全方面的问题。在“复制”这一节，我们将讨论一下FTP复制，以及我们怎样使用FTP来在出版者和订阅者之间复制数据。数据库的收缩和日志的收缩是我们将要进行的另外两个示范。理解它们是如何工作的，以及收缩过程所

3、涉及到的一些因素。接下来是SQL Server 服务故障排除。没有示范来说明这个问题，但我们会详细讨论该主题。再下一个主题是统计更新：AutoStat事件是如何被触发以及我们如何跟踪这个事件。游标的使用是下一个主题，我们将讨论不同的游标类型，它们对服务器性能的不同影响、对TempDB数据库的使用，以及根据游标执行的语句，游标本身进行类型转换的方式。存储过程的重新编译是接下来要讨论的，并且有一个示范。最后一个主题是给服务器改名，也有一个示范。下一张幻灯片：无人值守的安装让我们来开始第一个主题：无人值守的安装。为了执行无人值守的安装，你需要加上K=RC参数来运行安装程序。这将创建一个安装文件，你可

4、以在以后安装时传递给安装程序。这个过程中你可以交互式地选择各种参数，并产生一个ISS文件。然后加上参数-F1 <文件路径>重新运行安装程序，就可以执行无人值守的安装了。下一张幻灯片：安装记录不管是无人值守的安装还是正常安装，安装程序都将产生安装记录，并保存至文件SQLSTP.LOG。这个文件在Windows或者Win NT的目录下，告诉我们安装过程都做了哪些事情。CNFGSRV.OUT文件位于SQL Server的INSTALL目录下面，它报告了由cnfgsvr.exe程序所产生的配置情况。产品支持小组经常被问到的一个问题是，怎样仅仅安装客户端以及SQL Server Profil

5、er？我们不打算在这里演示了，这其实很简单，在安装时仅仅选择Client和Profiler两项即可。下一张幻灯片：无人值守的SQL Server安装接下来我将示范如何执行无人值守的SQL Server安装。现在我切换到示范计算机。这里有一个批处理文件，用来进行无人值守的SQL Server安装。注意，我并不准备执行完全的无人值守安装。看一看我的脚本目录，这里有几个不同的文件。假如我们进行无人值守的安装然后打开这个文件，我们可以看到有一个路径指向SQL Server安装程序所在的目录，在光盘上。我把整个SQL Server 7.0的安装文件已经拷贝到这个目录了，这样会更方便一点。我们将把这个文件

6、中的路径改到这个目录，然后带上K=RC参数运行安装程序。双击这个批处理文件。SQL Server安装程序开始运行。可以看到，带上这个参数后安装程序看起来和普通的安装并没有什么不同。点击Next，然后是初始化画面，在许可证协议画面上点击Yes，输入姓名和公司名称，接下来才是一些真正重要的选项：典型安装、最小化安装还是定制安装。我们选择定制安装。请注意，假如运行无人值守安装时，如果机器上已经安装了SQL Server并且你试图把SQL Server安装到原先SQL Server的数据和程序目录时，你将会得到一个错误信息。如果你确实需要把SQL Server安装到同一个目录下，你可以运行完安装程序以

7、后手工修改安装文件。点击Next，继续安装。在这里我们可以选择完全安装搜索引擎。点击Next，使用缺省的字符集和排序方式，并使用缺省的网络库。关于服务帐号，安装程序会试图验证你所使用的实际服务帐号。假如你在所要安装的计算机上没有服务帐号的权限，你必须在安装程序完成后手工修改安装文件。现在你需要做出一些选择，例如使用本地系统帐号，继续安装，然后添加一些实际参数。我们现在继续安装，为这台计算机选择一个帐号，并设定每个服务都使用同一个帐号。点击Next。然后弹出对话框，此时需要输入更多关于许可证的信息。我们选择每服务器模式，添加100个许可证。然后点击Finish。应该注意到，安装程序结束了，但此时

8、并没有进行实际的安装操作。现在我们到Windows的安装目录，即WinNT目录下面去看一看。我们找到了一个安装文件。这就是SQLSTP文件，它告诉了我们安装过程都发生了哪些事情。这个问题我们刚才提起过。我们可以看到，这个文件里面保存了诸如所使用的域帐号等等之类的信息。现在我们可以打开脚本目录下的setup.iss文件，使用Notepad作为编辑器。在这个文件里我们可以看到诸如Streetmarket、Streetmarket Administrator、我们为登录帐号所做的选择，以及许多其它选择。接下来，为了运行这个文件，我们所需要做的就是创建另外一个批处理文件，或者就使用目前这一个并做少许改

9、动。给安装程序带上-F1参数以及安装文件的路径。如果你希望运行“安静”的安装，你可以加上/s参数。这将使安装程序在安装过程中不弹出任何对话框或提示。返回幻灯片：“最常见的10个 SQL Server 7.0 问题”讲座议程现在我们返回幻灯片看看下一个演示的主题。下一张幻灯片：DTS包的权限接下来我们将讨论有关DTS包权限方面的话题。有一些关于DTS包权限方面的问题可能会让人感到迷惑。主要问题跟理解实际帐号，即DTS包所运行的帐号有关。实际上本节的有关知识也适用于其它SQL Server作业，但DTS包的使用是产品支持小组所遇到的问得最多的问题之一。网络权限也是一个需要注意的问题。下一张幻灯片：

10、DTS包的权限主要问题是作业的拥有者是谁。DTS包所在的那个作业的拥有者是谁？如果是SA或者sysadmin用户，换句话说，DTS包运行在SQL Server Agent的登录帐号下，不论是网络访问还是本地文件访问都不会有什么权限上的问题。如果作业的拥有者不是sysadmin服务器角色的成员，那么它将运行在SQLAgentCmdExec帐号下。缺省的情况下这个帐号在网络上没有访问权限，其它方面的能力也非常有限。我们将特意演示作业运行在sysadmin帐号下和运行在普通设计者帐号下的不同情况。然后我们讨论一下SQLAgentCmdExec帐号在这个过程中所扮演的角色。作业的拥有者缺省为调度DTS

11、包的用户。下一张幻灯片：示范：DTS权限我们现在来看一个示范。我现在切换到示范计算机。启动SQL Server Enterprise Manager，我们的第一个任务是创建一个非常简单的DTS包。因为我们的主要目标是示范包运行所需要的权限，我们没有必要利用数据转换服务（DTS）和SQL Server服务的那些高级功能。在Local Packages图标上按右键，选择New Package，将会出现设计器窗口。我们将创建一个SQL Server连接，并命名为“SQL Server”。我们用SA帐号登录，并进入pubs数据库。这将是我们的第一个连接。我们将把数据存入到硬盘上的一个文本文件中，所以我

12、们指定路径为C:DTSDESdemo.txt。选择缺省的格式。在我们把这两个条目连接起来之前，一个非常重要的步骤是在包属性设置里面指定错误文件的路径。这将能给我们提供包运行时的帐号信息。点击OK，然后把两个条目连接起来。双击该任务。我们将使用缺省的authors表。定义列，转到“传输”标签，点击OK。然后把这个包保存至服务器，命名为DTSdemonstration。然后我们要试图第一次运行这个包。现在这个包成功运行完成了。现在，这个包运行的帐号环境是管理员帐号，或者更确切一点，是我们现在用Enterprise Manager登录到SQL Server的帐号。现在我们要关闭它，看一看我们的注册属

13、性。可以看到我们现在使用的是Windows NT鉴别模式。我们是以管理员身份登录到这台计算机的，这也正是我们用以访问数据库、表、文件以及网络资源的帐号，也就是这个包所运行的帐号环境。这一点很重要。现在我们来看看这个包本身，比如说，我们要调度它，调度对话框弹了出来。为了演示的方便，我们设定这个包每分钟运行一次。点击OK。然后我们到Management文件夹下的Agent文件夹，然后是Jobs文件夹。我们看到这儿有一个DTS示范作业，正是我们刚才所创建的。我们可以查看这个作业的属性，可以看到，它的拥有者是管理员帐号。接下来我们运行这个作业。它可能要花上几秒钟来执行。等它执行完毕。目前显示正在执行作

14、业的步骤。通常需要10秒钟左右来完成这个作业，所以再等一等。查看一下是否有了作业历史。哦，还没有，再等一会儿。好，执行完成了。刷新这个作业。没有运行成功。查看作业历史，系统表明这个作业运行成功了。这儿的关键问题是这个包运行在什么安全环境下。为了说明这一点，我们转到C盘，找到那个叫做DTSdemo.txt的错误文件。这个文件是由刚才的包创建的，我们可以看到我们在两个不同的帐号下运行了那个包，由作业执行的和手工执行的。你们可以看到正是这一点导致了一些困惑。某个开发人员创建了一个包，运行一切正常。然后管理员把它作为一个作业运行，突然发现这个包运行失败了。正是因为SQL Server Agent没有这

15、个包所要访问的资源的权限。另外，如果万一这个作业的拥有者不是管理员，而是一个使用Enterprise Manager来调度作业以及执行其它任务的用户，那么正如我们这儿所看到的，将使用SQLAgentCmdExec帐号来执行这个包。这更给安全问题增加了一层复杂性。没有什么特殊办法来处理这个问题，我们仅仅需要意识到这一点。返回幻灯片：“SQL Server 7.0最常见的10个问题”讲座议程让我们继续。返回幻灯片，看看下一个演示是什么。现在我切换到演示计算机，下一个演讲主题是复制。下一张幻灯片：复制我们将主要讨论通过FTP来进行复制。当复制场景中两台计算机不处在同一个网络中时，通过FTP进行复制是

16、一个可能的解决方案。如果你希望使用FTP进行复制，你需要做以下一些设置：出版物必须被设置为允许订阅者通过FTP下载；订阅者必须选择通过FTP下载并输入FTP服务器的帐号信息。缺省情况是使用匿名登录。另外一个非常重要的步骤是，分发者的FTP站点的跟目录必须指向SQL Server安装目录下Repldata目录下的FTP子目录。在我这台机器上，因为我们目前设置为出版者、分发者和订阅者都在同一台机器上，我们把它指向本地路径。还必须给服务设置权限，例如SQL Server Agent，让它能够访问这些数据。在我们进入下一个主题之前，我先演示一下这个问题。我将切换到示范计算机，看看如何在我的示范计算机上

17、设置FTP复制。打开SQL Server Enterprise Manager。选择Tools菜单下的Replication，弹出了一个窗口。然后选择创建和管理出版物，并一步一步完成这个向导。设置通过FTP进行复制和设置普通的复制并没有太大的差别。但是需要注意一些关键选项，也正是我们的演示要强调的地方。点击Next，第一个问题是，“要使用本台计算机作为分发者吗？”选择Yes，并选择事务复制。这些选择在大多数情况下都是合适的。我们不打算使用“立即更新定购者”这个选项，并且选择所有订阅者都运行SQL Server。我们使用缺省设置来复制employee表，并把这个出版物命名为“Northwind

18、Empolyees”。继续下一步，虽然还有更多选项可以设置，例如数据过滤、是否允许匿名订阅者等，这些选项可能在某些FTP复制场合需要进行设置，但在这里我们并不打算进行设置。点击Finish，完成这个向导。需要等一会儿才能运行完成。这次需要运行的时间稍微长一些，因为这台机器以前并没有设置复制，我们必须设置分发者。好了，运行完毕。现在我们成功设置了一个出版物。接着弹出一个关于复制监视器的提示。现在我们要做的是返回到出版物的属性，因为我们还需要设置它的一个特殊选项。打开出版物的属性对话框，选择properties & subscriptions。转到subscription options。

19、我们看到，这儿有一个选项：“allow snapshots to be downloaded via FTP”，即允许通过FTP下载快照。我们需要选上这个选项，这样的话当订阅者选择拉一个出版物时，他们将会被提示“是否通过FTP下载出版物”。当我们点击OK后，弹出了一个对话框，告诉我们应该把分发者FTP根目录设置成为出版者的工作目录。这一点我们刚才已经提起过了。出版者的工作目录是repledata/ftp。下面是一小段文字告诉我们为什么需要使用FTP，正如我们前面所讨论的，是因为我们可能没有直接访问网络的权限。点击OK，然后点击Close，继续下一步。选择Tools菜单下的replication

20、菜单，选择拉出版物到这台计算机。选择拉一个新的出版物，然后点击Next。现在可以查看可用的出版物，当然是选择我们刚才所创建的“Northwind Empolyees”。 点击Next，提示使用什么帐号信息登录。我们使用标准的SA帐号。我们把出版物放到新的数据库中，命名为FTP1。这将是一个非常简单的数据库，不需要很大，应该能很快就创建好。一两秒钟就可以了。好了，创建完成了。下一步，提示是否在订阅者处初始化模式和数据。我们选择Yes，接下来我们看到了一个选项：是否使用FTP来拷贝快照数据。这一点我们刚才谈起过。因为我们刚才设置了出版物的属性允许通过FTP下载快照，所以才出现了这个选项。选择这个选

21、项，然后点击Next。在这里我们选择不进行调度，仅仅在要求的时候更新出版物。这是为了演示上的方便，让我们能够看到演示中的实际交互。在实际的生产环境中其它选项可能更合适。下一步是一些其它选项，然后我们就完成了出版者和订阅者之间的关系设置。一些安全性上的设置很重要。有可能不能通过匿名访问。我们所要做的是打开这个拉订阅的属性，转到snapshot delivery选项卡片。可以看到，这里我们可以设置分发者的地址、FTP站点位于何处、以及该站点的登录名和口令信息。现在我们要做的是查看我们刚才所设置的作业。转到agent文件夹下的jobs文件夹。按类别排序，我们看到了一些不同类型的作业。首先要做的是设置

22、快照，所以我们先运行这个快照作业以便分发代理能够用来进行复制。跟我们前面做的DTS作业类似，可能需要一段时间才能运行完成，这次大概需要15到20秒。还在运行之中。好，现在显示运行成功了。我们查看一下作业历史，可以看到快照代理已经成功运行了。现在我们要转到分发任务。开始这个作业。跟以前一样，快照代理需要一段时间来运行。作业还在执行中。再等一两秒钟。好，运行成功了。看一看作业历史。正如这儿所看到的，这个作业有一个步骤是连接到FTP站点。我们已经设置为通过FTP进行复制了。复习一下，有两个主要的步骤需要设置。一个是在拉订阅的属性里面设置你的FTP帐号信息。另外一个是，当设置好出版物后，你还需要在运行

23、完向导后设置出版物的属性，以允许订阅者通过FTP下载快照。返回幻灯片：“SQL Server 7.0最常见的10个问题”讲座议程现在我们返回到演示计算机。下一个主题是数据库的收缩。下一张幻灯片：数据库（损坏的页面）下一张幻灯片：数据库（收缩）数据库收缩是另外一个常见的产品支持问题，因为当你运行DBCC shrink database或shrink file时，事情可能没有像你最初期望的那样发生。例如，有可能你运行完shrink database，而实际上数据库并没有收缩，而只是在数据库文件中进行了移动和重新分配空间。也许有的时候确实需要这么做，但现在的问题是，当你运行shrink databa

24、se时，SQL Server所进行的操作对用户是不透明的，而且这确实是一个需要好好掌握的命令，需要让它有效地运行。shrink file的情况和shrink database类似。需要运行shrink file的主要原因是，你可能希望把数据库的大小调整到创建时的大小以下。shrink database命令是不会这么做的。运行shrink file的另外一个目的是为了删除一个给定的文件，你可能需要清空它。当运行shrink file时，empty file可以作为该命令的一个参数，这样就可以把文件组中某一个文件的数据全部移动到另外一个文件中去。下一个示范将主要集中于shrink database

25、。回到我们的示范计算机，我们将在这台计算机上调入一个脚本文件。在SQL Server Query Analyzer中，我们将调入一个名为SHRINK A DATABASE(#4).SQL脚本文件。首先我们要运行这个脚本的第一部分，这将创建一个数据库，在接下来的例子中我们要用到。然后将创建一个相对而言比较大的表，主要是因为列的大小。这个表将有500行。之所以把列的大小设定成一个大的值，是因为我们可以在短时间内创建一个相对而言比较大的数据库，而不用创建太多的表。我们接着进行，运行这部分脚本。注意，这个演示接下来将会使用很多脚本，有的脚本可能需要花20到60秒来执行。我们将把这段时间用于观察脚本的执

26、行上。现在这个脚本执行成功并创建了我们需要的表。我们来看看如果我们不带任何参数运行DBCC SHRINKDATABASE将会有什么结果。我们需要在运行这个命令前和运行后分别观察数据库的大小。最后一点要注意的是，我们需要删除这个大表以便留出空间让数据库能够真正收缩。现在我们选定这一段脚本然后执行它。可以看到数据库原先大小是5.63MB，收缩后减少了1.56MB。不带任何参数运行DBCC SHRINKDATABASE将在数据库中保留25%的剩余空间，而不会收缩数据库中的所有剩余空间回到其原始缺省大小。接下来到这个脚本的第三部分。我们要演示带上百分比参数运行shrink database。因为我们删

27、除了那个大表，我们必须重新创建它并填入数据。跟上部分脚本不同的是，我们要求在数据库中保留剩余空间的50%。同样我们需要在运行脚本以前和以后分别观察数据库的大小。这将需要几秒钟来执行，因为我们必须重新创建这个表。现在执行完毕。我们看到，数据库的原始大小是5.81MB，执行完shrink database命令后数据库收缩的程度没有刚才那样大。这是因为我们指定了参数，让数据库保留更多的剩余空间，我们指定的是保留50%，而刚才是25%。接下来我们将看到执行DBCC SHRINKDATABASE的另一种情况：带上truncate only参数。理解这个参数很重要，因为带上这个参数后运行DBCC SHRI

28、NKDATABASE对运行中的数据库的性能影响最小。这是因为带上truncate only参数后将只收缩最后分配的那部分空间。我们将看到它是如何做到这一点的。首先我们将创建一个叫做“largetable”的表，接着创建“largetable2”和“largetable3”。我们将在不同的时间删除这些表，然后在删除某一个特定的表后运行shrink database命令来观察数据库大小的变化。这一部分脚本中有很多print语句，它可以在运行时输出许多有用的信息，让我们知道脚本正在做什么。在这个脚本中我们所要做的第一件事就是创建第一个表。然后是第二个表。现在正在创建第三个表，当这个表创建完成后过程会

29、变得更快一些。现在完成了。在没有表被删除之前，数据库大小是14.06MB。当我们删除第一个表后，查看数据库的大小，接着运行shrink database命令，可以看到，数据库大小并没有减小多少。你可能会认为数据库的大小应该减小三分之一，但实际上却没有。这是因为我们使用truncate only参数将只收缩最后分配的那部分空间。这意味着它不会在文件中移动数据重新分配空间。接下来我们删除数据库中的第三个表，也就是最后创建的那个表。可以看到这个表被删除后数据库的大小并没有变化。然后带上truncate only参数运行shrink database命令。现在可以看到，数据库的大小减少了很多。现在数据

30、库的第一部分被清空了，最后一部分被收缩了，只剩下第二部分，也就是我们创建的第二个表。但是使用truncate only参数仍然不能把数据库恢复到实际大小。这就是truncate only参数所起的作用。我们还要测试另外一个参数的效果，但在开始之前首先需要运行一小段脚本来清除largetable2。下一段脚本主要讲解DBCC shrink database的最后一个参数：notruncate。Notruncate参数和truncate only参数所起的作用完全不同。它并不实际收缩数据库，运行该命令后数据库的大小并不改变。它所做的是把数据库中的对象尽量移动到数据库文件的前面去，更好地重新分配空间

31、，以便为以后的插入或创建操作留出更连续的空间。现在我们需要重新创建数据库。现在正在重新创建表，删除了原先的数据库然后重新创建三个表。当这些脚本正在运行时，我们来看看下一条将要执行的语句：DBCC extendinfo。这个命令将显示某一个对象所在的页面和扩展页面。注意各个对象之间的相对位置关系。比如，你可以看到largetable2在物理存储位置上在largetable1之后，largetable3则在largetable2之后。以后我们会看到这些相对位置发生了什么变化。现在我们看看执行结果。前一段脚本执行没有错误。现在我们来执行脚本中的5b节，用于演示notruncate参数。我们首先看一下

32、删除以前各个表的相对位置。largetable2存储在largetable1之后，largetable3则在largetable2之后。然后我们看看删除第一个表后会有什么结果。当然数据库的大小不会变。我们带上notruncate参数运行shrink database命令，查看一下数据库文件的大小，确实没有变。我们运行了shrink database命令但实际上并没有收缩数据库。现在重新运行extendinfo命令，可以看到，largetable2的位置基本上没有变，从第六百个页面直到一千多。然而，largetable3原先紧接于largetable2之后，现在却只有一部分位于原来的页面，其它部

33、分则被移动到了数据库文件的前面部分，就是原先largetable1未被删除之前所处的地方。回顾一下我们的操作：首先删除了第一个表，然后带上notruncate参数运行shrink database命令，把第三个表的部分数据移动到了第一个表原先占据的空间。这样就在文件的最后留出了一块连续空间，可以用于以后创建新的对象。现在返回到幻灯片，下面将要涉及到的是日志文件的收缩。返回幻灯片：数据库/日志的收缩现在切换回演示计算机，我们来讨论一下日志文件收缩的有关话题。关于日志收缩的一些问题不像有些DBC shrink database命令那样复杂。然而还是在产品支持中有一些关于日志收缩的问题。应该注意的是

34、，如果数据库从来没有备份过，那么日志文件将不会增长。问题在于，如果数据库从来没有备份，日志将被设置为自动截断模式。这一点不像“在检查点处截断日志”选项那样明显，所以我们需要花一些时间来看看这意味着什么。另外，日志可能不会在你所要求的精确时间点进行收缩。你所需要做的是，标出可用空间，然后备份日志，有时可能还需要往数据库中插入一些记录以移除当前使用的虚拟日志文件，然后日志就可以在必要的时候进行收缩了。我们的下一个示范就是日志收缩。现在我们切换到示范计算机。现在我们打开一个脚本文件，它将帮助我们理解一些日志收缩方面的问题。我们将运行这个脚本文件的前两节，然后当运行完成后再观察一下输出结果。现在这段脚

35、本所做的是，如果已经存在一个叫做shrink2数据库的话，删除它。然后创建一个新的数据库，接着创建表。也将是一个相对比较大的表，和我们上次演示所用的表类似。然后在往表中插入1000行数据后，检查一下日志文件。接下来备份数据库，看看这个操作是如何影响和改变数据库日志大小的。现在我们可以看到，尽管我们刚刚向数据库中插入了1000行数据，shrink2数据库的日志空间只有56%被实际使用，小于1MB。接着我们备份数据库，使数据库不再处于自动截断状态，并装载更多的数据。现在看看日志的增长：日志已经增长到接近9MB，日志空间的使用率达到96%。显然日志的使用方式已经发生了很大的变化。然后返回，重新备份和

36、恢复数据库。检查shrink2数据库，发现日志文件使用率下降了。当然日志的大小不会被收缩，但是它的使用率降到了25%。接下来要讨论的是怎样真正收缩数据库日志的物理大小。我们所要做的是返回并运行DBCC shrink database命令，再检查一下日志的大小。然后备份日志，我们发现日志仍然没有收缩。问题出来了。这可能不是你所期望的结果。看看shrink2数据库，仍然显示日志有8.9MB。我们已经明确要求了收缩日志，并且我们已经备份过了。操作过程似乎没有问题。问题的关键在于，日志的活动部分仍然在物理文件的尾部。我们需要做的是，向数据库中插入足够的行，以把日志的活动部分从物理文件的尾部移走。然后再

37、运行收缩命令。我们向数据库中插入30行。让我对这个脚本做一些小的纠正然后再运行。现在看看shrink2数据库，它的日志已经被收缩到了2.49MB。这就是因为我们已经把日志的活动部分和活动的虚拟日志文件从文件尾部移到了前部。现在shrink database命令就可以正常工作、真正收缩日志文件了。现在我们回到幻灯片，看看演示的下一个主题。返回幻灯片：小测验返回到幻灯片后，我们来做几个小测验。如果作业的拥有者不是sysadmin的成员，也不是SA，DTS包运行在什么权限下？分配给 SQLAgentCmdExec帐号的权限。登录到FTP服务器时，在哪里输入帐号信息： (出版者|分发者|订阅者) ？在

38、订阅者处。把数据从一个指定的文件移出使用什么命令？DBCC Shrinkfile with EMPTYFILE。哪个命令对正在运行的数据库影响最小， notruncate还是truncateonly?Truncate only，因为它只收缩最后分配给数据库的空间，并且它不会移动数据。下一张幻灯片：“SQL Server 7.0最常见的10个问题”讲座议程下一张幻灯片：SQL Server服务故障排除下一个主题是SQL Server服务故障排除。这个主题没有相应的示范，我们只是简单提一下应该注意的问题。对于Microsoft SQL Server和SQL Server Agent服务，你需要验证

39、分配给这些服务的帐号是以服务权限登录的。如果该帐号不属于管理员组，他们必须具有如下的权限：对SQL Server目录的完全控制权限；对数据库文件的完全控制权限；正如我们刚才所提到的，必须以服务权限登录；对和MS SQL Server服务相关的注册键的完全控制权限；对注册表中和SQL Server相关的software和services等目录树的权限；对performance library键的完全控制权限。总而言之，把分配给这些服务的帐号加入到管理员组的话会更方便一点，但如果一定要把这些帐号排除在管理员组之外，也可以进行以上的设置使之可以正常运行。下一张幻灯片：SQL Server服务故障排除

40、另外需要注意的问题是关于Microsoft分布式事务协调器（MSDTC）服务的。只需要在控制面板的“服务”中输入口令即可。那里才是输入口令的正确地方。而对于MS Search服务，你就不能在控制面板的“服务”中输入口令了。它是从MS SQL Server服务那里获取帐号和口令的信息。因此改变了MS SQL Server服务的帐号信息也就改变了MS Search的帐号信息。单独改变MS Search是不会起作用的。下一张幻灯片：“SQL Server 7.0最常见的10个问题”讲座议程我们下一个主题是统计更新。关于这个主题我们有一些示范，不过在开始之前我们先看一看幻灯片。下一张幻灯片：理解自动统

41、计更新自动统计更新是SQL Server 7.0的一个非常有用的特性。统计信息由系统自动更新。关于这个话题常见的问题是，它是如何工作的？我怎样跟踪它？它对系统性能的影响？等等。我们接下来会谈到如何捕获自动统计更新事件。有一篇Q系列文章，Q195565，详细解释了这一点。它的基本法则如下：在一个有1000行以上的表中，如果有500行加上总行数的20%被改变，则更新统计值。下一张幻灯片：理解自动统计更新其它值得注意的关于自动统计更新的问题还有，如果表的基数小于6，每500个修改操作的更新次数不到500。Profiler可以捕获Auto-Update-Stats事件，这也正是我们下面将要用到的。为了

42、在错误日志中保存统计更新事件，可以打开跟踪标志8721，你就可以看到该事件开始的行数，更新过程所涉及的总行数，以及处理所花费的时间。这些参数被列为“Mods”、“Bound”、“Duration”。这将是我们示范的内容之一。现在我来进行示范，切换到示范计算机。为了示范关于自动统计更新的一些问题，我们需要打开一个脚本文件。我们现在所看到脚本，叫做AutoStat setup，它将创建一个大约有10,000行的表。首先我们运行这段脚本，然后我们在这个表上创建了索引。这需要几秒钟的时间来运行。让这段脚本先运行，我们去设置一下SQL Server Profiler，以便可以有效使用它来进行示范。我们来

43、使用向导让Profiler对SQL Server Query Analyzer进行跟踪。停止跟踪，再做另外一个改动。需要确保我们显示了所有的事件类和所有的数据列。完成后我们再加入一个叫做auto-updates stats的事件，这个事件将显示统计信息的实际更新。返回SQL Server Query Analyzer，我们来看一看sysindexes表中一个叫做“Row My Counter”的列。这个列将显示SQL Server认为表中实际改变了的行数，它们最终将成为统计更新的一部分。然后我们将向表中插入4000行，再次检查那个数值并返回脚本。我们来运行这段脚本。系统显示，sysindex表

44、中当前被改变的行数是0。这是正常的，因为当我们最初向表中插入10,000行时，SQL Server已经进行了自动统计更新。现在当插入4000行后，我们看到sysindex表中的当前被修改行数是大约4000。我们返回脚本，运行一个查询，然后再看看sysindex中这个数值的变化。查询运行完毕，我们看到了，sysindex表中的当前被修改行数是0。应该注意的是，自动统计更新事件直到我们运行查询才发生。所以那个查询将在某种程度上影响更新事件的性能。现在回到Profiler，我们看到，auto-update stats事件已经发生了。问题是这儿只显示了时间已经发生以及事件的持续时间，缺乏更详细的信息。

45、所以我们现在运行这段脚本，叫做“Gathering Better Information”。这将要用到两个DBCC命令。第一个命令将新建一个错误日志文件，然后打开一个跟踪标志以便让AutoStats事件的输出都写入到那个日志文件中。我们将插入6000行，并像刚才那样查看当前被修改的行数。我们来运行脚本的第一部分，即插入6000行。这需要10秒到20秒的时间。现在我们看到，当前被修改行数是大约6000。接下来我们开始一个查询，然后再次检查当前被修改行数。这个查询需要一段时间来运行，因为它将检索出C2列的所有数据。查询完成，我们看到当前被修改行数是0。切换到Profiler，auto-update

46、 stats事件已经发生，我们看到了和刚才类似的信息。现在我们到SQL Server Enterprise Manager中检查一下SQL Server日志。在当前日志中，我们看到了一个自动统计更新符号。在这儿可以看到关于自动统计更新时间的一些更详细的信息。但是注意，如果在生产环境中打开这个跟踪标记的话，可能会在错误日志中产生非常多的记录，所以要小心使用。回到幻灯片：“SQL Server 7.0最常见的10个问题”讲座议程现在我们切换到幻灯片。下一个主题是游标的使用。下一张幻灯片：什么是游标产品支持小组碰到了非常多的关于游标的问题。许多问题是关于如何正确使用的。这个问题有时可以归结为游标的特

47、定类型、什么时候被使用，以及诸如此类的问题。我们首先非常简要地谈一下什么是游标，然后我们再进入相关主题。一个游标指向某一个特定的行，根据游标的当前位置获取或修改当前行。游标的数据对底层数据敏感，能够反映底层数据的变化。这些变化可以是由其它连接作出的。下一张幻灯片：Transact-SQL 游标的语法Transact-SQL游标的语法有5个关键字：Declare cursor、Open、Fetch、Close和Deallocate。我们不会详细讲述这些关键字的含义，但在以后的脚本中我们需要大量使用这些关键字来声明、打开以及关闭游标。下一张幻灯片：Transact-SQL游标是如何工作的我们用下面

48、的例子来示范游标是如何工作的。这个游标将从sysobjects表中取出各行。我们看到，只要游标的读取数据标志等于0，就说明还有可用的数据，那么游标就继续读取数据并把读到的数据放入一个变量。这样每个用户表的表名就都被放入了表名变量中。然后我们看到了结果：各个表的表名都被列了出来。下一张幻灯片：隐式游标转换下面我们将谈论一些关于游标类型转换方面的问题。我们将讨论不同的游标类型，以及不同游标类型的特点，例如static型游标在tempdb数据库中需要占用非常大的空间，而Keyset型则不需要占用如此多的空间。理解各种类型之间的转换非常重要。因为当你选择不同的游标类型时，它们在tempdb数据库中所占

49、的空间相差可能会特别大。例如，假如一个游标使用top子句引用了某个视图，它马上就变成了static型。如果一个查询包含有distinct、group by之类的参数，也将立即转换成static型。如果一个查询引用了一个带有触发器的表，同样将变成静态型。而如果一个查询因为使用了order-by子句产生了内部的工作表，或者引用了远程服务器或链接服务器上的表，将产生一个keyset型的游标。有以下几种主要的不同游标类型：dynamic、forward、static和keyset。Dynamic和forward有一些不同，但从空间利用的角度来说，它们和static类似。Static型游标需要占用tem

50、pdb数据库中的大量空间，是因为实际上它包含了整个行。我们一会儿将在脚本中解释这一点。而keyset型游标则只包含了组成某一个特定游标的一些键。在实施中Dynamic和forward only型游标的主要区别在于，dynamic型游标能够反映基础数据的更多改动。我们也将在脚本中解释这一点。下一张幻灯片：游标的选择我们来谈一下游标的选择。选择游标的类型依赖于以下几个我们将要谈到的因素。首先是结果集的大小。我已经提到过不止一次，不同的游标类型需要向tempdb数据库中写入不同的信息。正因为如此，需要的空间以及写入信息所需要的时间就是必须要考虑的因素了。其次是返回的结果集中有可能真正用到的数据。考虑

51、你是否需要反映基础数据的变化。还有打开游标的性能，例如static和keyset之间的差别。这主要依赖于游标试图去取得的数据量的大小。还有对于其它游标操作的考虑，例如滚动和定点更新。这是因为不同的游标类型支持不同的选项。我们现在切换到示范计算机。我们将运行一些脚本，这将帮助我们理解以上要点。我们需要打开两个脚本。第一个是游标成员，我们先运行这段脚本的一部分，用来设置一个数据库并向其中插入一些行。我们先看看forward类型的游标。我们打开一个游标，然后向数据库中插入几个新行，接着用print语句查看我们从数据库中所取得的数据，看新插入的行是否可以被检索到。运行这段脚本。首先是声明游标并取得第一

52、行。当游标已经打开后，向表中插入一个新行。然后继续运行，取得下面的三行。我们看到，新插入的行被检索出来了。如果我们更新了一个主键列，然后使用fetch命令取出这一列，是可以看到刚才所作的修改的。这就是forward-only型游标。然而，如果你更新的不是主键列，而且你对非主键列的修改是你对该行的唯一改动，你将看不到你对非主键列的更新。这是关于forward-only型游标需要注意的一点。现在我们来看另外一种类型的游标，即static-oly型。这一段设置脚本和刚才我们所看到的是类似的。我们来运行它。这将执行一个static型游标。我们重新创建一个有3行数据的表，和刚才我们所创建的一样。我们用f

53、etch命令，取得表中的第一行数据。然后向表中插入一行新的数据。然后同刚才一样，继续运行，取得下面的三行。我们看到，没有取出新插入的行。Static型游标不能反映数据库基础数据的变化。下面要讨论的是keyset游标。同样，我们创建一个keyset型游标，重新创建表，用fetch命令取得表中的第一行。然后向表中插入新的记录，再用fetch命令取出新插入的那条记录，看看发生了什么。我们注意到，没有取出来。但是，如果我们更新的是我们已经取出过的行，即第1、2、3行，然后把游标位置返回第一行来重新取出刚才被修改过的行，情况就不一样了。把C2列的值由5修改成3，现在用fetch命令重新取出这一行，我们确

54、实可以看到刚才我们所作的修改了。如果我们从游标中删除一行，比如这儿我们删除C1=3的那一行，然后试图去取出那一行的话，我们可以看到这一行已经被删除，或者说被清空为零值。所以，通过keyset型游标，可以反映出对游标在键集中那一部分的更新和删除操作。最后我们要讨论的是dynamic型游标。我们重新创建那个表，声明游标，取出第一行，然后向表中插入一行。然后试图去取出刚才插入的那一行，没有问题，可以成功取出。如果像刚才在keyset型游标中讨论的那样，我们更新基础表的数据，然后返回游标，也可以看到我们刚才所作的更新。如果我们删除一行然后试图用游标去取出这一行的话，我们可以看到它已经确实不存在了，而不

55、是显示为空或者零。因为这里我们删除了第三行，游标将直接返回第四行的数据。现在我们将打开另外一个脚本，用来演示游标类型对tempdb数据库以及空间分配上的影响。打开这个脚本文件，第一部分已经运行了，创建了一个10,000行的表。脚本的下一部分演示了在使用keyset型游标的情况下tempdb数据库的大小。我们将打开一个游标，并在游标打开前和打开后分别观察tempdb数据库中扩展页的分配情况。运行，系统显示在打开游标前tempdb数据库中使用的扩展页是29。等待游标初始化完成，我们看到游标打开后使用的扩展页增加到了34。这个增加量并不算大。如果我们打开的是一个static型游标，tempdb数据库

56、中空间使用就会完全不一样了。现在我们来打开一个static型游标，打开前使用的扩展页是28。等待游标初始化完成。这比刚才初始化keyset型游标所花的时间要长一些，因为现在是在初始化整个行，而不是像刚才那样只初始化键集。现在我们看看使用的扩展页，这个数值跳到了1163，和刚才使用keyset型游标相比差别非常大。现在应该对static型游标在tempdb数据库中所需要的空间有一个初步概念了吧，使用static型游标的时候应该注意这一点。如果我们打开dynamic型游标观察它使用空间的情况的话，它所需要的空间是最少的。因为dynamic型游标不会像keyset型游标那样去初始化键集，也不会像st

57、atic型游标那样初始化整个行。然而，dynamic型游标需要跟踪其它连接以检测数据是否被修改，所以需要额外的开销。正如我们前面所看到的，dynamic型游标能够反映基础数据的变化。最后我们来讨论一些关于游标类型转换方面的问题。创建另外一个数据库，并在其中创建一个非常简单的表。然后我们打开游标，然后使用存储过程sp_show_cursor_details来显示游标的有关信息。现在我们打开一个dynamic型游标，察看一下这个游标的状态。状态值是3，表示现在是一个dynamic型游标。现在我们设置游标，带上top子句引用一个视图。注意我们试图打开一个dynamic型游标。我们运行这个游标，然后我

58、们注意到状态值变成了1，表示已经从dynamic型游标转换成static型游标了。从刚才不同游标类型所需要的空间来看，static型游标所需要的空间非常大。因此在这种情况下dynamic型游标会自动转换成static型，这是应该注意的一点。现在我们看一看select语句中带有distinct子句的游标。同样试图以dynamic型打开，我们注意到它又自动转换成了static型。如果你没有注意到这样的类型转换，可能会给你的应用程序带来性能上的问题。另外，我们来看看会产生内部工作表的查询会是什么情况。同样以dynamic型游标打开，运行它。正如我们所看到的，状态值变成了2，意味着已经转换成keyset型游标了。这是因为使用了内部工作表，这个查询有order-by参数，按C2列的值进行了排序。返回幻灯片：“SQL Server 7.0最常见的10个问题”讲座议程关于游标的使用就到这儿。我们现在返回到幻灯片，下一个主题是关于存储过程的重新编译。下一张幻灯片：存