
安全
在安装过程中,您在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已失效。
无论您选择何种模式,安装程式都为BUILTINAdministrators组创建一个Windows身份验证的登录,他映射到本地机器的管理员组。这个登录的创建意味着任何本地管理员组的成员,包括域组域管理员,都是您的SQL Server的系统管理员(sysadmin)角色的成员。给予网络和本地管理员在SQL Server上的毫无限制的权限并不总是个好主意,因为这引入了安全风险,这样一来您可能决定从SQL Server 的sysadmin角色中移除BUILTINAdministrators,或您可能从SQL Server中完全移去这些自动创建的登录而为DBA成员组用sysadmin身份创建一个登录——不是网络管理员。
假如您决定遵从上述这些建议,这样做就够了:首先,为DBA成员组用sysadmin身份创建一个登录,然后删除BUILTINAdministrators登录。假如您的服务器的身份验证模式时Windows而且您在为DBA创建登录以前删除任何具备sysadmin资格的登录,您会发现您自己被锁在了SQL Server之外,无法执行管理任务——如:创建新的登录。假如您落入了这个陷阱,您仍然能够通过把注册表HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL Server实例名MSSQLServerLoginMode的键值更改为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 数据库默认。 |