<nobr><a href="http://www.microsoft.com/china/technet/prodtechnol/sql/default.mspx"></a></nobr>

Microsoft SQL Server 2000整合规划

更新日期： 2004年06月24日

SQL Server技术文章

作者：Allan Hirt

投稿人：Tom Davidson和Shaun Tinline-Jones

技术评论员：Prem Mehra，Will Sweeny，JC Armand，Shaun Tinline-Jones，Johnson Noel，Cathan Cook

适用范围：Microsoft® SQL Server™ 2000的所有版本

摘要： 这份白皮书是一系列有关Microsoft® SQL Server™ 2000服务器整合文章中的第一篇。它是一份面向决策制订者和广大技术人员的说明性规划指南。这份白皮书并非针对整合过程的实施方案或管理/操作指南，此类主题是该系列文章中其它成员的关注对象。

本页内容

	引言
	整合基础
	技术任务
	小结
	附录A：技术资源
	附录B：利用SQL Server实现资金返回
	附录C：系统配置工作表

引言

计算（包括服务器以及应用中所实现的商务功能）整合并非一个全新概念。然而，在过去几年中，整合已被推向众多商务企业优先发展领域的最前沿。整合的主要目的往往是在紧缩预算且需要实现更高投资回报率的情况下降低从软硬件设备到人员/维护成本在内的各项费用开支。这份白皮书力图帮助您完成Microsoft® SQL Server™ 2000数据库平台上的整合工作。从诸如Microsoft Access、Sybase和Oracle之类的其它平台上进行数据库迁移并非本文所关注的主要内容，然而，本文同样为您提供了有助于完成此类任务的大量有用信息。

本文所面向的读者

本文能够满足多种类型读者的需求。如果您是一名商业决策者或与此相关的非技术人员，请阅读“整合基础”部分以了解与SQL Server 2000相关的明确整合定义。这部分内容从通用商务角度撰写。

如果您是一名技术人员——诸如DBA或网络管理员，请分别阅读“整合基础”和“技术任务”部分。“整合基础”部分中描述的许多概念将成为帮助您理解整合过程中各项任务的关键所在。

本文结尾部分的三段附录提供了有助于商务决策者和技术管理人员规划数据库整合意图的附加信息与资料。

返回页首

整合基础

简而言之，服务器整合是指将多套物理服务器、应用程序和工作负载精简到少数物理服务器上的过程。在采用合理设计方案的情况下，这些少量的服务器将至少能够提供与原先相同等级的功能和服务，绝大多数情况下，这一等级将得到显著提升。整合过程通常能够为企业带来以下优势：

•	集中化管理方式
•	得以优化的硬件资源
•	平台与处理过程标准化
•	更高的投资回报率
•	得以降低的费用开支（通常包含人员及管理成本）

整合不仅限于大型企业级客户。这份白皮书中所涉及的概念与过程同样可以被各行各业中的各种规模客户所利用。整合具有双重目标：实现足以满足当前或近期商务需求的基础架构规模；提供能够随着业务增长不断加以扩展的体系结构。

整合形式

目前存在四种值得考虑的基本整合形式。其中两种与SQL Server关系最为密切的整合形式为物理服务器整合和存储整合。逻辑整合同样与SQL Server直接相关，但其在概念上与物理服务器整合具有一定差别。

物理服务器整合 ——减少物理服务器数量——通常是SQL Server 2000整合工作的主要动机。由于SQL Server 2000之前的SQL Server版本并不具备实例概念，因此，在早期版本的产品环境中，SQL Server装机数与物理服务器之间存在1:1的比例关系。

存储整合 相对比较抽象。存储整合既可涉及服务器整合，也可与服务器整合无关。它是将多台服务器的磁盘存储空间整合到少量乃至单一高密度存储设备（如存储区域网络，SAN）上的过程。由于需要在单一磁盘子系统上托管更多数据库，因此，整合多台服务器的过程中几乎总是要涉及某种形式的存储整合。

地理整合 是指将当前存在于不同位置上的服务器集中安置在统一位置上的过程。这种整合过程可能会以物理服务器整合的一部分出现，但在许多情况下，其在规划过程中与其说是一种推动，倒不如说是一种要素。

逻辑服务器整合同样有些抽象。这种整合既可在某种程度上涉及物理服务器整合，也可与物理服务器整合无关。当您将多套数据库（而非所有服务器）或多个现有SQL Server 2000实例整合到单一或若干实例上时，由于首要目标在于精简特定功能，因此，这种整合将成为最主要的整合方式。逻辑服务器整合并非总是为了减少服务器数目，某些情况下，这种方式被用以对“详细”功能进行分组。

无论最终选定或实现了哪种整合形式，您都必须同时从商务和技术影响方面对各种选项进行认真思考。可以肯定的是，任何整合方式最终都将归为上述类型的某种组合。

重要提示：整合不仅仅是一项技术工作——它同时还是一项会对各个业务领域产生影响的商务决策。

促成整合的因素

当您在技术层次上制订规划前，必须首先就存在疑问的技术对相关商务案例进行全面掌握。其中包括为何整合过程仅涉及少量服务器而非整个企业，或者，如果您正在就目标平台的选择做出决策，为何选择整合到SQL Server 2000？

基于IT控制的考虑

企业必须将信息技术（IT）视为一种资产。正像对待其它企业资产一样，针对这种资产的控制同样至关重要。对数据库服务器进行整合的最主要动机之一便是更好的对IT运行资源加以控制。企业IT资源通常散布于各个角落，从而导致企业经常失去对其IT运行成本的控制能力。此外，这种控制能力还经常会被其他IT组织机构所篡夺，从而导致企业丧失为自身各个部门提供最佳服务所需的灵活性。对于这部分内容所讨论的每种推动因素，Microsoft公司均在充分权衡集中管理与分布性能的基础上提供了解决控制问题的推荐方式。

您应从在自身所处环境中执行调研来着手建立这种控制机制，以便准确分辨如何使您的企业能够在当今时代正常运转。这里提供了四个旨在帮助您开始建立控制机制的调查问题。这些问题将帮助您确定哪些需求最为重要。可用性？安全性？还是伸缩性？同时，它们还将帮助您确定其它次要需求。

问题：您是否存在同时使用SQL Server 6.5、SQL Server 7.0和SQL Server 2000服务器的情况？您是否同时维护多种数据库平台（Microsoft SQL Server、Microsoft Access、Oracle、Sybase Adaptive Server和IBM DB2）？

在同一套计算环境中运行多个任务密集型应用，并且为每个应用维持包括专用数据库服务器在内的独立后端支持服务器的情况并不罕见。这种方式通常被称作“烟囱”式体系结构，在这种方式下，更高级别的系统体系结构依赖于各自独立的底层平台，而非共享的数据库或数据库服务器。“烟囱”式系统可以随着时间的推移逐步发展，并遗留下依赖于过时数据库技术的危险任务密集型应用。

举例来说，假设您正在使用SQL Server 6.5并且您所维护的应用之一具有任务密集型特性。最终，SQL Server 6.5将不再被支持。然而，向诸如SQL Server 2000这样的更高版本进行升级也并非易事。对数据库平台以及使用该平台的应用进行版本升级需要必要的规划、资金和停机时间。然而，终究会有一天，您的6.5系统将走到生命的尽头，导致这种结果的原因既可能是其逐渐丧失了性能优势，也可能是因为无法满足使其成为得到全面支持的系统平台所应具备的企业级需求。无论出现上述哪种情况，得到厂商提供的产品支持服务并获取与您商务需求相对应的支持级别都是至关重要的。

无论涉及SQL Server的不同版本还是多种不同的产品，这种后端数据库的混用现象都不仅会为其管理者带来挑战，同时还会增加涉及维护技术、人员配置及相关资源的风险与成本。风险来自于DBA需要经常回忆不同数据库平台与版本之间所存在的细微差别。这种情况对运行与维护过程来说非常危险：如果意外执行了错误的操作，将直接导致任务密集型系统无法使用，其代价将是非常高昂的。通过对数据库平台实施标准化并减少混用现象，与运行环境相关的整体风险及成本将得到显著降低。

问题：您是否拥有多套未得到充分利用的独立SQL Server安装实例？

您的数据库服务器是否未得到充分利用非常难以界定。在缺乏合理基准测试与性能分析的情况下，并不存在某种合理的界定方式能够确认一台服务器是否未能得到充分利用。然而，如果感觉到某些服务器仍然存在处于“闲置”状态的剩余性能，那么，您可能的确需要对其进行整合。如果尚不存在粗略的统计数字，那么，您需要执行上述分析；否则，从表面上对那些未得到充分利用的服务器进行整合很可能于事无补。

问题：您是否拥有大量未能得到集中管理的部门级数据库？

在各种规模的企业当中，同时在不同部门内维护众多中小型数据库已成为一种常见现象。通常情况下，这些数据库或服务器被置于IT部门负责日常维护管理的系统范畴之外，因此，它们无法达到企业在设计、实现及维护方面所制订的IT标准。由于处在IT控制范畴之外，因此，经常接到类似下面这样的电话：

部门工作人员：“嗨。我们的财务系统数据库服务器无法使用了。”

IT支持人员：“请问您说的是哪台服务器？”

对公司内部的所有数据库进行集中管理几乎能够减轻每个人的工作（尽管DBA的工作量有所增加），并且，通过这种方式，面向诸如系统体系结构、安全性、备份机制和系统监控之类各项功能的企业IT策略与标准也将能够被利用或建立起来。

问题：您是否没有注意到在同一时刻内有多少套数据库系统在同时运行？是否在您的运行环境中，对整个拓扑结构或技术架构进行控制是一项非常艰难的工作？

即便能够对所有数据库服务器进行集中管理，您仍旧可能无法获得运行环境中每套系统的最新统计信息。例如，哪台服务器正在运行，哪台服务器无法使用？哪台服务器属于测试、开发、阶段性或生产服务器？如果您不了解特定系统所处的角色或重要性，那么，您将无法有效的对其实施监控。监控信号本身可能不具备任何意义，或者，它只能证明发生了某种不该出现的故障。在此方面，服务器整合将发挥辅助作用，它允许您针对IT运行环境生成易于理解的完整快照。

如果对于上述所有问题您都能够给出肯定的答案，那么，您或许已经具备了对SQL Server系统进行整合的充分理由。

尽管考虑进行服务器整合的理由非常多，例如只需管理少量服务器并且能够减少所需支持的平台与配置数量，但归根结底，所有这些理由的目的都是在于优化总体拥有成本（TCO）和投资回报率（ROI）。以下为降低TCO的案例所应具备的要素：

面向整合的成本依据

一家公司内部，是否制订了相互交迭的标准，或者，是否这些标准之间存在相互矛盾的现象？是否所有计算机系统组件已得到全面集成？是否数据中心能够在最为高效的状态下运行？以下部分中所讨论的此类因素在您准备就整合议案进行论证前为您呈现了一套有待分析的复杂考虑因素。

说明：附录C——“商务工作表”——中提供了面向SQL Server整合的成本依据工作表。

服务器整合能够在企业内部的不同团队之间实现更好的业务集成，从而使各个团队均能对当前及未来的商务需求做出更为快速、合理的响应。由于更多信息被广泛共享，更多人员对其所有使用的系统有所了解，因此，企业所制订的决策也将更加合理。

然而，尽管服务器整合能够带来许多优势，必须强调的一点是，您不应将整合方式视为解决服务器所存在问题的唯一答案。正如前面所提到的那样，为了整合而整合的做法并非正确方式。请不要幻想能够简单的将资源从一台服务器转移到另一台服务器上，将您的业务赌定在少量服务器上意味着您需要实现与其相匹配的更为复杂的工具和处理过程。因此，请认真衡量所有成本因素。不要招致因某种故障导致整套业务受到潜在威胁的风险。

标准与过程

企业内部的不同机构可能采用不同方式来管理他们的系统。其中可能涉及不同的监控软件、不同的系统可用性标准以及不同的安全管理过程等。当某个业务单位需要与其它业务单位进行协作时，这种方式将有可能造成混淆。在小型与大型企业中，应当在业务层次的顶部确定标准，并使其从上至下逐级贯彻。在更加集中的服务器部署与利用方式下，更为严格且更具规范化的控制方式通常将被实施，以便使企业能够以一种统一的方式处理各类问题。

计算资源

无论企业创办者在硬件设备上投入的资金是1,000美元、10,000美元、100,000美元还是1,000,000美元，他们都期望使其得到充分、合理的使用。然而，不幸的是，目前许多企业都是在推测的基础上购买硬件和软件资源，从而很可能导致资源无法得到充分利用，或者出现更糟的情况：即这些资源根本未被使用。如果您清楚的掌握您的企业拥有哪些设备以及这些设备正在如何发挥作用，那么，您将能够更好的决策如何利用当前平台以及将来如何进一步采购硬件设备及软件产品。服务器整合能够促进标准化运行环境，进而更好的掌握资源使用情况。性能管理使IT专业人员能够随时间对系统使用情况进行预测，进而使从操作系统与网络支持人员到DBA在内的所有人员从中受益。

数据中心控制

您的数据中心是否得到了合理的气候控制？所有系统是否具备足够的能源？是否为将来的发展预留了足够的空间、能源、制冷、网络端口及其它资源？整套解决方案中的哪些独立系统能够在灾难情况下保持可用性？以上这些仅仅是通常情况下数据库中心所关注问题中的一小部分示例。确保合理的气候控制能力能够保证系统具有更高可用性——但同时也将占用更多资金。如果某一数据中心只被利用了三分之一，而您却花费了过高的制冷费用，那么，该数据中心是否将会使企业支出或损失不应花费的资金呢？所有额外空间都是为将来发展所设计的还是由于规划失误造成的呢？整合通常会减少硬件设备所需占用的物理空间，但与此同时，这一点必须与数据中心规划过程中的其他方面一同进行考虑。从战略角度着眼将有助于确定您真正需要总体成本。

技术技能

不同公司所采用的技能各不相同，即便在相同技术领域内也是如此。维护多种平台所使用的多套专业与技术技能需要付出昂贵的代价。整合到单一数据库平台，如Microsoft SQL Server，将优化知识成本并提高所有人员的工作效率。凭借一套标准平台，从团队角度而言，您的员工能够在得以缩小的技术领域内不断提高自身能力，从个人角度而言，他们得以专注于那些直接影响日常业务的知识与技能。

许可协议

许可费用的概念非常简单：您所拥有的用以安装软件产品的服务器数量越多，获取这些服务器上软件产品（包括操作系统和数据库软件）所需支付的相应许可费用也就越高。当尝试解决诸如哪些服务器许可证需要在何时进行更新这样的问题时，您将遇到一项非常令人头痛的潜在管理难题。从短期角度而言，购买少量大型服务器似乎需要投入更多资金。然而，经过两至三年的时间后，其所节省的费用将非常可观。在某种整合运行环境（诸如基于SQL Server 2000企业版的整合环境）中，许多产品可以采用以系统为单位的许可模型，从而不必为每台服务器购买单独的许可证（正像您处理SQL Server 2000标准版那样）。这样的安排使您得以与以往相比针对某种特定操作系统的更为灵活且更具伸缩性的版本进行投资。同时，您还可以购买诸如增强技术支持之类的其它附加选项，这在以往可能是根本无法实现的。

备份与离线存储

在具有多套系统的企业中，针对每套系统的备份计划可能各不相同：对于某些系统，您可能采用集中式程序通过网络进行备份并最终将备份数据存储到磁带上，对于另外一些系统，您可能先后在磁盘和磁带上进行备份，对于其余系统，则直接在本地磁带驱动器上进行备份。多系统备份策略的复杂化正是由于需要同时处理数据库、文件系统和操作系统所造成的。这样的复杂运行环境并不利于对备份系统进行常规测试，而这种常规测试的目的正是为了确保备份系统能够在灾难情况下及时进行恢复。

假设多系统环境中的每台服务器都具有包括离线存储机制在内的各自备份计划，那么，需要提供储存所有磁带的相应物理空间，同时，还需为这些服务器购买大量磁带。这两项资源的成本无法被忽略。从系统管理员的角度而言，需要针对这些磁带制订一套统一的标记方法，否则，在灾难恢复情况下查找某一套备份数据将变得像大海捞针一样困难。在考虑到这些因素的情况下，减少需要时刻挂念的服务器数量或许是一件好事。整合将最终减小大多数备份计划的复杂性，并降低相关硬件设备及软件产品的采购成本。对灾难恢复过程的管理与测试，包括验证备份介质的完整性，同样将变得更具可行性。

安全性

安全性是所有企业不断关注的焦点。这一领域不仅包括系统与数据的安全性，同时还涉及如何确保办公机构和数据中心的安全性，以避免发生未经授权的访问。实现高度安全性并非一项廉价的工作，同时，为确保整合环境受到良好的保护，它已成为一项必须完成的工作。

可用性

尽管成本和预算是众所周知的底线，然而，为了整合而整合的做法并非正确的方式。如果系统本身无法使用，即便成本得到了降低，您会觉得真正节省了资金吗？人员方面同样是商务案例中需要考虑的因素。整合究竟能够为终端用户和那些负责维护系统的日常管理员带来哪些帮助呢？

IT专业人员

对于DBA及其它IT专业人员来说，整合乍看起了似乎并不是个好主意。将他们业已熟知的多台服务器整合到少数工作负载更大的系统上将改变DBA的工作方式。尽管功能依旧如常（或有所改进）并且工作中的特定环节依然保持不变，然而，他们现在必须为正确维护新的配置环境而重新接受培训。同时，整合还将导致对企业基础架构收缩的某些担忧，即担心工作安全性与运行环境稳定性。

