微软总是试图使它的软件安装尽可能地简单顺畅，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身份创建一个登