版本 2.0
第 10 章
服务蓝图
MSA 参考体系结构工具包
Microsoft 机密。© 2003 Microsoft Corporation。保留所有权利。这些资料属于 Microsoft 公司的机密信息，同时被当作商业秘密。这些资料中的信息仅面向 Microsoft 授权的接收者。对于这些资料的使用、散发或公开讨论，以及任何反馈均以所附的许可协议条款为依据。您可以通过向 Microsoft 提供这些资料的任何反馈，表示同意该许可协议的条款。如果该许可协议已被删除，请在使用这些资料之前，在http://www.microsoft.com/licensing/specs/agrmt02.asp 上阅读有关条款。
摘要
本章详细讲述了成功创建企业数据库解决方案所需的设计程序和背景技术知识。该解决方案在基于 Windows® Server 2003 的操作系统环境中使用 Microsoft® SQL Server™ 2000。
本文档中的信息（包括 URL 及其他 Internet 网站参考资料）可能随时变更，恕不另行通知。使用本文档的全部风险或因此导致的后果均由用户自行承担。
除非另外注明，否则此处作为例子提到的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和时间纯属虚构，绝不意指，也不应由此臆测任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和时间。
遵守所有适用的版权法律是用户应尽的责任。在不对版权法所规定的权利加以限制的情况下，如未得到 Microsoft Corporation 明确的书面许可，不得为任何目的、以任何形式或手段（电子的、机械的、影印、录制等等）复制、传播本文的任何部分，也不得将其存储或引入到检索系统中。
Microsoft 可能拥有本文档主题涉及到的专利、专利申请、商标、版权或其他知识产权。除非在 Microsoft 的任何书面许可协议中明确表述，否则获得本文档不代表您将同时获得这些专利、商标、版权或其他知识产权的许可证。
© 2003 Microsoft Corporation。保留所有权利。
Microsoft、Active Directory、BizTalk、MSDN 以及 Windows 徽标是 Microsoft Corporation 在美国和/或其它国家或地区的注册商标或商标。
此处提及的实际公司和产品名称可能是其各自所有者的商标。
Microsoft Corporation • One Microsoft Way • Redmond，WA 98052-6399 • USA 00
目录
结合 Windows Server Clustering 部署 SQL Server 14
方案 5 —— 使用多个 SQL Server 实例... 20
方案 1 —— 通过 SQL Server 2000 联合进行外扩... 20
方案2 —— 外扩只读 SQL Server 负载... 21
SQL Server 2000 Enterprise Manager 34
Microsoft Operations Manager 35
方案 1 —— 在同一台服务器上运行多个 SQL Server 实例... 36
方案 2 —— 合并相同的 SQL Server 实例上的数据库... 37
将 SQL 6.5/7.0 数据库迁移到 SQL Server 2000. 38
将 SQL Server 6.5/7.0 升级到 SQL Server 2000. 39
运行 SQL Server 6.5/7.0 和 SQL Server 2000. 39
“Microsoft Systems Architecture（MSA） 服务蓝图”指南的这一章详细介绍了在 Windows® Server 2003 环境中如何使用 Microsoft SQL Server™ 2000 设计企业数据库解决方案。它提供了一种参考体系结构，各个组织可以使用这种体系结构在企业级系统基础结构中提供关键任务的数据服务。尽管本章曾经是用来指导在 MSA 2.0 情境下创建设计方案的，但现在它仅仅是一个参考，并且在用于满足特定的业务要求之前，您应该将它与 SQL Server 和数据库设计中的经验及专业技术结合起来。
有关数据服务的附加信息，可以在本文档工具包内的“体系结构蓝图”指南的“MSA 应用程序基础结构的体系结构”一章中找到。而在“MSA 实施工具包”内的“MSA 2.0 规划指南”的“数据服务”一章中提供了具体实施细节。
撰写本章的目的是满足负责在企业、公司或分公司环境中设计和部署数据服务的信息技术 (IT) 专业人员的要求。本章的读者应该对技术细节有一定的了解；然而，服务级专家无需参与企业级讨论并了解所做的决策。
虽然本章旨在帮助任何有兴趣了解实施基于 SQL Server 2000 的数据服务所涉及的各个层面的人员，但是我们假定读者已经具备了相当于至少两年 Microsoft 认证系统工程师 (MCSE) 经验的知识水平。本章还假定读者对以下几方面的知识有所了解：
· SQL Server 2000
· 数据库复制
· 高端存储技术
在本章末尾处的“参考资料”一节中包含了一些网站的地址，提供了有关数据服务设计和部署的详细信息。
大多数企业组织都需要提供全天 24 小时的数据服务，这就意味着在保持基础结构、数据和服务联机的同时，必须保证最短的停机时间。当数据库系统基础结构的各个组成部分有不同的来源，并且需要高水平的技术人员进行维护时，满足这些需求就变得更加复杂了。
数据服务最重要的要求之一是可用性、安全性、可伸缩性。SQL Server 2000 可以满足企业环境中的这些要求，因为其能够：
· 提供多级别的安全性。
· 应对大型内存空间。
· 支持大型数据库。
· 支持集群和容错数据库。
数据服务旨在应对当前商业组织（包括在分布式环境中提供电子商务、数据仓储、数据挖掘、联机事务处理 (OLTP) 的组织）所面临的数据服务方面的要求。这些组织需要在某个地方维护大量记录，并且采取一定的机制对这些记录进行有效的访问和更新。在这些数据中，有些包含敏感的组织信息，它们对安全性和业务连续性提出了其他方面的要求。
MSA 2.0 数据服务体系结构是一种通用设计，这种设计应该能够支持下列方案：
· 面向大型电子商务站点的数据库设计：电子商务应用程序在联机事务方面通常需要安全和高度可用的数据库。用户数据和购物车服务可以处理动态数据，并且能够运行在故障转移服务器群集以实现高可用性。然而，电子商务站点中的多数采样数均由进行浏览的客户生成。网站可以提供一些保持相对不变的类数据目录，并且可以通过提供只读数据服务的 SQL Server 群集中的防火墙公开给用户。这种群集可以运行在各种服务器之间随机分布请求的 Microsoft Network Load Balancing。
· 面向大型商业智能应用程序的数据服务设计：大型商业智能应用程序向客户端发布联机分析处理 (OLAP) 数据结构，客户端将它们表示成直接可读的结果。已处理的数据结构（也称为多维数据库）可以在负载平衡的 SQL Server 群集上进行托管。由于所要发布的数据随业务流程的进行和相关要求的变化而不断地发生变化，因此创建可读数据（主题数据库）的服务器必须提供高性能。在这种情况下，可以将多个 CPU 与 SQL Server 2000 一起使用。
· 高吞吐量 OLTP 系统：典型的 OLTP 应用程序需要处理繁重的事务，涉及大量的读/写操作。这些应用程序都要求系统具备强大的处理能力和充足的内存，以便同时为大量企业用户提供服务。典型的例子有企业资源规划实施，其中，中间服务器是 8-CPU 的服务器，而生产服务器是 24-CPU 服务器，以满足众多联机用户的服务需求。配备大量 CPU 的计算机提供了处理器分区机制，因而允许中间服务器和生产服务器构建于相同的计算机上。
· 通过数据服务进行状态管理：某些种类的应用程序（例如 Microsoft BizTalk® Server）必须对它们所提供的服务执行状态维护。这类应用程序要求数据库始终处于联机状态，因为集成系统的其他部分可能会因数据库的脱机而出现故障。在这种情况中，建议采用故障转移服务器群集，因为其廉价、高效，而且易于维护。可以实施双节点群集，但是这可能导致单一服务器超负荷。最有效的解决方案是采用四节点服务器群集，其中三个节点用于托管数据库，第四个作为热备用。
· 数据仓库应用程序：数据仓储应用程序通常需要大量数据和诸如 SAN（存储区域网络）这样的高端存储系统。数据仓储应用程序用户需要访问数据以进行 OLAP 处理。对于这类应用程序，建议把数据库从分析服务中独立出来。数据库可托管于执行所有处理工作的多处理器计算机。由于分析服务器上包含相同的数据，因而可将这类数据库托管于负载平衡群集以实现更高的可伸缩性。两组服务器可以通过 SQL Server 复制保持同步。
针对数据服务的 MSA 企业设计
以下部分提供了有关使用 Windows Server 2003 和 SQL Server 2000 创建一个设计来支持企业级数据服务的详细信息。
为了满足上述业务需求，提供数据储备库、数据管理和数据维护服务的技术应该高度可用、安全、可伸缩且易于为开发和管理所用。随着数据储备库的扩大，它还应该能够满足性能要求，并且帮助组织有效地管理和分析数据。
所有这些目标都可以通过使用 SQL Server 2000 和Windows Server 2003 来实现。Microsoft SQL Server 2000 是一个用于大规模 OLTP、数据仓储和电子商务应用程序的优秀数据库平台。只要进行相关的部署、维护和管理，它就是一个可靠、安全且易于使用的数据库引擎。另外，它还提供了一些灵活性，因为它既可以部署在具有较少资源的低端服务器上，又可以部署在具有多个 CPU 和大容量内存的高端服务器上。一些可以与 SQL Server 一起使用以满足企业业务需求的技术包括：
· 数据复制：大多数电子商务网站需要以只读方式访问目录数据，因此用户可以浏览产品并且在购买前获得它们的详细信息。这种数据通常由网站所有者在产品可用性发生改变和添加或删除一些种类时更新。需要将数据负载外扩到一定的程度，因为许多客户端将同时对其进行访问。要做到这一点，可以将数据放在负载平衡的服务器群集上，并且可以在需要时使用复制技术进行更新。SQL Server 2000 支持各种复制技术，例如事务复制、日志传送和快照复制，这些技术可以用来自动将后端读/写服务器移到多个只读日志服务器中。复制技术也可以用来将数据库备份到一个地域上隔离的备用服务器上，以保护其免受灾难性故障或自然灾害的损害。
· 对大量数据的支持：诸如 SAP、Siebel 和业务线这样的应用程序需要支持日益增长的数据量。在这种情况下，具有多 CPU、大容量内存和适当的存储结构的高端服务器有可能是必需的。这些应用程序每分钟可以执行成千上万个事务，并且其容许的停机时间在可以忽略的范围内。SQL Server 2000 可以使用 32 路服务器和 64GB 的随机存取存储器 (RAM)，以满足大型数据库的要求。
· 最短的停机时间：对于某些在线业务（例如电子商务网站），停机时间可能是灾难性的。诸如 Microsoft BizTalk Server 和 Microsoft Commerce Server 这样的业务应用程序依赖于数据服务的可用性，并且在这些服务变得不可用时可能会导致重大的金融损失。SQL Server 2000 可以部署在 Windows Server 2003 上的群集配置中，以获得高可用性。
· 对增长做出响应：数据服务体系结构需要提供足够的可伸缩性来满足跨组织内的数据中心的用户要求和业务需求，以便应对正在不断增长的数据和相关的数据服务。Windows Server 2003 服务器上的 Microsoft SQL Server 2000 可以支持附加的内存和更多 CPU，以处理日益增长的数据量。Windows Server 2003 中的 Diskpart 工具提供了在无需重新启动的情况下动态扩展容量的能力。
· 数据隐私：对于当今的组织来说，数据隐私是不可或缺的。组织数据可能包含机密的客户信息，必须对这些信息加以保护，以免遭受恶意用户的攻击。Microsoft SQL Server 2000 支持基于角色的访问，它允许将用户权限仅限制到某些数据库对象上。另外，还可以通过给 SQL Server 2000 用户分派固定的服务器角色来防止其执行预定义任务，例如创建数据库、管理磁盘文件或者进行批插入等等。通过使用固定的数据库角色，还可以将用户限制在通过某些特定的数据库执行某些特定的任务。
· 数据管理：日益增长的数据量也使得管理越来越麻烦。Microsoft SQL Server 2000 包含诸如 SQL Query Analyzer 之类的工具和内置审核技术，可以用来监视和管理数据服务。用于监视服务器是否处于良好状态并且在出现任何故障时发出警报的其他工具包括：Windows Performance Monitor 和Microsoft Operations Manager (MOM)。
· 灾难恢复：在发生故障时，必须存在一些机制来优化系统、数据和应用配置信息的恢复。下面是这种机制的两个例子：冗余计算资源的使用以及数据和处理资源的退耦。另外，Windows Server 2003 中的 Microsoft SQL Server 2000 还支持诸如快照备份之类的技术和 Virtual Shadow Copy Service，以在不影响当前的数据库活动的情况下备份数据。这样备份的数据可以存放在磁带中，当发生故障时再移至线上。
· 负载分布：随着业务的发展，更多的应用都开始依赖于数据服务。根据关键性和安全性要求，一些应用程序数据可能需要存放在单独的数据库中，仅允许有限的用户进行访问。Microsoft SQL Server 2000 能够在单个服务器上运行多达 16 个数据库引擎实例，通过使用这项功能，可以提供数据机密性，并且将用户对数据库的访问进行分离。
设计数据服务的第一步就是识别数据库及其用户的类型。这些标准将推动数据库技术及其相关实施方案的选择。本指南所选择的技术为运行在 Windows Server 2003 上的 SQL Server 2000。这一部分考虑应该使用哪个版本的 SQL Server 2000；一旦做出了选择，就可以评估下一组设计方案。
要确定适合特定情形的数据服务设计，需要考虑以下事项：
· 数据服务必须满足何种可用性和可伸缩性标准？
· 必须托管的数据库有多大？另外，是否存在必须考虑的现有存储体系结构？
· 是否有用来度量数据服务性能的基准？
· 哪些管理资源可以用来管理所选的方案？
· 管理数据服务的合适体系结构类型是什么？例如，它是集中式的还是分布式的？
· 需要将何种安全性标准作为数据服务定义的一部分加以考虑？
一旦您具有了这些信息，就可以给数据服务定义一组适当的设计方案了。
SQL Server 版本的设计方案
有七种不同版本的 SQL Server 2000 可以用来满足组织对性能、运行时和价格的独特要求。下表列出了五种典型的数据中心情境、以及要求和适合每个情境的 SQL Server 版本。
| 数据中心 | 所需的 SQL Server 功能 | SQL Server 版本 |
| 分公司 | · 数据服务必须担负得起，并且应该满足精简的商业组织的需要。 · 可能需要一些数据挖掘功能和核心 OLAP 功能。 · 不需要带有多个 CPU 的高可用性服务器。 | SQL Server 2000 Standard Edition/Personal Edition |
| 部门 | · 可能使用分析服务的高级功能（例如具有高维的 OLAP 多维数据库，并且可能需要实时快速更新多维数据库。 · 必须保护敏感数据，并且需要更高级别的隔离性和安全性。 · 必须是可伸缩的，以适应快速增长的数据量。 | SQL Server 2000 Standard/Enterprise Edition |
| 外联网 | · 需要为一些合作伙伴提供高可用性的服务。 · 需要限制对经过选择的数据的访问，因为一些合作伙伴对安全性提出了严格的要求。 · 服务应该扩展到一定的水平（例如，4 个处理器的服务器和至少 2 GB RAM。） · 为了跨数据中心移动数据库，必须支持复制功能。 | SQL Server 2000 Standard Edition |
| 公司 | · 扩展到支持大型网站、企业 OLTP 和数据仓储系统所需的性能水平。 · 支持故障转移群集，以适应关键任务的业务线应用程序。 · 多个 SQL Server 实例的数据联合，旨在提供更好的吞吐量 · 地区性站点的数据复制 · 将多个 SQL Server 实例合并到高端服务器上。 · 使用 SAN 技术。 | SQL Server 2000 Enterprise Edition |
| Internet | · 与公司情境相同。因为 Internet 数据中心托管在线业务，所以可用性和可伸缩性是必需的。 | SQL Server 2000 Enterprise Edition |
表 1. SQL Server 2000 的版本和数据中心要求
Microsoft SQL Server 2000 可以用来创建多种体系结构以满足企业的业务需求。适用于 SQL Server 的所有部署的关键设计方案包括：
· 采用什么样的体系结构 —— 是独立的服务器还是多台服务器？
· 可以实施何种存储类型 —— 直接附加存储 (DAS)、网络附加存储 (NAS)，还是存储区域网络 (SAN）？
· 数据库性能要求达到什么样的水平，适合您的数据服务的性能设计方案是什么？
为了支持附加的依赖服务和附加的用户，数据服务应该是可扩展的。本章讨论了两种扩展策略，上扩 (scale up) 和外扩 (scale out)，它们可以用来从数据量和速度两个方面提高数据服务的吞吐量。两种升级策略都有其内在的优势以及约束，这些内容将在下一节中介绍。有关选择最佳策略（上扩或外扩）的附加信息，请参阅 www.microsoft.com/technet/tcevents/teched/tesql01.asp 上标题为“QL Server 2000：上扩和外扩”的 Microsoft TechNet 文章。
下面的设计方案适用于大多数企业数据服务，尽管一些方案对某些企业情境（如分公司）可能不是很重要，或不是很合适。而且，一些选择还依赖于前面的选择；例如，如果使用单个独立服务器来部署数据服务，则扩展服务的方案就仅限于上扩而不是外扩。
正在考虑的设计方案主要与下列可用性和可伸缩性问题有关：
· 用 Windows Clustering 提高 SQL Server 可用性的方案是什么？
· 如果数据服务必须是可扩展的，则在同一台服务器上（上扩）/跨不同的服务器（外扩）扩展服务的方案是什么？
· 如果采取外扩策略，则如何及何时可以使用负载平衡？
SQL Server 体系结构设计方案
Microsoft SQL Server 2000 既可以部署在独立的服务器上，也可以跨多台服务器部署。这一选择会影响到数据服务的可用性以及可伸缩性。
方案 1 ―― 独立部署
Microsoft SQL Server 2000 可以部署在独立服务器上以满足数据服务的要求。
您可以通过添加内存、CPU 和存储空间来扩展单台服务器，以获得更好的性能。例如，运行多个 SQL Server 实例的高端服务器可以代替几个单独的服务器。有关 SQL Server 扩展的详细信息请参见本章的“可伸缩性”一节。
优点
独立部署的优点包括：
· 经济：在单台独立服务器上运行 SQL Server 是一种经济的解决方案，其中，可用性不是主要问题。
· 低空间要求：独立服务器所需物理空间最小。
· 低管理开销：对于管理、安全、监视和部署服务程序包或者热修补来说，在单个独立服务器上运行 SQL Server 是最简单的设计。
· 递增式硬件升级：通过上扩独立服务器，组织可以采用递增的方式给相同的 SQL Server 实例添加资源，以达到所需的性能水平。
· 集中式数据：独立服务器有助于合并和集中数据（为了安全或其他原因）。
缺点
独立部署的缺点包括：
· 没有容错能力：单个独立服务器部署具有低可用性的风险。一个硬件上的小问题就能导致服务器停机，这可能严重地影响依赖于数据服务的应用程序。
· 安全性：在独立的服务器中，关键数据不能与其他应用程序数据分离开来。因此，将适当的安全防范措施应用于关键任务的数据是不可能的。
方案 2 —— 多服务器部署
当将应用程序进行优化并且将硬件上扩到适当的水平时，SQL Server 2000 可以提供企业级性能。但是在数据库已经充分优化和应用程序生成超过单台服务器的功能的负载并且需要增加吞吐量的情况下，通过多台服务器外扩可能是适当的。本章“可伸缩性”一节提供了更多有关 SQL Server 外扩的信息。.
优点
多台服务器部署的优点在于，可以将 SQL Server 2000 外扩，以支持负载处理并满足大型网站和企业系统不断增长的需求。
缺点
多服务器部署的缺点在于服务器管理和维护方面的复杂性。
最佳实践推荐
除非有重要的理由进行外扩，否则一直使用独立服务器并进行上扩。
对于数据服务，重要的存储注意事项包括：
· 数据检索：为了优化性能，能够从数据储存设备快速访问和检索数据是非常重要的。如果数据检索速度慢，应用程序的性能就会下降。
· 数据增长：数据存储设备应该能够适应数据中心发展的需要。
· 数据可靠性：数据存储必须能够在磁盘或数据路径发生故障的情况下保证安全性及可靠性，这可以通过建立数据的镜像和使用从服务器到数据存储设备的冗余路径来实现。
· 数据共享：Microsoft SQL Server 2000可以部署在故障转移的集群中，这需要在多台服务器之间共享同一个磁盘驱动器，同时必须保证任何时候磁盘驱动器只属于一台服务器。
可以用于数据存储的存储技术包括 DAS、SAN 和 NAS。在以下章节中，我们将更加详细地讨论这些技术的优缺点。
方案1 —— 直接附加存储 (DAS)
DAS 直接连接到使用光纤或铜线的服务器，DAS 的例子包括本地磁盘驱动器，这种驱动器通常通过 SCSI 或 RAID （独立磁盘冗余阵列）控制器进行访问。对于 DAS，主要应该考虑到它只能从单台主机访问。
优点
使用 DAS 的优点包括：
· 性能：DAS 提供了比较好的性能，因为存储子系统的输入/输出 I/O 带宽不是在多台服务器之间共享的。
· 安全性：因为只能通过单台服务器访问 DAS 系统，所以如果对服务器的访问进行适当的控制，就可以防止未经授权的访问。
缺点
使用 DAS 的缺点包括：
· 不能进行集群：DAS 不能在多台服务器之间共享，因而不能通过群集提高它的可用性。
· 能力限制：DAS 系统有能力限制，其扩展不能超过一定的限度。
方案 2 —— 存储区域网络 (SAN)
SAN 是一种外部高性能存储系统，它允许多台计算机访问同一个存储器。SAN 控制器能够通过一个开关接受来自不同服务器的对同一个存储系统中不同逻辑卷的请求。现有存储容量从10 TB 至12 TB 的企业级 SAN。SAN 使用光纤通道连接传输数据，并且能够达到 Gigabit 的速度。通常我们称用来连接主机和存储设备的光纤和开关为 SAN 光纤。
优点
使用 SAN的优点包括：
· 可用性：通过使用穿过 SAN 光纤的多条路径，SAN 可以提高存储子系统的可用性。
· 可伸缩性：SAN 很容易进行扩展，可以扩展其光纤或存储子系统。
· 适用性：SAN 提供了一些机制，通过这些机制，不同的应用程序可以通过数据移动、数据共享或数据复制来使用数据。
· 没有网络影响：SAN 使用 LAN-free 备份，这样就可以在不影响服务器用户使用网络的情况上进行数据存档。
· 自动负载平衡：通过自动负载平衡，SAN 具有包括错误恢复、数据处理及性能管理在内的自我管理能力。
· 容错：通过利用本地和远程系统之间的同步及异步数据复制，SAN 提供了有效的应用程序恢复以及容错功能。
缺点
使用 SAN 的缺点包括：
· 复杂性：设计、操作和维护 SAN 需要专门技能。
· 费用高：与 DAS 或 NAS 相比，SAN 的费用比较高。
方案 3 —— 网络附加存储 (NAS)
NAS 服务器是一种专用存储设备，是一种经过优化的服务器，具有某种水平存储能力，并且直接与网络相连接的。因为多个计算机可以同时访问相同的 NAS 设备，所以如果同时有太多的用户访问该存储，性能就可能出现问题。然而，从数据服务的观点来看，NAS的主要问题就在于其 I/O 路径要比 SAN 长得多，这就使得 10ms I/O访问有时变得不可能，因而反过来影响了数据解决方案的性能。
优点
使用 NAS 的优点包括：
· 标准组件：NAS 是使用标准网络组件构建的，例如以太网或者其他 LAN 技术，这就使得部署 NAS 变得经济和简单。
· 灵活性：通过扩展 NAS 设备，可以轻松地将附加存储容量添加到数据解决方案。
缺点
使用 NAS 的缺点包括：
· 低性能：尽管 SQL Server 2000 可以支持 NAS 系统，但是，除非使用足够快的网络接口，否则 NAS 还是不能提供 SQL Server 要求的性能。NAS 的速度通常都受到网络接口的速度的限制。
· 隔离性：NAS 子系统可能是隔离的，这使得备份和恢复操作更加困难。
· 可管理性：因为需要增加存储空间，所以添加了额外的 NAS 设备，这导致基础结构变得更加难于管理。
对于企业数据服务而言，一般推荐使用 SAN 作为存储方案，因为它提供的存储子系统可以同时被多台主机使用，并且具有很高的可伸缩性和灵活性。
SQL Server 2000 性能主要取决于：
· 数据库设计
· 系统配置
通过良好的应用程序和数据库设计，可以达到高水平的性能，并且不需要进行额外的配置调整。如果系统配置不是很糟糕，则通过配置调整来改进性能的程度是有限的。如果需要进行一些更改，建议在任何更改之前和之后都进行严格的性能测试，以评估性能改进的程度。
糟糕的数据库设计会消耗较多的 CPU 资源，从而导致性能下降和更长的查询时间。例如，一个高度标准化的数据库将占用更少的空间，但是从多个相关表中收集信息的查询将花费更长的时间。为了改进响应时间，数据库应该标准化更少的表。
索引是数据库设计的另一关键要素。索引可以通过更快速的数据访问来提高 SQL 查询的性能，但是索引需要数据库中额外的存储空间；另外，插入、更新或删除数据命令可能花费更长的时间，因而需要更多的处理时间。为了设计一个好的索引方案，可以使用 SQL Server Profiler 来监视和记录工作负荷，然后将其提交给 SQL Server 索引调整向导 (SQL Server Index Tuning Wizard)。经常使用 SQL Server Profiler 和索引调整向导非常重要，因为整个查询工作负荷经常随着时间的改变而改变。在设计数据库时，其他一些需要考虑的事项包括：数据库活动、查询类型和数据库大小。有关设计 OLTP 和决策支持数据库的一般指导原则，请参阅：
msdn.microsoft.com/library/en-us/createdb/cm_8_des_02_62ur.asp
数据库文件注意事项
SQL Server 2000 使用两种类型的文件来存储数据库信息：数据文件和日志文件。SQL Server 可以使用多个数据和日志文件将写入分发到不同的文件中。文件组技术可以帮助将相关数据文件分到不同的组中。例如，可以根据预期的负载特征在特定的文件组中创建表和其他数据库对象。
文件和文件组的使用改进了数据库的性能，使得数据库能够受益于多个磁盘和磁盘控制器或 RAID 系统提供的并行I/O流。配置文件的一些指导原则包括：
· 自动调整大小：将日志和数据文件配置为自动增大，把初始大小和增大大小设置为尽可能大。只要 SQL Server 需要增大这个文件时，数据吞吐量将会下降，因为查询在增大阶段不能进行处理。
· 最大的文件大小：此参数应该设置为尽可能大的一个值，但是必须留有一定的空闲空间，以供交换使用。
· 磁盘驱动器分区：将数据和日志文件放在不同的磁盘驱动器中以改善SQL Server 检验点之间的性能。
有关使用 SQL Server文件和文件组的一般建议，请参阅 msdn.microsoft.com/library/en-us/createdb/cm_8_des_02_2ak3.asp 上的文章 ——“文件和文件组的使用”。
下面几节描述改进数据库性能的一些调整方案。然而，如前所述，高水平的数据库性能的关键是良好的数据库设计；其次才应该考虑系统调整。根据企业的特定数据服务要求，可以使用下列方案的部分或全部。
方案 1 —— 内存和 CPU 注意事项
在任何数据库服务器环境中，一项主要的注意事项就是 RAM 缓冲区缓存的管理。访问 RAM 缓存中的数据比从磁盘访问相同的信息快得多，但 RAM 的资源是有限的。如果能够将物理磁盘子系统的数据库 I/O 操作所需的数据和索引页面集减到最少，这些页面就可以在 RAM 中保留更长的时间。太多不必要的数据和索引信息流入缓冲区缓存将会迅速地推出有价值的页面。性能调整的着重点是减少 I/O，以最优化缓存器的使用。
SQL Server 2000 包括下列内存调整方案：
· 最小化服务器内存
· 最大化服务器内存
· 索引创建内存
· 最小化每次查询所占用的内存
这些方案可以通过 sp_configure 存储过程进行配置。有关这些方案的详细信息，请参阅 msdn.microsoft.com/library/en-us/optimsql/odp_tun_1a_2f3b.asp 上的文章 ——“优化服务器性能”。
Intel® 超线程 (Hyper-Threading) 是一种新技术，这种技术允许操作系统将一个物理处理器视为两个逻辑处理器；此功能是对允许在每个处理器上同时运行多个线程的对称多线程处理 (SMP) 技术的补充。SQL Server 2000 可以利用这些逻辑处理器的优点，而即使操作系统将一个物理处理器视为两个逻辑处理器，也只需要一个处理器许可证。SQL Server 2000 可以同时调度多个线程，以在不增加额外费用的条件下达到更好的吞吐量和性能。尽管如此，性能改进并不是双倍的；每个逻辑处理器都必须与另一个逻辑处理器共享执行资源，例如一级内存缓存。
详细信息请参阅
www.microsoft.com/windows2000/server/evaluation/performance/reports/hyperthread.asp 上的文章 ——“基于 Microsoft Windows 的服务器和 Intel 超线程技术”。
方案 2 —— 提高 SQL Server 的优先级
可以通过提高 SQL Server 的优先级来提高 SQL Server 线程的优先级。如果不加以提高，SQL Server 线程的优先级为7。而如果加以提高，SQL Server 线程的优先级则 13 (高优先级)，这可以改进只运行 SQL Server 的专用系统的性能。然而，如果服务器运行其他的应用程序，则它们的性能可能会降低。另外，在故障转移集群环境中增加 SQL Server 的优先级时需要给予特别注意。在故障转移群集环境中增加优先级会将 sqlservr.exe 进程设置为“高”优先级，它与服务器群集和服务器群集资源进程（clussvc.exe和resrcmon.exe）具有相同的优先级。这会导致在这些进程之间的线程调度中出现冲突，从而引起资源故障转移。
方案 3 —— 工作线程
SQL Server 保留了 Windows 线程池，它用于将 SQL Server 命令提交给数据库服务器。通过设置 sp_configure 选项“最大工作线程数（max worker threads）”，可以规定对所有输入命令可用的工作线程总数。如果实际提交的批连接数量大于所定义的最大工作线程数，工作线程将会在活动连接之间共享。在大多数情况下，默认的 255 将工作良好。
如果 SQL Server 托管多个数据库并且有非常多的用户尝试访问这些数据库，则配置工作线程可能特别有用。然而，将“最大工作线程数”设置得太高可能会产生过多的上下文切换并导致性能下降。
详细信息请参阅 msdn.microsoft.com/library/en-us/adminsql/ad_config_09wu.asp 上的文章 ——“最大工作线程数选项”。
方案 4 —— 物理磁盘配置
要最大化超大数据库（数百 Gigabyte）和有持续频繁读写操作的数据库的 SQL Server 磁盘 I/O性能，可以跨多个硬盘驱动器加载平衡磁盘访问。硬件 RAID 控制器将 Windows 和应用程序（如 SQL Server ）中的所有数据的读写分割成小块（通常为 16-128KB），这些小块分散在 RAID 系列的各个物理硬盘驱动器上。这种分割数据的方法可以将读/写 I/O 工作负荷均匀地分布到参与 RAID 阵列的所有磁盘中，这样可以提高磁盘 I/O 性能，因为磁盘一直保持在同等忙碌状态。 RAID 还提供对硬盘故障的保护，并且为数据丢失提供了数据镜像和奇偶校验机制。
许多硬件 RAID 控制器都有某种形式的读写缓存，SQL 可以利用这样的机制的优点，以大大增加磁盘子系统的 I/O 容量。这些基于控制器的缓存机制聚合较小的和可能不连续的来自 SQL Server 的 I/O 请求，并且在几毫秒之内将它们与其他的 I/O 请求进行批处理，这样就可以将较大的和可能更连续的 I/O 请求发送给磁盘驱动器。坚持连续且较大的 I/O 的性能更好这一原则，有利于提供更大的磁盘 I/O 吞吐量。另外，这些 RAID 控制器通常还通过某种形式的备用电源来保护它们的缓存机制，这可以帮助在电源出现故障时将数据写入缓存并保存一段时间。
方案 5 —— SQL SERVER 检查点
recovery interval（恢复间隔）服务器配置选项控制 SQL Server 2000 何时在每个数据库中发布检查点。在默认情况下，SQL Server 确定执行检查点操作的最佳时间。然而，为了确定这是否是合适的设置，可以通过 System Monitor 监视数据库文件上的磁盘写操作。如果磁盘利用率高达 100%，则性能将会受到影响。在这种情况下，将 recovery interval 参数更改为使检查点进程的出现频率降低可以改进整体性能。这对于有大量插入、更新和删除操作的高活动性 OLTP 服务器应用程序特别适用。将 recovery interval 设置为更高的数（例如 5 或 10）可以改进性能。然而，应该使用 System Monitor 来确定是否有新的值会对性能产生积极效应。详细信息请参阅 msdn.microsoft.com/library/en-us/adminsql/ad_config_70ry.asp 上的文章 ——“恢复间隔选项”。
方案 6 —— 加密文件系统 (EFS)
EFS 可以用来保护 SQL Server 数据库文件和备份。数据加密（在某些企业中是强制要求的）可能会导致性能下降。使用 EFS 对性能的影响取决于多种因素，包括硬件、磁盘速度、RAID 级别、磁盘互连以及磁盘和 RAID 缓存。性能可能会降低 25% 到 30% 之多，这取决于查询。在启用 EFS 之前，必须仔细比较和考虑它可能带有的安全利益和性能降低。
有关 SQL Server 配置设置的详细信息，请参阅 support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B319942 上的微软知识库文章 319942。
提供高可用性的数据服务是企业数据中心的核心要求之一。Web 应用程序、业务层组件和软件（如 BizTalk Server 和 Commerce Server）都依赖于数据服务。在企业数据中心中，数据服务可用性的一些关键要素包括：
· 硬件冗余：通过使用 NIC 协作（协作网络适配器）和冗余电源供应，可以获得最大的 Microsoft SQL Server 2000 可用性，它们是更加昂贵的冗余服务器的可选方案。通过将冗余路径的使用和 RAID 的正确使用（本节其他部分将对其进行详细描述）结合起来，这些方案可以把由于硬件故障造成服务损失的可能性降到最低。有关各种 SQL Sever 相关故障的详细信息，请参阅 msdn.microsoft.com/library/en-us/dnsqlpro01/html/sql01e1.asp 上的文章 ——“A Taxonomy of Database Unavailability: 18 Types of Failures”。
· 使用冗余路径来消除单一故障点：数据和服务器之间的路径应该是冗余的。应该在所有的服务器上安装多路径软件，并且应该使用开关独立的或联合的 SAN 光纤来合并服务器和存储之间的冗余。无论是发生组件故障还是路径故障，这种设计都允许进行连续操作。有关配置 SAN 的详细信息，请参阅 www.microsoft.com/windowsserver2003/techinfo/overview/san.mspx 上的文章 ——“Microsoft Windows Clustering: Storage Area Networks”的文章。
· 减少数据损失：在由于磁盘故障或病毒攻击而造成数据损失的情况下，必须有一种机制来从备份副本中恢复这些数据。对于关键数据，应该设置适当的备份计划，以确保在安全的地方总有该数据的备份。
· 日志传送：为可能使整个数据中心瘫痪的事件（如电源故障或自然灾害）作计划非常重要。为了处理这些情况，需要确保在地理上相隔比较远的数据中心中总有这些数据的副本，并且使该数据中心能够在线提供数据服务。通过实现 SQL Server 2000 日志传送可以提供这种功能。有关部署和理解日志传送的详细信息，请参阅 www.microsoft.com/technet/prodtechnol/sql/deploy/confeat/sqlha/sog/HASOG02.ASP 上的文章 ——“实现日志传送功能”。
· 正确的 RAID 配置：不同的 RAID 级别用于不同的目的，因而为数据服务选择正确的级别是十分必要的。例如，RAID 0 允许带状划分跨多个通道将 I/O 通信分发到多个磁盘，以提高性能。RAID 1 允许数据镜像提供更好的实用性，而 RAID 5 增加了奇偶校验，这样即使磁盘失效，数据仍然是可以恢复的。每种 RAID 级别都需要付出一些代价。例如，镜像意味着需要更多的磁盘空间，奇偶校验需要在 I/O 处理期间进行额外的检测。有关 RAID 级别的详细信息，请参阅 msdn.microsoft.com/library/en-us/optimsql/odp_tun_1_87jm.asp 上的文章“RAID 级别和 SQL Server"。
· 在故障转移模式下部署 SQL Server 2000：SQL Server 2000 通过使用 Windows Server 群集来维护大型网站和企业所需的高水平可用性。SQL Server 可以配置为在硬件设备或网络出现故障时让 SQL 服务自动将故障转移到群集内可用的节点上。本节的其他部分将更详细地讨论 SQL Server 群集。
地理上呈分布式的数据中心的群集：通过融入密集波分复用技术 (DWDM) 的光纤，SQL Server 可以在多个相距很远（超过 100 公里）的服务器之中进行群集。尽管从实施所需的硬件设备和工艺技术上讲，该方案是非常昂贵的，但是它可以提供从某一地点的灾难几乎瞬间恢复的功能（虽然可能会有一些性能方面的损失）。有关地理上呈分布式的群集的使用的详细信息，请参阅 www.microsoft.com/windowsserver2003/techinfo/overview/clustergeo.mspx 上的文章“Geographically Dispersed Clusters in Windows Server 2003”。
结合 Windows Server Clustering 部署 SQL Server
通过下列方法，可以结合 Windows Server Clustering 部署 SQL Server 2000。
方案 1－双节点群集
在双节点服务器群集中，SQL Server 2000 可以在主动-主动或主动-被动的模式下运行。在主动-主动模式下，SQL Server 2000 的实例运行在每个节点上，如果出现节点失效，SQL Server 服务就会转移到另一个节点上。在主动-被动模式下，只安装一个 SQL Server 的实例，如果出现节点失效，该实例就会转移到另一个节点上。
优点
使用双节点群集的优点包括：
· 主动-主动模式 —— 利用率：在这种模式下，群集中的两台服务器一直都在使用，因此服务器仅仅在出现问题时才会空闲下来。
· 主动-被动模式 —— 性能保护：在这种模式下，失效之后的 SQL Server 的性能应该和失效之前的性能一样，因为没有额外的实例运行在健康的节点上。
缺点
使用双节点群集的缺点包括：
· 主动-主动模式 —— 性能：在这种模式下，存在的风险就是，当两个 SQL Server 实例都停止在同一个节点上运行时，将会由于处理器超负荷而导致性能下降。
· 主动-被动模式 —— 未使用的能力：在这种模式下，尽管只安装了一个 SQL Server 实例被安装，但是会导致在大部分时间里处于空闲状态的冗余节点的开销。
方案 2－四节点群集
在 N+1 模式下，SQL Server 2000 可以部署在四节点服务器群集的环境中。在这种模式下，有三个节点处于活动状态，支持整个负载，而第四个节点作为热备份。在一个节点失效的情况下，第四个节点将承担失效节点处理负载。
优点
使用四节点群集的优点包括：
· 最小的冗余度：这种设计方案以最小的硬件冗余度提供了最大的可用性
· 灵活的实例配置：这种设计方案提供了运行多个 SQL Server 实例的灵活性，其中的每个实例都可以根据预期的工作负载来进行配置。
缺点
四节点聚集的缺点是在发生失效之后性能有可能下降。如果所有三个 SQL Server 都将故障转移到单个备份服务器，则这种设计可能有性能严重下降的风险（在三台服务器都失效的情况下）。
最佳实践推荐
在数据中心中，维护高可用性是必不可少的。所选择的群集方案必须是经济的，并且应该符合将停机时间减到最少的要求。在设计中是选择双节点群集还是选择四节点群集由以下因素来决定：
· 可以支持多少“备用”硬件？为了保证高的冗余度，必须准备好多个“备用”系统，以防活动节点失效，这虽然保证了高可用性，但是也付出了所有的硬件不是在所有的时间内都被使用的代价。在双节点多实例（主动-主动）群集的情况下，没有冗余度（所有的硬件在所有的时间内都被使用），并且在发生失效时其余的服务器还超负荷。
注意：如果节点在正常运行时使用一半的硬件资源，同一服务器上的两个节点的故障转移就不可能导致资源争用。
在单个实例（主动-被动）双节点群集的情况下，冗余度是 50％。四节点群集结合了高可用性和低成本的优点，它为三个活动服务器提供单个故障转移节点，这样把冗余度减低到 25％，同时也获得了相同的可用性。
· 需要多高的可用性？如果需要高可用性，就必须以冗余的形式配置更多的组件，这样才能从设计中消除单点失效。然而，在四节点群集中，故障转移遵循一个首选的故障转移顺序；如果多台服务器失效，则它们的负荷就转移到正在运行的服务器上。即使在多台服务器失效的情况下，这种配置也可以提供高可用性。
有关 SQL Server 2000 故障转移群集的详细信息，请参阅：
www.microsoft.com/sql/techinfo/administration/2000/failovercluster.asp
SQL Server 上扩设计方案
上扩允许组织通过向同一个SQL Server添加额外的资源来获得所需的服务器性能水平；通过使用高速计算 CPU 的服务器以及数量充足的 RAM 可以实现上扩。具有多处理器体系结构的机器允许将不同处理器以及相关资源分离到不同的功能单元，而不管它们是同一台服务器的不同部分的事实。这些功能单元可以容纳 OLTP 和 DTS 类型的应用程序（它们有很高的吞吐量要求）或 CPU 密集型的应用程序。
可以更换服务器的不同组件以获得高的能力和性能。选择何种系统组件来上扩取决于许多因素，包括：
· 现有系统：现有系统可能存在固有的局限性，这种局限性可能会限制上扩的机会；一般来说，这些限制都与硬件有关。例如，大多数硬件体系结构只能支持有限数量的附加处理器或内存。在某些情况下，为了获得所需的能力水平，可能有必要将整个系统替换掉。
· 瓶颈的位置：在某些情况下，因为系统中其他地方存在瓶颈，所以升级的组件不能提供所需的性能。在制订上扩的决策之前，必须通过性能分析查明问题，并找到解决问题的途径。
· 应用程序类型：选择任何上扩方案都应该与正在使用的应用程序有关。例如，企业资源规划 (ERP) 系统可能需要大的数据库引擎；与之形成对照的是，决策支持系统 (DSS) 可以对数据执行 CPU 密集型的操作。
· 预计的需求：决定要将哪个组件上扩应该考虑到目前以及将来的需求。例如，企业可以从 DAS 迁移到 NAS 以满足当前的增长需求，但是，如果数据量预计会大大增加，则 SAN 也许是一个更好的长期解决方案。
· 成本：当进行上扩时，成本是一个主要因素，特别是在需要将整个基础结构迁移到功能更强大的平台时。应该将单个功能强大的服务器的成本与多个小型服务器成本的总和相比较。除了购买成本之外，考虑与设计、实施和支持多个小型服务器而不是一个功能强大的服务器有关的费用也非常重要。
· 管理：上扩使得可以用比较少的资源构建比较强大的系统，而外扩则需要许多单独的系统来提供同样的功能。因此，上扩可以使管理费用降低。
一旦将上扩确定为企业的最佳方案，并且已经找到瓶颈，则需要确定将上扩的组件。在这个过程中，应该考虑当前的需求以及可预见的未来的需求。
下面的设计方案描述了可以升级来上扩 SQL Server 的各个组件。注意，这些方案不是彼此孤立的；一些情境可能需要这些方案中的许多或全部。
方案 1 —— 多处理器
如果应用程序的大部分工作是受 CPU 约束的，或者它的服务需要更多的处理器时间，则多处理器是一个有效的上扩候方案。SQL Server 是一种可以识别多处理器的系统，它允许使用 SMP，而 SMP 可以通过 SQL Server 设置进行操纵。
SQL Server 2000 有几个关联开关，通过这些开关，可以将功能性组件映射到一组处理器。这样的拆分可以用于处理、I/O 以及网络。各个开关通过 SQL Server 设置公开，本节后面有与此相关的内容。取决于要上扩的应用程序的特征，可以将可用的处理器分给不同的任务。
CPU 关联
在默认情况下，SQL Server 实例的每个线程都安排使用下一个可用的处理器。在 sp_configure 存储过程中定义的 CPU 关联掩码设置储可以用来将实例限制到一部分处理器，并且确保每个线程在中断之间一直使用相同的处理器。（这一设置减少了同一线程在多个处理器之间的交换，并且提高了二级缓存中的缓存命中率。）也可以使用 CPU 关联掩码设置将为操作系统进程预留的处理器中的线程排除在外。然而，必须谨慎使用这一特性，因为如果工作负荷不是平均分布的，不同的处理器上的工作负荷就不能动态平衡。
另外，可以设置 I/O 关联掩码（将其设置为 SQL Server 启动参数）来确定使用哪个处理器满足 SQL Server 的 I/O 要求。
可以定义与网络连接有关的第三个关联掩码，即关联掩码连接开关。Server Network Utility 可以用于定义 SQL Server 将侦听的协议和端口。对于Virtual Interface Architecture (VIA) 传输，需要为每个已定义的端口创建网络读取程序；这个线程可以仅限于运行在一组具有指定掩码的已定义处理器上，并且只将工作项目分布到这样的计划程序，它们运行在一组与关联掩码连接开关定义的处理器相同的处理器上。
通常，可以一起使用 CPU 关联掩码和 I/O 关联，以便分开在操作系统、SQL Server 和 SQL Server I/O 之间可以使用的处理器的数量（一般多于 16 个）。
上扩的处理器的数量也依赖于使用的操作系统，因为不同版本的 Windows 操作系统支持的处理器的数目是不同的。许多使用高速计算 CPU 的机器都可以考虑将处理器上扩；它们中的大多数都允许将处理器分成与各种配置中的 SQL 实例相关的组。处理器组通过高带宽的数据总线或者允许跳过 TCP 堆栈的系统区域网络连接起来，因而提高了处理器到处理器和处理器到内存的数据交换速度。这些组可以与不同的配置（例如单实例（主动-被动）或多实例（主动-主动））相关联。
方案 2 —— 大内存
大多数 32 位操作系统只能寻址最多 4 GB 的 RAM，而且如果实施了 /3GB 配置开关，SQL Server 可以使用多达 3 GB 的内存。然而，通过使用 boot.ini 文件中的 /PAE 开关，可以改变可寻址的内存的数量，这使得操作系统能够寻址多达4 GB 的 RAM。在设置了 SQL Server 中的 Address Windowing Extensions (AWE) 内存之后，必须为该应用程序选择最佳的最大内存，这样它就不会捕获所有的可用内存。
AWE 内存
AWE 需要专门为 AWE 编码的应用程序（例如 SQL Server 2000）。必须使用 sp_configure 中的 awe_enabled 方案配置 SQL Server 2000 中的 AWE 支持，awe_enabled 方案是在每个实例上进行设置的。在默认情况下，awe_enabled设置为 0 或 off。在 SQL Server 2000 中启用 AWE 还需要一些其他的操作系统配置。
为了能够使用 AWE，服务器硬件应该支持大容量 RAM，而且还必须在硬件兼容性列表 (HCL)中列出。
当在 boot.ini 文件中使用 /PAE 开关时，操作系统会从二级线性地址转换变为三级线性地址变换。这个额外的转换层就提供了对超过 4 GB 的物理内存的访问。因此，如果 /3GB 开关也与 /PAE 一起使用，操作系统就因严重缺乏 RAM 而求助于磁盘分页，这反过来又会影响性能。详细信息请参阅 msdn.microsoft.com/library/en-us/appendix/hh/appendix/pae_3oyn.asp 上的文章“Physical Address Extension (PAE)”。
下表概括了应该如何根据可用内存的数量配置扩展内存设置。
| 4 GB 或更少 | 4 GB 到 16 GB | 多于 16 GB |
| 启用 /3GB | 启用 /3GB | 禁用 /3GB |
|
| 启用 AWE | 启用 AWE |
|
| 启用 PAE (boot.ini) | 启用 PAE (boot.ini) |
表 2. 扩展内存配置设置
在使用 AWE 之前必须考虑以下问题：
· 如果现有超过 16 GB 的 RAM，就不应该使用 /3GB 开关。这是因为操作系统需要使用 2 GB 的内存作为其自身的功能去管理超过 16GB 的 RAM。使用超过 16 GB 的 RAM 以及 /3GB 开关将导致操作系统用于管理其配置功能的资源不足。
· 如果在启用 AWE 时不设置 max server memory 配置方案，SQL Server 2000 将仅仅保留 128 MB 给操作系统使用，这可能剥夺操作系统以及其他在同一台服务器中运行的进程的基本内存资源。
· 为了利用 AWE 内存，SQL Server 2000 必须在已经赋予 Windows Lock Page in Memory（锁定内存页面）特权的 Windows 帐户下运行。SQL Server 安装将自动赋予 MSSQLServer 服务帐户权限这种特权。
· 如果启用了 AWE，SQL Server 可能会花很长的时间启动。详细信息请参阅 support.microsoft.com/default.aspx?scid=kb;en-us;329914 上的 Microsoft 知识库文章“AWE-enabled SQL Server 2000 May Take a Long Time to Start”。
在服务器群集中，如果故障转移强制 SQL Server 实例运行在相同的服务器上，则可能会引起内存争用问题。为了防止这种情况的发生，可以设置“最大的服务器内存”配置选项，这样，所有实例的“最大的服务器内存”值的总和就少于计算机中的物理内存的数量。
有关在服务器上配置 AWE 内存的详细信息，请参考 SQL Server Books Online 中的主题“在 Windows 2000 上使用 AWE 内存（Using AWE Memory on Windows 2000）”，以及 msdn.microsoft.com/library/en-us/dngenlib/html/awewindata.asp 上标题为“Address Windowing Extensions and Microsoft Windows 2000 Datacenter Server”的白皮书。
有关各种开关（/3GB、/PAE 和 AWE-enabled）的常规讨论，请参阅 msdn.microsoft.com/library/en-us/adminsql/ad_1_server_1fnd.asp 上的文章“管理 AWE 内存（Managing AWE Memory）”。
考虑增加的内存的类型也是一个重要的问题。某些系统可能受益于直接增加 RAM 或缓存（尽管缓存的增加不能超过某些限制），这允许系统将 SQL Server 的缓存命中率增加到最大的限度。有足够的磁盘空间供 SQL Server 执行交换和分页操作同样非常重要。尽管这可能被认为是存储需求，但是在考虑系统的内存需求时，它也是一个重要的因素。
方案 3 —— 存储增强
企业可以采用任何存储解决方案来满足其当前的需求，但是存储需求将随着时间的推移而增加，以适应不断增长的数据量并保持检索和处理的速度。对于存储性能，需要需要考虑以下因素：
· 磁盘空间：磁盘空间需求将随着企业的发展而增加。选择一个在需要时能够容易地添加更多的磁盘空间的存储体系结构非常重要
· 可靠性：包含数据的磁盘应该有内置的容错功能，这样它们就不会因单点失效而导致数据丢失。可以考虑不同的 RAID 配置；RAID 5（它为数据冗余提供了最大的存储空间）可以用于大多数非关键数据，而 RAID 1+0 可以用于关键数据。
· I/O 速度：磁盘 I/O 速度是数据检索和合并最关键的因素之一。应该考虑不同的磁盘配置和控制器。还有一点应该注意，不管是否有数据复制，用于多个磁盘的单个控制器可能会形成单点失效。
· 存储的连接性：性能也取决于与存储连接的类型和带宽。以太网网络可能会允许大量的数据吞吐量，但是也会产生一些可能难以接受的时延。为了满足更高的性能需求，应该考虑更高带宽的网络，例如使用 HBA 卡和共享存储的光纤网络。
· Tempdb 大小注意事项：在 SQL Server 群集中，tempdb 文件的大小由两个互相冲突的因素决定。通常，将 tempdb 大小增加到最大的限度，以使大多数排序和相关操作更快速，并且最大限度地发挥数据库服务器的性能。然而，更大的 tempdb 文件会导致较长的故障转移时间。下面是对物理位置和各种其他的 tempdb 文件方案的一般推荐：
· 将 tempdb 文件放在快速 I/O 子系统中以确保获得好的性能。
· 将 tempdb 文件分成条带放入多个磁盘中以获得好的性能，并且使用文件组把它放在与用户数据库使用的磁盘不同的磁盘中。
· 对于大型数据库，建议将 tempdb 文件与主数据库和二进制文件分开，单独放在一组磁盘中。
· 首先将 tempdb 文件设置为适当的大小，这样，当需要更多的空间时也无需自动扩展。
· 允许 tempdb 文件按需自动扩展，这样，生成大于预期的中间结果集（存储在tempdb 文件中）的查询在完成执行之前就不会终止。
· 将文件扩大递增百分比设置为一个合理的大小，以防止 tempdb 文件按照一个太小的值扩大。如果与正在写入 tempdb 文件的数据量相比文件扩大太小，则 tempdb 文件可能需要在短期内扩展多次，这反过来会影响性能。
· 在添加更多的磁盘空间方面，DAS 有其固有的局限性，因此在应对连续的数据增长的情境时，应该考虑将 SAN 作为一个重要的方案。可以使用 NAS，但是它有网络延时的缺点；SAN 允许有专门的光纤路径，这可以提供更高的数据传输速率。
方案4 ——网络增强
在某些情况下，企业数据服务的处理器或内存组件可能是最佳的，但是在数据和存储之间或者在客户端和公开的数据服务之间的网络连接中可能会存在一个或多个瓶颈。差的性能可能是由数据总线的速度限制导致的；在这种情况下，应该考虑使用多路和允许在同一串行总线上允许存在不同的通道的新技术。Winsock Direct 受到 Windows Server 2003 的支持，并且应该看作是为了获得更好的性能而进行的网络技术升级。Winsock Direct 绕过内核网络连接层，从而加快了系统区域网络的速度。Gigabit 网卡或光纤网络也可以大大提高网络性能。
方案 5 —— 使用多个 SQL Server 实例
SQL Server的多个实例可以用于将分布在许多服务器上的数据服务合并到一个中央服务器。对于托管多个用户数相对较少的数据库的组织，这种功能特别有用。它有助于在单台服务器上支持更大的工作负荷；根据不同的性能、安全和备份要求分离数据库；基于更改控制、操作和维护要求分离数据库。
方案 6 —— 使用多个端口
在默认情况下，SQL Server 侦听用于客户端连接的端口 1433。如果连接数高，该端口就可能变成瓶颈并拒绝新的连接。在这种情况下，建议打开其他的端口供 SQL Server 使用，这样就可以在这两个端口之间分配客户端连接请求。要实现这一点，客户端必须配置为连接到不同的端口上。例如，如果要使用端口 1433 和 1533 并且有 10 个 Web 服务器访问 SQL Server，则其中 5 个 Web 服务器应该配置为使用端口 1533，另外的 5 个使用默认端口 1433，从而将通信分开。
方案 7 —— 部署 64-位 SQL Server
64-位 SQL Server 2000 最重要的优点是它支持 64-位 Windows 和硬件环境中的超大容量内存。这种对超大容量内存的支持有益于需要高度可伸缩性和性能的数据库应用程序。它特别适用于这样的应用程序：可能拥有无限数量的用户和大量用户事务的大型电子商务网站；大型数据仓库和分析应用程序；驱动高 OLTP 工作负荷的 Global Web Services。诸如此类的应用程序都是高内存密集型的，并且可能受到 32-位 平台所限定的 4 GB 可寻址内存的限制。有关 64-位 SQL Server 的详细信息可以在下列 URL 中找到：
www.microsoft.com/sql/evaluation/64bit/default.asp
SQL Server 外扩设计方案
在 SQL Server 外扩设计中，数据服务是在多台服务器上托管的。这一节将讨论使用 SQL Server 2000 设计外扩配置的一些方法。
方案 1 —— 通过 SQL Server 2000 联合进行外扩
服务器联合是一些运行 SQL Server 的服务器组，用于特定应用程序的数据分布在这些服务器上。这种技术可以用来将一个表中的处理分布到单独的服务器上的多个 SQL Server 实例中。
优点
通过 SQL Server 2000 联合进行外扩的优点是利用率的灵活性。这种方法允许不同的用户和服务组使用不同的服务器，而不对负载平衡程序进行只读访问限制（后面的部分将对此进行讨论）。
缺点
通过 SQL 2000 联合进行外扩的缺点包括：
· 数据库设计是关键：由于表架构需要遵循分布式模型，所以通过联合进行外扩需要专业的数据库设计。
· 应用程序相关性：例如，应用程序需要设计成能以分布式分区视图的方式工作。
· 不能容易地添加新的服务器：在这种设计中，添加更多的服务器可能需要重新分布数据库以优化负载分布。
· 容错能力：如果服务器出现故障，则对一组数据的访问就会失败。
方案2 —— 外扩只读 SQL Server 负载
SQL Server 2000 可以通过在负载平衡器下运行多个 SQL Server 来进行外扩，该负载平衡器根据负载平衡算法将客户端请求转发到随机服务器。实施负载平衡的方式有多种；以下部分将会介绍这些设计方案。
优点
外扩只读 SQL Server 负载针对只读数据进行了优化。此设计可以为接收大量只读点击（例如在线产品目录或参考资料库数据库）的应用程序提供优化性能。
缺点
外扩只读 SQL Server 负载的缺点是，它可能很难确保一台服务器上的更新数据将会立即复制到其他服务器上。
实际上，基于数据方面的考虑，在外扩 SQL Server 时，部署这两种方法通常都是很必要的。在大型企业应用程序中，常常同时会有可读/写数据和只读数据，这意味着有效的设计将分离读/写数据服务和只读数据服务，并把它们放在不同的服务器上。这种分离允许负载平衡服务器群以最佳方式提供只读服务，同时允许将新的服务器添加到群集中，以适应不断增长的需要。数据库中的可读/写部分可以驻留在不同的服务器群集中，以确保事务和可修改的数据的高可用性和其他安全性。
实施只读 SQL Server 负载的设计方案
要实施只读 SQL Server 负载，需要一种负载平衡机制。这部分将讨论各种负载平衡方案。
方案 1 —— 硬件负载平衡
硬件负载平衡透明地将对单个 IP 地址的客户端请求定向到一个群集中的多台主机上。硬件负载平衡器通常使用一种称为网络地址转换 (NAT) 的技术来将一个或多个虚拟 IP 地址公开给客户端，并通过转换 IP 地址和重新发送网络数据包来为主机转发数据。
优点
使用硬件负载平衡的优点是性能。硬件负载平衡器能够提供更好的性能，因为平衡完全是在网络设备内发生的。
缺点
使用硬件负载均衡的缺点包括：
· 单点故障：当使用单个硬件负载均衡器时，群集与客户端之间会存在单点故障。为了提供高可用性，需要备份负载均衡器。
· 额外费用：用于负载平衡的其他硬件会增加解决方案的成本；对于小型只读数据库实施，这是不合理的。
方案2 —— 应用程序负载平衡
应用程序负载平衡包括对应用程序进行编码，以便它可以访问分布在一组服务器中的数据库。可以使用多种分配负载的方法，算法也可以根据应用程序的不同而有所不同。最广泛使用的是轮询方法，它以重复模式将请求分配到各个节点中。然而，还有其他更复杂的方法比这种方法优越，这些方法会考虑特定节点的负载情况及其能力，以便为特定类型的请求服务。
优点
使用应用程序负载平衡的优点是可以对它进行自定义，以便满足应用程序的特定要求。
缺点
使用应用程序负载平衡的缺点包括：
· 灵活性差：这种解决方案只适用于特定的应用程序，除非对它进行编码，使之具有灵活性。
· 可伸缩性有限：难以添加或删除其他服务器，以满足不断变化的扩展要求。
方案 3 —— 网络负载平衡
网络负载平衡是一种完全分布式的 IP 级的负载平衡解决方案。它让各个群集成员同时检测定向到一个群集 IP 地址的传入通信。具有多个负载平衡 IP 地址是可能的，且负载平衡适配器上的任何 IP 地址（专用或管理 IP 地址除外）的通信都将是负载平衡的。
优点
相对于硬件负载平衡，网络负载平衡的优点包括：
· Windows Server 2003 组件：Windows Server 2003 附带网络负载平衡，不需要其他硬件或软件来实现。
· 无单点故障：这种设计可以避免单点故障，因为它是在群集中的所有主机上并行运行的。大多数硬件负载平衡器需要两个硬件单元来避免单点故障，而且第二套同样昂贵的硬件组件是在被动模式下运行的。
缺点
相对于硬件负载平衡器，网络负载平衡的缺点包括：
· 网络上的广播通信开销：网络负载平衡请求将广播到负载平衡群集中的所有服务器上，这会在服务器上生成额外的网络通信。
· 硬件相关性：网络负载平衡可能无法使用所有的网络交换类型。
对于需要经济且可扩展的负载平衡解决方案的企业数据服务，推荐的设计方案是使用 Windows Server 2003 中的内置网络负载平衡服务。
在企业中，业务需求可能要求使用 SQL Server，并以多种方式对其进行配置。对映射为业务需求的 SQL Server 特性进行正确的评估并考虑本章中的方案可以帮助您形成一个对所有企业数据要求具有足够灵活性的设计。
下图显示如何在组织中以具有高可伸缩性和可用性的方式部署 SQL Server。
图 1. 数据库逻辑设计
在本例中，使用运行 Internet Information Services (IIS) 6.0 的 Web 服务器来维护数据库中的客户端状态。周边的 Web 服务器通过内部网络访问数据服务以进行状态管理几乎是不可能的。因此，可以在周边部署一个数据库服务器，它不应该含有任何敏感信息，并且外部客户端对该服务器进行的任何访问都应该避免。
一些企业数据库应用程序需要在具有多个 CPU 和大容量内存的高端服务器上建立强大的数据库引擎来满足它们的数据需求。如上图所示，也可以通过运行负载平衡群集中的多台服务器或者通过数据库联合来扩展 SQL Server。为了实现高可用性，可以将 SQL Server 部署在故障转移群集中，以便提供持续服务（即使在硬件失效的情况下）。可以使用一个独立的低端维护服务器来管理和监控数据库服务器。
数据服务的硬件要求随着可用性、可伸缩性和存储优先级而改变。SQL Server 2000 可以运行在低端服务器上，也可以运行在具有多个 CPU 并支持大容量 RAM 的高端服务器上。下面的列表概述了实施企业数据中心中数据服务的硬件要求：
· 服务器：需要提供数据服务所需的服务器的数量因性能要求和负载特征而异。为了实现高可用性，可以在 Windows 服务器集群模式下安装数据服务，以便提供故障转移支持。为了获得更好的性能，可以通过添加 RAM、CPU 或更多的存储器来扩展数据服务。为了分布负载，可以通过数据联合或者通过在一个负载平衡集群集内运行 SQL Server 的多台计算机外扩数据服务。
· 内存和 CPU：Windows Server 2003 Enterprise Edition 可以使用 8 路服务器和多达 32 GB 的 RAM。Windows Server 2003 Datacenter Edition 可以安装在 32 路服务器上，RAM 多达 64 GB。对于需要高级别 CPU 和数据缓存以便为 OLTP、DTS 或 OLAP 工作负载提供更好的吞吐量的应用程序，可以将 SQL Server 2000 配置为使用 32 路服务器和高达 64 GB 的 RAM。在一些多处理器的计算机上，不同的处理器组可以映射为不同的数据库进程，例如 I/O、处理和服务中断。
· 存储：如果合理地配置内存、CPU 和存储子系统，SQL Server 2000 可以支持千兆字节大小的数据库。推荐使用 SAN 来提供稳定的高端存储，因为它们可以托管可能达到千兆字节大小的超大型数据库，而不损害数据安全标准和检索速度。SAN 还可以将数据与处理分开，这使得对数据的管理更加自由。要提高可用性和性能，必须用 RAID 1+0 配置 SAN；此配置提供磁盘错误镜像，并为快速读写数据进行带状划分。
· 网络：网络的使用取决于应用程序的数据需求。尽可能地外扩网络通信（包括使用用于不同类型的网络通信的独立 VLAN）是有利的，这有助于提供更好的维护、吞吐量和更大的安全性。通常，在数据服务中，推荐使用以下网络段：
1. SQL 前端：该 VLAN 对使用数据服务的客户端公开。它们的请求通过外部网络路由到数据服务 VLAN。
2. SQL 后端： 该 VLAN 主要用于管理以及复制和更新数据。
3. 心跳：该专用网络允许服务器集群集的节点之间进行通信。
4. 管理：该网络段用于监视和管理 SQL Server。
5. SAN 连接性：为了实现更快的数据访问， 应该使用光纤网络来连接 SQL Server和 SAN。为了保证可用性，应该在容错和负载平衡模式下配置和使用指向存储的多个路径。在 Windows Server 2003 中，Microsoft 已经开发并向厂商提供了一个多路径驱动器以替代定制驱动器。该驱动器将作为各个厂商产品的一部分附带提供，预计 Microsoft 支持的所有厂商产品都将提供该驱动器。然而，厂商在对它们进行认证并将其列于 HCL 中之后，仍然可以继续使用他们自己的驱动器。
大多数企业环境要求数据是高度安全的，包括防止未经授权的访问。这一部分描述如何设计数据中心环境中的 SQL Server 数据库安全性。
以下安全性指导原则适用于运行 SQL Server 2000 的服务器。同时还描述了特定于解决方案组件的安全性设置。
SQL Server 2000 支持两种形式的用户身份验证：
· 集成 Windows 身份验证
· SQL Server 登录
在默认情况下，SQL Server 2000 配置为只支持 Windows 身份验证，不过，可以通过启动混合模式身份验证将服务器配置为同时支持 Windows 和 SQL Server 登录。
Windows 身份验证模式通常比混合身份验证模式更安全，因为它可以利用 Windows Server 2003 支持来进行密码加密、审核和安全性策略（例如最小密码长度和密码期限）。混合模式主要用于提供向后兼容性或者在比 Windows 2000 更早的操作系统上安装 SQL Server 2000。对于大多数应用程序，建议将 SQL Server 2000 配置成 Windows 身份验证模式，以便提供最高级别的安全性。如果要配置的应用程序需要或依赖于 SQL Server 登录，则必须使用混合模式验证。
应该通过属于 sysadmin 角色的组授予 SQL Server 的管理员以 Windows 组成员身份访问 SQL Server 的权限。然而，这种方法有一个潜在的问题；Windows 管理员可以授予 SQL Server 2000 任何 sysadmin 权限，因为它们可以将任何用户添加到适当的 Windows 组。如果一个组织已经设置，因而 Windows 管理员没有能力给 SQL Server 分配 sysadmin 访问权限，则应该只将单个 Windows 帐户分配到 sysadmin 的角色。
不管哪种情况，系统管理员 (SA) SQL Server 帐户都不应该用于日常管理。相反，应该使用特定管理功能（例如备份数据库或管理帐户）的角色。应该给 SA 帐户分配一个难以破译且锁定在一个只限紧急访问的安全位置的密码；这主要是因为将安全模式从 Windows 身份验证模式更改为混合模式只需在注册表中进行少量更改。如果 SA 密码为空（即默认安装时的设置）或是弱密码，则入侵者（或 Windows 管理员）就能够获得服务器的访问权限。有关降低此类攻击可能性的方法的信息，请参见下面的“注册表注意事项”部分。
NTFS 文件权限应该适用于所有数据库的数据和日志文件，并且 SQL Server 2000 配置使用的用户帐户必须对数据库文件具有完全控制权限。所有 SQL Server 2000 文件，包括可执行文件和动态链接库 (DLL)，都配置为不允许用户进行操纵。这些文件的权限应该设置成 SQL Server 帐户、管理员组和本地系统帐户可以完全控制。同时不应该再设置其他权限。
为了保护 SQL Server 2000 的安装免受对物理服务器具有登录权限的用户的攻击，建议在注册表项中使用以下 Windows 权限来配置 SQL Server 2000。下面的所有项都是受保护的：
· HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/MSSQLServer（用于默认实例）
· HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Microsoft SQL Server/Instancename（用于命名实例）
应该删除该项中的“所有人”组权限，同时应该为“管理员”组、本地系统帐户或 SQL Server 服务帐户添加完全控制权限。在安装的过程中，安装程序会自动为所选的服务帐户执行这些操作。
如果 SQL Server 的管理员想要阻止 Windows 管理员访问正在运行 SQL Server 的计算机，则在注册表项中设置权限就显得特别重要。在这种情况下，SQL Server 管理员应该对注册表项拥有所有者权限，并删除管理员组的权限。然后强制要求服务帐号拥有完全控制权限；虽然这并不能阻止管理员获得访问权限，但是允许 SQL Server 管理员知道 Windows 管理员是否对安全构成威胁、以及何时构成威胁。
SQL Server 2000 使得在 Windows 事件日志中审核服务器登录成为可能。审核级别可以使用SQL Server Enterprise Manager 或 xp_loginconfig 扩展存储过程进行配置。
可能的审核设置如下：
· 无：不记录审核信息。
· 成功：只记录成功的登录。
· 失败：只记录失败的登录。
· 所有：同时记录成功和失败的登录。
失败设置是最低限度的推荐审核设置。如果安全性要求非常高，则所有的登录（成功和失败登录）都应该进行审核。审核信息写入 SQL Server 2000 错误日志中。
备份 SQL Server 数据的推荐步骤如下：
1. 使用 SQL Server 2000 备份数据文件。
2. 使用 Windows Server 2003 备份程序将备份文件复制到所需的媒体上。
SQL Server 2000 允许为单个备份或备份媒体集指定一个密码；如果没有此密码，数据库还原就会失败。通过使用此项功能，可以防止备份未经授权恢复。
理解数据本身并没有进行加密非常重要；因此，备份媒体必须在物理上是安全的并且离站存储。备份数据文件应该放在具有目录权限的 NTFS 分区中，以防止普通用户访问。
删除或拒绝对服务器上的每个数据库中的来宾帐户的访问非常重要。所有具有有效的 SQL 登录帐号的用户都可以访问允许来宾帐户访问的任何数据库。只要来宾有权访问数据库，就不必显式地授予 SQL 登录权限。
只要有可能就应该限制物理访问。未经授权的物理访问的一个风险是入侵者可以通过软盘启动服务器并访问 Windows 文件系统。关键任务的产品数据库服务器必须在物理上是安全的。
为了能够后向兼容，SQL Server 2000 支持在数据库内使用用户帐户别名。这种方式允许多个登录共享同一个数据库用户帐户，从而可以更容易地管理大量用户的数据库对象权限。在 SQL Server 2000 数据库解决方案中，使用角色更好，因为它比别名更强大并且具有相似的管理优势。在 SQL Server 2000 中不需要使用别名，而且应该尽可能地避免使用别名。
安全套接字层 (SSL) 协议可以保护客户端（直接调用程序）和 SQL Server 2000 之间的通信链接的安全。当 SQL Server 配置为使用 SSL 时，客户端和服务器之间（反之亦然）传输的所有数据都进行加密。加密强度取决于为 SQL Server 安装的证书所授权的密码功能以及客户端和服务器的加密功能。为 SQL Server 选择的证书必须以完全限定域名 (FQDN) 的形式指派给服务器名称，例如 SQLServer1.na.wingtiptoys.com。有关使用 SSL 来保护与 SQL Server 2000 的通信的详细信息，请参见
msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT19.asp 上的“How To: Use SSL to Secure Communication with SQL Server 2000”。
客户端也可以请求对 SQL Server 的所有数据通信进行加密。此方案是通过使用带有Force Protocol Encryption方案的 Client Network Utility 设置的，它适用于来自该计算机的所有出站连接。此方案也可以通过数据库服务器的 OLE DB 或 ODBC 连接中的 Encrypt=yes 方案来程序化地设置。
也可以使用 Internet 协议安全 (IPSec) 来保护两台计算机（例如应用程序服务器和数据库服务器）之间的数据传送。IPSec 对应用程序是完全透明的，因为加密、完整性和身份验证服务都是在传输层上实现的。有关如何在数据库和客户端之间配置 IPSec 的详细信息，请参见 msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT18.asp 上的“How To: Use IPSec to Provide Secure Communication Between Two Servers”。
然而，启用加密总是安全和性能之间的一种平衡，因为加密和解密会带来了额外的开销。
SQL Server 2000 数据文件可以通过 Windows Server 2003 EFS 进行保护。该数据文件是通过服务帐户进行加密的。
如果服务帐户需要更改，则必须首先解密该文件，更改 SQL Server 服务的服务帐户，然后用新的服务帐户对文件重新加密。如果这些更改没有全部进行，则 SQL Server 可能就不能启动，因为它不能解密用以前的服务帐户凭证加密的文件。
典型的企业包括许多安全边界。必须根据数据的敏感性将数据放在合适的安全边界内。有高安全性和一致性要求的数据（例如 HR 数据库中的雇员记录）应该存储在位于网络中最安全的部分的服务器上。应该阻止从较低安全区域（例如周边网络）对这些数据的访问。如果需要，外部访问应该通过身份验证机制（例如安全 Web 服务）进行。
已经为 SQL Server发布了一些服务包和安全补丁，以应对各种漏洞。要获得最新的补丁，请访问“热修补和安全公告服务”页面，地址在 www.microsoft.com/technet/security/current.asp?productid=30andservicepackid=0 。搜索SQL Server 2000 的所有服务包，可以下载它们，并且根据各自的 Readme 文件中的说明进行安装。
使用 Microsoft Baseline Security Analyzer (MBSA) 工具可以识别服务器的当前补丁状态以及常见的安全错误配置。目前，该工具不受 Windows Server 2003 的支持，但是可以用它来识别常见的 SQL Server 相关漏洞。该工具可以从 www.microsoft.com/technet/security/tools/Tools/MBSAhome.asp下载。
也可以从www.microsoft.com/sql/downloads/securitytools.asp下载其他各种 SQL 安全工具。
Kerberos 和委派
为了跨服务器访问数据，Microsoft SQL Server 2000 可以使用 Windows Server 2003 安全子系统来将 Windows 登录凭证传送到 SQL Server 的其他实例（如果该数据库服务器已经启用了 Kerberos 支持的话）。此功能可以帮助 SQL Server 实例跟踪和审核正在执行查询的用户。如果没有通过 Kerberos 进行这种委派，数据库管理员就需要创建一个通用登录来从其他实例进行连接。有关 SQL Server 安全帐户委派的详细信息，请参考
msdn.microsoft.com/library/en-us/adminsql/ad_security_2gmm.asp
安装后，Microsoft SQL Server 和Microsoft SQL Server Agent 服务就会启动。这些服务会出现在“服务控制管理器”对话框中的已安装服务列表中，可以通过 Windows 控制面板进行访问。下表显示了每个服务的名称、以及当 SQL Server 的默认和指定的实例出现在“服务”对话框中时引用它们的术语。
| 服务 | 名称 | 默认术语 | 指定实例的术语 |
| Microsoft SQL Server | SQL Server | MSSQLSERVER | MSSQ$InstanceName |
| Microsoft SQL Server Agent | SQL Server Agent | SQLSERVERAGENT | SQLAgent$InstanceName |
表 3. SQL Server 服务帐户信息
这两个 Windows 服务需要一个将在其特权下运行的用户帐户。SQL Server 和 SQL Server Agent 服务可以配置成使用本地系统帐户、本地用户或域用户帐户。这两个服务都可以配置成使用相同的 Windows 用户帐户。但是，为了能够更好地控制数据和操作访问，建议所有的服务帐户都不同。
要使 SQL Server 2000 正确地执行任务，必须为服务帐户设置下列权限（由安装程序自动分配）：
· 对 SQL Server 目录（默认为 /Program Files/Microsoft SQL Server/MSSQL）具有完全控制权限。
· 对所有 .mdf、.ndf 和 .ldf 数据库文件具有完全控制权限。
· 对与 SQLAgent$InstanceName、MSSearch 和 MSDTC 相对应的注册表项具有读写权限。
· 对
HKEY_LOCAL_MACHINE/Software/Microsoft/MSSQLServer
HKEY_LOCAL_MACHINE/System/CurrentControlset/Services/MSSQLServer
或者（对于命名实例）
HKEY_LOCAL_MACHINE/Software/Microsoft/Microsoft SQL Server/InstanceName
HKEY_LOCAL_MACHINE/System/CurrentControlset/Services/MSSQL$InstanceName
注册表项及其下的注册表项具有完全控制权限。
对于 SQL Server 2000 中的用户帐户，有几个可用的方案。以下部分对这些方案进行讨论。
方案 1 —— 本地系统帐户
如果没有为复制配置运行 SQL Server 的服务器并且不需要访问网络资源，则可以使用本地系统帐户。
方案 2 —— 本地用户帐户
此方案与使用本地系统帐户有相同的限制，但是它可以提供其他级别的安全性，因为本地用户具有比本地系统帐户低的特权。但是，此方案有以下要求：
· 用户帐户必须授予“Log On As A Service”权限（安装程序默认授予此权限）。
· 对于其他功能，包括运行扩展存储过程（例如 xp_sendmail 和 xp_cmdShell），或者在 Windows Server 2003 Active Directory 中添加或删除 SQL Server 对象，则需要其他权限。
方案 3 —— 域用户帐户
域用户帐户提供了最大程度的灵活性并且减少了多服务器环境中的管理开销。一些功能只有在使用域用户帐户时才可用，例如：
· 复制
· 备份到网络驱动器以及从网络驱动器恢复
· 执行需要远程数据源的异类联接
· SQL Server Agent 邮件功能和 SQLMail
· 远程过程调用
· 需要远程数据源的异类联接
SQL Server 的每个实例都在服务器上安装了一个单独的 Windows 服务。根据需要的功能，这些服务可以配置为在不同的域帐户下运行。
这一部分讨论针对 Microsoft SQL Server 2000 的管理相关问题。随着需求的不断扩大，为了维护数据服务的传送，数据库管理员经常必须执行大量任务。有关 SQL Server 2000 的操作和管理的详细信息，请参阅：
www.microsoft.com/technet/prodtechnol/sql/maintain/operate/opsguide/sqlops4.asp
数据服务可管理性设计假定企业生产环境中的数据库服务器必须向大量客户端提供高吞吐量。这样的生产服务器参与日常的管理活动的效率可能很低，这就是为什么应该考虑对数据中心的所有执行监控和管理任务的原因。这台服务器也可以用来执行备份和还原工作、以及运行数据库一致性检查 (DBCC)。此外，可以创建一个独立的管理网络来执行管理任务以及将管理流量从客户端网络通信中分离出来。可以使用一个功能较弱的服务器来执行管理任务，但是此服务器需要本章“系统管理”部分中描述的所有 SQL Server 工具。
这一部分描述了与 SQL Server 2000 相关的一些管理功能。
更改管理需要管理对 Microsoft SQL Server 2000 环境的任何部分（包括数据库代码、对象、系统进程、服务器配置以及硬件）的更改。此外，更改管理确保将正确的服务包和热修补应用于系统。所有与数据库相关的更改，包括创建新的数据库以及将新的数据库对象添加到现有数据库，都应该通过更改管理系统完成。该更改管理系统也必须确保对该系统的任何更改，例如添加或删除表格，都不会中断数据复制、应用程序交互或数据备份。最好有一个分段或开发环境，从而可以在生产服务器中实现更改之前将其在此环境中进行应用和测试。
安全性管理涉及用户和帐户管理、密码实践以及权限和角色的使用。如果没有加入安全管理组，就不能在具有访问 SQL Server 的权限的域群中添加新用户。应该定期执行安全审核以确定是否有违反安全或恶意攻击的情况，从而隔离导致任何这样的事件的因素，以防它们再次发生。安全管理还可以确保服务器在物理上是安全的，未经授权的人无法接触到。
系统管理包括与系统有关的各种任务，例如数据备份和还原、建立 SQL Server 复制、以及监控系统。系统管理员负责执行系统审核以及预防可能会造成问题的隐患。此外，他们还要执行每天、每周以及每月的任务，例如确保 SQL 服务正在运行、分析事件日志、运行 DBCC、执行事务日志备份以及收集性能统计信息。
容量管理任务包括配置和维护用于数据服务的硬件，以获取最好性能和吞吐量，这需要对所使用的硬件有很好的理解、记录系统的性能、监控数据库性能、以及规划未来的硬件需求。作为能管理管理的一部分，我们需要预测数据库的扩大情况，使附加的存储可用并且添加更多的 RAM 和处理器，以满足吞吐量需求的增长。
问题和事件管理涉及故障诊断以及 SQL Server 相关问题的解决。这些问题可能源自很多方面，包括应用程序设计、SQL Server 配置或编写不良的代码。问题和事件管理还涉及收集和分析故障现象以隔离问题、解决问题以及实施解决方案。一些在实际中反复出现的问题可能需要使用分段或测试环境来进行适当的故障诊断。
SQL Server 管理涉及许多任务。由单个用户或单种权限执行所有的任务通常是不可能的。此外，基于安全的考虑，也不建议用同一个帐户执行所有的管理任务。而是应该创建一个独立的域组，并将其添加到 SQL Server 角色中以获得需要的权限。
下表描述了执行 SQL Server 管理任务需要的各种用户角色。这些角色通过 Microsoft Operations Framework (MOF) Team Model 映射到“角色群”，该模型可以在如下地址找到：www.microsoft.com/business/services/MOFteam.asp。
| MOF 角色群 | 角色名称 | 角色职责 | Active Directory 权限 | 其他权限/能力 |
| 安全性 | 数据库管理员 (DBA) | 检查并跟踪添加到具有任何 SQL Server 权限的域群中的用户。 为 SQL Server 用户设置密码期限策略。 执行严格的密码策略。 执行安全审核。 确保服务器物理上的安全。 | 需要在 Active Directory 中创建一个名为 GP_SQLSecurity 的独立组来为此角色管理用户。 | 服务器的本地管理。 GP_SQLSecurity 组应该是 SQL Server securityadmin 固定服务器角色的一部分。 |
| 版本 | DBA | 应用热修补和 SQL Server Service Pack。 创建新的数据库。 向现有的数据库添加数据库对象。 确保对数据库的任何修改都不会破坏现有的系统。 执行批量加载。
| 需要在 Active Directory 中创建一个名为 GP_SQLChangeMgmt 的独立组来为此角色管理用户。 | 服务器的本地管理。 GP_SQLSecurity 组应该是 SQL Server dbcreator 和 bulkadmin 固定服务器角色的一部分。 |
| 操作 | DBA | 执行系统相关任务，例如数据库的备份和复制的建立。 招待系统审核。 执行每日、每周及每月的例行任务。 | 服务器的本地管理。 需要在 Active Directory 中创建一个名为 GP_SQLOps 的独立组来为此角色管理用户。 | 服务器的本地管理。 用户组 GP_SQLOps 应该有 SQL Server sysadmin 固定服务器角色。 |
| 支持 | DBA | 寻找针对反复出现的问题的解决方案。 调试与性能相关的问题。 确保添加新的组件（数据库对象）不会破坏系统。 | 服务器的本地管理。 需要在 Active Directory 中创建一个名为 GP_SQLSupport 的独立组来为此角色管理用户。 | 用户组 GP_SQLSupport 应该有 SQL Server processadmin 和 setupadmin 固定服务器角色。 |
| 基础结构 | DBA | 确保网络的安全。 添加更多内存、CPU 或 SAN 存储器以满足数据增长的需求。 维护系统性能记录。 更改 SQL Server 设置，例如 AWE 内存和最小或最大内存设置。 | 服务器的本地管理。 需要在 Active Directory 中创建一个名为 GP_SQLInfrastructure 的独立组来为此角色管理用户。 | 用户组 GP_SQLInfrastructure 应该有 SQL Server serveradmin、processadmin、diskadmin 和 setupadmin 固定服务器角色。 |
表 4. 用于管理 SQL Server 的用户角色
这一部分通过各种可用于监控性能计数器、控制 SQL Server 资源的再分配和其他维护活动的工具来分析基于 SQL Server 的解决方案的管理需求。可以从维护服务器远程运行 SQL Server 工具来监控和跟踪 SQL Server 2000 应用程序,而不需要登录到运行 SQL Server 的生产服务器。
System Monitor 用于测量 CPU 活动、I/O 活动和内存的使用情况，以帮助查找瓶颈，并计划采取适当的行动来处理出现的任何问题。SQL Server 性能监控器中的一些主要计数器包括：
· Percent User-Time—Processor Object：此计数器给出处理器每秒钟的利用率。如果处理器的利用率持续保持在 80％ 以上，则有可能是 CPU 瓶颈。造成 CPU 瓶颈的原因包括：
SQL 语句数目和类型。
JOIN 操作数量和类型。
排序操作数量。
· Disk Transfers Per Second—Physical Disk Object：此计数器用于监控磁盘的活动。下面是造成大量磁盘活动从而引起 I/O 瓶颈的可能原因：
物理数据模型设计。例如，数据和索引文件的数目。
RAID 配置。例如，存储集数量。
逻辑数据模型。例如，分区。
SQL Server 语句。例如，事务设计。
· Buffer Cache Hit Ratio—Buffer Manager Object：此计数器测量在数据缓存中的而不是从磁盘读取的数据页的百分比。数据缓存是 SQL Server 2000 最重要的一个方面。
建议缓存利用率在 95％ 以上。如果监控值明显偏低，则应该：
检查 SQL Server 2000 中 max-server-memory 参数的配置。
添加更多内存。
SQL Profiler 用于查找关键的 SQL Server 语句和测量调整干预的影响。使用 SQL Profiler，可以监控单个 SQL Server 语句运行的时间。要弄清楚关键SQL Server 语句的性能，应该首先关注持续时间、读、写和 CPU 测量。SQL Profiler 允许添加各种对 SQL Server 的性能和瓶颈诊断非常关键的计数器。它也允许进行安全性审核和其他审核。
SQL Query Analyzer 用于查看查询执行计划并观察干预。此工具提供的信息有助于设计更有效的查询。
SQL Server 2000 Enterprise Manager
SQL Server 2000 Enterprise Manager 是 SQL Server 2000 附带的一种 Microsoft Management Console (MMC) 实用工具。它可以用于控制数据库和 SQL Server 设置、以及提供对 SQL Server 日志的轻松访问。
日志
Windows Server 2003 和 SQL Server 2000 提供了大量日志，它们可以用于诊断和解决问题。可以使用的主要日志有：
· 事件日志：此日志提供对所有可能引起关键条件出现的事件的历史的访问。可以扫描事件日志以查找操作系统安全和系统事件，然后可以把它们用于审核的目的。
· SQL Server 日志：这些日志可以从 SQL Server 2000 Enterprise Manager 访问。它们记录了属于 SQL Server 实例的所有事件，并且可以用于通过比事件日志更大的粒度诊断问题。应该尽早地改正具有 19-25 严重级别的错误。
· SQL Server Agent 日志：此日志可以用于检查应用程序的关键事件。
· 其他日志方案：其他日志方案可以通过数据库应用程序进行选择，这样管理人员就可以监控关键变量。
SQLDiag 实用程序
sqldiag 实用工具生成一个带有 SQL Server 实例的所有规范的文件。此实用工具收集和存储诊断信息以及查询历史跟踪的内容（如果正在运行的话）。输出文件包括错误日志、sp_configure 的输出以及附加的版本信息。如果在运行查询历史跟踪的同时调用此实用工具，则跟踪文件将包含最近的 100 个 SQL 事件和异常。
Microsoft Operations Manager (MOM) 是一个企业级的监控工具，它可以用于定义标准健康监控和维护系统。MOM 将某些计数器视为集中式监控系统的一部分，并根据响应定义采取适当的行动。某些管理任务（例如系统硬件规范的生成和配置）的详细信息应该使用 Windows Management Instrumentation (WMI) 的接口来执行，这是非常重要的，因为一旦发生硬件故障，它就成为故障管理的不可缺少的一部分。
数据服务器可以连接到基础结构的不同部分中的 MOM 服务器，用于持续监控不同 SQL Server 数据库的关键参数。在这样的环境中，每个运行 SQL Server 的服务器也运行 MOM 代理，从而允许将该服务器上的事件周期性地传输到中央 MOM 服务器。一旦 MOM 服务器不可用，MOM 代理就会缓冲事件和跟踪日志，直到 MOM 服务器可用为止。
Microsoft SQL Server 2000 SP3 提供了一种新的错误报告功能。该功能可以在安装 SP3 时启用，或者在安装之后通过 SQL Server 2000 Enterprise Manager 中的“服务器特性”对话框或 SQL Server 2000 Analysis Manager 中的“服务器特性”对话框启用。如果启用了该功能，则 SQL Server 会这样配置，一旦数据库引擎、SQL Server Agent 或 SQL Server Analysis Services 中出现致命错误，它就会自动通过安全 (HTTPS) 连接向 Microsoft 发送一个报告。组织可以设置自己的“公司错误报告”，并配置 SQL Server 来向其发送错误报告。详细信息请参阅oca.microsoft.com/en/Cerintro.asp 中的“公司错误报告”。
服务器合并可以减少提供数据服务所需的物理设备的数量，从而获得更好的投资回报和服务质量。服务器合并也有助于降低维护和管理数据服务的成本，尤其是在企业数据中心中。此外，服务器合并也有利于：
· 标准化
· 提高计算资源的利用率
· 减少设备空间
· 更好的安全性
· 因共享信息而带来的更好决策
· 简化操作、管理、备份和恢复、安全以及灾难恢复
· 服务器合并需要考虑操作、维护以及所需的系统性能级别的成本。
SQL Server 合并可以通过在同一台服务器上运行多个 SQL Server 实例、或者将 SQL Server 数据库合并到同一个 SQL Server 实例来实现。
这一部分提供了 SQL Server 合并的一般指南；各个用户的 SQL Server 2000 合并策略可能不同，因为它对所使用的数据库应用程序信赖性很大。例如，如果一个应用程序涉及高级别的 OLTP 工作负载，则在同一个 SQL Server 实例上合并多个数据库可能就不是一个好主意。在这种情况下，更好的选择是在同一台服务器上运行多个 SQL Server 的实例。
方案 1 —— 在同一台服务器上运行多个 SQL Server 实例
Windows Server 2003 操作系统的单个实例可以支持多达 16 个 SQL Server 2000 实例。每个 SQL Server 实例都作为一个独立的进程运行并要求有供自己使用的系统资源（例如内存和 CPU ）。在同一台服务器上运行多个实例有助于减少管理、操作、空间、供电和许可的成本。SQL Server 设置（如处理器关联、最小和最大内存以及工作线程数）可以用来配置每个实例，以获得跨服务器的最大吞吐量。
通常，添加更多的 RAM、CPU，采用多个网络适配器和 SAN 连接要比购买一个托管 SQL Server 2000 的独立服务器便宜。在 Windows Server 2003 中，可以使用卷装入点来避免 Windows 2000 中的 23 个驱动器号的缺陷。单许可的 Windows Server 2003 支持大内存（64 GB 的 RAM）和 32 个处理器，因而可以对系统进行扩展，以便为 SQL Server 的所有单个实例提供足够的硬件资源。
运行多个 SQL Server 实例有如下好处：
· 共享资源：当单个 SQL Server 实例托管多个数据库时，数据库可能会争用分布在所有数据库中的共享资源（例如锁和闭锁）。因此，取决于数据库活动，一个数据库可能获取这些资源中的更高比例，并导致其他数据库的运行效率低下。将数据库分成多个实例使得可以创建更多共享资源，从而带来更好的资源管理。
· 动态内存管理：当 SQL Server 的多个实例运行在同一个计算机上时，每个实例独立使用动态内存管理的标准算法。分配给每个实例的内存数量取决于实例的相对工作负载。这种设计确保较高工作负载的实例能够获得较多的内存，而处理较低工作负载的实例获得较少的内存。然而，当运行很多实例时就没有足够的物理内存来满足所有实例的需要。SQL Server 的实例会开始争用有限的可用内存，并且需要花费很长时间才能达到平衡。在这些情况下，使用静态内存分配能够保证最初分配给实例的内存大小合适并能提供较好的性能。每个实例所需的准确内存大小必须随着工作负荷的改变而不断计算。在多个实例中分配内存的最好方式是静态和动态结合的内存分配方法。为每个实例预留合理且最小数量的服务器内存可以减少实现平衡的开销。保留最大的服务器内存开放使得实例可以根据自己的工作负载来动态地调整内存分配。需要更多内存的 SQL Server 实例可以使用 SQL Server AWE 内存设置。
· CPU 关联：在默认情况下，SQL Server 实例的每个线程都被安排使用下一个可用d的处理器。CPU 关联掩码设置可以用于限制一个实例只使用 CPU 的一个子集，并且确保每个线程在中断间总是使用同一个处理器。然而，应该仔细地使用 CPU 关联设置，因为如果每个实例的工作负载不平均，则不同 CPU 的工作负载就不能动态平衡。本章的“设计 SQL Server 上扩的设计方案”部分更详细地讨论了 CPU 关联。
· 提高的安全性：多实例配置提供了隔离用户的能力以及将用户组织在需要对数据进行更小粒度的访问的组中的能力。每个实例都应该有自己的服务器角色和登录。在同一台机器上运行多个 SQL Server 实例的能力允许每个实例以不同的帐号运行。每个实例都需要不同用户集的应用程序也可以利用这种能力。通过运行多个实例来合并 SQL Server 2000 对于有多个 CPU 并且支持大量内存的高端服务器尤其有用。使用前面讨论的 SQL Server 设置，每个 SQL Server 实例都可以根据其需要分配硬件资源，从而允许不同类型的数据库应用程序（例如 OLTP 和决策支持数据库）合并在一台服务器上。
· 对于某些应用程序可以获得更好的性能： 一些 Microsoft 产品（例如 BizTalk Server）需要维护应用程序状态。许多在这样的数据库中进行插入、删除和更新操作使用大量 SQL Server 共享资源。多实例配置避免了在频繁使用数据库的应用程序中发生死锁，从而获得了更好的吞吐量并提高了性能。
在同一个数据库上运行多个 SQL Server 实例可能会带来 SQL Server 成为其所有实例的故障点的风险。托管所有实例的服务器出现问题会导致所有数据库同时出现故障。应该考虑网络适配器组、磁盘镜像 (RAID 1+0) 以及冗余电源供给，以便为服务器提供最大的容错能力。服务器群集可以在可用性方面提供更好的解决方案。有关使用多个实例来提高性能的详细信息，请参阅 www.msdn.microsoft.com/library/en-us/dnsql2k/html/sql_asphosting.asp 上的“Microsoft SQL Server 2000 Scalability Project—Server Consolidation”文档。
方案 2 —— 合并相同的 SQL Server 实例上的数据库
取决于数据库活动，多个数据库可以在 SQL Server 的单个实例上进行托管。一个 SQL Server 实例可以托管多达 32,767 个数据库，它们的结构和数据可能完全不同。这有助于减少管理和操作的成本，而且同时提高硬件的利用率。
在将数据库合并到单个实例之前，应该进行 SQL Server 数据库分析以确定合适的合并候选者。可以采用本章的“系统管理”部分所讨论的各种工具，通过监控数据库来进行这种分析。带有争用资源的数据库不能合并。例如，两个 OLTP 数据库不应该合并在一起，因为它们都可能争用共享的 SQL Server 资源。但是，一个 OLTP 数据库可以与静态只读数据库合并在一起。
应该执行数据库安全策略以防止数据被非授权访问。可以使用 SQL Server 固定数据库角色来限制用户或域组访问数据库。例如，可以通过将一个用户组添加到 db_datareader 固定数据库角色中，以使它具有对一个数据库的只读访问权限。通过适当的配置，也可以限制用户访问任何其他数据库。
本章的“可伸缩性”和“性能”部分所讨论的 SQL Server 配置设置可以为 SQL Server 提供合适的资源。因为可能有许多用户同时访问数据库，所以增加 SQL Server 的工作线程可以缩短响应时间。必须注意将数据库文件扩展到不同的磁盘驱动器，这样可以改进磁盘的 I/O 效率。每个数据库的日志和数据文件都应该保存在不同的磁盘驱动器上。如果一个数据库表需要不断的更新，则也应该将其部署在单独的文件组中。
优点
合并同一个 SQL Server 实例中的 SQL Server 数据库可以简化安装、配置、维护、调整和管理。
缺点
合并同一个 SQL Server 实例中的 SQL Server 数据库的缺点包括：
· 可用性：单个的 SQL Server 实例可能成为所有数据库的故障点。
· 性能退化的风险：一个 SQL Server 实例中的所有数据库都共享服务器和硬件资源。如果有任何数据库是资源密集型的，则其他数据库的性能都会受影响。
· 更改公共配置：更改任何配置都会影响所有的数据库。例如，不正确的索引可能影响所有数据库的全部 I/O 性能。
在默认情况下，Windows Server 2003 使用 MDAC (Microsoft Data Access Components) 版本 2.7。如果客户端运行的是 SQL Server 目前支持的 MDAC 版本，则它们应该可以相互通信。因此没有必要升级客户端，除非它们需要使用 MDAC 2.7 附加的功能。然而，如果使用 MDAC 2.6，则客户端在通过 IP 地址连接 SQL Server 时可能需要花费较长的时间；这个问题在 MDAC 2.6 SP1 版本中已经得到改进。详细信息请参阅 support.microsoft.com/?id=300420 上的 Microsoft 知识库中文章“FIX: Connection to SQL Server Database Using IP Address Is Unusually Slow”。
如果客户端需要穿过防火墙连接数据库服务器，则客户端、数据库服务器以及防火墙都必须配置成能够参与分布式事务处理。这个配置包括打开防火墙端口以及修改客户端和服务器的注册表设置。在 support.microsoft.com/default.aspx?scid=KB;EN-US;q250367and 上的 Microsoft 知识库文章“INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall”中深入地讨论了这些设置。
其他信息在下面的文章中提供：
· “Q306843 HOWTO: Troubleshoot MS DTC Firewall Issues”
support.microsoft.com/default.aspx?scid=KB;EN-US;q306843&
· “Q311846 INFO: Names and IP Addresses That an MSDTC Client In a Cluster Environment Must Have”
support.microsoft.com/default.aspx?scid=KB;EN-US;q311846&
Microsoft SQL Server 7.0 和 6.5 是 SQL Server 2000 以前的版本。SQL Server 2000 提供的新功能包括丰富的 XML 支持、全面的分析服务以及简化的数据库管理。
将 SQL 6.5/7.0 数据库迁移到 SQL Server 2000
可以将数据库从 SQL Server 7.0 的实例移动或复制到本地计算机中 SQL Server 2000 的一个默认实例上，或者移动或复制到远端计算机的一个默认或指定的实例上。复制数据库向导可以从 SQL Server 7.0移动或复制一个数据库，而不需要关闭进程中的任何服务器。详细信息请参阅 msdn.microsoft.com/library/en-us/instsql/in_upgrade_6nqr.asp 上的文章“Upgrading Databases from SQL Server 7.0 (Copy Database Wizard)”。
类似地，可以利用 SQL Server 升级向导将来自 Microsoft SQL Server 6.5 的数据转换成 SQL Server 2000 格式。该向导升级数据库并传递所有目录数据、对象和用户数据。该向导还传递复制设置、SQL Executive 设置以及大部分的 SQL Server 6.5 配置方案。详细信息请参阅 msdn.microsoft.com/library/en-us/instsql/in_upgrade_5dko.asp 上的文章“Upgrading Databases from SQL Server 6.5 (Upgrade Wizard)”。
将 SQL Server 6.5/7.0 升级到 SQL Server 2000
如果有可能，应该将 SQL Server 的以前版本升级为 SQL Server 2000，从而使数据服务能从新功能得到好处。有关升级 SQL Server 安装的详细信息，请参阅 www.microsoft.com/technet/prodtechnol/sql/deploy/upgrdmigrate/sqlugrd.asp?frame=true 上的文章“How to Upgrade SQL Server 6.5 and 7.0 to SQL Server 2000”。
运行 SQL Server 6.5/7.0 和 SQL Server 2000
SQL Server 2000 可以与 SQL Server 6.5 和 SQL Server 7.0 在同一台服务器上互操作。在SQL Server 6.5 下，可以安装一个默认的或指定的 SQL Server 2000 实例并使用版本转换在 SQL Server version 6.5 和 SQL Server 2000 默认实例之间切换。详细信息请参阅 msdn.microsoft.com/library/en-us/instsql/in_backcomp_5dx1.asp 上的文章“SQL Server 2000 and SQL Server version 6.5”。
类似地，一个 SQL Server 2000 指定实例可以安装在运行 SQL Server 7.0 的服务器上而不会影响 SQL Server 7.0 的功能。有关 SQL Server 2000 和 SQL Server 7.0 如何协同工作的详细信息，请参阅 msdn.microsoft.com/library/en-us/instsql/in_bckwd_3vlc.asp 上的文章“SQL Server 2000 and SQL Server version 7.0”。
有关 SQL Server 和 SQL Server 2000 以前版本的兼容性的详细信息，请参阅 support.microsoft.com/default.aspx?scid=kb;en-us;261334 上的 Microsoft 知识库文章“Frequently Asked Questions - SQL Server 2000 – Upgrade”。
在企业环境下，SQL Server 2000 服务通常依赖于其他几个关键服务，包括支持存储、连接性以及数据安全的服务。下表列出了这些服务的相关性。
| 服务相关性名称 | 具体要求 |
| 存储服务 | 相应的存储子系统（SAN、NAS 或 DAS）应该在配置 SQL Server storage 之前就配置并测试好。 |
| 防火墙服务 | 如果周边网络中的 Web 和应用程序服务器要求访问 SQL Server，则应该打开内部防火墙中的相应端口来允许访问。例如，SQL Server 客户端连接的监听端口默认为 1433。如果要实现服务器合并而在同一台服务器上安装多个 SQL Server 实例，则可能还需要打开其他的非默认端口。 可能需要打开 RPC（远程过程调用）端口以支持服务器－到－服务器 DTC（分布式事务协调器）调用。有关设计防火墙以支持 RPC 调用的详细信息，请参阅 MSA 参考结构工具包 中服务蓝图 指南中的“防火墙服务”一章。 |
| Active Directory® 目录服务 | 为数据服务帐户创建一个组织单元 (OU)。 为服务器集群服务帐户创建一个 OU。 创建一个用户组以提供对 SQL Server 的访问。必须在 Active Directory 中配置用户帐户和 SQL Server 计算机以支持 Kerberos。 SQL 服务帐户必须授予服务主体名 (SPN) 以使用安全帐户委派。 |
| 网络体系结构服务 | 在部署 SQL Server 之前，合适的网络服务应该到位并进行测试。具体的网络服务需要依数据服务设计而定，例如： · 如果需要只读 SQL Server 支持，则需要利用内部网络管理协议 (IGMP)，对独立虚拟局域网 (VLAN) 中的负载均衡服务器进行硬件和网络负载均衡，以防止交换泛洪或组播。这就将网络业务限制到负载均衡服务器使用的端口而不需要独立的 VLAN。 · 如果网络流量是个问题，则应该分数据服务分配一个独立的网络，从而使管理和复制任务不会影响到客户端的网络流量。 · 如果实施了 Windows 集群，则需要独立的网络连接来使 Windows 集群服务器之间能够进行 heartbeat 通信。 · 如果部署了一个 SAN，则需要保证从 SQL Server 到 SAN 的路径连接的安全，以便支持 SAN 路径故障转移。
|
表 5. 数据服务的服务相关性
Microsoft SQL Server 实施了一种针对数据组织的关系数据库方法。在关系数据库中，数据集合到表中，而一个表代表一个对象类。表中的每一列表示对象的一个属性，每一行表示由表表示的对象的一个实例。这一部分描述 Microsoft SQL Server 2000 支持的一些标准。
开放式数据库连接 (ODBC)
ODBC 是一个支持访问任何 ODBC 驱动器可用的数据源的数据访问 API （应用程序接口）。ODBC 与 ANSI（美国国家标准局）和 ISO（国际标准化组织）在数据库调用级接口的标准一致。ODBC 允许程序在从一个数据库管理系统 (DBMS) 移植到另一个数据库管理系统，而需要在代码中进行的修改最少，因为它指定了所使用的数据库技术；因此，当新的数据库变得可用时，可以很容易地对软件进行升级。
Microsoft SQL Server 2000 包括一个本地 Microsoft SQL Server ODBC 驱动程序，ODBC 应用程序使用这个驱动程序来访问 SQL Server 数据库中的数据。SQL Server ODBC 驱动程序遵循 ODBC 3.51 2 规范，并且公开 SQL Server 的所有功能。在 SQL Server 2000 中，除 isql 之外所有的 SQL Server 实用工具都使用 ODBC API 和 SQL Server ODBC 驱动程序。
结构化查询语言 (SQL)
一个数据库系统需要一套命令和语句（语言）才能处理数据库中的数据。关系数据库可以使用几种不同的语言；最通用的语言是 SQL。ANSI 和 ISO 定义的软件标准包括 SQL 标准。SQL Server 2000 支持 SQL-92 Entry Level，它是 ANSI 和 ISO 在 1992 年发布的 SQL 标准。Microsoft SQL Server 支持的 SQL 特定语言称为 Transact-SQL (T-SQL)。T-SQL 是 Microsoft SQL Server 应用程序使用的主要语言。
可扩展标记语言 (XML)
XML 是一套可用于定义超文本文档结构的标记，它是新兴的 Internet 数据标准。虽然大多数 SQL 语句都以关系或表格式结果集的形式返回结果，但 SQL Server 2000 数据库组件则支持FOR XML 子句，它以 XML 文件形式返回结果。SQL Server 2000 也支持来自 Internet 和 intranet 应用程序的 XPath 查询。可以在SQL Server 数据库中添加 XML 文档，并使用 OPENXML 子句以关系结果集的形式公开来自 XML 文档的数据。
用于程序级集成的 COM 接口
COM 接口是用于构建、使用以及开发组件化软件的二进制规范。COM 体系结构以及支持基础结构是由微软开发和维护的。在设计数据服务时，可以使用 COM 接口（如存储库 API 中所定义的）来访问数据存储库引擎及其信息模型。因为存储库引擎和信息模型是作为 COM 对象公开的，各种编程语言之间的唯一区别在于 COM 实施策略开发平台。因此，开发人员可以为应用程序选择最合适的开发工具。如果使用的是基于 COM 的工具，则一旦应用程序需要更改，就可以很容易将应用程序迁移到不同的编程环境中。
数据服务设计过程涉及选择大量方案来满足组织对可用性、安全性、可伸缩性以及可管理性的要求。有些选择必须为作为一个整体的组织选择，而有些方案可以应用到数据服务的单个安装。
可以按照如下方式适当地选择设计方案来满足组织的服务要求：
· 可用性：在发生故障的情况下，数据服务设计可以通过使用冗余计算资源（包括服务器群集）和周期性备份来提供优化的系统、数据和/或配置恢复。方案包括一个全面的备份和恢复解决方案，它使用瞬时备份技术来备份数据服务实现。
· 安全性：数据服务设计实施了建立在 MSA 安全体系结构的设计原则之上的深层防御策略，并通过使用 Microsoft Windows 身份验证以及从正在处理的资源中分离数据来增加其他的数据安全级别。这种设计还利用了 SAN 提供的高级安全特性。
· 可伸缩性：上扩和外扩方法对可伸缩性都是可用的。可以通过使用能够根据需要无缝扩展的 SAN 和光纤技术来简化存储可伸缩性。
· 可管理性：数据服务设计可以预计安装、配置、管理、进行中的正常监控、故障检测以及性能监控的需求。方案包括持续监控和对正常操作问题进行故障诊断的能力以及以一种受控的而一致的方式管理更改的能力。通过基于业务需求选择合适的方案，设计人员可以在企业环境中开发关键任务的数据服务。
在下面的 URL 中可以找到更多有关设计和配置数据服务的信息：
· “Windows Server 2003 服务器群集体系结构”
www.microsoft.com/windowsserver2003/techinfo/overview/servercluster.mspx
· “创建高度可用的大型 OLAP 站点”
www.microsoft.com/sql/evaluation/bi/creatingolapsites.asp
· “高可用性”
www.microsoft.com/sql/techinfo/administration/2000/availability.asp
· “分割镜像备份与恢复”
www.microsoft.com/technet/prodtechnol/sql/deploy/prodspecs/spltmirr.asp
· “Windows Server 2003 和 Microsoft SQL Server 2000 Enterprise Edition 打破性能记录”
www.microsoft.com/windowsserver2003/evaluation/performance/tpcc2.mspx
· “Windows Server 2003 基准测试”
www.microsoft.com/windowsserver2003/evaluation/performance/benchmarks
/default.mspx
4015
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