对DBA来说，整合的积极因素同样是巨大的，他们将可以更加充分的利用现有技能、经验、人员、平台及工具。他们可以减少重复性工作任务。DBA将变得更像是值得信赖的技术顾问，关注于哪些诸如调整数据处理策略与目标这样的重要企业级任务。同时，他们还将腾出更多时间来从事诸如性能改进之类更有意义的任务；提供有关性能管理的反馈信息；在开发周期中扮演更具影响力且更加深入的角色；并对软件产品进行评估以改进IT资源采购的决策方式。

从另一种观点来看，整合符合多数IT商家的共同目标：获得IT资源控制权，降低IT基础架构复杂性，提供面向部门和商业单位的灵活性，针对硬件设备与软件产品配置实施标准化，减少单点故障以增加可用性，逐步提高由具备资额的人员来管理系统的重要性，并且不断增强安全性。

客户

从企业的角度出发，对客户或最终用户所产生的影响是所应考虑的最重要因素。您的用户是您实施整套系统的首要原因。如果经过整合的基础架构并不透明——如果它对最终用户产生巨大影响，那么，用户满意程度将会受到损伤。整合的目标应当是提高或维持用户满意度，因为整合应在尽一切可能的情况下做到不对最终用户产生影响。

整合过程

并无针对SQL Server 2000的整合向导。整合决策是精心规划的最终结果并且将在产品环境滚动升级前进行测试。为协助将诸如整合工作这样的IT计划转化为合乎逻辑的分阶段实施步骤，Microsoft提供了Microsoft解决方案框架（MSF），它是一种有关方法与实现方式的参考体系结构。凭借MSF方式，整合工作将分为四个阶段进行：展望、规划、开发与部署。

•	展望阶段在SQL Server整合项目中类似于其它基于基础架构的项目。一支由代表企业观点和最终用户的人员所组成的团队将协同负责制订商业目标并确定项目所涉及的范围。这支团队的构成方式将在下一部分——“第一阶段：展望”——中予以描述。在展望阶段，项目团队将负责收集用户简要信息，制订解决方案概念，启动风险分析，并确定项目结构。整个展望阶段将在实现设想/范畴审批里程碑时达到顶峰。
•	规划阶段的主要可交付成果包括功能说明草案、主项目计划草案、项目进度草案以及一套开发环境。功能说明包括设计、可用性与开发目标、解决方案设计、组件规范、项目风险以及项目标准。主项目计划包括实现步骤、依赖关系以及项目构想。此外，主项目计划中还包括其它相关计划，例如开发计划、试验计划、采购与设施计划、测试计划、性能计划、培训计划以及安全计划。规划阶段将在实现项目计划审批里程碑时达到顶峰。
•	在开发阶段内，项目团队将对解决方案进行测试与试验，编制培训资料，并筹备部署过程。这一阶段内的关键活动包括技术验证、概念论证、测试、试验、以及从试验过程中获取反馈信息。开发阶段将在实现发布里程碑时达到顶峰。
•	部署阶段是一个活动阶段而非分析阶段。在此阶段内，项目团队将部署核心技术，部署站点组件，稳定开发工作，将项目移交给运行和支持人员，并获得来自客户的项目授权。在完成部署工作后，项目团队将进行项目复审，并就客户满意程度进行调查。部署阶段将在实现部署完毕里程碑时达到顶峰。

MSF采用迭代方式，其中每个阶段又被细分为一系列步骤。如需获取更多关于MSF的信息，请参阅http://www.microsoft.com/china/technet/itsolutions/techguide/msf/default.mspx

第一阶段：展望

展望阶段由四个必须执行的步骤构成。

第一步：组成整合团队

展望过程中的第一步工作是组成一支核心整合团队，这支团队将负责对整个整合过程进行监督。这支团队至少应包括企业发起者、来自各支应用开发或实施团队的代表（包括内部定制应用及第三方应用）、来自企业系统管理团队（IT、运行及DBA）的相应技术代表以及某些能够反映最终用户意见的代表。这支团队中的其它人员还可以包括某些最终用户、数据分析专家以及项目经理等。最终的团队成员将因运行环境的不同而有所差异，但所有团队的目标却是相同的：即构成一支能够代表企业各方面意见的团队。

第二步：确定初始整合组件

一旦整合团队组建完成后，其首要任务便是确定那些需要进行整合的应用、系统、数据库及服务器。选择这些实体的标准将由整个团队来确定，并应以其对企业、成本及整合过程的其它所有方面所产生的影响作为权重来衡量。请确保从有限的切入点来启动整合工作，例如某一两个业务单位、应用类别或少量特定应用列表。从整个企业（或者对于小型企业中的所有服务）着手的做法并非最佳整合方式。不应犯下错误——任何整合工作都应从企业的角度执行。从小处着手的方式将使您有时间从以小见大的工作中取得对整合工作的正确认识，并从所积累的经验教训中受益，从而确保下一步整合工作的高度成功。

第三步：确定指导原则与目标

本文前部的“促成整合的因素”部分简要描述了促成整合的最大商业动机。现在，是时候来确定您所在特定情况下的促成因素了。当完成整合项目后应当实现哪些目标？整合过程中会遇到哪些风险？这些是经常会被提出的问题，您将如何来收集与其相关的关键信息呢？

为确定企业的整合目标，以及制订这些目标所依据的原则，应当定期召开一系列广泛参与的会议。除核心整合团队外，还应确保参与整合工作的所有其它各方（从企业发起者到某些最终用户）能够参加最初的会议。企业内部所有牵扯在内的团队都有机会提出自己的想法，从而使控制整合过程的各项原则能够满足各方面的需求。

除这些会议外，还应确定最初可能遇到的风险。所有原则与风险都必须通过文档方式被正确记录下来。

此项任务的目的在于收集反馈信息并澄清由此产生的结果信息：团队的预期、运行环境的当前工作知识（包括基于事实的或主观认识上的）、整合约束条件、与运行环境相关整合工作的规模与复杂性、以及最为重要的部分——即最终为其投资的管理方针对该项目所做出的承诺。在最初阶段确定各项风险是至关重要的。

以下表格提供了某些示例问题，这些问题能够促进针对整合过程中必要商务原则的讨论。这些问题不仅可以帮助您确定指导原则，同时，它们或许将不会全部应用于您的运行环境。这些问题同时涉及非技术领域和技术领域，其中某些还同时适用于技术和非技术情况。在此阶段内，您可能无法就某些技术性较强的问题给出完整答案。（本文稍后的“技术任务”部分将详细描述如何从技术方面确定指导原则。）

技术等级

旨在确定指导原则的示例问题

非技术

您认为能够通过整合方式实现哪些商业价值？

您如果针对现有服务器做出整合决策？

IT及企业股东是否认同整合概念？

可供购买新增硬件设备的资金有多少？整个整合项目的可用预算额是多少？

作为整合项目的结果，您是否计划裁撤或削减相关工作人员？

陈述您认为核心整合团队必须关注的所有特定问题或信息。例如：

•	是否存在可能会对服务器整合工作造成影响的企业策略？
•	企业是否具有“独家”提供商？此种情况在某些国家是非法的，并且可能会以某种形式对整合合同产生影响。
•	是否存在可能通过要求使用独立物理系统并从不同部门获取数据的方式对服务器整合工作进行约束或修改的企业安全策略（就像LLP那样）？

技术

在完成整合工作后是否需要使用其它类型的工具？

随着时间的推移，数据增长情况如何？您的预期与实际增长情况相比有何差别（如果能够获取相关数据的话）？

如果对新系统进行维护？整合工作使维护方式产生了哪些改变？

现有解决方案中存在哪些组件依赖关系？举例来说：是否存在由于可用性问题或系统内部迁移导致外部数据无法输入SQL Server的情况？

解决方案中所包含的应用与组件当前使用哪些技术，哪些（当前或附加）是您所希望的？相应变化会对解决方案产生哪些影响？

当前系统中是否存在已经达到或超过性能上限的组件——此类组件是处理器、内存还是磁盘？

您是否拥有合适的开发、测试及阶段性运行环境？

两者兼具

针对资源使用情况的资金返回是否属于需求或考虑因素之一？目前用于衡量资金返回情况的工具在整合后是否仍然使用？

短期内，您希望通过这种解决方案支持多少并发用户？您的长远预期又是如何？

您希望这种解决方案能够在生产环境中维持多久？

从最终用户和系统管理/业务管理的角度而言，何谓可以接受的性能？请描述您对性能的定义——它能够通过吞吐率、响应时间或其它基准指标来衡量。

目前针对每套独立系统或每套解决方案的可用性目标是什么？在整合后的运行环境中，各种组件是否能够满足需求？

针对组成现有解决方案的应用和系统而言，安全需求到底有哪些？它们是否与企业策略保持一致？目前在即将整合到一起的系统之间是否存在冲突？您必须面向整合对需求做出怎样的调整？

短期内，开发、实施并支持新型解决方案的成本如何？长期情况又是怎样的？

目前针对每套独立系统的真正停机成本是多少？针对整个解决方案的停机成本又是多少？当前服务器的管理与运行成本是多少？

目前应用何种服务等级协议（SLA），这些协议是否会受到整合的影响？

目前的服务器位于何处？它们是否部署在同一个数据中心内？如果不是，改变这些服务器的位置或地理布局会对用户、性能及SLA造成怎样的影响？地理位置或所处域的改变还会产生哪些其它影响？

目前的IT分支机构扮演哪些角色？您是否已经设置了专门的性能管理角色？

您是否已经具备了面向现有系统（无论是否涉及整合）的有效变更控制过程？

您是否建立了测试/质量保证团队？

是否均在专职DBA，如果存在的话，这支队伍的人数是多少？

目前，SQL Server实例与数据库同DBA之间的数量比例是多少？

考虑对哪些不同类型的系统实施整合：生产、测试、开发？还是其它类型？

您是否计划采用诸如群集之类的新型技术来实现高可用性？这些新型技术在技能、成本及培训能方面将对您的员工产生哪些影响？

在整合过程中，您是否仍然要维持某些特定SLA？

目前，在即将整合到相同机器上的系统中，是否有多套系统存在SLA冲突的情况？

是否存在由于性能或SLA冲突等原因需要与其它系统相分离的系统？

项目的预期截止日期是什么时间？是否存在某种约束限制，例如由硬件设备或服务厂商造成的限制条件？

是否存在任务密集型系统？此类系统将对与其整合在一起其它系统产生哪些影响？

就真实事务（非数据库事务）或收入而言，每套系统所产生的业务量有多大？?

列出您的企业用以制定日程计划的所有参考信息，例如会对您的整合收效产生影响或影响您的分析结果的其它整合项目。

在召开最初由多方广泛参与的会议后，核心整合团队应当对由于服务器整合所带来的复杂性挑战有所了解。作为开始阶段会议的一部分，应当制订出贯穿整个项目的总体指导方针。同时，您还可以利用这些方针在整合完成后来衡量整合工作的成功与否。

以下表格显示了针对整合项目的指导原则示例。这些示例均是基于多个安装实例的实际经验得出的。

说明：这些指导原则并非做为Microsoft官方建议或最佳实现方式提供的。每套安装实例都有不同的服务器整合动机与目的，并且这些动机与目的将直接引导整合指导原则的制订。

针对整合项目的指导原则示例

只有免费赠送的SQL Server负载将被整合到单一Windows安装实例上。举例来说，OLTP和决策支持（DSS）负载不能位于相同服务器上。

诸如Microsoft Exchange、文件服务器、打印服务器之类的额外服务将不会整合到SQL Server系统上来。

当整合免费赠送的工作负载时，数据库有可能将被整合到一个多数据库SQL Server 2000实例上。除非特别考虑，否则，无目标的数据库将不会整合到同一实例上。

只有非任务密集型负载将在最初进行整合。任务密集型应用和服务器将不会在最初进行整合，这样做的原因有两条：获取整合经验；并将对任务密集型系统最终用户产生干扰降至最低限度。

在考虑对应用及数据库（包括所有相关对象）进行整合前，它们将首先被更新或转换为能够支持SQL Server 2000。在更新或转换过程中，功能不会得到增强，但将仍旧维持相同的级别。允许项目范围超出协议尺度和参数的做法（称为范围蔓延）将影响最终成果。因此，只有与兼容性相关的程序错误将被修复。

在容量或使用性能提出相应需求的情况下，将使用一个以上的SQL Server 2000实例。

多个SQL Server实例可能用以隔离不同的工作负载。然而，必须对底层服务器进行必要的配置，以便使其尽可能实现隔离。

如需存在明显的命名冲突现象，则将使用多个实例。

整合过程以及整合后的系统将尽可能针对最终用户保持透明。.

整合过程将推动系统配置、系统管理与系统支持的标准化。

一旦原则被确定下来，负责实施整合方案的核心团队——以及其它相关人员，如负责部署并维护整合后运行环境的人员——应当对其进行审核。收集反馈信息并在必要的情况下进行修改。这是一个反复迭代的过程，整个工作直到所有原则得到一致认可后方才结束，此后，这些指导原则将由负责整个项目的团队和企业发起人正式签署生效。

第四步：通过文档形式记录系统配置与性能

在制订正式商务或技术整合规划前，您需要尽可能多的了解即将进行整合的系统。在缺乏这些信息的情况下，做出决定性选择几乎是不可能的。一旦整合团队就需要进行整合的系统达成一致，您便可以收集各类相关信息。您如何断定尚未达到或超过系统性能上限呢？这将直接影响组件是否需要进行整合，以及为支持最终生产系统需要采购哪些硬件设备。这一过程将在“技术任务”部分中进行详细描述。

说明：如需了解如何收集并概括有关当前SQL Server数据库的信息，请参阅附录B，“利用SQL Server实现资金返回”。如需获取帮助您完成这一过程的工作表，请参阅附录C，“系统概要工作表”。

第二阶段：规划

一旦完成展望阶段的工作，即就指导原则达成一致并形成文档，整合规划工作将随之开始。在此之后的所有工作都将受到指导原则的约束。规划工作主要分为两个部分：设计整合后服务器的构成方式，并对设计方案进行论证。

第一步：设计整合完成后的服务器

当您开始设计整合后的运行环境时，请充分考虑运行环境中的每个方面，其中包括管理与运行（包括监控）、性能、备份与恢复、资金返回（如果必要的话）、灾难恢复、高可用性以及安全性。

请不要假定您只需使用当前系统中已有的资源。新的运行环境将有所差别。由于新的运行环境中每台服务器上将部署更多的数据库和SQL Server实例，因此，您将面对更多需要协调的不同规则与选项。在此阶段，如果您确定需要建立或购买新型工具，请同样针对其建立文档并进行规划。

第二步：迁移应用、用户及数据

DBA所面临的首要问题在于如何将应用、用户与数据迁移到整合后的全新运行环境中。从Transact-SQL不兼容到系统设置，所有潜在的SQL Server 6.5和SQL Server 7.0迁移问题均应在此刻完全独立并确定下来。您可考虑在6.5兼容模式下部署SQL Server 2000，以便减少迁移过程中可能遇到的问题。此外，您可能还需要配备用以过渡的阶段性服务器。您应确定应用、用户与数据的迁移顺序。解决对象名称与位置所存在的冲突。时刻考虑最终用户的体验方式，并确保尽可能使您的工作对其而言相对透明。同时，您还应考虑如何就移植工作向最终用户进行通报，以及业务流程将受到哪些影响。

最为重要的是，应当全力避免出现范围蔓延现象。您可以整合——但不应新增——应用程序或数据架构的功能与特性。相关问题可以在迁移规划过程中标识出来，只要它们不会对整合后的运行环境造成破坏，就应暂时不予处理。一旦完成整合工作后，您可能希望着手处理此类事务，然而，将此类工作加入到这一阶段只会导致整合过程因不必要的因素而被延长。

第三步：测试整合过程

在生产环境中对服务器进行实际整合操作前，您必须首先建立并测试所有的新增程序、工具以及整个迁移过程。测试环境的容量与性能应与最终生产环境保持一致或非常接近。然而，您可能会受到诸如预算或资源等因素的制约。这一阶段的主要目标在于独立、标识、记录并修复遇到的所有缺陷、错误或问题，以便使即将在生产环境中进行的同样工作尽可能完美无缺。制订恰当的测试计划有助于确保生产环境滚动升级的成功进行。

第四步：确定风险

确定您所面临的风险（包括潜在障碍）是整合过程前期的一个重要步骤。这些风险可能涉及人员、技术或成本。如果对这些风险缺乏了解，在实际工作结束后，您将无法分辨整项任务成功与否。此外，您所确定的风险还可用作衡量标准。风险迁移是一项独立任务，某些风险可能无法避免，但如果将其记录下来，您至少可以以最佳方式将其考虑在内。

第三阶段：开发

在开发阶段，规划内容将首次在测试或阶段运行环境（或者同时在两种环境）中予以实现。由于在实地操作前确定所有潜在问题具有至关重要的意义，因此，这一阶段要求提供与最终生产服务器完全分离的硬件设备。

理想情况下，您在这一阶段中所使用的服务器应与生产环境中所使用的服务器具有同样的性能。由于受到预算的限制，对于某些站点而言，这种要求可能并不现实。然而，您需要清楚的是，您的测试及阶段运行环境与生产环境越为接近，实际生产迁移过程就将越发成功。

开发阶段至少需要经历三个步骤，而通常情况下则为四个步骤。

第一步：技术验证

一旦相关技术被确定下来，必须对所选定的技术进行全面测试，以确保其能够在最终生产环境中正常发挥作用。各项测试应当分别在独立及负载条件下进行。该步骤将明确显示出您的选择是否正确，以及是否需要实现某种新型技术。同时，这也是您对整合工作的物理设计方案进行修改的最有机会。

第二步：概念论证

