SQL Server的有效安装

发表于:2007-07-02来源:作者:点击数: 标签:
微软总是试图使它的软件安装尽可能地简单顺畅,SQL Server 2000的安装也不例外。你从安装光盘的x86 etup文件夹启动setup sql .exe、在安装对话框中填入一些细节后,几分钟内,安装将在没有用户介入的情况下继续执行。你甚至可以成功的安装SQL Server 2000而

    微软总是试图使它的软件安装尽可能地简单顺畅,SQL Server 2000的安装也不例外。你从安装光盘的x86 etup文件夹启动setupsql.exe、在安装对话框中填入一些细节后,几分钟内,安装将在没有用户介入的情况下继续执行。你甚至可以成功的安装SQL Server 2000而不用明白那些选择意味着什么——只需在大多数安装对话框中点击“下一步”。然而,我强烈建议你不要如此轻率地对待安装;留意每一个选项并且确保你完全理解你所作的每个选择的影响。一些低劣的决定,比如错误的排序规则设置,可能很难被修复;其他的,比如接受默认的身份验证模式,可能创建了安全漏洞。

 

    让我们看一些有关标准安装的重点,包括实例配置、安全性、排序规则和网络库。然后让我们探索无人值守和远程安装的高级选项。

  

实例

当你开始安装时,经常执行标准安装(与远程或无人值守安装相比)。你调用setupsql.exe程序来启动安装向导。在开始的两个对话框——欢迎和机器名——之后,你需要对你的实例配置作选择。SQL Server 2000支持在一台机器上安装多个SQL Server的实例。安装程序显示两个对话框来给你安装实例的选项。

首先,安装选择对话框显示了让你选择是否安装一个新的实例或者升级一个已经存在的安装。如果你选择安装一个新的实例,你将看到“实例名对话框”显示出来。你可以指明一个实例名或选择默认来安装一个默认实例——如果默认实例还未安装在机器上。

在做有关安装实例的选择时你需要考虑几件事。如果机器上没有默认实例、你打算在同一台机器上使用SQL Server 2000和7.0,确信你没有将SQL Server 2000作为默认实例安装。SQL Server 7.0不支持命名实例,所以它必须成为默认实例。除了卸载和重新安装SQL Server,你不能把命名实例改为默认实例或者相反。你同样也不能在实例安装后更改实例名。然而,你可以在安装SQL Server 2000后再安装SQL Server 7.0——如果你还没有安装一个默认实例的话。

如果一个SQL Server 7.0的安装已经存在,你可以将它升级——通过在安装选择对话框中选择升级路径并在后一个对话框中说明你想要升级默认实例。然而,SQL Server 2000将成为默认实例,SQL Server 7.0在这台机器上将不复存在。要两个版本都保留,把SQL Server 2000作为一个命名实例来安装。

安装完SQL Server 2000后,你可以使用备份和恢复、分离和连接、数据转换服务或者复制数据库向导来把SQL Server 7.0的数据库调到SQL Server 2000中来。注意,当你升级一个先前的版本到SQL Server 2000时,无论选择何种方式,你不能对数据库同样的拷贝指明超过一个的安装,所以每个安装必须维护它自己的每个数据库拷贝。

另一个考虑涉及SQL Server 7.0被称为“版本切换”的特性,它让SQL Server 7.0与SQL Server 6.5共存于同一台机器。但是,同时只有一个安装可以是活动的,另一个是静止的。当你调用版本控制,它激活静止的安装并使活动的那个停止活动。如果机器上包括一个SQL Server 6.5的安装——它没有以版本控制的形式和SQL Server 7.0共存,安装程序要求你选择两个选项之一:升级SQL Server 6.5到SQL Server 2000的默认实例并且在两个版本间保持一个版本控制;升级到SQL Server 2000的命名实例。和从SQL Server 7.0升级不同——它覆盖了当前的安装,6.5的安装保留在电脑中——不管你为升级到2000选择何种路径。

