演示文稿和示范脚本.docx
《演示文稿和示范脚本.docx》由会员分享，可在线阅读，更多相关《演示文稿和示范脚本.docx（17页珍藏版）》请在冰豆网上搜索。
演示文稿和示范脚本
TNQ400-13演示文稿和示范脚本
SQLServer™7.0最常见的10个技术支持问题
演讲者：
SeanCampbell
欢迎来参加“SQLServer™7.0最常见的10个技术支持问题”讲座。
我是SeanCampbell，是微软认证系统工程师（MCSE）、微软认证数据库管理员（MCDBA）、微软认证教师（MCT），以及ThreeLeafSolutions的讲师和拥有者。
[下一张幻灯片：
参加此次讲座应该预先具备的知识]
参加本次讲座应该预先具备的知识如下。
本次讲座假设你们有过使用WindowsNT4.0和Windows2000的经验。
还要求你们有过安装SQLServer7.0的经验，以及熟悉和SQLServer相关的数据库管理任务。
这是一个难度级别为300的讲座。
[下一张幻灯片：
“最常见的10个SQLServer7.0问题”讲座议程]
本次讲座所要进行的主题都是直接和SQLServer产品支持问题相关的，这些问题由微软产品支持小组所提供。
第一个问题是执行无人值守的安装。
这将是我们要进行的第一个示范。
在“DTS包的权限”一小节中我们将讨论DTS包的权限以及安全方面的问题。
在“复制”这一节，我们将讨论一下FTP复制，以及我们怎样使用FTP来在出版者和订阅者之间复制数据。
数据库的收缩和日志的收缩是我们将要进行的另外两个示范。
理解它们是如何工作的，以及收缩过程所涉及到的一些因素。
接下来是SQLServer服务故障排除。
没有示范来说明这个问题，但我们会详细讨论该主题。
再下一个主题是统计更新：
AutoStat事件是如何被触发以及我们如何跟踪这个事件。
游标的使用是下一个主题，我们将讨论不同的游标类型，它们对服务器性能的不同影响、对TempDB数据库的使用，以及根据游标执行的语句，游标本身进行类型转换的方式。
存储过程的重新编译是接下来要讨论的，并且有一个示范。
最后一个主题是给服务器改名，也有一个示范。
[下一张幻灯片：
无人值守的安装]
让我们来开始第一个主题：
无人值守的安装。
为了执行无人值守的安装，你需要加上K=RC参数来运行安装程序。
这将创建一个安装文件，你可以在以后安装时传递给安装程序。
这个过程中你可以交互式地选择各种参数，并产生一个ISS文件。
然后加上参数-F1<文件路径>重新运行安装程序，就可以执行无人值守的安装了。
[下一张幻灯片：
安装记录]
不管是无人值守的安装还是正常安装，安装程序都将产生安装记录，并保存至文件SQLSTP.LOG。
这个文件在Windows或者WinNT的目录下，告诉我们安装过程都做了哪些事情。
CNFGSRV.OUT文件位于SQLServer的INSTALL目录下面，它报告了由cnfgsvr.exe程序所产生的配置情况。
产品支持小组经常被问到的一个问题是，怎样仅仅安装客户端以及SQLServerProfiler？
我们不打算在这里演示了，这其实很简单，在安装时仅仅选择Client和Profiler两项即可。
[下一张幻灯片：
无人值守的SQLServer安装]
接下来我将示范如何执行无人值守的SQLServer安装。
现在我切换到示范计算机。
这里有一个批处理文件，用来进行无人值守的SQLServer安装。
注意，我并不准备执行完全的无人值守安装。
看一看我的脚本目录，这里有几个不同的文件。
假如我们进行无人值守的安装然后打开这个文件，我们可以看到有一个路径指向SQLServer安装程序所在的目录，在光盘上。
我把整个SQLServer7.0的安装文件已经拷贝到这个目录了，这样会更方便一点。
我们将把这个文件中的路径改到这个目录，然后带上K=RC参数运行安装程序。
双击这个批处理文件。
SQLServer安装程序开始运行。
可以看到，带上这个参数后安装程序看起来和普通的安装并没有什么不同。
点击Next，然后是初始化画面，在许可证协议画面上点击Yes，输入姓名和公司名称，接下来才是一些真正重要的选项：
典型安装、最小化安装还是定制安装。
我们选择定制安装。
请注意，假如运行无人值守安装时，如果机器上已经安装了SQLServer并且你试图把SQLServer安装到原先SQLServer的数据和程序目录时，你将会得到一个错误信息。
如果你确实需要把SQLServer安装到同一个目录下，你可以运行完安装程序以后手工修改安装文件。
点击Next，继续安装。
在这里我们可以选择完全安装搜索引擎。
点击Next，使用缺省的字符集和排序方式，并使用缺省的网络库。
关于服务帐号，安装程序会试图验证你所使用的实际服务帐号。
假如你在所要安装的计算机上没有服务帐号的权限，你必须在安装程序完成后手工修改安装文件。
现在你需要做出一些选择，例如使用本地系统帐号，继续安装，然后添加一些实际参数。
我们现在继续安装，为这台计算机选择一个帐号，并设定每个服务都使用同一个帐号。
点击Next。
然后弹出对话框，此时需要输入更多关于许可证的信息。
我们选择每服务器模式，添加100个许可证。
然后点击Finish。
应该注意到，安装程序结束了，但此时并没有进行实际的安装操作。
现在我们到Windows的安装目录，即WinNT目录下面去看一看。
我们找到了一个安装文件。
这就是SQLSTP文件，它告诉了我们安装过程都发生了哪些事情。
这个问题我们刚才提起过。
我们可以看到，这个文件里面保存了诸如所使用的域帐号等等之类的信息。
现在我们可以打开脚本目录下的setup.iss文件，使用Notepad作为编辑器。
在这个文件里我们可以看到诸如Streetmarket、StreetmarketAdministrator、我们为登录帐号所做的选择，以及许多其它选择。
接下来，为了运行这个文件，我们所需要做的就是创建另外一个批处理文件，或者就使用目前这一个并做少许改动。
给安装程序带上-F1参数以及安装文件的路径。
如果你希望运行“安静”的安装，你可以加上/s参数。
这将使安装程序在安装过程中不弹出任何对话框或提示。
[返回幻灯片：
“最常见的10个SQLServer7.0问题”讲座议程]
现在我们返回幻灯片看看下一个演示的主题。
[下一张幻灯片：
DTS包的权限]
接下来我们将讨论有关DTS包权限方面的话题。
有一些关于DTS包权限方面的问题可能会让人感到迷惑。
主要问题跟理解实际帐号，即DTS包所运行的帐号有关。
实际上本节的有关知识也适用于其它SQLServer作业，但DTS包的使用是产品支持小组所遇到的问得最多的问题之一。
网络权限也是一个需要注意的问题。
[下一张幻灯片：
DTS包的权限]
主要问题是作业的拥有者是谁。
DTS包所在的那个作业的拥有者是谁？
如果是SA或者sysadmin用户，换句话说，DTS包运行在SQLServerAgent的登录帐号下，不论是网络访问还是本地文件访问都不会有什么权限上的问题。
如果作业的拥有者不是sysadmin服务器角色的成员，那么它将运行在SQLAgentCmdExec帐号下。
缺省的情况下这个帐号在网络上没有访问权限，其它方面的能力也非常有限。
我们将特意演示作业运行在sysadmin帐号下和运行在普通设计者帐号下的不同情况。
然后我们讨论一下SQLAgentCmdExec帐号在这个过程中所扮演的角色。
作业的拥有者缺省为调度DTS包的用户。
[下一张幻灯片：
示范：
DTS权限]
我们现在来看一个示范。
我现在切换到示范计算机。
启动SQLServerEnterpriseManager，我们的第一个任务是创建一个非常简单的DTS包。
因为我们的主要目标是示范包运行所需要的权限，我们没有必要利用数据转换服务（DTS）和SQLServer服务的那些高级功能。
在LocalPackages图标上按右键，选择NewPackage，将会出现设计器窗口。
我们将创建一个SQLServer连接，并命名为“SQLServer”。
我们用SA帐号登录，并进入pubs数据库。
这将是我们的第一个连接。
我们将把数据存入到硬盘上的一个文本文件中，所以我们指定路径为C:
\DTS\DESdemo.txt。
选择缺省的格式。
在我们把这两个条目连接起来之前，一个非常重要的步骤是在包属性设置里面指定错误文件的路径。
这将能给我们提供包运行时的帐号信息。
点击OK，然后把两个条目连接起来。
双击该任务。
我们将使用缺省的authors表。
定义列，转到“传输”标签，点击OK。
然后把这个包保存至服务器，命名为DTSdemonstration。
然后我们要试图第一次运行这个包。
现在这个包成功运行完成了。
现在，这个包运行的帐号环境是管理员帐号，或者更确切一点，是我们现在用EnterpriseManager登录到SQLServer的帐号。
现在我们要关闭它，看一看我们的注册属性。
可以看到我们现在使用的是WindowsNT鉴别模式。
我们是以管理员身份登录到这台计算机的，这也正是我们用以访问数据库、表、文件以及网络资源的帐号，也就是这个包所运行的帐号环境。
这一点很重要。
现在我们来看看这个包本身，比如说，我们要调度它，调度对话框弹了出来。
为了演示的方便，我们设定这个包每分钟运行一次。
点击OK。
然后我们到Management文件夹下的Agent文件夹，然后是Jobs文件夹。
我们看到这儿有一个DTS示范作业，正是我们刚才所创建的。
我们可以查看这个作业的属性，可以看到，它的拥有者是管理员帐号。
接下来我们运行这个作业。
它可能要花上几秒钟来执行。
等它执行完毕。
目前显示正在执行作业的步骤。
通常需要10秒钟左右来完成这个作业，所以再等一等。
查看一下是否有了作业历史。
哦，还没有，再等一会儿。
好，执行完成了。
刷新这个作业。
没有运行成功。
查看作业历史，系统表明这个作业运行成功了。
这儿的关键问题是这个包运行在什么安全环境下。
为了说明这一点，我们转到C盘，找到那个叫做DTSdemo.txt的错误文件。
这个文件是由刚才的包创建的，我们可以看到我们在两个不同的帐号下运行了那个包，由作业执行的和手工执行的。
你们可以看到正是这一点导致了一些困惑。
某个开发人员创建了一个包，运行一切正常。
然后管理员把它作为一个作业运行，突然发现这个包运行失败了。
正是因为SQLServerAgent没有这个包所要访问的资源的权限。
另外，如果万一这个作业的拥有者不是管理员，而是一个使用EnterpriseManager来调度作业以及执行其它任务的用户，那么正如我们这儿所看到的，将使用SQLAgentCmdExec帐号来执行这个包。
这更给安全问题增加了一层复杂性。
没有什么特殊办法来处理这个问题，我们仅仅需要意识到这一点。
[返回幻灯片：
“SQLServer7.0最常见的10个问题”讲座议程]
让我们继续。
返回幻灯片，看看下一个演示是什么。
现在我切换到演示计算机，下一个演讲主题是复制。
[下一张幻灯片：
复制]
我们将主要讨论通过FTP来进行复制。
当复制场景中两台计算机不处在同一个网络中时，通过FTP进行复制是一个可能的解决方案。
如果你希望使用FTP进行复制，你需要做以下一些设置：
出版物必须被设置为允许订阅者通过FTP下载；订阅者必须选择通过FTP下载并输入FTP服务器的帐号信息。
缺省情况是使用匿名登录。
另外一个非常重要的步骤是，分发者的FTP站点的跟目录必须指向SQLServer安装目录下Repldata目录下的FTP子目录。
在我这台机器上，因为我们目前设置为出版者、分发者和订阅者都在同一台机器上，我们把它指向本地路径。
还必须给服务设置权限，例如SQLServerAgent，让它能够访问这些数据。
在我们进入下一个主题之前，我先演示一下这个问题。
我将切换到示范计算机，看看如何在我的示范计算机上设置FTP复制。
打开SQLServerEnterpriseManager。
选择Tools菜单下的Replication，弹出了一个窗口。
然后选择创建和管理出版物，并一步一步完成这个向导。
设置通过FTP进行复制和设置普通的复制并没有太大的差别。
但是需要注意一些关键选项，也正是我们的演示要强调的地方。
点击Next，第一个问题是，“要使用本台计算机作为分发者吗？
”选择Yes，并选择事务复制。
这些选择在大多数情况下都是合适的。
我们不打算使用“立即更新定购者”这个选项，并且选择所有订阅者都运行SQLServer。
我们使用缺省设置来复制employee表，并把这个出版物命名为“NorthwindEmpolyees”。
继续下一步，虽然还有更多选项可以设置，例如数据过滤、是否允许匿名订阅者等，这些选项可能在某些FTP复制场合需要进行设置，但在这里我们并不打算进行设置。
点击Finish，完成这个向导。
需要等一会儿才能运行完成。
这次需要运行的时间稍微长一些，因为这台机器以前并没有设置复制，我们必须设置分发者。
好了，运行完毕。
现在我们成功设置了一个出版物。
接着弹出一个关于复制监视器的提示。
现在我们要做的是返回到出版物的属性，因为我们还需要设置它的一个特殊选项。
打开出版物的属性对话框，选择properties&subscriptions。
转到subscriptionoptions。
我们看到，这儿有一个选项：
“allowsnapshotstobedownloadedviaFTP”，即允许通过FTP下载快照。
我们需要选上这个选项，这样的话当订阅者选择拉一个出版物时，他们将会被提示“是否通过FTP下载出版物”。
当我们点击OK后，弹出了一个对话框，告诉我们应该把分发者FTP根目录设置成为出版者的工作目录。
这一点我们刚才已经提起过了。
出版者的工作目录是repledata/ftp。
下面是一小段文字告诉我们为什么需要使用FTP，正如我们前面所讨论的，是因为我们可能没有直接访问网络的权限。
点击OK，然后点击Close，继续下一步。
选择Tools菜单下的replication菜单，选择拉出版物到这台计算机。
选择拉一个新的出版物，然后点击Next。
现在可以查看可用的出版物，当然是选择我们刚才所创建的“NorthwindEmpolyees”。
点击Next，提示使用什么帐号信息登录。
我们使用标准的SA帐号。
我们把出版物放到新的数据库中，命名为FTP1。
这将是一个非常简单的数据库，不需要很大，应该能很快就创建好。
一两秒钟就可以了。
好了，创建完成了。
下一步，提示是否在订阅者处初始化模式和数据。
我们选择Yes，接下来我们看到了一个选项：
是否使用FTP来拷贝快照数据。
这一点我们刚才谈起过。
因为我们刚才设置了出版物的属性允许通过FTP下载快照，所以才出现了这个选项。
选择这个选项，然后点击Next。
在这里我们选择不进行调度，仅仅在要求的时候更新出版物。
这是为了演示上的方便，让我们能够看到演示中的实际交互。
在实际的生产环境中其它选项可能更合适。
下一步是一些其它选项，然后我们就完成了出版者和订阅者之间的关系设置。
一些安全性上的设置很重要。
有可能不能通过匿名访问。
我们所要做的是打开这个拉订阅的属性，转到snapshotdelivery选项卡片。
可以看到，这里我们可以设置分发者的地址、FTP站点位于何处、以及该站点的登录名和口令信息。
现在我们要做的是查看我们刚才所设置的作业。
转到agent文件夹下的jobs文件夹。
按类别排序，我们看到了一些不同类型的作业。
首先要做的是设置快照，所以我们先运行这个快照作业以便分发代理能够用来进行复制。
跟我们前面做的DTS作业类似，可能需要一段时间才能运行完成，这次大概需要15到20秒。
还在运行之中。
好，现在显示运行成功了。
我们查看一下作业历史，可以看到快照代理已经成功运行了。
现在我们要转到分发任务。
开始这个作业。
跟以前一样，快照代理需要一段时间来运行。
作业还在执行中。
再等一两秒钟。
好，运行成功了。
看一看作业历史。
正如这儿所看到的，这个作业有一个步骤是连接到FTP站点。
我们已经设置为通过FTP进行复制了。
复习一下，有两个主要的步骤需要设置。
一个是在拉订阅的属性里面设置你的FTP帐号信息。
另外一个是，当设置好出版物后，你还需要在运行完向导后设置出版物的属性，以允许订阅者通过FTP下载快照。
[返回幻灯片：
“SQLServer7.0最常见的10个问题”讲座议程]
现在我们返回到演示计算机。
下一个主题是数据库的收缩。
[下一张幻灯片：
数据库（损坏的页面）]
[下一张幻灯片：
数据库（收缩）]
数据库收缩是另外一个常见的产品支持问题，因为当你运行DBCCshrinkdatabase或shrinkfile时，事情可能没有像你最初期望的那样发生。
例如，有可能你运行完shrinkdatabase，而实际上数据库并没有收缩，而只是在数据库文件中进行了移动和重新分配空间。
也许有的时候确实需要这么做，但现在的问题是，当你运行shrinkdatabase时，SQLServer所进行的操作对用户是不透明的，而且这确实是一个需要好好掌握的命令，需要让它有效地运行。
shrinkfile的情况和shrinkdatabase类似。
需要运行shrinkfile的主要原因是，你可能希望把数据库的大小调整到创建时的大小以下。
shrinkdatabase命令是不会这么做的。
运行shrinkfile的另外一个目的是为了删除一个给定的文件，你可能需要清空它。
当运行shrinkfile时，emptyfile可以作为该命令的一个参数，这样就可以把文件组中某一个文件的数据全部移动到另外一个文件中去。
下一个示范将主要集中于shrinkdatabase。
回到我们的示范计算机，我们将在这台计算机上调入一个脚本文件。
在SQLServerQueryAnalyzer中，我们将调入一个名为SHRINKADATABASE（#4）.SQL脚本文件。
首先我们要运行这个脚本的第一部分，这将创建一个数据库，在接下来的例子中我们要用到。
然后将创建一个相对而言比较大的表，主要是因为列的大小。
这个表将有500行。
之所以把列的大小设定成一个大的值，是因为我们可以在短时间内创建一个相对而言比较大的数据库，而不用创建太多的表。
我们接着进行，运行这部分脚本。
注意，这个演示接下来将会使用很多脚本，有的脚本可能需要花20到60秒来执行。
我们将把这段时间用于观察脚本的执行上。
现在这个脚本执行成功并创建了我们需要的表。
我们来看看如果我们不带任何参数运行DBCCSHRINKDATABASE将会有什么结果。
我们需要在运行这个命令前和运行后分别观察数据库的大小。
最后一点要注意的是，我们需要删除这个大表以便留出空间让数据库能够真正收缩。
现在我们选定这一段脚本然后执行它。
可以看到数据库原先大小是5.63MB，收缩后减少了1.56MB。
不带任何参数运行DBCCSHRINKDATABASE将在数据库中保留25%的剩余空间，而不会收缩数据库中的所有剩余空间回到其原始缺省大小。
接下来到这个脚本的第三部分。
我们要演示带上百分比参数运行shrinkdatabase。
因为我们删除了那个大表，我们必须重新创建它并填入数据。
跟上部分脚本不同的是，我们要求在数据库中保留剩余空间的50%。
同样我们需要在运行脚本以前和以后分别观察数据库的大小。
这将需要几秒钟来执行，因为我们必须重新创建这个表。
现在执行完毕。
我们看到，数据库的原始大小是5.81MB，执行完shrinkdatabase命令后数据库收缩的程度没有刚才那样大。
这是因为我们指定了参数，让数据库保留更多的剩余空间，我们指定的是保留50%，而刚才是25%。
接下来我们将看到执行DBCCSHRINKDATABASE的另一种情况：
带上truncateonly参数。
理解这个参数很重要，因为带上这个参数后运行DBCCSHRINKDATABASE对运行中的数据库的性能影响最小。
这是因为带上truncateonly参数后将只收缩最后分配的那部分空间。
我们将看到它是如何做到这一点的。
首先我们将创建一个叫做“largetable”的表，接着创建“largetable2”和“largetable3”。
我们将在不同的时间删除这些表，然后在删除某一个特定的表后运行shrinkdatabase命令来观察数据库大小的变化。
这一部分脚本中有很多print语句，它可以在运行时输出许多有用的信息，让我们知道脚本正在做什么。
在这个脚本中我们所要做的第一件事就是创建第一个表。
然后是第二个表。
现在正在创建第三个表，当这个表创建完成后过程会变得更快一些。
现在完成了。
在没有表被删除之前，数据库大小是14.06MB。
当我们删除第一个表后，查看数据库的大小，接着运行shrinkdatabase命令，可以看到，数据库大小并没有减小多少。
你可能会认为数据库的大小应该减小三分之一，但实际上却没有。
这是因为我们使用truncateonly参数将只收缩最后分配的那部分空间。
这意味着它不会在文件中移动数据重新分配空间。
接下来我们删除数据库中的第三个表，也就是最后创建的那个表。
可以看到这个表被删除后数据库的大小并没有变化。
然后带上truncateonly参数运行shrinkdatabase命令。
现在可以看到，数据库的大小减少了很多。
现在数据库的第一部分被清空了，最后一部分被收缩了，只剩下第二部分，也就是我们创建的第二个表。
但是使用truncateonly参数仍然不能把数据库恢复到实际大小。
这就是truncateonly参数所起的作用。
我们还要测试另外一个参数的效果，但在开始之前首先需要运行一小段脚本来清除largetable2。
下一段脚本主要讲解DBCCshrinkdatabase的最后一个参数：
notruncate。
Notruncate参数和truncateonly参数所起的作用完全不同。
它并不实际收缩数据库，运行该命令后数据库的大小并不改变。
它所做的是把数据库中的对象尽量移动到数据库文件的前面去，更好地重新分配空间，以便为以后的插入或创建操作留出更连续的空间。
现在我们需要重新创建数据库。
现在正在重新创建表，删除了原先的数据库然后重新创建三个表。
当这些脚本正在运行时，我们来看看下一条将要执行的语句：
DBCCextendinfo。
这个命令将显示某一个对象所在的页面和扩展页面。
注意各个对象之间的相对位置关系。
比如，你可以看到largetable2在物理存储位置上在largetable1之后，largetable3则在largetable2之后。
以后我们会看到这些相对位置发生了什么变化。
现在我们看看执行结果。
前一段脚本执行没有错误。
现在我们来执行脚本中的5b节，用于演示notruncate参数。
我们首先看一下删除以前各个表的相对位置。
largetable2存储在largetable1之后，largetable3则在largetable2之后。
然后我们看看删除第一个表后会有什么结果。
当然数据库的大小不会变。
我们带上notruncate参数运行shrinkdatabase命令，查看一下数据库文件的大小，确实没有变。
我们运行了shrinkdatabase命令但实际上并没有收缩数据库。
现在重新运行extendinfo命令，可以看到，largetable2的位置基本上没有变，从第六百个页面直到一千多。
然而，largetable3原先紧接于largetable2之后，现在却只有一部分位于原来的页面，其它部分则被移动到了数据库文件的前面部分，就是原先largetable1未被删除之前所处的地方。
回顾一下我们的操作：
首先删除了第一个表，然后带上notruncate参数运行shrinkdatabase命令，把第三个表的部分数据移动到了第一个表原先占据的空间。
这样就在文件的最后留出了一块连续空间，可以用于以后创建新的对象。
现在返回到幻灯片，下面将要涉及到的是日志文件的收缩。
[返回幻灯片：
数据库/日志的收缩]
现在切换回演示计算机，我们来讨论一下日志文件收缩的有关话
升级会员 