在用以建立最终运行环境的技术环境中对概念进行典型论证的工作将按照预期方式进行。概念论证的主要工作为：在小范围内以可控方式证明您的观点。尽管规模较小，但概念论证却涵盖与全面实施方案相同的范围。这就意味着您可以充分发挥想象力，进行必要缩减，并关注于能够代表最终产品小尺寸模型。

在将应用、数据及用户迁移至经过整合的全新SQL Server运行环境中的指定区域后，请按照其各自的方式完成相关工作。按照日常方式对其进行试用，并在负载条件下对服务器进行测试。您必须确保当所有应用程序均处于高利用率的情况下，当前被整合到同一SQL Server实例下的数据库仍能正常工作，否则，您将会在生产环境中遇到性能问题。

如果在概念论证测试过程中发现共存问题，请及时将其以文档形式记录下来，并尽可能重新就特定应用的数据库策略进行考虑。由于将会直接对试运行造成影响，因此，这一阶段内的迁移风险极为关键。

重要提示：请记住，不仅要测试迁移过程，同时还要对最终生产环境中所使用的管理计划、脚本、过程、工具及其它元素进行测试。仅仅对迁移过程进行测试是远远不够的。

第三步：试运行

最后，选择一台将要进行整合的服务器，并将其作为生产环境中的试点。即便概念论证非常成功，您仍旧需要证明在全比例生产环境内，整合工作将使整个企业受益。就像概念论证那样，您必须对整合实施方案进行彻底测试与试验。

第四步：重新考虑

如果试运行以失败告终或由于其它原因而被迫中止，那么就需要您及时进行处理。此时，应遵循事先制订的配置计划和迁移计划。当问题出现时，请以文档形式加以记录。如果找到某种修复措施，则应及时修改文档，并对计划做出相应的调整。此后，应根据实际情况重新进行测试。

第四阶段：部署与稳定

一旦确信合理的硬件设计方案已被制订且迁移计划已经通过测试，您便可以开始建立并部署经过整合的生产SQL Server系统。部署阶段包括三个主要步骤：后端部署、应用部署和稳定。

•	在后端部署过程中，您将完成系统骨干组件（硬件设备、操作系统、网络环境及SQL Server等）的配置与测试工作。
•	在应用部署过程中，您需要对数据库进行配置，并在整合后的全新运行环境中对应用实施滚动升级。
•	完成滚动升级后，稳定阶段将为您提供处理最终出现问题的机会。此时，您将身处无法轻易返回原先运行环境的“进退两难”境地。通过这一阶段，系统将逐步趋于稳定。

完成滚动升级后，稳定阶段将为您提供处理最终出现问题的机会。此时，您将身处无法轻易返回原先运行环境的“进退两难”境地。通过这一阶段，系统将逐步趋于稳定。即便您的计划经过了充分测试，仍旧不要一次部署所有整合组件。在整合过程中，请采用分阶段方式：部署一项整合工作，对其进行全面测试，将其与最初运行环境进行对比，并最终放弃原有运行环境。只有完成上述工作后，您才应着手考虑整合另一套SQL Server，如果未能按照预期对前一项整合任务进行全面验证，或者在另一项迁移工作中遇到了其它问题，那么，您所面临的问题数量和复杂性都将增加。

返回页首

技术任务

本文前一部分“整合基础”从商务角度概要描述了整合过程。这部分内容将把这些基本原则映射到负责整合过程中必须考虑的相关技术领域的特定技术任务与问题上。这些任务与事项对应于Microsoft解决方案框架的前两阶段：展望与规划。

说明：如欲获取协助您完成整合过程的相关技术资源列表，请参阅附录A，“技术资源”。

展望事项

在此阶段，整合团队中的技术人员（以及其他涉及技术领域的人员）必须确定整个整合项目的技术指导原则与目标。完成此项工作后，您必须概括有关需要整合系统的各个方面，并收集系统性能指标与附加信息。以下各个步骤将引领您成功完成整合工作。

确定指导原则与目标

除一套由业务驱动的指导原则外，您还必须建立一套技术指导原则。凭借为业务指导方针保驾护航的技术指导方针，您将获得通向成功的指导原则与标准，以及“前”、“后”运行环境之间的基本对比情况。

技术团队必须协同工作以收集必要的信息。当寻找到的答案是需要进行整合时，他们必须根据商务指导方针进行协调。系统各部分之间共存是否融洽，或者，是否存在有待调和的不协调现象？在各方面达成一致或就潜在的问题达成妥协之前，将无法开发任何整合工作。

以下表格列出了某些有助于探寻整合过程所需技术原则的示例问题。正如商务原则那样，这些问题并不代表所有能够帮助您确定指导原则的信息，并且，它们中的某些成员可能并不适用于您的特定运行环境。

领域	用以确定指导原则的示例问题
通用技术	您认为能够从整合中获取哪些技术优势？
	未经整合的部署方案会出现哪些问题？从这些部署方案中能够得到哪些（正面和负面的）经验教训？
	需要进行整合的服务器数量有多少？
	平均而言，目标服务器上存在多少数据库？
	服务器是否已被确定？
	对于确定需要进行整合的服务器，其地理分布目前是否相互独立？
	您是否了解每套系统上的工作负载类型（诸如OLTP、OLAP或DSS）？
	您是否了解整合计划中所有可能使用SQL Server的第三方应用需求？
	组织机构内部的DBA是否接受过有关SQL Server各方面技术的正规培训，其中包括管理、高可用性与性能等？
备份与恢复	当前使用何种备份技术？
性能管理	目标服务器的使用方式如何（包括系统数据库的使用）？您是否针对每台服务器确定了性能基准？这种基准是否被商务单位或其各自的系统所打破？
	您是否了解每台服务器的资源利用率？您是否能够准确估算出目标服务器是否超负荷运转或未得到充分利用？
	随着时间的推移，数据增长情况如何？您的预期与实际增长情况相比有何差别（如果能够获取相关数据的话）？
变更管理	您如何管理包括存储过程和功能在内的数据库架构？您是否通过某种形式的版本控制对其进行维护？
配置	您是否掌握有关每台服务器的全部信息（诸如服务包级别、磁盘空间使用情况、SQL Server配置选项等）？
	您是否使用诸如Alert或SQL Mail这样的管理工具？您是否针对所有服务器实现了标准化？
	这些服务器使用何种SQL Server版本？
	这些服务器安装何种操作系统版本？
	解决方案中当前采用何种技术？
连接	您是否了解平均有多少用户连接到SQL Server？通过哪些类型的客户端产品（诸如手持设备或胖客户端）连接到SQL Server？以及如何进行连接？
	当前服务器是否位于不同域中？
高可用性	目标服务器是否已经通过诸如故障转移群集或日志传送之类的技术实现了某种形式的高可用性？
	您的企业中目前应用了哪些高可用性技术——经过整合的运行环境是否符合您的企业发展战略？
对象	您是否拥有可能会对其它数据库产生影响的定制化扩展存储过程？
	您是否拥有名称相同的冲突对象？
	您是否拥有所有访问SQL Server的应用程序以及所有存储过程（特别是当您通过存储过程进行加密时）的源代码？
复制	是否针对所有目标数据库设置了复制措施？
安全性	您是否针对每台服务器（物理硬件设备、操作系统、SQL Server及应用）制订了安全策略与程序？是否所有安全策略均与目前的企业策略保持一致？

概要描述有待整合的系统

每套需要进行整合的系统都必须予以概要描述。概要描述绝不仅仅是记录下系统名称：系统的各方面信息都必须被捕获。这项工作将确定负载与系统是否能够进行整合，并检查由于配置设置、应用需求或其它因素造成的无法兼容问题。请使用附录C，“系统概要描述工作表”中所提供的以下工作表来完成这项工作：

•	系统信息工作表收集正在运行中的系统与应用的相关信息。
•	磁盘配置工作表收集有关磁盘子系统使用与配置情况的信息，并帮助您理解各项磁盘性能指标。
•	SQL Server信息工作表收集有关将要进行整合的SQL Server实例的特定SQL Server信息。当为每套数据库编制文档时，请注明其所承担的工作负载类型（诸如读/写和写）。

这些工作表是以指导原则形式提供的。您可以轻松对其进行扩展，以便包含与您所处运行环境相关的特定信息。

除通过这些工作表收集常规系统信息外，您还需收集针对每种应用的特定设置信息。SQL Server提供了一些能够帮助您建立系统文档的方法：

•	运行名为sp_configure的系统存储过程以收集所有针对SQL Server的配置信息。
•	在SQL Server 6.5上运行系统存储过程sp_helpstartup或在SQL Server 7.0及2000上运行系统存储过程sp_procoption以确定SQL Server所使用的启动过程与设置。
•	利用sqldiag工具收集SQL Server系统信息。sqldiag工具一般用以诊断各类问题，收集系统信息只是该工具的一项附加功能。请使用以下语法： SQLDIAG –X –U <user name> -P <password> -I <instance name if not default> -O <output file> 在sqldiag的命令行参数中，-X 用以跳过错误日志；同时，您可以使用–C 来获取群集信息。

对于每套数据库，还需通过文档方式记录与其相关的所有对象（诸如存储过程、作业、系统与数据库用户登录信息以及维护计划等），即便这些对象位于数据库之外也要进行记录。稍后，您将利用这些信息来确定其它冲突——例如存储过程名称与登录重复或命名标准不同等。请在每套系统上运行相同的DBCC命令，以便针对各套系统获得相同的基线以及一致的处理过程。请记录您所收集的各项信息——包括相互链接的服务器、经过修改的系统数据库等等，由于稍后可能才会发现这些信息的真正有用，因此，即便当时认为并无相关性，您也应将其收集起来。

收集系统性能指标

从您的服务器上收集性能指标并非一项一次性工作。如欲真正理解系统工作方式，您必须定期收集性能指标并对这些信息进行分析。

有关系统的各类信息与指标——包括处理器、内存、磁盘I/O以及磁盘性能等——必须及时予以收集。请将您所收集的结果记录到附录A提供的性能信息工作表中。

我们建议您至少每周收集一次有关系统的统计信息。在此过程中，分别记录系统在不承担负载、承担中度负载以及承担繁重负载情况下的各项性能指标。如果仅仅收集了反映某种极端或特定状态下的性能指标，那么，您将无法获得有关系统使用情况的真实描述。

如需获取有关SQL Server性能测量方式的其它技术提示，请参阅SQL Server联机丛书中的“监控服务器性能与活动”部分。

处理器指标

统计在您服务器上运行的所有服务器进程。如果SQL Server是您系统上运行的唯一主要应用，那么，收集性能指标将是一项非常简单的任务。如果SQL Server是您系统上运行的几种主要应用之一，那么，了解每个进程的独立执行方式与系统协同机制将非常重要。当您对不同应用进行测试并且能够区分它们之间的差别时，您将能够更好的规划整合设计方案。

举例来说，假设您同时运行SQL Server和一种第三方软件应用。系统整体CPU利用率看上去很高。您应停止第三方应用，并单独对SQL Server进行监控。通过单独测量SQL Server，您看到CPU利用率最高未超过30%，这意味着其它CPU负载是由第三方应用及其它活动服务器进程产生的。如果这些附加应用或进程为关键性任务，那么，在条件允许的情况下，应尽可能分别停止并启动各项服务，以便独立收集针对每种应用或进程的性能指标。

尽可能分别停止并启动各项服务，以便独立收集针对每种应用或进程的性能指标。您可能无法获取执行全面分析所需的指标，这种情况可能是由于特定系统并非整合候选者造成的。在一套具备完善管理机制的运行环境中，所有或绝大多数性能指标都将在系统进入生产环境前被记录下来，从而使这一问题得以解决。

在性能监视器（或Windows NT® 4.0的系统监视器）中，在处理器分支下选择捕获% Processor Time指标以监控总体处理器利用率。除非通过参数指定同时收集整套系统及每颗独立处理器的性能指标，否则，性能监视器将不会特别挑选某颗处理器。这项指标无法测量单个进程的处理器利用率。如需测量某项服务（例如SQL Server）的处理器利用率，可在进程分支下选择% Processor Time。

在分析过程中，理解对整合产生的影响非常重要。同时，理解其它服务器进程对CPU利用率的影响也是至关重要的。被指定为整合服务器的单一物理服务器上的服务器进程将受到从其它服务器整合到这台服务器上的应用和服务器进程（诸如SQL Server）的影响。

内存指标

收集内存统计信息与收集处理器利用率指标非常相似。服务器上的每项独立服务应当分别予以测量，此后，还应将整台服务器作为一个整体进行测量。

在处理针对SQL Server的统计信息时，必须注意内存配置情况。您是否正在使用动态内存？是否配置了一定数量的静态内存？是否使用诸如AWE之类的扩展内存？这些将有助于理解您所收集到的统计信息。

利用性能监视器中所提供的以下计数器来收集内存统计信息：

•	内存：可用字节数
•	SQL Server：内存管理器：连接内存（KB）
•	SQL Server：内存管理器：锁定内存（KB）
•	SQL Server：内存管理器：最大工作区内存（KB）
•	SQL Server：内存管理器：优化器内存（KB）
•	SQL Server：内存管理器：SQL高速缓存（KB）
•	SQL Server：内存管理器：服务器内存总和（KB）

磁盘I/O与容量指标

磁盘是数据库系统的心脏与灵魂。您可以利用附录C中所提供的磁盘配置工作表以及这部分所介绍的方式来收集与每个SQL Server安装实例相关的磁盘子系统性能指标。

diskperf命令

通过在命令行窗口中执行以下diskperf命令，可以对特定时刻的磁盘性能计数器进行转储，并将结果存储在指定文件中。缺省情况下，Windows® 2000及其以上版本的Windows操作系统能够支持磁盘计数器：

diskperf –y

性能监视器计数器

在性能监视器中，可对以下磁盘计数器进行分析：

% Disk time

显示磁盘利用情况。如果某台磁盘驱动器的利用率连续保持或接近100%，则说明其已经处于超负荷运转状态并且可能导致SQL Server性能问题。

平均磁盘队列长度

指示平均有多少系统请求等待进行磁盘访问。0代表最佳取值。如果取值维持在2或3以上并且始终保持不变，则说明您可能已经遇到了磁盘性能问题（取值的瞬间上升并不代表出现问题）。然而，平均磁盘队列长度并不能够精确测量磁盘I/O问题。此处介绍该计数器只是为了对比整合之前与整合之后的取值。需要说明的是，该计数器取值会因磁盘存储系统的品牌与类型而有所不同。

平均磁盘读取次数/秒和平均磁盘写入次数/秒

对于日志文件来说，该计数器理想取值为2至3毫秒，平均随机读取时间为6至8毫秒（峰值情况下最大为15至20毫秒）。根据您的硬件设备配置方式与最终性能目标，这些取值将有所不同。

请记住PhysicalDisk类别下物理磁盘指标与LogicalDisk类别下逻辑磁盘指标之间的差别。

独立SQL Server文件

如需获取SQL Server所使用的单个文件性能指标，请执行以下操作步骤：

1.	通过执行以下查询操作获取数据库ID编号： SELECT * FROM master..sysdatabases
2.	通过执行以下查询操作获取文件名称： SELECT * FROM pubs..sysfiles
3.	通过执行以下查询操作获取文件统计信息： SELECT * FROM ::fn_virtualfilestats(dbid, -1) 其中，-1将显示对应于指定数据库ID（dbid）所有文件。
4.	对比第三次查询操作所返回的结果。如果IOStallMS取值除以NumberReads与NumberWrites取值之和后大于您的预期日志文件数量，那么，日志文件将成为一个系统瓶颈。

磁盘容量

评估磁盘容量的一种不太可靠的简单方式是根据预计增长速度检查您是否还有足够的磁盘空间。然而，磁盘容量不能简单的用尚未使用的空间来衡量。磁盘子系统同样必须依据您的当前及未来需求进行合理的结构设计。在整合过程中，您或许能够通过新增硬件设备来纠正此类体系结构问题。

填写磁盘配置工作表的主要原因之一便是查看所需的磁盘空间。该工作表将通过汇总所需整合的服务及数据库数量的方式帮助您完成此项工作。磁盘空间的计算方式主要有两种：根据原始磁盘空间或根据物理磁盘。原始磁盘空间与实际需要的物理磁盘数量是相互关联但又各自独立的。

原始磁盘空间是指所需要的物理磁盘空间总量。数据库原始磁盘需求不仅仅限于独立的数据和日志文件。它还包括tempdb、空闲空间、索引尺寸以及其它与SQL Server相关的元素。同时，您还必须考虑将来的增长需求。在SQL Server实例整合过程中，确定tempdb尺寸是一项重要工作。只有对所有数据库的增长方式进行全面跟踪时，才能够对磁盘容量的增长情况进行正确评估。

您需要使用多少物理磁盘来实现预期的性能指标呢？全面实现您所期望的性能或许是无法负担或不可行的。请记住，您所需要的原始空间可能不同于Windows和SQL Server所识别的实际空间。举例来说，如果您拥有一块73.8 GB的物理磁盘，经过格式化后，Windows究竟能够识别多大空间呢？您可能需要比原始计算结果更多的物理磁盘。

以下介绍了一个只读数据库示例：

假设一台物理磁盘驱动器每秒能够处理100个输入/输出操作。每次页面读取操作返回8 KB数据，每次预先读取操作返回64 KB数据。您拥有1000个用户，其中每个用户每秒需要取回0.250 MB信息，相当于每秒总共需要生成250 MB数据。假设60%的页面读取和40%的预先读取：

(60x8 = 480 kb) + (40x64  = 2560 kb)

等于所有驱动器需要提供总共3.040 MB/秒的吞吐率。将所需的数据总量除以驱动器吞吐率后得出，您的数据库需要83块独立磁盘来实现您所需要的吞吐率。