如果7.0和6.5都已安装并以“版本控制”的形式共存在同一台机器中,而且你不想升级已存在的安装,你可以安全地在同一台机器上安装2000的命名实例并且在同一台机器上使用所有三个版本。然而,以版本控制形式共存的同时只有一个版本可以运行,而所有命名实例可以同时运行。

在说明了你的实例选项后,我们来到安装类型对话框。

 

自定义安装

       在安装类型对话框中,安装向导要求你在3个安装类型中作选择:典型、最小和自定义。如果你选择典型或者最小,SQL Server对组件和子组件、排序规则和网络库都使用默认选项。因为典型安装会潜在地引起棘手的问题,我强烈建议始终选择自定义——即使你认为默认满足你的安装需求。一些以前提及的选项——特别是排序规则——在安装后如果发现不满足需求是非常难以更改的。自定义安装让你再次检查那些选项。

 

安全

       在安装过程中,你在2个对话框中说明和安全相关的信息:服务账号和验证模式。在服务账号对话框里,你填入SQL Server和SQL Server Agent服务的服务账号细节。每个服务使用在对话框中说明的账号来被操作系统调入,并且在操作系统中运行于这个账号的安全上下文里。比如:当你备份到一个磁盘设备,SQL Server检查你用来登录到SQL Server的登录是否具有适当的“备份数据库”权限。然而,创建备份文件设备并写入,SQL Server必须在磁盘或者网络共享中创建一个文件,这个操作使用SQL Server服务账号的安全上下文。

       同样的,SQL Server Agent服务在SQL Server Agent服务账号的安全上下文下在SQL Server、操作系统或网络中运行过程。虽然一个在本机不具有管理权限的账号可以启动SQL Server 服务,把SQL Server 服务账号加入到本地管理员组是个好主意。否则,你需要额外地把所有所需的权限授权给该帐号,还需要授权该帐号合适的网络权限。

       而如果你试图通过一个机器上不具有管理员权限的服务账号来启动SQL Server Agent,它甚至无法启动。而且如果SQL Server Agent在网络上的其他机器上执行操作,比如复制或者多服务器工作,你应该使用一个在其他机器上具有适当权限的域账号。比如在一个包含3台SQL Server机器的单域多服务器环境中,一台主服务器控制目标服务器上的自动活动。因为双方(主服务器和目标服务器)需要相互通讯,你需要确保主服务器上的SQL Server Agent服务账号在目标服务器上具有适当的权限,反之亦然。配置这样一个环境的最简便方法就是创建一个域账号,使它在所有服务器上成为本地管理员组的成员,并且通过该帐号来调用所有的SQL Server Agent服务。

       在身份验证模式对话框中,你可以选择是否只允许Windows身份验证登录(Windows身份验证模式)或者Windows和SQL Server两者登录(混合模式)。你也可以为sa(System Administrator)的SQL Server登录指定一个密码。Windows身份验证模式是默认的和最常用的推荐安全模式。然而,为安全起见,我建议你选择混合模式并且为sa账号提供一个密码,在安装完成和处理完一些其他的安全项目后,再把验证模式改为Windows身份验证模式。如果你选择Windows身份验证模式作为你的服务器的安全模式,安装过程把sa登录创建为无效并且没有密码(因为SQL Server身份验证模式是无效的)。你可以在安装后更改sa的密码——我强烈建议你这么做——但是一开始就选择Windows身份验证模式是危险的,因为你可能忘了更改密码或者使用空密码,以为sa已经失效。

       无论你选择何种模式,安装程序都为BUILTIN\Administrators组创建一个Windows身份验证的登录,它映射到本地机器的管理员组。这个登录的创建意味着所有本地管理员组的成员,包括域组域管理员,都是你的SQL Server的系统管理员(sysadmin)角色的成员。给予网络和本地管理员在SQL Server上的毫无限制的权限并不总是一个好主意,因为这引入了安全风险,这样一来你可能决定从SQL Server 的sysadmin角色中移除BUILTIN\Administrators,或者你可能从SQL Server中完全移去这些自动创建的登录而为DBA成员组用sysadmin身份创建一个登录——不是网络管理员。

       如果你决定遵从上述这些建议,这样做就够了:首先,为DBA成员组用sysadmin身份创建一个登录,然后删除BUILTIN\Administrators登录。如果你的服务器的身份验证模式时Windows而且你在为DBA创建登录以前删除所有具有sysadmin资格的登录,你会发现你自己被锁在了SQL Server之外,无法执行管理任务——如:创建新的登录。如果你落入了这个陷阱,你仍然可以通过把注册表HKEY_LOCAL_MACHINE OFTWARE\Microsoft\Microsoft SQL Server\实例名\MSSQLServer\LoginMode的键值更改为2,来把SQL Server身份验证的模式改为混合模式,修改好后重新启动SQL Server服务即可。

       虽然通过注册表可以控制SQL Server的登录模式是方便的,它也有个缺点。任何人只要具有编辑注册表键值的权限,包括网络和本地管理员,都可以更改SQL Server的身份验证模式。如果你用Windows身份验证模式来安装SQL Server,sa是失效的但是仍然具有一个空白的密码。如果接着你更改SQL Server身份验证模式到混合模式(这就使sa登录有效),任何人都可以作为sa登录。所以,绝对确保你一完成安装就更改sa密码或者在安装过程中选择混合模式并且为sa提供一个密码。

 