如需获取有关磁盘及其潜在性能问题的详细信息，请参阅Microsoft SQL Server高可用性（Microsoft出版社）的第4章和第11章。

收集其它系统统计信息

这部分内容列出了需要测量的SQL Server特定统计信息以及其它需要对比的常用数据，这些统计信息与数据将帮助您分析系统性能并就整合过程中最常遇到的问题做好准备。如需了解有关此处所列内容的详细信息，请参阅稍后的“规划事项”部分。

SQL Server

对于SQL Server 2000来说，服务器上的每个实例都拥有一套自己的计数器（对于命名实例通过“SQL Server：”或某种变化形式来标识）。以下为某些需要测量的最重要指标的顶级列表，您的运行环境可能需要监控更多或某些不同的计数器。如需获取有关SQL Server监控技术的更多信息，请参阅Microsoft SQL Server 2000高可用性的第15章。

•	SQL Server：常规统计信息：用户连接数（提供连接到SQL Server的用户数量）
•	SQL Server：高速缓存管理器：高速缓存命中率（提供针对SQL Server的高速缓存命中与查询比例，多数情况下，该计数器取值应在90%到100%之间）
•	SQL Server：数据库：事务/秒（提供每秒发起的事务数量，即可针对所有SQL Server实例，也可以针对每个独立数据库）
•	SQL Server：SQL统计信息：SQL重新编译/秒
•	进程：线程计数（针对每个实例监控此项数据）
•	磁盘I/O计数器（如需获取更多相关信息，请参阅Microsoft SQL Server 2000高可用性的第4章）
•	SQL Server：常规：用户连接数（提供特定时刻进入SQL Server实例的用户连接数，使用这个计数器来监控最大、最小及平均使用情况）
•	SQL Server：数据库：数据文件尺寸（KB）（提供与选定数据库相关的数据文件尺寸，由于您希望了解在整合后的运行环境中，使用系统数据库提供信息的每个安装实例的增长情况，因此，应对所有用户数据库以及tempdb和msdb 进行监控）
•	SQL Server：锁：死锁数量/秒（提供不同SQL Server实体在每秒内的死锁数量）
•	SQL Server：数据库：日志文件尺寸（KB）和/或日志文件使用尺寸（KB）（这些计数器提供日志文件的物理尺寸以及实际使用的空间，应针对服务器上的所有数据库设置这些计数器）
•	SQL Server：缓存管理器：过程高速缓存页面数
•	SQL Server：缓存管理器：页面总数
•	SQL Server：高速缓存管理器：高速缓存页面数

系统数据库

•	确定系统表中所有非缺省安装的对象。
•	确定系统表中自缺省安装后被修改过的对象。
•	寻找重复的名称。
•	在经过整合的运行环境中就连续相关性对所有对象进行审核。
•	审核所有对象以确定是否在更高粒度级别上存在重复现象。
•	审核所有对象的显式引用，如路径名称、服务器名称以及任务名称等。
•	在tempdb中搜索非缺省对象。
•	暂且不要关注tempdb的使用情况，这个问题将在稍后的“规划事项”部分中予以介绍。
•	暂且不要关注msdb中的任务，这个问题将在稍后的“规划事项”部分中予以介绍。

排序规则与排序顺序

•	确定源服务器排序顺序。
•	确定违背服务器排序规则设置的对象。

安全性

•	汇总并检测重复登录。
•	确定是否需要在域间建立信任关系。
•	确定guest是否为活动用户。
•	利用管理权限收集登录用户。
•	收集针对公共组的安全设置与权限。
•	确定是否需要特殊注册表权限。
•	确定扩展存储过程——特别是xp_cmdshell——需要哪些权限。
•	确定SQL Server服务在哪个系统帐号下运行。
•	理解安全模型与客户端实现方式。
•	对比源服务器和目标服务器的安全模型。
•	收集数据库选项，以便在迁移过程中确保只读单用户和仅供dbo使用的设置得以保持。
•	收集需要传输到新服务器上的加密口令。
•	汇总所有具有管理权限的NT及SQL登录。

服务器配置信息

•	确定各项SQL Server配置自安装后是否被修改过（与缺省设置不同）。
•	在迁移完成后对环境切换情况进行跟踪，主要在于确定是否需要应用纤程模式。
•	确定是否需要使用XML存储过程和OLE自动化对象。
•	确定在纤程模式下运行时哪些统计信息不够准确。
•	确定工作线程数目是否超出了为其分配的最大值。
•	收集被添加到sysmessages和sysservermessages中的错误消息。
•	确定由系统提供的错误消息是否被修改过。

现有运行环境

•	如果您尚未利用随MDAC 2.6一同提供的SQL Server 2000工具对客户端或应用程序计算机进行升级，那么，请验证MDAC 2.5或更早版本的客户端能够与SQL Server 2000的缺省实例建立连接。
•	收集需要与SQL Server命名实例进行连接的主机名称。
•	确定连接字符串采用硬编码方式的应用，其中包括诸如COM对象和ODBC数据源名称（DSN）这样的连接对象。
•	确定是否使用除TCP/IP之外的其它连接方式（不包括通过命名管道实现的内部连接）。
•	确定所有使用硬编码参数已知应用。
•	确定所有厂商不再提供支持的应用。
•	收集描述每种应用工作负载产生方式的信息。
•	确定中央服务器所处的域。
•	确定源服务器域。
•	确定连接源所处域。
•	收集中央服务器与所有连接源之间的信任关系。

健康检测

•	执行DBCC语句并在日志中扫描出错信息。
•	审核错误日志和事件查看器。
•	确定在面向用户社区开放运行环境前是否需要在高速缓存中添加某些过程。

多种版本

•	收集所有服务器版本、二进制代码和数据库兼容模式。

对tempdb的过度使用

•	确定源服务器tempdb数据库所使用的最大空间。
•	确定存储过程所使用的内存空间。

数据库选项

•	确定为源服务器上的设备分配了多少空间。
•	确定实际使用了多少空面。
•	确定事务日志最大使用了多少空面。
•	通过查看系统快照评估过去一周、一月、一季度、半年乃至一年的增长率。
•	分析源服务器上目前所采用的备份策略是否与目标服务器所采用的备份策略相一致。
•	确定是否具有非缺省的连接设置、ANSI设置或其它设置需求。
•	收集目前的数据库选项。

规划事项

这部分提供了必须在整合后的运行环境中予以考虑的深入规划事项：

单实例与多实例对比

磁盘子系统
内存
网络互连
处理器
安全与登录
高可用性
复制
对象迁移
管理
资金返回
系统数据库
排序规则与排序顺序
其它技术事项

一旦收集了针对每项要素的必要信息，您便可以执行制订合理规划方案所需的分析过程。

单实例与多实例对比

实例的概念是最先在SQL Server 2000中引入的。一个SQL Server 2000实例等同于在您的计算机上安装一套SQL Server。在SQL Server 2000发布以前，您只能在每台物理服务器上安装一套SQL Server。

在考虑有关整合的技术问题之前，您必须首先确定整合对象是拥有众多数据库的单一SQL Server实例，还是各自拥有一套数据库的多个实例。

实例类型有两种：缺省实例和命名实例。缺省实例类似于早期SQL Server版本的功能。SQL Server命名实例的准确描述为：一套具有唯一指定名称的SQL Server安装。SQL Server 2000最多能够在单一物理服务器上或Windows服务器群集中支持16个实例。这是在SQL Server 2000 32位版本下的测试与支持限制，就理论而言，唯一的限制因素便是您手中的资源。尽管如此，您只能使用一个缺省实例，因此，无法处理命名实例的旧应用可能会遇到问题。

每个实例拥有一套属于自己的核心代码，但所有实例共享一套诸如MDAC、Microsoft 分布式事务处理协调器这样的底层组件以及一套单一Microsoft搜索服务。因此，如果运行环境中存在多个SQL Server实例，那么，除共享组件外，每个实例可以维持自己的服务软件包级别。这是整合所带来的一项主要优势。然而，整合还会产生另外一个后果：针对某项共享资源的操作将会影响所有系统。举例来说，如果您需要安装一个物理重启后方可生效的SQL Server 2000服务软件包，那么，服务器上运行的所有其它服务都将受到影响。由于存在这种问题，在设计整合后的SQL Server系统时，必须同时考虑可用性和服务等级协议。

实例与性能

通常情况下，单一实例意味着较低的管理工作量。由于只需管理一个实例，SQL Server系统的复杂性可以轻松管理和局部化。同时，由于不存在其它相互竞争的进程，因此，单实例还可确保诸如使用动态内存这样的“自动”设置得以轻松实现。

多实例方式允许每个实例采用不同的规则和服务等级协议。同时，在各级系统设计与管理过程中，多实例还意味着更大的复杂性。您必须分析专用内存与独立进程（除共享组件外）所产生的优势对您所处的环境而言是否具有价值。

当您在单实例与多实例方式之间进行抉择时，有关磁盘I/O、处理器和内存的决策将成为关键要素。请参考本文的相关部分及其它参考资料，以确保将多种工作负载整合到单一物理服务器或服务器群集后（这种情况下为多个SQL Server 2000实例），这些负载能够良好的协同工作。您可以通过执行合理的性能规划以及应用可靠的性能指标来促进整合的成功。当您统计每个单独SQL Server安装实例的磁盘、处理器和内存使用情况时，您可以获取这些设备的使用情况快照。通过与从所有SQL Server安装中获得的信息相结合，您将了解到哪些工作可以完成，哪些工作无法完成，以及导致这些情况的原因。如果您正在向更高级的硬件设备上迁移，这些指标可能无法准确反映性能及系统使用情况，但它们至少可以为您提供一个可靠的起点。

举例来说，每个实例拥有自己的内存空间，其中包括用以存放存储过程的高速缓存。如果某个应用使用了大部分过程缓存空间，那么，它将会对其它存储过程的性能与可用性造成影响。因此，在整合过程中，您必须决定将数以百计的数据库部署在单一实例上，还是将这些数据库分散部署到多个实例上（本文稍后的“内存”部分中将就这一问题展开深入讨论）。

针对实例的应用兼容性

SQL Server 2000的体系结构随着实例——特别是命名实例——的引入发生了本质上的改变。请确保对旧的应用进行全面测试，以保证无论您是否使用命名实例，它们均能够在SQL Server 2000环境下正常工作。

尽管从技术角度而言，命名实例并不需要通过MDAC 2.6（或更高版本）来允许应用和用户与SQL Server 2000命名实例正确建立连接（对命名实例的支持已被MDAC 2.6所引入），然而，如果您没有使用MDAC 2.6或更高版本，那么，这部分中稍后所列出的某些需要使用命名实例的领域可能会出现问题。如果您的应用无法与命名实例建立连接，那么，这里为您提供了一些故障诊断建议：

•	在负责托管应用的服务器上安装MDAC 2.6或更高版本，或者，如果应用程序直接由客户端运行，则应在每套客户端上安装该产品。随SQL Server 2000一同发售的MDAC 2.6提供了针对命名实例的支持能力。尽管如此，安装MDAC2.6并不能保证应用可以使用命名实例。在将应用滚动升级至大量用户前，建议您在一台或多台计算机上对每个应用进行测试。
•	在将客户端工具升级到SQL Server 2000后，应使用客户端网络实用工具的SQL Server 2000版本来为应用能够识别的命名实例创建一个别名。
•	如果无法将客户端工具升级为安装MDAC 2.6或更高版本的SQL Server 2000版本，请不要使用SQL Server命名实例的名称，而是直接与同该实例相关联的IP地址和端口号建立连接。同时，还应在客户端网络实用工具的SQL Server 7.0或6.5版本中配置别名。
•	升级应用代码以使其支持名称实例。如果应用已经包含了通过硬编码方式实现的服务器名称、数据库名称和应用路径，那么，您所面临的问题就不仅仅限于命名实例了。应用代码或许已经超出了整合项目的范围。由于应用缺乏灵活性，您或许将会面临迁移问题和可用性问题。

如果您要在缺省实例上维护所有旧应用，那么，这些应用很可能仍将按照现在的方式运行，尽管如此，对其进行必要的复查仍旧不失为明智的选择。

磁盘子系统

在确定您的系统是否能够使用多实例时，磁盘子系统的体系结构将成为其中的决定因素之一。磁盘体系结构将影响SQL Server从性能到可用性的各个方面。其基本规则为：物理驱动器的数量越多，在为I/O请求提供服务的过程中，您所遇到的冲突现象就会越少。然而，这种方式说起容易做起难。大量物理磁盘所涉及的资金将迅速成为制约因素。

您需要适当容量的磁盘空间，具体数值将由诸多因素来确定（其中包括数据规模、tempdb规模、日志规模、Microsoft 分布式事务处理协调器（MSDTC）使用情况、全文索引以及其它与磁盘相关的因素）。同时，您还必须考虑SQL Server二进制程序所占用的空间，由于这些二进制程序位于系统磁盘，因此，它们经常会被忽视。

假如存在相互冲突的I/O特征，您将如何对应用和数据库进行整合呢？这是各种规模的客户都将遇到的一项严峻挑战。与处理大量写操作和少量读操作的繁重OLTP系统相比，只读型报表数据库具有不同的I/O需求。请不要轻视这种配置上的差异：您可能最初通过整合节省一定资金，但如果整合后的应用性能不够理想，那么，整合后的运行环境将是失败的。

当您考虑磁盘解决方案的体系结构时，有关文件放置方式的决定将对性能与可用性产生巨大影响。无论如何，日志文件必须始终独立存放在单独的物理磁盘上。日志记录不同于由读操作或写操作构成的一般磁盘访问：如果条件允许的话，它将是一种连续的写操作，您永远不希望驱动器的磁头被抬起。将日志文件存放在其专用的磁盘上不仅能够提高性能，同时还能够提高可用性。如果数据库遭到破坏，但您拥有一套备份并且能够访问日志，那么，您通常可以将数据库恢复至故障发生点。尽管如此，请不要将多份日志存放在同一块驱动器上。由于日志操作所需要的是一种磁头始终不被抬起的连续写操作，因此，这种方式将扰乱原先的意图。如果您将多个日志存放在同一台驱动器上，根据具体活动情况，可能会对解决方案的性能及其它方面造成影响。从成本角度考虑，这种配置方式可能是不现实的，然而，由于1:1的磁盘与日志比例通常无法满足，因此，您必须了解相关风险并根据实际情况做出权衡（同时在技术方面和非技术方面）。

通常情况下，不建议将数据和日志所使用的备份文件存放在磁盘上。在数据或日志磁盘上执行备份操作将会降低实时数据库的性能。将备份文件——特别是大中型备份文件——写入到与本身具有繁重读写操作的系统共用的磁盘上肯定会对性能产生影响。结合您将诸如备份数据之类的更多文件存放在相同磁盘之前所统计的I/O操作次数，你将看到磁盘在操作过程中所需完成的工作。这里需要考虑的另一项因素是备份数据的物理存储空间需求。您是否具有足够的空间来存放备份数据呢？这些备份数据又将被放置在何处呢？

如果您能够利用磁盘子系统的高速缓存，那么，请对其进行配置，以使其能够与您的工作相匹配。同样，当您具有多种不同的工作负载时，这在整合后的运行环境中也将是一项非常艰难的工作。从另一个硬件设备的角度来看，您可以考虑使用不同的通道对I/O操作进行分割。

使用RAID同样会对可用性和性能有所帮助。带区镜像将为您提供优异的性能与可用性，但其成本将非常昂贵。对于多数运行环境而言，RAID 5是最常见的解决方案。然而，如果您的应用对I/O操作非常敏感，RAID 5可能并非最佳选择，这是因为它将降低可用性与写操作性能。从短期来看，购买另一套磁盘子系统似乎非常昂贵，但从长远角度而言，这种方式很可能会为您节省更多的资金。

在考虑过独立用户数据库后，您还应考虑在何处放置tempdb以及如何对其规模进行控制？您将不再只关心一个数据库的tempdb使用情况——您可能会拥有多个！这些因素对于整个部署的成功具有至关重要的作用。请确保tempdb的部署方式不会对其它数据库的性能产生影响。此外，应为tempdb设置合理的规模，以确保数据库不会因获取tempdb资源而不断增长。

显然，对于设计合理的配置方案而言，正确理解您的硬件设备是非常重要的。应与您所首选的硬件设备厂商保持协作，以购买并配置能够满足性能及可用性目标的磁盘子系统。

如需了解有关SQL Server 2000下配置磁盘子系统的详细信息，请参阅Microsoft SQL Server 2000高可用性的第4章内容。

内存

针对内存的需求在一定程度上取决于您的操作系统版本，这是因为每种操作系统版本都有自己的内存规范。正如整合的其它方面一样，您必须首先收集特定的基准测试指标以及应用/系统配置数据，以便根据您的内存需求做出准确决定。以下列出了某些需要查看的主要因素：

•	操作系统选项
•	过程高速缓存尺寸
•	扩展内存需求
•	如需了解有关内存的更多信息，请参阅Microsoft SQL Server 2000高可用性的第14章内容。

操作系统选项

根据您对总体内存需求的最初评估，您需要选择合适的操作系统。下表显示了SQL Server底层各种操作系统所支持的最大内存容量。

操作系统	最大内存支持能力
Windows 2000 Advanced Server	8 GB
Windows 2000 Datacenter Server	32 GB
Windows Server 2003企业版（32位）	32 GB
Windows Server 2003企业版（64位）	64 GB
Windows Server 2003 Datacenter Server（32位）	64 GB
Windows Server 2003 Datacenter Server（64位）	512 GB

如需获取有关确定操作系统配置方式的更多帮助信息，请参阅稍后的“处理器”部分。如需了解不同类型对象所消耗的内存空间，请参阅SQL Server联机丛书中的“SQL Server对象内存使用规范”。

过程高速缓存容量

在内存与SQL Server使用情况环节上，针对应用程序和数据库的主要考虑因素在于SQL Server的过程高速缓存使用情况。这项决定进而将确定在整合过程中采用单实例方式还是多实例方式。对于运行32位SQL Server的32位操作系统，您最多可以访问2.6 GB的过程高速缓存（精确容量同样取决于您所使用的内存选项及操作系统，如需了解详细信息，请参阅稍后的“32位高级内存需求”部分）。

如果您计划整合多套包含大量存储过程的数据库，那么，存储过程的运行范围很容易超出过程高速缓存。这项配置肯定会对性能产生影响，并且需要您针对多个实例进行规划。如果您尚且不知道是否面临这样的情况，那么，您将在测试阶段找到答案。

32位高级内存需求

整合后的运行环境通常需要2 GB以上的内存空间，这是32位SQL Server版本所提供的基本内存支持能力。如需访问2 GB以上的内存空间，则需应用不同的特定选项——其中某些基于操作系统，某些基于SQL Server。

如果您计划在整合方案中使用大量内存空间，应确保您所选择的配置方案中包含提供相应支持能力的硬件设备。请确保您所选择的硬件设备列于硬件兼容列表当中，并在厂商说明书中明确指明的相应功能。

正如前面“操作系统选项”部分中所描述的那样，您的操作系统选择将决定您能够利用的最大内存空间。由于32位内存寻址限制，标准Windows 2000操作系统（不支持寻址窗口扩展[AWE]特性）最多只能使用4 GB物理内存。缺省情况下，其中2 GB内存空间分配给操作系统专用，另外2 GB则为应用程序专用。由于这种限制，即便某台服务器配置了8 GB内存，除非设置相应的选项，否则，超过4 GB以上的空间实质上将无法使用。

您同时还必须做出一些配置决策，以确定为每个独立的SQL Server实例分配多少内存空间。首先，查看您当前安装的SQL Server使用多少内存空间。您应当在迁移之前掌握这些数字，以便将其与预期的内存使用情况关联起来。借助这些数字，您可以计算出整合后的工作负载，并最终获得特定实例所必需的最小内存空间。

如果您仅仅使用一个SQL Server实例，那么，很少会对内存有所关注。由于没有其它SQL Server实例会针对任何类型的资源（包括整体系统内存使用）展开竞争，因此，您仍需确保分配正确的内存容量。

多实例配置方案面对更多的挑战，与此相应，每个实例的配置难度也会有所增加。如果同时规划使用故障转移群集，那么，您还必须对每个实例在故障转移过程中的运行情况进行评估。

访问2 GB以上的内存

可以通过几种方式来访问2 GB以上的内存区域：

•	物理寻址扩展（PAE）（位于boot.ini文件中）允许所有版本的32位Windows操作系统访问4 GB以上的内存空间。/PAE参数通常与AWE一同使用（然而，由于AWD可以针对小于4 GB的内存空间进行设置，因此，AWD并不依赖于PAE）。
•	地址窗口扩展（AWE），作为操作系统配置与SQL Server配置相结合的产物，允许诸如SQL Server这样的应用程序在额外的物理内存空间中进行寻址。如果启用AWE，您必须设置允许实例使用的最大内存空间，同时，内存将不再是动态的。AWE并不需要PAE，但通常情况下两者一般共同使用。（SQL Server中的AWE可以在不使用PAE的情况下进行设置，然而，由于访问4 GB以下的内存可以通过其它方式来处理，因此，这样做没有任何实际意义）。
•	/3GB参数（位于boot.ini文件中）允许32位SQL Server实例使用最多3 GB的内存空间，并且始终为Windows操作系统保留1 GB的额外内存空间。您可以结合使用/3GB和AWE，但只有在对采取这种步骤的原因进行认真评估后方可实施。通常情况下，您只需使用两者之一。

以下表格根据您针对SQL Server使用情况配置的内存空间，汇总了扩展内存设置的配置方式。

内存需求
4 GB或更少	4 GB至16 GB	大于16 GB
/3GB开关	启用/3GB	禁用/3GB
	启用AWE	启用AWE
	启用/PAE	启用/PAE

说明：如果您启用了AWE或PAE内存，那么，我们强烈建议您在将服务器投入生产环境前对相关配置进行测试。同时，您最好不要在组合使用AWE和/PAE的情况下使用/3GB。请确保对您的配置方案与需求进行认真评估，并对其进行广泛测试。

这三种内存选项可以通过两种不同的机制来启动，这两种机制分别为：boot.ini文件和sp_configure存储过程。

boot.ini文件

/3GB参数以一个通过boot.ini文件启用的开关选项。一旦您安装Windows 2000 Advanced Server后，便可以修改boot.ini文件，并像以下示例中粗体部分所显示的那样，在路径中添加/3GB：

multi(0)disk(0)rdisk(0)partition(2)/WINNT="Windows 2000 Advanced
Server" /3GB /basevideo /sos

PAE同样可以通过boot.ini文件中的开关选项来启用。打开boot.ini文件，并像以下示例中粗体部分所显示的那样，在路径中/PAE参数：

multi(0)disk(0)rdisk(0)partition(2)/WINNT="Windows 2000 Advanced
Server" /PAE /basevideo /sos

AWE：地址窗口扩展

AWE是操作系统内建支持特性，它是一种用以向Win32®应用程序暴露扩展内存的方式。借助AWE，那些对内存非常敏感的应用程序现在可以在SQL Server 2000下以更高的效率运行，从而实现性能提升。Windows 2000 Advanced Server和Windows 2000 Datacenter Server引入了增强AWE API。AWE允许应用程序访问大量物理内存空间。由于32位内存寻址机制的限制，在未启用AWE的情况下，Windows NT® 4.0和Windows 2000最多只能使用4 GB物理内存。缺省情况下，其中2 GB内存空间分配给操作系统专用，另外2 GB则为应用程序专用。借助位于操作系统使用的boot.ini文件中的/3GB参数，诸如SQL Server这样的应用程序最多可以访问3 GB内存空间，同时，操作系统所使用的内存空间将减小为1 GB。此种情况下，即便某台服务器配置了8 GB内存空间，在引入AWE之前，4 GB以上的内存空间实际上仍旧无法使用。

AWE需要诸如SQL Server 2000这样能够通过API方式针对AWE进行特殊编码的应用程序来配合使用。SQL Server 2000中的AWE支持特性必须通过sp_configure 存储过程中的awe enabled 选项进行配置。这种选项应以实例为单位进行设置。缺省情况下，awe enabled选项被设置为0（关闭）。在SQL Server 2000中启用AWE支持同样需要某些额外的操作系统配置。如需获取更多相关信息，请参阅SQL Server联机丛书中的“AWE内存”。

sp_configure存储过程

正如以下示例所显示的那样，AWE将通过调用sp_configure的方式在一条SQL Server 2000查询语句中启用：

EXEC sp_configure 'awe enabled', 1
RECONFIGURE

当您实现AWE内存时，请考虑以下问题：

•	SQL Server实例无法动态管理所使用的内存地址空间规模。 当在SQL Server 2000中启用AWE时，如未设置最大服务器内存配置选项，SQL Server将占用所有可用内存空间（除128 MB允许基本操作系统功能使用外），从而潜在的阻碍操作系统及其它进程在同一台服务器上运行。
•	一旦被初始化后，AWE内存将控制启动时获得的所有物理内存空间，直到被关闭为止。 如果AWE被启用并且占据了过多的内存空间，必须停止SQL Server以便重新配置AWE，这将导致停机现象（使诸如故障转移群集这样的高可用性选项无用武之地）。由于SQL Server实例所使用的内存页面来自于Windows内存空间的不可分页池，因此，没有可供交换的内存空间。这意味着如果物理内存被填满，SQL Server将无法使用在物理磁盘上设置的分页文件来解决内存使用过度的问题。
•	一旦最大服务器内存选项被设置，请将工作集大小设置为0。

如需了解更多关于在服务器上配置AWE内存的信息，请参阅SQL Server联机丛书中的“在Windows 2000中使用AWE内存”以及本文后部的附录A——“技术资源”。如需获取更多关于群集与内存的信息，请查看附录A中所提供的示例与信息。

内存示例1：四个SQL Server实例（群集或独立方式）

无论是否以群集方式进行组织，SQL Server均只适用于对其可用的资源。请考虑以下示例：

您目前拥有四个SQL Server实例，其中每个实例当前消耗33%的服务器资源（在这个示例中，所消耗的资源仅代表内存，然而，您可以在某些情况下将这个示例扩展为包含处理器、磁盘等）。此后，您把四个工作负载整合到一个故障转移群集或一台单一服务器上。整合后的最大容量——100%——小于最初四台服务器独立容量之和（33% X 4，或132%）。

为匹配最初的容量，您需要使用多台服务器进行整合（例如在两台物理服务器上各自分配两个工作负载），或者在群集方式下配置两个以上节点。

内存示例2：内存与故障转移s

在前一个示例基础上，考虑具有两个节点的32位群集运行环境。每个节点上具有一个SQLServer 2000群集实例，总共使用两个SQL Server虚拟实例。通过AWE方式为每个实例分配7 GB内存空间（在每台服务器最多8 GB的范围之内）。

此后，当一个实例出现故障时，相应负载本应从一个节点转移至另一个节点，然而实际情况却并非如此。这究竟是为什么呢？其原因在于7 GB加7 GB并不等于8 GB，而是等于14 GB！正如前一个示例所演示的那样，您无法在不影响服务器性能的情况下超越100%的容量限制。同时，由于您在32位平台上启用了AWE，因此，无法对内存进行动态管理。

如欲实现您所期望的性能，您需要重新对每个实例进行配置，以便使两个实例均可在故障转移的情况下切换至同一系统下运行。您必须在允许两个实例外加操作系统正常工作的某一空间点上对内存进行封顶。即便需要进行分离，也应为每个实例分配3.5 GB内存空间，并为操作系统保留1 GB空间。

现在，在不启用PAE或AWE的前提下考虑同样的情况，此时，您将使用动态内存。类似的情况将会发生：当实例出现故障时，它将根据自身需要占用大量内存空间。如果您拥有两个或更多实例，并且所有这些实例都对内存非常敏感，那么，它们将相互竞争资源。在这种情况下，除非您能够确定故障转移不会导致性能冲击（除最初一次外），否则，应确保从物理上限制为每个实例分配的内存空间，以保证不会遇到故障转移问题。

64位内存利用方式

SQL Server的64位版本改变了传统的内存使用规则。借助SQL Server 2000 64位版，所有内存都将是动态的——您不会再受到2 GB内存的起始限制。在64位版本下，可以设置每个SQL Server实例所使用的最小内存空间，这将是所需使用的最小内存空间，同时，可以利用动态内存来处理内存需求。在某些情况下，您可能需要设置一个最大值。无论通过何种方式，64位版本均为您开辟了一个全新的资源利用与整合时代。

说明：无论使用启用AWE的32位实例或是64位实例，都需要花费一段时间对您所指定的内存空间进行归零。请将这一时间考虑在内，特别是在使用故障转移群集的情况下。

网络互连

当您对系统进行整合时，更多的网络通信量将会转向同一套SQL Server。为制订出处理新型网络互连需求的有效决策，您需要了解通常在不同时刻（特别是最大负载条件下）与SQL Server建立连接的并发用户数量。

就内存而言，除常规SQL Server使用过程中所消耗的内存空间（如过程高速缓存、查询等）外，您还必须考虑所有网络连接。每个连接将消耗12 KB内存，此外还需外加网络数据包的尺寸并乘以三倍：

12 + (3 x 数据包大小) = 连接内存需求

这种计算方式将帮助您确定整合为单一实例或多个实例。

一旦掌握每套数据库的用户连接所占用的内存空间后，还应对网络带宽进行检测。请考虑以下问题：您所设想的网络互连规划能否处理服务器所流入/流出的网络负载？举例来说，假设您拥有一块10 MB的网卡，但您的总体吞吐量需求却为20 MB。您是否需要添加新的网卡和IP地址呢（两者将在一定程度上增加系统开支）？

或者，您是否需要使用具有更高带宽的网卡并确保网络自身能够处理这样的负载呢？

其它网络互连方面的问题还包括：

•	端口使用情况 每套SQL Server安装分别使用哪个TCP/IP端口？在安装过程中，SQL Server将占用一个动态分配的端口，而并不一定是原先SQL Server版本所使用的1433端口。这种端口分配方式在一定程度上是由支持实例造成的，因为多个实例无法共享同一个端口。通常情况下，第一个实例（命名实例或缺省实例）将使用1433端口。同时，UDP 1434端口将为SQL Server保留。您可以使用服务器网络实用工具为每个实例分配一个已知的静态端口。
•	域连通性 SQL Server安装是否需要域连通能力（故障转移群集），或者，其是否拥有需要使用其它SQL Server实例的进程（诸如日志传送）呢？是否所有SQL Server安装均位于相同的域中呢？域的混用可能会在整合过程中导致某些问题。
•	域帐号 您是否拥有使用域帐号作为服务帐号的SQL Server安装，或者说，这些服务是否使用仅与特定服务器相关的本地管理员帐号呢？这些安装是否均位于相同域中呢？有多少台服务器使用本地服务帐号？在整合过程中，您可以通过对管理帐号和连通性实时标准化的方式来解决这些问题。 然而，通过这些方式对您的配置实现标准化仍旧无法解决所有权问题：举例来说，对象所有权，或SQL Server代理作业的执行方式是由用户来分配的。这些更为复杂的问题还需要解决。

处理器

当确定新增服务器所需的处理器数量时，需要考虑某些因素。就像磁盘和内存那样，为做出准确的决策，您必须收集基准测试与应用/系统配置数据。这里列出了需要考虑某些主要因素：

•	处理器相似性 出于整合的目的，处理器相似性允许您将特定SQL Server实例限制在服务器上可用处理器的某个子集当中。举例来说，如果您的服务器拥有四颗处理器，那么，你可以限制SQL Server仅使用其中三颗。为限制特定实例的处理器使用方式，请使用SQL Server的相似性掩码选项。（如需了解更多关于相似性掩码选项的信息，请参阅SQL Server联机丛书中的“相似性掩码选项”部分。）这种方式（在很大程度上）将防止单一SQL Server实例消耗所有可用资源且只留下少量可供其它实例使用的资源。这个选项是一把双刃剑。其负面影响在于，如果没有其它工作负载能够利用尚未使用的性能空间，那么，剩余资源将始终处于空闲状态。因此，在使用处理器相似性之前，应认真评估使用处理器相似性可能对处理器分配管理产生的影响，其中包括无法充分利用资源的潜在负面影响。
•	连接相似性 该特性允许某个实例始终将一套客户端连接定向至特定SQL Server调度程序，并由该调度程序对可用处理器上的线程分派情况进行管理。连接相似性只能在极少情况下实现明显的性能提升。使用连接相似性所带来的负面影响类似于前面讨论的处理器相似性。如果使用不慎，连接相似性将会导致所有可用资源无法得到充分利用。
•	并行度 如果您正在将某个应用从一套配备一至二颗处理器的系统移植到配备六至八颗处理器的系统，以期提高处理能力，那么，由于采用新的执行计划，每次查询的执行方式将会发生变化。在此种情况下，您可能需要修改最大并行度选项以及相似性掩码选项的设置。在执行此项操作时，请格外小心，因为通过这种方式整合多个负载时，对上述两个选项的调节将会直接影响在该实例上运行的所有功能。
•	仅使用SQL Server参数 除唯一一种特殊情况外，请不要使用SQL Server以外的其它工具来管理您的处理器资源。其它工具可能无法产生您所希望的效果。所有与处理器相关的调整都应通过SQL Server参数来完成。唯一一种例外情况是在Windows Server 2003中使用Microsoft Windows系统资源管理器（WSRM），但这种工具仅用于配置特定SQLServer实例所能使用的处理器百分比。

根据实际处理器需求，您需要选择合适的操作系统。可供选择的操作系统包括32位和64位两种版本。除每种版本所支持的处理器数量外，考虑32位处理器与64位处理器之间处理能力的差别同样非常重要。您的决策依据应不仅仅限于处理器速度，同时，您所看到的实施效果也会各不相同。请记住，64位处理器无法保证您的应用执行速度提高十倍，甚至两倍也很难保证。在64位平台上对您的应用进行测试是唯一能够真正显示在64位平台上实施效果的方式。

以下表格显示了SQL Server依托的每种操作系统所支持的最大处理器数量。

操作系统	处理器数量
Windows 2000 Advanced Server	8
Windows 2000 Datacenter Server	32
Windows Server 2003 Enterprise Edition（32位或64位）	8
Windows Server 2003 Datacenter Server（32位或64位；您至少需要配备8颗处理器）	64

如需获取更多有关确定操作系统设置的帮助信息，请参阅本文前面“内存”部分中的“操作系统选项”。

安全与登录

安全性是一个显而易见的关注焦点。在此方面，是否存在面向所有需要整合的应用、数据库及服务器的不同标准呢？如果存在的话，它们之间是否存在相互冲突的现象呢？或者，举例来说，您或许需要使用IPSec技术，但您正在向一个无法在故障转移情况下支持IPSec的群集进行整合（查看附录A以参考相关知识库文章），因此，该应用可能需要进行修改或排除在整合范围之外。

在整合过程中，应用及用户如何实际登录并访问SQL Server是需要关注的最主要安全领域。用户迁移可能会消耗大量规划时间。本文前部“网络互连”章节中已经提到了域连通性和域帐号，但这里主要关注于实际登录过程。您是否拥有混用Windows身份验证模式和混合模式的服务器呢？在对工作负载进行整合时，这些服务器是否会带来风险呢？