排序规则

    接下来,你需要选择排序规则设置。SQL Server 2000中的排序规则(Collation)设置用来管理和语言相关的行为、对象名称和列的值的唯一性,以及排序规则(sorting rules)。在排序规则设置对话框里,你说明排序规则并在SQL Server排序规则和Windows排序规则两者之间选择其一。如果你需要和以前SQL Server版本的向后兼容性,选择SQL Server排序规则——比如,如果你打算在一个早期版本的SQL Server和SQL Server 2000之间使用复制。否则,选择Windows排序规则。SQL Server 2000的排序规则设置,不管是Windows或是SQL Server,合并了在先前版本中的3个独立的设置:字符集,排序次序和Unicode排序规则。除了整合旧的3个设置到一起外,SQL Server 2000在排序规则中还提供了比以前版本更为强大的灵活性。

       在你安装SQL Server 2000时选择的排序规则决定了系统数据库的排序规则设置。要在安装后更该系统数据库的排序规则设置,你需要脚本化所有你的系统对象(比如:登录,消息,工作)并且运行rebuildm.exe,它用新的排序规则重建了所有的系统数据库。然而,你不必先导出用户数据库中的所有数据再在运行完rebuildm.exe后把他们再导入——就像你再SQL Server 7.0中所作的那样。你只须重新连接用户数据库到SQL Server。你可以用不同于默认服务器的排序规则(这是模板系统数据库的)的排序规则配置你的用户数据库,或者甚至用不同于服务器设置的排序规则连接或恢复一个数据库。你可以以后修改用户数据库的默认排序规则。对于特定的一列,你可以指定不同于默认的数据库排序规则的一种排序规则;你甚至可以稍后修改列的排序规则——如果该列上没有创建索引的话。

       虽然在排序规则方面SQL Server 2000是灵活的,不要低估了你在安装时作的选择。正如我前面所言,服务器的排序规则应用到所有的系统数据库并且决定了记录在系统数据库中所有对象(如登录名,数据库名)的排序规则。进一步而言,tempdb的排序规则也是你在安装过程中选择的服务器排序规则。当你创建一个临时表,表的列使用tempdb的排序规则——除非你在每列的定义里指明COLLATE 数据库默认。

 