同样，在SQL Server 6.5及其更早版本之后，安全性得到了一些修改。SQL Server 7.0引入了角色的概念，从而使您需要重新考虑针对特定应用程序的安全性实现方式。这种现象可能导致您陷入本应避免的范围蔓延怪圈，因此，如果会阻止整合工作的正常进行，请不要考虑或实现新的安全计划。

以下列出了一些需要考虑的登录问题：

•	为登录和用户迁移的规划、测试与实施留出足够时间。与生成脚本并将其应用到目标运行环境相比，这是一项更为消耗时间的工作：您需要梳理整个登录过程，以确保提供正确的登录方式，并废除旧的登录方式。
•	仅为用户提供他们所需的权限。假设您在SQL Server级别上拥有一个名为JoeJ的登录帐号，该帐号具备某台数据库服务器上的系统管理权限，另一台数据库服务器上的常规用户权限，以及位于第三台服务器上的某个特定数据库的dbo权限。所有这些权限在您整合到少量服务器后是否依然适用呢？您是否希望JoeJ在这些实例上拥有系统管理权限呢？在整合过程中，您肯定不希望无意中为某个用户分配不必要的权限。因此，在整合工作负载时，请认真考虑这一问题。
•	整合后的系统将不允许不同数据库服务器上的多个用户使用相同的登录名称。截止到目前为止，这还未构成任何问题。您应通过良好的沟通方式来解决这一问题。
•	不要允许同一个用户在正在进行整合的不同服务器上维护不同的口令。您可以分配一个新的口令，选择当前所使用的口令之一，或要求用户自己选择一个口令。
•	考虑BUILTIN/ADMINISTRATORS登录。您是否需要使用这个帐号呢？您目前是否已经从所有安装中将其删除？如果您尚未将其删除，但正在考虑这样做，那么，这样做将会产生哪些影响呢？是否需要应用某些第三方软件产品呢？
•	整合意味着可能将会有更多用户连接到服务器。您需要为公用和来宾登录帐号分配哪些权限呢？
•	您的系统中可能包含大量非活动或过期登录帐号，诸如过去的员工等。整合过程中应只迁移那些处于活动状态的登录帐号。请注意，登录帐号的添加与删除将会影响事务日志。
•	如果您的系统采用Windows身份验证模式，是否登录操作来自不同的域呢？您是否需要在Windows级别上建立双向信任关系呢？
•	如果使用数据库的应用程序目前通过sa帐号进行访问，那么，则需要对其进行评估。由于sa用户享有对SQL Server上所有数据库的完整访问权限，因此，应用程序不应使用该用户帐号。一种通常采用的SQL Server最佳安全实现方式是不允许具有系统管理权限的帐号访问所有无需相应权限的用户或应用。只要应用所使用的用户拥有相应数据库的dbo权限，多数情况下，已经足以完成管理任务并在该数据库中执行所需的各项操作。
•	您是否因服务器滚动升级而在Windows Server实例上锁定组策略呢？这对整合后新的运行环境将会产生哪些影响？举例来说，如果符合最终预期目标，您是否会锁定群集所需的策略呢？

高可用性

整合的一个重要目的便是提高SQL Server解决方案的可用性。作为内建功能特性，SQL Server 2000提供了两种实现高可用性的基本方式：故障转移群集和日志传送。在某些情况下，复制机制也可用于实现可用性。

故障转移群集是实现可用性的一种最佳方式。它能够在出现问题时自动将负载转移到另一台服务器上。故障转移群集的规划与配置与整合的规划过程非常类似，同样需要考虑处理器、内存和磁盘的使用情况。故障转移群集与整合的另一个相似之处在于通过相同的方式在单一平台上实现可用性，同时可以通过一定数量的节点——加入服务器群集的服务器——来实现可用性。故障转移群集使您得以更加轻松的规划整合工作。举例来说，如果您采用由四个节点构成的群集，假设未出现任何故障并且有更多的内存可供使用，那么，您将能够更好的平衡各项资源（参见本文前面的“内存”部分）。

SQL Server 2000企业版需要使用故障转移群集。下表列出了SQL Server 2000企业版在每种运行SQL Server 2000的Windows操作系统版本上所支持的节点数量。

Windows操作系统	SQL Server 2000所支持的最大节点数量
Windows 2000 Advanced Server	2
Windows 2000 Datacenter Server	4
Windows Server 2003 Enterprise Edition（32位）和Windows Server 2003 Datacenter Server（32位）	4
Windows Server 2003 Enterprise Edition（64位）和Windows Server 2003 Datacenter Server（64位）	8（要求使用64位SQL Server版本）

如果您业已实现了某种形式的高可用性配置，例如故障转移群集或日志传送，那么，这种高可用性配置同样需要在整合规划过程中予以考虑。举例来说，如果您正在使用具备日志传送特性的数据库，那么，在整合后的运行环境中，是否仍将对日志进行传送呢？或者，您是否会对日志传送任务进行整合，以便将多个数据库复制到备份服务器上呢？这种整合将会对可用性产生哪些影响？

如需了解更多关于SQL Server 2000高可用性的信息，请参见附录A“技术资源”。

复制

如果将要进行整合的数据库上配置了复制操作，您还需将复制机制作为整合规划的一部分。每套数据库，或发布服务器需要一套与之对应的分发服务器。然而，在整合后的运行环境中，1:1的发布服务器与分发服务器比例可能是不切实际的。因此，您需要进行某些前端性能规划，以确保一台分发服务器能够处理多台发布服务器。根据实际使用的处理器和内存情况，特别是您所实现的复制类型，磁盘I/O性能将受到很大影响。同时，这还意味着分发服务器需要位于一个完全独立的实例或者（多数情况下）一台不同的服务器上，以便确保其性能与可用性不受影响。

您也可以考虑使用远程分发服务器。面向不同发布服务器的远程分发服务器可以整合到同一SQL Server实例下，但每台发布服务器的分发数据库应当互不相同。在未经整合的运行环境中，具备发布服务器和分发服务器的实例或许可以被接受，然而，这种方式在整合后的运行环境中却是无法接受的。

同时，您还必须考虑基本快照目录及其在每台发布服务器上的位置。您希望在每个SQL Server实例上共享同一个快照目录还是使用第二个快照目录呢？

同样需要考虑的还有订阅服务器，因为在您移植发布服务器和分发服务器以及在整合过程中禁用复制功能时，它们也将受到影响。

除具有少数不同的变量外，复制（或日志发送）整合非常类似于数据库整合。

对象迁移

在所有升级、迁移或整合工作中，最艰巨的任务之一便是对象的迁移，这些对象包括警告、SQL Server代理作业以及DTS包等。

您可以轻松针对警报、作业和运算符编制脚本。然而，在将这些脚本应用到经过整合的SQL Server之前，必须确保其中不存在命名冲突。当您迁移到新的服务器时，应在相应用户与每个SQL Server代理作业之间建立关联。

您可以通过几种方式将DTS包迁移到其它服务器上，其中包括将其保存为文件形式或对其进行重建。如果对DTS包进行移植时，请不要假设它们仍将按照以前的方式运行——您可能需要对其进行一定的修改。此外，还应确保这些DTS包能够与您当前使用的SQL Server版本相互兼容：从SQL Server 7.0 Service Pack 1开始，Microsoft对SQL Server 7.0 RTM和Service Pack 1中的包格式进行了调整。由于这种格式调整是随Service Pack 2一起引入的，您可能必须在SQL Server 2000下完全重建这些包。请记住，应在测试阶段留出专门的时间来测试并修正此种类型的问题。

说明：如需获取能够帮助您对这些对象进行迁移的资源列表，请查看附录A“技术资源”。

重要提示：64位SQL Server版本无法运行DTS包。您可以在32位SQL Server 2000下针对64位实例执行DTS包。如需了解相关信息，请参阅SQL Server联机丛书64位版本中的“64位版本与32位版本之间的差别（64位）”，以及Windows文档中“64位Windows Server 2003产品家族成员中的不可用特性”。

管理

在实施迁移工作前，请考虑以下因素，它们将对整合完成后每个SQL Server实例的最终管理方式产生影响：

•	在将经过整合的全新服务器上线投产前，必须对所有服务器设置进行协调。每个单独的SQL Server实例可能都会有其自己的设置，每项设置都会通过各种方式对数据库产生影响，因此，当整合完成时，最终的全局服务器设置将发挥至关重要的作用。
•	与此相似，如果您使用某种启动选项，那么，同样需要重新对其进行调解。
•	对于msdb中所包含的诸如复制或SQL Server代理作业这样的元素，您是否拥有仍旧合法并且需要进行迁移的历史记录呢？
•	在添加多个数据库或实例后，您的维护计划需要进行怎样的修改？举例来说，您的整个企业备份策略需要进行哪些调整？是否某项备份操作会与其它备份操作产生冲突并对性能产生影响？面向服务器的维护窗口是否会因负载的增大而变小？
•	观察msdb增长情况，因为对于许多数据库而言，其大小会随状态和历史记录的不断写入（取决于您所使用的SQL Server功能）而不断增大。

资金返回

资金返回是根据硬件设备利用率进行成本评估的过程，根据评估结果，商业单位或客户可以支付相应的费用。如果需要考虑资金返回，那么，您将有几种候选方案。其中之一是使用SQL Server，其具体使用方式包含在附录B“利用SQL Server实现资金返回”中。此外，某些来自第三方的工具（诸如来自Aurema的ARMTech）也可帮助您针对系统资源使用情况完成成本核算。

系统数据库

系统数据库是整合过程中的一个重要考虑事项。系统数据库中包含与整套服务器安装相关的数据和结构。不同于相互独立的用户数据库，系统数据库自身之间以及与来自源服务器的用户数据库之间具有密切的关联关系。

如何对master、model和msdb这些系统数据库进行配置呢？现在，您需要整合多台服务器，其中每台服务器上都具有自己的数据库拷贝，由于最近一次恢复操作将覆盖前一个拷贝，因此，您将无法恢复多个拷贝。请记住，msdb中包含您的所有作业、警报和运算符（以及某些功能的历史记录），该数据库的大小应至少包含45 MB空间、每个实例所需的额外空间以及大约10%的剩余空间。

除以上所提到的空间需求外，您还需要对master、model和msdb进行分析，以检测重复的数据库对象并为其编制文档。这种分析将从登录、存储过程、用户定义数据类型与任务扩展到特定的对象类型。举例来说，一个具有相同名称的对象将针对特定源服务器代表或执行某种操作，或者，一个具有不同名称的对象将代表或执行在服务器级别上进行修改的某种操作。当针对这些数据库登录以外的功能进行过修改后，这项工作将变得极为困难。请切记包含所有启动存储过程。

您必须确定不属于标准SQL Server成员的修改或新增对象。请认真核查整合后运行环境所涉及的每种对象。确定是否在更高粒度级别上存在重复现象。查看针对每个对象的显式引用，例如路径名称、服务器名称及任务名称等。请不要考虑位于msdb中的任务，这些任务将独立进行处理，并且必须由其自身完成处理工作。此外，应只在tempdb中搜索非缺省对象（tempdb的使用方法将在本文稍后的“排序规则与排序顺序”部分中进行介绍）。

排序规则与排序顺序

将要进行整合的所有服务器之间的排序规则与排序顺序必须在整合过程中予以考虑。与众多独立服务器相比，具有不同排序规则的数据库更容易在整合后的运行环境中实现共存。某些应用依赖于数据库的排序规则与排序顺序设置。因此，在迁移到经过整合的运行环境后，您可能会遇到无法预期的结果。如果应用程序设置不当，在切换到经过整合的运行环境后，它们将无法正常工作。

如果Transact-SQL语句中并未包含排序规则子句，那么，在tempdb中创建的临时表将应用tempdb的排序规则设置。大小写不敏感SQL Server实例中的口令在存储或使用之前将被转换为大写。而大小写敏感SQL Server实例中的口令则不会转换为大写。由于存在这种差异，除非口令中的所有字母均为大写，否则，最初在大小写敏感服务器上加密的口令在转移到大小写不敏感服务器后将无法使用。

如需了解这种转换方式的更多相关信息，请参阅SQL Server 6.5或7.0版联机丛书中的“排序顺序改变对口令的影响”，或者参阅SQL Server联机丛书中的“选择排序规则”。

其它技术事项

这部分将介绍本文其它部分未涉及到的迁移前技术注意事项：

•	链接服务器 您目前是否使用链接服务器来支持整合后将不复存在的服务器之间的连接与查询？您是否正在修改将会对链接服务器产生影响的域？如果您将要进行整合，那么，整合将会对应用产生何种影响？查询是否需要进行重写？您将如何迁移链接服务器设置？
•	共享资源 正如前面已经数次提到的那样，诸如MS DTC和用以驱动全文检索的底层Microsoft搜索服务这样的特定资源将在所有实例甚至其它应用程序当中加以共享。当您添加更多需要利用共享资源的数据库和资源时，资源共享将成为整合后的运行环境所关注的问题之一。
•	升级与迁移规则 针对常规应用和数据库的升级规则与迁移规则将在整合过程中继续得到应用。请不要忘记考虑诸如DBCC之类特性的运行问题、日志审核问题以及统计信息的更新问题，并在移植数据库前将其解决。同时，还应记住，根据物理布局（整合后SQL Server数据文件与日志文件的存放位置），您对某一数据库所进行的操作可能会对其它数据库产生影响。
•	系统表 如果您对某些系统表进行过修改，那么，这些修改可能无法在整合后的SQL Server中正常工作。同时，Microsoft也不建议您对系统表进行修改，或向诸如msdb 和master这样的系统数据库中添加对象。请将您所创建的所有定制化内容及对象放置在用户数据库中。
•	排序规则与排序顺序冲突 当前的SQL Server实例与整合后的SQL Server运行环境之间是否存在排序规则与排序顺序冲突？如果规划人员、实施人员与DBA之间缺乏沟通，这将是个很容易被忽略的问题。应在整合开始前解决所有冲突现象。
•	扩展存储过程 将要进行整合的数据库是否使用扩展存储过程？如果使用的话，这些扩展存储过程将对其它数据库和其它潜在实例产生何种影响？请记住，扩展存储过程非常类似于通过编码实现的应用程序，因此，如果扩展存储过程存在内存泄漏现象，同时您将多个应用整合到同一个SQL Server 2000实例上，那么，您可能会将其它应用置于危险境地。
•	服务软件包 服务软件包是整合后运行环境所需关注的一大主要问题。如果您的一套SQL Server位于某一服务软件包级别上，而另一套SQL Server位于不同的服务软件包级别上，这种情况允许吗？借助SQL Server 2000，您可以针对各个相互独立的实例应用混合服务软件包级别，但所有共享组件（如MDAC）均必须采用最新版本。尽管如此，对于Windows Server 2003，您必须使用SQL Server 2000 Service Pack 3或更高版本。这将肯定会对发生在各种版本Windows Server 2003操作系统上的整合工作产生影响。举例来说，如果您拥有三个在Windows 2000下安装的实例，这三个实例分别使用SQL Server 2000 Service Pack 1、SQL Server 2000 Service Pack 2和SQL Server 2000 Service Pack 3。这种情况下，所有共享二进制程序及文件必须处于SP3级别，但各个独立的数据库和无需进行共享的二进制程序仍可维持各自的服务软件包级别。
•	XML存储过程 纤程模式不支持XML存储过程，因此，请采用线程模式或独立实例来避免出现6604错误。

SQL Server整合工具

根据您所入手的SQL Server版本，各种不同的内建SQL Server工具将在整合过程中为您提供帮助。除此之外，诸如用以开放执行迁移操作的时间窗口等其它需求也将帮助您选择所需使用的工具。无论您决定使用何种工具，您都应认识到，每种工具均有其自身需要考虑的注意事项。

SQL Server 6.5至SQL Server 2000

SQL Server 6.5与SQL Server 2000的数据库格式互不兼容。当您的整合计划中包含从SQL Server 6.5向SQL Server 2000进行迁移时，您将无法通过备份/恢复的方式在目标SQL Server 2000实例上创建数据库。在规划从SQL Server 6.5进行迁移时，您可以考虑使用平面文件或升级向导：

对于平台间的数据迁移，使用平面文件是一种经过检验的可靠方式。BCP（大容量复制程序）实用工具自4.21a版本后便一直包含在SQL Server中，目前，这种工具不仅提供命令行版本，同时还提供Transact-SQL命令BULK INSERT。在某些情况下，同使用升级向导相比，采用平面文件的方式将更加易于规划，换言之，将更为可靠。举例来说，对于这种迁移方式，您必须在SQL Server 2000中创建所有大小合适的数据库，并设计一套流程来迁移用户。BCP只关心数据的迁移。诸如索引及视图之类的其它元素则必须在批量插入后重新创建，这是因为在插入数据前配置索引可能会降低处理速度。

SQL Server 2000提供了一种用以帮助您从SQL Server 6.5进行迁移的内建升级向导。这种升级向导考虑到了包括用户在内的SQL Server 6.5各方面配置情况。然而，升级向导并不适用于所有针对SQL Server 2000的迁移。如需了解更多关于升级向导使用方式的信息，请参阅SQL Server联机丛书中的“从SQL Server 6.5升级数据库（升级向导）”。

SQO Server 7.0至SQL Server 2000

如果您正在从SQL Server 7.0向SQL Server 2000进行迁移，将有更多方式可用您选择。

•	备份与恢复 无需进行过多介绍。您可以生成一个SQL Server 7.0备份并在SQL Server 2000下对其进行恢复，恢复过程将对数据库进行升级并完成诸如重建统计信息之类的工作。
•	BCP和BULK INSERT 与其在SQL Server 6.5或2000数据库下的工作方式完全相同。您可以使用平面文件向数据库中导入数据。如果使用BCP或BULK INSERT，您必须通过其它方式来导入用户、对象及其它非核心数据对象。
•	复制数据库向导 利用SQL Server的附加与分离功能来执行迁移操作。数据库文件将被分离、复制并附加到目标服务器上。当您从SQL Server 7.0向SQL Server 2000进行迁移时，附加过程将把数据库升级到SQL Server 2000；然而，在此过程中，统计信息将不会自动重建。当您在备份/恢复和复制数据库向导之间做出选择时，这一点可能会成为一项考虑因素。同样，如果排序规则在SQL Server实例之间存在差异，特别是当您拥有国际应用时，您必须协调这种差异或考虑不对其进行整合。（举例来说，如果您使用char或varchar 数据类型，您将无法存储或读取除目标SQL Server上代码页所含内容以外的其它数据；Unicode将成为一个工作区。）
•	借助日志传送特性，可以从SQL Server 7.0 SP2数据库向SQL Server 2000数据库发送并应用事务日志。这是一种更好的迁移方式，它不仅可以通过保留源数据库原封不动的方式提供回退计划，同时还能将停机时间控制在最短范围内。

SQL Server 2000至SQL Server 2000

在从SQL Server 2000向SQL Server 2000迁移的过程中，从SQL Server 7.0向SQL Server 2000进行迁移的方式同样有效。由于所有数据库处于相同版本（除服务软件包有所差别外）且无需进行升级，您只需完成少量工作。您仍旧需要关注排序规则和服务软件包，然而，由于是从一个引擎版本最终迁移至相同的引擎版本，因此，整体服务器运行方式与功能差异以及语法上的变化不会对您产生过多影响。

返回页首

小结

从上层管理到最终用户，整合是一项有益于各个层次的工作。有鉴于此，整合的范围非常广泛，它将对整合后系统的各个方面——不仅仅是技术方面，还包括人员及过程方面——产生影响。尽管如此，您不应仅仅为了整合而进行整合：而是应当制订正确的决策。合理的规划与测试是确保最终成功的唯一方式。对于某些独立的系统，您最好仍旧使其保持独立状态。掌握每套系统的基本信息将大大提供工作效率，并有助于您对运行环境更加深入的进行理解。整合的最终结果应当是经济效益、人力资源以及技术领域等各个方面的全面胜利。

如需获取更多相关信息：

http://www.microsoft.com/sql/

返回页首

附录A：技术资源

案例研究

•	明尼阿波利斯市
•	马克•安东尼集团

整合链接

•	SQL Server 2000伸缩性/整合项目
•	http://www.microsoft.com/windowsserversystem/ articles/consolidation/default.mspx
•	http://www.unisys.com/services/server__infrastructure __services/architecture/consolidation/index.htm
•	http://www.microsoft.com/windows2000/ datacenter/evaluation/features/aurema/default.asp
•	硬件兼容列表

常规SQL Server与Windows

•	SQL Server 2000安全白皮书
•	SQL Server 2000资源工具包（同样由Microsoft出版社以实用工具光盘的形式发布）
•	SQL Server 2000操作指南
•	SQL Server 2000故障转移群集白皮书
•	Microsoft SQL Server 2000虚拟服务器基本安装、维护与服务软件包安装，Web广播
•	事务复制性能调节与优化
•	更新SQL Server 2000联机丛书（可下载）
•	更新SQL Server 2000联机丛书（Web方式）
•	Microsoft SQL Server 2000高可用性（Microsoft出版社 ISBN 0735619204）
•	TechNet .NET Server专区
•	TechNet Windows群集资源专区（包括如何执行滚动服务器群集升级）
•	PAE设计方案
•	AWE白皮书

有用的Microsoft技术支持知识库文章

说明：知识库文章将会经常更新或添加，因此，请定期搜索http://support.microsoft.com以查找适用于您所处运行环境的有用文章。

常规硬件设备/Windows/群集

•	在Windows Server中添加Eight LUNS以外的支持能力
•	针对附加到相同SAN设备上的多群集支持能力
•	网络数据库文件支持能力
•	面向服务器群集的Microsoft支持策略与硬件兼容列表
•	Windows群集与地理分散的站点
•	如何扩展群集共享磁盘分区
•	不适用于服务器群集磁盘资源的动态磁盘配置
•	如何手工重建群集服务帐号
•	配置能够在防火墙下工作的RPC动态端口分配方式
•	在您限制远程过程调用的可用IP端口后，群集服务可能无法启动
•	在Windows 2000和Windows XP上限制TCP/IP端口
•	网络适配器组合与服务器群集
•	Microsoft群集服务安装资源
•	如何域控制器不可用，群集服务可能无法启动
•	作为域控制器的Windows 2000群集节点

内存

•	Windows 2000中的Intel物理寻址扩展（PAE）特性
•	在PAE模式下运行时，SQL Server 2000或Windows 2000备份将无法查看
•	Windows 2000不支持大容量内存
•	当内存超过4 GB且开启PAE特性时，转储文件将无法正确创建
•	4 GB RAM调优特性与物理地址扩展开关描述

移植数据库

•	在运行SQL Server的计算机间移植数据库
•	在RESTORE语句中使用WITH MOVE选项
•	通过分离/附加方式将SQL Server数据库移植到新位置
•	利用BACKUP与RESTORE命令将SQL Server 7.0数据库移植到新服务器上
•	确定合理的SQL Server配置方式

登录

•	如何在SQL Server间转换登录与口令
•	在SQL Server间移植数据库时如何解决权限问题
•	联机丛书中的“孤儿用户故障诊断”部分内容不够全面
•	PRB：在利用不同的排序顺序从SQL Server 6.5升级到7.0后，口令将无法使用

DTS

•	DTS包开发、部署与性能
•	DTS导入/导出向导或TransferObjectsTask无法维持传输对象的文件组设置
•	DTS对象传输机制无法传输大于64 KB的BLOB数据

SQL邮件

•	如何配置SQL邮件
•	无法在协同使用群集虚拟SQL Server的情况下全面支持SQL邮件
•	当您在纤程模式下运行服务器时，SQL邮件将无法得到支持
•	常见SQL邮件问题
•	当SQL Server运行在轻量级池模式下时，DTC事务可能会失败

防病毒软件

•	运行SQL Server计算机上的病毒扫描程序注意事项
•	防病毒软件可能导致群集服务出现问题

日志传送

•	针对日志传送配置安全性
•	SQL Server 2000日志传送常见问题与解答

故障转移群集

•	如果计算机名称过长，群集环境中的SQL Server安装过程将会遇到违规访问的问题
•	如何在SQL虚拟服务器上变更服务帐号
•	如何阻止Windows NT管理员对群集中的SQL Server进行管理
•	IsAlive检查在BUILTIN/Administrators帐号环境下无法运行
•	如果SQL Server IP地址被修改，SQL Server 2000群集可能无法与端口相互绑定
•	SQL Server虚拟服务器客户端连接必须由客户端进行控制
•	SQL虚拟群集服务器无法与其所监听的端口相关绑定
•	Microsoft群集服务器上的SQL Server 2000企业版安装顺序
•	重建或移植SQL故障转移群集所使用的MSDTC
•	如果在Windows 2000域控制器上进行安装，虚拟SQL Server 2000安装可能会失败

安全性

•	基于Windows 2000服务器群集上的Kerberos支持能力
•	群集化SQL Server中带有虚拟名称的证书使用问题
•	配置IPSec以处理受信任和不受信任的域身份验证
•	针对使用Microsoft管理控制台的SQL Server 2000启用SSL加密
•	针对使用证书服务器的SQL Server 2000启用SSL加密

返回页首

附录B：利用SQL Server实现资金返回

这部分内容将向您介绍如何利用SQL Server及其相关工具来实现资金返回。整个解决方案涉及两个存储过程：sp_ChargebackProc和sp_ChargebackAnalysis，其代码将在稍后为您提供。

第一步——安装存储过程

审核过程所需使用的两个存储过程为sp_ChargebackProc和sp_ChargebackAnalysis。sp_ChargebackProc通过注销事件完成实际审核工作，这种注销事件可用于捕获每个用户连接期间的读操作、写操作和CPU利用情况。对于每个用户连接，假设用户最终会在某一时刻注销，因此，都会有一条相应的注销记录被捕获。对于永久连接，这一事件不会捕获到任何信息。跟踪所需消耗的开支约占5%左右。

sp_ChargebackAnalysis 将帮助您分析由sp_ChargebackProc所生成的跟踪报告。

为使SQL Server能够轻松使用存储过程，请在msdb中创建它们。

第二步——配置sp_ChargebackProc

sp_ChargebackProc 存储过程必须在SQL Server上线前启动。为实现这一目标，请执行以下Transact-SQL语句：

exec sp_procoption @ProcName='sp_ChargebackProc',@OptionName='startup',
@OptionValue='true'

sp_ChargebackProc 向外部文件名中写入审核注销数据。为使其正常工作，您必须对该存储过程进行配置。如需了解详细信息，请查看稍后列出的代码。可配置的选项包括跟踪文件位置、跟踪文件名称等。

该存储过程针对每次注销操作捕获以下跟踪事件：EventClass（这里为审核注销）、DatabaseID、NTUserName、HostName、ClientProcessID、ApplicationName、LoginName、SPID、Duration、StartTime、Reads、Writes、CPU、DBUserName和ServerName。

每个用户连接都应对应一个注销事件。如果用户连接始终未被注销，那么，除非通过KILL命令强行注销该用户连接，否则，针对该用户的利用率信息将被忽略。

sp_ChargebackProc将在跟踪开始、停止或跟踪文件重命名时向错误日志中写入消息。如果sp_ChargebackProc 运行时跟踪文件名已经存在，那么，它将自动对该文件进行重命名，在创建新的跟踪文件前添加YYYYMMDD.HH.MM后缀，并记录事件以及与其相关联的登录名称。

说明：请确保sp_configure 中的扫描启动进程选项被设置为1，以便使该存储过程能够在启动时执行。为启用该选项，您必须停止并启动SQL Server。

第三步——利用sp_ChargebackAnalysis分析跟踪文件

一旦生成跟踪文件后，您需要对其进行分析。资金返回分析可以通过多种方式来完成，例如应用程序或NTUserName。sp_ChargebackAnalysis负责将跟踪文件装载到SQL Server中并执行资金返回分析。sp_ChargebackAnalysis的参数包括@TraceID、@TraceFile和@TraceAggegateBy。

•	@TraceID 用以显示指定traceID的跟踪信息。在开始进行分析前，必须通过以下方式停止并删除相应的traceID： execute sp_trace_setstatus 1,0 -- stops traceID 1 execute sp_trace_setstatus 1,2 -- removes traceID 1
•	@TraceFile用以准备资金返回分析报告。在通过sp_ChargebackAnalysis 读取跟踪文件之前，必须首先停止并删除跟踪（参见前文）。
•	@TraceAggregateBy 能够根据“数据库”，“ntusername”或“应用”来分解利用率信息（读取、写入及CPU）。利用率报告中将包含读操作、写操作、总体I/O、I/O百分比、CPU及CPU百分比等明细信息。

以下为部分sp_ChargebackAnalysis执行示例及其相应的输出：

查看完整尺寸图像

exec sp_ChargebackAnalysis NULL,'c:/MyLogoutTrace.trc','application'
exec sp_ChargebackAnalysis NULL,'c:/MyLogoutTrace.trc','ntusername'
exec sp_ChargebackAnalysis @traceFile='c:/MyLogoutTrace.trc'
,@traceAggregateby='database'

告诫

当您实施这种资金返回解决方案时，您必须考虑某些因素，以确保资金返回根据您的要求进行：

•	为确保审核注销事件的发生，用户连接必须被注销（或断开连接）。kill命令可用以触发注销事件。而SQL Servre停机则不会触发注销事件。
•	在sp_ChargebackProc中定义外部跟踪文件名。如果当sp_ChargebackProc运行时跟踪文件名已经存在，那么，它将自动对该文件进行重命名，并在创建新的跟踪文件前添加YYYYMMDD.HH.MM后缀。
•	如果跟踪文件已被SQL Server使用，那么，该文件将无法通过sp_ChargebackAnalysis进行分析（装入到SQL Server中）。举例来说，如果跟踪程序正在将审核注销事件写入跟踪文件，那么，此跟踪文件将无法装入到SQL Server中。在将跟踪文件装入SQL Server前，所有引用该文件的跟踪程序均必须通过以下语句停止并卸载： execute sp_trace_setstatus 1,0 -- stops traceID 1 execute sp_trace_setstatus 1,2 -- removes traceID 1
•	可以通过以下语句之一显示当前已经定义的所有跟踪： execute sp_ChargebackAnalysis select * from ::fn_trace_getinfo(Default)
•	轻量级池，也称作纤程模式，将无法通过这个存储过程正确捕获。此种情况下，需要采用资金返回的某种替代方式。

Sp_ChargebackAnalysis

create proc sp_ChargebackAnalysis (
      @traceId int=NULL
      ,@traceFile nvarchar(1000)=NULL
      ,@traceAggregateBy varchar(100)=NULL)
as
-- Author:    T. Davidson, SQL Server Development Customer Advisory Team
-- Description:    SQL Server Audit Logout events are traced to a file for
chargeback utilization.
-- Notes: A trace file cannot be analyzed (e.g. loaded into SQL Server) by
sp_ChargebackAnalysis
--    if the file is already in use by SQL Server. For example, if a
trace is writing audit logout
--   events to a trace file, it cannot be loaded into SQL Server.  Before
a trace file can be
--   loaded by SQL Server, any trace referencing it must be stopped and
removed using:
--        a.   execute sp_trace_setstatus 1,0   -- stop traceID 1
--        b.   execute sp_trace_setstatus 1,2   -- remove traceID 1
set nocount on
-- if no traceId provided, display all traces
declare @totIO Numeric(20,1)
   ,@totCPU Numeric(20,1)
   ,@totReads Numeric(20,1)
   ,@totWrites Numeric(20,1)
   ,@trc_cnt int
if @traceId is NULL and @traceFile is NULL
begin
   print 'please provide either @traceID or @traceFile parameters'
   print 'example: execute sp_ChargebackAnalysis
NULL,''c:/logout.trc'',''database'' '
   select *
   into #traceDefs
   from ::fn_trace_getinfo(default)
   select @trc_cnt = count(*)
   from #traceDefs
   where Property=1
   print convert(varchar(10),@trc_cnt)+' traces are currently defined
for this server: '
   if @trc_cnt > 0
   begin
      select traceId,traceFile=convert(nvarchar(1000),Value)
      from #traceDefs
      where Property=2
      print 'you must stop the trace before you can load the
traceFile'
      print 'Example of stopping a traceID: execute
sp_trace_setstatus @traceID,0'
      print 'then you must remove the trace before you can load the
traceFile'
      print 'Example of removing a traceID: execute
sp_trace_setstatus @traceID,2'
   end
   return 200
end
if lower(@traceAggregateBy) not in ('database','ntusername','application')
begin
   print 'chargeback can be aggregated by either: database,NTUserName,
or application'
   print 'example: exec sp_ChargebackAnalysis
NULL,''c:/data/logout.trc'',''NTUserName'' '
   return 100
end
if @traceFile is NULL and @traceId > 0
begin
   select *
   into #traceDef
   from ::fn_trace_getinfo(@traceId)
   select TraceId,TraceFile=convert(nvarchar(1000),Value)
   from #traceDef
   where TraceId=@traceId
   and Property=2
   print 'you must stop the trace before you can load the traceFile'
   print 'Example of stopping a traceID: execute sp_trace_setstatus
@traceID,0'
   print 'then you must remove the trace before you can load the
traceFile'
   print 'Example of removing a traceID: execute sp_trace_setstatus
@traceID,2'
   return -99
end
if @traceFile is not null
   begin
   --you may want to create a permanent table in another database
   --drop table traceFile
   print '**** Chargeback Analysis by '+@traceAggregateBy + ' ****'
   SELECT * INTO #traceFile
   FROM ::fn_trace_gettable(@traceFile, default)
   select @totReads = 1+sum(reads)
      ,@totWrites = 1+sum(writes)
      ,@totIO=1+sum(reads+writes)
      ,@totCPU=1+sum(cpu)
   from #traceFile
   if lower(@traceAggregateBy) = 'database'
   select 'breakdown by database'=substring(db_name(DatabaseId),1,30)
      ,percentIO=cast(100*sum(reads+writes)/@totIO as numeric(20,1))
      ,totIO=sum(reads+writes)
      ,reads=sum(reads)
      ,writes=sum(writes)
      ,percentCPU=cast(100*sum(cpu)/@totCPU as numeric(20,1))
      ,cpu=sum(cpu)
   from #traceFile
   group by DatabaseId
   order by DatabaseId
   
   if lower(@traceAggregateBy) = 'ntusername'
   select 'breakdown by NTUserName'=substring(NTUserName,1,30)
      ,percentIO=cast(100*sum(reads+writes)/@totIO as numeric(20,1))
      ,totIO=sum(reads+writes)
      ,reads=sum(reads)
      ,writes=sum(writes)
      ,percentCPU=cast(100*sum(cpu)/@totCPU as numeric(20,1))
      ,cpu=sum(cpu)
   from #traceFile
   group by NTUserName
   order by NTUserName
   if lower(@traceAggregateBy) = 'application'
   select 'breakdown by application'=substring(ApplicationName,1,30)
      ,percentIO=cast(100*sum(reads+writes)/@totIO as numeric(20,1))
      ,totIO=sum(reads+writes)
      ,reads=sum(reads)
      ,writes=sum(writes)
      ,percentCPU=cast(100*sum(cpu)/@totCPU as numeric(20,1))
      ,cpu=sum(cpu)
   from #traceFile
   group by ApplicationName
   order by ApplicationName