网络库

       在说明了排序规则设置后,你来到了网络库对话框。网络库是客户机应用程序用来和SQL Server通讯的协议。客户机和SQL Server都必须有至少一个匹配的网络库,通过它两者可以通讯。在网络库对话框中,你设置SQL Server将会用来和客户机通讯的网络库。

       在SQL Server 6.5中,只有命名管道和多协议允许Windows身份验证;所有其他网络库只允许SQL Server身份验证。这样一来,对于SQL Server 6.5来说,你想要支持的登录类型时你选择网络库的一个因素。进一步来说,只有多协议允许数据加密,所以如果你SQL Server 6.5支持数据加密,你就不得不选择这个网络库。在SQL Server 7.0中,所有网络库支持Windows身份验证,在这个意义上你就更加灵活,但是多协议仍然是唯一允许数据加密的网络库。

       在SQL Server 2000里,你可以通过使用SQL Server 网络工具和SQL Server客户机网络工具的安全套接字层(Secure Socket Layer,SSL)来对所有网络库强制加密,这样一来,加密因素不再决定网络库的选择。同样,在SQL Server 2000里,多协议不支持命名实例方案(服务器名\实例名),这样的话,当你使用命名实例时,多协议也不是个好的选择。SQL Server 2000中最通用的网络库大概是TCP/IP套接字吧。它提供了良好的性能,允许Windows身份验证,而且你可以在需要时对它进行强制SSL加密。

       大多数使用SQL Server早期版本的用户知道SQL Server的默认TCP端口是端口1433。当使用默认端口时,客户机连接除了服务器名或者IP地址不需要提供端口号。然而,SQL Server 2000支持多个实例,这无法统统使用同样的端口号。所以当你安装一个命名实例时,安装程序建议把0作为端口号。端口号为0意味着当SQL Server第一次启动时,它动态地选择一个空闲的端口号并且把它永久保留或者直到你稍后手工修改它为止。那么客户机连接如何继续通过仅仅提供服务器名称/IP地址+实例名而不用指定端口号找到SQL Server呢?SQL Server 2000中的一个监听器服务监听端口1433上的客户机请求,然后通过检测请求中的实例名并把它和实例的端口号匹配,再把该请求重定向到适当的实例。

 