end
go

Sp_ChargebackProc

/************************************************************/
/* Created by: SQL Profiler
*/
/* Date: 12/30/2002  02:20:51 PM
*/
/* Revision 1 - TD:  Rollover file option added to sp_trace_create
*/
/* Revision 2 - TD:  must run Sp_procoption to make proc auto execute */
/*                    during server startup
*/
/* Revision 3 - TD:  add automatic trace stop & removal
*/
/* Revision 4 - TD:  add automatic trace file rename -
*/
/*      appending date (yyyymmdd) & time (hh.mm)*/
/* Revision 5 - TD:  add raiserror log messages
*/
/************************************************************/
Create proc dbo.sp_ChargebackProc
as
-- Create a Queue
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
declare @TraceLive int
declare @user nvarchar(128)
set @maxfilesize = 1
-- Please replace the text c:/MyLogoutTrace,
-- with an appropriate filename
-- prefixed by a path, e.g., c:/MyFolder/MyTrace. The .trc extension
-- will be appended to the filename automatically. If you are writing from
-- remote server to local drive, please use UNC path and make sure server
has
-- write access to your network share
-- option value of 2 means rollover files with _n appended to the filename
--   e.g. c:/MyLogoutTrace_1 will be created when trace file >
@maxfilesize and so on
declare @traceFile nvarchar(128),@traceFilePath nvarchar(128),
@traceFileFullName nvarchar(128)
declare @appendname varchar(20),@cmd varchar(200)
select @user = loginame
from master..sysprocesses
where spid = @@spid
select @traceFilePath = N'c:/', @traceFile= N'MyLogoutTrace'
select @traceFileFullName = @traceFilePath+@traceFile
-- check to see if trace file is active.  if active, must be stopped,
removed, and renamed
select    @traceID=traceid
   ,@traceLive=count(*)   -- if trace file not active, returns 0
from ::fn_trace_getinfo(default)
where value = @traceFileFullName
and property = 2
group by traceid
if @traceLive > 0  -- > 0 means trace file is in use. stop and remove
trace      
begin
   exec @rc=sp_trace_setstatus @traceId,0   -- stop trace
   if (@rc=0) raiserror ('Trace %d to %s stopped by
%s',10,1,@TraceID,@TraceFileFullName,@user) with log
   else raiserror ('Chargeback trace %d stop attempt
failed',10,1,@TraceID) with log
   exec @rc=sp_trace_setstatus @traceID,2   -- remove trace
   if (@rc=0) raiserror ('Chargeback trace %d removed by
%s',10,1,@TraceID,@user) with log
   else raiserror ('Chargeback trace %d removal failed',10,1,@TraceID)
with log
end
--    rename previous trace file, appending today's date and time
(yyyymmdd.hh.mm)
select @appendname =convert(varchar(20),getdate(),112) + '.' +
onvert(varchar(2),getdate(),14) + '.' +
substring(convert(varchar(20),getdate(),14),4,2)
set @cmd = 'rename ' + @traceFilePath + @traceFile + '.trc ' + @traceFile
+ @appendname + '.trc'
exec @rc=xp_cmdshell @cmd
if (@rc = 0) raiserror ('Trace file %s renamed to
%s%s%s',10,1,@traceFileFullName,@traceFilePath,@TraceFile,@appendname)
with log
--   create new chargeback trace
exec @rc = sp_trace_create @TraceID output, 2, @traceFileFullName,
@maxfilesize, NULL
if (@rc != 0) goto error
-- Client side File and Table cannot be scripted
-- Set the events
declare @on bit
set @on = 1
exec sp_trace_setevent @TraceID, 15, 3, @on
exec sp_trace_setevent @TraceID, 15, 6, @on
exec sp_trace_setevent @TraceID, 15, 8, @on
exec sp_trace_setevent @TraceID, 15, 9, @on
exec sp_trace_setevent @TraceID, 15, 10, @on
exec sp_trace_setevent @TraceID, 15, 11, @on
exec sp_trace_setevent @TraceID, 15, 12, @on
exec sp_trace_setevent @TraceID, 15, 13, @on
exec sp_trace_setevent @TraceID, 15, 14, @on
exec sp_trace_setevent @TraceID, 15, 16, @on
exec sp_trace_setevent @TraceID, 15, 17, @on
exec sp_trace_setevent @TraceID, 15, 18, @on
exec sp_trace_setevent @TraceID, 15, 40, @on
-- Set the Filters
declare @intfilter int
declare @bigintfilter bigint
-- filter out application named 'SQL Profiler'
exec sp_trace_setfilter @TraceID, 10, 0, 7, N'SQL Profiler'
-- Set the trace status to start
exec sp_trace_setstatus @TraceID, 1
-- display trace  id for future references
raiserror ('Chargeback trace %d to %s started by
%s',10,1,@TraceID,@TraceFileFullName,@user) with log
goto finish
error:
-- if the traceFile already exists, this will fail with ErrorCode=12
select ErrorCode=@rc
finish:
go

返回页首

附录C：系统配置工作表

由于您可能无需使用所有相关技术，或者，您可能已经具备了某些文档，因此，您可能无需使用这部分提供的所有工作表。

商务工作表

填写这两部分商务工作表将帮助您完成非技术性分析——整合项目中商务决策制订方面的问题已在本文前面的“整合基础”部分中进行了讨论。

当前年度数据库费用

属性	取值
目前雇用的DBA数量（薪酬方式或承包商）
数据库服务器总数
数据库总数
数据库与DBA之间的比例
每名DBA平均每小时的费用
每名DBA每年的工作小时数

属性	DBA所投入的小时数	费用（一般为每小时费用乘以DBA所投入的小时数）
当前所有数据库系统（或将要进行整合的数据库系统）的年度许可证费用
执行备份所花费的小时数
培训/筹备所花费的小时数
故障诊断所花费的小时数
监控所花费的小时数
性能调优所花费的小时数
实现安全性所花费的小时数
数据库规划与设计（包括架构）所花费的小时数
灾难恢复所花费的小时数
其它DBA任务所花费的小时数
总体费用

预期数据库费用收益

属性	当前费用	预期费用	实现整合/技术后导致费用降低/收益增加的原因
所有数据库系统（或将要进行整合的数据库系统）的年度许可证费用
执行备份所花费的小时数
培训/筹备所花费的小时数
故障诊断所花费的小时数
监控所花费的小时数
性能调优所花费的小时数
实现安全性所花费的小时数
数据库规划与设计（包括架构）所花费的小时数
灾难恢复所花费的小时数
其它DBA任务所花费的小时数
总体费用S

系统信息工作表

通过填写这部分列出的所有系统信息工作表，您将收集到本文前面“技术任务与注意事项”部分中所讨论的特定系统基本技术信息。

基本系统信息

如果目标系统拥有两个以上IP地址，请分别针对每套IP属性完成基本系统信息部分。

属性	取值
服务器名称
域名
处理器数量
处理器类别与类型
内存总量与内存类型（如RDRAM、SDRAM等）
操作系统版本（其中包括服务软件包版本以及条件允许情况下的构建编号）
IP地址 1
NIC制造厂商
NIC型号
NIC驱动程序版本
IP 1子网
IP 1——更多信息	网络名称： 若为群集的一部分，请填写以下内容： 仅供客户端访问（公用网络） 所有通信（专用及公用网络） 仅供内部群集通信（专用网络）
IP 1所对应的NIC速度	10 100 其它 取值：
IP地址 2
IP 2子网
IP 2——更多信息	网络名称： 若为群集的一部分，请填写以下内容： 仅供客户端访问（公用网络） 所有通信（专用及公用网络） 仅供内部群集通信（专用网络）
IP 2所对应的NIC速度	10 100 其它 取值：
DNS信息
WINS信息
系统中当前配置并运行的应用
页面文件位置
页面文件大小
网络类型（T1、56k等）
高级安全性	Kerberos SSL IPSEC
该服务器是否为域控制器？	是 否 如果是的话： PDC BDC
若为PDC/BDC，组总数
若为PDC/BDC，用户总数
是否配置了AWE/PAE/3GB？
配置日期
位于服务中的日期

服务器群集信息

如果目标系统属于服务器群集，请填写服务器群集信息部分。

属性	取值
群集名称
群集IP地址
群集IP子网
节点数量
群集域管理员帐号
群集域管理员口令
MS DTC网络名称（NT4）
MS DTC IP地址（NT4）
MS DTC子网（NT4）

网络负载平衡群集信息

如果目标系统属于网络负载平衡（NLB）群集，请填写网络负载平衡群集信息部分。

属性	取值
群集名称
群集IP地址
群集IP子网
服务器总数
NLB设置

磁盘配置工作表t

通过填写这部分提供的所有磁盘配置工作表来收集针对特定服务器的磁盘配置信息，且无论这些磁盘位于系统内部或外部。

基本磁盘信息

属性	取值
系统名称
内部驱动器数量
每台物理驱动器容量
物理驱动器速度
磁盘类型	IDE SCSI 混合

SQL Server磁盘信息

属性	取值
是否使用文件/文件组？	是 否
每套数据库的详细文件/文件组配置

外部阵列信息

针对系统中的每套外部阵列复制并填写外部阵列信息。

属性	取值
外部阵列类型（SAN/DAS）
制造商
型号
驱动器版本
磁盘子系统类型（SCSI/Fibre）
物理驱动器总数
每台物理驱动器容量
物理驱动器速度
所使用的LUN/分区/卷数量
是否与其它系统和/或应用程序共享阵列？	是 否
磁盘高速缓存容量
磁盘高速缓存设置（例如读/写比例）

详细磁盘配置信息

填写针对系统中每台磁盘驱动器的表格。在以下表格的各列当中，逻辑磁盘用以标识操作系统所使用的驱动器盘符。分区/LUN/卷标识或数量为磁盘子系统中特定LUN的数量或标识。每个LUN可能包含多个逻辑磁盘。LUN所使用的物理驱动器数量为用以创建LUN的阵列中的驱动器数量。RAID级别为LUN所采用的RAID类型。总空间为可供逻辑磁盘使用的驱动器空间总量。当前空闲空间为逻辑磁盘上所有文件使用的驱动器磁盘空间总量。用途将详细描述特定逻辑驱动器的特殊用途。

系统名称：

	C:/	D:/	E:/	F:/	G:/	H:/
逻辑磁盘
分区/LUN/卷标识或数量（如果位于SAN或DAS上）
LUN所使用的物理驱动器数量
RAID级别（未使用时填写N/A）
总空间
当前空闲空间
所使用的文件和文件组
用途

	I:/	J:/	K:/	L:/	M:/	N:/
逻辑磁盘
分区/LUN/卷标识或数量 （如果位于SAN或DAS上）
LUN所使用的物理驱动器数量
RAID级别（未使用时填写N/A）
总空间
当前空闲空间
所使用的文件和文件组
用途

	O:/	P:/	Q:/	R:/	S:/	T:/
逻辑磁盘
分区/LUN/卷标识或数量（如果位于SAN或DAS上）
LUN所使用的物理驱动器数量
RAID级别（未使用时填写N/A）
总空间
当前空闲空间
所使用的文件和文件组
用途

	U:/	V:/	W:/	X:/	Y:/	Z:/
逻辑磁盘
分区/LUN/卷标识或数量（如果位于SAN或DAS上）
LUN所使用的物理驱动器数量
RAID级别（未使用时填写N/A）
总空间
当前空闲空间
所使用的文件和文件组
用途

SQL Server信息工作表

填写SQL Server信息工作表的相关部分以记录特定服务器的SQL Server配置信息。

基本SQL Server信息

属性	取值
SQL Server版本
SQL Server实例名称/类型（若为SQL Server 2000）	名称： 实例类型： 缺省实例 命名实例 若为命名实例，实例名称：
实例数量（若为SQL Server 2000且每台服务器上具有多个实例）
SQL Server二进制程序存放位置
SQL Server管理员帐号（连同域名）
SQL Server管理员口令
SQL Server代理管理员帐号（连同域名）
SQL Server代理管理员口令
身份验证模式	Windows 混合 若为混合模式，SA口令：
许可模式	以座席为单位 以处理器为单位 取值：
所需SQL服务	SQL Server代理 SQL Server全文
内存分配	动态 静态 数量：
所使用的处理器数量

SQL Server故障转移群集信息

如果配置了故障转移群集，请填写SQL Server故障转移群集信息部分。

参数	取值
虚拟服务器名称（对于所有版本）
IP地址1
所使用的网络（IP 1）
IP 2子网
所使用的网络（IP 2）
所分配的数据/日志磁盘（一个在安装过程中使用，其它作为附属在安装完成后添加）
群集定义/首选所有者顺序（虚拟服务器定义节点部分）
磁盘附属

SQL Server日志传送配置信息

如果配置了内建日志传送特性，请填写SQL Server日志传送配置信息部分。请根据您所使用的日志传送特性版本对工作表加以定制。

参数	取值
作为维护计划的一部分对数据库进行备份
主服务器名称
辅助服务器名称
需要进行日志传送的数据库（主服务器上）
用以存储备份文件的目录（应为合法的UNC名称）
在每个数据库的UNC下创建一个子目录
定期删除特定时间以前的事务日志文件
备份文件扩展名（缺省为TRN）
备份目录的网络共享名称
事务日志目标目录（应为辅助服务器上的合法UNC）
创建并初始化新的数据库
数据库负载状态
终止数据库中的用户连接
允许数据库假定主要角色
执行完整备份（如果不使用现有数据库）
使用最新备份文件（如果不使用现有数据库）
事务日志备份计划（缺省为每15分钟一次）
复制/载入频率（缺省为15分钟）
载入延迟（缺省为0分钟）
文件保留周期（缺省为24小时）
备份警报阈值
丧失同步警报阈值
日志传送监控服务器
监控服务器身份验证模式
生成一份报告
限制sysdbmaintplan_history表中的历史记录条目数量

SQL Server复制配置信息

如果配置了复制功能，请填写SQL Server复制配置信息部分。请针对每种复制类型填写此类信息。

参数	取值
当前服务器是否为发布服务器、分发服务器、订阅服务器或这几种服务器的组合？
复制类型	事务 整合 快照
发布类型（推送、请求）
频率

性能信息工作表

性能信息工作表将帮助您记录与性能相关的统计信息。

常规系统性能信息

参数	取值
总体处理器利用率
每颗处理器的处理器利用率
内存使用总量
处理器数量与类型
RAM容量与类型

网络性能信息

包括整合前后针对每套数据库所收集的信息。

参数	取值
网络接口：数据包/秒
网络接口：发送数据包/秒
网络接口：接收数据包/秒
网络接口：输出队列长度
NIC数量与类型

磁盘性能信息

包括物理磁盘与逻辑磁盘的映射关系以及整合前后的物理数据文件布局。

参数	取值
物理磁盘：平均读队列长度
物理磁盘：平均写队列长度*
物理磁盘：磁盘读操作/秒
物理磁盘：磁盘写操作/秒

SQL Server性能信息

参数	取值
最低内存使用量
最高内存使用量
最小并行连接数量
最大并行连接数量
处理器利用率
数据库增长情况（每个数据库的详细信息、增长率以及增长量，例每月10%）

其它应用程序性能信息

参数	取值
最低内存使用量
最高内存使用量
最小并行连接数量
最大并行连接数量
处理器利用率
数据库增长情况（每个数据库的详细信息、增长率以及增长量，例每月10%）

选定查询性能

对于每套系统而言，查询语句的定义将对系统性能产生至关重要的影响。请分别在原始系统及整合后的系统中对这些查询语句的执行计时。通过这种方式测得的数据将为您查看以上所收集的统计数据提供依据。请注意，为区分数据库服务器性能和整体应用性能，应通过脚本或查询分析器来执行这些查询语句，而不应从应用程序中来执行。

每条查询或每个脚本对应一条记录	取值
查询或过程名称 执行时间 查询执行期间整台服务器上的每秒处理的SQL Server事务总数（或每秒的批量请求数）
查询或过程名称 执行时长 查询执行期间整台服务器上的每秒处理的SQL Server事务总数（或每秒的批量请求数）
查询或过程名称 执行时长 查询执行期间整台服务器上的每秒处理的SQL Server事务总数（或每秒的批量请求数）

版权所有

本文档所提供的信息资料仅代表Microsoft公司在信息发布当日就所讨论问题持有的临时观点。鉴于Microsoft公司必须针对瞬息万变的市场状况不断做出相应调整，故而，本文档内容不应被解释为Microsoft方面所做出的任何承诺；与此同时，Microsoft也无法在发布之日后继续保证文件所含信息的准确性。

本文档仅供用于信息参考目的。Microsoft并未在本文档中提供任何形式的保证、明示或暗示。

遵守所有适用版权法律是文档使用者所应承担的义务。Microsoft公司虽未在版权保护下就与本文档相关的权利做出任何限定，但是，任何人未经Microsoft公司书面授权许可，均不得出于任何目的、以任何形式、利用任何手段（电子、机械、影印、录音等）将本文档的任何组成部分制作成拷贝、存储或引入检索系统、亦或向任何对象进行传送。

Microsoft公司可能就本文档所涉及的主题拥有专利、专利申请、商标、版权或其它形式的知识产权。除非已同Microsoft公司签订书面许可协议，并根据协议条款获得明确授权，任何出示本文档的行为均无法使您具备针对上述专利、商标、版权或其它知识产权加以利用的许可权限。

© 2003年，Microsoft公司。版权所有，保留所有权利。

Microsoft、SQL Server、Win32、Windows和Windows NT均系Microsoft公司在美国和/或其它国家所拥有的注册商标或商标。

本文档所涉及的其它公司和产品的真实名称均为其各自所有者持有的商标。