无人值守和远程安装

    现在我们的标准安装已经完成,让我们讨论一下无人值守安装。Setupsql.exe程序让你记录下一个应答文件,它包括了你在安装程序对话框中常选的对于各种安装选项的所有回答。稍后,你能够通过调用以该应答文件作为参数的setupsql.exe命令来运行一个安装。这种无需任何用户干预的安装类型被称为无人值守安装。

       要准备应答文件,先启动安装程序,在安装选择对话框中选择高级选项,在对话框中选择选取“记录无人值守.ISS文件”。安装程序会指导你完成常规的安装对话框,其中你可以填入所有你想要记录的选项。当你完成后,安装程序在\WINNT文件夹下创建一个名为setup.iss的文件。

       要启动一个无人值守安装,运行setupsql.exe程序,用-s作为执行安静安装的参数、-fl参数指定一个应答文件。例如,要启动一个安静的、无人值守的安装——安装完成后不通知你,你可以使用以下命令:

       <path> etupsql.exe –s –fl <path> etup.iss

       如果你想在安装完成时得到通知,从命令行执行如下setupsql.exe程序,或者把它写入一个批处理文件中:

       start /wait <path> etupsql.exe -s –fl <path> etup.iss

       直到安装结束,控制才会传递到下一条命令。当你从批处理文件启动安装,而这个文件又包括其他依赖于安装的行为时,使用start /wait选项是特别重要的。例如,假设你要为一个名为INST1的命名实例执行无人值守安装来创建批处理文件,然后启动SQL Server服务,再运行一个用来创建数据库及其对象(如:表、存储过程)的sql脚本。这个批处理文件看起来可能像这样:

       start /wait D:\X86 etup etupsql.exe –s –fl C:\WINNT etup.iss

      .net start MSSQL$INST1

       OSQL /E /I “c:\data cripts\createappdb.sql”

       如果你不使用start /wait选项,控制从安装一开始就移到了批处理文件的第二条命令,而这条NET START命令试图启动一个还不存在的服务。

       对一个无人值守安装进行故障排除要比对待标准安装的故障排除更需要慎重对待。标准安装往往在安装程序遇到问题时通过显示一个包含出错信息的对话框(并伴有响亮的警告声)来通知你。而无人值守安装只是简单地终止,且没有交互的通知。

       要了解如何对无人值守安装进行故障排除,让我们来看一组我遇到过的问题。假设你已经在服务器上完成了另一个产品的安装,然后你试图执行一个SQL Server的无人值守安装。安装程序检测到在前一个安装结束后服务器尚未重启,于是放弃安装,同时没有任何信息提示。如果你保持任务管理器窗口打开,你会注意到setupsql.exe 程序不活动,所以SQL Server没有被安装。你也应该检查日志文件。一旦安装成功,\WINNT etup.log文件应该显示0作为出错代码;然而,在我描述的情景中,他很可能显示-1,这表示一个基本错误。你也应该看一下出错信息。

       当执行无人值守安装时,我遇到过多次的另一个错误是“对话框次序紊乱”。在我调用安装程序后不久我就意识到这一问题的存在——那是在我打开任务管理器并看到setupsql.exe虽然在运行但是没有像正常的无人值守安装那样调用和释放进程。同时,安装程序通常在\Program Files\Microsoft SQL Server下创建的文件夹也没有被创建。Setupsql.exe程序看来并没有占用CPU或者I/O资源,只是在大约10分钟后消失了。Setup.log文件显示一个-12的错误代码而sqlstp.log文件显示没有错误——实际上,它看来还未完成。Sqlstp包含了不完整的注意事项,只是一条消息——Begin Action:DialogShow<dialogname>。BOL显示了以下有关错误代码-12的信息:“对话框次序紊乱。这是一个常见错误,由在安装初始化文件(Setup.iss)文件中的一个对话框次序紊乱所引起。这是由于Setup.iss文件创建过程中的系统问题所产生。”足以确认,在我重新对Setup.iss文件排序后,无人值守安装成功完成。

       除了完全安装,你还可以执行SQL Server 2000服务包的无人值守安装。要把服务包应用到默认实例上,从服务包的安装目录调用setupsql.exe程序,指明应答文件为位于服务包安装目录根目录下的sql2kdef.iss。例如:如果服务包安装文件位于c: ql2ksq2下,执行入下命令:

       start /wait c: ql2ksp2\x86 etup etupsql.exe –s –fl c: ql2ksp2 ql2kdef.iss

要把服务包应用到命名实例上,使用sql2knm.iss应答文件,但是首先修改文件中的下列两行来对应正确的命名实例:

       InstanceName = INSTANCE_NAME

       NMPPipeName=\\.\pipe\MSSQL$INSTANCE_NAME ql\query

       另一个高级选项——远程安装——让你在一台远程的电脑上安装SQL Server 2000。你可以从一台本地的电脑上手工记录下一个setup.iss文件,把它复制到远程电脑上,在激活setupsql.exe程序和在远程电脑上的setup.iss文件。然而,你可以替自己省些麻烦——通过在本地电脑上运行setupsql.exe程序,在电脑名对话框中选择远程电脑,指明你想要安装到的电脑名。当你点击下一步时,远程安装信息对话框会显示出来。

       首先你要提供帐号细节(用户、密码、域),到目标文件夹的UNC路径和源安装文件的UNC路径。接下来,安装程序将指引你完成常规安装对话框并根据你的选择记录下setup.iss文件。接着,程序复制setup.iss文件到目标电脑的\WINNT文件夹下,再用复制的setup.iss文件来激活setupsql.exe。

       如果你在目标电脑上打开任务管理器,你会看到setupsql.exe进程在安装过程中调用和释放其他进程。在本地电脑上,安装程序显示远程安装正在进行中,并且会在完成时通知你。

 

最后的话

       虽然基本安装看来简单,你仍需队与你所选择的安装选项给予密切注意,并且完全理解它们。良好的安装选择为运行和管理SQL Server提供了一个坚实的基础。而如果你认为执行无人值守安装和远程安装听起来复杂的话,我希望这篇文章有助于你对它们加深了解。

原文转自:http://www.ltesting.net