SQL Server 构架概述

Microsoft® SQL Server™ 2000 由一系列相互协作的组件构成，能满足最大的 Web 站点和企业数据处理系统存储和分析数据的需要。SQL Server 构架概述部分的主题描述了各种组件通过何种方式发挥合力，更富成效地管理数据。

主题 | 描述
SQL Server 2000 的特性 | 重点描述 Microsoft SQL Server 2000 的各项功能。
关系数据库组件 | 描述 SQL Server 2000 中主要的关系数据库组件，包括数据库引擎本身和应用程序与数据库引擎间通信所涉及的组件。
数据库构架 | 描述 SQL Server 数据库中定义的逻辑组件，以及如何在数据库文件中真正实现这些组件。
关系数据库引擎构架 | 描述服务器引擎的各项功能。这些功能使服务器引擎得以高效地处理大量并发用户的数据要求。
管理构架 | 描述 SQL Server 2000 附带的易用工具和 SQL Server 的动态配置功能如何最大程度地减少日常管理任务。
复制构架 | 描述 SQL Server 2000 的复制组件以及如何使用这些组件在数据库间分发数据。
数据仓库和联机分析处理 | 描述数据转换服务 (DTS) 和 Microsoft SQL Server 2000 Analysis Services，以及这些服务如何帮助生成和分析数据仓库或数据集市。
应用程序开发构架 | 描述 SQL Server 2000 如何支持各类数据库编程 API，使用户能够创建可靠的数据库应用程序。
实施细则 | 提供实施细则，例如：Transact-SQL 语句的最大容量、SQL Server 配置选项的范围、SQL Server 对象的内存使用以及 Microsoft SQL Server 不同版本间的差异。


SQL Server 2000 构架基础知识

Microsoft® SQL Server™ 2000 由一系列产品组成，不仅能够满足最大的数据处理系统和商业 Web 站点存储数据的需要，还能为个人或小企业提供易于使用的数据存储服务。

如今，企业或政府部门对数据存储的要求非常复杂。以下是一些示例：

  • 联机事务处理 (OLTP) 系统必须能够同时处理上千份订单。

  • 越来越多的公司正在实施将大型 Web 站点作为一种商业途径，顾客可以通过网络输入订单、联系服务部门和获取产品信息，而许多过去必须与雇员联系才能完成的任务也可以通过网络来处理。这些网站需要安全的、与 Web 紧密集成的数据存储。

  • 有些组织对重要业务，例如人力资源规划、生产资源规划和库存控制采用现成的软件包。这些系统要求数据库能够存储大量的数据和支持众多的用户。

  • 有些组织的用户必须在没有联网的情况下继续工作。例如，正在旅行的销售代表或地区视察员因移动而中断了与网络的连接。这些用户必须使其笔记本或膝上型电脑中的数据与公司系统的当前数据保持同步，与网络断开连接，在现场记录工作结果，然后重新与公司网络连接，将自己的现场工作结果合并到公司数据存储中。

  • 管理人员和市场营销人员需要对公司数据中记录的趋势作更为复杂的分析。他们需要可靠的联机分析处理 (OLAP) 系统，这些系统能够很容易地通过 OLTP 数据生成，并支持复杂的数据分析。

  • 独立的软件供应商 (ISV) 必须能够通过专门针对个人或小型工作组而开发的应用程序来分配数据存储能力。这意味着对于购买了该应用程序的用户而言，数据存储机制必须是透明的。这就要求数据存储系统可由应用程序配置，然后系统自身可以自动调整，用户不需要专门的数据库管理员不间断地监视和调整应用程序。


SQL Server 2000 组件概述

下面的关系图说明了 Microsoft® SQL Server™ 2000 主要组件间的关系：

SQL Server 2000 为在 Windows® DNA 环境下的应用程序提供了两项基本服务：

  • SQL Server 2000 关系数据库引擎是一个流行的、具有高度可伸缩性和高度可靠性的数据存储引擎。该数据库引擎将数据存储在表中。每个表上都列出组织感兴趣的一些对象，例如交通工具、雇员或顾客。每个表上的列表示由表建模的对象的属性（如重量、名称或价钱），而表上的行则代表由表建模的这种对象的事例（例如车牌号为 ABC-123 的轿车或雇员 ID 为 123456 的雇员）。应用程序可以将结构化查询语言 (SQL) 的语句提交给数据库引擎，后者将表格格式的结果集返回给应用程序。SQL Server 支持的特定 SQL 语言称为 Transact-SQL。应用程序还可以提交 SQL 语句或 XPath 查询，并请求数据库引擎以 XML文档形式返回结果。

    关系数据库引擎具有高度的可伸缩性。SQL Server 2000 企业版可以支持多组数据库服务器相互协作，构成可供上千用户同时访问的 TB 大小的数据库。该引擎能够处理世界上任何 Web 站点的流量。该数据库引擎还能自我调节，自动在连接到数据库的用户增多时获取资源，并在用户注销后释放资源。这表明较小的 SQL Server 版本可用于无需专职数据库管理员的个人或小型工作组。SQL Server for Windows CE 甚至将 SQL Server 编程模型扩展到与网络断开的移动用户所使用的 Windows CE 设备上。甚至对于在生产中运行的大型企业版数据库服务器，也能很容易地使用作为本产品一部分的图形用户界面 (GUI) 的管理实用工具进行管理。

    关系数据库引擎具有高可靠性，能够运行很长时间而不会发生故障。在数据库引擎的早期版本中要求停止和启动的管理操作现在可以在引擎运行当中执行，从而增加了可用性。数据库引擎与 Windows 2000 和 Windows NT® 故障转移群集的集成使您得以定义虚拟服务器，即使节点中的一台物理服务器出现故障，这些虚拟服务器仍然保持运行。在适当的地方，日志传送可以用于维护热备用服务器。在故障发生的数分钟内，热备用服务器可以代替生产服务器运行。

    关系数据库引擎还具有高度的安全性。登录身份验证可以与 Windows 身份验证集成在一起，这样，密码将不会存储在 SQL Server 中，也不会通过网络发送而被网络嗅探器读取。网站可以设置 C2 级审核，对所有访问数据库的用户进行审核，还可以使用安全套接字层 (SSL) 加密的办法，对所有在应用程序和数据库间传送的数据进行加密。

    数据库引擎的分布式查询功能使您得以访问所有可通过 OLE DB 访问的数据源中的数据。在 Transact-SQL 语句中，可以像引用实际驻留在 SQL Server 数据库中的表一样引用远程 OLE DB 数据源表。此外，全文检索功能使您得以对 SQL Server 数据库或 Windows 文件中存储的文本数据进行复杂的模式匹配。

    关系数据库引擎能够存储由顶层联机事务处理 (OLTP) 系统生成的所有事务的详细记录。该数据库引擎还可以支持最大的联机分析 (OLAP) 数据仓库中的事实数据表和维度表的严格处理要求。

    有关 SQL Server 2000 关系数据库组件的更多信息，请参见关系数据库组件

  • Microsoft SQL Server 2000 Analysis Services 提供分析数据仓库和数据集市中存储的数据的工具。某些分析方法，例如获取一份关于某地区中所有商店按产品划分的月销售额细目表，如果对 OLTP 系统中的所有详细记录逐个进行分析，需要花相当长的时间。为了加快这类分析，应采取定期汇总 OLTP 系统中的数据，然后存储在数据仓库或数据集市的事实数据表和维度表中的办法。Analysis Services 以多维数据集的形式显示事实数据表和维度表中的数据，从多维数据集中可以分析趋势和其它对于规划今后工作非常重要的信息。在 Analysis Services 多维数据集上处理 OLAP 查询比试图在 OLTP 数据库中记录的详细数据上进行同样的查询要快得多。有关 Analysis Services 的更多信息，请参见数据仓库和联机分析处理。
应用程序支持

关系数据库引擎和 Analysis Services 都能为常用的 Windows DNA 或 Win32 数据访问接口（如 ActiveX® 数据对象 (ADO)、OLE DB 和开放式数据库连接 (ODBC)）提供本机支持。应用程序可以使用上述任何一种应用程序接口 (API)，将 SQL 或 XML 语句发送到使用本机 OLE DB 提供程序或 ODBC 驱动程序的关系数据库引擎。SQL Server 2000 还提供使用 HTTP 将 SQL 或 XML 语句发送到关系数据库引擎的能力。应用程序可以使用 ADO 或 OLE DB 的多维扩展向 Analysis Services 发送多维表达式 (MDX) 查询。因为 SQL Server 使用标准的 Windows DNA 数据访问 API，所以 Microsoft 应用程序开发环境为 SQL Server 应用程序的开发提供了很好的支持。此外，交互式查询工具（如查询分析器）提供模板、交互式调试器和交互式测试环境，这些都加快了程序员提交 SQL Server 应用程序的能力。

除了支持应用程序的数据存储和 OLAP 处理需要外，SQL Server 2000 还提供了全套的易于使用的图形管理工具和向导，用于创建、配置和维护数据库、数据仓库和数据集市。SQL Server 还记录了由 SQL Server 工具使用的管理 API，使您得以直接在自己的应用程序中加入 SQL Server 管理功能。SQL Server 管理 API 包括：

  • SQL 分布式管理对象 (SQL-DMO)，这是一组 COM 对象，封装了关系数据库引擎和数据库中所有实体的管理功能。

  • 决策支持对象 (DSO)，这是一组 COM 对象，封装了 Analysis Services 引擎和多维数据集中所有实体的管理功能。

  • Windows 管理规范 (WMI)，SQL Server 2000 提供 SQL Server WMI提供程序，允许 WMI 应用程序获取关于 SQL Server 数据库和实例的信息。

有关开发 SQL Server 应用程序的更多信息，请参见应用程序开发构架以及 SQL Server 和 XML 支持。

附加组件

SQL Server 2000 提供了几个能支持时下流行的数据存储系统重点需求的组件。当今的大企业对数据存储的需求非常复杂，仅仅拥有一个集成了单一数据仓库或数据集市的 OLTP 系统还远远不够。越来越多的现场工作人员需要在工作时装载一组数据，与网络断开，自主记录每天的现场工作，然后在一天工作结束时重新与网络连通，将自己的记录合并到中央数据存储中。OLTP 系统必须通过 Intranet 支持内部雇员的操作需求，并通过 Web 入口支持成百上千客户的订购需求。通过使最需要处理数据的工作组甚至个人轻松获得数据，然后将数据复制到主数据存储中，可以最大程度地减轻系统的总体处理负荷。

  • SQL Server 2000 复制使网站得以在不同的计算机上维护多个数据复本以提高系统总体性能，同时确保不同的数据复本保持同步。例如，部门可以在自己的服务器上维护部门的销售数据，同时使用复制来更新公司计算机上的销售数据。一些与网络断开的移动用户可以在不连网的情况下完成工作，并在一天工作结束时通过合并复制将自己的工作记录合并到主数据库中。这些工作人员可能在笔记本或膝上型电脑上使用 SQL Server 个人版，或在 Windows CE 设备上使用 SQL Server for Windows CE；SQL Server 复制支持所有这些软件。SQL Server 复制还支持将数据复制到数据仓库，并且可以向（或从）任何支持 OLE DB 访问的数据源中复制数据。有关更多信息，请参见复制构架。

  • SQL Server 2000 数据转换服务 (DTS) 大大改进了生成 OLAP 数据仓库的过程。对大型 OLTP 数据库进行了细致地调整，使其能够支持同时输入上千个商业事务。同时还调整了 OLTP 数据库的结构，以便记录每个事务的详细信息。在根据数月和数年的销售情况进行复杂分析以便发现趋势时，需扫描大量的记录，而过重的处理负荷会降低 OLTP 数据库的性能。数据仓库和数据集市通过一个或多个 OLTP 系统中的数据生成，这些数据被提取出来并转换成对 OLAP 处理更有用的形式。OLTP 详细信息行被定期拉入中间临时数据库中并在这里汇总，之后，汇总数据被存储到数据仓库或数据集市中。数据转换服务支持从一个数据源中提取数据，不时地进行复杂的数据转换，并在另一个数据源中存储已汇总和转换的数据。该组件大大简化了从多个 OLTP 系统中提取数据，并将数据置入 OLAP 数据仓库或数据集市中的过程。有关更多信息，请参见将 OLTP 数据转换到 OLAP 数据仓库。

    DTS 不仅限于用来生成数据仓库，还可以随时用来检索数据源中的数据、对数据进行复杂转换并将数据存储到另一个数据源中。DTS 也不只限于和 SQL Server 数据库或 Analysis Services 多维数据集一同使用，DTS 能与任何可通过 OLE DB 访问的数据源一同使用。

  • SQL Server 2000 English Query 使您得以生成针对特殊用户问题定制的应用程序。English Query 管理员为 English Query 引擎定义数据库的表间和列间的所有逻辑关系，以及数据仓库或数据集市中的多维数据集之间的所有逻辑关系。应用程序于是可以向用户显示一个对话框，用户可在此对话框中输入字符串（英文），提出有关数据库或数据仓库数据的问题。应用程序将该字符串传递给 English Query 引擎，后者根据所定义的表间或多维数据集间的关系分析字符串。然后，English Query 向应用程序返回一条 SQL 语句或 MDX（多维表达式）查询，而该查询将返回用户问题的答案。有关更多信息，请参见 SQL Server 和 English Query。

  • Meta Data Services 为存储、查看和检索有关应用程序对象和系统对象的描述提供了便利。Meta Data Services 支持 MDC 开放信息模型 (OIM) 规范，该规范定义存储实体（如表、视图、多维数据集或转换）描述以及实体间关系描述的公用格式。支持 OIM 的应用程序开发工具可以使用这些描述加快开发的速度并帮助与其它工具和应用程序进行交换。SQL Server 组件（如数据转换服务包和 Analysis Services 数据库）还可以存储在 Meta Data Services 知识库中。有关更多信息，请参见 SQL Server 2000 数据仓库和 OLAP 组件。
使用 SQL Server 2000

单位可使用 SQL Server 2000 组件执行各种任务，例如：

  • 每个部门可能有一台自己的 SQL Server 数据库服务器。这些服务器定期将各自的数据复制到为整个组织提供服务的中央数据库服务器。

  • 组织还可能有另外一台中央数据库计算机为组织的 Web 站点提供服务，有时一次要处理上千个查询。一些 Web 应用程序使用 English Query，允许顾客针对 Web 站点的数据库数据定制请求。

  • 有些雇员可能运行个别的压缩软件包产品复本，该软件包将 SQL Server Desktop Engine 复本作为其数据存储组件安装。

  • 服务部门的有些员工在与网络断开的移动环境下工作，他们每天早晨通过复制功能将当天的安排装入笔记本电脑或 Microsoft Windows CE 设备中，然后到现场工作，在一天工作结束时通过合并复制将一天的工作结果输入到中央计算机中。

  • 数据转换服务包定期从中央数据库中提取详细的 OLTP 数据，并清理数据和生成汇总数据，然后将汇总数据装入数据仓库中。

  • 高级管理人员和市场营销人员使用 Analysis Services 分析数据仓库中的业务趋势，了解存在哪些可拓展的机遇或必须尽量避免的风险。


SQL Server 2000 的特性

Microsoft® SQL Server™ 2000 的特性包括：

  • Internet 集成。

    SQL Server 2000 数据库引擎提供完整的 XML 支持。它还具有构成最大的 Web 站点的数据存储组件所需的可伸缩性、可用性和安全功能。SQL Server 2000 程序设计模型与 Windows DNA 构架集成，用以开发 Web 应用程序，并且 SQL Server 2000 支持 English Query 和 Microsoft 搜索服务等功能，在 Web 应用程序中包含了用户友好的查询和强大的搜索功能。

  • 可伸缩性和可用性。

    同一个数据库引擎可以在不同的平台上使用，从运行 Microsoft Windows® 98 的便携式电脑，到运行 Microsoft Windows 2000 数据中心版的大型多处理器服务器。SQL Server 2000 企业版支持联合服务器、索引视图和大型内存支持等功能，使其得以升级到最大 Web 站点所需的性能级别。

  • 企业级数据库功能。

    SQL Server 2000 关系数据库引擎支持当今苛刻的数据处理环境所需的功能。数据库引擎充分保护数据完整性，同时将管理上千个并发修改数据库的用户的开销减到最小。SQL Server 2000 分布式查询使您得以引用来自不同数据源的数据，就好象这些数据是 SQL Server 2000 数据库的一部分，同时分布式事务支持充分保护任何分布式数据更新的完整性。复制同样使您得以维护多个数据复本，同时确保单独的数据复本保持同步。可将一组数据复制到多个移动的脱接用户，使这些用户自主地工作，然后将他们所做的修改合并回发布服务器。

  • 易于安装、部署和使用。

    SQL Server 2000 中包括一系列管理和开发工具，这些工具可改进在多个站点上安装、部署、管理和使用 SQL Server 的过程。SQL Server 2000 还支持基于标准的、与 Windows DNA 集成的程序设计模型，使 SQL Server 数据库和数据仓库的使用成为生成强大的可伸缩系统的无缝部分。这些功能使您得以快速交付 SQL Server 应用程序，使客户只需最少的安装和管理开销即可实现这些应用程序。

  • 数据仓库。

    SQL Server 2000 中包括析取和分析汇总数据以进行联机分析处理 (OLAP) 的工具。SQL Server 中还包括一些工具，可用来直观地设计数据库并通过 English Query 来分析数据。


与 Internet 集成

Microsoft ®SQL Server™ 2000 关系数据库引擎包含对 XML 的本机支持：

  • 可将 Transact-SQL 结果作为 XML 文档返回到使用 OLE DB 和 ADO API 的 Web 或业务流应用程序。

  • 可定义代表数据库表的逻辑视图的批注 XDR 架构。Web 应用程序于是可在 XPath 查询中引用这些架构以生成 XML 文档。

  • SQL Server 2000 包含一个 ISAPI DLL，使您得以在与 SQL Server 2000 实例相关联的 Microsoft Internet Information 服务 (IIS) 中定义虚拟根。这样，Internet 应用程序可组成 URL 字符串，在其中引用 SQL Server 2000 虚拟根并包含 Transact-SQL 语句。将 Transact-SQL 语句发送到与虚拟根相关联的 SQL Server 2000 实例，并返回 XML 文档格式的结果。

  • 可将 XML 文档添加到 SQL Server 2000 数据库。OPENXML 函数可用于在行集中表现 XML 文档数据，可用 SELECT、INSERT、UPDATE 等 Transact-SQL 语句引用这些数据。

SQL Server 2000 与其它产品共同构成了可靠安全的 Internet 和 Intranet 系统的数据存储。

  • SQL Server 2000 与 Microsoft Windows® 2000 Server 和 Microsoft Windows NT® Server 安全及加密工具共同实现安全的数据存储。

  • SQL Server 2000 为在 IIS 服务下运行或通过防火墙访问数据库的 Web 应用程序构成了高性能的数据存储服务。

  • SQL Server 2000 可与 Site Server 一起使用，建立并维护大型的复杂电子商务 Web 站点。

  • SQL Server 2000 TCP/IP 套接字通讯支持可与 Microsoft Proxy Server 集成，以实现安全的 Internet 和 Intranet 通讯。

Analysis Services 包含支持许多企业对企业 (B2B) 或企业对个人 (B2C) 的 Web 应用程序所需的功能：

  • 集成的数据挖掘引擎支持关系数据库和 OLAP 多维数据集的数据挖掘分析。数据挖掘引擎可通过用于数据挖掘的 OLE DB 进行扩展，使得可以并入独立软件开发商 (ISV) 支持扩展数据挖掘功能的算法。

  • 非重复计数和 OLAP 警报等功能使您得以执行分析 Web 站点点击流这样的操作，以评估 Web 接口的有效性。

English Query 使 Web 应用程序得以支持任何技术水平的用户输入的有关关系数据库或 OLAP 多维数据集中的数据的英文问题。English Query 将问题与数据库或多维数据集的模型进行匹配，并返回 SQL 或 MDX 查询以检索适当的结果。

业务流应用程序支持所有这些 SQL Server 2000 功能，使您得以更容易地集成 Web 和业务流应用程序。

请参见

通讯组件

安全管理

SQL Server 和 XML 支持


可伸缩性和可用性

同一 Microsoft® SQL Server™ 2000 数据库引擎运行在 Microsoft Windows 2000 Professional、Microsoft Windows 2000 Server、Microsoft Windows 2000 Advanced Server、Windows 98 和 Windows Millennium Edition 上。还运行在 Microsoft Windows NT® 4.0 版的所有版本上。此数据库引擎是一个功能强健的服务器，可管理供上千用户访问的 TB 数据库。同时，当以默认设置运行时，SQL Server 2000 还具有动态自调整等功能，这使得它可以有效地运行在便携式电脑和台式机中，用户无需承担管理任务。SQL Server 2000 Windows CE 版将 SQL Server 2000 程序设计模型扩展到移动的 Windows CE 设备上，并且可以很容易地集成到 SQL Server 2000 环境中。

SQL Server 2000 与 Windows NT 和 Windows 2000 故障转移群集共同支持不间断地将故障即时转移到备份服务器。SQL Server 2000 还引入了日志传送功能，使您得以在可用性要求较低的环境中维护备用服务器。

同一服务器跨 Windows 2000、Windows NT、Windows 98 和 Windows Millennium Edition 平台

因为 SQL Server 2000 数据库引擎运行在 Windows NT 工作站、Windows NT Server、Windows 2000 Professional、Windows 2000 Server、Windows 2000 Advanced Server、Windows 2000 DataCenter、Windows 98 和 Windows Millennium Edition 上，所以在所有环境中共享同一程序设计模型。

通常情况下，根据运行在某一环境中的 SQL Server 2000 实例编写的应用程序可在任何其它 SQL Server 2000 实例上运行。Microsoft 搜索服务在 Windows NT 工作站、Windows 2000 Professional、Windows Millennium Edition 或 Windows 98 操作系统上不可用。SQL Server 数据库在这些平台上不支持全文目录和索引。但是，如果在这些操作系统中运行的应用程序连接到支持全文功能的其它计算机上的 SQL Server 2000 实例，则可使用全文功能。

运行在不同操作系统上的 SQL Server 2000 的行为不同，主要是因为 Windows Millennium Edition 或 Windows 98 不支持某些功能，如异步 I/O 和散播-聚集 I/O。通常情况下，这些功能不影响发送给应用程序的数据或响应。它们只是防碍运行在 Windows Millennium 或 Windows 98 上的 SQL Server 实例具有与 Windows NT 或 Windows 2000 上的 SQL Server 实例相同的性能级别。但是 Windows Millennium Edition 或 Windows 98 上的 SQL Server 实例不支持故障转移群集并且不能发布事务复制。

联合数据库服务器

SQL Server 2000 引入了对可更新的分布式分区视图的支持。这些视图可用于在一组 SQL Server 实例间对表中行的子集进行分区，同时使每个 SQL Server 实例象拥有原始表的完整复本那样运行。这些分区视图可用于将某个表的处理分散到多个 SQL Server 实例中（每个实例位于一台单独的服务器上）。通过分区数据库中的全部或多数表，该功能可用于将单个 Web 站点的数据库处理分散到运行 SQL Server 2000 的多台服务器中。这些服务器彼此之间是分开管理的，因此不会形成群集。这种自主服务器的集合称为服务器联合体。运行 SQL Server 2000 的服务器联合体能够支持当前最大的 Web 站点或企业数据库系统的增长需求。

为提高联合服务器的性能和可伸缩性，SQL Server 2000 支持高速系统局域网络 (SAN)，如 GigaNet。

大型数据库改进

SQL Server 2000 具有支持超大型数据库环境的高速优化。SQL Server 6.5 版和更早的版本可支持 200 GB 到 300 GB 的数据库。SQL Server 2000 和 SQL Server 7.0 版可有效地支持 TB 数据库。

Transact-SQL BACKUP 和 RESTORE 语句已得到优化，可以串行读取数据库，并将数据库并行写入多个备份设备。站点还可以通过执行差异备份（即只备份自上次备份后更改的数据），或备份个别的文件或文件组来减少要备份的数据量。在 SQL Server 2000 中，运行差异备份所需的时间已得到改进，与自上次备份后修改的数据数量成比例。

还可以对单个表同时执行多个大容量复制操作，以提高数据输入速度。数据库控制台命令 (DBCC) 实用工具语句在实现上减少了锁定要求并支持在具有多个处理器的计算机上进行并行操作，从而极大地提高了运行速度。

现在可以在一个表上同时创建多个索引。

SQL Server 2000 数据库可直接映射到 Windows 文件，从而简化了数据库的创建和管理。数据库页大小为 8 KB，扩展盘区的大小增加到 64 KB，从而改进了 I/O。

改进的查询优化器

SQL Server 2000 查询优化器中新增了可提高查询处理速度的访问方法。这些改进的访问方法通常是为了配合改进和简化数据库中的磁盘上数据结构：

  • 查询优化器在扫描表和索引时使用串行预读 I/O 以提高性能。此优化器还使用合并和哈希算法进行联接。

  • 查询优化器对用于执行 SQL 语句的准备/执行模型提供本机支持。当某个应用程序执行 SQL 语句时，优化器采用高效算法确定是否有其它任何应用程序已执行了相同的语句。如果优化器发现已有该语句的执行计划，便不编译新计划而是通过重新使用现有计划来节省处理资源。在许多用户都运行同一应用程序的系统中，这种算法可以减少将 SQL 语句编译成执行计划所需的资源。
查询内并行度

当运行在有多个 CPU 的服务器上时，SQL Server 2000 可以生成并行执行计划，以将一个 SQL 语句的处理分成几个部分。每个部分可以运行在不同的 CPU 上，这样生成完整结果集的速度比串行执行不同部分的方式要快。

支持大内存

SQL Server 2000 企业版使用 Microsoft Windows 2000 Address Windowing Extensions (AWE) API 支持将近 64 GB RAM 的内存。这使 SQL Server 2000 企业版得以在内存中高速缓存大量的行，从而减少了开销并加快了处理查询的能力。

索引视图

SQL Server 2000 关系数据库引擎支持在视图上创建索引。在创建索引的同时将索引的结果集具体化，并在修改基础基本数据时对其进行维护。在对大量数据进行复杂计算的视图上创建索引可加快使用不同数据量的后续查询的速度。性能收益不仅限于在 FROM 子句指定索引视图的查询，任何引用索引视图所覆盖的数据的查询都能获得性能收益。这意味着现有查询可通过使用视图来实现性能收益，而不必通过重新编码来显式引用索引视图。索引视图显著提高了访问 SQL Server 数据库的大型复杂报表应用程序的性能。

高度可用性

SQL Server 2000 可维护不间断运行的 Web 站点和企业系统所需的极高的可用性级别。

SQL Server 2000 发扬了 SQL Server 7.0 构架，该构架已被证实在高容量 Web 站点和企业系统中非常可靠。

SQL Server 2000 增强了对 Windows NT 和 Windows 2000 故障转移群集的支持。对安装故障转移群集的支持现在作为"安装"选项来实现，该选项比 Microsoft SQL Server 的早期版本容易使用得多。SQL Server 2000 还支持在故障转移群集中可有多达 4 个节点。

SQL Server 2000 为不要求即时故障转移支持从而有可能丢失某些更新的 Web 站点和企业系统引入了日志传送。可创建生产数据库，将其复制到备用服务器，然后使用日志传送按设置的间隔（如每隔 10 分钟）将事务日志从生产服务器传送给备用服务器。通过在备用服务器上还原日志，创建可在出问题时替换生产服务器的服务器。唯一可能丢失的数据是自上一组传送到备用服务器的日志后所做的任何修改。如果报表系统无须与生产服务器保持完全同步，则日志传送还可用于将数据从生产服务器复制到一个或多个只读报表服务器。

请参见

设计联合数据库服务器

关系数据库引擎构架概述

SQL Server 可伸缩性

日志传送

创建故障转移群集

使用 Windows 2000 上的 AWE 内存


企业级数据库功能

Microsoft® SQL Server™ 2000 包含多个支持大型 Web 站点和时下的企业数据处理系统的复杂数据存储需求的功能。

分布式查询

SQL Server 2000 支持在 Transact-SQL 语句中直接引用异类 OLE DB 数据源。分布式查询使您得以将来自不同数据源的数据与 SQL Server 2000 数据库中的数据集成。

OLE DB 提供程序将结果作为表格格式的行集返回。SQL Server 2000 支持从 OLE DB 数据源返回行集的函数，如 OPENQUERY 和 OPENDATASOURCE。这些函数可在 Transact-SQL 语句中代替表引用。还可以定义引用 OLE DB 数据源的链接服务器名称，然后使用 Transact-SQL 语句中的 FROM 子句从该数据源引用表，就像引用任何 SQL Server 表一样。

如果 OLE DB 提供程序支持更新，则 SQL Server 2000 的分布式查询功能支持在 INSERT、UPDATE、DELETE 等数据修改语句中引用 OLE DB 行集。如果 OLE DB 提供程序支持所需的接口，分布式事务将防止对 OLE DB 行集进行修改。

SQL Server 2000 还可利用 OLE DB 提供程序发布由提供程序表现的行集中的数据值的分发统计。SQL Server 2000 使用这些统计信息生成智能查询，以使 OLE DB 提供程序必须返回给 SQL Server 的行数减到最少。这将提高分布式查询处理的速度。

动态行级锁定

SQL Server 2000 动态地将查询所引用的每一个表的锁定粒度调整到合适的级别。当查询所引用的少数几行分散在一个大型表中时，优化数据并行访问的最佳办法是使用粒度锁，如行锁。但是，如果查询引用的是一个表中的大多数行或所有行，优化数据并行访问的最佳办法可以是锁定整个表，以尽量减少锁定开销并尽快完成查询。

SQL Server 2000 通过为每个查询中的每个表选择适当的锁定级别，在总体上优化了数据并发访问。对于一个查询，如果只引用一个大型表中的几行，则数据库引擎可以使用行级锁定；如果引用一个大型表的几页中的多行，则使用页级锁定；如果引用一个小型表中的所有行，则使用表级锁定。

充分的完整性保护

SQL Server 2000 提供充分的数据库完整性保护。所有数据修改都在事务中执行，每个事务或者在状态达到一致时全部提交，或者在遇到错误时全部回滚。如果服务器出现故障，则当服务器重新启动时，所有未完成的事务都从所有 SQL Server 2000 数据库中自动回滚。

分布式事务

SQL Server 2000 数据库可以参与由遵从 X/Open XA 的事务管理器所管理的分布式事务。这包括跨多个 SQL Server 2000 数据库的分布式事务和跨异类资源管理器的分布式事务。用于 SQL Server 2000 的 OLE DB 提供程序和 SQL Server 2000 ODBC 驱动程序都支持分布式事务中的登记。

如果 Transact-SQL 脚本和应用程序引用其它 SQL Server 2000 系统或异类 OLE DB 数据源中的对象，则可以将它们的本地事务动态地升级为分布式事务。SQL Server 2000 使用 Microsoft 分布式事务处理协调器透明地管理这些分布式事务。

复制

SQL Server 2000 复制使您得以在多个站点（有时甚至是几百个站点）使用发布-订阅术语维护数据的复本。这使站点得以将数据定位到靠近最常访问它的用户，同时使数据与其它位置的复本保持同步。

SQL Server 2000 支持三种类型的复制。快照复制按数据或数据库对象在特定时间的状态对其进行复制。在事务复制中，发布服务器和订阅服务器通常先使用快照同步数据，然后随着数据在发布服务器上进行修改，所做的修改被传送到订阅服务器。合并复制使多台订阅服务器自主地处理数据集的复本，然后过一段时间将它们更新的版本合并到发布服务器。合并复制支持多种解决不同订阅服务器如何修改同一数据的冲突的方法。

SQL Server 2000 中的复制支持排队更新，使得事务和快照复制订阅服务器不需要动态网络连接即可修改发布的数据。

SQL Server 2000 复制引入了可转换的订阅，允许订阅使用数据转换服务 (DTS) 的灵活性和强大功能来映射、转换和筛选复制的数据。

复制的可用性已得到进一步增强，使管理员可以十分轻松地使用复制。事务复制现在可与备份和还原数据库同步，消除了重新配置事务复制的需要。依据适当的权限，可浏览 Windows 2000 Active Directory 以查找发布。SQL Server 2000 引入了新改进的复制向导，并支持更集中的发布和订阅记录。

请参见

分布式查询构架

关系数据库引擎构架概述

事务构架

复制构架


易于安装、部署和使用

如果一个数据库可支持企业的所有处理需求，则往往这个数据库很复杂，且难以管理。Microsoft® SQL Server™ 2000 包含许多简化安装、部署、管理和使用数据库的过程的工具和功能。SQL Server 2000 为数据库管理员提供了精细调整运行生产联机系统的 SQL Server 2000 安装所需要的全部工具。SQL Server 2000 还可以有效地运行在小型的单用户系统上，并将管理开销控制在最低水平。

动态自管理

运行期间，SQL Server 2000 自动对自身进行动态的重新配置。随着更多的用户连接到 SQL Server 2000，它可以动态地获取额外的资源（如内存）。当工作负荷减轻时，SQL Server 2000 会将资源释放回系统。如果服务器上有其它应用程序启动，则 SQL Server 2000 将检测那些应用程序额外分配的虚拟内存，并减少自己使用的虚拟内存以减少分页开销。当插入或删除数据时，SQL Server 2000 还会自动增大或减小数据库的大小。

数据库管理员可控制在每个 SQL Server 2000 实例中动态重新配置的数量。由某位对数据库不熟悉的用户使用的小型数据库可以默认配置设置运行，在这种情况下，数据库将对自身进行动态配置。如果某个大型生产数据库是由富有经验的数据库管理员管理，则可以将该数据库设置为管理员可以对配置进行完全控制。

完整的管理工具集

SQL Server 2000 为数据库管理员提供了多个管理系统的工具：

  • SQL Server 企业管理器是 Microsoft 管理控制台 (MMC) 的管理单元组件。

    MMC 支持从单个控制台管理多种类型的服务器，如 Microsoft Windows® 2000 服务、Microsoft Internet Information 服务器、Microsoft SNA Server 和 SQL Server 2000 实例。单个控制台上的管理员具有在万维网上管理所有服务器的能力。SQL Server 企业管理器共享一个用于 Web 管理的 MMC 用户界面子集。它通过易于使用的图形用户界面，将所有 SQL Server 对象展现在一个分层结构的控制台树中。

  • SQL Server 代理程序允许对按调度执行或反复出现的任务进行定义和调度。

    它还支持在某些警告情况发生时向管理员发出警报，甚至可以通过编程使它能在这种情形下采取正确的操作。

  • SQL 事件探查器为管理员提供了一个完善的工具，用于监视和分析进出运行 SQL Server 2000 的服务器的网络流量。

    它还探查服务器事件，例如获取锁。

  • SQL Server 性能监视器将 SQL Server 计数器集成到 Windows 性能监视器中，使管理员得以使用用于监视 Microsoft Windows NT® Server 的同一工具来监视 SQL Server 并绘制它的性能曲线图。

  • 索引优化向导分析 SQL 语句或语句组如何使用表集上现有的索引。

    此向导会建议修改某些索引以提高 SQL 语句的执行速度。

可编程管理

SQL Server 2000 的管理可以实现高度自动化，使数据库管理员无需设计新的数据库和应用程序。

SQL 分布式管理对象 (SQL-DMO) 是一组自动化对象，可用于在应用程序中编入管理 SQL Server 2000 实例的逻辑。这给应用程序包提供了将 SQL Server 2000 透明地嵌入其应用程序的能力。有经验的数据库管理员还可以使用 SQL-DMO，针对他们站点所特有的许多常见管理任务生成应用程序。SQL Server 2000 也支持 Windows 管理规范 (WMI) API。WMI 支持映射在 SQL-DMO API 上。

重复出现的日常任务可以按自动调度作业的方式执行，无需操作员不间断地监视。例如，在数据库管理员设计好服务器的备份过程后，备份就可以作为一组自动作业来执行。

还可以对 SQL Server 2000 进行程序设计，以便在特定事件发生时发出警报。警报所采取的操作可以有几种形式：

  • 可以给受影响方发送电子邮件、寻呼信息或 Windows 2000"网络发送"消息。

    例如，如果服务器中"完整扫描"（扫描整个表或索引）的数目超过一个特定的数，可以给数据库管理员发送一个电子邮件以进行调查。

  • 可以执行一项预定义的作业来解决问题（如果该问题比较常见，且可通过程序设计进行处理）。
安装和升级

SQL Server 2000 光盘包含自动运行应用程序，允许用户做出多种选择，如：

  • 安装新的 SQL Server 2000 实例。

  • 升级 Microsoft SQL Server 7.0 版或更早版本的现有实例。

  • 安装必备软件。

  • 只安装光盘上的文档以便在安装产品之前可进行查看。

  • 查看有关 SQL Server 2000 功能优点的评估指南。

SQL Server 2000 的安装或升级由图形用户界面 (GUI) 应用程序驱动，该程序引导用户一步步地设置 SQL Server 2000 安装所需的信息。安装程序本身自动检测机器中是否有 SQL Server 的早期版本，并在安装了 SQL Server 2000 后询问用户是否要启动 SQL Server 2000 升级向导以快速引导用户完成升级过程。整个安装或升级过程可很快完成，用户只需输入很少的信息。

需要在多台服务器上安装 SQL Server 2000 的站点可利用 SQL Server 的无值守安装功能，按适当的配置将 SQL Server 安装在所有的服务器上。

生成 SQL Server 2000 应用程序

SQL Server 2000 在生成应用程序方面有几个优点：

  • 通过提供对 Windows DNA 数据访问 API（包括对这些 API 的 ADO、OLE DB 和 MDX（多维）OLAP 扩展）的本机支持，在 Windows DNA 构架中完全集成。

    这些 API 包括功能强大的低级 API，如 ODBC 和 OLE DB，使程序员得以控制应用程序与数据库之间的交互。还包括支持快速应用程序开发的 API，如 ADO。

  • SQL-DMO、SQL-DTS 和复制组件。

    这些是自动化对象，可用来编写自定义程序以管理运行 SQL Server 的服务器。

  • SQL 查询分析器

    该组件使程序员得以交互地开发和测试 Transact-SQL 语句。它可以帮助以图形方式显示执行计划和提供 Transact-SQL 语句的性能统计。它以颜色区分不同的语法元素以提高 Transact-SQL 语句的可读性，并包含集成的 Transact-SQL 调试器。它还具有对象浏览器，可用于确定数据库中的表、视图、存储过程和其它对象的特性，并支持可用于加快复杂语句生成速度的模板。

  • Analysis Services、Meta Data Services 和 English Query 程序设计

    Analysis Services 和 Meta Data Services 提供支持 OLE DB 和 ADO 的联机分析处理 (OLAP) 扩展的 OLE DB 提供程序。这些使得在使用 Microsoft 数据访问 API 的应用程序中更容易集成 OLAP 和元数据处理。English Query 还支持对象模型 API，可以很容易将 English Query 功能集成到通过 OLE DB 或 ADO 访问 SQL Server 2000 数据库和 Analysis Services 多维数据集的应用程序中。

  • 改进的 Transact-SQL 可编程性

    SQL Server 2000 引入了多个改进 Transact-SQL 能力和灵活性的组件，并提高了程序员的工作效率。级联引用完整性操作可取代在更新或删除行时开发触发器以强制引用完整性操作的需要。INSTEAD OF 触发器可用于极大地扩展视图可支持的更新操作类型，并且现在可以指定最先或最后激发的 AFTER 触发器。用户定义函数可用于将新特性引入 Transact-SQL 语句。

与 Windows NT 集成的安全性和 Windows 2000 安全性

SQL Server 支持使用 Windows NT 和 Windows 2000 用户以及域帐户作为 SQL Server 2000 的登录帐户。这称为 Windows 身份验证。当用户连接到网络时，Windows 2000 对其进行验证。当连接到 SQL Server 时，SQL Server 客户端软件请求信任连接，该连接只有在已通过 Windows 2000 验证后才能授予。这样，SQL Server 就不必分别验证用户。用户也不用对所连接到的每个 SQL Server 系统都有一个单独的登录和密码。

通过 Windows 身份验证，没有密码传递到运行 SQL Server 的服务器，因而不必考虑安全性问题。SQL Server 2000 还支持使用安全套接字层 (SSL) 对客户端计算机和 SQL Server 实例间的所有网络通讯进行加密。

SQL Server 2000 还提供审核，使您得以跟踪并记录 SQL Server 实例中的活动。SQL Server 2000 审核可支持由美国政府定义的 C2 级安全性。有关更多信息，请参见《信任设备手册》。

请参见

管理构架

应用程序开发构架

安装 SQL Server 2000 概述


数据仓库

Microsoft® SQL Server™ 2000 包含多个可用于生成有效地支持决策支持处理需求的数据仓库的组件。

数据仓库框架

数据仓库框架是一组实现 SQL Server 2000 数据仓库功能的组件和 API。它提供一个公用界面，供各种力求生成并使用数据仓库或数据集市的组件使用。

数据转换服务

数据转换服务 (DTS) 提供一套用于生成数据仓库或数据集市的服务。决策支持系统对数据进行分析，以找出数据库用户所关心的趋势。联机事务处理数据库中存储的大量记录包含每个事务的详细信息，并且联机分析处理 (OLAP) 系统聚合和汇总信息，以提高对数据中所表现出来的趋势的分析速度。

DTS 支持从异类 OLE DB 数据源提取数据，并支持汇总或聚合这些数据以生成数据仓库。

联机分析处理支持

Microsoft SQL Server 2000 Analysis Services 使您得以为 Web 站点和大型企业系统生成灵活的、功能强大的商业智能应用程序。

Microsoft SQL Server 2000 Analysis Services 提供针对异类 OLE DB 数据源的 OLAP 处理功能。它包含定义和生成多维数据集的高效算法，应用程序可使用 OLE DB 2.0 OLAP 扩展或 Microsoft ActiveX® 数据对象多维扩展引用这些多维数据集。Analysis Services 是对 SQL Server 2000 数据库中的数据进行多维分析的优秀工具。

Analysis Services 支持对具有数亿维度的多维数据集进行多维查询。在多维数据集中可向下一直控制到单元和成员级的安全性。可针对聚合类型和可在多维数据集中执行的处理来创建自定义汇总函数。

数据挖掘支持

数据挖掘使您得以定义包含分组和预测规则的模型，以便应用于关系数据库或多维 OLAP 数据集中的数据。之后，这些预测模型便可用于自动执行复杂的数据分析，以找出帮助识别新机会并选择有获胜把握的机会的趋势。SQL Server 2000 Analysis Services 包含对数据挖掘模型的支持，包括对用于数据挖掘规范的 OLE DB 的 API 支持。通过用于数据挖掘 API 的 OLE DB，Analysis Services 支持与第三方数据挖掘提供程序集成。

English Query

English Query 给出 SQL Server 2000 数据库中实体和关系的定义。给出此定义后，应用程序可使用自动化 API 给 English Query 发送一个字符串，在其中包含有关数据库内数据的自然语言问题。English Query 返回一个 SQL 语句，应用程序可用此语句提取必要的数据。

Meta Data Services

SQL Server 2000 中包含的 Microsoft Meta Data Services 由一系列 Microsoft ActiveX® 接口和信息模型组成，这些模型定义 Microsoft 数据仓库框架所定义的数据库架构和数据转换。Microsoft 数据仓库框架的目的是通过共享元数据，将多个产品集成在一起。它将商业和技术两方面的元数据结合起来，提供了一种存储生产数据来源和目的架构的行业标准方法。

Meta Data Services 是数据仓库方案中存储 DTS 包的首选方法，因为它是为包提供数据沿袭的唯一方法。DTS 还使用 Meta Data Services 存储，使异类应用程序得以重复使用转换、查询和 ActiveX 脚本。

请参见

数据仓库和联机分析处理


关系数据库组件

Microsoft® SQL Server™ 2000 数据库组件是基于结构化查询语言 (SQL) 的可伸缩的关系数据库，集成了对 Internet 应用程序的可扩展标记语言 (XML) 支持。下列术语描述了 SQL Server 2000 数据库组件构架的基本组成：

数据库

数据库与数据文件相似，同为存储数据的场所。与数据文件一样，数据库并不直接向用户显示信息；用户运行应用程序访问数据库中的数据，数据库将这些数据以用户能够理解的格式呈现给用户。

数据库系统比数据文件的功能强大，因为数据库中的数据组织程度更高。在设计良好的数据库中，没有用户或应用程序必须同时更新的重复数据块。相关的数据分在一个结构或一条记录中，同时，还可以定义这些结构和记录之间的关系。

处理数据文件时，必须根据每个数据文件的特定结构对应用程序进行编码。数据库则不同，它包含一个目录，应用程序可以利用该目录来确定数据的组织结构。通用数据库应用程序能够利用该目录动态地向用户提供来自不同数据库的数据，而不受特定数据格式约束。

数据库通常有两个主要部分：一个是保存物理数据库的文件，一个是应用程序用于访问数据的数据库管理系统 (DBMS) 软件。DBMS 负责维护数据库的结构，包括：

  • 维护数据库内数据间的关系。

  • 确保数据存储正确，定义数据间关系的规则未被违反。

  • 在系统崩溃的情况下，按照已知的一致性程度恢复所有数据。

关系数据库

组织数据库数据的方法有很多种，而关系数据库是最为高效的一种。关系数据库系统是数学集合理论在如何高效组织数据这一问题上的应用。在关系数据库中，数据被收集在表（在关系型理论中称为关系）中。

表描述了对企业具有重要意义的某类对象。比如，一个公司的数据库中可能会有有关员工的表、有关客户的表，以及有关库存的表。每个表都由列和行（关系型理论中称为属性和元组）组成。每一列描述表代表的对象的某个属性。比如，Employee 表通常包含名字、姓氏、员工 ID 号、部门、工资级别以及职位等属性列。每一行表示表所代表的对象的一个实例。比如，Employee 表中的某一行代表员工 ID 号为 12345 的员工。

在将数据组织成表的过程中，用户通常会发现有许多不同定义表的方法。关系数据库理论定义了一个称为规范化的进程，可确保定义的表集能够有效地组织数据。

可伸缩性

SQL Server 2000 支持许多用户的同时访问。一个 SQL Server 2000 实例通常包括组成一系列数据库的文件和一套 DBMS 软件。在不同计算机上运行的应用程序使用 SQL Server 2000 通讯组件，通过网络将命令传送到 SQL Server 2000 实例。当应用程序与 SQL Server 2000 实例连接后，就可以引用该实例中用户被授权访问的任何数据库。通讯组件还允许 SQL Server 2000 实例与在同一台计算机上运行的应用程序之间进行通讯。用户可以在一台计算机上同时运行多个 SQL Server 2000 实例。

SQL Server 2000 被设计为可支持最大的 Web 站点或企业数据处理系统上的数据流通。在大型多处理器服务器上运行的 SQL Server 2000 支持成千上万的用户同时连接。SQL Server 表中的数据可在多台服务器间分区，这样，多台多处理器计算机就可彼此协作，支持超大型系统的数据库处理需求。这些数据库服务器组称为联合体。

尽管 SQL Server 2000 被设计为用作通过网络连接的成千上万并发用户的数据存储引擎，它仍可作为一个独立的数据库，像应用程序一样直接在同一台计算机上运行。SQL Server 2000 卓越的可伸缩性和便于使用的诸多功能使其能够在单个计算机上高效运行，既不占用过多的系统资源，也不需要专门的用户来管理。这些功能还使 SQL Server 2000 得以动态地获取支持上千用户所需的资源，同时将数据库的管理和调节工作减到最少。SQL Server 2000 关系数据库引擎动态调节自身以获取或释放适当的计算机资源，以支持在任何特定时间访问 SQL Server 2000 实例时不断变化的用户负荷之需。SQL Server 2000 关系数据库引擎的强大功能可以避免因某个用户读取或修改其他用户当前使用的数据而引起的逻辑问题。

结构化查询语言

若要处理数据库中的数据，必须使用一套由 DBMS 软件定义的命令和语句（语言）。处理关系数据库的语言有很多种，其中最常用的是 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 是新出现的 Internet 数据标准。XML 是一套可用于定义超文本文档结构的标记。XML 文档可由显示 Web 页的最重要语言——超文本标记语言 (HTML) 轻松处理。

尽管大多数 SQL 语句以关系或表格格式结果集的形式返回结果，但是 SQL Server 2000 数据库组件仍支持以 XML 文档形式返回结果的 FOR XML 子句。SQL Server 2000 还支持来自 Internet 和 Intranet应用程序的 XPath 查询。可将 XML 文档添加到 SQL Server 数据库中，并可使用 OPENXML 子句以关系结果集的形式显示 XML 文档中的数据。


数据库应用程序和服务器

Microsoft® SQL Server™ 2000 被设计为可作为下列任一数据库有效地工作：

  • 服务器上的中央数据库，可由许多用户通过网络连接共享。共享用户数的范围可从一个工作组中的若干人，到大型企业的上千名员工，甚至到成百上千万的 Web 用户。

  • 只服务于同一桌面上运行的应用程序提供服务的桌面数据库。
服务器数据库系统

基于服务器而构造的系统，使得多个用户可共享一台中央计算机（称为服务器）上的数据库。用户通过应用程序访问服务器：

  • 在多层系统（如 Windows® DNA）中，客户端应用程序逻辑在两个或多个位置上运行：
    • 瘦客户端在用户的本地计算机上运行，其主要作用是向用户显示结果。

    • 业务逻辑位于服务器上运行的服务器应用程序中。瘦客户端请求此服务器应用程序提供功能，此服务器应用程序本身是一个多线程应用程序，可由多个并发用户一起使用。此服务器应用程序负责打开与数据库服务器的连接。此服务器应用程序可作为数据库在同一服务器上运行，也可跨网络连接到另一台作为数据库服务器的服务器上。在复杂系统中，可在几个互相连接的服务器应用程序中或服务器应用程序的多个层次中实现业务逻辑。

      下面是一个典型的 Internet 应用方案。例如，一个多线程服务器应用程序可以在一台 Microsoft® Internet Information 服务 (IIS) 服务器上运行，并为在 Internet 或 Intranet 上运行的成千上万台瘦客户端提供服务。此服务器应用程序使用连接池与一个或更多的 SQL Server 2000 实例进行通讯。SQL Server 2000 实例可与 IIS 位于同一台计算机上，也可分别位于网络中的不同服务器上。

  • 在双层客户端/服务器系统中，用户在其本地计算机上运行称为客户端应用程序的应用程序，而客户端应用程序通过网络连接到运行于服务器计算机上的 SQL Server 2000 实例。客户端应用程序既运行业务逻辑，也运行向用户显示输出的代码，所以有时也称为胖客户端。
服务器数据库系统的优点

在中央位置存储和管理数据有几个优点：

  • 每个数据项都存储在中央位置，所有用户都可以在这个位置使用它们。

    各个客户端上不单独存储数据项复本，从而消除了因用户不得不确保使用的信息相同所带来的麻烦。系统不需要确保使用当前值更新所有数据复本，因为中央位置仅有一个复本。

  • 可以在服务器上一次性定义业务和安全规则，并对所有的用户平等执行。

    可以在数据库内通过使用约束、存储过程和触发器来强制执行规则。还可在服务器应用程序中执行规则，因为这些应用程序也是许多瘦客户端访问的中央资源。

  • 关系数据库服务器只返回应用程序所需要的数据，从而优化了网络流量。

    例如，如果一个使用文件服务器的应用程序想得到一份美国俄勒冈州 (OR) 销售代表的名单，它必须检索整个雇员文件。如果该应用程序使用关系数据库服务器，将发出下面的命令：

    SELECT first_name, last_name
FROM employees
WHERE emp_title = 'Sales Representative'
  AND emp_state = 'OR'

    关系数据库只返回俄勒冈州销售代表的姓名，而不返回所有雇员的全部信息。

  • 最大程度地降低硬件成本。

    由于数据不是存储在每个客户端上，客户端不必耗费磁盘空间来存储数据。客户端无需在本地增加管理数据的功能，同时，服务器不需将处理能力耗费在显示数据上。

    可以配置服务器以优化检索数据所需的磁盘 I/O 容量，配置客户端以优化从服务器检索的数据的格式和显示。

    可以将服务器存储在一个相对安全的位置，并配备如不间断电源供应系统这样的设备，这比完全保护每个客户端更经济。

  • 维护任务（例如备份和恢复数据）得到简化，因为这些任务都可以集中在中央服务器上执行。
SQL Server 2000 作为数据库服务器的优点

Microsoft SQL Server 2000 能提供超大型系统所需的数据库服务。大型服务器可能有成千上万的用户同时连接到 SQL Server 2000 实例。SQL Server 2000 为这些环境提供了全面的保护，具有防止问题发生的安全措施，例如，可以防止多个用户试图同时更新相同的数据。SQL Server 2000 还在多个用户之间有效地分配可用资源，比如内存、网络带宽和磁盘 I/O。

超大型 Internet 站点可将其数据分开存放在多台服务器上，从而使处理负荷分散到多台计算机上，使站点能为成千上万的并发用户提供服务。

可以在一台计算机上运行多个 SQL Server 2000 实例。例如，一个为其它许多组织提供数据库服务的组织可为每个客户组织单独运行一个 SQL Server 2000 实例，而全部实例可集中在一台计算机上。这样，既隔开了每个客户组织的数据，同时又使服务组织只需管理一台服务器计算机从而减少了费用。

SQL Server 2000 应用程序可在装有 SQL Server 2000 的计算机上运行。该应用程序通过 Windows 进程间通讯 (IPC) 组件（例如共享内存）而非通过网络连接到 SQL Server 2000。这使 SQL Server 2000 得以应用于应用程序必须在本地存储数据的小型系统中。

下图显示了一个作为大型 Web 站点和传统客户端/服务器系统的数据库服务器的 SQL Server 2000 实例。

大型 Web 站点和企业级数据处理系统通常会生成大量的数据库处理，超出了一台计算机的支持能力。在这些大型系统中，数据库服务由组成数据库服务层的一组数据库服务器提供。SQL Server 2000 不支持采用平衡负荷的聚集形式建立数据库服务层，但支持跨自主服务器组分存数据的机制。尽管每个服务器需分开管理，但组内的各个服务器可共同分担数据库处理负荷。共享同一工作负荷的一组自主服务器称为服务器联合体。有关更多信息，请参见设计联合数据库服务器。

桌面数据库系统

SQL Server 2000 不仅能作为一个功能强大的数据库服务器有效地工作，同样的数据库引擎也用在需要在客户端本地存储独立数据库的应用程序中。SQL Server 2000 可以动态地将自身配置成能有效地使用客户端桌面或膝上型电脑中的可用资源，而不需要为每个客户端专设一个数据库管理员。应用程序供应商还可以将 SQL Server 2000 作为应用程序的数据存储组件嵌入应用程序中。

当客户端使用本地 SQL Server 2000 数据库时，应用程序连接到本地数据库引擎实例，其方式与跨网络连接到远端服务器上运行的数据库引擎非常相似。二者的主要差别在于：本地连接通过本地 IPC（如共享内存），而远端连接必须通过网络。

下图显示在桌面数据库系统中使用 SQL Server 2000。


登录

若要连接到 Microsoft® SQL Server™ 2000 实例，只需给应用程序提供下面中的两条信息：

  • 运行 SQL Server 实例的计算机所在的网络名称。

  • 实例名（可选，只有在连接到命名实例时才需要）。

  • 登录标识符 (ID)。

登录 ID 是帐户标识符，用来控制对任何 SQL Server 2000 系统的访问权限。SQL Server 2000 只有在首先验证了指定的登录 ID 有效后，才完成连接。这种登录验证称为身份验证。

在登录属性中，有一个是默认数据库。当一个登录连接到 SQL Server 时，这个默认数据库就变成该连接的当前数据库，除非该连接请求指定另一个数据库作为当前数据库。

登录 ID 仅能使您连接到 SQL Server 实例。特定数据库内的权限由用户帐户控制。数据库管理员将您的登录帐户映射到您有权访问的任何数据库中的用户帐户。有关更多信息，请参见登录、用户、角色和组。

验证登录

SQL Server 实例必须验证每个连接请求所提供的登录 ID 是否具有访问该实例的权限。这一过程称为身份验证。SQL Server 2000 使用两类身份验证：Windows 身份验证和 SQL Server 身份验证。每一种身份验证都有不同类别的登录 ID。

Windows 身份验证

SQL Server 2000 sysadmin 固定服务器角色成员必须首先向 SQL Server 2000 指定所有允许连接到 SQL Server 2000 的 Microsoft Windows NT® 或 Microsoft Windows® 2000 帐户或组。当使用 Windows 身份验证时，在连接到 SQL Server 2000 时不必指定登录 ID 或密码。用户对 SQL Server 2000 的访问权限由 Windows NT 或 Windows 2000 帐户或组控制，当登录到客户端上的 Windows 操作系统时需接受身份验证。

当连接到 SQL Server 2000 时，SQL Server 2000 客户端软件向 SQL Server 2000 请求 Windows 信任连接。直到客户端使用有效的 Windows 帐户成功登录后，Windows 才打开信任连接。信任连接的属性包括打开连接的客户端的 Windows NT 和 Windows 2000 组及用户帐户。SQL Server 2000 从信任连接属性中得到用户的帐户信息，并将它们与定义为有效 SQL Server 2000 登录的 Windows 帐户相匹配。如果 SQL Server 2000 找到匹配的项，则接受这个连接。当使用 Windows 2000 身份验证连接到 SQL Server 2000 时，用户标识即是 Windows NT 或 Windows 2000 组或用户帐户。

Microsoft Windows 98 操作系统不支持服务器端的信任连接 API。SQL Server 在 Windows 98 上运行时不支持 Windows 身份验证。用户在连接时必须提供 SQL Server 登录帐户。当 SQL Server 在 Windows NT 或 Windows 2000 上运行时，Windows 95 和 Windows98 客户端可以使用 Windows 2000 身份验证与其连接。

SQL Server 身份验证

sysadmin 固定服务器角色成员首先向 SQL Server 2000 指定所有有效的 SQL Server 2000 登录帐户和密码。这些登录帐户和密码与用户的 Microsoft Windows 帐户或网络帐户无关。当连接到 SQL Server 2000 时，用户必须提供 SQL Server 2000 登录帐户和密码。系统将通过用户的 SQL Server 2000 登录帐户在 SQL Server 2000 中标识用户。

SQL Server 身份验证模式

当 SQL Server 2000 在 Windows NT 或 Windows 2000 上运行时，sysadmin 固定服务器角色成员可以指定下面两种身份验证模式之一：

  • Windows 身份验证模式

    只进行 Windows 身份验证。用户不能指定 SQL Server 2000 登录 ID。这是 SQL Server 2000 的默认身份验证模式。不能为在 Windows 98 上运行的 SQL Server 实例指定 Windows 身份验证模式，因为此操作系统不支持 Windows 身份验证。

  • 混合模式

    如果用户在登录时提供了 SQL Server 2000 登录 ID，则系统将使用 SQL Server 身份验证对其进行验证。如果没有提供 SQL Server 2000 登录 ID 或请求 Windows 身份验证，则使用 Windows 身份验证对其进行身份验证。

这些模式在安装过程中指定或使用 SQL Server 企业管理器指定。

登录委托

如果使用 Windows 身份验证登录到运行在 Windows 2000 上的 SQL Server 2000 实例，并且计算机启用了 Kerberos 支持，则 SQL Server 2000 可将 Windows 登录凭据传递给其它 SQL Server 实例。两个实例间的凭据委托有时称为模拟，尤其是在两个 SQL Server 实例运行在同一台计算机上时。

例如，如果实例 A 和实例 B 运行在两台使用 Windows 2000 的计算机上，那么您可以连接到实例 A 并执行一个分布式查询来引用实例 B 中的表。当实例 A 连接到实例 B 检索所需数据时，实例 A 可以使用您的 Windows 帐户凭据进行连接。实例 B 对您的特定帐户是可视的，并可验证您访问所请求数据的个别权限。

没有委托时，管理员必须指定实例 A 用于连接到实例 B（或任何其它实例）的登录。使用该登录时不考虑哪个用户在实例 A 上执行分布式查询，并阻止实例 B 了解执行查询的实际用户。实例 B 的管理员不能针对来自实例 A 的个别用户定义权限，他们必须为实例 A 使用的登录帐户定义一个全局权限集。管理员也不能审核哪些特定用户在实例 B 中执行了操作。在 Windows 2000 上，在 Windows 身份验证中使用委托可使管理员对用户权限有更多的控制，并使个别用户的操作对审核员更透明。

请参见

安全管理

安全帐户委托


客户端组件

客户端不直接访问 Microsoft® SQL Server™ 2000，而是使用为访问 SQL Server 中的数据而编写的应用程序。这些应用程序可包括 SQL Server 2000 附带的实用工具、可访问 SQL Server 2000 的第三方应用程序、由编程人员在 SQL Server 2000 站点或 Web 页上开发的内部应用程序。也可通过 COM、Microsoft ActiveX® 或 Windows® DNA 组件访问 SQL Server 2000。

SQL Server 2000 支持两类主要的应用程序：

  • 关系数据库应用程序，这类应用程序将 Transact-SQL 语句发送给数据库引擎，并以关系结果集的形式返回结果。

  • Internet 应用程序，这类应用程序将 Transact-SQL 语句或 XPath 查询发送给数据库引擎，并以 XML 文档的形式返回结果。
关系数据库 API

通过数据库应用程序接口 (API) 编写用于访问 SQL Server 2000 的关系数据库应用程序。数据库 API 包括以下两部分：

  • 传递给数据库的语言语句。

    关系 SQL Server 2000 应用程序使用的语言是 Transact-SQL。Transact-SQL 支持所有的 SQL-92 入门级 (Entry Level) SQL 语句和很多附加的 SQL-92 功能。它还支持对 SQL-92 的ODBC 扩展和对 Transact-SQL 的其它专用扩展。

  • 一组用于向数据库发送语言语句并处理由数据库返回的结果的函数或面向对象的接口与方法。
本机 API 支持

本机 API 支持是指将 API 函数调用直接映射到送往服务器的网络协议。没有到另一个 API 的中间转换。SQL Server 2000 为两类主要的数据库 API 提供本机支持：

  • OLE DB

    SQL Server 2000 包含一个本机 OLE DB 提供程序。该提供程序支持用 OLE DB 编写的应用程序或其它使用 OLE DB 的 API（例如 ActiveX 数据对象 (ADO)）。通过本机提供程序，SQL Server 2000 还支持使用 OLE DB 的对象或组件，例如 ActiveX、ADO 或 Windows DNA 应用程序。

  • ODBC

    SQL Server 2000 包含一个本机 ODBC 驱动程序。该驱动程序支持用 ODBC 编写的应用程序或组件，或其它使用 ODBC 的 API（例如：DAO、RDO 和 Microsoft 基础类 (MFC) 数据库类）。

一个支持非本机 API 的示例是：一个数据库没有 OLE DB 提供程序，但有 ODBC 驱动程序。一个 OLE DB 应用程序可以此 OLE DB 提供程序，通过 ODBC 驱动程序使 ODBC 连接数据库。该提供程序将来自此应用程序的 OLE DB API 函数调用映射到发往 ODBC 驱动程序的 ODBC 函数调用。

其它 SQL Server API 支持

SQL Server 2000 还支持：

  • DB-Library

    DB-Library 是 SQL Server 2000 和 Microsoft SQL Server 专用的 API。SQL Server 2000 支持用 C 语言编写的 DB-Library 应用程序。DB-Library 的功能没有超出它在 Microsoft SQL Server 6.5 版中的功能。在早期版本的 Microsoft SQL Server 基础上开发的现有 DB-Library 应用程序可以在 SQL Server 2000 上运行，但 DB-Library 应用程序不能使用 SQL Server 2000 和 SQL Server 7.0 版中引入的很多功能。

  • 嵌入式 SQL

    SQL Server 2000 包含一个用于嵌入式 SQL API 的 C 语言预编译器。嵌入式 SQL 应用程序使用 DB-Library DLL 访问 SQL Server 2000。

XML 访问

Internet 应用程序检索 XML 文档而非关系结果集形式的结果。这些应用程序执行 XPath 查询，或执行使用 FOR XML 子句指定返回 XML 文档形式的结果的 Transact-SQL 语句。如果在指向 SQL Server 2000 实例的 Microsoft Internet Information 服务器 (IIS) 上定义了一个虚拟根，IIS 应用程序可通过三种机制执行 XPath 查询或 Transact-SQL 语句：

  • 执行引用虚拟根并包含 XPath 查询或带有 FOR XML 子句的 Transact-SQL 语句的统一资源定位器 (URL)。

  • 使用 ADO API 对含有 FOR XML 子句的 Transact-SQL 语句执行 XPath 查询。

  • 使用 OLE DB API 对含有 FOR XML 子句的 Transact-SQL 语句执行 XPath 查询。
客户端通讯

用于 SQL Server 2000 的 Microsoft OLE DB 提供程序、SQL Server 2000 ODBC 驱动程序和 DB-Library 每一个都作为一个 DLL 实现，并通过一个称为客户端 Net-Library 的组件与 SQL Server 2000 通讯。

请参见

应用程序开发构架

生成 SQL Server 应用程序概述


通讯组件

Microsoft® SQL Server™ 2000 支持几种在客户端应用程序和服务器之间通讯的方法。如果应用程序与 SQL Server 2000 实例在同一台计算机上，则使用 Windows 进程间通讯 (IPC) 组件，例如本地命名管道或共享内存进行通讯。如果应用程序在另外一台客户机上，则使用网络 IPC 与 SQL Server 进行通讯。

IPC 有两个组件：

  • 应用程序编程接口 (API)

    API 定义一组软件用以向 IPC 发送请求并从 IPC 检索结果的函数。

  • 协议

    协议定义任意两个通过 IPC 通讯的组件之间传输信息的格式。如果是网络 IPC，协议定义两台使用 IPC 的计算机之间以数据包格式传输信息。

有些网络 API 可以用于多个协议。例如，命名管道 API 和 Microsoft Win32® RPC API 都可以用于多个协议。还有一些网络 API（如 Banyan VINES API）则只能用于一个协议。

当 SQL Server 2000 客户端通讯组件连接到 SQL Server 2000 时，不需要或只需要很少的管理。尽管实际的通讯组件实施比 SQL Server 早期版本复杂得多，但 SQL Server 2000 用户连接到 SQL Server 2000 实例时可避免这一复杂过程。SQL Server 2000 客户端软件能够动态地确定与 SQL Server 2000 实例通讯所需的网络地址。客户端软件所需要的全部信息就是：运行 SQL Server 2000 实例的计算机的网络名，若连接到命名实例则还需实例名。SQL Server 2000 用户几乎不需要使用客户端网络实用工具管理客户端通讯组件。

系统区域网络

SQL Server 2000 企业版引入了对使用虚拟接口构架 (VIA) 生成的系统区域网络 (SAN) 协议的支持。SAN 是一种用于互连服务器或服务器群集的高速、高度可靠的网络。一个多层的分布式系统在服务器之间产生的网络流量可达到非常高的水平。在这样的系统中，只有当消息传输足够快，可以使服务器花费在处理消息和等待答复的时间减到最小时，才有可能获得性能收益。与局域网 (LAN) 或广域网 (WAN) 相比，SAN 通过降低 CPU 负荷和消息滞后时间，使消息传递流量达到很高的水平。另外，SAN 比 LAN 或 WAN 更可靠，并以服务器组或服务器群集的方式实现，因此各服务器彼此离得很近（如位于同一计算机房内）。

Compaq®、Intel®、Microsoft 和其它公司已将虚拟接口构架 (VIA) 定义为一个普通的 SAN 定义，使得可以实现许多可能的硬件版本。虚拟接口构架允许 VIA 提供商使用标准组件，以低成本实现灵活的、可伸缩的和可靠的消息传递组件。VIA SAN 可以支持对大型 Web 服务器的大量消息传递要求。

虚拟接口构架定义了一个 API 和一个协议。此 API 称为 VIA API，而此协议称为 VIA 协议。

SAN 很适合与 SQL Server 2000 一起用于下列用途：

  • 构成业务服务层的应用程序服务器可以使用 SAN 实现与数据服务层的高速通讯。这在应用程序服务器和数据库服务器位于同一物理位置时实现。

  • SQL Server 2000 服务器可以使用 SAN 提高分布式查询和分布式事务的性能，以及在位于同一位置的服务器之间进行数据复制的性能。对于用于实现运行 SQL Server 的计算机联合体的分布式视图，SAN 可以提高支持这类视图所需的分布式查询的性能。

SQL Server 2000 支持 ServerNet II 和 Giganet VIA SAN 版本。因为 SAN 用于支持服务器之间的高通讯带宽，SQL Server 2000 只支持 Windows NT® Server、Windows 2000 Data Center、Windows 2000 Advanced Server 和 Windows 2000 操作系统上的 VIA Net-Library。


客户端和服务器 Net-Library

Microsoft® SQL Server™ 2000 通过称为客户端 Net-Library 的组件将用于 SQL Server 2000 的 OLE DB 提供程序、SQL Server 2000 ODBC 驱动程序和 DB-Library DLL 同使用不同进程间通讯 (IPC) 组件进行通讯的详细信息隔离开。服务器 Net-Library 也为数据库引擎执行同样的功能。

下列组件按下面的顺序管理 SQL Server 2000 与其客户端之间的通讯：

  1. 客户端应用程序调用 OLE DB、ODBC、DB-Library 或嵌入式 SQL API。这将使 OLE DB 提供程序、ODBC 驱动程序或 DB-Library DLL用于 SQL Server 通讯。

  2. OLE DB 提供程序、ODBC 驱动程序或 DB-Library DLL 调用客户端 Net-Library。客户端 Net-Library 调用 IPC API。

  3. 通过基础 IPC 将客户端对 IPC API 的调用传输给服务器 Net-Library。如果是本地 IPC，将使用 Windows 操作 IPC（例如共享内存或本地命名管道）传输调用。如果是网络 IPC，客户端的网络协议栈将通过网络与服务器上的网络协议栈通讯。

  4. 服务器 Net-Library 将来自客户端的请求传递给 SQL Server 2000 实例。

SQL Server 2000 按相反的顺序答复客户端。

下图显示当 SQL Server 应用程序在装有 SQL Server 实例的同一台计算机上运行时的通讯路径。

这是在 SQL Server 应用程序通过 LAN 或 WAN 连接到另一台计算机上的 SQL Server 2000 实例时的简化通讯路径图示。虽然图中显示了使用特定 Net-Library 的用于 SQL Server 2000 的 OLE DB 提供程序、SQL Server ODBC 驱动程序和DB-Library DLL，但对这些组件连接这些 Net-Library 没有任何限制。这些提供程序、驱动程序和 DB-Library 每个都可以使用任何的 SQL Server Net-Library。

SQL Server 2000 将 Net-Library 分为主 Net-Library 和次 Net-Library。用于 SQL Server 2000 的 OLE DB 提供程序、SQL Server 2000 ODBC 驱动程序、DB-Library DLL 和数据库引擎只能直接与以下两个主 Net-Library 通信：

  • 默认情况下，应用程序与同一计算机上的 SQL Server 2000 实例之间的本地连接使用共享内存主 Net-Library。该路径见上面的图示。

  • 计算机间连接通过超级套接字主 Net-Library 通讯。超级套接字 Net-Library 有两条通讯路径：
    • 若选择 TCP/IP 套接字连接或 NWLINK IPX/SPX 连接，超级套接字 Net-Library 直接为应用程序和 SQL Server 2000 实例间的通讯调用 Windows 套接字 2 API。

    • 如果选择命名管道、虚拟接口构架 (VIA) SAN、多协议、AppleTalk 或 Banyan VINES 连接，则超级套接字 Net-Library 的子组件（称为 Net-Library 路由器）将为选择的协议装载次 Net-Library，并将所有的 Net-Library 调用路由到该 Net-Library。

下图更详细地显示了运行 SQL Server 2000 客户端组件的计算机和运行 SQL Server 2000 实例的计算机之间的网络连接，通过客户端和服务器 Net-Library 通讯的路径。

服务器超级套接字 Net-Library 作为 Ssnetlib.dll 实现，而客户端超级套接字 Net-Library 作为 Dbnetlib.dll 实现。

下表显示 Net-Library 如何与 IPC API 及用于连接的协议相关。

网络实用工具中指定的协议 | 使用的客户端 Net-Library | 使用的服务器 Net-Library | Net-Library 调用的 IPC API | 支持 IPC API 的协议
TCP/IP 套接字 | Dbnetlib.dll | Ssnetlib.dll | Windows 套接字 2 | TCP/IP
命名管道 | Dbnetlib.dll 路由至 Dbnmpntw.dll | Ssnetlib.dll 路由至 Ssnmpn70.dll（仅限于 Microsoft Windows NT® 和 Windows® 2000） | Windows 命名管道 | 文件系统（本地） TCP/IP NetBEUI NWLink
NWLink IPX/SPX | Dbnetlib.dll | Ssnetlib.dll | Windows 套接字 2 | NWLink
VIA ServerNet II SAN | Dbnetlib.dll 路由至 Dbmssnet.dll（仅限于 Microsoft Windows NT 和 Windows 2000） | Ssnetlib.dll 路由至 Dbmssnet.dll（仅限于 Microsoft Windows NT 和 Windows 2000） | 虚拟接口构架 (VIA) | 虚拟接口构架 (VIA)
VIA GigaNet SAN | Dbnetlib.dll 路由至 Dbmsgnet.dll（仅限于 Microsoft Windows NT 和 Windows 2000） | Ssnetlib.dll 路由至 Dbmsgnet.dll（仅限于 Microsoft Windows NT 和 Windows 2000） | 虚拟接口构架 (VIA) | 虚拟接口构架 (VIA)
多协议 | Dbnetlib.dll 路由至 Dbmsrpcn.dll | Ssnetlib.dll 路由至 Ssmsrpc.dll（仅限于默认实例） | Windows RPC | 文件系统（本地） TCP/IP NetBEUI NWLink
AppleTalk | Dbnetlib.dll 路由至 Dbmsadsn.dll | Ssnetlib.dll 路由至 Ssmsad70.dll（仅限于默认实例） | AppleTalk ADSP | AppleTalk
Banyan Vines | Dbnetlib.dll 路由至 Dbmsvinn.dll | Ssnetlib.dll 路由至 Ssmsvi70.dll（仅限于默认实例） | Banyan VINES SPP | Banyan VINES

在 Microsoft Windows® 98 上运行的 SQL Server 2000 实例不支持服务器命名管道和 Banyan VINES Net-Library，因为 Windows 98 操作系统不支持这些 API 的服务器部分。SQL Server 2000 在 Windows 98 上支持这些 Net-Library 的客户端部分；因此，在 Windows 98 上运行的应用程序可使用 Net-Library 连接到 Microsoft Windows NT 或 Microsoft Windows 2000 上的 SQL Server 实例。在 Microsoft Windows 98 上运行的应用程序也可使用这些 Net-Library 建立连接。

AppleTalk Net-Library 不在运行 Windows 95 或 Windows 98 的计算机上运行。

VIA 网络旨在使位于同一数据中心的服务器之间实现高水平的消息传递流量，比如在一个作为一台或多台 Internet Information 服务应用程序服务器实现的 Web 站点内，其中的每台服务器连接到一台或多台运行 SQL Server 的数据库服务器。VIA 网络并不用于连接个别的工作站。客户端和服务器 SQL Server VIA Net-Library 都只受 Windows NT Server、Windows NT Advanced Server、Windows 2000 Server、Windows 2000 Advanced Server 和 Windows 2000 Data Center 的支持。

SQL Server 2000 的命名实例仅支持命名管道、TCP/IP 套接字、NWLink IPX/SPX 和共享内存 Net-Library。命名实例不支持多协议、AppleTalk 或 Banyan VINES Net-Library。为了保持与 SQL Server 早期版本的兼容性，默认实例支持所有的服务器 Net-Library。

一些 Net-Library 只支持一种类型的协议栈。例如，AppleTalk Net-Library 需要 AppleTalk 协议栈。其它的 Net-Library，如命名管道和多协议 Net-Library 可支持多个协议栈。

Microsoft SQL Server Net-Library 已针对 Microsoft 协议栈做了大量的测试，并得到这些协议栈的支持。如果其它供应商的协议栈完全支持 Microsoft SQL Server Net-Library 所使用的 API，这些协议栈也应该有效。

使用命名管道或多协议 Net-Library 将应用程序连接到同一台计算机上的 SQL Server 实例时，如果这台计算机没有协议栈，IPC API 将由文件系统实现。


控制 Net-Library 和通讯地址

安装 Microsoft® SQL Server™ 2000 之后，即可使用客户端网络实用工具定义客户端 Net-Library 的行为，使用服务器网络实用工具定义服务器 Net-Library 的行为。

每个 SQL Server 2000 实例都可以同时监听服务器 Net-Library 的任何组合。每个数据库引擎可执行文件集都有一套服务器 Net-Library。这些服务器 Net-Library 安装在：C:\Program Files\Microsoft SQL Server\MSSQL$n，其中 n 是与此数据库引擎可执行文件集相关联的数字。

所有的服务器 Net-Library 都在 SQL Server 安装的服务器部分安装，但有些 Net-Library 可能是非活动的。运行安装程序的人员可选择哪些 Net-Library 组合对正在安装的实例是活动的。下表显示在 Microsoft Windows NT®、Microsoft Windows® 2000 和 Microsoft Windows 98 操作系统中，由 SQL Server 安装程序激活的默认服务器 Net-Library。

Windows NT 和 Windows 2000 | Windows 98
TCP/IP 套接字 | TCP/IP 套接字
共享内存 | 共享内存
命名管道 |

禁用和启用 Net-Library

安装后，用户可为使用服务器网络实用工具的数据库计算机上的每个 SQL Server 实例分别启用和禁用服务器 Net-Library。当禁止特定实例使用某个服务器 Net-Library 时，该实例的数据库引擎将不装载此服务器 Net-Library，也不接受使用此 Net-Library 的连接。但此服务器 Net-Library 仍装在机器上，可为其它共享同一可执行文件集的实例启用。有关更多信息，请参见 SQL Server 网络实用工具。

在运行 SQL Server 2000 客户端组件的任何一台计算机上总是装有一个客户端 Net-Library DLL 集。此客户端 Net-Library DLL 安装在 C:\Windows\System32 或 C:\Windows\System 目录中。安装 SQL Server 2000 客户端实用工具时，将安装所有这些客户端 Net-Library。可使用客户端网络实用工具启用和禁用各种客户端 Net-Library。当一个客户端 Net-Library 被禁用时，尽管它仍装在机器上，但不用于任何连接。可以：

  • 指定对于所有连接（使用服务器别名的连接除外），按照怎样的顺序使用客户端 Net-Library。

  • 启用或禁用特定的客户端 Net-Library。

  • 作为兼容性选项，定义服务器的别名，以确定在连接到 SQL Server 7.0 版或更早的版本时使用的特定 Net-Library 和连接参数。

有关更多信息，请参见配置客户端 Net-Library。

连接 SQL Server 2000

为使客户端能够连接运行 SQL Server 2000 的服务器，客户端必须使用一个与服务器当前正在监听的其中一个服务器 Net-Library 相匹配的客户端 Net-Library。而且，客户端和服务器都必须运行一个协议栈，以支持用于连接的 Net-Library 所调用的网络 API。例如，如果客户端试图使用客户端多协议 Net-Library，且服务器正在监听服务器多协议 Net-Library，但是服务器使用 TCP/IP 协议运行，而客户端计算机只使用 IPX/SPX 协议栈运行，那么客户端将无法连接到服务器。客户端和服务器必须使用相同的 Net-Library 并运行相同的协议栈。

计算机上的每个 SQL Server 实例必须监听不同的网络地址以便应用程序能连接到特定的实例。SQL Server 2000 的默认实例监听与 SQL Server 早期版本相同的默认网络地址，以使现有的客户端计算机能继续连接到默认实例。下表显示 SQL Server 2000 实例监听的默认网络地址。

Net-Library | 默认实例网络地址 | 命名实例网络地址
TCP/IP 套接字 | TCP 端口 1433 | MSSQL$instancename 服务第一次启动时将动态选择 TCP 端口。
命名管道 | \\computername\pipe\sql\query | \\computername\pipe\MSSQL$instancename\sql\query
NWLink IPX/SPX | 端口 33854 | 33854 后每个实例的第一个可用端口。
VIA ServerNetII SAN | VIA Port 0:1433 | VIA Port 0:1433
VIA Giganet SAN | VIA Port 0:1433 | VIA Port 0:1433

VIA 服务器 Net-Library 指派给默认实例和命名实例同一默认地址。系统管理员必须使用服务器网络实用工具给计算机上的每一实例分配唯一的端口地址。

可使用 SQL Server 2000 服务器网络实用工具为客户端连接查找每个 SQL Server 实例正在监听的特定网络地址集。

当 SQL Server 2000 客户端 Net-Library 连接到 SQL Server 2000 实例时，仅需要运行该实例的计算机所在的网络名和该实例名。当应用程序请求连接远端计算机时，Dbnetlib.dll 将打开到连接中所指定的计算机网络名上的 UDP 端口 1434 的连接。所有运行 SQL Server 2000 实例的计算机都监听此端口。当一个客户端 Dbnetlib.dll 连接到该端口时，服务器将返回一个监听服务器上运行的所有实例的数据包。对于每个实例，该数据包报告该实例正在监听的服务器 Net-Library 和网络地址。应用程序计算机上的 Dbnetlib.dll 收到该数据包后，选择在应用程序计算机和 SQL Server 实例上都启用的 Net-Library，然后连接为此数据包中的 Net-Library 列出的地址。只有在以下情况下该连接尝试才会失败：

  • 请求的 SQL Server 2000 实例未运行。

  • 在应用程序计算机上，SQL Server 2000 实例正在监听的 Net-Library 没有一个是活动的。

当 Dbnetlib.dll 将应用程序计算机上启用的网络协议与 SQL Server 2000 实例上启用的网络协议进行比较时，使用应用程序计算机上的客户端网络实用工具指定比较序列。例如，假设应用程序计算机启用了三个客户端 Net-Library 并指定比较序列依次为 TCP/IP 套接字、NWLink IPX/SPX 和命名管道。如果应用程序计算机尝试连接仅启用了 NWLink IPX/SPX、命名管道和多协议服务器 Net-Library 的 SQL Server 2000 实例，则使用 NWLink IPX/SPX 进行连接。有关配置比较序列的更多信息，请参见配置客户端 Net-Library。

在运行 SQL Server 2000 实例的计算机上，不能将 UDP 端口 1434 指派给 SQL Server 以外的应用程序。管理网络筛选的网络管理员必须允许在 UDP 端口 1434 上进行通讯，以使 SQL Server 2000 连接能够通过筛选。

当在装有 SQL Server 默认实例的同一台计算机上运行应用程序时，可使用以下名称引用默认实例。

Windows NT 和 Windows 2000 | Windows 95 和 Windows 98
计算机名 | 计算机名
(local)* | (local)*
.* |

*这里的"(local)"是带括号的单词 local，"."是一个句点或圆点。"."仅在 SQL Server 实用工具中有效，例如在 SQL 查询分析器和 osql 中；不能在 API 连接请求中指定。

不要使用 (local) 或 . 连接使用故障转移群集实现的虚拟服务器。

建议使用计算机名。这些连接将通过共享内存 Net-Library 建立。DB-Library 不支持使用 (local)。

连接早期 SQL Server 实例

当使用 SQL Server 2000 客户端组件的应用程序连接 SQL Server 7.0 版或更早版本的实例时，实例与应用程序之间的通讯与 SQL Server 的早期版本相同。使用 SQL Server 7.0 版或其早期版本客户端组件的应用程序连接 SQL Server 2000 默认实例时，这些实例与应用程序之间的通讯也与 SQL Server 早期版本相同。在这两种情况中，用户必须用管理 SQL Server 早期版本网络地址的方法来管理网络地址。有关在 SQL Server 早期版本中配置客户端的更多信息，请参见管理客户端。

SQL Server 6.5 版和更早版本仅在命名管道和多协议 Net-Library 上支持 Windows 身份验证（在这些版本中称为集成安全性）。SQL Server 2000 和 SQL Server 7.0 版在所有 Net-Library 上都支持 Windows 身份验证。现有的使用默认命名管道 Net-Library 的 SQL Server 6.5 版或 7.0 版应用程序可用于打开 Windows 身份验证与 SQL Server 6.5 版实例的连接。然而，如果将应用程序计算机上的 SQL Server 客户端实用工具升级到 SQL Server 2000，则默认 Net-Library 将改为 TCP/IP，任何尝试打开 Windows 身份验证与 SQL Server 6.5 版实例的连接操作都将失败。要想解决这一问题，可使用客户端网络实用工具将命名管道 Net-Library 放在 Net-Library 列表的最顶端，使其作为默认 Net-Library。

请参见

管理客户端

管理服务器


表格格式数据流协议

Microsoft® SQL Server™ 2000 使用一个称为表格格式数据流 (TDS) 的应用程序级协议进行客户端应用程序与 SQL Server 之间的通讯。TDS 数据包封装在 Net-Library 所使用的协议栈生成的数据包中。例如，如果使用的是 TCP/IP 套接字 Net-Library，TDS 数据包就封装在基础协议的 TCP/IP 数据包中。

将结果集发送回应用程序的数据包的内容取决于是否在传递给数据库引擎的 Transact-SQL 语句中指定了 FOR XML：

  • 如果没有指定 FOR XML，数据库引擎将关系结果集发送回应用程序。TDS 数据包中包含结果行集，每行包括一列或多列，就像在 SELECT 语句的选择列表中指定的那样。

  • 如果指定了 FOR XML，数据库引擎将 XML 文档以流的形式返回给应用程序。在 TDS 数据包中，XML 文档被格式化为单个的、长 Unicode 值，每个数据包的大小约为 4 KB。

可以配置 SQL Server 数据包大小，即 TDS 数据包大小。大多数客户端上的 TDS 数据包大小默认为 4 KB（DB-Library 应用程序默认为 512 字节），经过测试证明，在几乎所有的方案中，这是最佳的 TDS 数据包大小。TDS 数据包大小可以比基础协议中的数据包大。如果是这种情况，发送数据包的计算机上的协议栈自动将 TDS 数据包分解成适合协议数据包大小的单元，客户端计算机上的协议栈则在接收计算机上将 TDS 数据包重新组合在一起。


Net-Library 加密

Microsoft® SQL Server™ 2000 可使用安全套接字层 (SSL) 加密在应用程序计算机和数据库计算机上的 SQL Server 实例之间传输的所有数据。SSL 加密在超级套接字 Net-Library（Dbnetlib.dll 和 Ssnetlib.dll）内执行，并应用于 SQL Server 2000 支持的所有计算机间协议。当激活 SSL 加密时，超级套接字 Net-Library 在执行以下操作前执行 SSL 加密：

  • 调用 Windows 套接字 2 API 传输 TCP/IP 套接字或 NWLink IPX/SPX 套接字。

  • 调用 Net-Library 路由器将数据包发送到命名管道、多协议、AppleTalk 或 Banyan VINES Net-Library。

SSL 加密仅适用于运行于获得公共证书颁发机构证书的计算机上的 SQL Server 2000 实例。应用程序正在其上运行的计算机还必须有一个从同一证书颁发机构取得的根 CA 证书。

Net-Library 加密通过安全套接字层 API 实现。采用 40 位还是 128 位加密级别取决于在应用程序计算机和数据库计算机上运行的 Microsoft Windows® 操作系统的版本。

启用加密会降低 Net-Library 的性能。除所有未加密连接的工作外，加密还强制执行以下操作：

  • 连接时需要额外的网络往返次数。

  • 所有从应用程序发送到 SQL Server 实例的数据包必须由客户端 Net-Library 加密并由服务器 Net-Library 解密。

  • 所有从 SQL Server 实例发送到应用程序的数据包必须由服务器 Net-Library 加密并由客户端 Net-Library 解密。

共享内存 Net-Library 通讯本身具有安全性，无需加密。共享内存 Net-Library 不参与计算机间的通讯。不能从任何其它 Windows 进程访问应用程序进程与数据库引擎进程之间的共享内存区。

为了与 SQL Server 的早期版本兼容，多协议 Net-Library 将继续支持自己的加密。这种加密与 SSL 加密分开指定，并通过调用 Windows RPC 加密 API 实现。不要求使用证书。采用 40 位还是 128 位的 RPC 加密级别取决于在应用程序计算机和数据库计算机上运行的 Windows 操作系统的版本。命名实例不支持多协议 Net-Library。


服务器组件

除了服务器 Net-Library 外，Microsoft® SQL Server™ 2000 还包含以下主要的服务器组件：

  • SQL Server 数据库引擎（MSSQLServer 服务）

  • SQL Server 代理程序（SQLServerAgent 服务）

  • Microsoft 搜索服务

  • Microsoft 分布式事务处理协调器（MS DTC 服务）

运行 Microsoft Windows NT®、Windows® 2000 和 Windows 98 操作系统的计算机支持这四种服务器组件。运行 Microsoft Windows 95 的计算机不支持服务器组件。当 SQL Server 在 Windows NT 或 Windows 2000 上运行时，SQL Server 数据库引擎、SQL Server 代理程序和 MS DTC 均作为 Windows NT 或 Windows 2000 服务来实现。在 Windows 98 上，服务器组件不作为服务来实现，因为该操作系统不支持服务。Microsoft 搜索服务在 Windows 95 或 Windows 98 上不可用。

停止和启动服务器组件的方法有：

  • Windows NT 和 Windows 2000 在操作系统启动时自动启动每个服务。

  • 使用 SQL Server 服务管理器启动或停止服务。

  • 使用 SQL Server 企业管理器启动或停止服务。

  • 在 Windows NT 或 Windows 2000 中，使用 net start 和 net stop 命令提示命令停止或开始每个服务（故障转移群集中的虚拟服务器除外）。

SQL Server 2000 支持运行 Windows NT 或 Windows 2000 计算机上的多个 SQL Server 实例。每个实例都有自己的 SQL Server 服务和 SQL Server 代理服务复本。Microsoft 搜索服务或 MS DTC 服务只有单个复本，这些服务可由计算机上运行的多个 SQL Server 实例共享。


SQL Server 服务

Microsoft® SQL Server™ 2000 数据库引擎在 Microsoft Windows NT® 或 Microsoft Windows® 2000 操作系统上作为服务运行。它在 Microsoft Windows 98 上不作为服务运行，因为该操作系统不支持服务。SQL Server 在 Windows NT 和 Windows 2000 上也可以作为可执行文件运行，但它通常都作为服务运行。

当多个 SQL Server 实例在同一台计算机上运行时，每个实例都有自己的 SQL Server 服务。默认实例的服务名称为 MSSQLServer，命名实例的服务名称为 MSSQL$InstanceName。有关更多信息，请参见多个 SQL Server 实例。

SQL Server 服务管理组成由 SQL Server 实例拥有的数据库的所有文件。它是用来处理所有发自 SQL Server 客户端应用程序的 Transact-SQL 语句的组件。SQL Server 还支持分布式查询检索来自不同数据源的数据，而不只是 SQL Server 中的数据。

SQL Server 服务可在多个并发用户之间有效地分配计算机资源，并强制实施在存储过程和触发器中定义的业务规则，确保数据的一致性，防止发生逻辑问题（例如防止两个人试图同时更新同一数据）。


SQL Server 代理服务

SQL Server 代理程序支持的功能包括：允许在 Microsoft® SQL Server™ 2000 上调度定期执行的活动，以及通知系统管理员服务器所发生的问题。实现这些功能的 SQL Server 代理程序组件有：

  • 作业

    由一个或多个要执行的步骤组成的已定义对象。这些步骤为可执行的 Transact-SQL 语句。作业可以调度，例如，调度作业在特定时间或按特定重复间隔执行。

  • 警报

    发生特定事件，例如发生特定的错误或某种严重级别的错误，或者数据库达到定义的可用空间限制时所采取的措施。可以定义警报采取一定的措施，例如发电子邮件、寻呼操作员或运行一个作业来处理问题。

  • 操作员

    由网络帐户或电子邮件标识符 (ID) 标识的人员，这些人员可以处理服务器发生的问题。他们可以是通过电子邮件、寻呼机或 net send 网络命令发出警报的目标。

SQLServerAgent 的服务名称只适用于与默认实例相关联的代理服务。与命名实例相关联的 SQL Server 代理服务称为 SQLAgent$InstanceName。

管理调度操作

下图显示用于定义和运行作业、警报和操作员的主要组件。

  • 使用下列组件指定作业、警报和操作员：
    • SQL Server 企业管理器。

    • 使用 SQL 分布式管理对象 (SQL-DMO) 的应用程序。

    • 使用 Transact-SQL 和标准数据库 API 的应用程序。
  • SQL Server 将这些定义存储在 msdb 系统数据库中。

  • SQLServerAgent 服务启动时，它将查询 msdb 数据库中的系统表以确定启用哪些作业和警报。

  • SQL Server 代理程序按调度的时间执行作业。

  • SQL Server 将所有发生的事件传递给 SQL Server 代理程序。

  • SQL Server 代理程序执行所有警报，或向 SQL Server 发送 SQL 邮件请求，或向 Windows 发送 net send 命令。

与 SQL Server 6.5 版及更早的版本相比，SQL Server 2000 的自动化程度更高，并能更高效地优化自身以满足不同的处理需要。这些特点降低了发生触发警报的异常情况的可能性。调度作业对于处理要反复执行的任务（例如备份过程）仍是一个很好的办法。

请参见

自动化管理任务


Microsoft 搜索服务

Microsoft 搜索服务是一个全文索引和搜索引擎。

SQL-92 标准只定义了基本的字符搜索功能：

  • 检索等于、小于或大于一个字符常量的字符值。

  • 检索包含一个字符串模式的字符值。

通过 Microsoft 搜索服务，Microsoft® SQL Server™ 2000 和 SQL Server 7.0 版能够支持在字符串列上进行的更为复杂的搜索。

Microsoft 搜索服务包括两个角色：

  • 索引支持

    实现为数据库定义的全文目录和索引。接受全文目录以及各目录中组成索引的表和列的定义。执行填充全文索引的请求。

  • 查询支持

    处理全文检索查询。确定索引中满足全文选择条件的项。每一个符合选择条件的项都会向 SQL Server 服务返回行标识及等级值，这些信息将用于构造查询结果集。所支持的查询类型包括：

    • 检索词或短语。

    • 检索意思相近的词。

    • 检索动词和名词的屈折变化形式。

全文引擎以名为 Microsoft 搜索的服务在 Microsoft Windows NT® 或 Microsoft Windows® 2000 上运行。全文引擎在自定义安装过程中选择全文检索功能时安装。Microsoft 搜索服务本身并不安装在 Microsoft Windows 95 或 Microsoft Windows 98 上，但是 Windows 95 和 Windows 98 客户端在连接到运行 Windows NT 或 Windows 2000 的 SQL Server 安装时可以使用该服务。

Microsoft 搜索服务在本地系统帐户的环境中运行。在安装过程中，SQL Server 将自我添加为一个 Microsoft 搜索服务管理员。若要确保正确维护此关系，在更改 SQL Server 服务帐户信息时，都必须通过 SQL Server 企业管理器中"SQL Server 属性"对话框的"属性"选项卡来完成。

全文目录和索引不存储在 SQL Server 数据库内，而是存储在由 Microsoft 搜索服务单独管理的文件中。只有 Microsoft 搜索服务和 Windows NT 或 Windows 2000 系统管理员可以访问全文目录文件。

请参见

全文目录和索引

全文查询构架


MS DTC 服务

Microsoft 分布式事务处理协调器 (MS DTC) 是一个事务管理器，它允许客户端应用程序在一个事务中包含多个不同的数据源。MS DTC 协调在所有已在事务中登记的服务器间提交分布式事务。

Microsoft® SQL Server™ 安装可通过下列方法参与分布式事务：

  • 调用运行 SQL Server 的远程服务器上的存储过程。

  • 自动或显式地将本地事务提升为一个分布式事务并在该事务中登记远程服务器。

  • 执行分布式更新以更新多个 OLE DB 数据源上的数据。

    如果这些 OLE DB 数据源支持 OLE DB 分布式事务接口，SQL Server 还可以将它们登记在分布式事务中。

MS DTC 服务协调正确完成分布式事务，以确保所有服务器上的全部更新为永久性的，或在发生错误时删除所有更新。

SQL Server 应用程序也可以直接调用 MS DTC 以显式启动分布式事务。然后，可以指示一台或多台运行 SQL Server 的服务器在此分布式事务中登记，并在 MS DTC 的协调下正确完成此事务。

请参见

分布式事务


多个 SQL Server 实例

Microsoft® SQL Server™ 2000 支持在同一台计算机上同时运行多个 SQL Server 数据库引擎实例。每个 SQL Server 数据库引擎实例各有一套不为其它实例共享的系统及用户数据库。应用程序连接同一台计算机上的 SQL Server 数据库引擎实例的方式与连接其它计算机上运行的 SQL Server 数据库引擎的方式基本相同。

有两种类型的 SQL Server 实例：

默认实例

SQL Server 2000 数据库引擎默认实例的运行方式与 SQL Server 早期版本的数据库引擎相同。默认实例仅由运行该实例的计算机的名称唯一标识，它没有单独的实例名。如果应用程序在请求连接 SQL Server 时只指定了计算机名，则 SQL Server 客户端组件将尝试连接这台计算机上的数据库引擎默认实例。这保留了与现有 SQL Server 应用程序的兼容性。

一台计算机上只能有一个默认实例，而默认实例可以是 SQL Server 的任何版本。

命名实例

除默认实例外，所有数据库引擎实例都由安装该实例的过程中指定的实例名标识。应用程序必须提供准备连接的计算机的名称和命名实例的实例名。计算机名和实例名以格式 computer_name\instance_name 指定。

一台计算机上可以运行多个命名实例，但只有 SQL Server 2000 数据库引擎才可作为命名实例运行。SQL Server 早期版本中的数据库引擎不能作为命名实例运行。

实例主要应用于数据库引擎及其支持组件，而不应用于客户端工具。如果安装了多个实例，则每个实例都将获得各自唯一的一套：

  • 系统和用户数据库。

  • SQL Server 和 SQL Server 代理服务。对于默认实例，服务名仍为 MSSQLServer 和 SQLServerAgent。对于命名实例，服务名改为 MSSQL$instancename 和 SQLAgent$instancename，使得这些服务与服务器上的其它实例分开启动和停止。可使用相关联的 SQL Server 服务启动和停止不同实例的数据库引擎。SQL Server 代理服务管理相关联的数据库引擎实例的调度事件。

  • 与数据库引擎、SQL Server 和 SQL Server 代理服务相关联的注册表键。

  • 使应用程序能连接特定实例的网络连接地址。
共享组件

以下组件可由运行于同一台计算机上的所有实例共享：

  • 此计算机上只有一个 SQL Server 2000 程序组 (Microsoft SQL Server)，以及由该程序组中的每个图标表示的唯一一个实用工具的复本。唯一一个 SQL Server 联机丛书的复本。

    程序组中的实用工具版本来自计算机上最先安装的 SQL Server 2000 版本。例如，如果将 SQL Server 2000 简体中文版作为默认实例安装，然后将 SQL Server 2000 美国英语版作为命名实例安装，则只有一个 SQL Server 2000 程序组。该程序组中的所有实用工具图标和 SQL Server 联机丛书图标都将启动简体中文版的工具。

    所有 SQL Server 2000 实用工具都能处理多个实例。可以从一个 SQL Server 2000 服务管理器的复本启动和停止每个实例。可使用一个 SQL Server 2000 SQL Server 企业管理器复本控制计算机上所有实例中的对象，使用一个 SQL Server 2000 服务器网络管理器复本管理计算机上所有实例的网络通讯地址。

  • 仅有一个 MSSearchService 复本管理针对计算机上所有 SQL Server 实例的全文检索。

  • English Query 和 Microsoft SQL Server 2000 Analysis Services 服务器都只有一个复本。

  • 与客户端软件相关联的注册表键在实例间不重复。

  • 只有一个 SQL Server 开发库（包括 *.lib 文件）和示例应用程序的复本。
默认实例

可作为默认实例操作的配置包括：

  • SQL Server 2000 的默认实例。

  • 作为默认实例运行的 SQL Server 7.0 版安装。

  • 作为默认实例运行的 SQL Server 6.5 版安装。

  • 可使用 SQL Server 2000 vswitch 实用工具，与 SQL Server 6.5 版安装进行版本切换的 SQL Server 2000 默认实例。

  • 可使用 SQL Server 7.0 版 vswitch 实用工具，与 SQL Server 6.5 版安装进行版本切换的 SQL Server 7.0 版安装。

    说明 在同一台计算机上安装 SQL Server 2000 实例前，必须将 SQL Server 6.5 Service Pack 5 应用于所有 SQL Server 6.5 实例。

在 SQL Server 版本间切换

不能在 SQL Server 7.0 版安装和 SQL Server 2000 默认实例之间进行版本切换。

除了默认实例外，还可以拥有任意数量的 SQL Server 2000 命名实例。在运行命名实例前，无须在计算机上运行默认实例。在没有默认实例的计算机上可运行命名实例。SQL Server 6.5 版和 SQL Server 7.0 只能作为默认实例运行，不能作为命名实例运行。

在单台计算机或单个故障转移群集中，Microsoft 不支持超过 16 个实例。

如果在一台计算机上运行作为默认实例的 SQL Server 6.5 版和一个或多个 SQL Server 2000 命名实例，则该计算机将有两个 SQL Server 程序组，而非一个 SQL Server 程序组：

  • SQL Server 2000 程序组执行 SQL Server 2000 工具。

  • SQL Server 6.5 版程序组运行 SQL Server 6.5 工具。

如果同时运行 SQL Server 7.0 版和 SQL Server 2000，则 SQL Server 7.0 程序组中的图标将执行 SQL Server 2000 工具。

说明 在同一台计算机上安装 SQL Server 2000 实例前，必须将 SQL Server 6.5 Service Pack 5 应用于所有 SQL Server 6.5 实例。

故障转移群集上的多个 SQL Server 实例

在一个 SQL Server 故障转移群集中，每台虚拟服务器上只能运行一个 SQL Server 实例，但在一个故障转移群集中则可以安装最多 16 台虚拟服务器。该实例可以是默认实例也可以是命名实例。在连接此 SQL Server 实例的应用程序看来，虚拟服务器就像是单台计算机。当应用程序连接到虚拟服务器时，它们使用连接 SQL Server 的任何实例时所使用的同一规则；它们指定群集的虚拟服务器名和可选实例名（只有命名实例才需要）：virtualservername\instancename。有关群集的更多信息，请参见故障转移群集构架。


与多个实例进行通讯

每个 Microsoft® SQL Server™ 2000 实例都监听一组不同的网络地址，以便应用程序能连接不同的实例。无须将 SQL Server 2000 客户端特意配置为连接 SQL Server 2000 实例。SQL Server 2000 客户端组件查询运行 SQL Server 2000 实例的计算机，以确定每个实例的 Net-Library 和网络地址。然后，客户端组件透明地为连接选择一个支持的 Net-Library 和地址，而不必在客户端上进行配置。应用程序必须提供的唯一信息是计算机名和实例名。有关更多信息，请参见控制 Net-Library 和通讯地址。

SQL Server 2000 默认实例与 SQL Server 早期版本监听相同的网络地址。因此，使用 SQL Server 7.0 版或更早版本的客户端连接组件可以不做任何改变地继续连接默认实例。命名实例监听备用网络地址，同时，必须将使用 SQL Server 7.0 版或更早版本客户端连接组件的客户端计算机设置为连接备用地址。


使用多个实例

尽管在单台计算机上运行多个 Microsoft® SQL Server™ 2000 实例扩充了 SQL Server 的功能，但对于大多数生产数据库服务器，建议采用单个 SQL Server 实例带多个数据库的配置方法。

在一台生产服务器上配置一个 SQL Server 实例有以下优点：

  • 只需管理一个实例。

  • 没有重复的组件或处理开销，例如必须在同一台计算机上运行多个数据库引擎。这意味着只运行一个实例的服务器的总体性能可能比运行多个实例的服务器的总体性能高。

  • 单个的 SQL Server 2000 实例能够处理最大的 Web 站点和企业数据处理系统的处理增长需求，特别是在作为数据库服务器联合体的一部分时。有关更多信息，请参见联合 SQL Server 2000 数据库服务器。

在下列情况下最好在单台计算机上运行多个 SQL Server 实例：

  • 当必须支持需要彼此安全隔离的不同系统时，例如，某服务部门拥有一台大型服务器，且必须为每个客户创建独立的 SQL Server 实例。

  • 当需要支持多个测试和开发数据库时，最经济的配置方式是在一台大型服务器上让这些数据库作为不同的 SQL Server 实例运行。

  • 当需要在一台桌面上运行多个应用程序时，每个应用程序安装不同的 SQL Server 2000 Desktop Engine 实例。


处理多个实例

尽管多个 Microsoft® SQL Server™ 2000 实例可在单台计算机上运行，但实例间没有直接连接。每个实例以多种方式运行，就像位于单独的服务器上。连接某一实例的应用程序除了通过分布式查询外，不能访问其它实例中创建的数据库中的对象。实例之间不能共享数据库和数据库文件。

SQL Server 2000 数据库引擎的命名实例与默认实例的行为几乎相同。两者的主要差别是命名实例要求用户必须提供标识命名实例的计算机名和实例名。如果仅指定 computername，则使用默认实例。如果指定 computername\instancename，则使用命名实例。

  • 服务管理器。

    如果在服务管理器中仅指定 computername，则可停止和启动默认实例。如果指定 computername\instancename，则可停止和启动命名实例。当启动特定的实例时，对于任何使用具有访问数据库权限的授权 ID 连接实例的应用程序，都可使用在该实例中创建的所有数据库。

  • SQL Server 企业管理器。

    通过 SQL Server 企业管理器，用户可以注册自己拥有权限的任何一个实例。在注册实例后，可根据授予的权限，创建、编辑和除去数据库中与实例相关联的对象。还可为该实例创建、编辑和除去数据转换服务、复制和 SQL Server 代理对象。

  • 应用程序。

    在一个应用程序中，如果在连接请求中指定 computername 作为服务器名参数，则连接计算机上的默认实例。用户可访问自己拥有访问权限的默认实例中的任何数据库。如果指定 computername\instancename 作为服务器名称参数，则连接命名实例。用户可访问自己拥有访问权限的命名实例中的任何数据库。当连接特定的实例时，只能通过分布式查询访问其它实例中的数据库对象，正如只能通过分布式查询访问其它服务器中的数据库对象一样。应用程序指定实例名的方式各不相同：

    • ADO 应用程序在提供程序字符串中指定 "Server=computername\instancename"。有关更多信息，请参见连接多个 SQL Server 实例。

    • OLE DB 应用程序在提供程序字符串中指定 "Server=computername\instancename"。也可将 DBPROP_INIT_DATASOURCE 设置为 computername\\instancename（反斜杠必须通过另一个反斜杠转义）。有关更多信息，请参见建立与数据源的连接。

    • ODBC 应用程序在 SQLDriverConnect 上指定的连接字符串中指定 "Server=computername\instancename"。也可为 SQLConnect 上的参数 ServerName 指定 computername\\instancename，或通过已为服务器名称指定 computername\instancename 的数据源进行连接。有关更多信息，请参见 SQLDriverConnect 和 SQLConfigDataSource 支持。

    • SQL DMO 应用程序可使用 SQLServer2 对象管理 SQL Server 2000 实例。有关更多信息，请参见 SQLServer2 对象。

    • DB-Library 和用于 C 语言的嵌入式 SQL 不支持多个实例。
  • 分布式查询和链接服务器。

    分布式查询和链接服务器定义使用 computername\instancename 和 computername 分别标识命名实例和默认实例。有关更多信息，请参见多个 SQL Server 实例上的分布式查询。

  • 命令提示实用工具。

    使用命令提示实用工具时，可通过 computername\instancename 使用服务器开关指定实例，例如：

    osql -E -Scomputer1\instance1
sqlservr /Sinstance1

    isql 实用工具不支持命名实例。

  • SQL Server 2000 客户端组件。

    使用 SQL Server 2000 客户端组件的应用程序可枚举用于连接的实例：

    • 用于 SQL Server 2000 的 OLE DB 提供程序使用 ISourcesRowset::GetSourcesRowset 返回实例名。命名实例名作为格式为 computername\instancename 的数据源名返回，其中的 computername 可以是单台计算机的名称，也可以是故障转移群集的虚拟服务器名称。默认实例名作为格式为 computername 的数据源名返回，不带实例名。

    • SQL Server 2000 ODBC 驱动程序支持 SQLBrowseConnect 和 SQLSetConnectAttr 的扩展，这使应用程序得以枚举服务器上的实例。ODBC 应用程序还可确定 computername 是单个计算机名还是故障转移群集的虚拟服务器名。有关更多信息，请参见 SQLBrowseConnect。

    • SQL-DMO 应用程序可使用 SQLServer2 对象枚举实例。SQLServer2 对象还提供诸如 SQL Server 名和实例的 SQL Server 代理服务名，以及实例是在单个计算机上运行还是在故障转移群集上运行等方面的信息。有关更多信息，请参见 SQLServer2 对象。

    • DB-Library 和用于 C 语言的嵌入式 SQL 不支持命名实例。
标识实例

性能监视器计数器、事件探查器事件和事件查看器应用程序日志中的 Windows 事件都标识与它们相关联的 SQL Server 实例。

如果连接命名实例，则 @@SERVERNAME 函数返回的字符串以 servername\instancename 的格式标识实例名。如果连接默认实例，则 @@SERVERNAME 仅返回 servername。有关更多信息，请参见 @@SERVERNAME。

SERVERPROPERTY 函数的 INSTANCENAME 属性报告所连接实例的实例名。如果连接默认实例，则 INSTANCENAME 返回 NULL。另外，SERVERNAME 属性将返回与 @@SERVERNAME 返回的格式相同的字符串，并在连接命名实例时具有格式 servername\instancename。有关更多信息，请参见 SERVERPROPERTY。

尽管 @@SERVERNAME 和 SERVERNAME 报告的字符串采用相同的格式，但它们报告的信息可以不同，例如：

  • @@SERVERNAME 返回的字符串受 sp_addserver 和 sp_dropserver 操作的影响，而 SERVERNAME 报告的字符串则不受影响。

  • SERVERNAME 可自动报告计算机网络名中的更改，而 @@SERVERNAME 不报告这些更改，除非使用 sp_dropserver 和 sp_addserver 更改它报告的名称。


联合 SQL Server 2000 服务器

Microsoft® SQL Server™ 2000 数据库可分散在一组自主数据库服务器中，这组服务器能够支持通过 Microsoft Windows® DNA 建立的最大型 Web 站点和企业数据处理系统的处理增长需求。

Windows DNA 将数据处理系统的处理单元分为若干个逻辑层：

  • 用户服务层

    提供用户看得到的界面，通常调用第二层处理业务逻辑。

  • 业务服务层

    包含可控制 Web 站点运行的业务逻辑，使用第三层提供的持久数据存储。

  • 数据服务层

    存储运行 Web 站点所需的持久数据。

按比例缩放是指将资源添加到某一层，以使该层能够处理增大的工作负荷的过程。按比例缩放可以有两种实现方式：

  • 提高个体功能

    通过使用功能更强大的计算机提高服务器的处理能力。

  • 提高群体功能

    提高以模块化方式设计的系统的处理能力，例如在系统中添加一台或多台计算机（也称为节点），使之变为一个计算机群集。

大型 Web 站点的增长需求所产生的处理负荷远远超出了单独的大型服务器的能力。在这种情况下，提高群体功能可能是提高系统处理能力的最佳选择。

Microsoft Windows 2000 COM+ 组件被设计为可用于 Windows 2000 应用程序服务器群集，以形成群集的业务服务层。每一台服务器上都装有相同的 COM+ 组件集，Windows 2000 通过向处理负荷最小的服务器发送新的请求来平衡群集内的处理负荷。这样便形成了一个容易管理的群集，只需增加新的服务器即可快速提高群体功能。

SQL Server 2000 不支持这种类型的群集。然而，SQL Server 2000 确实支持可更新的分布式分区视图，而这些视图用于在一组服务器间透明地对数据进行水平分区。尽管这些服务器可合作管理分区数据，但它们通常自主运行。每一台服务器分开管理，有单独的操作规则并可支持独立的进程和数据。一组协作处理工作负荷的自主服务器称为联合体。尽管当服务器上的处理器增加到 8 个或更多时，SQL Server 2000 提供的性能已相当好了，但它仍支持在联合体间分散巨大的处理负荷。运行 SQL Server 2000 的服务器联合体能够支持任何 Web 站点或超大型企业系统的增长需求。


对数据分区

建立一个联合数据库服务器组的第一步是在多台服务器间水平分区表数据。水平分区表是指将表分成多个较小的表（称为成员表）。每一个成员表与原始表有相同的格式，但仅包含原始表中的部分行。将每一个表放在不同的资源（文件或服务器）上，以使处理负荷分散到多个资源上。例如，某公司从 1 至 9999999 分配客户标识符 (ID)。可将 Customers 表分为 3 个成员表，每个成员表的客户 ID 范围都相同。

如果在使用水平分区时不使用视图，则水平分区将要求应用程序具有确定哪些成员表包含用户请求数据的逻辑，并动态地生成引用这些表的 SQL 语句。应用程序需要使用复杂的查询联接这些成员表。更改成员表还涉及重新编写应用程序代码。为解决这一问题，视图使成员表看起来像一个表。SQL UNION 运算符将具有相同格式的结果集合并为一个。因为所有成员表都具有相同的格式，所以对每个表执行 SELECT * 语句所得到的结果也具有相同的格式，并且可使用 UNION 子句合并这些结果，以形成与原始表的操作相类似的单个结果集。例如，将 Customers 表分散在三台服务器（Server1、Server2 和 Server3）上。在 Server1 上定义的分布式分区视图为：

CREATE VIEW Customers
AS
SELECT * FROM Customers_33
   UNION ALL
SELECT * FROM Server2.CustomerDB.dbo.Customers_66
   UNION ALL
SELECT * FROM Server3.CustomerDB.dbo.Customers_99

此视图使数据的实际位置对应用程序是透明的。当在引用 Customers 分区视图的 Server1 上执行 SQL 语句时，应用程序看不到数据的位置。如果需要一些行来完成驻留在 Server2 或 Server3 上的 SQL 语句，Server1 上的 SQL Server 实例将自动生成一个分布式查询，从其它服务器中取得所需的行。这种透明性使数据库管理员得以重新分区表，而无须对应用程序重新编码。如果 Customers 视图可更新，则视图的行为与名为 Customers 的表的行为相同。

本地分区视图引用一台服务器上的成员表。分布式分区视图则引用多台服务器上的成员表。包含成员表的服务器称为成员服务器，而包含成员表的数据库称为成员数据库。每一个成员服务器包含一个成员表和一个分布式分区视图。引用任一服务器上的分区视图的应用程序得到的结果相同，就好象每台服务器上存在原始表的完整复本。

Microsoft SQL Server 2000 和 Microsoft SQL Server 7.0 版都支持分区视图。不过，SQL Server 2000 引入了关键的功能，使视图得以提高群体功能以形成数据库服务器联合体：

  • SQL Server 2000 分区视图可以更新。这对于分发数据十分关键，因为这使数据的位置对应用程序是透明的。可更新的视图支持原始表的全部行为，而不可更新的视图类似于只读复本。

  • SQL Server 2000 查询优化器支持新的优化功能，可使必须传输的分布式数据量减到最少。对于更大的查询集，SQL Server 2000 生成的分布式执行计划比 SQL Server 7.0 版生成的同类计划产生更好的性能。

SQL Server 2000 分区视图最适合 Web 站点和联机事务处理 (OLTP) 系统生成的 SQL 语句类型。

分区数据库

若要建立一个有效的数据库服务器联合体，必须：

  • 创建多个数据库，每一个数据库分别位于运行 SQL Server 2000 实例的不同的成员服务器上。

  • 在原始数据库中对个别表进行分区，使大部分相关数据位于一台成员服务器上。这可能需要不同的方法在各成员数据库上的各种表中分发数据，对一些表进行分区，制作每个成员数据库中其它表的完整复本，并保留一些表在原始服务器上的完整性。

  • 设计可纳入业务服务层的数据路由规则，以便应用程序将每条 SQL 语句发送到存储该语句所需的大部分数据的成员服务器。

在此类系统中，最重要的目标是最大程度地减少分布式处理。用户必须能够在同一台成员服务器上配置相关的数据，然后将每个 SQL 语句路由到包含处理语句所需的大部分数据（若不是全部）的成员服务器。例如，用户可能发现数据库中的所有销售额、客户、销售人员和库存清单都可以按照销售区域进行分区，并且大多数 SQL 语句仅引用单个区域中的数据。用户于是可创建多台成员服务器，其中每台服务器都包含一个或多个区域的水平分区数据。如果应用程序能够识别当前正由用户输入引用的区域，则应用程序可将生成的任何 SQL 语句提交到包含该区域数据的成员服务器。唯一生成分布式查询的 SQL 语句是那些引用多个区域数据的语句。


故障转移群集构架

Microsoft® SQL Server™ 2000 故障转移群集允许系统自动故障服务器中的 SQL Server 实例处理转换到工作服务器，从而提高了服务器的可用性。例如，SQL Server 实例可以快速地将数据库服务还原到 Web 站点或企业网络，即使运行该实例的服务器发生故障。SQL Server 2000 基于 Windows NT® 4.0 和 Windows® 2000 中的 Microsoft 群集服务 (MSCS) 的故障转移群集功能实现故障转移群集。

SQL Server 2000 使用的 MSCS 故障转移群集类型由多台服务器计算机组成（在 Windows NT 4.0 上为两个，在 Windows 2000 Datacenter Server 上最多可以为四个），它们共享一套公用群集资源，如磁盘驱动器。群集中的每台服务器都称为一个节点。每台服务器（或节点）与网络连接，并且各节点间可以相互通讯。每一节点都运行同一版本的 MSCS。

在故障转移群集中，共享资源被收集到群集组内。例如，如果故障转移群集有四个共享磁盘驱动器，其中的两个驱动器可以收集到一个群集组内，而另两个驱动器可以收集到另一个群集组内。每一群集组都由故障转移群集中的某个节点拥有，不过这种所有权可以在节点间转让。

应用程序可以安装在故障转移群集中的节点上。这些应用程序通常是服务器应用程序或用户通过网络连接访问的分布式 COM 对象。应用程序的可执行文件和其它资源通常存储在节点所拥有的一个或多个群集组内。每一节点都可以在其上安装多个应用程序。

故障转移群集节点定期相互发送称为心跳信号消息的网络消息。如果 MSCS 软件检测到群集中某个节点丢失了心跳信号，则将该服务器视为故障服务器。MSCS 然后自动将该节点的群集组和应用程序资源转移给网络中的其它节点。当任何特定的节点发生故障时，群集管理员指定将群集组转移到的替换节点。于是，其它节点继续处理对故障服务器转移来的应用程序的用户网络请求。

有关 MSCS 的更多信息，请参见 Windows NT Server、Windows 2000 Server、Windows 2000 Advanced Server 或Windows 2000 Datacenter 文档。


SQL Server 2000 故障转移群集

在一个 Microsoft 群集服务 (MSCS) 故障转移群集中，可以安装最多 16个 Microsoft® SQL Server™ 2000 实例。

通过运行群集中某个节点上的 SQL Server 安装程序安装 SQL Server 2000 实例。安装程序将实例安装在安装过程中指定的故障转移群集中的节点上。SQL Server 2000 可执行文件安装在故障转移群集中每一节点的本地磁盘驱动器上。这意味着每一节点都必须有本地硬盘，分配给该硬盘的驱动器号应与所有其它节点上的相同，而且该驱动器号必须在安装过程中为 SQL Server 可执行文件指定的位置路径中。例如，如果指定 C:\Program Files\Microsoft SQL Server 作为安装 SQL Server 可执行文件的位置，则群集中每一节点都必须使驱动器号 C 映射到本地驱动器。实例的注册表信息也存储在故障转移群集中每一节点的注册表中。

MSCS 群集组是共享资源（如某个故障转移群集节点所拥有的共享磁盘驱动器）的集合。该组的所有权可以在节点间转让，但每个组一次只能由一个节点拥有。SQL Server 2000 实例的数据库文件放置在单个 MSCS 群集组中，该群集组由安装此实例的节点拥有。如果运行某个 SQL Server 实例的节点发生故障，则 MSCS 将包含该实例数据文件的群集组切换至另一个节点。因为新节点的本地磁盘驱动器上已经有该 SQL Server 实例的可执行文件和注册表信息，所以它可以启动该 SQL Server 实例并开始接受连接该实例的请求。

因为 SQL Server 2000 实例的可执行文件和注册表信息存储在每一节点中，所以 SQL Server 2000 对每台计算机只能有 16 个实例的限制也适用于每个故障转移群集。故障转移群集中的每一实例要么必须有唯一的实例名，要么必须是默认实例。在每个故障转移群集中只能有一个默认实例。

保存实例数据库文件的 MSCS 群集组在 SQL Server 安装过程中与一个 SQL Server 虚拟服务器名称相关联。每台虚拟服务器只能有一个实例，这也意味着只能有一个实例与任一群集组相关联。

当应用程序尝试连接一个运行在故障转移群集上的 SQL Server 实例时，应用程序必须指定虚拟服务器名称和实例名。只有当与虚拟服务器关联的实例是没有名称的默认实例时，应用程序才不必指定实例名。

例如：

  • Windows 群集管理员创建了一个故障转移群集，该群集有两个节点：NodeA 和 NodeB。每一节点都将驱动器号 C 映射到本地硬盘上。

  • 在该群集中有一个共享磁盘。群集管理员创建 ClusterGroupA 来控制该驱动器，并把它指派给 NodeA。

  • SQL Server 系统管理员运行安装程序在 NodeA 上安装 SQL Server 默认实例。在安装过程中，管理员指定 SQL Server 虚拟服务器名称为 VirtualServerX，并指定将数据库文件放置在 ClusterGroupA 中的驱动器上。安装程序在本地驱动器 NodeA 和 NodeB 上安装 SQL Server 可执行文件，并将数据库文件放置在 ClusterGroupA 中。

  • 尝试连接默认实例的应用程序只需指定虚拟服务器名称 VirtualServerA。默认实例通常运行在 NodeA 上。然而，如果 NodeA 发生故障，则 MSCS 群集将 ClusterGroupA 的所有权转让给 NodeB，并重新启动 NodeB 上的默认实例。应用程序仍将通过指定虚拟服务器名称 VirtualServerX 连接默认实例。

请参见

故障转移群集

安装虚拟服务器配置


SQL Server 和 XML 支持

可扩展标记语言 (XML) 是用于描述数据集内容以及应如何将数据输出到设备上或如何在 Web 页上显示数据的语言。标记语言的创建来源于出版商指示印刷商如何组织报纸、杂志或书籍内容的方法。电子数据的标记语言对所有可显示在不同类型的电子装置上的电子文档执行相同的功能。

XML 和超文本标记语言 (HTML) 都来源于标准通用标记语言 (SGML)。SGML 是一种复杂的大型语言，难以完全用于在 Web 上发布数据。HTML 是比 SGML 简单的专用标记语言，但在处理 Web 上的数据时有许多限制。XML 比 SGML 小且比 HTML 可靠，所以，在通过 Web 或公司内部网络交换电子数据的活动中，正日益成为一种重要的语言。

在如 Microsoft® SQL Server™ 2000 的关系数据库中，对数据库表的所有操作都会产生表形式的结果。SELECT 语句的结果集为表形式。传统的客户端/服务器应用程序通过从表格格式的结果集中一次提取一行或一个行块，并将列值映射到程序变量中来执行 SELECT 语句处理结果。另一方面，Web 应用程序程序员更熟悉使用 XML 或 HTML 中的数据层次化表示。

SQL Server 2000 引入了对 XML 的支持。这些新特性包括：

  • 能够通过 URL 访问 SQL Server。

  • 支持 XML-Data 架构并能在这些架构上指定 XPath 查询。

  • 能够检索并写入 XML 数据：
    • 使用 SELECT 语句和 FOR XML 子句检索 XML 数据。

    • 使用 OpenXML 行集提供程序写入 XML 数据。
  • 增强了 Microsoft SQL Server 2000 OLE DB 提供程序 (SQLOLEDB)，使得可以将 XML 文档设置为命令文本并以流的形式返回结果集。

请参见

XML 和 Internet 支持概述

使用 URL 访问 SQL Server

使用带批注的 XDR 架构创建 XML 视图

使用 XPath 查询

检索和编写 XML 数据


数据库构架

Microsoft® SQL Server™ 2000 数据存储在数据库中。在数据库中，数据被组织到用户可以看见的逻辑组件中。数据库还可以按物理方式，在磁盘上作为两个或更多的文件实现。

使用数据库时使用的主要是逻辑组件，例如表、视图、过程和用户。文件的物理实现在很大程度上是透明的。一般只有数据库管理员需要处理物理实现。

每个 SQL Server 实例有四个系统数据库（master、model、tempdb 和 msdb）以及一个或多个用户数据库。有些单位只使用一个用户数据库来存储其所有数据。有些单位则为本单位的每一个组都设立了不同的数据库，而且有时一个数据库只能由一个应用程序使用。例如，一个单位可以有销售数据库、工资单数据库、文档管理应用程序数据库等。应用程序有时只使用一个数据库，而有时则可以访问几个数据库。

不需要运行多个 SQL Server 数据库引擎的复本，即可使多个用户得以访问服务器上的数据库。SQL Server 标准版或企业版实例能够处理同时在多个数据库中工作的上千个用户。根据定义的安全权限，每个 SQL Server 实例可使所有连接到实例的用户都能使用该实例上的所有数据库。

当连接到 SQL Server 实例时，您的连接会与服务器上的具体某个数据库相关联。这个数据库就称为当前数据库。系统管理员通常会将您连接到默认数据库，但您可以使用数据库 API 内的连接选项来指定另一个数据库。可使用 Transact-SQL USE database_name 语句，或使用可更改当前数据库上下文的 API 函数，由一个数据库切换到另一个数据库。

SQL Server 2000 允许从 SQL Server 实例中分离数据库，然后将数据库重新附加到另一个实例，甚至可以将数据库附加回原来的实例。如果有 SQL Server 数据库文件，可以在连接时让 SQL Server 以特定的数据库名称附加该数据库文件。

请参见

数据库设计注意事项


数据库逻辑组件

Microsoft® SQL Server™ 2000 数据库中的数据被组织成几个不同的对象。这些对象就是当用户连接到数据库时所能看到的东西。

在 SQL Server 中，这些组件被定义为对象：

约束 | 表
默认值 | 触发器
索引 | 用户定义的数据类型
键 | 用户定义函数
存储过程 | 视图


数据类型和表结构

Microsoft® SQL Server™ 2000 数据库中的所有数据包含在称为表的对象中。每个表代表某类对用户有意义的对象。例如，可在一个学校数据库内找到班级表、教师表和学生表。

SQL Server 中的表有两个主要组件：

  • 列

    每列代表由表建模的对象的某种特性，例如，一个部件表有 ID 列、颜色列和重量列。

  • 行

    每行代表由表建模的对象的个别事件。例如，部件表中公司运送的每个部件均占一行。

数据类型

因为每一列都代表对象的一个特性，所以一列中每个事件的数据均相似。列属性中有一个称为列数据类型的属性，用于定义该列可以包含的数据类型。SQL Server 有多种可指定给列的基本数据类型：

binary | Bigint | bit | Char | datetime
decimal | Float | image | Int | Money
nchar | Ntext | nvarchar | Numeric | Real
smalldatetime | smallint | smallmoney | sql_variant | sysname
text | timestamp | tinyint | varbinary | varchar
uniqueidentifier |  |  |  |

SQL Server 2000 还支持 table 基本数据类型，该数据类型可用于存储 SQL 语句的结果集。table 数据类型不适用于表中的列，而只能用于 Transact-SQL 变量和用户定义函数的返回值。有关更多信息，请参见使用特殊数据。

用户也可以创建自己定义的数据类型，例如：

-- Create a birthday data type that allows nulls.
EXEC sp_addtype birthday, datetime, 'NULL'
GO
-- Create a table using the new data type.
CREATE TABLE employee
   (emp_id         char(5),
   emp_first_name   char(30),
   emp_last_name   char(40),
   emp_birthday      birthday)

用户定义的数据类型使表结构对程序员更有意义，并有助于确保包含相似数据类的列具有相同的基本数据类型。

SQL Server 提供了几种数据类型同义词，有助于支持未包括在基本数据类型中的 SQL-92 数据类型名称，如国家字符和字符变化。当在 CREATE TABLE 语句中指定某个同义词时，给列指派一种与此同义词关联的基本数据类型。有关更多信息，请参见数据类型同义词。

域是列中所有允许值的集合。它不仅包括强制数据类型的概念，也包括列中所允许的值。例如，一个部件颜色域既包括数据类型，例如 char(6)，也包括该列所允许的字符串，例如：Red、Blue、Green、Yellow、Brown、Black、White、Teal、Grey 和 Silver。可以通过 CHECK 约束和触发器等机制来强制执行域值。

如果指派了列的数据类型，列中的所有值都必须是所指派的数据类型。仅当 SQL Server 可将源值的数据类型隐性转换为列的数据类型时，SQL 语句才能将不同的数据类型值指定为源值。例如，SQL Server 支持将 int 值隐性转换为 decimal；因此 SQL 语句可将 int 值指定为指派给 decimal 列的值。

SQL Server 2000 sql_variant 数据类型是一种特殊的数据类型，使您得以在同一列中存储多种基本数据类型的值。例如，可在同一列中存储 nchar 值、int 值和 decimal 值。有关更多信息，请参见使用 sql_variant 数据。

空值

列可以接受或拒绝空值。在数据库内 NULL 是特殊值，代表未知值的概念。NULL 不同于空字符或 0。空字符实际上是有效字符，0 是有效数字。而 NULL 只是表示该值未知这一概念。NULL 也不同于零长度字符串。如果列定义中包含 NOT NULL 子句，则不能为该行插入含有 NULL 值的行。如果列定义中仅包含 NULL 关键字，则接受 NULL 值。

在列内允许 NULL 值会增加使用该列的逻辑比较的复杂性。SQL-92 标准规定：对 NULL 值的任何比较都不取值为 TRUE 或 FALSE，而是取值为 UNKNOWN。此规定在比较运算符中引入了三值逻辑，而要正确运用该逻辑很困难。

系统表

SQL Server 将定义服务器配置的数据以及它的所有表存储在称为系统表的特殊表集内。用户不应直接查询或更新系统表，除非没有其它方法获得应用程序所需的数据。只有 SQL Server 才应引用系统表来响应用户发出的管理命令。系统表可能因版本的不同而异。对于直接引用系统表的应用程序，可能必须先进行重写，然后才能升级到使用不同版本系统表的新 SQL Server 版本。SQL Server 通过其它方法表现系统表中的大部分信息。有关更多信息，请参见系统表。

临时表

SQL Server 支持临时表。临时表就是那些名称以井号 (#) 开头的表。如果当用户断开连接时没有除去临时表，SQL Server 将自动除去临时表。临时表不存储在当前数据库内，而是存储在系统数据库 tempdb 内。

临时表有两种类型：

  • 本地临时表

    以一个井号 (#) 开头的那些表名。只有在创建本地临时表的连接上才能看到这些表。

  • 全局临时表

    以两个井号 (##) 开头的那些表名。在所有连接上都能看到全局临时表。如果在创建全局临时表的连接断开前没有显式地除去这些表，那么只要所有其它任务停止引用它们，这些表即被除去。当创建全局临时表的连接断开后，新的任务不能再引用它们。当前的语句一执行完，任务与表之间的关联即被除去；因此通常情况下，只要创建全局临时表的连接断开，全局临时表即被除去。

现在，临时表的许多传统用途可由具有 table 数据类型的变量替换。

使用表

用户使用数据操作语言 (DML) SQL 语句来处理表中的数据：

-- Get a list of all employees named Smith:
SELECT emp_first_name, emp_last_name
FROM employee
WHERE emp_last_name = 'Smith'

-- Delete an employee who quit:
DELETE employee
WHERE emp_id = 'OP123'

-- Add a new employee:
INSERT INTO employee
VALUES ( 'OP456', 'Dean', 'Straight', '01/01/1960')

-- Change an employee name:
UPDATE employee
SET emp_last_name = 'Smith'
WHERE emp_id = 'OP456'

请参见

指定列数据类型

表


SQL 视图

视图可以被看成是虚拟表或存储查询。可通过视图访问的数据不作为独特的对象存储在数据库内。数据库内存储的是 SELECT 语句。SELECT 语句的结果集构成视图所返回的虚拟表。用户可以用引用表时所使用的方法，在 Transact-SQL 语句中通过引用视图名称来使用虚拟表。使用视图可以实现下列任一或所有功能：

  • 将用户限定在表中的特定行上。

    例如，只允许雇员看见工作跟踪表内记录其工作的行。

  • 将用户限定在特定列上。

    例如，对于那些不负责处理工资单的雇员，只允许他们看见雇员表中的姓名列、办公室列、工作电话列和部门列，而不能看见任何包含工资信息或个人信息的列。

  • 将多个表中的列联接起来，使它们看起来象一个表。

  • 聚合信息而非提供详细信息。

    例如，显示一个列的和，或列的最大值和最小值。

通过定义 SELECT 语句以检索将在视图中显示的数据来创建视图。SELECT 语句引用的数据表称为视图的基表。在下例中，pubs 数据库中的 titleview 是一个视图，该视图选择三个基表中的数据来显示包含常用数据的虚拟表：

CREATE VIEW titleview
AS
SELECT title, au_ord, au_lname, price, ytd_sales, pub_id
FROM authors AS a
     JOIN titleauthor AS ta ON (a.au_id = ta.au_id)
     JOIN titles AS t ON (t.title_id = ta.title_id)

之后，可以用引用表时所使用的方法在语句中引用 titleview。

SELECT *
FROM titleview

一个视图可以引用另一个视图。例如，titleview 显示的信息对管理人员很有用，但公司通常只在季度或年度财务报表中才公布本年度截止到现在的财政数字。可以建立一个视图，在其中包含除 au_ord 和 ytd_sales 外的所有 titleview 列。使用这个新视图，客户可以获得已上市的书籍列表而不会看到财务信息：

CREATE VIEW Cust_titleview
AS
SELECT title, au_lname, price, pub_id
FROM titleview

视图可用于在多个数据库或 Microsoft® SQL Server™ 2000 实例间对数据进行分区。分区视图可用于在整个服务器组内分布数据库处理。服务器组具有与服务器聚集相同的性能优点，并可用于支持最大的 Web 站点或公司数据中心的处理需求。原始表被细分为多个成员表，每个成员表包含原始表的行子集。每个成员表可放置在不同服务器的数据库中。每个服务器也可得到分区视图。分区视图使用 Transact-SQL UNION 运算符，将在所有成员表上选择的结果合并为单个结果集，该结果集的行为与整个原始表的复本完全一样。例如在三个服务器间进行表分区。在第一个服务器上定义如下的分区视图：

CREATE VIEW PartitionedView AS
SELECT *
    FROM MyDatabase.dbo.PartitionTable1
UNION ALL
SELECT *
    FROM Server2.MyDatabase.dbo.PartitionTable2
UNION ALL
SELECT *
    FROM Server3.MyDatabase.dbo.PartitionTable3

在其它两个服务器上定义类似的分区视图。利用这三个视图，三个服务器上任何引用 PartitionedView 的 Transact-SQL 语句都将看到与原始表中相同的行为。似乎每个服务器上都存在原始表的复本一样，而实际上每个表只有一个成员表和分区视图。有关更多信息，请参见视图使用方案。

只要所做的修改只影响视图所引用的其中一个基表，就可以更新所有 SQL Server 版本内的视图（可以对其执行 UPDATE、DELETE 或 INSERT 语句）。

-- Increase the prices for publisher '0736' by 10%.
UPDATE titleview
SET price = price * 1.10
WHERE pub_id = '0736'
GO

SQL Server 2000 支持可引用视图的更复杂的 INSERT、UPDATE 和 DELETE 语句。可在视图上定义 INSTEAD OF 触发器，指定必须对基表执行的个别更新以支持 INSERT、UPDATE 或 DELETE 语句。另外，分区视图还支持 INSERT、UDPATE 和 DELETE 语句修改视图所引用的多个成员表。

索引视图是 SQL Server 2000 具有的功能，可显著提高复杂视图类型的性能，这些视图类型通常在数据仓库或其它决策支持系统中出现。

视图的结果集通常不保存在数据库中，因此视图也称为虚拟表。视图的结果集动态包含在语句逻辑中并在运行时动态生成。有关更多信息，请参见视图解析。

复杂的查询（如决策支持系统中的查询）可引用基表中的大量行，并将大量信息聚积在相对较简洁的聚合中，如总和或平均值。SQL Server 2000 支持在执行此类复杂查询的视图上创建聚集索引。当执行 CREATE INDEX 语句时，视图 SELECT 的结果集将永久存储在数据库中。SQL 语句此后若引用该视图，响应时间将会显著缩短。对基本数据的修改将自动反映在视图中。

SQL Server 2000 CREATE VIEW 语句支持 SCHEMABINDING 选项，以防止视图所引用的表在视图未被调整的情况下发生改变。必须为任何创建索引的视图指定 SCHEMABINDING。

请参见

CREATE INDEX

CREATE TRIGGER

CREATE VIEW

设计索引视图

视图


SQL 存储过程

存储过程是一组编译在单个执行计划中的 Transact-SQL 语句。

Microsoft® SQL Server™ 2000 存储过程以四种方式返回数据：

  • 输出参数，既可以返回数据（整型值或字符值等），也可以返回游标变量（游标是可以逐行检索的结果集）。

  • 返回代码，始终是整型值。

  • SELECT 语句的结果集，这些语句包含在该存储过程内或该存储过程所调用的任何其它存储过程内。

  • 可从存储过程外引用的全局游标。

存储过程帮助在不同的应用程序之间实现一致的逻辑。在一个存储过程内，可以设计、编码和测试执行某个常用任务所需的 SQL 语句和逻辑。之后，每个需要执行该任务的应用程序只须执行此存储过程即可。将业务逻辑编入单个存储过程还提供了单个控制点，以确保业务规则正确执行。

存储过程还可以提高性能。许多任务以一系列 SQL 语句来执行。对前面 SQL 语句的结果所应用的条件逻辑决定后面执行的 SQL 语句。如果将这些 SQL 语句和条件逻辑写入一个存储过程，它们就成为服务器上一个执行计划的一部分。不必将结果返回给客户端以应用条件逻辑，所有工作都可以在服务器上完成。下例中的 IF 语句显示了在一个过程中嵌入条件逻辑，以防止给应用程序发送结果集：

IF (@QuantityOrdered < (SELECT QuantityOnHand
                  FROM Inventory
                  WHERE PartID = @PartOrdered) )
   BEGIN
   -- SQL statements to update tables and process order.
   END
ELSE
   BEGIN
   -- SELECT statement to retrieve the IDs of alternate items
   -- to suggest as replacements to the customer.
   END

应用程序不必传输存储过程中的所有 SQL 语句：它们只须传输包含过程名和参数值的 EXECUTE 或 CALL 语句。

存储过程还可以使用户不必知道数据库内的表的详细信息。如果一组存储过程支持用户需要执行的所有业务功能，则用户永远不必直接访问表，他们可以只执行特定的存储过程，这些过程为他们所熟悉的业务进程建立了模型。

存储过程的这个用途的一个例证是 SQL Server 系统存储过程，它将用户从系统表中隔离出来。SQL Server 中包含一组系统存储过程，这些过程的名称通常以 sp_ 开头。这些系统存储过程支持运行 SQL Server 系统所需的所有管理任务。可以使用 Transact-SQL 中与管理相关的语句（如 CREATE TABLE）或系统存储过程来管理 SQL Server 系统，永远不必直接更新系统表。

存储过程和执行计划

在 SQL Server 6.5 版及更早的版本中，存储过程是对执行计划进行部分预编译的方法。在创建存储过程的同时，系统表内也存储了一个部分编译好的执行计划。执行存储过程比执行 SQL 语句更有效，因为 SQL Server 不必从头到尾编译执行计划，而只须优化该过程所存储的计划。同时，在 SQL Server 过程高速缓存中保留了完全编译好的存储过程执行计划，这意味着后面执行的存储过程可以使用预先编译好的执行计划。

SQL Server 2000 和 SQL Server 7.0 版在语句处理上做了许多修改，将存储过程的许多性能优点扩展到所有 SQL 语句。SQL Server 2000 和 SQL Server 7.0 在创建存储过程时不保存部分编译的计划。与任何其它的 Transact-SQL 语句一样，存储过程也在执行时进行编译。SQL Server 2000 和 SQL Server 7.0 在过程高速缓存内保留所有 SQL 语句的执行计划，而不只是存储过程的执行计划。数据库引擎使用一种高效的算法，将新的 Transact-SQL 语句与现有执行计划的 Transact-SQL 语句进行比较。如果数据库引擎确定新的 Transact-SQL 语句与现有执行计划的 Transact-SQL 语句相匹配，就重新使用这个计划。这样就将执行计划的重复使用性扩展到了所有 SQL 语句，从而减少了预编译存储过程的相对性能优势。

SQL Server 2000 和 SQL Server 7.0 版提供了新的处理 SQL 语句的可选方法。有关更多信息，请参见查询处理器构架。

临时存储过程

SQL Server 2000 还支持临时存储过程，这些过程与临时表一样，在连接断开时自动被除去。临时存储过程存储在 tempdb 内，它们在连接到 SQL Server 以前的版本时很有用。如果应用程序生成需要多次执行的动态 Transact-SQL 语句，就可以使用临时存储过程。无须每次重新编译 Transact-SQL 语句，而可以创建临时存储过程，在第一次执行时编译该过程，然后多次执行预先编译好的计划。不过，大量使用临时存储过程会导致在 tempdb 内争夺系统表。

SQL Server 2000 和 SQL Server 7.0 的两个功能消除了使用临时存储过程的需要：

  • 可重新使用前面 SQL 语句的执行计划。该功能与新的系统存储过程 sp_executesql 结合使用时尤为强大。

  • 本来就支持用于 OLE DB 和 ODBC 的准备/执行模型，无须使用任何存储过程。

有关临时存储过程的其它用法的更多信息，请参见执行计划的高速缓存和重新使用。

存储过程示例

下面简单的存储过程示例说明存储过程返回数据的三个方法：

  1. 首先发出 SELECT 语句，要求返回汇总了 sales 表中销售点 (store) 订购活动的结果集。

  2. 然后发出 SELECT 语句填写输出参数。

  3. 最后通过带 SELECT 语句的 RETURN 语句返回整数。返回代码通常是用来传回错误检查信息的。此过程的执行没有错误，因此返回了另一个值说明所返回代码的填写方式。
USE Northwind
GO
DROP PROCEDURE OrderSummary
GO
CREATE PROCEDURE OrderSummary @MaxQuantity INT OUTPUT AS
-- SELECT to return a result set summarizing
-- employee sales.
SELECT Ord.EmployeeID, SummSales = SUM(OrDet.UnitPrice * OrDet.Quantity)
FROM Orders AS Ord
     JOIN [Order Details] AS OrDet ON (Ord.OrderID = OrDet.OrderID)
GROUP BY Ord.EmployeeID
ORDER BY Ord.EmployeeID

-- SELECT to fill the output parameter with the
-- maximum quantity from Order Details.
SELECT @MaxQuantity = MAX(Quantity) FROM [Order Details]

-- Return the number of all items ordered.
RETURN (SELECT SUM(Quantity) FROM [Order Details])
GO

-- Test the stored procedure.

-- DECLARE variables to hold the return code
-- and output parameter.
DECLARE @OrderSum INT
DECLARE @LargestOrder INT

-- Execute the procedure, which returns
-- the result set from the first SELECT.
EXEC @OrderSum = OrderSummary @MaxQuantity = @LargestOrder OUTPUT

-- Use the return code and output parameter.
PRINT 'The size of the largest single order was: ' +
                 CONVERT(CHAR(6), @LargestOrder)
PRINT 'The sum of the quantities ordered was: ' +
                 CONVERT(CHAR(6), @OrderSum)
GO

下例执行后的输出结果是：

EmployeeID  SummSales
----------- --------------------------
1           202,143.71
2           177,749.26
3           213,051.30
4           250,187.45
5           75,567.75
6           78,198.10
7           141,295.99
8           133,301.03
9           82,964.00
The size of the largest single order was: 130
The sum of the quantities ordered was: 51317

请参见

存储过程


SQL 用户定义函数

编程语言中的函数是用于封装经常执行的逻辑的子例程。任何代码若必须执行函数所包含的逻辑，都可以调用该函数，而不必重复所有的函数逻辑。

Microsoft® SQL Server™ 2000 支持两种函数类型：

  • 内置函数

    按 Transact-SQL 参考中定义的方式运行且不能修改。只有使用 Transact-SQL 参考中所定义语法的 Transact-SQL 语句才能引用这类函数。有关这些内置函数的更多信息，请参见使用函数。

  • 用户定义函数

    使您得以用 CREATE FUNCTION 语句定义自己的 Transact-SQL 函数。有关这些内置函数的更多信息，请参见用户定义函数。

用户定义函数接受零个或更多的输入参数，并返回单值。一些用户定义函数返回单个的标量数据值，如 int、char 或 decimal 值。

例如，下面的语句创建一个返回 decimal 的简单函数：

CREATE FUNCTION CubicVolume
-- Input dimensions in centimeters.
   (@CubeLength decimal(4,1), @CubeWidth decimal(4,1),
    @CubeHeight decimal(4,1) )
RETURNS decimal(12,3) -- Cubic Centimeters.
AS
BEGIN
   RETURN ( @CubeLength * @CubeWidth * @CubeHeight )
END

然后可以在允许整型表达式的任何地方（如表的计算列中）使用该函数：

CREATE TABLE Bricks
   (
    BrickPartNmbr   int PRIMARY KEY,
    BrickColor      nchar(20),
    BrickHeight     decimal(4,1),
    BrickLength     decimal(4,1),
    BrickWidth      decimal(4,1),
    BrickVolume AS
              (
               dbo.CubicVolume(BrickHeight,
                         BrickLength, BrickWidth)
              )
   )

SQL Server 2000 还支持返回 table 数据类型的用户定义函数：

  • 该函数可声明内部 table 变量，将行插入该变量，然后将该变量作为返回值返回。

  • 一类称为内嵌函数的用户定义函数，将 SELECT 语句的结果集作为变量类型 table 返回。

这些函数可用在能指定表表达式的地方。有关 table 数据类型的更多信息，请参见使用特殊数据。

返回 table 的用户定义函数可以是替代视图的强大方式。返回 table 的用户定义函数可用在 Transact-SQL 查询中允许表或视图表达式的地方。视图受限于单个 SELECT 语句，而用户定义函数可包含附加的语句，使函数所包含的逻辑比视图可能具有的逻辑更强大。

返回 table 的用户定义函数还可替换返回单个结果集的存储过程。由用户定义函数返回的 table 可在 Transact-SQL 语句的 FROM 子句中引用，而返回结果集的存储过程则不能。例如，fn_EmployeesInDept 是返回 table 的用户定义函数，可由 SELECT 语句唤醒调用：

SELECT *
FROM tb_Employees AS E,
     dbo.fn_EmployeesInDept('shipping') AS EID
WHERE E.EmployeeID = EID.EmployeeID

下面的语句在 Northwind 数据库中创建将要返回 table 的函数：

CREATE FUNCTION LargeOrderShippers ( @FreightParm money )
RETURNS @OrderShipperTab TABLE
   (
    ShipperID     int,
    ShipperName   nvarchar(80),
    OrderID       int,
    ShippedDate   datetime,
    Freight       money
   )
AS
BEGIN
   INSERT @OrderShipperTab
        SELECT S.ShipperID, S.CompanyName,
               O.OrderID, O.ShippedDate, O.Freight
        FROM Shippers AS S
             INNER JOIN Orders AS O ON (S.ShipperID = O.ShipVia)
        WHERE O.Freight > @FreightParm
   RETURN
END

在这个函数中，返回的本地变量名是 @OrderShipperTab。函数中的语句在 @OrderShipperTab 变量中插入行，以生成由该函数返回的 table 结果。外部语句唤醒调用该函数以引用由该函数返回的 table：

SELECT *
FROM LargeOrderShippers( $500 )


约束、规则、默认值和触发器

除数据类型和大小外，表中的列还具有其它属性。这些属性在确保数据库中的数据完整性方面有重要作用：

  • 数据完整性是指列中每个事件都有正确的数据值。

    数据值必须是正确的数据类型，并且位于正确的域内。

  • 引用完整性表示得到正常维护的表之间的关系。

    表中的数据只应指向另一个表中的现有行，不应指向不存在的行。

用于维护这两种完整性的对象包括：

  • 约束

  • 规则

  • 默认值

  • 触发器


约束

约束使您得以定义 Microsoft® SQL Server™ 2000 自动强制数据库完整性的方式。约束定义关于列中允许值的规则，是强制完整性的标准机制。使用约束优先于使用触发器、规则和默认值。查询优化器也使用约束定义生成高性能的查询执行计划。

约束类

SQL Server 2000 支持五类约束。

  • NOT NULL 指定不接受 NULL 值的列。

  • CHECK 约束对可以放入列中的值进行限制，以强制执行域的完整性。

    CHECK 约束指定应用于列中输入的所有值的布尔（取值为 TRUE 或 FALSE）搜索条件，拒绝所有不取值为 TRUE 的值。可以为每列指定多个 CHECK 约束。下例显示名为 chk_id 约束的创建，该约束确保只对此关键字输入指定范围内的数字，以进一步强制执行主键的域。

    CREATE TABLE cust_sample
    (
    cust_id                int        PRIMARY KEY,
    cust_name            char(50),
    cust_address            char(50),
    cust_credit_limit    money,
    CONSTRAINT chk_id CHECK (cust_id BETWEEN 0 and 10000 )
    )
  • UNIQUE 约束在列集内强制执行值的唯一性。

    对于 UNIQUE 约束中的列，表中不允许有两行包含相同的非空值。主键也强制执行唯一性，但主键不允许空值。UNIQUE 约束优先于唯一索引。

  • PRIMARY KEY 约束标识列或列集，这些列或列集的值唯一标识表中的行。

    在一个表中，不能有两行包含相同的主键值。不能在主键内的任何列中输入 NULL 值。在数据库中 NULL 是特殊值，代表不同于空白和 0 值的未知值。建议使用一个小的整数列作为主键。每个表都应有一个主键。

    一个表中可以有一个以上的列组合，这些组合能唯一标识表中的行，每个组合就是一个候选键。数据库管理员从候选键中选择一个作为主键。例如，在 part_sample 表中，part_nmbr 和 part_name 都可以是候选键，但是只将 part_nmbr 选作主键。

    CREATE TABLE part_sample
            (part_nmbr        int            PRIMARY KEY,
            part_name        char(30),
            part_weight        decimal(6,2),
            part_color        char(15) )
  • FOREIGN KEY 约束标识表之间的关系。

    一个表的外键指向另一个表的候选键。当外键值没有候选键时，外键可防止操作保留带外键值的行。在下例中，order_part 表建立一个外键引用前面定义的 part_sample 表。通常情况下，order_part 在 order 表上也有一个外键，下面只不过是一个简单示例。

    CREATE TABLE order_part
        (order_nmbr        int,
        part_nmbr        int
            FOREIGN KEY REFERENCES part_sample(part_nmbr)
                ON DELETE NO ACTION,
        qty_ordered        int)
GO

    如果一个外键值没有候选键，则不能插入带该值（NULL 除外）的行。如果尝试删除现有外键指向的行，ON DELETE 子句将控制所采取的操作。ON DELETE 子句有两个选项：

    • NO ACTION 指定删除因错误而失败。

    • CASCADE 指定还将删除包含指向已删除行的外键的所有行。

    如果尝试更新现有外键指向的候选键值，ON UPDATE 子句将定义所采取的操作。它也支持 NO ACTION 和 CASCADE 选项。

列约束和表约束

约束可以是列约束或表约束：

  • 列约束被指定为列定义的一部分，并且仅适用于那个列（前面的示例中的约束就是列约束）。

  • 表约束的声明与列的定义无关，可以适用于表中一个以上的列。

当一个约束中必须包含一个以上的列时，必须使用表约束。

例如，如果一个表的主键内有两个或两个以上的列，则必须使用表约束将这两列加入主键内。假设有一个表记录工厂内的一台计算机上所发生的事件。假定有几类事件可以同时发生，但不能有两个同时发生的事件属于同一类型。这一点可以通过将 type 列和 time 列加入双列主键内来强制执行。

CREATE TABLE factory_process
   (event_type   int,
   event_time   datetime,
   event_site   char(50),
   event_desc   char(1024),
CONSTRAINT event_key PRIMARY KEY (event_type, event_time) )

请参见

CREATE TABLE

创建和修改表


规则

规则是一个向后兼容的功能，用于执行一些与 CHECK 约束相同的功能。CHECK 约束是用来限制列值的首选标准方法。CHECK 约束比规则更简明，一个列只能应用一个规则，但是却可以应用多个 CHECK 约束。CHECK 约束作为 CREATE TABLE 语句的一部分进行指定，而规则以单独的对象创建，然后绑定到列上。

下例创建一个规则，执行与前面主题中的 CHECK 约束示例相同的功能。Microsoft® SQL Server™ 2000 首选的方法是 CHECK 约束。

CREATE RULE id_chk AS @id BETWEEN 0 and 10000
GO
CREATE TABLE cust_sample
   (
   cust_id            int
   PRIMARY KEY,
   cust_name         char(50),
   cust_address         char(50),
   cust_credit_limit   money,
   )
GO
sp_bindrule id_chk, 'cust_sample.cust_id'
GO

请参见

CREATE TABLE

创建和修改表


默认值

如果在插入行时没有指定列的值，那么默认值指定列中所使用的值。默认值可以是任何取值为常量的对象，例如：

  • 持续

  • 内置函数

  • 数学表达式

有两种使用默认值的方法：

  • 在 CREATE TABLE 中使用 DEFAULT 关键字创建默认定义，将常量表达式指派为列的默认值。

    这是首选的标准方法，也是定义默认值的更简明的方法。

  • 使用 CREATE DEFAULT 语句创建默认对象，然后使用 sp_bindefault 系统存储过程将它绑定到列上。

    这是一个向前兼容的功能。

下例使用其中一种默认值类型创建表。它创建默认对象给一列指派默认值，并将默认对象绑定到该列上。然后在没有为该列指定值的情况下使用默认值做插入测试，并检索测试行以验证所应用的默认值。

USE pubs
GO
CREATE TABLE test_defaults
   (keycol      smallint,
   process_id   smallint DEFAULT @@SPID,   --Preferred default definition
   date_ins   datetime DEFAULT getdate(),   --Preferred default definition
   mathcol      smallint DEFAULT 10 * 2,   --Preferred default definition
   char1      char(3),
   char2      char(3) DEFAULT 'xyz') --Preferred default definition
GO
/* Illustration only, use DEFAULT definitions instead.*/
CREATE DEFAULT abc_const AS 'abc'
GO
sp_bindefault abc_const, 'test_defaults.char1'
GO
INSERT INTO test_defaults(keycol) VALUES (1)
GO
SELECT * FROM test_defaults
GO

下例的输出是：

Default bound to column.

(1 row(s) affected)

keycol process_id date_ins                    mathcol char1 char2
------ ---------- --------------------------- ------- ----- -----
1      7          Oct 16 1997  8:34PM         20      abc   xyz

(1 row(s) affected)

请参见

CREATE TABLE

创建和修改表


触发器

Microsoft® SQL Server™ 2000 触发器是一类特殊的存储过程，被定义为在对表或视图发出 UPDATE、INSERT 或 DELETE 语句时自动执行。触发器是功能强大的工具，使每个站点可以在有数据修改时自动强制执行其业务规则。触发器可以扩展 SQL Server 约束、默认值和规则的完整性检查逻辑，但只要约束和默认值提供了全部所需的功能，就应使用约束和默认值。

表可以有多个触发器。CREATE TRIGGER 语句可以与 FOR UPDATE、FOR INSERT 或 FOR DELETE 子句一起使用，指定触发器专门用于特定类型的数据修改操作。当指定 FOR UPDATE 时，可以使用 IF UPDATE (column_name) 子句，指定触发器专门用于具体某列的更新。

触发器可使公司的处理任务自动进行。在库存系统内，更新触发器可以检测什么时侯库存下降到了需要再进货的量，并自动生成给供货商的定单。在记录工厂加工过程的数据库内，当某个加工过程超过所定义的安全限制时，触发器会给操作员发电子邮件或寻呼。

无论何时只要有新的标题添加到 pubs 数据库中，下面的触发器就会生成电子邮件：

CREATE TRIGGER reminder
ON titles
FOR INSERT
AS
   EXEC master..xp_sendmail 'MaryM',
      'New title, mention in the next report to distributors.'

触发器包含 Transact-SQL 语句，这与存储过程十分相似。与存储过程一样，触发器也返回由触发器内的 SELECT 语句生成的结果集。不建议在触发器中包含 SELECT 语句，但仅填充参数的语句除外。这是因为用户不期望看到由 UPDATE、INSERT 或 DELETE 语句返回的结果集。

可使用 FOR 子句指定触发器的执行时间：

  • AFTER

    触发器在触发它们的语句完成后执行。如果该语句因错误（如违反约束或语法错误）而失败，触发器将不会执行。不能为视图指定 AFTER 触发器，只能为表指定该触发器。可以为每个触发操作（INSERT、UPDATE 或 DELETE）指定多个 AFTER 触发器。如果表有多个 AFTER 触发器，可使用 sp_settriggerorder 定义哪个 AFTER 触发器最先激发，哪个最后激发。除第一个和最后一个触发器外，所有其它的 AFTER 触发器的激发顺序不确定，并且无法控制。

    在 SQL Server 2000 中 AFTER 是默认触发器。不能在 SQL Server 7.0 版或更早的版本中指定 AFTER 或 INSTEAD OF，这些版本中的所有触发器都作为 AFTER 触发器运行。

  • INSTEAD OF

    该触发器代替触发操作执行。可在表和视图上指定 INSTEAD OF 触发器。只能为每个触发操作（INSERT、UPDATE 和 DELETE）定义一个 INSTEAD OF 触发器。INSTEAD OF 触发器可用于对 INSERT 和 UPDATE 语句中提供的数据值执行增强的完整性检查。INSTEAD OF 触发器还允许指定某些操作，使一般不支持更新的视图可以被更新。

请参见

用触发器强制执行业务规则


排序规则

在 Microsoft® SQL Server™ 2000 中，字符串的物理存储由排序规则控制。排序规则指定表示每个字符的位模式以及存储和比较字符所使用的规则。

SQL Server 2000 支持在一个数据库中存储具有不同排序规则的对象。可为一直到列级的各级别指定不同的 SQL Server 2000 排序规则。可为表中的每列指派不同的排序规则。SQL Server 的早期版本仅支持每个 SQL Server 实例有一个排序规则。在 SQL Server 7.0 或更早的版本实例中创建的所有数据库和数据库对象具有相同的排序规则。

字符数据的存储方式

在计算机中，字符由不同的位模式（ON 或 OFF）表示。每个字节有 8 位，这 8 位可以有 256 种不同的 ON 和 OFF 组合模式。对于使用 1 个字节存储每个字符的程序，通过给每个位模式指派字符可表示最多 256 个不同的字符。2 个字节有 16 位，这 16 位可以有 65,536 种唯一的 ON 和 OFF 组合模式。使用 2 个字节表示每个字符的程序可表示最多 65,536 个字符。

单字节代码页是字符定义，这些字符映射到每个字节可能有的 256 种位模式中的每一种。代码页定义大小写字符、数字、符号以及 !、@、#、% 等特殊字符的位模式。每种欧洲语言（如德语和西班牙语）都有各自的单字节代码页。虽然用于表示 A 到 Z 拉丁字母表字符的位模式在所有的代码页中都相同，但用于表示重音字符（如"é"和"á"）的位模式在不同的代码页中却不同。如果在运行不同代码页的计算机间交换数据，必须将所有字符数据由发送计算机的代码页转换为接收计算机的代码页。如果源数据中的扩展字符在接收计算机的代码页中未定义，那么数据将丢失。如果某个数据库为来自许多不同国家的客户端提供服务，则很难为该数据库选择这样一种代码页，使其包括所有客户端计算机所需的全部扩展字符。而且，在代码页间不停地转换需要花费大量的处理时间。

仅靠单字节字符集存储许多语言所使用的字符也是不够的。例如，一些亚洲语言包含上千个字符，所以每个字符必须使用双字节。双字节字符集正是为这些语言定义的。但是，这些语言都有各自的代码页，在运行不同双字节代码页的计算机之间传输数据也存在困难。

SQL Server 2000 支持以下代码页。

代码页 | 描述
1258 | 越南语
1257 | 波罗的语
1256 | 阿拉伯语
1255 | 希伯来语
1254 | 土耳其语
1253 | 希腊语
1252 | 拉丁 1 字符 (ANSI)
1251 | 西里尔语
1250 | 中欧语言
950 | 繁体中文
949 | 朝鲜语
936 | 简体中文
932 | 日语
874 | 泰国语
850 | 多语种 (MS-DOS Latin1)
437 | MS-DOS 美国英语

为解决在网络中支持多种代码页时出现的字符转换和解释问题，ISO 标准化组织和称为 Unicode Consortium 的团体定义了 Unicode 标准。Unicode 使用双字节存储每个字符。由于 65,536 个字符足以涵盖世界上所有语言常用的字符，因此 Unicode 标准适用于所有的主要语言。如果网络中的所有计算机和程序都使用 Unicode，则无需进行任何字符转换，每个用户与所有其它用户看到的字符完全相同，并且不会丢失任何字符。

在运行 Microsoft Windows® 操作系统的计算机上，操作系统和 Windows 应用程序使用的代码页由 Windows 区域设置定义。区域设置是在安装操作系统时选择的。Windows 应用程序使用由 Windows 区域设置定义的代码页来解释数据。Windows 应用程序还支持宽字符数据，即 Unicode 数据。

SQL Server 2000 支持两类字符数据类型：

  • Unicode 数据类型 nchar、nvarchar 和 ntext。这些数据类型使用 Unicode 字符表示法。代码页不适用于这些数据类型。

  • 非 Unicode 字符数据类型 char、varchar 和 text。这些数据类型使用单字节或双字节代码页中定义的字符表示法。

有关字符数据的存储方式以及代码页、Unicode 和排序次序操作的更多信息，请参见在 http://msdn.microsoft.com MSDN® 页中的 Developing International Software for Windows 95 and Windows NT 4.0。

国际化数据和 Unicode

当只使用字符数据和代码页时，在一个数据库内很难以多种语言存储数据。很难为数据库找到一种代码页，能够存储所需全部语言特有的字符。对于运行各种代码页的不同客户端所读取和更新的特殊字符，要确保正确地转换也很困难。支持国际化客户端的数据库应始终使用 Unicode 数据，而不应使用非 Unicode 数据类型。

例如，北美洲客户的数据库必须处理三种主要语言：

  • 墨西哥使用的西班牙文名称和地址。

  • 魁北克使用的法文名称和地址。

  • 加拿大的其余地区和美国使用的英文名称和地址。

当只使用字符列和代码页时须小心，以确保数据库所安装的代码页能够处理这三种语言的字符。当其中一种语言的字符由运行另一种语言的代码页的客户端读取时，必须更加小心以确保能够正确转换字符。

随着 Internet 的发展，支持众多运行不同区域设置的客户端计算机变得日益重要。很难选择这样一种代码页，使其包含的字符数据类型能够支持全球范围用户所需的全部字符。

管理国际化数据库中的字符数据的最简单方法是始终使用 Unicode nchar、nvarchar 和 ntext 数据类型，代替对应的非 Unicode 数据类型（char、varchar 和 text）。如果所有使用国际化数据库的应用程序也采用 Unicode 变量而不是非 Unicode 变量，那么在系统中的任何地方都无须进行字符转换。每个客户端与所有其它客户端看见的字符数据都完全相同。

对于可使用单字节代码页的系统，Unicode 数据需要的存储空间是非 Unicode 字符数据的两倍，但却消除了在代码页间转换扩展字符的必要，因此至少部分弥补了上面的不足。使用双字节代码页的系统没有这个问题。

SQL Server 2000 将所有的文本化系统目录数据都存储在包含 Unicode 数据类型的列中。数据库对象（如表、视图和存储过程）的名称存储在 Unicode 列中。这样就可以只使用 Unicode 开发应用程序，从而避免了所有的代码页转换问题。

排序次序

排序次序指定 SQL Server 解释、排序、比较和显示字符数据所使用的规则。例如，排序次序定义"a"是小于、等于还是大于"b"。排序次序定义排序规则是否区分大小写，例如"m"和"M"是否相同。另外还定义排序规则是否区分重音，例如"á"和"ä"是否相同。

SQL Server 2000 对每种排序规则使用两种排序次序，一种用于 Unicode 数据，另一种用于字符代码页。

许多 SQL Server 排序规则使用相同的代码页，但是代码页的排序次序不同。这使站点得以选择：

  • 是否仅根据位模式所表示的数字值来排序字符。二进制排序的速度最快，这是因为 SQL Server 不用做任何调整并可使用快速、简单的排序算法。二进制排序次序始终区分大小写。由于代码页中的位模式可能不按照特定语言的字典规则所定义的序列排列，二进制排序有时并不按照使用该语言的用户所期待的序列对字符进行排序。

  • 区分大小写还是不区分大小写。

  • 区分重音还是不区分重音。

请参见

用于国际支持的排序规则选项

SQL Server 排序规则基础知识

Unicode 数据

使用 Unicode 数据


SQL Server 排序规则基础知识

Microsoft® SQL Server™ 2000 支持多种排序规则。排序规则对控制正确使用语言（如马其顿语或波兰语）或字母表（如西欧语言使用的拉丁字母表 Latin1_General）字符的规则进行编码。

每个 SQL Server 排序规则指定三个属性：

  • 用于 Unicode 数据类型（nchar、nvarchar 和 ntext）的排序次序。排序次序定义字符的排序序列，以及在比较操作中对字符取值的方法。

  • 用于非 Unicode 字符数据类型（char、varchar 和 text）的排序次序。

  • 用于存储非 Unicode 字符数据的代码页。

    说明 不能指定与 Unicode 数据类型（nchar、nvarchar 和 ntext）对应的代码页。用于 Unicode 字符的双字节位模式由 Unicode 标准定义且不能更改。

可在任何级别上指定 SQL Server 2000 排序规则。安装 SQL Server 2000 实例时，可指定该实例的默认排序规则。每次创建数据库时，可指定用于该数据库的默认排序规则。如果未指定排序规则，数据库的默认排序规则即是实例的默认排序规则。无论何时定义字符列、变量或参数，都可指定这些对象的排序规则。如果未指定排序规则，将使用数据库的默认排序规则创建这些对象。

如果 SQL Server 实例的所有用户都使用同一种语言，则应选择支持该语言的排序规则。例如，若所有用户都讲法语，则选择法语排序规则。

如果 SQL Server 实例的用户使用多种语言，则应选择能对多语种需求提供最佳支持的排序规则。例如，如果用户一般都讲西欧语言，则选择 Latin1_General 排序规则。当支持使用多种语言的用户时，对所有字符数据都使用 Unicode 数据类型 nchar、nvarchar 和 ntext 最为重要。Unicode 旨在消除非 Unicode char、varchar 和 text 数据类型的代码页转换困难。因为排序规则定义用于比较操作的排序次序和 Unicode 字符的排序，所以当用 Unicode 数据类型实现所有的列时，排序规则仍会产生不同。即使当使用 Unicode 数据类型存储字符数据时，也应选择支持大多数用户的排序规则，以防使用非 Unicode 数据类型实现列或变量。

SQL Server 排序规则定义数据库引擎存储和操作字符及 Unicode 数据的方式。然而，当数据移入应用程序后，在应用程序中进行的字符排序和比较将由计算机上选定的 Windows 区域设置控制。应用程序使用的字符数据排序规则是由 Windows 区域设置控制的项目之一，区域设置还定义其它项目，如数字、时间、日期和货币格式。对于 Microsoft Windows NT® 4.0、Microsoft Windows® 98 和 Microsoft Windows 95，可使用控制面板中的"区域设置"应用程序指定 Windows 区域设置。对于 Microsoft Windows 2000，可使用"控制面板"中的"区域选项"应用程序指定区域设置。有关 Windows 区域设置的更多信息，请参见 Microsoft Web 站点 MSDN® 页中的 Developing International Software for Windows 95 and Windows NT 4.0。

多个排序规则可对非 Unicode 数据使用相同的代码页。例如，代码页 1251 定义西里尔语字符集。多个排序规则（如 Cyrillic_General、Ukrainian 和 Macedonian）都使用该代码页。虽然这些排序规则都使用相同的位集来表示非 Unicode 字符数据，但在处理字典定义时所应用的排序和比较规则略有不同，而字典定义确定语言或字母表中与排序规则相关的正确字符序列。

因为 SQL Server 2000 排序规则控制 Unicode 和非 Unicode 排序次序，所以不会遇到由为 Unicode 和非 Unicode 数据指定不同的排序规则而引起的问题。在 SQL Server 的早期版本中，对代码页号、字符排序次序和 Unicode 排序规则分别进行指定。SQL Server 的早期版本还支持每个代码页有不同数目的排序次序，并为某些代码页提供 Windows 区域设置中没有的排序次序。在 SQL Server 7.0 中，还可以指定为非 Unicode 数据选择的排序次序以外的其它 Unicode 排序次序。这会导致在使用与非 Unicode 数据相对的 Unicode 数据时，排序和比较操作返回不同的结果。

请参见

COLLATE

用于国际支持的排序规则选项

排序规则

Unicode 数据

使用 Unicode 数据


选择排序规则

在 Microsoft® SQL Server™ 2000 中，可指定单个排序规则名来控制所有三个排序规则特性：Unicode 排序次序、非 Unicode 代码页和非 Unicode 排序次序。SQL Server 2000 排序规则不允许对 Unicode 和非 Unicode 字符数据使用不同的比较和排序规则。有两组 SQL Server 2000 排序规则：Windows 排序规则和 SQL 排序规则。

Windows 排序规则

Windows 排序规则是为 SQL Server 定义的排序规则，用以支持 Microsoft Windows® 区域设置。通过为 SQL Server 指定 Windows 排序规则，并为计算机指定相关联的 Windows 区域设置，SQL Server 实例便与计算机上运行的应用程序使用相同的代码页及排序和比较规则。例如，SQL Server 的法语 Windows 排序规则与 Windows 法语区域设置的排序规则特性相匹配。

Windows 区域设置的数量比 SQL Server Windows 排序规则多。Windows 区域设置名基于语言和地域，如法语（加拿大）。不过，多种语言共享用于排序和比较字符的公用字母表和规则。例如，33 个 Windows 区域设置（包括所有葡萄牙语和英语 Windows 区域设置）使用 Latin1 代码页 (1252) 并遵循一组公用的字符排序和比较规则。基于 Latin1_General 代码页和排序规则的 SQL Server Windows 排序规则支持所有这 33 个 Windows 区域设置。另外，Windows 区域设置还指定 SQL Server Windows 排序规则不涉及的特性，如货币、日期和时间格式等。美国和英国这样的国家有不同的货币、日期和时间格式，因此它们需要不同的 Windows 排序规则。但它们排序和比较字符所使用的字母表和规则相同，所以不需要不同的 SQL Server 排序规则。

SQL 排序规则

SQL 排序规则是兼容性选项，用以匹配 SQL Server 早期版本所指定的代码页号和排序次序的公用组合特性。例如，为将 SQL Server 2000 SQL 排序规则映射到 SQL Server 早期版本所指定的排序规则，SQL Server 2000 SQL 排序规则 SQL_Latin1_General_CP1_CI_AS 与下列 SQL Server 7.0 版的默认规范相匹配：

  • ISO 代码页 1252。

  • 字典次序、不区分大小写的字符排序次序。

  • 通用 Unicode 排序规则。

SQL Server 2000 中的可用 SQL 排序规则与可在 SQL Server 早期版本中指定的所有组合并非都匹配。例如，SQL Server 2000 SQL 排序规则不支持非 Unicode 数据的区分大小写排序次序和 Unicode 数据的不区分大小写排序次序。在 SQL Server 2000 中不能明确指定的 SQL 早期排序规则被称为已废弃的 SQL 排序规则。

在 SQL Server 2000 中应主要使用 Windows 排序规则。仅当要与 SQL Server 早期版本的现有实例保持兼容时，或要在使用 SQL Server 早期版本的 SQL 排序规则开发的应用程序中维护兼容性时，才应使用 SQL 排序规则。

排序规则比较和排列规则

排序规则中所定义的大多数比较和排列规则由字典定义控制，而字典定义确定字母表或语言的正确字符序列。可控制的特性包括字符和 Unicode 数据的比较和排序是：

  • 基于字典规则，即定义语言或字母表中与排序规则相关的正确字符序列，还是基于表示不同字符的二进制位模式序列。

  • 区分大小写还是不区分大小写。例如，定义"a"与"A"是否相同。如果选择不区分大小写，比较操作将始终忽略大小写，因此将字符的大写与小写视为相同。如果选择区分大小写，大写和小写的相对排序序列将不确定，除非还指定了大写字母优先。大写字母优先仅影响排序操作，用于指定在排序序列中大写字母排在同一字符的小写字母前面。大写字母优先不影响比较操作，因此指定该选项时仍将"A"和"a"视为相同。只能在 SQL 排序规则中指定大写字母优先，而不能在 Windows 排序规则中指定。

  • 区分还是不区分重音字符（也称为扩展字符）。重音字符是带变音符的字符，如德语的元音变化 (ë) 或西班牙语的颚化符号 (~)。例如，区分重音将定义"a"和"ä"是否相同。

当选择排序规则时，可指定是否需要二进制行为，或指定字典排序是否区分大小写和重音：

  • 在二进制排序规则中，比较和排序操作严格基于字符的位模式。这是最快的选项。因为存储大写字符所使用的位模式不同于存储相应的小写字符所使用的位模式，而且重音字符的位模式与非重音字符的位模式也不相同，所以二进制排序次序始终区分大小写和重音。二进制排序规则还忽略为特定语言定义的字典序列。它们仅基于表示每个字符的相对位模式值对字符进行排序。虽然为拉丁字符（如"A"或"z"）定义的位模式使二进制排序输出正确的结果，但为某些代码页中的扩展字符定义的位模式可能不同于该语言与排序规则相关的字典所定义的排序序列。这会导致排序和比较结果有时与使用该语言的用户所期望的不同。

  • 如果不指定二进制排序规则，SQL Server 将使用选定排序规则的字典次序。字典次序表示不只是基于位模式对字符进行排序或比较。该排序规则将遵从相关语言关于正确字符序列的规则。例如，不区分大小写的排序次序必须使用字典规则来确定哪种大写和小写位模式相同。

    虽然代码页中的位模式通常可为使用该代码页的任何语言输出正确的比较和排序结果，但某些语言的规则可能需要不同于为少量字符的位模式生成的结果。例如，捷克语、匈牙利语和波兰语使用同一代码页 1250，该代码页专门用于斯拉夫语。然而，这些语言所使用的重音字符排序序列规则略有不同。

    如果不指定二进制排序，所有 SQL Server 操作将遵从用于排序和比较字符的字典规则。当使用字典次序时，可指定排序规则是否区分大小写和重音字符。

区分大小写不仅适用于数据，还适用于 SQL 标识符和密码。如果为 SQL Server 实例或数据库指定二进制或区分大小写的默认排序次序，则所有的对象引用都必须使用创建对象时所使用的大小写。例如，考察下表：

CREATE TABLE MyTable (PrimaryKey int PRIMARY KEY, CharColumn nchar(10))

如果在使用区分大小写或二进制排序次序的 SQL Server 实例或数据库上执行 CREATE TABLE 语句，所有的表引用都必须使用在 CREATE TABLE 语句中指定的大小写：

-- Object not found error because case is not correct:
SELECT * FROM MYTABLE
-- Invalid column name error because case is not correct
-- for the WHERE clause reference to the PrimaryKey column.
SELECT *
FROM MyTable
WHERE PRIMARYKEY = 123
-- Correct statement:
SELECT CharColumn
FROM MyTable
WHERE PrimaryKey = 123

请参见

用于国际支持的排序规则选项

指定排序规则

Unicode 数据

使用 Unicode 数据


指定排序规则

可在多个级别上指定 Microsoft® SQL Server™ 2000 排序规则，具体如下：

  • 当安装 SQL Server 实例时，可在安装过程中指定该实例的默认排序规则。实例的默认排序规则也成为这些系统数据库的默认排序规则：master、model、tempdb、msdb 和 Distribution。

  • 当创建数据库时，可使用 CREATE DATABASE 语句的 COLLATE 子句指定该数据库的默认排序规则。还可在创建数据库时使用 SQL Server 企业管理器指定排序规则。如果不指定排序规则，将为数据库指派 model 数据库的默认排序规则。model 数据库的默认排序规则与 SQL Server 实例的默认排序规则相同。

  • 当创建表时，可使用 CREATE TABLE 语句的 COLLATE 子句指定每个字符的排序规则。还可在创建表时使用 SQL Server 企业管理器指定排序规则。如果不指定排序规则，将为列指派数据库的默认排序规则。

    还可使用 COLLATE 子句中的 database_default 选项，指定临时表中的列使用连接的当前用户数据库（而不是 tempdb）的默认排序规则。

  • 当指定文字字符串时，可使用 COLLATE 子句指定排序规则。如果不指定排序规则，将为文字指派数据库的默认排序规则。

  • 在 SQL-DMO 中可使用"排序规则"属性指定实例、数据库和列的排序规则。有关更多信息，请参见排序规则属性。

  • 为存储过程或函数的参数、用户定义数据类型和变量指派数据库的默认排序规则：

标识符的排序规则取决于定义标识符时所在的级别。为实例级对象（如登录名和数据库名）的标识符指派实例的默认排序规则。为数据库对象（如表、视图和列名）的标识符指派数据库的默认排序规则。当连接上下文与一个数据库相关联时，可创建变量、GOTO 标签、临时存储过程和临时表，然后当连接上下文切换到另一个数据库时加以引用这些对象。由于这一点，变量、GOTO 标签和临时表的标识符使用实例的默认排序规则。

只能为 char、varchar、text、nchar、nvarchar 和 ntext 数据类型指定列或文字的排序规则。

排序规则一般由排序规则名标识。有两类名称：一类是 Windows 排序规则名称，用于匹配 Windows 区域设置的新排序规则；另一类是 SQL 排序规则名称，用于升级 SQL Server 早期版本时所产生的兼容模式排序规则。有关更多信息，请参见 Windows 排序规则名称和 SQL 排序规则名称。

指定排序规则名的特例是在安装过程中：

  • 不指定 Windows 排序规则的排序规则名，而是指定排序规则指示器，然后选择复选框以指定区分或不区分大小写或重音的二进制排序或字典排序。

  • 不指定 SQL 排序规则名称，而是基于更易于阅读的长显示名称选择排序规则。

可以执行系统函数 fn_helpcollations，检索 Windows 排序规则和 SQL 排序规则的有效排序规则名列表，例如：

SELECT *
FROM ::fn_helpcollations()

还可使用 SQL-DMO ListCollations 方法获得有效排序规则名的列表。有关更多信息，请参见 ListCollations 方法。

系统目录存储过程已得到增强，可报告有排序规则的所有 SQL Server 对象的排序规则。

SQL Server 只支持由基础操作系统支持的代码页。当执行依赖排序规则的操作时，被引用对象所使用的 SQL Server 排序规则必须使用计算机上运行的操作系统所支持的代码页。这些操作可包括：

  • 指定 SQL Server 实例的默认排序规则。

  • 创建数据库时指定数据库的默认排序规则。

  • 还原数据库备份。Windows 必须支持数据库的默认排序规则所使用的代码页。

  • 附加数据库。Windows 必须支持数据库的默认排序规则所使用的代码页。

  • 创建表时指定列的排序规则。

  • 创建用户定义的数据类型时指定排序规则。

  • 声明字符串常量时指定排序规则。

如果指定的排序规则或被引用对象所使用的排序规则使用 Microsoft Windows® 操作系统不支持的代码页，SQL Server 将发出 2775 号错误：

"系统不支持代码页 codepagenumber。"

对该错误信息的响应取决于计算机上安装的 Windows 操作系统版本：

  • Microsoft Windows 2000 支持 SQL Server 排序规则所使用的所有代码页，因此不会产生该错误信息。

  • Microsoft Windows NT® 4.0 可能要求安装语言包以支持某些代码页。有关安装 Windows NT 语言包的更多信息，请参见 Windows NT 帮助。

  • Microsoft Windows 98 仅支持在一台计算机上使用一种代码页。必须选择与 Windows 98 使用相同代码页的 SQL Server 排序规则。

请参见

ALTER TABLE

用于国际支持的排序规则选项

排序规则

常量

CREATE DATABASE

CREATE TABLE

DECLARE @local_variable

table

使用 Unicode 数据


指定 SQL Server 实例的默认排序规则

在安装过程中定义 Microsoft® SQL Server™ 2000 实例的默认排序规则。如果选择最小安装或典型安装选项，安装程序将安装以下排序规则：

  • 如果将 SQL Server 6.5 版或 SQL Server 7.0 版的默认实例升级到 SQL Server 2000，或者安装的 SQL Server 2000 默认实例将与 SQL Server 6.5 版的默认实例进行版本交换，SQL Server 安装程序将继续使用现有 SQL Server 6.5 版或 7.0 版实例所使用的排序规则，包括已废弃的排序规则。

  • 在所有其它情况下，安装程序将选择 Windows 排序规则，以便在安装有 SQL Server 2000 实例的计算机上支持 Windows 区域设置。

说明 如果计算机使用的是美国英语区域设置，则安装程序不将实例的默认排序规则设置为 Windows 排序规则 Latin1_General_CI_AS。而是设置为 SQL 排序规则 SQL_Latin1_General_Cp1_CI_AS。这一点在以后的版本中可能会改变。

如果选择"自定义"安装选项，当显示"字符集/排序次序/Windows 排序规则"窗口时，安装程序将使用与最小和典型安装相同的逻辑来设置选定的排序规则。在以下情况中不应使用选定的排序规则：

  • 如果要在复制方案中包括该实例，则复制方案中包括的所有 SQL Server 实例（发布服务器、订阅服务器和分发服务器）应使用相同的代码页。应确保安装程序所选择的排序规则与复制方案中的其它 SQL Server 实例使用相同的代码页。

  • 如果实例必须支持的主要语言与安装实例的计算机所使用的 Windows 区域设置不同。

有关说明为 Windows 区域设置指定何种排序规则名称，请参见 Windows 排序规则名称。

在安装过程中，指派给 master、model、tempdb、msdb 和 Distribution 系统数据库的默认排序规则与为实例选择的默认排序规则相同。

请参见

用于国际支持的排序规则选项


混合排序规则环境

兼容性问题对使用多个排序规则存储数据的组织会有影响。大多数组织对所有的 Microsoft® SQL Server™ 2000 数据库使用相同的排序规则，从而消除了所有的排序规则兼容性问题。然而，有些组织存储的数据必须可由使用不同语言的用户查看，并且希望尽可能减少排序规则兼容性问题。

所有字符和 Unicode 对象（如列、变量和常量）都有排序规则。每当使用具有不同排序规则和代码页的对象时，都必须对查询进行编码以符合排序规则类型强制规则。当对使用运算符将多个具有不同排序规则的简单表达式组合在一起的复杂表达式进行编码时，所有排序规则必须可以隐性转换，或者可以使用 COLLATE 子句显式转换。有关排序规则强制顺序的更多信息，请参见排序规则的优先顺序。

如果没有在字符或 Unicode 表达式中指定排序规则，则默认排序规则可能因连接的当前数据库设置而异。例如，如果没有在字符或 Unicode 常量上指定 COLLATE 子句，则将给该常量指派当前数据库的默认排序规则。这意味着 Transact-SQL 语句的结果在不同数据库的上下文中执行时可能有不同的排序规则。

若设置复制，则复制网络（包括发布服务器、订阅服务器和分发服务器）中包括的所有数据库都必须使用相同的代码页。

大容量复制函数 BULK INSERT 和 bcp 命令提示实用工具支持列排序规则。有关更多信息，请参见在不同排序规则间复制数据。

尽可能减少排序规则问题

如果必须存储反映多种语言的字符数据，始终使用 Unicode nchar、nvarchar 和 ntext 数据类型（而不是 char、varchar、text 数据类型）可使排序规则兼容性问题减到最少。使用 Unicode 数据类型可消除代码页转换问题。

对减少排序规则兼容性问题的另一个建议是使站点标准化，使之区分或不区分大小写和重音字符。若始终选择对大小写和重音使用相同敏感性的排序规则，最终用户将在所有系统间体验到一致的行为。大多数 SQL Server 2000 站点选择不区分大小写但区分重音。大小写敏感性还适用于 SQL Server 的对象名；因此，若指定区分大小写的排序规则，则所有用户在查询数据库时必须指定正确的大小写。例如，若服务器区分大小写并创建一个名为 Employees 的表，则所有的查询都必须将该表引用为 Employees。未使用正确大小写的引用（如 EMPLOYEES 或 employees）将无效。

排序规则和 tempdb

每次启动 SQL Server 时都生成 tempdb 数据库，该数据库与 model 数据库的默认排序规则相同，后者通常与实例的默认排序规则相同。如果为创建的用户数据库指定的默认排序规则与 model 的排序规则不同，则该用户数据库与 tempdb 的默认排序规则也不同。所有的临时存储过程或临时表都创建并存储在 tempdb 中，这意味着临时表中的所有隐性列以及临时存储过程中的所有类型强制默认常量、变量和参数与永久表和永久存储过程中创建的对等对象使用不同的排序规则。

text 数据类型可能由此产生问题。例如，某个 SQL Server 2000 实例的默认排序规则是 Latin1_General_CS_AS，并且执行以下语句：

CREATE DATABASE TestDB COLLATE Estonian_CS_AS
USE TestDB
CREATE TABLE TestPermTab (PrimaryKey int PRIMARY KEY, TextCol text )

在该系统中，tempdb 数据库对代码页 1252 使用 Latin1_General_CS_AS 排序规则，TestDB 和 TestPermTab.TextCol 对代码页 1257 使用 Estonian_CS_AS 排序规则。如果接下来执行：

USE TestDB
GO
-- Create a temporary table with the same column declarations
-- as TestPermTab
CREATE TABLE #TestTempTab (PrimaryKey int PRIMARY KEY, TextCol text )
-- This statement gets an code page conversion not allowed error
-- because the temporary table is created in tempdb, which has a
-- different default collation than TestDB.
INSERT INTO #TestTempTab
         SELECT * FROM TestPermTab
GO

若要消除错误，可使用以下可选方法之一：

  • 在两个 TextCol 列中使用 Unicode 数据类型 ntext 而不是 text。

  • 指定临时表列使用用户数据库（而不是 tempdb）的默认排序规则。如果系统需要，这将使临时表得以在多个数据库中使用具有类似格式的表。
    CREATE TABLE #TestTempTab
   (PrimaryKey int PRIMARY KEY,
    TextCol text COLLATE database_default
   )
  • 指定 #TestTempTab 列的正确排序规则：
    CREATE TABLE #TestTempTab
   (PrimaryKey int PRIMARY KEY,
    TextCol text COLLATE Estonian_CS_AS
   )
BACKUP 和 RESTORE 中的排序规则

若还原数据库，RESTORE 将使用记录在备份文件中的源数据库的排序规则。还原的数据库与备份的原始数据库使用相同的排序规则。数据库内具有不同排序规则的个别对象仍保留其原来的排序规则。即使运行还原的实例与运行 BACKUP 的实例使用不同的默认排序规则，仍能还原数据库。

若目标服务器上已存在同名数据库，还原备份的唯一方法是在 RESTORE 语句中指定 REPLACE。若指定 REPLACE，现有的数据库将由备份文件中的数据库内容完全替换，并且还原数据库的排序规则将与备份文件中记录的排序规则相同。

若还原日志备份，目的数据库必须与源数据库的排序规则相同。

排序规则和文本列

若创建的含有 text 列的表所使用的代码页与数据库默认排序规则的代码页不同，则仅有两种方法可指定插入列的数据值或更新现有值。可以：

  • 指定 Unicode 常量。

  • 从另一个具有相同代码页的列中选择值。

假设数据库和表如下：

-- Create a database with a default of code page 1252.
CREATE DATABASE TestDB COLLATE Latin1_General_CS_AS
-- Create a table with a different code page, 1253.
CREATE TABLE TestTab
   (PrimaryKey int PRIMARY KEY,
    TextCol text COLLATE Greek_CS_AS
   )

-- This INSERT statement successfully inserts a Unicode string.
INSERT INTO TestTab VALUES (1, N'abc')
-- This INSERT statement successfully inserts data by selecting
-- from a similarly formatted table in another database that uses
-- uses the Greek 1253 code page as its default.
INSERT INTO TestTab
     SELECT * FROM GreekDatabase.dbo.TestTab


更改排序规则

可使用 ALTER TABLE 语句更改列的排序规则：

CREATE TABLE MyTable
  (PrimaryKey   int PRIMARY KEY,
   CharCol      varchar(10) COLLATE French_CI_AS NOT NULL
  )
GO
ALTER TABLE MyTable ALTER COLUMN CharCol
            varchar(10)COLLATE Latin1_General_CI_AS NOT NULL
GO

不能更改正由以下对象引用的列的排序规则：

  • 计算列。

  • 索引。

  • 自动生成或由 CREATE STATISTICS 语句生成的分发统计。

  • CHECK 约束。

  • FOREIGN KEY 约束。

还可在 ALTER DATABASE 上使用 COLLATE 子句来更改数据库的默认排序规则：

ALTER DATABASE MyDatabase COLLATE French_CI_AS

更改数据库的默认排序规则不会更改任何现有用户定义表中的列排序规则。可使用 ALTER TABLE 更改列的排序规则。在 ALTER DATABASE 语句上使用 COLLATE CLAUSE 可以：

  • 更改数据库的默认排序规则。新的默认排序规则适用于随后创建在数据库中的所有列、用户定义数据类型、变量和参数。在数据库中定义的对象上解析 SQL 语句中指定的对象标识符时，也使用新的默认排序规则。

  • 将系统表中的任何 char、varchar、text、nchar、nvarchar 或 ntext 列更改为使用新的排序规则。

  • 将存储过程和用户定义函数的所有现有的 char、varchar、text、nchar、nvarchar 或 ntext 参数和标量返回值更改为使用新的排序规则。

  • 将 char、varchar、text、nchar、nvarchar 或 ntext 系统数据类型，以及基于这些系统数据类型的所有用户定义数据类型更改为使用新的默认排序规则。

为列或数据库以外的任何其它对象指派了排序规则后，将不能更改排序规则，除非除去并重新创建对象。这一操作将十分复杂。若要更改 Microsoft® SQL Server™ 2000 实例的默认排序规则，必须：

  • 确保具有重新创建用户数据库及数据库中的所有对象所需的全部信息或脚本。

  • 使用工具（如大容量复制）导出所有数据。

  • 除去所有用户数据库。

  • 重建 master 数据库并指定新的排序规则。

  • 创建所有数据库及数据库中的所有对象。

  • 导入所有数据。

    说明 也可以不更改 SQL Server 2000 实例的默认排序规则，而为创建的每个新数据库指定默认排序规则。


SQL 索引

Microsoft® SQL Server™ 2000 索引是与表或视图相关联的结构，可加快从表或视图中检索行的速度。索引包含由表或视图中的一列或多列生成的键。这些键存储在一个结构内，使 SQL Server 得以快速有效地找到与键值相关联的一行或多行。


表索引

Microsoft® SQL Server™ 2000 支持在表中任何列（包括计算列）上定义的索引。

如果一个表没有创建索引，则数据行不按任何特定的顺序存储。这种结构称为堆集。

SQL Server 索引的两种类型为：

  • 聚集

    聚集索引基于数据行的键值在表内排序和存储这些数据行。由于数据行按基于聚集索引键的排序次序存储，因此聚集索引对查找行很有效。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。数据行本身构成聚集索引的最低级别。

    只有当表包含聚集索引时，表内的数据行才按排序次序存储。如果表没有聚集索引，则其数据行按堆集方式存储。

  • 非聚集

    非聚集索引具有完全独立于数据行的结构。非聚集索引的最低行包含非聚集索引的键值，并且每个键值项都有指针指向包含该键值的数据行。数据行不按基于非聚集键的次序存储。

    在非聚集索引内，从索引行指向数据行的指针称为行定位器。行定位器的结构取决于数据页的存储方式是堆集还是聚集。对于堆集，行定位器是指向行的指针。对于有聚集索引的表，行定位器是聚集索引键。

只有在表上创建了聚集索引时，表内的行才按特定的顺序存储。这些行就基于聚集索引键按顺序存储。如果一个表只有非聚集索引，它的数据行将按无序的堆集方式存储。

索引可以是唯一的，这意味着不会有两行有相同的索引键值。另外，索引也可以不是唯一的，多个行可以共享同一键值。

有两种方法可以在 SQL Server 内定义索引。CREATE INDEX 语句创建并命名索引。CREATE TABLE 语句支持在创建索引时使用下列约束：

  • PRIMARY KEY 创建唯一索引来强制执行主键。

  • UNIQUE 创建唯一索引。

  • CLUSTERED 创建聚集索引。

  • NONCLUSTERED 创建非聚集索引。

当在 SQL Server 2000 上创建索引时，可指定是按升序还是降序存储键。

SQL Server 2000 支持在计算列上定义的索引，只要为列定义的表达式满足某些限制，如仅引用包含计算列的表中的列、具有确定性等。

填充因子是 SQL Server 索引的一个属性，它控制索引在创建时的填充密度。默认的填充因子通常能够提供较好的性能，但在某些情况下，更改填充因子可能会有益。如果打算对表执行许多更新和插入，则可在创建索引时使用小填充因子，以便为后面的键留出更多的空间。如果是不会更改的只读表，则可在创建索引时使用大填充因子，以减小索引的物理大小，这样可以降低 SQL Server 浏览索引时的磁盘读取次数。只有在创建索引时才能应用填充因子。随着键的插入和删除，索引最终将稳定在某个密度上。

索引不仅可以提高选择行的检索速度，通常还可以提高更新和删除的速度。这是因为 SQL Server 在更新或删除行时必须先找到该行。使用索引定位行提高了效率，这通常可以弥补更新索引所需的额外开销，除非表中有很多索引。

下例显示在表上创建索引的 Transact-SQL 语法。

USE pubs
GO
CREATE TABLE emp_sample
   (emp_id      int         PRIMARY KEY CLUSTERED,
   emp_name      char(50),
   emp_address   char(50),
   emp_title   char(25)      UNIQUE NONCLUSTERED )
GO
CREATE NONCLUSTERED INDEX sample_nonclust ON emp_sample(emp_name)
GO

对于具体什么样的索引集可优化性能这个问题，取决于系统中的查询混合。考察 emp_sample.emp_id 上的聚集索引。如果大多数引用 emp_sample 的查询在它们的 WHERE 子句中有关于 emp_id 的等式或范围比较，聚集索引将发挥很好的作用。如果大多数查询的 WHERE 子句引用的是 emp_name 而非 emp_id，则通过将 emp_name 上的索引置为聚集索引可提高性能。

许多应用程序的查询混合都很复杂，单靠询问用户和程序员很难进行评估。SQL Server 2000 提供索引优化向导，帮助您在数据库中设计索引。对具有复杂访问模式的大型架构，最简单的设计索引的方法是使用索引优化向导。

可以为索引优化向导提供一组 SQL 语句。这组语句可以是为反映系统中典型的语句混合而生成的语句脚本。不过，这组语句通常是 SQL 事件探查器跟踪记录，记录在系统典型负载期间系统上实际处理的 SQL 语句。索引优化向导分析工作负荷和数据库，然后提出可提高工作负荷性能的索引配置建议。可以选择替换现有的索引配置，或者保留现有的索引配置并实现新的索引，以提高执行速度慢的查询子集的性能。

请参见

索引

创建索引的并行操作


视图索引

Microsoft® SQL Server™ 2000 支持在视图上定义索引。视图有时也称为虚拟表，这是由于视图返回的结果集与包含行和列的表具有相同的常规格式，并且在 SQL 语句中可以相同的方式引用视图和表。非索引视图的结果集不永久存储在数据库中。每当查询引用视图时，SQL Server 便动态地将生成视图结果集所需的逻辑合并到由基表中的数据生成完整的查询结果集所需的逻辑中。生成视图结果的过程称为视图具体化。有关更多信息，请参见视图解析。

对于涉及对大量的行进行复杂处理的非索引视图，为引用视图的每个查询动态生成结果集的开销会很大。这类视图包括聚集大量数据或联接许多行的视图。若经常在查询中引用这类视图，可通过在视图上创建唯一聚集索引来提高性能。在视图上创建唯一聚集索引时将执行该视图，并且结果集在数据库中的存储方式与带聚集索引的表的存储方式相同。有关用于存储聚集索引的结构的更多信息，请参见聚集索引。

在视图上创建索引的另一个好处是：查询优化器开始在查询中使用视图索引，而不是直接在 FROM 子句中命令视图。这样一来，可从索引视图检索数据而无需重新编码，由此带来的高效率也使现有查询获益。

在视图上创建聚集索引可存储创建索引时生成的结果集。索引视图还自动反映自创建索引后对基表数据所做的更改，这一点与在基表上创建的索引相同。当对基表中的数据进行更改时，索引视图中存储的数据也反映数据更改。视图的聚集索引必须唯一，从而提高了 SQL Server 在索引中查找受任何数据更改影响的行的效率。

必须设置特定的 SET 选项后才能在视图上创建索引。只有当执行语句的连接具有相同的选项设置时，查询优化器才考虑对后续 SQL 语句使用索引。有关更多信息，请参见影响结果的 SET 选项。

与基表上的索引相比，对索引视图的维护可能更复杂。只有当提高的视图结果检索速度超过了修改所需的开销时，才应在视图上创建索引。这样的视图通常包括映射在相对静态的数据上、处理多行以及由许多查询引用的视图。

在视图上创建的第一个索引必须是唯一聚集索引。在创建唯一聚集索引后，可创建其它非聚集索引。视图上的索引命名规则与表上的索引命名规则相同。唯一区别是表名由视图名替换。

若除去视图，视图上的所有索引也将被除去。若除去聚集索引，视图上的所有非聚集索引也将被除去。可分别除去非聚集索引。除去视图上的聚集索引将删除存储的结果集，并且优化器将重新像处理标准视图那样处理视图。

尽管 CREATE UNIQUE CLUSTERED INDEX 语句仅指定组成聚集索引键的列，但视图的完整结果集将存储在数据库中。与基表上的聚集索引一样，聚集索引的 B 树结构仅包含键列，但数据行包含视图结果集中的所有列。

请参见

CREATE INDEX

创建索引视图

在视图上使用索引


索引键的最大值

Microsoft® SQL Server™ 2000 保留 900 字节的最大索引键值限制，但更改了 CREATE INDEX 检查指定索引键是否超出允许的 900 字节最大键值时所使用的算法。新的 CREATE INDEX 算法与用于 CREATE TABLE 的行大小算法类似。

Microsoft SQL Server 7.0 版和更早的版本在检查 CREATE INDEX 语句所指定的键是否超出 900 字节时始终使用可变列的最大大小，例如：

CREATE TABLE TestTable
    (PrimaryKey      int PRIMARY KEY,
     VarCharCol1     varchar(500),
     VarCharCol2     varchar(500)
    )
-- This statement fails because the maximum sizes
-- of the two columns exceeds 900 bytes:
CREATE INDEX TestIdx ON TestTable(VarCharCol1, VarCharCol2)

在 SQL Server 2000 中，上面的 CREATE INDEX 语句将成功执行但出现警告消息，除非一个或更多的数据行生成的键值超出 900 字节。

SQL Server 2000 CREATE INDEX 语句使用以下算法：

  • 若所有固定列的大小加上 CREATE INDEX 语句指定的所有可变列的最大大小小于 900 字节，CREATE INDEX 语句将成功执行且不出现警告或错误。

  • 若所有固定列的大小加上所有可变列的最大大小超过 900 字节，但是所有固定列的大小加上所有可变列的最小大小小于 900 字节，CREATE INDEX 语句将成功执行但出现一条警告，指出如果后续 INSERT 或 UPDATE 语句指定的值所生成的键值大于 900 字节，该语句将失败。若表中现有数据行的值所生成的键值大于 900 字节，CREATE INDEX 语句将失败。若后续 INSERT 或 UPDATE 语句指定的数据值所生成的键值大于 900 字节，该语句将失败。

  • 若所有固定列的大小加上 CREATE INDEX 语句指定的所有可变列的最小大小大于 900 字节，CREATE INDEX 语句将失败。

下表显示创建某类索引的结果，这类索引的键只包含固定列或可变长度列。

索引列 |  |  |  |  |
固定数据列的大小 | 可变长度列的最大大小 | 索引键列长度总和的最大值* | 是否创建索引 | 消息 | 由于索引键值过大导致 INSERT 或 UPDATE 运行时错误
> 900 字节 | 无 | 不相关 | 否 | 错误 | 索引没有生成错误。
<=900 字节 | 无 | 不相关 | 是 | 无 | 否
无 | <=900 字节 | 不相关 | 是 | 无 | 否
无 | > 900 字节 | > 900 字节 | 否 | 错误 | 索引没有生成错误。
无 | > 900 字节 | <=900 字节 | 是 | 警告 | 仅当所有索引列的当前长度之和大于 900 字节。

*在执行 CREATE INDEX 语句时，表中的任何行都不能有总长度超过 900 字节的索引键值。

下表显示创建某类索引的结果，这类索引的键包含由固定列和可变长度列组成的混合类型。

索引列 |  |  |  |  |
可变长度列的最小大小 + 固定数据列的大小 | 可变长度列的最大大小 + 固定数据列的大小 | 索引键列长度总和的最大值* | 是否创建索引 | 消息 | 由于索引键值过大导致 INSERT 或 UPDATE 运行时错误
> 900 字节 | 不相关 | 不相关 | 否 | 错误 | 索引没有生成错误。
<=900 字节 | <=900 字节 | 不相关 | 是 | 无 | 否。
<=900 字节 | > 900 字节 | <=900 字节 | 是 | 警告 | 仅当所有索引列的当前长度之和大于 900 字节。
<=900 字节 | > 900 字节 | > 900 字节 | 否 | 错误 | 索引没有生成错误。

*在执行 CREATE INDEX 语句时，表中的任何行都不能有总长度超过 900 字节的索引键值。

请参见

CREATE INDEX


属性管理

Microsoft® SQL Server™ 2000 引入了扩展属性，用户可在各种数据库对象上定义这些属性。这些扩展属性可用于存储与数据库对象有关的应用程序或站点特有的信息。因为属性存储在数据库中，所有读取属性的应用程序都能以相同的方式评估对象。这有助于在系统中的所有程序对数据的处理方式上强制一致性。

每个扩展属性都有用户定义的名称和值。扩展属性的值是可包含最多 7500 字节数据的 sql_variant。个别数据库对象可以有多个扩展属性。

扩展属性由三个系统存储过程进行管理：sp_addextendedproperty、sp_updateextendedproperty 和 sp_dropextendedproperty。可使用系统函数 FN_LISTEXTENDEDPROPERTY 读取现有扩展属性的值。

在定义扩展属性方面没有规则和标准。当设计数据库时，数据库设计器设置用于指定属性名和内容的规则，此后必须对访问数据库的应用程序进行编码，使其遵守那些规则或规范。

请参见

在数据库对象上使用扩展属性

fn_listextendedproperty

sp_addextendedproperty

sp_dropextendedproperty

sp_updateextendedproperty


全文目录和索引

Microsoft® SQL Server™ 2000 全文索引为在字符串数据中进行复杂的词搜索提供有效支持。全文索引存储关于重要词和这些词在特定列中的位置的信息。全文查询利用这些信息，可快速搜索包含具体某个词或一组词的行。

全文索引包含在全文目录中。每个数据库可以包含一个或多个全文目录。一个目录不能属于多个数据库，而每个目录可以包含一个或多个表的全文索引。一个表只能有一个全文索引，因此每个有全文索引的表只属于一个全文目录。

全文目录和索引不存储在它们所属的数据库中。目录和索引由 Microsoft 搜索服务分开管理。

全文索引必须在基表上定义，而不能在视图、系统表或临时表上定义。 全文索引的定义包括：

  • 能唯一标识表中各行的列（主键或候选键），而且不允许 NULL 值。

  • 索引所覆盖的一个或多个字符串列。

全文索引由键值填充。每个键的项提供与该键相关联的重要词（干扰词或终止词除外）、它们所在的列和它们在列中的位置等有关信息。

格式化文本字符串（如 Microsoft® Word™ 文档文件或 HTML 文件）不能存储在字符串或 Unicode 列中，因为这些文件中的许多字节包含不构成有效字符的数据结构。数据库应用程序可能仍需要访问这些数据并对其应用全文检索。因为 image 列并不要求每一字节都构成一个有效字符，所以许多站点将这类数据存储在 image 列中。SQL Server 2000 引入了对存储在 image 列中的这些类型的数据执行全文检索的能力。SQL Server 2000 提供筛选，可从 Microsoft Office™ 文件（.doc、.xls 和 .ppt 文件）、文本文件（.txt 文件）及 HTML 文件（.htm 文件）中析取文本化数据。设计表时除包括保存数据的 image 列外，还需包括绑定列来保存存储在 image 列中的数据格式的文件扩展名。可以创建引用 image 列和绑定列的全文索引，以便在存储于 image 列中的文本化信息上启用全文检索。SQL Server 2000 全文检索引擎使用绑定列中的文件扩展名信息，选择从列中析取文本化数据的合适的筛选。

全文索引是用于执行两个 Transact-SQL 谓词的组件，以便根据全文检索条件对行进行测试：

  • CONTAINS

  • FREETEXT

Transact-SQL 还包含两个返回符合全文检索条件的行集的函数：

  • CONTAINSTABLE

  • FREETEXTTABLE

SQL Server 在内部将搜索条件发送给 Microsoft 搜索服务。Microsoft 搜索服务查找所有符合全文检索条件的键并将它们返回给 SQL Server。SQL Server 随后使用键的列表来确定表中要处理的行。

请参见

全文索引

全文查询构架

对 SQL Server 数据进行全文查询

Microsoft 搜索服务


登录、用户、角色和组

登录、用户、角色和组是 Microsoft® SQL Server™ 2000 安全机制的基础。连接到 SQL Server 的用户必须使用特定的登录标识符 (ID) 标识自己。因此，用户只能查看经授权可以查看的表和视图，并且只能执行经授权可以执行的存储过程和管理功能。这一安全系统基于用来标识用户的 ID。

请参见

安全管理


登录

用户在连接到 Microsoft® SQL Server® 2000 时与登录标识符 (ID) 相关联。登录 ID 是控制访问 SQL Server 系统的帐户。若不先指定有效登录 ID，用户就不能连接到 SQL Server。sysadmin 固定服务器角色成员定义登录 ID。

sp_grantlogin 使用 Windows 身份验证授予 Microsoft Windows® 网络帐户（组帐户或用户帐户）作为连接到 SQL Server 的 SQL Server 登录。sp_addlogin 则使用 SQL Server 身份验证为 SQL Server 连接定义登录帐户。

请参见

登录

sp_addlogin

sp_grantlogin


用户

用户标识符 (ID) 在数据库内标识用户。在数据库内，对象的全部权限和所有权由用户帐户控制。用户帐户与数据库相关。sales 数据库中的 xyz 用户帐户不同于 inventory 数据库中的 xyz 用户帐户，即使这两个帐户有相同的 ID。用户 ID 由 db_owner 固定数据库角色成员定义。

登录 ID 本身并不提供访问数据库对象的用户权限。一个登录 ID 必须与每个数据库中的一个用户 ID 相关联后，用这个登录 ID 连接的人才能访问数据库中的对象。如果登录 ID 没有与数据库中的任何用户 ID 显式关联，就与 guest 用户 ID 相关联。如果数据库没有 guest 用户帐户，则该登录就不能访问该数据库，除非它已与一个有效的用户帐户相关联。

用户 ID 在定义时便与一个登录 ID 相关联。例如，db_owner 角色成员可以使 Microsoft® Windows® 2000 登录 NETDOMAIN\Joe 与 sales 数据库中的用户 ID abc 和 employee 数据库中的用户 ID def 相关联。默认情况下，登录 ID 和用户 ID 相同。

下例说明给 Windows 2000 帐户授予对数据库的访问权限，并使该登录与数据库中的用户相关联：

USE master
GO
sp_grantlogin 'NETDOMAIN\Sue'
GO
sp_defaultdb @loginame = 'NETDOMAIN\Sue', defdb = 'sales'
GO
USE sales
GO
sp_grantdbaccess 'NETDOMAIN\Sue', 'Sue'
GO

在 sp_grantlogin 语句中，授予 Windows 2000 用户 NETDOMAIN\Sue 访问 Microsoft SQL Server™ 2000 的权限。sp_defaultdb 语句使 sales 数据库成为该用户的默认数据库。sp_grantdbaccess 语句给 NETDOMAIN\Sue 登录提供了访问 sales 数据库的权限，并将其在 sales 内的用户 ID 设置成 Sue。

下例说明定义 SQL Server 登录，指派默认数据库，并使该登录与数据库中的用户相关联：

USE master
GO
sp_addlogin @loginame = 'TempWorker', @password = 'fff', defdb = 'sales'
GO
USE sales
GO
sp_grantdbaccess 'TempWorker'
GO

sp_addlogin 语句定义了一个供各种临时工作人员使用的 SQL Server 登录。该语句还将 sales 数据库指定为此登录的默认数据库。sp_grantdbaccess 语句给 TempWorker 登录授予了对 sales 数据库的访问权限，由于没有指定用户名，默认为 TempWorker。

数据库中的用户由用户 ID 而非登录 ID 标识。例如，在每个数据库中，sa 是映射到特殊用户帐户 dbo（数据库所有者）的登录帐户。所有与安全有关的 Transact-SQL 语句都将该用户 ID 作为 security_name 参数使用。如果 sysadmin 固定服务器角色成员和 db_owner 固定数据库角色成员对系统进行设置，使每个用户的登录 ID 和用户 ID 都相同，就不容易混淆权限的管理和理解，但不必非这样做。

在 SQL Server 数据库中，guest 帐户是特殊的用户帐户。如果用户使用 USE database 语句访问的数据库中没有与此用户关联的帐户，此用户就与 guest 用户相关联。

请参见

guest 用户

sp_addlogin

sp_defaultdb

sp_grantdbaccess

sp_grantlogin


角色

角色是一个强大的工具，使您得以将用户集中到一个单元中，然后对该单元应用权限。对一个角色授予、拒绝或废除的权限也适用于该角色的任何成员。可以建立一个角色来代表单位中一类工作人员所执行的工作，然后给这个角色授予适当的权限。当工作人员开始工作时，只须将他们添加为该角色成员，当他们离开工作时，将他们从该角色中删除。而不必在每个人接受或离开工作时，反复授予、拒绝和废除其权限。权限在用户成为角色成员时自动生效。

Microsoft® Windows NT® 和 Windows® 2000 组的使用方式与角色很相似。有关更多信息，请参见组。

如果根据工作职能定义了一系列角色，并给每个角色指派了适合这项工作的权限，则很容易在数据库中管理这些权限。之后，不用管理各个用户的权限，而只须在角色之间移动用户即可。如果工作职能发生改变，则只须更改一次角色的权限，并使更改自动应用于角色的所有成员，操作比较容易。

在 Microsoft® SQL Server™ 2000 和 SQL Server 7.0 版中，用户可属于多个角色。

以下脚本说明登录、用户和角色的添加，并为角色授予权限。

USE master
GO
sp_grantlogin 'NETDOMAIN\John'
GO
sp_defaultdb 'NETDOMAIN\John', 'courses'
GO
sp_grantlogin 'NETDOMAIN\Sarah'
GO
sp_defaultdb 'NETDOMAIN\Sarah', 'courses'
GO
sp_grantlogin 'NETDOMAIN\Betty'
GO
sp_defaultdb 'NETDOMAIN\Betty', 'courses'
GO
sp_grantlogin 'NETDOMAIN\Ralph'
GO
sp_defaultdb 'NETDOMAIN\Ralph', 'courses'
GO
sp_grantlogin 'NETDOMAIN\Diane'
GO
sp_defaultdb 'NETDOMAIN\Diane', 'courses'
GO
USE courses
GO
sp_grantdbaccess 'NETDOMAIN\John'
GO
sp_grantdbaccess 'NETDOMAIN\Sarah'
GO
sp_grantdbaccess 'NETDOMAIN\Betty'
GO
sp_grantdbaccess 'NETDOMAIN\Ralph'
GO
sp_grantdbaccess 'NETDOMAIN\Diane'
GO
sp_addrole 'Professor'
GO
sp_addrole 'Student'
GO
sp_addrolemember 'Professor', 'NETDOMAIN\John'
GO
sp_addrolemember 'Professor', 'NETDOMAIN\Sarah'
GO
sp_addrolemember 'Professor', 'NETDOMAIN\Diane'
GO
sp_addrolemember 'Student', 'NETDOMAIN\Betty'
GO
sp_addrolemember 'Student', 'NETDOMAIN\Ralph'
GO
sp_addrolemember 'Student', 'NETDOMAIN\Diane'
GO
GRANT SELECT ON StudentGradeView TO Student
GO
GRANT SELECT, UPDATE ON ProfessorGradeView TO Professor
GO

该脚本给 John 和 Sarah 教授提供了更新学生成绩的权限，而学生 Betty 和 Ralph 只能选择他们自己的成绩。Diane 因同时教两个班，所以添加到两个角色中。ProfessorGradeView 视图应将教授限制在自己班学生的行上，而 StudentGradeView 应限制学生只能选择自己的成绩。

SQL Server 2000 和 SQL Server 7.0 版在安装过程中定义几个固定角色。可以在这些角色中添加用户以获得相关的管理权限。下面是服务器范围内的角色。

固定服务器角色 | 描述
sysadmin | 可以在 SQL Server 中执行任何活动。
serveradmin | 可以设置服务器范围的配置选项，关闭服务器。
setupadmin | 可以管理链接服务器和启动过程。
securityadmin | 可以管理登录和 CREATE DATABASE 权限，还可以读取错误日志和更改密码。
processadmin | 可以管理在 SQL Server 中运行的进程。
dbcreator | 可以创建、更改和除去数据库。
diskadmin | 可以管理磁盘文件。
bulkadmin | 可以执行 BULK INSERT 语句。

可以从 sp_helpsrvrole 获得固定服务器角色的列表，可以从 sp_srvrolepermission 获得每个角色的特定权限。

每个数据库都有一系列固定数据库角色。虽然每个数据库中都存在名称相同的角色，但各个角色的作用域只是在特定的数据库内。例如，如果 Database1 和 Database2 中都有叫 UserX 的用户 ID，将 Database1 中的 UserX 添加到 Database1 的 db_owner 固定数据库角色中，对 Database2 中的 UserX 是否是 Database2 的 db_owner 角色成员没有任何影响。

固定数据库角色 | 描述
db_owner | 在数据库中有全部权限。
db_accessadmin | 可以添加或删除用户 ID。
db_securityadmin | 可以管理全部权限、对象所有权、角色和角色成员资格。
db_ddladmin | 可以发出 ALL DDL，但不能发出 GRANT、REVOKE 或 DENY 语句。
db_backupoperator | 可以发出 DBCC、CHECKPOINT 和 BACKUP 语句。
db_datareader | 可以选择数据库内任何用户表中的所有数据。
db_datawriter | 可以更改数据库内任何用户表中的所有数据。
db_denydatareader | 不能选择数据库内任何用户表中的任何数据。
db_denydatawriter | 不能更改数据库内任何用户表中的任何数据。

可以从 sp_helpdbfixedrole 获得固定数据库角色的列表，可以从 sp_dbfixedrolepermission 获得每个角色的特定权限。

数据库中的每个用户都属于 public 数据库角色。如果想让数据库中的每个用户都能有某个特定的权限，则将该权限指派给 public 角色。如果没有给用户专门授予对某个对象的权限，他们就使用指派给 public 角色的权限。

请参见

将成员添加到预定义角色中

sp_dbfixedrolepermission

sp_helpdbfixedrole

sp_helpsrvrole

sp_srvrolepermission


登录、用户、角色和组

SQL Server 构架

组

Microsoft® SQL Server™ 2000 或 SQL Server 7.0 版中没有组。然而，可以在整个 Microsoft Windows NT® 或 Microsoft Windows® 2000 组的级别上管理 SQL Server 安全性。

如果使用 sp_grantlogin 并给 Windows NT 或 Windows 2000 组指定了名称，该组中的所有成员都可以使用 Windows 身份验证连接到 SQL Server。

在授予该组建立连接后，可以使用 sp_grantdbaccess 将该组中的成员与他们需要访问的每个数据库中的一个用户标识符 (ID) 相关联。可以使用两种方法：

  • 将该组与数据库中的一个用户 ID 相关联。

    在这种情况下，该组的所有成员都将在引用数据库时与那个用户 ID 相关联。

  • 将 Windows NT 或 Windows 2000 组中的个别用户帐户与数据库中的某个用户 ID 相关联。

    这个用户帐户在引用数据库时将与那个用户 ID 相关联。组中没有任何其它帐户会与那个用户 ID 相关联，它们将指派给与该组登录相关联的用户 ID。

假设有一个 Windows NT 或 Windows 2000 组 NETDOMAIN\Managers，它包含三个成员：NETDOMAIN\Sue、NETDOMAIN\Fred 和 NETDOMAIN\Mary。下列 Transact-SQL 语句将 Windows NT 或 Windows 2000 组同时作为登录和用户添加到 sales 数据库中，然后将 NETDOMAIN\Sue 与一个特定的用户 ID 相关联：

USE master
GO
-- Authorize all members of NETDOMAIN\Managers to connect
-- using Windows Authentication.
sp_grantlogin 'NETDOMAIN\Managers'
GO
-- Make sales the default database for all members.
sp_dbdefault 'NETDOMAIN\Managers', 'sales'
USE sales
GO
-- Grant all members of the group access to sales
-- No user ID is specified, so SQL Server creates
-- one named 'NETDOMAIN\Managers'
sp_grantdbaccess 'NETDOMAIN\Managers'
GO
-- Grant a specific member of the group access to
-- sales with a specific user.
sp_grantdbaccess 'NETDOMAIN\Sue', 'Sue'

现在可以给用户 NETDOMAIN\Managers 或用户 Sue 授予权限：

USE sales
GO
GRANT SELECT ON SalesTable TO NETDOMAIN\Managers
GO
GRANT UPDATE ON SalesTable to NETDOMAIN\Sue

适用于 NETDOMAIN\Sue 的权限是对用户 NETDOMAIN\Managers 或用户 Sue 授予、废除或拒绝的权限的并集。任何 DENY 权限替代任何相应的 GRANT 权限。

除非 Windows NT 或 Windows 2000 帐户已与特定的用户相关联，否则组成员受限于指派给该组所关联用户的权限。不过，如果组成员创建了对象，对象的所有者名称就是它们的 Windows NT 或 Windows 2000 帐户名，而不是组名。考察 NETDOMAIN\Manager 帐户。如果 NETDOMAIN\Fred 连接到 sales 数据库，他就能看见所有已给 NETDOMAIN\Managers 授予了 SELECT 权限的表。如果 NETDOMAIN\Fred 执行下列语句，表就创建成 sales.NETDOMAIN\Fred.TableX，而不是 sales.NETDOMAIN\Managers.TableX：

CREATE TableX (cola INT PRIMARY KEY, colb CHARACTER(200))

请参见

sp_grantdbaccess

sp_grantlogin


所有者和权限

Microsoft® SQL Server™ 2000 中的每个对象都由用户所有。所有者由数据库用户标识符 (ID) 标识。当第一次创建对象时，可以访问该对象的唯一用户 ID 是所有者或创建者的用户 ID。对于任何其他想访问该对象的用户，所有者必须给该用户授予权限。如果所有者只想让特定的用户访问该对象，可以只给这些特定的用户授予权限。

对于表和视图，所有者可以授予 INSERT、UPDATE、DELETE、SELECT 和 REFERENCES 权限，或授予 ALL 权限。用户必须对表有 INSERT、UPDATE、DELETE 或 SELECT 权限，才能在 INSERT、UPDATE、DELETE 或 SELECT 语句中指定该表。REFERENCES 权限使得另一个表的所有者可以对您表中的列应用他们表中的 REFERENCES FOREIGN KEY 约束。下例说明给一个名为 Teachers 的组授予 SELECT 权限以及给另一个开发用户授予 REFERENCES 权限：

GRANT SELECT ON MyTable TO Teachers
GRANT REFERENCES (PrimaryKeyCol) ON MyTable to DevUser1

存储过程的所有者可以授予该存储过程的 EXECUTE 权限。如果基表的所有者不想让用户直接访问基表，则可以对引用基表的视图或存储过程授予权限，而不对基表本身授予任何权限。这是 SQL Server 机制的基础，以确保用户看不到没有授权他们访问的数据。

还可以给用户授予语句权限。CREATE TABLE 和 CREATE VIEW 等语句只能由某些用户（此处为 dbo 用户）执行。如果 dbo 用户想让另一个用户能够创建表或视图，则必须给那个用户授予执行这些语句的权限。


会话上下文信息

Microsoft® SQL Server™ 2000 引入了编程能力，可将最多 128 字节的二进制信息与当前会话或连接关联起来。会话上下文信息使应用程序得以设置二进制值，以便在同一会话或连接上运行的多个批处理、存储过程、触发器或用户定义函数中加以引用。可使用新的 SET CONTEXT_INFO 语句设置会话上下文，然后从 master.dbo.sysprocesses 表的新 context_info 列中检索上下文字符串。

会话上下文信息不同于 Transact-SQL 变量，后者的作用域局限于当前的批处理、存储过程、触发器或函数。而会话上下文信息可用于存储每个用户或应用程序当前状态所特有的信息，这些信息随后可用于控制 Transact-SQL 语句中的逻辑。

SET CONTEXT_INFO 语句支持：

  • 最多 128 字节的常量，可以是二进制或是可隐性转换为二进制的数据类型。

  • varbinary(128) 或 binary(128) 变量的名称。

不能在用户定义函数中指定 SET CONTEXT_INFO。因为用来存储信息的 sysprocesses 表不允许空值，所以不能给 SET CONTEXT_INFO 提供空值。

若要获得当前连接的当前会话上下文，请从 SQL Server 进程 ID (SPID) 与连接 SPID 相等的 master.dbo.sysprocesses 行中选择 context_info 列。当前连接的 SPID 由 @@SPID 函数返回：

SELECT context_info
FROM master.dbo.sysprocesses
WHERE spid = @@SPID

如果还没有对当前连接执行 SET CONTEXT_INFO，则 context_info 列中的值将初始化为 128 字节的二进制零。如果已执行 SET CONTEXT_INFO，context_info 列将包含由当前连接最后执行的 SET CONTEXT_INFO 设置的值。context_info 列是 varbinary(128) 列。

以下是使用会话上下文信息的示例：

-- Set context information at start.
SET CONTEXT_INFO 0x1256698456
GO
-- Perform several non-related batches.
sp_who
GO
USE Northwind
GO
SELECT CustomerID
FROM Customers
WHERE City = 'London'
GO
-- Select context information set several batches earlier.
SELECT context_info
FROM master.dbo.sysprocesses
WHERE spid = @@spid
GO

SET CONTEXT_INFO 不支持引用常量或变量名以外的表达式，如函数。如果需要将上下文信息设置为函数调用结果，必须先在 binary 或 varbinary 变量中放置函数调用结果：

DECLARE @BinVar varbinary(128)
SET @BinVar = CAST( REPLICATE( 0x20, 128 ) AS varbinary(128) )
SET CONTEXT_INFO @BinVar

请参见

SET CONTEXT_INFO

sysprocesses


系统数据库和数据

Microsoft® SQL Server™ 2000 系统有四种系统数据库：

  • master 数据库

    master 数据库记录 SQL Server 系统的所有系统级别信息。它记录所有的登录帐户和系统配置设置。master 数据库是这样一个数据库，它记录所有其它的数据库，其中包括数据库文件的位置。master 数据库记录 SQL Server 的初始化信息，它始终有一个可用的最新 master 数据库备份。

  • tempdb 数据库

    tempdb 数据库保存所有的临时表和临时存储过程。它还满足任何其它的临时存储要求，例如存储 SQL Server 生成的工作表。tempdb 数据库是全局资源，所有连接到系统的用户的临时表和存储过程都存储在该数据库中。tempdb 数据库在 SQL Server 每次启动时都重新创建，因此该数据库在系统启动时总是干净的。临时表和存储过程在连接断开时自动除去，而且当系统关闭后将没有任何连接处于活动状态，因此 tempdb 数据库中没有任何内容会从 SQL Server 的一个会话保存到另一个会话。

    默认情况下，在 SQL Server 在运行时 tempdb 数据库会根据需要自动增长。不过，与其它数据库不同，每次启动数据库引擎时，它会重置为其初始大小。如果为 tempdb 数据库定义的大小较小，则每次重新启动 SQL Server时，将tempdb 数据库的大小自动增加到支持工作负荷所需的大小这一工作可能会成为系统处理负荷的一部分。为避免这种开销，可以使用 ALTER DATABASE 增加 tempdb 数据库的大小。

  • model 数据库

    model 数据库用作在系统上创建的所有数据库的模板。当发出 CREATE DATABASE 语句时，新数据库的第一部分通过复制 model 数据库中的内容创建，剩余部分由空页填充。由于 SQL Server 每次启动时都要创建 tempdb 数据库，model 数据库必须一直存在于 SQL Server 系统中。

  • msdb 数据库

    msdb 数据库供 SQL Server 代理程序调度警报和作业以及记录操作员时使用。

在 SQL Server 2000 和 SQL Server 7.0 版中，包括系统数据库在内的每个数据库都有自己的文件集，而且不与其它数据库共享这些文件。

数据库文件 | 物理文件名 | 默认大小，典型安装
master 主数据 | Master.mdf | 11,0 MB
master 日志 | Mastlog.ldf | 1,25 MB
tempdb 主数据 | Tempdb.mdf | 8,0 MB
tempdb 日志 | Templog.ldf | ,5 MB
model 主数据 | Model.mdf | ,75 MB
model 日志 | Modellog.ldf | ,75 MB
msdb 主数据 | Msdbdata.mdf | 12,0 MB
msdb 日志 | Msdblog.ldf | 2,25 MB

对于不同版本的 SQL Server 2000，这些文件的大小可能略有不同。有关这些文件的默认位置的更多信息，请参见定位目录和文件。

SQL Server 2000 中的每个数据库都包含系统表，用来记录 SQL Server 组件所需的数据。SQL Server 的操作能否成功，取决于系统表信息的完整性，因此 Microsoft 不支持用户直接更新系统表中的信息。

Microsoft 提供了一套完整的管理工具，使用户得以充分管理他们的系统和数据库中的所有用户和对象。用户可以使用管理实用工具（如 SQL Server 企业管理器）直接管理系统。程序员可以使用 SQL-DMO API，在他们的应用程序中加入完整的 SQL Server 管理功能。程序员在生成 Transact-SQL 脚本和存储过程时，可以使用系统存储过程和 Transact-SQL DDL 语句来支持系统中的所有管理功能。

SQL-DMO、系统存储过程和数据定义语言 (DDL) 语句的一个重要功能是，防止应用程序在系统表中发生更改。Microsoft 有时需要更改 SQL Server 新版本中的系统表，以支持在那个版本中新增的功能。但应用程序在发出直接引用系统表的 SELECT 语句时，常常依赖于原来的系统表格式。站点在重写从系统表中选择的应用程序之前，不能升级到 SQL Server 的新版本。Microsoft 考虑了系统存储过程、DDL 和 SQL-DMO 发布的接口，力求保持这些接口的向后兼容性。

Microsoft 不支持对系统表定义触发器，触发器会更改系统的操作。

另外一个查询 SQL Server 目录的重要工具是信息架构视图集。这些视图遵从 SQL-92 标准中定义的信息架构。这些视图为应用程序提供了一个用于查询 SQL Server 目录的基于标准的组件。

不应编写直接查询系统表的 Transact-SQL 语句，除非这是获得应用程序所需信息的唯一方法。大多数情况下，应用程序应通过下列方式获取目录和系统信息：

  • SQL-92 信息架构视图。

  • SQL-DMO。

  • 应用程序中使用的数据 API（如 ADO、OLE DB 或 ODBC）的目录函数、方法、特性或属性。

  • Transact-SQL 系统存储过程、目录语句和内置函数。


物理数据库构架

本部分的主题描述 Microsoft® SQL Server™ 2000 文件和数据库的组织方式。SQL Server 2000 和 SQL Server 7.0 版的结构不同于 SQL Server 6.5 版或更早版本中的数据结构。


页和扩展盘区

在 Microsoft® SQL Server™ 中，数据存储的基本单位是页。在 SQL Server 2000 中，页的大小是 8 KB。这意味着 SQL Server 2000 数据库每兆字节有 128 页。

每页的开始部分是 96 字节的页首，用于存储系统信息，如页的类型、页的可用空间量、拥有页的对象的对象 ID 等。

下表显示 SQL Server 2000 数据库的数据文件中的八种页类型。

页类型 | 内容
数据 | 包含数据行中除 text、ntext 和 image 数据外的所有数据。
索引 | 索引项。
文本/图像 | text、ntext 和 image 数据。
全局分配映射表、辅助全局分配映射表 | 有关已分配的扩展盘区的信息。
页的可用空间 | 有关页上可用空间的信息。
索引分配映射表 | 有关表或索引所使用的扩展盘区的信息。
大容量更改映射表 | 有关自上次执行 BACKUP LOG 语句后大容量操作所修改的扩展盘区的信息。
差异更改映射表 | 有关自上次执行 BACKUP DATABASE 语句后更改的扩展盘区的信息。

日志文件不包含页，而是包含一系列日志记录。

数据页包含数据行中除 text、ntext 和 image 数据外的所有数据，text、ntext 和 image 数据存储在单独的页中。在数据页上，数据行紧接着页首按顺序放置。在页尾有一个行偏移表。在行偏移表中，页上的每一行都有一个条目，每个条目记录那一行的第一个字节与页首的距离。行偏移表中的条目序列与页中行的序列相反。

在 SQL Server 中，行不能跨页。在 SQL Server 2000 中，一行内最多包含的数据量是 8060 字节，不包括 text、ntext 和 image 数据。

扩展盘区是一种基本单元，可将其中的空间分配给表和索引。一个扩展盘区是 8 个邻接的页（或 64 KB）。这意味着 SQL Server 2000 数据库每兆字节有 16 个扩展盘区。

为了使空间分配更有效，SQL Server 2000 对只含少量数据的表不分配完整的扩展盘区。SQL Server 2000 有两种类型的扩展盘区：

  • 统一扩展盘区由单个对象所有，扩展盘区中的所有八页只能由拥有该盘区的对象使用。

  • 混合扩展盘区最多可由 8 个对象共享。

通常从混合扩展盘区中向新表或新索引分配页。当表或索引增长到 8 页时，就变成统一扩展盘区。如果在现有表上创建索引，并且该表包含的行足以在索引中生成 8 页，则对该索引的所有分配都在统一扩展盘区内进行。


物理数据库文件和文件组

Microsoft® SQL Server™ 2000 将数据库映射到一组操作系统文件上。数据和日志信息绝不混合在同一个文件中，而且个别文件只由一个数据库使用。

SQL Server 2000 数据库有三种类型的文件：

  • 主要数据文件

    主要数据文件是数据库的起点，指向数据库中文件的其它部分。每个数据库都有一个主要数据文件。主要数据文件的推荐文件扩展名是 .mdf。

  • 次要数据文件

    次要数据文件包含除主要数据文件外的所有数据文件。有些数据库可能没有次要数据文件，而有些数据库则有多个次要数据文件。次要数据文件的推荐文件扩展名是 .ndf。

  • 日志文件

    日志文件包含恢复数据库所需的所有日志信息。每个数据库必须至少有一个日志文件，但可以不止一个。日志文件的推荐文件扩展名是 .ldf。

SQL Server 2000 不强制使用 .mdf、.ndf 和 .ldf 文件扩展名，但建议使用这些扩展名以帮助标识文件的用途。

在 SQL Server 2000 中，某个数据库中的所有文件的位置都记录在 master 数据库和该数据库的主文件中。大多数情况下，数据库引擎使用 master 数据库中的文件位置信息。不过对于某些操作，数据库引擎使用主文件中的文件位置信息初始化 master 数据库中的文件位置项：

  • 当使用 sp_attach_db 系统存储过程附加数据库时。

  • 当从 SQL Server 7.0 版升级到 SQL Server 2000 时。

  • 当还原 master 数据库时。

SQL Server 2000 文件有两个名称：

  • logical_file_name 是在所有 Transact-SQL 语句中引用文件时所使用的名称。

    逻辑文件名必须遵守 SQL Server 标识符规则，且对数据库必须是唯一的。

  • os_file_name 是物理文件名。

    物理文件名必须遵从 Microsoft Windows NT® 或 Microsoft Windows® 98 和 Microsoft Windows 95 的文件名规则。

下面是在 SQL Server 2000 默认实例上创建的数据库的逻辑文件名和物理文件名示例：

SQL Server 数据和日志文件可以放置在 FAT 或 NTFS 文件系统中，但不能放在压缩文件系统中。

在 SQL Server 2000 中，数据文件的页按顺序编号，文件首页的页码是 0。每个文件都有一个文件 ID 号。在数据库中唯一标识一页需要同时使用文件 ID 和页码。下例显示包含 4-MB 主要数据文件和 1-MB 次要数据文件的数据库中的页码。

在每个文件中，第一页是包含文件特性信息的文件的页首页。在文件开始处的其它几页也包含系统信息（如分配映射表）。系统页存储在主要数据文件和第一个日志文件中，其中有一个是包含数据库属性信息的数据库引导页。

SQL Server 2000 文件可以从它们最初指定的大小自动增长。定义文件时可以指定增量。每次填充文件时，均按这个增量值增加它的大小。如果在文件组中有多个文件，这些文件在全部填满之前不自动增长。填满后，这些文件使用循环算法进行增长。

还可以指定每个文件的最大大小。如果没有指定最大大小，文件可以一直增长到用完磁盘上的所有可用空间。如果 SQL Server 作为数据库嵌入应用程序，而该应用程序的用户无法迅速与系统管理员联系，此功能在这种情况下特别有用。用户可以让文件按需要自动增长，以减轻监视数据库中的可用空间量和手工分配额外空间的管理负担。

如果有多个 SQL Server 实例在单个计算机上运行，则每个实例获得不同的默认目录来存储该实例中创建的数据库文件。有关更多信息，请参见定位目录和文件。

数据库文件组

出于分配和管理目的，可以将数据库文件分成不同的文件组。一些系统可以通过控制在特定磁盘驱动器上放置的数据和索引来提高自身的性能。文件组可以对此进程提供帮助。系统管理员可以为每个磁盘驱动器创建文件组，然后将特定的表、索引、或表中的 text、ntext 或 image 数据指派给特定的文件组。

没有一个文件可以是一个以上文件组的成员。表、索引、以及 text、ntext 和 image 数据可以与文件组相关联，在这种情况下，它们的所有页都将分配在那个文件组中。

日志文件不能作为文件组的一部分。日志空间与数据空间分开管理。

文件组中的文件不自动增长，除非文件组中的文件全都没有可用空间。

有两种类型的文件组：

  • 主要文件组

    主文件组包含主要数据文件和任何没有明确指派给其它文件组的其它文件。系统表的所有页均分配在主文件组中。

  • 用户定义文件组

    用户定义文件组是在 CREATE DATABASE 或 ALTER DATABASE 语句中，使用 FILEGROUP 关键字指定的文件组。

每个数据库中都有一个文件组作为默认文件组运行。当 SQL Server 给创建时没有为其指定文件组的表或索引分配页时，将从默认文件组中进行分配。一次只能有一个文件组作为默认文件组。db_owner 固定数据库角色成员可以将默认文件组从一个文件组切换到另一个。如果没有指定默认文件组，则主文件组是默认文件组。

SQL Server 2000 在没有文件组时也能有效地工作，因此许多系统不需要指定用户定义文件组。在这种情况下，所有文件都包含在主文件组中，而且 SQL Server 2000 可以在数据库内的任何位置分配数据。文件组不是在多个驱动器之间分配 I/O 的唯一方法。

db_owner 固定数据库角色成员可以备份和还原个别的文件或文件组，而不用备份或还原整个数据库。

下例在 SQL Server 2000 的默认实例上创建数据库。该数据库包括一个主要数据文件、一个用户定义的文件组和一个日志文件。主要数据文件在主文件组中，而用户定义文件组有两个次要数据文件。ALTER DATABASE 语句将用户定义文件组指定为默认文件组。之后，通过指定用户定义的文件组来创建表。

USE master
GO
-- Create the database with the default data
-- filegroup and the log file. Specify the
-- growth increment and the max size for the
-- primary data file.
CREATE DATABASE MyDB
ON PRIMARY
  ( NAME='MyDB_Primary',
   FILE NAME=
      'c:\Program Files\Microsoft SQL Server\MSSQL\data\MyDB_Prm.mdf',
   SIZE=4,
   MAXSIZE=10,
   FILEGROWTH=1),
FILEGROUP MyDB_FG1
  ( NAME = 'MyDB_FG1_Dat1',
   FILE NAME =
      'c:\Program Files\Microsoft SQL Server\MSSQL\data\MyDB_FG1_1.ndf',
   SIZE = 1MB,
   MAXSIZE=10,
   FILEGROWTH=1),
  ( NAME = 'MyDB_FG1_Dat2',
   FILE NAME =
      'c:\Program Files\Microsoft SQL Server\MSSQL\data\MyDB_FG1_2.ndf',
   SIZE = 1MB,
   MAXSIZE=10,
   FILEGROWTH=1)
LOG ON
  ( NAME='MyDB_log',
   FILE NAME =
      'c:\Program Files\Microsoft SQL Server\MSSQL\data\MyDB.ldf',
   SIZE=1,
   MAXSIZE=10,
   FILEGROWTH=1)
GO
ALTER DATABASE MyDB
MODIFY FILEGROUP MyDB_FG1 DEFAULT
GO

-- Create a table in the user-defined filegroup.
USE MyDB
CREATE TABLE MyTable
  ( cola      int   PRIMARY KEY,
   colb      char(8) )
ON MyDB_FG1
GO

可以将用户文件组设成只读，数据不能更改，但可以修改目录以执行权限管理等工作。

SQL Server 2000 数据库可以从服务器中分离出来，然后重新连接到另一台服务器或原来的服务器上。这对制作要分发的、以便用于在客户的本地 SQL Server 安装上使用的数据库特别有用。例如，公司可以创建包含其当前产品目录的数据库。公司可以在可写的光盘驱动器上创建这个数据库，并将它设成只读。然后，他们可以复制这张光盘，给那些在 Windows 95 便携式电脑上安装了目录应用程序和 SQL Server 的地区销售代表发送复本。这样一来，销售代表就有了最新的产品目录信息。


空间分配和重新使用

Microsoft® SQL Server™ 2000 在给对象快速分配页和重新使用删除行所释放的空间上很有效。这些操作是系统的内部操作，用户看不见它们所使用的数据结构，不过 SQL Server 消息中偶尔会引用这些进程和结构。本主题简要介绍空间分配算法和数据结构，为用户和管理员提供相关知识，以便他们了解 SQL Server 生成的消息中所引用的术语。


管理扩展盘区分配和可用空间

跟踪可用空间的 Microsoft® SQL Server™ 2000 数据结构相对来讲具有简单结构。这有两个好处：

  • 可用空间信息被紧密压缩，因此包含这些信息的页相对较少。

    这种方式通过减少检索分配信息所需的磁盘读取量，增加分配页保留在内存中的机会消除可能出现的更多的读取，达到提高速度的目的。

  • 大多数的分配信息不链接在一起，从而简化了对分配信息的维护。

    可以快速执行每个页的分配或释放，以减少需要分配页或释放页的并发任务之间的争夺。

SQL Server 使用两种类型的分配映射表来记录扩展盘区的分配：

  • 全局分配映射表 (GAM)

    GAM 页记录已分配的扩展盘区。每个 GAM 包含 64,000 个扩展盘区，将近 4 GB 的数据。GAM 对所涵盖区间内的每个扩展盘区都有一位。如果这个位是 1，则扩展盘区可用；如果这个位是 0，则扩展盘区已分配。

  • 共享全局分配映射表 (SGAM)

    SGAM 页记录特定的扩展盘区，这些盘区当前用作混合扩展盘区而且至少有一个未使用的页。每个 SGAM 包含 64,000 个扩展盘区，将近 4 GB 的数据。SGAM 对所涵盖区间内的每个扩展盘区都有一位。如果这个位是 1，则该扩展盘区就用作混合扩展盘区且有可用的页；如果这个位是 0，则该扩展盘区不用作混合扩展盘区，或者虽然用作混合扩展盘区但其所有页都正在使用中。

根据扩展盘区的当前使用情况，每个扩展盘区在 GAM 和 SGAM 中有以下位模式设置。

扩展盘区的当前使用情况 | GAM 位设置 | SGAM 位设置
可用，未使用 | 1 | 0
统一扩展盘区或已满的混合扩展盘区 | 0 | 0
有可用页的混合扩展盘区 | 0 | 1

这简化了扩展盘区管理算法。若要分配统一扩展盘区，SQL Server 在 GAM 中搜索是 1 的位，然后将它设成 0。若要查找有可用页的混合扩展盘区，SQL Server 在 SGAM 中搜索是 1 的位。若要分配混合扩展盘区，SQL Server 在 GAM 中搜索是 1 的位，并将它设置为 0，然后将 SGAM 中相应的位也设置为 1。若要释放扩展盘区，SQL Server 应确保 GAM 位设置为 1 而且 SGAM 位设置为 0。SQL Server 内部实际使用的算法比这里叙述的算法要复杂（SQL Server 在数据库中均匀分布数据），但由于无须管理扩展盘区分配信息链，所以即使是真正的算法也简化了。

页可用空间 (PFS) 页记录堆集中的个别页或 ntext、text 或 image 列是否已分配，以及每页的可用空间的数量。每个 PFS 页包含大约 8,000 页。PFS 对每一页都有一个相应的位图，该位图记录这一页是空的、1-50% 已满、51-80% 已满、81-95% 已满还是 96-100% 已满。

给对象分配了扩展盘区后，SQL Server 使用 PFS 页记录扩展盘区的哪些页已分配或可用，以及有多少可用的剩余空间。当 SQL Server 需要分配新页，或者需要找到有可用空间的页来容纳新插入的行时，就使用这些信息。

在数据文件中，PFS 页是文件的页首页之后的第一页（页码是 1）。接下来的一页是 GAM（页码是 2），再接下来是 SGAM（页码是 3）。第一个 PFS 页之后是一个有大约 8,000 页的 PFS 页。在第二页上，第一个 GAM 之后是另一个有 64,000 个扩展盘区的 GAM；在第三页上，第一个 SGAM 之后是另一个有 64,000 个扩展盘区的 SGAM。


管理对象使用的空间

索引分配映射表 (IAM) 页映射数据库文件中由堆集或索引使用的扩展盘区。对于任何具有 ntext、text 和 image 类型的列的表，IAM 页还映射分配给这些类型的页链的扩展盘区。这些对象中的每一个都有由一个或多个记录所有分配给自己的扩展盘区的 IAM 页组成的链。每个对象对每个包含扩展盘区的文件都至少有一个 IAM。如果分配给对象的文件上的扩展盘区的范围超过了一个 IAM 页可以记录的范围，则扩展盘区可能会在文件上有多个 IAM 页。

IAM 页按需要分配给每个对象，并在文件内随机定位。Sysindexes.dbo.FirstIAM 指向对象的 IAM 首页，这个对象的所有IAM 页用链条链接在一起。

IAM 页的页首说明 IAM 所映射的扩展盘区范围的起始扩展盘区。IAM 中还有大位图，该位图内的每个位代表一个扩展盘区。位图的第一个位代表范围内的第一个扩展盘区，第二个位代表范围内的第二个扩展盘区，依此类推。如果一个位是 0，则不将它代表的扩展盘区分配给拥有该 IAM 的对象。如果这个位是 1，则将它代表的扩展盘区分配给拥有该 IAM 页的对象。

当 Microsoft® SQL Server™ 2000 需要插入新行而当前页没有可用空间时，它使用 IAM 和 PFS 页查找具有足够空间容纳该行的页。SQL Server 使用 IAM 页查找分配给对象的扩展盘区。对于每个扩展盘区，SQL Server 搜索 PFS 页以查看是否有一页具有足够的空间容纳这一行。每个 IAM 和 PFS 页涵盖大量数据页，因此一个数据库内只有很少的 IAM 和 PFS 页。这意味着 IAM 和 PFS 页一般在 SQL Server 缓冲池的内存中，所以能很快找到它们。

SQL Server 只有当无法在现有的扩展盘区内快速找到一页有足够空间容纳正插入的行时，才给对象分配新的扩展盘区。SQL Server 使用按比例分配算法，从文件组内的可用扩展盘区中分配扩展盘区。如果一个文件组有两个文件，其中一个的可用空间是另一个的两倍，那么每从后者分配一页，就从前者分配两页。这意味着文件组内的每个文件应该有近似的空间使用百分比。


跟踪修改的扩展盘区

SQL Server 2000 引入了两种新的内部数据结构，用以跟踪大容量复制操作所修改的扩展盘区或自上次完整备份后所修改的扩展盘区。如果数据库使用的是有日志记录的大容量恢复模式，这些新的数据结构将大大加快差异备份和有日志记录的大容量复制操作的速度。与全局分配映射表 (GAM) 和辅助全局分配映射表 (SGAM) 页一样，这些新结构是位图，其中的每一位代表一个扩展盘区。

  • 差异更改映射表 (DCM)

    跟踪自上次执行 BACKUP DATABASE 语句后更改的扩展盘区。如果扩展盘区的位是 1，则自上次执行 BACKUP DATABASE 语句后扩展盘区已被修改。如果位是 0，则扩展盘区没有被修改。

    现在差异备份只需读取 DCM 页即可找出已被修改的扩展盘区。这样大大减少了差异备份必须扫描的页数。现在，运行差异备份所需的时间与自上次执行 BACKUP DATABASE 语句之后修改的扩展盘区数成比例，而不是与整个数据库的大小成比例。

  • 大容量更改映射表 (BCM)

    跟踪自上次执行 BACKUP LOG 语句后，有日志记录的大容量复制操作所修改的扩展盘区。如果某个扩展盘区的位是 1，表明自上次执行 BACKUP LOG 语句后，该扩展盘区已经被有日志记录的大容量复制操作修改。如果位是 0，则该扩展盘区未被有日志记录的大容量复制操作修改。

    仅当数据库使用的是大容量日志记录恢复模式时，BCM 页才是相关的。在此恢复模式中，当执行 BACKUP LOG 时，备份进程扫描 BCM 以查找已修改的扩展盘区并将这些扩展盘区记入日志备份中。如果数据库从数据库备份和一系列事务日志备份恢复，这使得可以恢复有日志记录的大容量复制操作。在使用简单恢复模式的数据库中，BCM 页是不相关的，因为有日志记录的大容量复制操作不记入日志。在使用完全恢复模式的数据库中，BCM 页也是不相关的，因为该恢复模式将有日志记录的大容量复制操作视为有完整记录的操作。

DCM 页与 BCM 页的间隔同 GAM 与 SGAM 页的间隔相同，都是 64,000 个扩展盘区。在物理文件中，DCM 和 BCM 页位于 GAM 和 SGAM 页之后：

请参见

管理扩展盘区分配和可用空间


收缩数据库

SQL Server 2000 自动收缩有大量可用空间的数据库。该进程仅适用于那些 autoshrink 选项设置为 true 的数据库。服务器定期检查每个数据库中的空间使用情况。如果发现数据库中有大量闲置空间，而且它的 autoshrink 选项设置为 true，SQL Server 就缩小该数据库中的文件大小。也可以使用 SQL Server 企业管理器或 DBCC SHRINKDATABASE 和 DBCC SHRINKFILE 语句，手工收缩数据库中的文件。

文件始终从末端开始收缩。例如，如果有个 5 GB 的文件并将 DBCC SHRINKDB 语句中的 target_size 指定为 4GB，则 SQL Server 将从文件的最后一个 1 GB 开始释放尽可能多的空间。如果文件中被释放的部分包含使用过的页，则 SQL Server 首先将这些页重新定位到保留的部分。只能将数据库收缩到没有剩余的可用空间为止。例如，某个 5GB 的数据库有 4 GB 的数据并且 DBCC SHRINKDATABASE 语句的 target_size 被指定为 3 GB，则只释放 1 GB。

如果 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 语句无法收回日志文件中的所有空间，该语句将发出信息，指示必须执行什么操作以释放更多符合条件的空间。有关收缩日志文件的更多信息，请参见收缩事务日志。


表和索引构架

在 Microsoft® SQL Server ™ 2000 数据库内，对象作为 8 KB 页的集合存储。本主题描述表和索引页的组织方式。

SQL Server 2000 支持视图上的索引。视图上第一个允许的索引是聚集索引。在视图上执行 CREATE INDEX 语句时，视图的结果集被具体化，并且存储在与有聚集索引的表具有相同结构的数据库中。存储的结果集与下面的语句所产生的结果集相同：

SELECT * FROM ViewName

每个表或索引视图的数据行存储在 8 KB 数据页集合中。每个数据页都有一个 96 字节的页头，其中包含象拥有该页的表的标识符 (ID) 这样的系统信息。如果页链接在列表中，则页头还包含指向下一页及前面用过的页的指针。在页尾有行偏移表。数据行填充页的剩余部分。

数据页的组织方式

SQL Server 2000 中的表使用下面两种方法组织其数据页。

  • 聚集表是有聚集索引的表。

    基于聚集索引键按顺序存储数据行。索引按 B 树索引结构实现，B 树索引结构支持基于聚集索引键值对行进行快速检索。每级索引中的页（包括叶级中的数据页）链接在双向链接列表中，但使用键值在各级间导航。

  • 堆集是没有聚集索引的表。

    不按任何特殊顺序存储数据行，数据页序列也没有任何特殊顺序。数据页不在链表内链接。

索引视图与聚集索引表具有相同的存储结构。

SQL Server 在每个表或索引视图上还支持多达 249 个非聚集索引。非聚集索引有一个与聚集索引中相似的 B 树索引结构。不同的是非聚集索引对数据行的顺序不起作用。聚集索引表和索引视图基于聚集索引键按顺序存储数据行。如果为表定义了非聚集索引，对堆集的数据页集合没有影响。除非定义了聚集索引，否则数据页保留在堆集内。

包含 text、ntext 和 image 数据的页作为每个表的单个单元进行管理。一个表的所有 text、ntext 和 image 数据存储在一个页集合内。

sysindexes 表内的页指针定位表、索引和索引视图的所有页集合。每个表和索引视图有一个数据页集合，以及其它一些实现为这个表或视图定义的各个索引的页集合。

每个表、索引和索引视图在 sysindexes 内有一行，由对象标识符 (id) 列和索引标识符 (indid) 列的组合唯一标识。IAM 页链管理分配给表、索引和索引视图的页。sysindexes.FirstIAM 列指向 IAM 页链的 IAM 首页，IAM 页链管理分配给表、索引或索引视图的空间。

每个表在 sysindexes 内有一个行集：

  • 一个堆集在 sysindexes 内有一行，其 indid = 0。

    FirstIAM 列指向表的数据页集合的 IAM 链。服务器使用 IAM 页查找数据页集合内的页，因为这些页不链接在一起。

  • 某个表或视图上的一个聚集索引在 sysindexes 内有一行，其 indid = 1。

    root 列指向聚集索引 B 树的顶端。服务器使用索引 B 树查找数据页。

  • 为某个表或视图创建的每个非聚集索引在 sysindexes 内有一行。

    每个非聚集索引的行内的 indid 值都从 2 到 250。root 列指向非聚集索引 B 树的顶端。

  • 对于每个至少有一个 text、ntext 或 image 列的表，在 sysindexes 内也有一行，其 indid = 255。

    FirstIAM 列指向管理 text、ntext 和 image 页的 IAM 页链。

在 SQL Server 6.5 版及更早的版本中，sysindexes.first 始终指向堆集的起点、索引叶级的起点或者 text 和 image 页链的起点。在 SQL Server 7.0 版及更高的版本中，很少使用 sysindexes.first。在 SQL Server 6.5 版及更早的版本中，indid = 0 这行内的 sysindexes.root 指向堆集的最后一页。在 SQL Server 7.0 版及更高的版本中，不使用 indid = 0 这行内的 sysindexes.root。


分发内容统计

所有索引都有分发内容统计，用以描述索引内键值的选择性和分发内容。选择性是一种与一般由键值标识的行数有关的属性。唯一键的选择性高；而可在 1000 行内找到的键值的选择性低。选择性和分发内容统计由 Microsoft® SQL Server™ 2000 用来在处理 Transact-SQL 语句时通过表和索引视图优化它的浏览。分发内容统计用于评估索引检索与键值或查询指定的范围相关联的数据的效率。每个索引的统计并不仅限于单个页，而是与存储 image 数据一样，作为一长串位存储在多个页上。sysindexes.statblob 列指向这些分发内容数据。可以使用 DBCC SHOW_STATISTICS 语句得到关于索引的分发内容统计的报表。

也可以维护无索引列的分发内容统计。可以用 CREATE STATISTICS 语句手工定义，或者使用查询优化器自动创建。无索引列上的统计将对非聚集索引进行计数，检查其是否超过一个表最多允许的 249 个非聚集索引。

为有利于查询优化器的性能，必须将分发内容统计保持在适当的当前状态。每当索引键发生大量更改，都应刷新分发内容统计。可以使用 UPDATE STATISTICS 语句手工更新分发内容统计。SQL Server 2000 还可以检测分发内容统计何时过期并自动更新它。由检测到统计需要更新的任务执行更新过程。使用一种复杂的采样方法执行更新，该方法可将更新对事务吞吐量的影响减到最小。

请参见

统计信息


堆集结构

堆集在 sysindexes 内有一行，其 indid = 0。sysindexes.FirstIAM 列指向 IAM 页链的 IAM 首页，IAM 页链管理分配给堆集的空间。Microsoft® SQL Server™ 2000 使用 IAM 页在堆集中浏览。堆集内的数据页和行没有任何特定的顺序，也不链接在一起。数据页之间唯一的逻辑连接是记录在 IAM 页内的连接。

通过扫描 IAM 页可以对堆集进行表扫描或串行读，以找到容纳这个堆集的页的扩展盘区。因为 IAM 按扩展盘区在数据文件内存在的顺序表示它们，所以这意味着串行堆集扫描一律沿每个文件进行。这要比沿 SQL Server 早期版本中使用的数据页链进行扫描效率高，在早期版本中，数据页链常常通过有点随机的路径扫描数据库文件。使用 IAM 页设置扫描顺序还意味着堆集中的行一般不按照插入的顺序返回。


聚集索引

聚集索引在 sysindexes 内有一行，其 indid = 1。数据链内的页和其内的行按聚集索引键值排序。所有插入都在所插入行中的键值与排序顺序相匹配时执行。

Microsoft® SQL Server™ 2000 将索引组织为 B 树。索引内的每一页包含一个页首，页首后面跟着索引行。每个索引行都包含一个键值以及一个指向较低级页或数据行的指针。索引的每个页称为索引节点。B 树的顶端节点称为根节点。索引的底层节点称为叶节点。每级索引中的页链接在双向链接列表中。在聚集索引内数据页组成叶节点。根和叶之间的任何索引级统称为中间级。

对于聚集索引，sysindexes.root 指向它的顶端。SQL Server 沿着聚集索引浏览以找到聚集索引键对应的行。为找到键的范围，SQL Server 浏览索引以找到这个范围的起始键值，然后用向前或向后指针扫描数据页。为找到数据页链的首页，SQL Server 从索引的根节点开始沿最左边的指针进行扫描。

下图说明聚集索引的结构。


非聚集索引

非聚集索引与聚集索引一样有 B 树结构，但是有两个重大差别：

  • 数据行不按非聚集索引键的顺序排序和存储。

  • 非聚集索引的叶层不包含数据页。

    相反，叶节点包含索引行。每个索引行包含非聚集键值以及一个或多个行定位器，这些行定位器指向有该键值的数据行（如果索引不唯一，则可能是多行）。

非聚集索引可以在有聚集索引的表、堆集或索引视图上定义。在 Microsoft® SQL Server™ 2000 中，非聚集索引中的行定位器有两种形式：

  • 如果表是堆集（没有聚集索引），行定位器就是指向行的指针。该指针用文件标识符 (ID)、页码和页上的行数生成。整个指针称为行 ID。

  • 如果表没有聚集索引，或者索引在索引视图上，则行定位器就是行的聚集索引键。如果聚集索引不是唯一的索引，SQL Server 2000 将添加在内部生成的值以使重复的键唯一。用户看不到这个值，它用于使非聚集索引内的键唯一。SQL Server 通过使用聚集索引键搜索聚集索引来检索数据行，而聚集索引键存储在非聚集索引的叶行内。

由于非聚集索引将聚集索引键作为其行指针存储，因此使聚集索引键尽可能小很重要。如果表还有非聚集索引，请不要选择大的列作为聚集索引的键。


tempdb 和索引创建

创建索引时可以指定 WITH SORT_IN_TEMPDB 选项，该选项指示数据引擎使用 tempdb 存储用于生成索引的中间排序结果。虽然该选项会增加用于创建索引的磁盘空间量，但是当 tempdb 与用户数据库位于不同的磁盘集上时，该选项可减少创建索引所需的时间。

数据库引擎在生成索引时经历下面两个阶段：

  • 首先，数据库引擎扫描数据页以检索键值，并为每个数据行生成索引叶行。当内部排序缓冲区被叶索引项填满时，这些项被排序并作为中间排序进程写入磁盘。然后，数据库引擎继续扫描数据页，直到排序缓冲区再次被填满。这种先扫描多个数据页，然后排序并写入排序进程的模式继续进行，直到处理完基表中的所有行。在聚集索引中，索引的叶行是表的数据行，因此中间排序进程包含所有的数据行。在非聚集索引中，叶行不包含非键列的值，因此通常较小。然而，如果索引键很大，则非聚集的排序进程也可能很大。

  • 数据库引擎将排序的索引叶行进程合并为单个的排序流。引擎的排序合并组件从每个排序进程的第一页开始，在所有的页中找出最小的键，并将那个叶行传递到索引创建组件。然后处理下一个最小的键，随后再处理下一个，依此类推。当将最后一个叶索引行从排序进程页中析取出来时，该进程从此排序进程切换到下一页。当处理完某个排序进程扩展盘区中的所有页时，释放该扩展盘区。每个叶索引行在传递到索引创建组件时，均被放置在缓冲区的叶索引页中。每个叶页在填充时被写入。当写入叶页时，数据库引擎还会生成该索引的上级。每个上级索引页在填充时被写入。

如果在已经有非聚集索引的表上创建聚集索引，一般过程是：

  • 重新分配非聚集索引，但保留索引的定义。空间直到包含 CREATE INDEX 语句的事务结束时才可用，因而，如果在事务回滚期间必须恢复旧索引页，则这些旧索引页仍是可用的。

  • 创建聚集索引。

  • 重新创建非聚集索引。

如果未指定 SORT_IN_TEMPDB，则排序进程将存储在目的文件组中。在创建索引的第一阶段，基表页的交替读取和排序进程的写入使读写磁头从磁盘的一个区域移动到另一个区域。当扫描数据页时，磁头位于数据页区域。当填充排序缓冲区并且当前的排序进程必须写入磁盘时，读写磁头移动到某个可用空间区域，然后当继续扫描表页时移回数据页区域。在第二阶段，读写磁头的移动频率较高。这时，排序进程一般正在从各排序进程区域交替读取。目的文件组中将生成排序进程和新的索引页，这意味着数据库引擎在各排序进程间分布读取的同时，还必须定期跳到索引扩展盘区，以便在填充索引页时写入新的索引页。

如果指定了 SORT_IN_TEMPDB 选项并且 tempdb 与目的文件组位于不同的磁盘集上，那么在第一阶段，对数据页的读取与对 tempdb 中排序工作区的写入会发生在不同的磁盘上。这意味着对数据键的磁盘读取在整个磁盘上会趋于更加连续，并且对 tempdb 磁盘的写入也趋于连续，正如生成最终索引时的写入操作一样。即使其他用户正在使用数据库并且正在访问不同的磁盘地址，指定 SORT_IN_TEMPDB 选项时的总体读写模式的效率也比没有指定时要高。

SORT_IN_TEMPDB 选项可能会提高索引扩展盘区的邻接，尤其当不是并行处理 CREATE INDEX 时。排序工作区扩展盘区在数据库中的释放位置方面有些随机。如果排序工作区包含在目的文件组中，则释放排序工作区扩展盘区时，可通过请求来获取它们，以使扩展盘区在生成时容纳索引结构。这在某种程度上使索引扩展盘区的位置随机化。如果在 tempdb 中单独容纳排序扩展盘区，则它们的释放顺序与索引扩展盘区的位置无关。另外，当中间排序进程存储在 tempdb 中而不是目的文件组中时，目的文件组中将有更多的可用空间，从而增加了索引扩展盘区邻接的机会。

SORT_IN_TEMPDB 选项只影响当前的语句。没有任何元数据记录索引是否存储在 tempdb 中。例如，如果使用 SORT_IN_TEMPDB 选项创建了某个非聚集索引，后来在没有指定该选项的情况下创建了某个聚集索引，则当数据库引擎重新创建那个非聚集索引时，将不使用该选项。

可用空间要求

如果指定了 SORT_IN_TEMPDB 选项，则 tempdb 中必须有足够的可用空间容纳中间排序进程，而且目的文件组中必须有足够的可用空间容纳新的索引。如果没有足够的可用空间，并且由于某种原因数据库不能自动增长以获得更多的空间（如磁盘上没有剩余空间或关闭了自动增长功能），CREATE INDEX 语句将失败。

如果没有指定 SORT_IN_TEMPDB，目的文件组中的可用空间必须大约等于最终索引的大小。在第一阶段，生成排序进程并要求可用空间量大约等于最终索引的大小。在第二阶段，处理每个排序进程扩展盘区后将其释放。这意味着释放排序进程扩展盘区的速度与获取扩展盘区以容纳最终索引页的速度差不多相同，因此总的空间要求并没有显著超过最终索引的大小。这样的一个副作用就是如果可用空间量非常接近最终索引的大小，则数据库引擎倾向于在排序进程扩展盘区释放后立即重新使用它们。因为排序进程扩展盘区的释放方式有些随机，所以在这种情形中将降低索引扩展盘区的连续性。如果没有指定 SORT_IN_TEMPDB，那么如果目的文件组中有足够的可用空间，则可以从邻接的池而不是从刚刚重新分配的排序进程扩展盘区分配索引扩展盘区，这将提高索引扩展盘区的连续性。

执行 CREATE INDEX 语句时，必须有足够的可用空间：

  • 创建非聚集索引时：
    • 如果指定了 SORT_IN_TEMPDB，则 tempdb 中必须有足够的可用空间存储排序进程，而且目的文件组中必须有足够的可用空间存储最终索引结构。排序进程包含索引的叶行。

    • 如果没有指定 SORT_IN_TEMPDB，目的文件组中必须有足够的可用空间存储最终索引结构。如果有更多的可用空间，则可以提高索引扩展盘区的连续性。
  • 在没有非聚集索引的表上创建聚集索引时：
    • 如果指定了 SORT_IN_TEMPDB，则 tempdb 中必须有足够的可用空间存储排序进程，包括表的数据行。目的文件组中必须有足够的可用空间存储最终的索引结构，包括表的数据行和索引 B 树。粗略的估计值是原始表大小的 1.2 倍，但可能需要根据不同的因素调整估计值，如键的大小很大或填充因子的值很低。

    • 如果没有指定 SORT_IN_TEMPDB，则目的文件组中必须有足够的可用空间存储最终表，包括索引结构。如果有更多的可用空间，则可以提高表和索引扩展盘区的连续性。
  • 在有非聚集索引的表上创建聚集索引时：
    • 如果指定了 SORT_IN_TEMPDB，则 tempdb 中必须有足够的可用空间存储最大索引（一般为聚集索引）的排序进程集合，而且目的文件组中必须有足够的空间存储所有索引的最终结构，包括表的数据行所在的聚集索引。

    • 如果没有指定 SORT_IN_TEMPDB，则目的文件组中必须有足够的可用空间存储最终表，包括所有索引结构。如果有更多的可用空间，则可以提高表和索引扩展盘区的连续性。

请参见

CREATE INDEX


text、ntext 和 image 数据

各个 text、ntext 和 image 值最大为 2 GB，否则将太长以致不能存储在单个数据行中。在 Microsoft® SQL Server™ 2000 中，小的 text、ntext 或 image 值可以直接存储在行中，由于太大而不能存放在行中的值则存储在页集合内，该页集合与容纳行的其它列的数据的页分开存储。

管理员使用 sp_tableoption 中的 text in row 选项，指定小的 text、ntext 或 image 值是否直接存储在行中：

  • 当 text in row 是 OFF 时，SQL Server 2000 的 ntext、text 和 image 行为与 SQL Server 7.0 版相同。对于每个 text、ntext 或 image 值，存储在数据行内的所有内容是一个 16 字节的指针。对于每一行，该指针指向 text、ntext 或 image 数据的位置。包含多个 text、ntext 或 image 列的行对每个 text、ntext或 image 列均有一个指针。

  • 当 text in row 是 ON 时，SQL Server 2000 在数据行中存储小的 text、ntext 和 image 值。只有不能存储在行中的 text、ntext 或 image 值存储在单独的页集合中。

每个表只有一个保存 text、ntext 和 image 数据的页集合。indid = 255 的 sysindexes 行是这个集合的定位点。表内所有行的 text、ntext 和 image 数据交叉存取在这个 text 和 image 页集合内。

在 SQL Server 2000 中，各个 text、ntext 和 image 页不局限于只包含 text、ntext 或 image 列的一个事件的数据。一个 text、ntext 或 image 页能包含多行数据，甚至能包含 text、ntext 和 image 数据的混合。

虽然用户总是将 text、ntext 和 image 数据当作单个长字节字符串来使用，但这类数据并不按那种格式存储。这类数据存储在 8 KB 页的集合内，而这些页不一定相邻。在 SQL Server 2000 中按 B 树结构逻辑地组织页，而在SQL Server 6.5 版及更早的版本中是在页链内将页链接在一起。SQL Server 2000 使用的这种方法的优点在于：从字符串的中间开始操作效率更高。SQL Server 2000 可以在 B 树中快速浏览，而 SQL Server 6.5 版必须在页链中扫描。

请参见

sp_tableoption


text in row 设置为 OFF 时的 text、ntext 和 image 数据

如果 sp_tableoption 的 text in row 选项设置为 OFF，数据少于 32 KB 与多于 32 KB 时用于存储 text、ntext 或 image 数据的 B 树结构略有不同。

如果数据量少于 32 KB，数据行的 16 字节文本指针就指向 84 字节的文本根结构。这形成 B 树结构的根节点。根节点指向 text、ntext 或 image 数据块。

虽然 text、ntext 和 image 列的数据在 B 树内按逻辑排列，但根节点和各数据块却分布在整个表的 text、ntext 和 image 页链内。根节点和各个数据块放置在任何可用的空间内。每个数据块的大小由应用程序写定的大小决定。小数据块组合在一起填充一页。如果数据量少于 64 字节，则全都存储在根结构中。

例如，如果应用程序先写入一个 1 KB 的 image 数据，则该数据作为行的第一个 1 KB 的 image 数据块存储。如果应用程序随后写入一个 12 KB 的 image 数据，则将 7 KB 和刚才的 1 KB 的块组合在一起，这样第一个块就是 8 KB。剩下的 5 KB 形成第二个 image 数据块。（每个 text、ntext 或 image 页的实际容量是 8080 字节的数据。）

因为 text、ntext 或 image 数据块以及根结构都可以在相同的 text、ntext 或 image 页上共享空间，所以在 SQL Server 7.0 中，text、ntext 或 image 数据使用的空间比以前的 SQL Server 版本少。例如，如果在 text 列中插入 20 行，每行有 200 字节的数据，那么这些数据和所有根结构都可以放在同一个 8 KB 页中。

如果 text、ntext 或 image 列的一个事件的数据量超过 32 KB，则 SQL Server 开始在数据块和根节点之间生成中间节点。

在整个 text、ntext 或 image 页内，用前面介绍的相同方式交叉存取根结构和数据块。然而，中间节点存储于不在 text、ntext 或 image 列事件之间共享的页内。存储中间节点的页仅包含一个数据行内的一个 ntext、text 或 image 数据值的中间节点。

请参见

sp_tableoption


text in row 设置为 ON 时的 text、ntext 和 image 数据

通过使用 sp_tableoption，为某个表启用 text in row 选项。当 text in row 选项设置为 ON 时，在下列情况下，Microsoft® SQL Server™ 2000 直接将 text、ntext 或 image 字符串存储在数据行中：

  • 字符串的长度比指定的长度限制短。

  • 数据行中有足够的可用空间容纳字符串。

当 text、ntext 或 image 串被存储在数据行时，SQL Server 就无须访问单独的页或页的集合来读写这些串。这使得读写 text、ntext 或 image 这些行中的串就象读写 varchar、nvarchar 或 varbinary 串一样快。

如果 text、ntext 或 image 字符串的长度比 text in row 选项的限制或行中的可用空间长，则本应存储在指针树根节点中的指针集将存储在行中。若将根节点移动到行本身，则在 SQL Server 每次引用字符串值时不用访问页，从而加快处理速度。

放置在数据行中的完整根结构需要用 72 个字节来容纳五个指针。如果 text in row 选项的限制少于 72 字节，或行中的可用字节少于 72，则 SQL Server 将在行中放入尽可能多的指针。最低限制是 24 字节，可容纳只有一个指针的根节点。

减少根结构中的指针数将截断用于存储 text、ntext 或 image 字符串的树结构的顶层。例如，如果根结构中只有三个指针，则树结构的顶层可能只包含三个节点，而不是五个。减小根结构的大小会在树结构中引入额外的层。将 text in row 选项的限制设置在 72 以下还可能导致截断顶层。

当 text、ntext 或 image 字符串存储在行中时，它们的存储类似于长度可变的字符串。例如，如果 text in row 选项的限制为 500 字节，则在行中存储一个 200 字节的字符串时，SQL Server 将只使用存储该字符串所需的字节数。如果插入的字符串比 500 字节长，以致指针存储在行中，则 SQL Server 只使用足够容纳指针的空间，而不是全部 500 字节。

如果某个表有多个 text、ntext 或 image 列，则当尝试插入多个 text、ntext 或 image 字符串时，SQL Server 将按基于列 ID 的顺序给这些字符串逐个分配空间。例如，假设有一个包含四个 text 列的表，并且将 text in row 选项的限制设置为 1000。然后插入某行，该行中每个 text 列为 900 字节的字符串，并且有足够的数据用于表中的所有其它列，因此在行中只有 3,000 字节的可用空间容纳 text 字符串。前三个 text 列的字符串存储在行中，使用 3,000 可用字节中的 2,700 字节。第四个 text 列的字符串不存储在行中，但根节点的指针存储在行中。

将 text in row 选项设置为 On 对处理 text、ntext 或 image 数据将造成负面影响。有关更多信息，请参见管理 ntext、text 和 image 数据。

请参见

sp_tableoption


事务日志构架

每个 Microsoft® SQL Server™ 2000 数据库都有事务日志，用以记录所有事务和每个事务对数据库所做的修改。记录事务及其修改有三个作用：

  • 恢复个别的事务。

    如果应用程序发出 ROLLBACK 语句，或者 SQL Server 检测到错误（例如失去与客户端的通讯），就使用日志记录回滚未完成的事务所做的修改。

  • SQL Server 启动时恢复所有未完成的事务。

    当运行 SQL Server 的服务器发生故障时，数据库可能处于这样的状态：还没有将修改从高速缓冲存储器写入数据文件，在数据文件内有未完成的事务所做的修改。当启动 SQL Server 的复本时，它对每个数据库执行恢复操作。前滚日志中记录的、可能尚未写入数据文件的每个修改。然后回滚在事务日志中找到的每个未完成的事务，以确保数据库的完整性。

  • 将还原的数据库前滚到故障点。

    丢失数据库（在没有 RAID 驱动器的服务器上，硬盘驱动器出现故障时可能会出现这种情况）后，可以将数据库还原到故障点。首先还原上一次的完整数据库备份或差异数据库备份，然后将事务日志备份序列还原到故障点。当还原每个日志备份时，SQL Server 重新应用日志中记录的所有修改以前滚所有事务。当最后的日志备份还原后，SQL Server 将使用日志信息回滚到该点未完成的所有事务。

SQL Server 2000 事务日志的特点是：

  • 事务日志不是作为一个表实现，而是作为单独的文件或数据库内的一组文件实现。日志高速缓存与数据页的高速缓冲存储器分开管理，从而使数据库引擎内的编码更简单、更快速和更可靠。

  • 日志记录和页的格式不必遵守数据页的格式。

  • 事务日志可以在几个文件上实现。可以根据需要定义这些文件为自动增长。这样可减少事务日志内空间不足的可能性，同时减少管理开销。

  • 截断日志中未用部分的机制速度快且对事务吞吐量影响最小。


预写事务日志

Microsoft® SQL Server™ 2000 与许多关系数据库一样使用预写日志。预写日志确保在相关的日志记录之后才将数据修改写入磁盘。

SQL Server 维护一个高速缓冲存储器，当必须检索数据时，它将数据页读入这个存储器。不是直接在磁盘上进行数据修改，而是修改高速缓冲存储器内的数据页复本。直到对数据库执行检查点或必须将修改写入磁盘以便用缓冲区来容纳新页时，才能将修改写入磁盘。将修改的数据页从高速缓冲存储器写入磁盘称为刷新页。已在高速缓存内修改但尚未写入磁盘的页称为脏页。

在缓存区内对一页进行修改时，在记录修改的日志高速缓存内生成日志记录。在将关联的脏页从高速缓存刷新到磁盘之前，必须将这条日志记录写入磁盘。如果在日志记录前刷新了脏页，脏页会在磁盘上创建一条修改，如果服务器在日志记录写入磁盘之前发生故障，就不能回滚这条修改。SQL Server 有一个逻辑可防止在关联的日志记录之前刷新脏页。由于日志记录始终在关联的数据页之前写入，因此日志称为预写日志。

请参见

备份/还原构架

事务构架


事务日志逻辑构架

Microsoft® SQL Server™ 2000 事务日志按逻辑运行，就好象是一串连续的日志记录一样。每条日志记录由一个日志序号 (LSN) 标识。每条新日志记录用一个比以前记录的 LSN 更高的 LSN 写入日志的逻辑末端。

数据修改的日志记录或者记录所执行的逻辑操作，或者记录已修改数据的前像和后像。前像是操作执行前的数据复本；后像是操作执行后的数据复本。操作的恢复步骤取决于日志记录的类型：

  • 记录的逻辑操作：
    • 若要前滚逻辑操作，请再次执行它。

    • 若要回滚逻辑操作，请执行相反的逻辑操作。
  • 记录的前像和后像：
    • 若要前滚操作，请应用后像。

    • 若要回滚操作，请应用前像。

事务日志内记录许多类型的操作，包括：

  • 每个事务的起点和终点。

  • 每次数据修改（插入、更新或删除）。这包括系统存储过程或数据定义语言 (DDL) 语句对系统表所做的更改。

  • 每次分配或释放扩展盘区。

  • 表或索引的创建或除去。

日志记录按创建时的串行序列存储。每条日志记录由所属的事务的 ID 标记。对于每个事务，使用可提高事务回滚速度的向后指针，在链内单向链接与事务相关联的所有日志记录。

回滚语句也将记入日志。每个事务都在事务日志上保留空间，以确保在遇到错误时有足够的日志空间支持回滚操作。当事务完成后，将释放该保留空间。保留的空间量取决于在事务中执行的操作，但通常等于用于记录每项操作的空间量。


检查点和日志的活动部分

检查点最大限度地减少数据库完全恢复时所必须执行的日志部分。在完全恢复时，必须执行两种操作：

  • 日志可以包含修改记录，这些修改在系统停止前还没有刷新到磁盘上。必须前滚这些修改。

  • 必须回滚与未完成的事务（没有 COMMIT 或 ROLLBACK 日志记录的事务）相关联的所有修改。

检查点从当前数据库的高速缓冲存储器中刷新脏数据和日志页，以尽量减少在恢复时必须前滚的修改量。

SQL Server 2000 检查点在当前数据库内执行下列进程：

  • 将标记检查点起点的记录写入日志文件。

  • 将为检查点记录的信息存储在检查点日志记录链内。将这条链起点的 LSN 写入数据库根页。

  • 记录在检查点记录中的一条信息是第一个日志映像的 LSN，该映像必须存在以保证成功的数据库范围的回滚。这个 LSN 称为最小恢复 LSN (MinLSN)，它是下面这些 LSN 中的最小 LSN：
    • 检查点起点的 LSN。

    • 最旧的活动事务起点的 LSN。

    • 最早的复制事务起点的 LSN，该事务尚未复制到所有订阅服务器。
  • 记录在检查点记录中的另一条信息是所有未完成的活动事务的列表。

  • 如果数据库使用的是简单恢复模式，则删除新的 MinLSN 之前的所有日志记录。

  • 将所有脏日志和数据页写入磁盘。

  • 将标记检查点末端的记录写入日志文件。

从 MinLSN 到日志末端的日志文件部分称为日志的活动部分。这是进行数据库完全恢复所需的日志部分。永远不能截断活动日志的任何部分。所有的日志截断都必须从 MinLSN 之前的日志部分进行。

这是有两个活动事务的事务日志末端的简化版本。检查点记录已压缩成单个记录。

LSN 148 是事务日志内的最后一条记录。在执行处理 LSN 147 时所记录的检查点时，Tran 1 已经提交而且 Tran 2 是唯一的活动事务。这就使 Tran 2 的第一条日志记录成为最后一个检查点上的活动事务的最旧日志记录。这使 LSN 142（Tran 2 的开始事务记录）成为 MinLSN。

检查点在下列情况下发生：

  • 当执行 CHECKPOINT 语句时。对连接所使用的当前数据库执行检查点操作。

  • 当使用 ALTER DATABASE 更改数据库选项时。当数据库选项被更改时，ALTER DATABASE 对数据库执行检查点操作。

  • 当 SQL Server 实例由于以下原因停止运行时：
    • 执行 SHUTDOWN 语句。

    • 使用 SQL Server 服务控制管理器阻止运行数据库引擎实例的服务。

    上述方法之一对 SQL Server 实例中的每个数据库执行检查点操作。

  • 当 SQL Server 实例为减少恢复数据库所需的时间而在每个数据库内定期生成自动检查点时。
自动检查点

SQL Server 2000 始终生成自动检查点。自动检查点的时间间隔基于日志内的记录数而非时间。自动检查点的时间间隔可能有很大的变化。如果数据库只做了很少的修改，自动检查点的时间间隔就长。如果修改了大量数据，自动检查点将经常发生。

根据 recovery interval 服务器配置选项计算自动检查点的时间间隔。该选项指定 SQL Server 在系统重新启动时恢复数据库所用的最长时间。SQL Server 在执行恢复操作时估计自己能在恢复间歇内处理多少日志记录。自动检查点之间的间歇还取决于数据库使用的是否是简单恢复模式。

  • 如果数据库使用的不是完全恢复模式或有日志记录的大容量恢复模式，则每当日志记录数达到 SQL Server 估计在 recovery interval 选项所指定的时间内能处理的记录数，就生成自动检查点。

  • 如果数据库使用的是简单恢复模式，则每当日志中的记录数达到下面两个值中较小的那个，就生成自动检查点：
    • 日志的 70% 已满。

    • 日志中的记录数达到 SQL Server 估计在 recovery interval 选项所指定的时间内能处理的记录数。

如果数据库使用的是简单恢复模式，则自动检查点截断事务日志中没有使用的部分。如果数据库使用的完全恢复模式或有日志记录的大容量恢复模式，则自动检查点不截断日志。有关更多信息，请参见截断事务日志。

长时间运行的事务

日志的活动部分必须包括所有未提交事务的每一部分。如果应用程序启动事务但不提交或回滚该事务，就会妨碍 SQL Server 前移 MinLSN。从而导致两种问题：

  • 如果系统在事务执行了许多未提交的修改后关闭，以后重新启动时，恢复阶段所用的时间将比 recovery interval 选项指定的时间长得多。

  • 因为不能截断 MinLSN 之后的日志部分，日志可能增长得非常大。这种情况即使在数据库使用的是简单恢复模式时也有可能发生，在简单恢复模式下，每次执行自动检查点操作时通常都截断事务日志。
复制事务

日志的活动部分还必须包含所有被标记为复制但尚未复制到订阅服务器的事务。如果这些事务不是以即时方式复制，则它们还可以防止截断日志。

请参见

备份/还原构架

CHECKPOINT

释放和写入缓冲区页

事务恢复


截断事务日志

如果从来没有从事务日志中删除日志记录，逻辑日志就会一直增长，直到填满容纳物理日志文件的磁盘上的所有可用空间。在某个即时点，必须删除恢复或还原数据库时不再需要的旧日志记录，以便为新日志记录腾出空间。删除这些日志记录以减小逻辑日志的大小的过程称为截断日志。

永远不能截断事务日志的活动部分。日志的活动部分是在任何时间恢复数据库所需的日志部分，因此必须有回滚所有未完成的事务所需的日志映像。这部分必须始终在数据库中，因为一旦服务器发生故障，在服务器重新启动时必须用它恢复数据库。日志活动部分起点处的记录由最小恢复日志序号 (MinLSN) 标识。

为数据库选择的恢复模式决定了在数据库内，必须在活动部分之前保留的事务日志量。虽然 MinLSN 之前的日志记录对恢复活动事务没有作用，但在使用日志备份将数据库还原到故障点时，必须用这些记录前滚修改。如果由于某种原因丢失了数据库，则可以通过还原上次的数据库备份，然后还原自该数据库备份后的每个日志备份来恢复数据。这意味着这些日志备份必须包含自数据库备份后所写入的每个日志记录。当维护事务日志备份序列时，日志记录直到写入日志备份时才能被截断。

MinLSN 之前的日志记录只用于维护事务日志备份序列。

  • 在简单恢复模式中，不维护事务日志序列。MinLSN 之前的所有日志记录可以随时被截断，但在处理 BACKUP 语句时除外。NO_LOG 和 TRUNCATE_ONLY 是只对使用简单恢复模式的数据库有效的 BACKUP LOG 选项。

说明 tempdb 数据库始终使用简单恢复模式，不能切换到其它恢复模式。日志截断始终发生在 tempdb 中的检查点上。

  • 在完全恢复模式和有日志记录的大容量恢复模式中，维护事务日志备份序列。MinLSN 之前的逻辑日志部分直到复制到某个日志备份时才能被截断。

日志截断在下列情况下发生：

  • 执行完 BACKUP LOG 语句时。

  • 在每次处理检查点时（如果数据库使用的是简单恢复模式）。这包括 CHECKPOINT 语句所产生的显式检查点和系统生成的隐式检查点。例外情况是如果检查点发生在 BACKUP 语句仍活动时，则不截断日志。有关自动检查点间隔的更多信息，请参见检查点和日志的活动部分。

事务日志在内部分成若干称为虚拟日志文件的部分。虚拟日志文件是截断的单元。当截断事务日志时，删除包含 MinLSN 的虚拟日志文件头之前的所有日志记录。有关虚拟日志文件的更多信息，请参见事务日志物理构架。

因此，按下面任一方式控制事务日志的大小：

  • 在维护日志备份序列时，调度 BACKUP LOG 语句按间隔发生，以使事务日志不致增长到超过预期的大小。

  • 当不维护日志备份序列时，指定简单恢复模式。

下图显示一个有四个虚拟日志的事务日志。创建数据库后没有截断过日志。逻辑日志从第一个虚拟日志的始端开始，而且从未使用过第四个虚拟日志中超过逻辑文件末端的部分。

下图说明日志截断后的样子。MinLSN 记录所在的虚拟日志始端之前的行被截断。

截断不减小物理日志文件的大小，但减小逻辑日志文件的大小。有关收缩物理日志文件大小的更多信息，请参见"收缩事务日志"。

请参见

BACKUP

设置数据库选项

事务日志备份

截断方法


事务日志物理构架

数据库内的事务日志映射在一个或多个物理文件上。日志文件在概念上是一串连续的日志记录。在物理上，日志记录序列必须有效地存储在实现事务日志的物理文件集内。

Microsoft® SQL Server™ 2000 在内部将每个物理日志文件分成许多虚拟日志文件。虚拟日志文件没有固定大小，且物理日志文件所包含的虚拟日志文件数不固定。在创建或扩展日志文件时，SQL Server 动态地选择虚拟日志文件的大小。SQL Server 尝试维护少量的虚拟文件。在日志文件扩展名后，根据现有日志的大小和新文件增量的大小确定虚拟文件的大小。虚拟日志文件的大小或数量不能由管理员配置或设置，而是由 SQL Server 代码动态确定。

只有当虚拟日志文件的 size 和 growth_increment 值较小时，它们才会影响系统的性能。如果这些日志文件经过多次按小增量值增长后变得很大，它们将有大量的虚拟日志文件，从而降低恢复的速度。建议使用接近最终所需大小的 size 值来定义日志文件，并将日志文件的 growth_increment 值设得相对大一些。

事务日志是回绕的日志文件。例如，假设有一个数据库，它包含一个分成四个虚拟日志文件的物理日志文件。当创建数据库时，逻辑日志文件从物理日志文件的始端开始。在逻辑日志的末端添加新的日志记录，逻辑日志就向物理日志末端增长。截断操作发生时，删除最小恢复日志序号（MinLSN）之前的虚拟日志内的记录。本示例数据库内的日志外观与下图所示相似。

当逻辑日志的末端到达物理日志文件的末端时，新的日志记录绕回物理日志文件的始端。

这个循环不断重复，只要逻辑日志的末端不到达逻辑日志的始端。如果经常截断旧的日志记录，使得总能为下一个检查点创建的所有新日志记录保留足够的空间，那么日志永远不会填满。然而，如果逻辑日志的末端真的到达了逻辑日志的始端，将发生下列两件事之一：

  • 如果对日志启用了自动增长且磁盘上有可用空间，文件就按 growth_increment 指定的数量扩展，新的日志记录则添加到扩展中。

  • 如果没有启用自动增长，或者保存日志文件的磁盘上的可用空间比 growth_increment 指定的数量少，则生成 1105 错误。

如果逻辑日志包含多个物理日志文件，则逻辑日志将沿着所有的物理日志文件移动，然后回绕到第一个物理日志文件的始端。

请参见

事务日志备份

事务日志


收缩事务日志

在下列情况下，日志文件的物理大小将减少：

  • 执行 DBCC SHRINKDATABASE 语句时。

  • 执行引用日志文件的 DBCC SHRINKFILE 语句时。

  • 自动收缩操作发生时。

日志收缩操作依赖于最初的日志截断操作。日志截断操作不减小物理日志文件的大小，但减小逻辑日志的大小，并将没有容纳逻辑日志任何部分的虚拟日志标记为不活动。日志收缩操作会删除足够多的不活动虚拟日志，将日志文件减小到要求的大小。

减小大小的单位是一个虚拟日志文件。例如，如果有个 600 MB 的日志文件被分成了 6 个 100 MB 的虚拟日志，则该日志文件的大小只能按 100 MB 递减。比如，文件可以减小到 500 MB 或 400 MB，但不能减小到 433 MB 或 525 MB。

不能释放容纳逻辑日志部分的虚拟日志。如果某个日志文件中的所有虚拟日志都容纳了逻辑日志部分，则不能收缩该文件，直到截断操作在物理日志的末端将一个或更多的虚拟日志标记为不活动。

当收缩任何文件时，必须从文件的末端开始释放空间。当收缩事务日志文件时，从文件的末端开始释放足够的虚拟日志以将日志减小到用户所要求的大小。用户指定的 target_size 四舍五入为下一个最大的虚拟日志边界大小。例如，如果用户为包含 6 个 100 MB 虚拟日志文件的 600 MB 文件指定 325 MB 的 target_size，则删除最后两个虚拟日志文件，因此新的文件大小为 400 MB。

在 SQL Server 2000 中，DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 操作试图立即将物理日志文件收缩到所要求的大小（以四舍五入的值为准）：

  • 如果虚拟日志中的逻辑日志部分没有超出 target_size 标记，则释放 target_size 标记之后的虚拟日志，并且成功完成 DBCC 语句，不出现任何信息。

  • 如果虚拟日志中的逻辑日志部分超出 target_size 标记，则 SQL Server 2000 释放尽可能多的空间并发出一条信息。该信息告诉您需要执行什么操作以获得文件末端超出虚拟日志的逻辑日志部分。执行完该操作后，可以重新发出 DBCC 语句以释放剩余的空间。

例如，当执行 target_size 为 275 MB 的 DBCC SHRINKFILE 语句时，假设有一个包含 6 个虚拟日志的 600 MB 日志文件，其逻辑日志从第 3 个虚拟日志开始，到第 4 个虚拟日志结束：

将立即释放第 5 个和第 6 个虚拟日志，因为它们没有容纳逻辑日志部分。然而，为达到指定的 target_size，还应释放第 4 个虚拟日志，但无法释放，因为它容纳了逻辑日志的末端部分。在释放第 5 个和第 6 个虚拟日志之后，SQL Server 2000 用虚记录填充第 4 个虚拟日志部分。这将日志文件的末端强制为第 1 个虚拟日志。在大多数系统中，起始于第 4 个虚拟日志的所有事务将在几秒钟内提交，这意味着日志的所有活动部分都移动到了第 1 个虚拟日志，并且日志文件现在看起来像下面这样：

DBCC SHRINKFILE 语句还发出一条信息，指出它不能释放所要求的全部空间，并告诉您可以执行 BACKUP LOG 语句以便释放剩余的空间。一旦日志的活动部分移动到第 1 个虚拟日志，BACKUP LOG 语句将截断第 4 个虚拟日志中的整个逻辑日志：

因为第 4 个虚拟日志不再容纳逻辑日志的任何部分，如果现在执行同一个 target_size 为 275 MB 的 DBCC SHRINKFILE 语句，则会释放第 4 个虚拟日志，并且物理日志文件的大小会减小到所要求的大小。

请参见

BACKUP

设置数据库选项

空间分配和重新使用

事务日志备份

截断事务日志


关系数据库引擎构架

服务器是 Microsoft® SQL Server™ 2000 的组件，接收来自客户端的 SQL 语句并执行完成这些语句所需的全部操作。本部分讨论：

  • 构成服务器的组件概述。

  • 服务器如何将每个批处理 SQL 语句编译为执行计划，以告诉服务器处理语句的方法。

  • 服务器如何管理 Microsoft Windows® 资源（如内存、线程和任务）。

  • 服务器如何确定分布式查询的哪一部分引用链接服务器，以及向服务器传输什么请求以获得所需的数据。

  • 服务器如何将远程存储过程调用传输给远程服务器。

  • 服务器如何管理并发问题和事务问题。

  • 服务器如何实现服务器游标。

  • 使 SQL Server 得以适应从小型膝上型电脑到为大企业提供主要数据存储的大型服务器的那些功能。

  • SQL 邮件组件如何将 SQL Server 与电子邮件服务器集成，以使服务器得以在指定的事件发生时发送电子邮件和寻呼。


关系数据库引擎构架概述

Microsoft® SQL Server 2000™ 服务器组件接收来自客户端的 SQL 语句并处理这些 SQL 语句。下图显示处理来自 SQL Server 客户端的 SQL 语句所涉及的主要组件。

表格格式数据流

客户端使用称为表格格式数据流 (TDS) 的 SQL Server 专用应用程序级协议来发送 SQL 语句。SQL Server 2000 接受 TDS 的下列版本：

  • 由运行来自 SQL Server 2000 的 SQL Server 客户端组件版的客户端发送的 TDS 8.0。TDS 8.0 客户端支持 SQL Server 2000 的所有功能。

  • 由运行来自 SQL Server 7.0 版的 SQL Server 客户端组件版的客户端发送的 TDS 7.0。TDS 4.2 客户端不支持 SQL Server 2000 中引入的功能，而且服务器有时必须调整发送回 TDS 7.0 客户端的数据。例如，TDS 7.0 客户端不支持 sql_variant 数据类型，因此 SQL Server 2000 必须将所有 sql_variant 数据都转换成 Unicode 数据类型。

  • 由从 SQL Server 6.5、6.0 和 4.21a 中运行 SQL Server 客户端组件的客户端所发送的 TDS 4.2。TDS 4.2 客户端不支持 SQL Server 2000 中引入的功能，也不支持 SQL Server 7.0 中引入的功能，而且服务器有时必须调整发送回 TDS 4.2 客户端的数据。例如，TDS 4.2 客户端不支持 Unicode 数据类型，因此在给客户端发送 Unicode 数据类型之前，SQL Server 2000 必须先将其转换成字符数据，这样做可能会丢失扩展字符。TDS 4.2 客户端还不支持比 255 个字节长的 char、varchar、binary 或 varbinary 值，因此在将任何超过 255 的值发送给客户端之前，SQL Server 2000 必须先将其截断。
服务器 Net-Library

TDS 数据包由用于 SQL Server 的 Microsoft OLE DB 提供程序、SQL Server ODBC 驱动程序或 DB-Library DLL 生成。TDS 数据包然后被传递给 SQL Server 客户端 Net-Library，客户端 Net-Library 将 TDS 数据包封装为网络协议数据包。在服务器上，服务器 Net-Library 接收网络协议数据包，且析取 TDS 数据包并将其传递给关系数据库服务器。

在将结果返回给客户端时，这一进程反向执行。

每台服务器都可以同时监听几个网络协议，并为其监听的每个协议各运行一个服务器 Net-Library。

关系数据库引擎

数据库服务器处理从服务器 Net-Library 传递来的所有请求。它将所有 SQL 语句编译为执行计划，然后使用这些计划访问请求的数据，并生成结果集返回给客户端。

请参见

关系数据库组件


数据库引擎组件

Microsoft® SQL Server™ 2000 的关系数据库服务器主要有两部分：关系引擎和存储引擎。SQL Server 7.0 版的一个最重要的构架更改是：在服务器中将关系引擎组件和存储引擎组件明确分开，并让它们使用 OLE DB API 相互通讯。

对只引用本地数据库表的 SELECT 语句的处理可以简单概括为：

  1. 关系引擎将 SELECT 语句编译为优化的执行计划。执行计划对 SELECT 语句中引用的个别表或索引内的基本行集定义一系列操作。

    行集是 OLE DB 对结果集的叫法。关系引擎请求的行集返回表或索引内所需的数据量，以执行一个操作来生成 SELECT 结果集。例如，如果这个 SELECT 语句引用没有索引的表，则需要表扫描：

    SELECT * FROM ScanTable

    关系引擎通过请求一个包含 ScanTable 内所有行的行集来执行表扫描。

    这个 SELECT 语句只需要索引中的可用信息。

    SELECT DISTINCT LastName
FROM Northwind.dbo.Employees

    关系引擎执行该索引扫描的方式是请求一个行集，该行集包含在 LastName 列上生成的索引中的叶行。

    这个 SELECT 语句需要两个索引中的信息：

    SELECT CompanyName, OrderID, ShippedDate
FROM Northwind.dbo.Customers AS Cst
     JOIN Northwind.dbo.Orders AS Ord
       ON (Cst.CustomerID = Ord.CustomerID)

    关系引擎请求两个行集，一个用于 Customers 上的聚集索引，另一个在 Orders 中的一个非聚集索引上。

  2. 之后，关系引擎使用 OLE DB API 请求存储引擎打开行集。

  3. 在处理执行计划的步骤并需要数据时，关系引擎使用 OLE DB 从它请求存储引擎打开的行集中提取个别行。存储引擎将数据从数据缓冲区传输到关系引擎。

  4. 关系引擎将存储引擎行集内的数据合并到最终结果集中并传回用户。


关系引擎

关系引擎的主要任务是：

  • 分析 SQL 语句。

    语法分析器扫描 SQL 语句并将其分成逻辑单元（如关键字、参数、运算符和标识符）。语法分析器还将整个 SQL 语句分成一系列更小的逻辑操作。

  • 优化执行计划。

    一般情况下，服务器使用源表中的数据生成结果集的方法有许多种。查询优化器确定这些不同的步骤系列，估计每个系列的成本（主要就文件 I/O 项目而言），然后选择成本最低的步骤系列。之后，优化器将特定的步骤与查询树进行组合以生成优化的执行计划。

  • 执行在执行计划中定义的逻辑操作系列。

    在查询优化器定义了完成语句所需的逻辑操作后，关系引擎将以优化执行计划中所指定的顺序一步步完成这些操作。

  • 处理数据定义语言 (DDL) 和其它语句。

    这些语句不是典型的 SELECT、INSERT、UPDATE 或 DELETE 语句，且都有特殊的处理要求。这类语句的例子包括 SET 语句和 CREATE 语句，其中 SET 语句用来设置连接选项，CREATE 语句用来创建数据库中的对象。

  • 格式化结果。

    关系引擎格式化返回给客户端的结果。结果被格式化为传统的表格格式结果集或 XML 文档，然后封装进一个或多个 TDS 数据包并返回给应用程序。


存储引擎

存储引擎的主要职责是：

  • 管理存储数据库的文件和文件中的空间使用。

  • 生成和读取用来存储数据的物理页。

  • 管理物理文件的数据缓冲区和所有 I/O。

  • 控制并发。管理事务，以及使用锁定控制并发用户对数据库中行的访问。

  • 记录日志和恢复。

  • 执行实用工具的功能（如 BACKUP、RESTORE 和 DBCC 语句以及大容量复制）。


SQL Server 语言支持

Microsoft® SQL Server™ 2000 随服务器上定义的 33 种自然语言一起安装。每种语言的定义都确定了 date 数据的解释方法：

  • 日期的显示格式：
    • dmy（日、月、年）

    • mdy（月、日、年）

    • ymd（年、月、日）
  • 每个月份的缩写和全称。

  • 每天的名称。

  • 哪一天被视作一周的第一天。

这些语言定义存储在 master.dbo.syslanguages 中，每种语言由一个语言标识符 (ID) 标识。

每个 SQL Server 实例对所有与服务器的连接都使用默认语言。有关配置该设置的更多信息，请参见 default language 选项。

大多数连接使用为服务器配置的默认语言，但是每个连接也可以自行设置用于连接的 SQL Server 语言：

  • Microsoft ActiveX® 数据对象和 OLE DB 应用程序可以在连接时所指定的提供程序字符串中包括 Language 关键字。

  • OLE DB 应用程序还可以在连接之前设置提供程序专用属性 SSPROP_INIT_CURRENTLANGUAGE。

  • 开放式数据库连接 (ODBC) 应用程序可以在 SQLDriverConnect 上所指定的连接字符串中包括 LANGUAGE 关键字。ODBC 应用程序还可以在 SQL Server ODBC 数据源定义中指定语言设置。

  • DB-Library 应用程序可以使用 dblogin 分配 loginrec，然后在调用 dbopen 打开连接之前使用 DBSETNATLANG 宏指定语言设置。

  • 任何应用程序都可以使用 SET LANGUAGE 语句指定 SQL Server 语言。

SQL Server 支持在 master.dbo.sysmessages 中存储错误信息的多个特定语言专用的复本。所有 SQL Server 实例都包含英文消息集。SQL Server 已本地化或翻译成法语、德语、西班牙语和日语。SQL Server 本地化版本的安装除安装英文消息集外，还安装翻译的消息集。SQL Server 在给连接发送消息时，如果连接的语言 ID 与 sysmessages 中提供的一种语言 ID 相匹配，则使用本地化消息。如果 sysmessages 中没有相同语言 ID 的消息，则发送英文版的消息。


查询处理器构架

SQL 语句是唯一从应用程序发送到 Microsoft® SQL Server™ 2000 的命令。SQL Server 实例所做的全部工作就是接受、解释和执行 SQL 语句。SQL Server 执行 SQL 语句的过程如下：

  • 处理单个 SQL 语句。

  • 处理批处理。

  • 执行存储过程和触发器。

  • 高速缓存执行计划并重新使用。

  • 处理并行查询。


处理单个 SQL 语句

处理单个 SQL 语句是 Microsoft® SQL Server™ 2000 执行 SQL 语句的最基本方法。对只引用本地基表（不引用视图或远程表）的单个 SELECT 语句的处理步骤说明了这个基本进程。

优化 SELECT 语句

SELECT 语句是非程序性的，它不规定数据库服务器检索所请求的数据的确切步骤。这意味着数据库服务器必须分析语句，以决定析取所请求数据的最有效方法。这称为 SELECT 语句优化，进行这项工作的组件称为查询优化器。

SELECT 语句只定义：

  • 结果集的格式。这通常在选择列表中指定，但其它子句（如 ORDER BY 和 GROUP BY）也影响结果集的最终形式。

  • 包含源数据的表。这在 FROM 子句中指定。

  • 就 SELECT 语句而言，表之间的逻辑关系。这在联接规范中定义。

  • 源表中的行必须满足的 SELECT 语句的限定条件。这些条件在 WHERE 和 HAVING 子句中指定。

查询执行计划定义：

  • 访问源表的顺序。

    数据库服务器一般可以按许多不同的序列访问基表以生成结果集。例如，如果 SELECT 语句引用三个表，数据库服务器可以先访问 TableA，使用 TableA 中的数据从 TableB 析取匹配的行，然后使用 TableB 中的数据从 TableC 析取数据。数据库服务器还可以按其它顺序访问表：TableC、TableB、TableA；或 TableB、TableA、TableC；或 TableB、TableC、TableA；或 TableC、TableA、TableB。

  • 从每个表析取数据的方法。

    访问每个表中的数据一般也有不同的方法。如果只需要有特定键值的几行，数据库服务器可以使用索引。如果需要表中的所有行，数据库服务器则可以忽略索引并执行表扫描。如果需要表中的所有行，而有一个索引的键列在 ORDER BY 中，则执行索引扫描而非表扫描可能会省去对结果集的单独排序。如果表很小，则对该表的几乎所有访问来说，表扫描可能都是最有效的方法。

从几个可能的执行计划中选出一个计划的过程称为优化。查询优化器是 SQL 数据库系统的最重要组件之一。虽然查询优化器在分析查询和选择计划时要使用一些开销，但当查询优化器选择了有效的执行计划时，节省的开销将是这一开销的数倍。例如，两家建筑公司可能拿到一所住宅的相同设计图。如果一家公司开始时先花几天时间规划如何建造这所住宅，而另一家公司不做任何规划就开始施工，则花了时间规划项目的那家公司很可能首先完工。

SQL Server 查询优化器是基于成本的优化器。每个可能的执行计划在所使用的计算资源量方面都有相关的成本。查询优化器必须分析可能的计划并选择一个估计成本最低的计划。有些复杂的 SELECT 语句有上千个可能的执行计划。在这些情况下，查询优化器不会分析所有可能的组合，而是使用复杂算法找到一个成本与理论上的最小值相当接近的执行计划。

SQL Server 查询优化器不只选择资源成本最低的执行计划，还选择能将结果集最快地返回给用户且资源成本合理的计划。例如，与串行处理查询相比，并行处理查询使用的资源一般更多但完成查询的速度更快。因此如果不对服务器的负荷产生负面影响，SQL Server 优化器将使用并行执行计划返回结果。

查询优化器在估计从表或索引中析取信息的不同方法所需的资源成本时，依赖于分发内容统计。对列和索引保留有分发内容统计。这些统计表明特定索引或列中的值的选择性。例如，在一个代表汽车的表中，很多汽车出自同一制造商，但每辆车都有唯一的车牌号 (VIN)。VIN 索引比制造商索引更具选择性。如果索引统计不是当前的，则查询优化器可能无法对表的当前状态做出最佳选择。有关保持索引统计最新的更多信息，请参见统计信息。

查询优化器很重要，因为它可以使数据库服务器针对数据库内的更改情况进行动态调整，而无须程序员或数据库管理员输入。这样程序员可以集中精力描述最终的查询结果。他们可以相信每次运行语句时，查询优化器总能针对数据库的状态生成一个有效的执行计划。

处理 SELECT 语句

SQL Server 处理单个 SELECT 语句的基本步骤是：

  1. 语法分析器扫描 SELECT 语句并将其分成逻辑单元（如关键字、表达式、运算符和标识符）。

  2. 生成查询树（有时称为序列树），以描述将源数据转换成结果集需要的格式所用的逻辑步骤。

  3. 然后，查询优化器分析所有可以访问源表的方法，从中选择一组返回结果最快且消耗资源较少的步骤。查询树随即进行更新以准确记录这个步骤系列，查询树的最终优化版本称为执行计划。

  4. 关系引擎开始执行执行计划。在处理执行计划的步骤并需要基表中的数据时，关系引擎使用 OLE DB 请求存储引擎向上传递从关系引擎请求的行集中的数据。

  5. 关系引擎将存储引擎返回的数据处理成为结果集定义的格式，然后将结果集返回客户端。
处理其它语句

上述处理 SELECT 语句的基本步骤也适用于其它 SQL 语句，例如 INSERT、UPDATE 和 DELETE。UPDATE 和DELETE 语句都必须确定要修改或删除的行集，识别这些行的过程与识别产生 SELECT 语句结果集的源行所用的过程相同。UPDATE 和 INSERT 语句都可以包含嵌入式 SELECT 语句，以提供要更新或插入的数据值。

即使象 CREATE PROCEDURE 或 ALTER TABLE 这样的数据定义语言 (DDL) 语句也被最终解析为系统目录表上的一系列关系操作，而有时（如 ALTER TABLE ADD COLUMN）则根据数据表解析。


视图解析

Microsoft® SQL Server™ 2000 查询处理器处理索引视图和非索引视图的方式不同：

  • 索引视图以与表相同的格式存储在数据库中。查询处理器处理索引视图的方式与基表相同。

  • 只存储非索引视图的源。查询优化器将视图源中的逻辑纳入执行计划，而该执行计划是它为引用非索引视图的 SQL 语句生成的。

SQL Server 查询优化器用于决定何时使用索引视图的逻辑与用于决定何时在表上使用索引的逻辑相似。如果索引视图中的数据包括 SQL 语句，且查询优化器确定视图上的某个索引是低成本的访问路径，则不论 WHERE 子句中是否引用了该视图，查询优化器都将选择此索引。有关更多信息，请参见解析视图上的索引。

SQL 语句引用非索引视图时，语法分析器和查询优化器分析 SQL 语句的源和视图的源，并将它们解析为单个执行计划。没有单独用于 SQL 语句或视图的计划。

例如，请看下面的视图：

USE Northwind
GO
CREATE VIEW EmployeeName AS
SELECT EmployeeID, LastName, FirstName
FROM Northwind.dbo.Employees
GO

在此视图中，这两个 SQL 语句在基表上执行相同的操作且生成相同的结果：

/* SELECT referencing the EmployeeName view. */
SELECT LastName AS EmployeeLastName,
       OrderID, OrderDate
FROM Northwind.dbo.Orders AS Ord
     JOIN Northwind.dbo.EmployeeName as EmpN
       ON (Ord.EmployeeID = EmpN.EmployeeID)
WHERE OrderDate > '31 May, 1996'

/* SELECT referencing the Employees table directly. */
SELECT LastName AS EmployeeLastName,
       OrderID, OrderDate
FROM Northwind.dbo.Orders AS Ord
     JOIN Northwind.dbo.Employees as Emp
       ON (Ord.EmployeeID = Emp.EmployeeID)
WHERE OrderDate > '31 May, 1996'

SQL 查询分析器的显示计划功能显示关系引擎为这两个 SELECT 语句生成相同的执行计划。


解析视图上的索引

Microsoft® SQL Server™ 2000 查询优化器确定给定查询是否能从使用数据库中定义的任何索引中获益。索引包括索引视图和基表索引。当满足下列条件时，SQL Server 查询优化器使用索引视图：

  • 下列会话选项均设置为 ON：
    • ANSI_NULLS

    • ANSI_PADDING

    • ANSI_WARNINGS

    • ARITHABORT

    • CONCAT_NULL_YIELDS_NULL

    • QUOTED_IDENTIFIERS
  • NUMERIC_ROUNDABORT 会话选项设置为 OFF。

  • 查询优化器查找视图索引列与查询中的元素之间的匹配部分，如：
    • WHERE 子句中的搜索条件谓词。

    • 联接操作。

    • 聚合函数。
  • 估计的索引使用成本是查询优化器考虑使用的所有访问机制中的最低成本。

除 SET 选项的要求外，查询优化器使用上述规则确定表索引是否包含查询。查询中无须再指定其它选项以使用索引视图。

查询不必在 FROM 子句中显式引用索引视图，查询优化器即可使用该索引视图。如果查询所引用的基表中的列也同时存在于索引视图中，并且，查询优化器估计使用索引视图将提供最低成本的访问机制，则查询优化器会选择索引视图，其方式类似于当查询中不直接引用基表索引时选择基表索引。当视图中包含非查询所引用的列时，只要视图提供覆盖一个或多个查询所指定列的最低成本选项，查询优化器即可能选择该视图。

使用 EXPAND VIEWS 选项可防止使用视图索引进行查询。可使用 NOEXPAND 视图提示强制优化器使用在 FROM 子句中指定的索引视图上的索引。不过，建议让查询优化器动态地决定各查询使用的最佳访问方法。只在经测试证实 EXPAND 和 NOEXPAND 可显著提高性能的特定情形中使用它们。

EXPAND VIEWS 选项指定对于整个查询，查询优化器不应使用任何视图索引。

  • 查询优化器不使用任何索引视图，除非在 FROM 子句中指定了视图。当查询优化器评估覆盖查询中所引用列的低成本方法时，它将忽略所有视图索引。

  • 查询优化器将 FROM 子句中引用的索引视图视为标准视图。查询优化器将视图的逻辑纳入查询执行计划中，并从基表中动态生成结果集。查询优化器忽略在视图上定义的索引。

当指定视图为 NOEXPAND 时，查询优化器将考虑使用视图上定义的任何索引。通过在可选的 INDEX() 子句中指定 NOEXPAND，可强制查询优化器使用指定索引。只能为索引视图指定 NOEXPAND，而不能为还未建立索引的视图指定 NOEXPAND。


解析分布式分区视图

Microsoft® SQL Server 2000™ 查询处理器已得到增强，优化了分布式分区视图的性能。分布式分区视图性能的最重要方面是使成员服务器之间传送的数据量减到最少。

SQL Server 2000 生成智能的动态计划，以便有效地利用分布式查询访问远程成员表中的数据：

  • 查询处理器首先使用 OLE DB 从每个成员表中检索 CHECK 约束定义。这使查询处理器可以在各成员表间映射键值的分布。

  • 查询处理器将 SQL 语句 WHERE 子句中指定的键范围与显示成员表中行的分布方式的映射进行比较。查询处理器然后生成查询执行计划，以使用分布式查询只检索那些完成 SQL 语句所需的远程行。还以这样一种方式生成执行计划，即任何对远程成员表中的数据或元数据的访问都一直被延迟到要求这些信息时。

例如，考察某个系统，该系统中的客户表在 Server1（CustomerID 从 1 到 3299999）、Server2（CustomerID 从 3300000 到 6599999）和 Server3（CustomerID 从 6600000 到 9999999）间进行分区。

考虑在 Server1 上执行的下列查询所生成的执行计划：

SELECT *
FROM CompanyData.dbo.Customers
WHERE CustomerID BETWEEN 3200000 AND 3400000

该查询的执行计划从本地成员表中析取 CustomerID 键值从 3200000 到 3299999 的行，并发出分布式查询从 Server2 中检索键值从 3300000 到 3400000 的行。

SQL Server 2000 查询处理器还可以在查询执行计划中内置动态逻辑，以用于在必须生成计划时尚不知道键值的 SQL 语句。例如，考察下面的存储过程：

CREATE PROCEDURE GetCustomer @CustomerIDParameter INT
AS
SELECT *
FROM CompanyData.dbo.Customers
WHERE CustomerID = @CustomerIDParameter

SQL Server 2000 无法预测每次执行过程时 @CustomerIDParameter 参数将提供什么键值。因为无法预测键值，所以查询处理器还无法预测必须访问哪个成员表。为了处理这种情况，SQL Server 生成了具有条件逻辑（称为动态筛选）的执行计划，可根据输入参数值控制要访问的成员表。假设在 Server1 上执行了 GetCustomer 存储过程，则执行计划逻辑可以表示为：

IF @CustomerIDParameter BETWEEN 1 and 3299999
   Retrieve row from local table CustomerData.dbo.Customer_33
ELSEIF @CustomerIDParameter BETWEEN 3300000 and 6599999
   Retrieve row from linked table Server2.CustomerData.dbo.Customer_66
ELSEIF @CustomerIDParameter BETWEEN 6600000 and 9999999
   Retrieve row from linked table Server3.CustomerData.dbo.Customer_99

SQL Server 2000 有时甚至对没有参数化的查询生成这些类型的动态执行计划。优化程序可能将查询自动参数化，以便执行计划可再次使用。如果优化程序自动参数化引用分区视图的查询，则优化程序不再假定所需的行将来自指定的基表，并且必须使用执行计划中的动态筛选。有关更多信息，请参见自动参数设置。


工作表

关系引擎可能需要生成一个工作表以执行 SQL 语句中指定的逻辑操作。一般为某些 GROUP BY、ORDER BY 或 UNION 查询生成工作表。例如，如果 ORDER BY 子句引用的列不为任何索引所覆盖，则关系引擎可能需要生成一个工作表以将结果集按所请求的顺序排序。

工作表在 tempdb 内生成，并在语句执行完后被自动除去。


成批处理

批处理是客户端作为一个单元发出的一个或多个 SQL 语句的集合。每个批处理编译为一个执行计划。如果批处理包含多个 SQL 语句，则执行所有语句所需的全部优化步骤将生成一个单一的执行计划。

有几种指定批处理的方法：

  • 应用程序作为一个执行单元发出的所有 SQL 语句构成一个批处理，并生成单个执行计划。有关应用程序如何指定批处理的更多信息，请参见批处理。

  • 存储过程或触发器内的所有语句构成一个批处理。每个存储过程或触发器都编译为一个执行计划。

  • 由 EXECUTE 语句执行的字符串是一个批处理，并编译为一个执行计划。

  • 由 sp_executesql 系统存储过程执行的字符串是一个批处理，并编译为一个执行计划。

如果应用程序发出的批处理中包含 EXECUTE 语句，已执行字符串或存储过程的执行计划将与包含 EXECUTE 语句的执行计划分开执行。为 sp_executesql 存储过程所执行的字符串生成的执行计划也与包含 sp_executesql 调用的批处理的执行计划分开执行。如果批处理中的语句激发了触发器，触发器执行计划将与原始的批处理分开执行。

例如，一个包含以下四个语句的批处理使用五个执行计划：

  • 执行存储过程的 EXECUTE 语句。

  • 执行字符串的 sp_executesql 调用。

  • 执行字符串的 EXECUTE 语句。

  • 引用包含更新触发器的表的 UPDATE 语句。


存储过程和触发器执行

Microsoft® SQL Server™ 2000 只存储存储过程和触发器的源。第一次执行存储过程或触发器时，源被编译为执行计划。如果在执行计划从内存老化掉之前再次执行该存储过程或触发器，关系引擎将检测到这个现有的计划并重新使用它。如果该计划已从内存老化掉，将生成一个新的计划。这一进程类似于 SQL Server 2000 对所有 SQL 语句采用的进程。SQL Server 2000 中的存储过程和触发器所具有的主要性能优点是它们的 SQL 语句始终相同，因此关系引擎可将它们与任何现有的执行计划相匹配。

与 SQL Server的早期版本中的其它 SQL 语句相比，存储过程有一个更明显的性能优点。SQL Server 的早期版本不尝试重新使用非存储过程和触发器的批处理的执行计划。重新使用执行计划的唯一方法是在存储过程中编码 SQL 语句。

存储过程和触发器的执行计划与调用存储过程或激发触发器的批处理的执行计划分开执行。这样就有更大的机会重新使用存储过程和触发器的执行计划。有关更多信息，请参见批处理。


执行计划的高速缓存和重新使用

Microsoft® SQL Server™ 2000 有用于存储执行计划和数据缓冲区的内存池。池内分配给执行计划或数据缓冲区的百分比随系统状态动态波动。内存池中用于存储执行计划的部分称为过程高速缓存。

SQL Server 2000 执行计划包含下面两个主要组件：

  • 查询计划

    执行计划的主体是一个重入的只读数据结构，可由任意数量的用户使用。这称为查询计划。查询计划中不存储用户环境。查询计划在内存中永远不会有一个或两个以上的复本：一个复本用于所有串行执行，一个复本用于所有并行执行。并行复本覆盖所有的并行执行，与并行执行的并行度无关。

  • 执行环境

    每个正在执行查询的用户都有一个包含其执行专用数据（如参数值）的数据结构。该数据结构称为执行环境。执行环境数据结构可以重新使用。如果用户执行查询而其中的一个结构未使用，将会用新用户的环境重新初始化该结构。

在 SQL Server 2000 中执行任何 SQL 语句时，关系引擎将首先查看过程高速缓存中是否有用于同一 SQL 语句的现有执行计划。SQL Server 2000 重新使用所找到的任何现有计划以节省重新编译 SQL 语句的开销。如果没有现有执行计划，则 SQL Server 2000 将为查询生成新的执行计划。

SQL Server 2000 有一个高效的算法，可查找用于任何特定 SQL 语句的现有执行计划。在大多数系统中，这种扫描所使用的最小资源比通过重新使用现有计划而不是编译每个 SQL 语句所节省的资源要少。

该算法将新的 SQL 语句与高速缓存内现有的未用执行计划相匹配，并要求所有的对象引用完全合法。例如，这两个 SELECT 语句中的第一个语句与现有计划不匹配，而第二个语句则匹配：

SELECT * FROM Employees

SELECT * FROM Northwind.dbo.Employees

在 SQL Server 2000 实例中，个别执行计划重新使用的概率比在 SQL Server 6.5 或更早版本中高。

执行计划的老化

执行计划生成后便驻留在过程高速缓存中。只有当需要空间时，SQL Server 2000 才使旧的未用计划从高速缓存老化掉。每个查询计划和执行环境都有相关的成本因子，可表明编译结构所需的费用。这些数据结构还有一个年龄字段。对象每由连接引用一次，其年龄字段便按编译成本因子递增。例如，如果一个查询计划的成本因子是 8 且被引用了两次，它的年龄将变为 16。惰性写入器进程定期扫描过程高速缓存内的对象列表。惰性写入器减少每个对象的年龄字段，每扫描一次减少 1。在本例中，查询计划的年龄经过 16 次过程高速缓存扫描后减为 0，除非其他用户引用了该计划。如果满足下面三个条件，惰性写入器进程将释放对象：

  • 内存管理器需要内存且所有可用内存都正在使用。

  • 对象的年龄字段是 0。

  • 对象在当前没有被连接引用。

因为每次引用对象时其年龄字段都会增加，所以经常被引用的对象的年龄字段不会减为 0，也不会从高速缓存老化掉。不经常被引用的对象将很快满足释放条件，但是不会真被释放，除非其它对象有内存需求。

重新编译执行计划

由于数据库的新状态，数据库内的某些更改可能会导致执行计划效率低下或不再有效。SQL Server 检测这些使执行计划无效的更改，并将计划标记为无效。此后，必须为执行查询的下一个连接重新编译新的计划。导致计划无效的情况包括：

  • 对查询所引用的表或视图进行任何结构更改（ALTER TABLE 和 ALTER VIEW）。

  • 通过语句（如 UPDATE STATISTICS）显式生成或者自动生成新的分发内容统计。

  • 除去执行计划所使用的索引。

  • 显式调用 sp_recompile。

  • 对键的大量更改（其他用户对由查询引用的表使用 INSERT 或 DELETE 语句所产生的修改）。

  • 对于带触发器的表，inserted 或 deleted 表内的行数显著增长。


参数和执行计划的重新使用

使用参数（包括 ADO、OLE DB 和 ODBC 应用程序中的参数标记）可以增加重新使用执行计划的机会。

下面两个 SELECT 语句的唯一区别是 WHERE 子句中的比较值：

SELECT * FROM Northwind.dbo.Products WHERE CategoryID = 1

SELECT * FROM Northwind.dbo.Products WHERE CategoryID = 4

这两个查询的执行计划的唯一区别是为比较 CategoryID 列而存储的值。虽然 SQL Server 2000 的目标是始终承认语句生成的计划在本质上相同并重新使用这些计划，但是 SQL Server 有时在复杂的 SQL 语句中检测不到这一点。

使用参数将常量与 SQL 语句分开有助于关系引擎识别重复计划。可以按下列方式使用参数：

  • 在 Transact-SQL 中，使用 sp_executesql：
    DECLARE @MyIntParm INT
SET @MyIntParm = 1
EXEC sp_executesql
  N'SELECT * FROM Northwind.dbo.Products WHERE CategoryID = @Parm',
  N'@Parm INT',
  @MyIntParm

    这一方法最适于 Transact-SQL 脚本、存储过程或动态生成 SQL 语句的触发器。有关更多信息，请参见运行时生成语句。

  • ADO、OLE DB 和 ODBC 使用参数标记。参数标记是问号 (?)，在 SQL 语句中替代常量并绑定到程序变量。例如，在 ODBC 应用程序中：
    • 使用 SQLBindParameter 将整型变量绑定到 SQL 语句中的第一个参数标记上。

    • 在变量中放入整型值。

    • 执行语句，并指定参数标记 (?)：
      SQLExecDirect(hstmt,
  "SELECT * FROM Northwind.dbo.Products WHERE CategoryID = ?",
  SQL_NTS);

    在应用程序中使用参数标记时，随 SQL Server 2000 提供的用于 SQL Server 的 Microsoft OLE DB 提供程序和 SQL Server ODBC 驱动程序都使用 sp_executesql 将语句发送到 SQL Server 2000。

请参见

sp_executesql

使用参数

命令参数

使用语句参数


自动参数设置

在 Microsoft® SQL Server™ 2000 中，在 Transact-SQL 语句中使用参数或参数标记，将提高关系引擎将新的 SQL 语句与现有的未用执行计划进行匹配的能力。如果执行不带参数的 SQL 语句，SQL Server 2000 在内部参数化语句，以提高将该语句与现有执行计划相匹配的可能性。

请看下面的语句：

SELECT * FROM Northwind.dbo.Products WHERE CategoryID = 1

可以将该语句最后的值 1 指定为一个参数。关系引擎为这个批处理生成一个执行计划，如同已经指定了一个参数替代值 1。这种自动参数化使 SQL Server 2000 能识别出下面两个语句生成的执行计划在本质上相同，并对第二个语句重新使用第一个计划：

SELECT * FROM Northwind.dbo.Products WHERE CategoryID = 1

SELECT * FROM Northwind.dbo.Products WHERE CategoryID = 4

处理复杂的 SQL 语句时，关系引擎可能很难确定可以自动参数化哪些表达式。若要提高关系引擎将复杂的 SQL 语句与现有的未用执行计划相匹配的能力，请使用 sp_executesql 或参数标记显式指定参数。有关更多信息，请参见参数和执行计划的重新使用。


准备 SQL 语句

Microsoft® SQL Server™ 2000 关系引擎完全支持在执行 SQL 语句前准备 SQL 语句。如果应用程序需要多次执行 SQL 语句，可以通过数据库 API：

  • 准备一次语句。这将 SQL 语句编译为执行计划。

  • 在每次需要执行语句时执行预编译的执行计划。这将在第一次执行 SQL 语句后省去对每个执行计划重新编译 SQL 语句。

    语句的准备和执行由 API 函数和方法控制。API 函数和方法不是 Transact-SQL 语言的一部分。用于执行 SQL 语句的准备/执行模型则由用于 SQL Server 的 Microsoft OLE DB 提供程序和 SQL Server ODBC 驱动程序支持。在请求准备时，提供程序或驱动程序将语句发送到 SQL Server 以请求准备语句。SQL Server 编译执行计划，并将该计划的句柄返回给提供程序或驱动程序。在请求执行时，提供程序或驱动程序向服务器发送请求以执行与句柄相关联的计划。

准备好的语句无法用于在 SQL Server 2000 或 SQL Server 7.0 版上创建临时对象。准备的语句不能引用创建临时对象（如临时表）的系统存储过程。必须直接执行这些过程。

过多地使用准备/执行模型会降低性能。如果一个语句只执行一次，直接执行只需要与服务器进行一次网络往返。准备并而后执行只执行一次的 SQL 语句，则需要多进行一次网络往返；一次是准备语句，一次是执行语句。

如果使用参数标记，可更有效地准备语句。例如，假设可能偶尔让应用程序从 Northwind 示例数据库检索产品信息。应用程序可以采用两种方法执行这个操作。

第一种方法，应用程序可以为请求的每个产品执行一个单独的查询：

SELECT * FROM Northwind.dbo.Products
WHERE ProductID = 63

应用程序可以采用的第二种方法是：

  1. 准备带参数标记的 (?) 的语句：
    SELECT * FROM Northwind.dbo.Products
WHERE ProductID = ?
  2. 将程序变量绑定到参数标记上。

  3. 每次需要产品信息时，用键值填充绑定的变量，然后执行该语句。

如果执行语句的次数多于三次，第二种方法更有效。

在 SQL Server 2000 中，由于 SQL Server 2000 重新使用执行计划的方式，准备/执行模型与直接执行相比，性能优势很小。SQL Server 2000 有高效的算法，可将当前的 SQL 语句与为前面执行同一 SQL 语句而生成的执行计划进行匹配。如果应用程序使用参数标记多次执行一个 SQL 语句，SQL Server 2000 将在第二次执行以及后面的执行中重新使用第一次执行的执行计划（除非该计划已从过程高速缓存老化掉）。准备/执行模型还具有下列优点：

  • 与通过算法将 SQL 语句与现有执行计划进行匹配的方法相比，通过识别句柄查找执行计划的方法更有效。

  • 应用程序可以控制何时创建和重新使用执行计划。

  • 准备/执行模型可移植到其它数据库，包括早期的 SQL Server 版本。
在 SQL Server 早期版本中准备和执行

SQL Server 6.5 版和更早版本不直接支持准备/执行模型。但是，SQL Server ODBC 驱动程序通过使用存储过程支持准备/执行模型：

  • 应用程序请求准备 SQL 语句时，ODBC 驱动程序将 SQL 语句打包在 CREATE PROCEDURE 语句中，发送给 SQL Server。

  • 在请求执行时，ODBC 驱动程序将请求 SQL Server 执行生成的存储过程。

在 SQL Server 6.5 和 SQL Server 6.0 中，生成的存储过程是临时存储过程，存储在 tempdb 中。SQL Server 4.21a 及更早的版本不支持临时存储过程，因此驱动程序生成常规存储过程并将其存储在当前数据库中。与 SQL Server 2000 一起发布的用于 SQL Server 的 Microsoft OLE DB 提供程序和 SQL Server ODBC 驱动程序在连接到 SQL Server 6.5 版、6.0 版和 SQL Server 4.21a 版时遵循这些行为。

请参见

执行计划的高速缓存和重新使用

参数和执行计划的重新使用

执行已准备的语句

准备命令

已准备的执行


并行查询处理

Microsoft® SQL Server™ 2000 提供并行查询，可为拥有多个微处理器的计算机优化查询执行。通过使 SQL Server 得以用多个操作系统线程并行执行查询，SQL Server 可以快速有效地完成包含大量数据的复杂查询。

在查询优化过程中，SQL Server 查找可能从并行执行中受益的查询。对于这些查询，SQL Server 在查询执行计划中插入交换运算符，以准备并行执行查询。交换运算符是在查询执行计划中提供进程管理、数据重新分发和流控制的运算符。插入交换运算符后所得到的即是并行查询执行计划。并行查询执行计划可以使用多个线程，而非并行查询所使用的串行执行计划只使用一个线程执行查询。并行查询所使用的实际线程数取决于查询计划执行初始化，并被称为并行度。


并行度

Microsoft® SQL Server™ 2000 通过考虑下列因素，自动检测出每个并行查询执行实例的最佳并行度：

  1. SQL Server 是否运行在拥有多个微处理器或 CPU 的计算机上，如对称多处理计算机 (SMP)？

    只有具有多个 CPU 的计算机才能使用并行查询。

  2. 此刻 SQL Server 安装上的活动并发用户数是多少？

    SQL Server 监视 CPU 的使用情况，并在查询开始时调整并行度。如果 CPU 的使用量高，则选择较低的并行度。

  3. 是否有足够的内存用于并行查询执行？

    执行每个查询都需要一定的内存量。执行并行查询比执行非并行查询需要更多内存。执行并行查询所需的内存量随并行度的增加而增加。如果用于特定并行度的并行计划的内存要求得不到满足，SQL Server 将自动降低并行度，或在特定的工作负荷环境下完全放弃并行计划而执行串行计划。

  4. 所执行的查询是什么类型？

    大量消耗 CPU 循环的查询最适合使用并行查询。例如，大型表的联接、庞大的聚合和大型结果集的排序都十分适合使用并行查询。在进行简单查询（在事务处理应用程序中经常碰到）时，并行执行查询所需的额外协调工作，比潜在的性能提升要多。为区别从并行中受益的查询和不能从并行中受益的查询，SQL Server 将执行查询的估计成本与 cost threadshold for parallelism 的值进行比较。虽然不推荐，但用户可以使用 sp_configure 更改默认值 5。

  5. 特定的流中有足够的行被处理吗？

    如果查询优化器确定流中的行数太少，则不引入交换运算符分发流。结果，此流中的运算符被串行执行。以串行计划执行运算符可避免出现这样的情况：启动、分发和协调成本超过并行运算符执行所获得的收益。

虽然 INSERT、UPDATE 和 DELETE 运算符串行执行，但是 UPDATE 或 DELETE 的 WHERE 子句，或是 INSERT 语句中 SELECT 部分的 WHERE 子句可以并行执行。实际的数据更改于是串行应用到数据库。

并行执行计划可以填充静态和键集游标。然而，只有串行执行可以提供动态游标行为。查询优化器始终为查询生成串行执行计划，这是动态游标的一部分。

在执行时，SQL Server 确定当前的系统工作负荷和配置信息是否允许执行并行查询。如果允许执行并行查询，SQL Server 将确定最佳的线程数，并在那些线程上展开并行查询的执行。当开始在多个线程上并行执行查询时，查询将一直使用相同的线程数，直到完成。每次从过程高速缓存中检索查询执行计划时，SQL Server都重新检查最佳线程数决策。例如，执行一次查询会导致使用串行计划，第二次执行相同的查询会导致使用三个线程的并行计划，第三次执行会导致使用四个线程的并行计划。

使用 SQL 事件探查器监视个别语句的并行度。使用性能事件类别中的并行度事件类。有关更多信息，请参见性能事件分类。

每个并行查询的显示计划输出中至少有以下三个逻辑运算符中的一个：

  • Distribute Streams

  • Gather Streams

  • Repartition Streams

请参见

设置配置选项

sp_configure

系统存储过程


并行查询示例

下列查询计算从 2000 年 4 月 1 日开始的给定季度内的定单数，其中至少有一个定单的项目交付给客户的时间迟于规定日期。该查询列出这类定单的计数，并按每个定单的优先级分组和按优先级升序排序。

下例使用理论表和列名。

SELECT o_orderpriority, COUNT(*) AS Order_Count
FROM orders
WHERE o_orderdate >= '2000/04/01'
   AND o_orderdate < DATEADD (mm, 3, '2000/04/01')
   AND EXISTS
         (
          SELECT *
            FROM    lineitem
            WHERE l_orderkey = o_orderkey
               AND l_commitdate < l_receiptdate
         )
   GROUP BY o_orderpriority
   ORDER BY o_orderpriority

假定在 lineitem 和 order 表上定义下列索引：

CREATE INDEX l_order_dates_idx
   ON lineitem
      (l_orderkey, l_receiptdate, l_commitdate, l_shipdate)

CREATE UNIQUE INDEX o_datkeyopr_idx
   ON ORDERS
      (o_orderdate, o_orderkey, o_custkey, o_orderpriority)

下面是可能会为前面显示的查询生成的一种并行计划：

|--Stream Aggregate(GROUP BY:([ORDERS].[o_orderpriority])
                  DEFINE:([Expr1005]=COUNT(*)))
    |--Parallelism(Gather Streams, ORDER BY:
                  ([ORDERS].[o_orderpriority] ASC))
         |--Stream Aggregate(GROUP BY:
                  ([ORDERS].[o_orderpriority])
                  DEFINE:([Expr1005]=Count(*)))
              |--Sort(ORDER BY:([ORDERS].[o_orderpriority] ASC))
                   |--Merge Join(Left Semi Join, MERGE:
                  ([ORDERS].[o_orderkey])=
                        ([LINEITEM].[l_orderkey]),
                  RESIDUAL:([ORDERS].[o_orderkey]=
                        [LINEITEM].[l_orderkey]))
                        |--Sort(ORDER BY:([ORDERS].[o_orderkey] ASC))
                        |    |--Parallelism(Repartition Streams,
                           PARTITION COLUMNS:
                           ([ORDERS].[o_orderkey]))
                        |         |--Index Seek(OBJECT:
                     ([tpcd1G].[dbo].[ORDERS].[O_DATKEYOPR_IDX]),
                     SEEK:([ORDERS].[o_orderdate] >=
                           Apr  1 2000 12:00AM AND
                           [ORDERS].[o_orderdate] <
                           Jul  1 2000 12:00AM) ORDERED)
                        |--Parallelism(Repartition Streams,
                     PARTITION COLUMNS:
                     ([LINEITEM].[l_orderkey]),
                     ORDER BY:([LINEITEM].[l_orderkey] ASC))
                             |--Filter(WHERE:
                           ([LINEITEM].[l_commitdate]<
                           [LINEITEM].[l_receiptdate]))
                                  |--Index Scan(OBJECT:
         ([tpcd1G].[dbo].[LINEITEM].[L_ORDER_DATES_IDX]), ORDERED)

上图显示按并行度等于 4 执行且包括一个双表联接的查询优化器计划。

这个并行计划包含三个并行运算符。o_datkey_ptr 索引的索引查找运算符和 l_order_dates_idx 索引的索引扫描运算符都以并行方式执行并生成几个排它流。这可以分别通过索引扫描和索引查找运算符上方最近的那个并行运算符确定。它们都重新划分交换类型；它们只是在流中重新分组数据，以使输出中生成的流数与输入中的相同。这个流数等于并行度。

l_order_dates_idx 索引扫描运算符上方的那个并行运算符使用 L_ORDERKEY 的值作为键重新划分它的输入流，这样相同的 L_ORDERKEY 值最终会产生相同的输出流。同时，输出流维护 L_ORDERKEY 列上的定单以满足合并联接运算符的输入要求。

索引查找运算符上方的那个并行运算符使用 O_ORDERKEY 的值重新划分它的输入流。由于 O_ORDERKEY 列值上的输入没排序，而且这是合并联接运算符中的联接列，因此并行和合并联接运算符之间的排序运算符确保在联接列上将合并联接运算符的输入排序。与合并联接运算符一样，排序运算符以并行方式执行。

最上面的那个并行运算符将几个流中的结果聚集到一个流中。之后，该并行运算符下方的流聚合运算符所执行的部分聚合被聚集到单个的 SUM 值中，这个 SUM 值是该并行运算符上方的流聚合运算符中每个不同的 O_ORDERPRIORITY 值之和。

请参见

逻辑运算符和物理运算符


创建索引的并行操作

为创建索引而生成的查询计划允许在具有多个微处理器的计算机上执行并行的多线程索引创建操作。

Microsoft® SQL Server™ 2000 确定索引创建操作的并行度（单独运行的总线程数）时使用的算法，与其对其它 Transact-SQL 语句所使用的算法相同。唯一的区别是创建索引的 CREATE INDE、CREATE TABLE 或 ALTER TABLE 语句不支持 MAXDOP 查询提示。索引创建的最大并行度受限于 max degree of parallelism 服务器配置选项，用户不能为个别的索引创建操作设置不同的 MAXDOP 值。

SQL Server 2000 生成创建索引查询计划时，并行操作数设置为下面各项的最小值：

  • 计算机中的微处理器 (CPU) 数。

  • max degree of parallelism 服务器配置选项中指定的数目。

  • 尚未超过为 SQL Server 线程执行的工作阈值的 CPU 数。

例如，在具有 8 个 CPU 的计算机上，其 max degree of parallelism 却设置为 6，则为索引创建生成的并行线程不超过 6 个。如果生成索引创建执行计划时，计算机中有 5 个 CPU 超过了 SQL Server 工作阈值，则执行计划只指定三个并行线程。

并行索引创建的主要阶段包括：

  • 协调线程快速并随机地扫描表，以估计索引键的分布情况。协调线程建立键的边界，这将创建若干与并行操作度相等的键范围，其中每个键范围所包含的行数都差不多。例如，如果表中有四百万行，且并行度为 4，则协调线程确定将键值分为 4 个行集，每个行集有一百万行。

  • 协调线程分派与并行操作度相等的若干线程，并等待这些线程完成它们的工作。每个线程都使用筛选扫描基表，只检索键值在指派给线程的范围内的行。每个线程都为其键范围内的行生成索引结构。有关索引生成方式的更多信息，请参见 tempdb 和索引创建。

  • 当所有并行线程都完成后，协调线程将索引子单元连接到单个索引中。

个别 CREATE TABLE 或 ALTER TABLE 语句可以有多个要求创建索引的约束。这些多个索引创建操作连续执行，但每个索引创建操作可以是具有多个 CPU 的计算机上的并行操作。

请参见

tempdb 和索引创建


内存构架

Microsoft® SQL Server™ 2000 根据需要动态获取和释放内存。管理员通常不必指定应给 SQL Server 分配的内存量，但该选项仍然存在，且在某些环境下还是必需的。在计算机上运行多个 SQL Server 实例时，每个实例都可以动态获取和释放内存，以适应实例中工作负荷的变化。

SQL Server 2000 企业版支持使用 Microsoft Windows® 2000 地址窗口扩展 (AWE)，为在 Windows 2000 Advanced Server 上运行的实例寻到大约 8GB 的内存，为在 Windows 2000 Data Center 上运行的实例寻到大约 64GB 的内存。然而，每个使用该扩展内存的实例都必须静态分配所需的内存。

虚拟内存和数据库引擎

虚拟内存是扩展计算机的可用物理内存的一种方法。在虚拟内存系统中，操作系统创建页文件或交换文件，并将内存划分为称为页的单元。最新引用的页位于物理内存或 RAM 内。如果一个内存页暂时没有被引用，则会写入页文件。这称为交换或换出内存。如果以后有应用程序引用那个内存页，则操作系统将该内存页从页文件读回到物理内存，这也称为交换或换入内存。应用程序的可用内存总量是计算机的物理内存量与页文件大小之和。如果计算机有 256 MB 的 RAM 和 256 MB 的页文件，应用程序的可用内存总量就是 512 MB。Microsoft Windows NT®、Windows 2000、Windows 95 和 Windows 98 这样的操作系统支持虚拟内存。

所有数据库软件的一个主要设计目标是将磁盘 I/O 减到最少，因为磁盘的读写是最占用资源的操作之一。SQL Server在内存中生成一个高速缓冲存储器以支持数据库中的页读取。SQL Server 中的很多代码是专门用于使磁盘和高速缓冲存储器之间的物理读写减到最少。高速缓冲存储器越大，SQL Server 须对数据库文件执行的 I/O 越少。然而，如果高速缓冲存储器导致 SQL Server 的内存要求超过服务器的可用物理内存，操作系统将开始与页文件交换内存。所发生的一切便是数据库文件的物理 I/O 被交换为交换文件的物理 I/O。

有很多数据库文件的物理 I/O 是数据库软件的一个固有因素。默认情况下，SQL Server 尝试在两个目的之间取得平衡：

  • 将页文件 I/O 减到最少或消除，以便将 I/O 资源集中用于读写数据库文件。

  • 通过尽量增加高速缓冲存储器的大小，将数据库文件的物理 I/O 减到最少。

默认情况下，SQL Server 2000 版本动态管理每个实例的地址空间大小。Windows NT、Windows 2000、Windows 95 和 Windows 98 向应用程序报告虚拟内存的方法不同。因此，SQL Server 2000 使用不同的算法管理这几种操作系统上的内存。

如果使用 Windows 2000 AWE 支持大型地址空间，则默认情况下，SQL Server 2000 企业版不进行动态内存管理。


动态管理 Windows NT 和 Windows 2000 上的内存

当 SQL Server 数据库引擎在 Microsoft® Windows NT® 或 Windows® 2000 上运行时，其默认内存管理行为并不是获取特定的内存量，而是在不产生多余换页 I/O 的情况下获取尽可能多的内存。为此，数据库引擎获取尽可能多的可用内存，同时保留足够的可用内存以防操作系统交换内存。

SQL Server 实例在启动时通常获取 8 到 12 MB 的内存以完成初始化过程。当实例完成初始化后，就不会再获取更多的内存，直到用户连接到该实例并开始产生工作负荷。这时，该实例根据需要不停地获取内存以支持工作负荷。随着更多的用户连接并运行查询，SQL Server 将获取支持需求所需的额外内存。该实例将继续获取内存直到达到自身的内存分配目标，并且直到达到该目标的下限才会释放任何内存。

为了在不产生多余换页 I/O 的情况下获取尽可能多的内存，SQL Server 的每个实例都设置一个内存获取目标，直到计算机的可用物理内存在 4 MB 到 10 MB 的范围内。之所以选择该范围是因为测试表明 Windows NT 和 Windows 2000 都有最小内存交换，直到内存分配等于可用物理内存减去 4 MB。工作负荷处理任务重的 SQL Server 实例保留的可用物理内存为范围的较低端 (4 MB)；工作负荷处理任务轻的实例保留的可用物理内存为范围的较高端 (10 MB)。

SQL Server 实例的目标随工作负荷的改变而变化。当更多的用户连接并产生更多的工作时，该实例倾向于获取更多的内存以使可用的内存保持在 4 MB 的限制以下。当工作负荷减轻时，该实例将其目标调整为 10 MB 的可用空间，并释放内存给操作系统。将可用空间量保持在 10 MB 与 4 MB 之间可防止 Windows NT 或 Windows 2000 过多执行换页操作，同时使 SQL Server 得以获得尽可能最大的高速缓冲存储器而不至引起额外的交换。

实例的目标内存设置与数据库缓冲池的页相对于可用池大小的需求有关。在任何即时点，缓冲区页的总需求取决于满足所有当前执行的查询所需的数据页数。如果相对于高速缓冲存储器内的页数，数据页的需求很大，则当前在缓冲区内的每一页很可能在相对较短的时间内由新页替换。这可由"缓冲区管理器"对象的"页生命期"性能计数器来度量。对于相对较小的缓冲区有较高需求的情况将生成短生命期，而纯粹的影响就是使 I/O 增加，因为在页可由多个逻辑读取引用之前往往要被重写。为减轻这个问题，数据库引擎可以获取更多的内存以增加高速缓冲存储器的大小。当页生命期长时，数据库引擎将可用内存定位于目标的高端 (10 MB)；而当页生命期短时，数据库引擎定位于目标范围的低端 (4 MB)。

随着其它应用程序在运行 SQL Server 实例的计算机上启动，它们消耗内存致使可用物理内存量降到 SQL Server 的目标以下。SQL Server 实例于是从其地址空间释放足够内存，以使可用内存量回到 SQL Server 的目标。如果有其它应用程序停止运行而使可用内存增多，SQL Server 实例将增加其内存分配大小。SQL Server 可以每秒释放并获取几 MB 字节的内存，这使它得以根据内存分配变化作出快速调整。


最小和最大服务器内存的影响

min server memory 和 max server memory 配置选项建立由 SQL Server 数据库引擎使用的内存量的上限和下限。数据库引擎并不立即获取 min server memory 中指定的内存量。数据库引擎启动时只使用初始化所需的内存。随着数据库引擎工作负荷的增加，它将继续获取支持工作负荷所需的内存。数据库引擎直到到达 min server memory 中指定的内存量才会释放任何所需的内存。一旦到达 min server memory，数据库引擎将使用标准算法（使操作系统的可用内存保持在 4 MB 到 10 MB 之间）获取和释放所需内存。唯一的区别是数据库引擎从不将内存分配降到 min server memory 所指定的水平下，也从不获取超过max server memory 所指定水平的内存。

数据库引擎获取的内存量完全取决于放置在实例上的工作负荷。不处理很多请求的 SQL Server 实例可能永远达不到 min server memory。

如果为 min server memory 和 max server memory 指定相同的值，则一旦分配给数据库引擎的内存达到该值，数据库引擎将停止动态释放和获取内存。

如果在运行 SQL Server 实例的计算机上频繁启动或停止其它应用程序，启动这些应用程序所需的时间可能会因 SQL Server 实例分配和释放内存而延长。另外，如果 SQL Server 是几个在一台计算机上运行的服务器应用程序中的一个，系统管理员可能需要控制分配给 SQL Server 的内存量。在这些情况下，可以使用 min server memory 和 max server memory 选项控制 SQL Server 可以使用的内存量。有关更多信息，请参见服务器内存选项。


在多实例之间动态管理内存

当多个 SQL Server 实例在同一台计算机上运行时，每个实例都独立地使用标准动态内存管理算法。不需要使实例互相通讯以协同管理内存。当分配了计算机上差不多 4 MB 到 10 MB 的内存时，分配给数据库引擎的每个特定实例的内存量将由每个实例的相关工作负荷驱动。承担较高工作负荷的实例获取更多的内存，而处理较轻工作负荷的实例获取较少的内存。无论一台计算机上有多少 SQL Server 实例，该算法都可确保：

  • 已分配的内存总量保持在将产生 Windows NT® 或 Windows® 2000 页 I/O 的水平之下。

  • 根据各 SQL Server 实例的相对工作负荷，在它们之间有效地分配计算机内存。

  • 内存分配是动态的，并能根据个别 SQL Server 实例的工作负荷变化立即进行调整。

这种交互操作可通过在一台计算机上运行两个实例来加以说明，但上述原则同样适用于在同一台计算机上运行多个实例的情况。假设某台计算机有 512MB 的物理内存，并运行两个名为 Instance1 和 Instance2 的实例。

当这两个实例首次启动时，它们通常获取 8 MB 到 12 MB 的内存。随着用户连接到这两个实例，每个实例都要获取足够的内存以满足其当前的工作负荷。

一旦内存量中只剩 4 MB 到 10 MB 可用时，这两个实例将为争夺内存相互竞争。假设 Instance1 的页生命期长并且它的可用内存目标为 10 MB，而 Instance2 的页生命期短，且其可用内存目标为 4 MB。假设已分配 506 MB 内存，只剩 6 MB 的可用内存。因为 6 MB 可用内存低于 Instance1 的 10 MB 目标，所以 Instance1 开始释放内存。Instance2 继续获取内存，因为可用内存量超过它的 4 MB 目标。每个实例实际具有多少内存并不重要。重要的是，Instance2 的当前缓冲池相对于其数据页的需求较小，而 Instance1 的缓冲池相对于其数据页的需求又太大。只要这种情况存在，Instance1 将有 10 MB 的可用内存目标，而 Instance2 将有 4 MB 的可用内存目标，这会驱使 Instance1 释放可用内存供 Instance2 使用。

随着 Instance1 释放内存，其高速缓冲存储器的大小随之减少。Instance1 最终将达到这种情况：大小已经减小的高速缓冲存储器开始缩短该实例的页生命期。当这种情况发生时，Instance1 开始从 10 MB 降低它的可用内存目标。同时，Instance2 用它从 Instance1 处获取的内存增大 Instance2 的高速缓冲存储器的大小。这就延长了 Instance2 的页生命期，并且 Instance2 开始将它的可用内存目标从 4 MB 开始增加。在某一时刻，Instance1 已转让了足够的内存给 Instance2，使这两个实例具有了相同的可用内存目标。一旦可用内存量达到这两个实例的当前目标水平，Instance1 将停止释放内存，而 Instance2 将停止获取内存，此时系统达到平衡状态。

这种平衡状态只有在两个实例的相对工作负荷保持不变时才能维持。一旦其中有一个实例的工作负荷变化（增加或者减少），该实例将更改其可用内存目标。于是，具有较高可用内存目标的实例开始释放内存，而可用内存目标较低的实例则开始获取内存，直到达到新的平衡。

该机制对于一台计算机上有两个以上实例的情况同样适用。所有实例将不断地释放或获取内存，直到所有实例都达到相同的可用内存目标。一旦计算机上的可用内存量达到公共目标，这些实例即处于平衡状态。


动态管理 Windows 95 和 Windows 98 上的内存

每个 Microsoft SQL Server™ 2000 实例在 Microsoft® Windows® 95 和 Windows 98 上运行时，都使用请求驱动算法分配内存。随着处理更多的 Transact-SQL 语句和对高速缓存数据库页的需求增加，SQL Server 实例请求更多的虚拟内存。当对 SQL Server 实例的需求降低时（例如，当处理的 Transact-SQL 语句减少时），SQL Server 实例将内存释放回操作系统。


使用 Windows 2000 上的 AWE 内存

Microsoft® SQL Server™ 2000 企业版使用 Microsoft Windows® 2000 地址窗口扩展 (AWE) API 支持超大量的地址空间。SQL Server 2000 企业版在 Windows 2000 Advanced Server 上可访问大约 8 GB 内存，在 Windows 2000 Data Center 上可访问大约 64 GB 的内存。

标准 32 位地址最多可映射 4 GB 的内存。因此 32 位 Microsoft Windows NT® 4.0 和 Windows 2000 进程的标准地址空间限制到 4 GB。默认情况下，为操作系统留出 2 GB 的地址空间，且有 2 GB 可供应用程序使用。如果在 Windows NT 企业版或 Windows 2000 Advanced Server 的 Boot.ini 文件中指定 /3GB 开关，则操作系统只保留 1 GB 的地址空间，且应用程序最多可得到 3 GB 的地址空间。有关 /3GB 开关的更多信息，请参见 Windows NT 企业版或 Windows 2000 Advanced Server 帮助。

AWE 是 Microsoft Win32® API 的内存管理功能的一组扩展，它允许应用程序寻到多于 4 GB 的内存，而通过标准 32 位寻址可获得的内存为 4 GB。AWE 允许应用程序获取物理内存并作为非换页内存，然后将非换页内存的视图动态映射到 32 位地址空间。虽然 32 位地址空间限制为 4 GB，但是非换页内存却可以远远大于 4 GB。这使大量占用内存的应用程序（如大型数据库系统）可以寻到比 32 位地址空间中支持的更多的内存。有关 AWE 的更多信息，请参见 Microsoft Web 站点上的 MSDN® 页。

启用 AWE 内存

必须通过 SQL Server 2000 企业版实例，使用 sp_configure 选项 awe enabled 专门启用 AWE 内存。

  • 当 awe enabled 设置为 0 时，不使用 AWE 内存，实例默认为使用标准 32 位虚拟地址空间中的动态内存。

  • 当 awe enabled 设置为 1 时，使用 AWE 内存，且实例最多可以在 Windows 2000 Advanced Server 上得到 8 GB 物理内存，在 Windows 2000 Data Center 上得到 64 GB 物理内存。

SQL Server 2000 企业版实例在 awe enabled 设置为 1 的状态下运行时：

  • 实例不动态管理地址空间的大小。

  • 实例将启动时获取的所有内存一直控制到关闭时。

  • 实例的内存页来自 Windows 非换页池，这意味着不能换出实例的任何内存。

必须认真管理 SQL Server 实例在 awe enabled 设置为 1 时使用的内存。如果实例获取了大部分可用的物理内存并作为非换页内存，则其它应用程序或系统进程可能无法得到运行所需的内存。应使用 max server memory 配置设置控制每个使用 AWE 内存的 SQL Server 实例所使用的内存量。有关更多信息，请参见"在 Windows 2000 上管理 AWE 内存"。


SQL Server 内存池

在 Microsoft® Windows NT®、Windows® 2000、Windows 95 和 Windows 98 中，应用程序可用的虚拟内存总量形成了应用程序的有效内存地址集。应用程序的虚拟内存分配总量称为它的地址空间。

每个 Microsoft SQL Server™ 2000 实例都有包含两个主要组件的地址空间，其中每个主要组件又包含下面几个子组件：

  • 可执行代码

    SQL Server 实例使用的可执行文件和动态链接库 (DLL) 的数目和大小随时间改变。除开放式数据服务、SQL Server 引擎和服务器 Net-Library 所使用的可执行文件和 DLL 外，下列组件还以它们自己的 DLL 装载，这些 DLL 能自己分配内存：

    • 分布式查询可在运行 SQL Server 实例的服务器上装载 OLE DB 提供程序 DLL。

    • 扩展存储过程作为 DLL 实现并装载进 SQL Server 实例的地址空间。

    • OLE 自动化系统存储过程用于创建 OLE 自动化对象的实例。每类 OLE 自动化对象都将自己的代码装载进 SQL Server 实例的地址空间。
  • 内存池

    内存池是 SQL Server 实例的主要内存单元。在 SQL Server 实例中，几乎所有使用内存的数据结构都在内存池内分配。在内存池内分配的主要对象类型是：

    • 系统级数据结构

      这些是支持 SQL Server 实例全局数据（如数据库描述符和锁表）的数据结构。

    • 高速缓冲存储器

      这是数据页读入的缓冲区页池。

    • 过程高速缓存

      这是包含所有当前在实例中执行 Transact-SQL 语句的执行计划的页池。

    • 日志高速缓存

      每个日志都有一个缓冲区页高速缓存用于读写日志页。日志高速缓存与高速缓冲存储器分开管理以减少日志和数据缓存区之间的同步。这将产生快速可靠的代码。

    • 连接环境

      每个连接都有一组数据结构记录连接的当前状态。这些数据结构包含查询和存储过程的参数值、游标定位信息、当前引用的表等项目。

  • 堆栈空间

    Windows 为 SQL Server 启动的每个线程分配堆栈空间。堆栈空间的默认大小是 512K。

SQL Server 2000 实例使用的内存池大小可以是动态的，尤其是在运行其它应用程序或其它 SQL Server实例的计算机上。默认情况下，SQL Server 力求使计算机的虚拟内存分配量保持在比物理内存少 4 MB 到 10 MB 的水平上。SQL Server 实例可以实现此目的的唯一方法是改变它的地址空间大小。SQL Server 实例的地址空间中唯一可变的组件是内存池。SQL Server 地址空间中的其它可变组件（如 OLE DB 提供程序、OLE 自动化对象和扩展存储过程的数目和大小）全都由应用程序请求控制。如果应用程序执行分布式查询，SQL Server 必须装载相关联的 OLE DB 提供程序。这意味着如果装载 SQL Server 组件或其它应用程序启动，SQL Server 实例释放新组件或应用程序所需的内存的唯一机制只能是减少内存池的大小。SQL Server 管理员可以通过 min server memory 和 max server memory 配置选项限制内存池大小的改变量。

内存池内的区域也是高度动态的。SQL Server 代码不停地调整分配给不同区域的内存池量以优化性能。在内存池内，用于存储连接环境和系统数据结构的区域由用户请求控制。当建立新连接时，SQL Server 须分配数据结构存储连接环境。当定义新数据库时，SQL Server 须分配数据结构定义数据库的属性。当引用表和视图时，SQL Server 须分配数据结构描述它们的结构和属性。这使缓冲区高速内存、过程高速缓存和日志高速缓存成为内存单元，其大小由 SQL Server 控制。SQL Server根据需要动态调整这些区域的大小以优化性能。

有关各种系统和连接环境数据结构大小的更多信息，请参见 SQL Server 对象内存使用情况说明。

SQL Server 2000 存储每个连接的环境和状态信息的方式非常有效，一般每个连接使用少于 24 KB 的空间。


线程和任务构架

复杂的应用程序可能有很多任务可以同时执行。线程是一个操作系统功能，它使得应用程序逻辑被分隔到几个并发执行路径中。

操作系统在执行应用程序实例时，创建一个称为进程的单元来管理实例。进程有一个执行线程，它是应用程序代码所执行的一系列编程指令。在只有一套可串行执行的指令的简单应用程序中，只有一个执行路径或线程通过应用程序。更复杂的应用程序可能有几个任务，这些任务只能一前一后地执行而不能串行执行。应用程序可以通过对每个任务启动单独的进程执行此操作，但是启动进程是一个大量占用资源的操作。相反，应用程序可以启动单独的线程，而这样的线程占用的资源相对较少。可以调度每个线程与进程所关联的其它线程分开执行。每个线程都在内存中称为栈的区域内存储自己的特定数据。

线程使复杂的应用程序得以更有效地使用 CPU，甚至是在只有一个 CPU 的计算机上。如果只有一个 CPU，每次只能执行一个线程。如果一个线程执行的是不使用 CPU 的长时间运行操作（如磁盘读写），则另一个线程可以一直执行到第一个操作完成。能够在其它线程等待操作完成的同时执行线程，这使应用程序得以最大限度地使用 CPU。这对有大量磁盘 I/O 活动的多用户应用程序（如数据库服务器）尤其如此。

对于有多个微处理器 (CPU) 的计算机，每个 CPU 都可以同时执行一个线程。如果一台计算机有八个 CPU，则可以同时执行八个线程。

Windows NT 纤程

Microsoft® Windows® 操作系统管理线程的代码在内核内。切换线程需要在应用程序代码的用户模式和线程管理器的内核模式之间切换，而这是比较昂贵的操作。Microsoft Windows NT® 纤程是线程的子组件，由以用户模式运行的代码管理。切换纤程不需要将用户模式切换到内核模式，而切换线程则需要这种转换。应用程序管理纤程的调度，而 Windows 管理线程的调度。每个线程可以有多个纤程。


SQL Server 任务调度

每个 Microsoft® SQL Server™ 2000 实例都是一个单独的操作系统进程。每个实例都有可能必须处理来自用户的成千上万个并发请求。SQL Server 2000 实例使用 Microsoft Windows® 线程（有时是纤程）有效地管理这些并发任务。每个 SQL Server 2000 实例始终为系统进程运行多个线程：每个服务器 Net-Library 的一个或多个线程，处理日志请求的网络线程，和与服务控制管理器进行通讯的信号线程。

每个 SQL Server 实例都有一个内部层，它实现类似于操作系统的环境，用于调度和同步并发任务，而无须调用 Windows 内核。这个内部层可以象处理线程那样有效地调度纤程。每个 SQL Server 实例都为用户连接维护一个线程池或纤程池。该池的最大大小由 max worker threads 服务器配置选项控制。

服务器配置 lightweight pooling 选项控制 SQL Server 2000 实例是使用线程还是纤程。默认情况下，lightweight pooling 的设置为 0，在该设置下 SQL Server 实例对每个并发用户命令调度一个线程，直到到达 max worker threads 的值。如果 lightweight pooling 的设置为 1，那么 SQL Server 使用纤程而不是线程。这称为以纤程模式运行。在纤程模式下，SQL Server 实例为每个 CPU 分配一个线程，然后为每个并发用户命令分配一个纤程，最大可以达到 max worker threads 的值。SQL Server 实例在使用线程或纤程时使用相同的算法调度和同步任务。SQL Server 2000 个人版和 SQL Server 2000 Desktop Engine 不支持纤程。

SQL 批处理是一组一个或多个 Transact-SQL 语句，由客户端发送到 SQL Server 实例作为一个单元执行。SQL Server 实例从客户端收到批处理时，将每个批处理与工作池中的可用线程或纤程相关联。如果没有可用线程或纤程且未达到 max worker threads 的值，SQL Server 实例将给新批处理分配新线程或纤程。如果没有可用线程或纤程但已达到 max worker threads 的值，实例将一直阻塞新批处理直到有线程可用。线程或纤程与批处理相关联后将一直保持关联状态，直到批处理生成的结果集已全部返回给客户端。这时，线程或纤程被释放，可以调度到下一个可用批处理。

虽然线程和纤程在使用资源方面无足轻重，但它们仍要消耗资源。在有成百上千个用户连接的系统中，给每个连接分配一个线程或纤程所消耗的资源足以降低 SQL Server 的效率。而且没必要给每个用户连接分配一个线程或纤程，因为大多数连接实际上都花大量时间等待从客户端接收批处理。SQL Server 实例的工作线程池的大小只需满足同时在此实例内活动地执行批处理的用户连接数。保留 max worker threads 的默认值 255 可使 SQL Server 实例有效地将用户连接映射到许多线程或纤程上，这样不会消耗太多资源。


给 CPU 分配线程

默认情况下，每个 Microsoft® SQL Server™ 2000 实例都可启动每个线程，然后 Microsoft Windows NT® 或 Windows® 2000 将每个线程分配给特定的 CPU。Windows NT 或 Windows 2000 在计算机上的微处理器 (CPU) 间平均分配 SQL Server 实例线程。Windows NT 或 Windows 2000 还不时地将线程从一个大量使用的 CPU 移到另一个 CPU。

SQL Server 管理员可以使用 affinity mask 配置选项使一个或多个 CPU 无资格运行特定 SQL Server 实例的线程。affinity mask 值指定位模式，以表明适合运行 SQL Server 实例线程的 CPU。例如，affinity mask 的值 13 代表位模式 1101。在有 4 个 CPU 的计算机上，这表示可以在 CPU 0、2 和 3 上调度 SQL Server 实例线程，而不能在 CPU 1 上调度线程。如果指定 affinity mask，SQL Server 实例将在没有掩码的 CPU 中平均分配线程。affinity mask 的另一个作用是 Windows NT 和 Windows 2000 不将线程从一个 CPU 移到另一个 CPU。affinity mask 很少使用，大多数系统通过让 Windows NT 或 Windows 2000 在可用的 CPU 中调度线程以获得最佳性能。


使用 lightweight pooling 选项

切换线程上下文的开销不是很大。大多数 Microsoft® SQL Server™ 实例体现不出将 lightweight pooling 选项设置为 0 和 1 之间的性能差异。唯一有可能从 lightweight pooling 中获益的实例是运行在具有如下特点的计算机上的实例：

  • 大型多 CPU 服务器。

  • 所有 CPU 以接近最大容量运行。

  • 有高级的上下文切换。

通过将 lightweight pooling 的值设为 1，可以略微提高这些系统的性能。

请参见

lightweight pooling 选项


线程和纤程执行

Microsoft® Windows® 使用从 1 到 31 的数字优先级（0 留作操作系统使用）调度线程的执行。当有多个线程等待执行时，Windows 分派优先级最高的线程。

默认情况下，每个 Microsoft SQL Server™ 2000 实例都将优先级设置为 7，这称为正常优先级。这给 SQL Server 线程提供了足够高的优先级以获得足够的 CPU 资源，而不会对其它应用程序造成负面影响。priority boost 配置选项可用于将线程的优先级从 SQL Server 实例增加到 13，这称为高优先级。此设置给 SQL Server 线程提供了一个比大多数其它应用程序高的优先级。因此，往往是每当 SQL Server 线程准备好运行时便获得分派，而不会被其它应用程序的线程抢先。这在服务器只运行 SQL Server 实例而未运行其它应用程序时可提高性能。然而，如果在 SQL Server 内发生大量占用内存的操作，其它应用程序不大可能有足够高的优先级而抢先于 SQL Server 线程。如果正在一个计算机上运行多个 SQL Server 实例，并只为其中的某些实例打开了优先级提升时，则任何以正常优先级运行的实例性能都将受到负面影响。如果打开 priority boost 选项，服务器上的其它应用程序和组件的性能可能会降低，因此只应在严密控制的情况下使用该选项。

一些 Transact-SQL 语句需要大量内存执行某些操作（如排序）。如果没有足够的可用内存，线程将等待释放内存。query wait 选项限制线程等待释放内存的时间长度。

请参见

query wait 选项


I/O 构架

数据库的主要作用是存储和检索数据，因此执行大量磁盘读写操作是数据库引擎的固有特性之一。磁盘 I/O 操作消耗很多资源，且需相对较长的时间才能完成。在关系数据库软件中，多数逻辑都涉及高效地建立 I/O 使用模式。

Microsoft® SQL Server™ 2000 将很多虚拟内存分配给高速缓冲存储器，并使用此高速缓存减少物理 I/O。每个 SQL Server 2000 实例都有自己的高速缓冲存储器。数据从数据库磁盘文件读入高速缓冲存储器。不必再次物理读取数据即可满足多次逻辑读取数据。数据一直保留在高速缓存内，直到已有一段时间不被引用且数据库需要缓存区读入更多数据。数据只有在被修改后才重新写入磁盘。在物理写将新数据传输回磁盘之前，数据可由逻辑写多次修改。

在 SQL Server 2000 数据库内的数据存储在 8 KB 页内。每组的八个邻接页是一个 64 KB 扩展盘区。高速缓冲存储器也被划分为 8 KB 页。

SQL Server 实例的 I/O 被划分为逻辑和物理 I/O。数据库服务器每次从高速缓冲存储器请求页时，即发生逻辑读取。如果页当前不在缓存区高速缓存内，则执行物理读取将页读入高速缓冲存储器。如果页当前在高速缓存内，则不产生物理读取；高速缓冲存储器只是使用已在内存内的页。当内存中页内的数据被修改时，发生逻辑写。当将页写入磁盘时，发生物理写。在将页物理写入磁盘之前，它有可能在内存内停留足够长的时间以至发生多次逻辑写。

SQL Server 实例的基本性能优化任务之一包括调整 SQL Server 内存的大小。目的是使高速缓冲存储器足够大以使逻辑读取与物理读取的比率达到最大，但又不至大到使过多的内存交换开始对页文件产生物理 I/O。SQL Server 2000 实例在默认配置设置下自动完成这一任务。

通过在虚拟内存内保持相对较大的高速缓冲存储器，SQL Server 实例可以显著减少所需的物理磁盘读取数。一个经常引用的页被读入高速缓冲存储器后很可能会继续留在那里，因此完全不用再进一步读取。

SQL Server 2000 使用 Microsoft Windows NT® 和 Windows® 2000 的下面两个功能来提高其磁盘的 I/O 性能：

  • 散播-聚集 I/O

    在 Windows NT 4.0版 Service Pack 2 中引入散播-聚集 I/O 之前，Windows NT 上所有用于磁盘读写的数据必须在邻接的内存区内。如果某个读取以 64 KB 为单位传送数据，则读取请求必须指定邻接 64 KB 内存区域的地址。散播-聚集 I/O 允许读取或写入操作将数据传入或传出内存的非邻接区域。Windows 2000 也支持散播-聚集 I/O。

    如果 SQL Server 2000 实例在 64 KB 扩展盘区中读取，则不须分配单个 64 KB 区并将各个页复制到高速缓冲存储器页内。它可以找到八个缓冲区页，然后执行一个散播-聚集 I/O 以指定这八个缓冲区页的地址。Windows NT 或 Windows 2000 直接在缓冲区页内放入八个页，使 SQL Server 实例不需要执行单独的内存复制。

  • 异步 I/O

    在异步 I/O 中，应用程序从 Windows NT 或 Windows 2000 中请求读取或写入操作。Windows NT 或 Windows 2000 立即将控制返回给应用程序。应用程序然后可以执行其它的工作，过一会儿执行测试以查看读写操作是否已完成。相反，在同步 I/O 中，操作系统直到读和写完成才将控制返回给应用程序。使用异步 I/O 使 SQL Server 实例得以在个别线程执行批处理时使它们所完成的工作最多。

SQL Server 支持对每个文件执行多个并发异步 I/O 操作。SQL Server 2000 动态确定一个实例能为任何文件发出的最大 I/O 操作数。


读取页

Microsoft® SQL Server™ 2000 实例生成的读取请求由关系引擎控制，并由存储引擎进一步优化。用于从表中读取页的访问方法（如表扫描、索引扫描或键读取）决定将执行的常规读取模式。关系引擎确定最有效的访问方法。请求随后被提供给存储引擎，存储引擎对实现访问方法所需的读取进行优化。执行批处理的线程调度读取。

表扫描在 SQL Server 2000 中非常有效。SQL Server 2000 数据库中的 IAM 页列出由表或索引使用的扩展盘区。存储引擎可以读取 IAM 以生成必须要读取的磁盘地址排序列表。这使 SQL Server 2000 得以将其 I/O 优化为大型有序读取，根据它们在磁盘上的位置按顺序完成。SQL Server 2000 同时对扫描所涉及的每个文件发出多个串行预读。这利用了条带化磁盘集的优点。SQL Server 2000 企业版根据现有内存量动态调整最大的预读页数；而该数值在 SQL Server 2000 所有其它版本中是固定的。

SQL Server 2000 企业版的一部分高级扫描功能使多项任务得以共享完全表扫描。如果 SQL 语句的执行计划调用对表中数据页的扫描，而关系数据库引擎检测到另外一个执行计划正在扫描该表，则数据库引擎会在第二个扫描的当前位置接着第一个扫描继续进行第二个扫描。数据库引擎一次读取一页，并将每页中的行传递到两个执行计划。该操作将一直持续到该表的结尾处。此时，第一个执行计划已有完整的扫描结果，而第二个执行计划仍必须检索在它加入正在进行的扫描之前发生的数据页。第二个执行计划的扫描将绕回到该表的第一个数据页，并从该这里向前扫描直到它加入第一个扫描的位置。可以通过这种方法组合任意数量的扫描，数据库引擎将不断在数据页中循环，直到完成所有的扫描。

例如，假设某个表有 500,000 页。UserA 执行一条 SQL 语句，要求对该表进行扫描。当扫描已处理了 100,000 页时，UserB 执行另一条 SQL 语句，对同一个表进行扫描。数据库引擎将为 100,001 之后的页调度一套读取请求，并将每页中的行传递回两个扫描。当扫描到第 200,000 页时，UserC 执行另一条 SQL 语句，对同一个表进行扫描。从 200,001 页开始，数据库引擎将它读取的每一页中的行传递回所有三个扫描。在读完第 500,000 行后，UserA 的扫描完成，而 UserB 和 UserC 的扫描绕回到第 1 页开始读取。当数据库引擎到达第 100,000 页时，UserB 的扫描完成。然后 Userc 的扫描单独继续往前读，直到读取第 200,000 页，至此所有扫描都已完成。

读取索引页

SQL Server 2000 按键顺序串行读取索引页。例如，下图显示一组叶级页的简化表示法，该组叶级页包含一组映射叶级页的键和中间级索引节点。

SQL Server 2000 使用位于叶级之上的中间级索引页内的信息为包含键的页调度串行预读 I/O。如果为'ABC'到'DEF'之间的所有键都生成请求，则 SQL Server 2000 实例首先读取叶级页之上的索引页。但是，它不是简单地按顺序读取第 504 页到第 556 页的每个数据页，第 556 页是键在期望范围内的最后一页。相反，存储引擎扫描中间级索引页并生成一个必须要读取的叶级页列表。然后存储引擎按键顺序调度所有 I/O。存储引擎还能够识别出第 504/505 页和第 527/528 页是邻接的页，并执行单个散播-聚集读取，以一个操作检索邻接页。当有许多页要以一个串行操作检索时，SQL Server 一次调度一个读取块。完成这些读取的子集后，SQL Server 调度同样数量的新读取，直到已调度所有所需的读取。

SQL Server 2000 使用预提取方式加快对非聚集索引的处理。非聚集索引的叶级行包含指向含有每个特定键值的数据行的指针。当数据库引擎在非聚集索引的叶级页中读取时，它也开始为已检索出其指针的数据行调度异步读取。这使数据库引擎得以在完成非聚集索引的扫描之前开始检索数据行。无论表是否有非聚集索引，都会按此过程进行。SQL Server 2000 企业版使用的预提取操作比 SQL Server 的其它版本多，并且在任何版本中都无法配置预提取水平。


释放和写入缓冲区页

在 Microsoft® SQL Server™ 2000 中，一个系统负责：

  • 将修改的缓冲区页写入磁盘。

  • 将一段时间未被引用的页标记为可用。

SQL Server 2000 有一个包含可用缓冲区页地址的单向链接列表。任何需要缓冲区页的线程都使用这个可用缓冲区列表的第一页。

高速缓冲存储器是一个内存中的结构。每个缓冲区页都有一个页首，页首中包含引用计数器和一个显示该页是否为脏页的指示器，脏页是指该页包含尚未写入磁盘的修改。SQL 语句每引用一次缓冲区页，引用计数器就增加 1。高速缓冲存储器被定期从头到尾进行扫描。由于高速缓冲存储器全部位于内存中，因此这些扫描非常快而且不需要 I/O。在扫描期间，每个缓冲区页首中的引用计数器被 4 除并废弃余数。当引用计数器变为 0 时，将检查脏页指示器。如果为脏页，则调度写操作将修改写入磁盘。SQL Server 实例使用预写日志，因此当记录修改的日志页第一次写入磁盘时将阻塞写入脏数据页。修改的页已刷新到磁盘后，或者如果该页不是脏页，等等，则释放该页。缓冲区页与它所包含的数据页之间的关联被删除，缓冲区被加入到可用列表内。

通过这一进程，经常被引用的页保留在内存中，而存有不被引用的页的缓冲区最终返回到可用缓冲区列表。SQL Server 实例根据高速缓冲存储器的大小在内部确定可用缓冲区列表的大小。无法配置该大小。

当 SQL Server 实例在 Microsoft Windows NT® 或 Windows® 2000 上运行时，扫描缓冲区、写入脏页和填充可用缓冲区列表的工作主要由个别的工作线程完成。工作线程在调度异步读取后与读取完成之间的间隔时间内执行扫描。线程从中央数据结构获得需要扫描的缓冲池下一部分的地址，然后扫描缓冲池的这个部分，同时执行异步读 I/O 进程。如果必须执行写操作，也将异步调度写操作，而写操作并不影响线程处理完成自身读操作的能力。

每个实例都有单独的惰性写入器线程扫描高速缓冲存储器。惰性写入器进程每隔一段时间休眠。当它重新启动时，检查可用缓冲区列表的大小。如果可用缓冲区列表低于某个点（取决于高速缓存的大小），惰性写入器进程将扫描高速缓冲存储器以收回未使用的页并写入引用计数为 0 的脏页。在 Windows NT 或 Windows 2000 操作系统中，大部分填充可用缓冲区列表和写入脏页的工作都由个别的线程完成，惰性写入器线程一般没什么事可做。Windows 95 和 Windows 98 不支持异步写入，因此惰性写入器线程完成填充可用缓冲区列表和写入脏页的工作。

检查点进程还定期扫描高速缓冲存储器，并将任何脏日志或数据页写入磁盘。不同之处是检查点进程不会将缓冲区页放回可用缓冲区列表。检查点进程的工作是使内存中的脏页数减到最小，以减少服务器发生故障时的恢复时间，而不是填充可用缓冲区列表。检查点一般很少会找到要写入磁盘的脏页，因为大部分脏页由两个检查点之间的工作线程或惰性写入器线程写入磁盘。

日志记录的写入通常由惰性写入器线程异步调度。下列情况除外：

  • 提交操作将事务的所有挂起日志记录强行写入磁盘时。

  • 检查点将所有事务的所有挂起日志记录强行写入磁盘时。


分布式查询构架

Microsoft® SQL Server™ 2000 支持两种在 Transact-SQL 语句中引用异类 OLE DB 数据源的方法：

  • 链接服务器名称

    系统存储过程 sp_addlinkedserver 和sp_addlinkedsrvlogin 用于给 OLE DB 数据源提供服务器名称。可以使用由四个部分构成的名称在 Transact-SQL 语句中引用这些链接服务器中的对象。例如，如果链接服务器的名称 DeptSQLSrvr 是用 SQL Server 2000 的另一个复本定义的，下面的语句引用该服务器上的一个表：

    SELECT * FROM DeptSQLSrvr.Northwind.dbo.Employees

    也可以在 OPENQUERY 语句中指定链接服务器的名称以从 OLE DB 数据源打开一个行集。之后，可以在 Transact-SQL 语句中像引用表一样引用该行集。

  • 特殊连接器名称

    在很少引用数据源时，OPENROWSET 或 OPENDATASOURCE 函数是用连接到链接服务器时所需的信息指定的。之后，可以在 Transact-SQL 中使用与引用表相同的方法引用行集：

    SELECT *
FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
        'c:\MSOffice\Access\Samples\Northwind.mdb';'Admin';'';
        Employees)

SQL Server 2000 使用 OLE DB 在关系引擎和存储引擎之间通讯。关系引擎将每个 Transact-SQL 语句分解为一系列操作，这些操作在由存储引擎从基表打开的简单 OLE DB 行集上执行。这意味着关系引擎也可以在任何 OLE DB 数据源上打开简单 OLE DB 行集。

关系引擎使用 OLE DB API 打开链接服务器上的行集，以提取行和对事务进行管理。

对于每个作为链接服务器访问的 OLE DB 数据源，运行 SQL Server 的服务器上必须有 OLE DB 提供程序。在特定 OLE DB 数据源上可执行哪些 Transact-SQL 操作取决于 OLE DB 提供程序的功能。有关更多信息，请参见用于分布式查询的 OLE DB 提供程序参考。

只要可能，SQL Server 就会将联接、限制、投影、排序和分组等关系操作推入 OLE DB 数据源。默认情况下，SQL Server 不将基表扫描进 SQL Server，也不自己执行关系操作。SQL Server 查询 OLE DB 提供程序以确定它支持的 SQL 语法级别，并根据此信息将尽可能多的关系操作推给提供程序。有关更多信息，请参见 OLE DB 提供程序的 SQL 方言要求。

SQL Server 2000 指定 OLE DB 提供程序返回统计信息的机制，该统计信息表明键值在 OLE DB 数据源内的分布情况。这使 SQL Server 查询优化器可以根据每条 SQL 语句的要求，更好地分析数据源中的数据模式，从而提高查询优化器生成最佳执行计划的能力。有关更多信息，请参见 OLE DB 提供程序的分布统计要求。

请参见

配置链接服务器

分布式查询


全文查询构架

Microsoft® SQL Server™ 2000 全文查询组件支持在字符串列上进行复杂搜索。

该项功能由 Microsoft 搜索服务实现，它具有两个作用：

  • 索引支持

    实现为数据库定义的全文目录和索引。接受全文目录以及各目录中组成索引的表和列的定义。执行填充全文索引的请求。

  • 查询支持

    处理全文检索查询。确定索引中满足全文选择条件的项。对于满足选择条件的每一项，它向 MSSQLServer 服务返回行标识外加一个等级值，MSSQLServer 服务将使用这些信息构造查询结果集。所支持的查询类型包括：

    • 检索词或短语。

    • 检索意思相近的词。

    • 检索动词和名词的屈折变化形式。

全文引擎作为 Microsoft Windows NT® Server、Windows NT Advanced Server、Windows® 2000 Server 或 Windows 2000 Advanced Server 上的 Microsoft 搜索服务运行。全文引擎在自定义安装过程中选择全文检索功能时安装。Microsoft 搜索服务本身并不在 SQL Server Desktop Engine 安装过程中安装。虽然这意味着 Microsoft Windows 95、Windows 98、Windows NT Workstation 或 Windows 2000 Professional 客户端上未安装 Microsoft 搜索服务，但是这些客户端可以在连接到 Server 2000 标准版、SQL Server 2000 程序员版或 SQL Server 2000 企业版的实例时使用该服务。

全文目录和索引不存储在 SQL Server 数据库内，而是存储在由 Microsoft 搜索服务单独管理的文件中。在 SQL Server 恢复过程中不恢复全文目录文件。也不能使用 Transact-SQL BACKUP 和 RESTORE 语句备份和还原它们。执行恢复或还原操作后，必须单独重新同步全文目录。只有 Microsoft 搜索服务和 Windows NT 或 Windows 2000 系统管理员可以访问全文目录文件。

SQL Server 与 Microsoft 搜索服务之间通过全文提供程序实现通讯。

Microsoft 搜索服务所支持的全文目录、索引和搜索只适用于 SQL Server 数据库内的表。Windows NT 索引服务和 Windows 2000 索引服务在操作系统文件上提供的功能相似。索引服务包括为 OLE DB 使用者提供的用于索引服务的 OLE DB 提供程序。SQL Server 应用程序可以通过分布式查询访问用于索引服务的 OLE DB 提供程序。Transact-SQL 语句可以通过使用全文 SQL 构造和用于索引服务的 OLE DB 提供程序的分布式查询引用，将引用 SQL Server 表的全文检索与文件数据的文本化搜索结合起来。有关更多信息，请参见文件数据的全文查询。

在任何运行多个 SQL Server 实例的计算机上都只有一个 Microsoft 搜索服务。全文检索引擎的单个实例为计算机上的所有 SQL Server 2000 和 SQL Server 7.0 版实例管理全文索引。

请参见

全文目录和索引

全文索引

全文检索

Microsoft 搜索服务


全文索引支持

下图显示构成全文索引支持的组件。下面是定义、创建和填充全文索引所涉及的组件。

使用下列组件指定是否对数据库和表启用全文索引、定义和填充：

  • SQL Server 企业管理器。

    SQL Server 企业管理器内的数据库树的一个节点用于管理数据库内的全文目录。

  • 使用 SQL 分布式管理对象 (SQL-DMO) 的应用程序。

    SQL-DMO 有用于管理全文目录和索引的对象。

  • 使用 Transact-SQL 和标准数据库 API 的应用程序。

    Transact-SQL 有一组用于管理全文目录和索引的系统存储过程。

其它组件以下面的方式定义和填充全文索引：

  1. 启用用于全文索引的 Microsoft® SQL Server™ 2000 数据库。

  2. 指定数据库的全文目录。

  3. 启用用于全文索引且与目录相关联的个别表。

  4. 每个表中的个别列被添加到表的全文索引中。从第 1 步到第 4 步的所有元数据信息都存储在 SQL Server 数据库内的系统表中。

  5. 逐表激活各表的全文索引。当激活全文表索引时，起始种子值将从 SQL Server 实例发送到 Microsoft 搜索服务内的索引服务。起始种子值标识全文索引所涉及的表。

  6. 基于逐个目录或逐个表来请求填充。基于目录填充使您得以在一个操作中填充多个索引；而填充表则允许填充特定索引。

第 6 步中的填充可以有下列不同形式：

  • 完全填充

    如果为全文目录请求完全填充，则为该目录所涉及的所有表中的所有行生成索引项。如果为表请求完全填充，则为该表中的所有行生成索引项。完全填充通常发生在当首先填充目录或索引，然后使用更改跟踪或增量填充来维护索引时。

  • 更改跟踪填充

    维护在系统表中已修改的行的记录，并将更改传播到全文索引。通过执行 sp_fulltext_table 启动更改跟踪并为 @action 参数指定 start_change_tracking。使用更改跟踪时，也指定从历史表取得更改并在全文索引中填充更改的时间：

    • 后台

      用 start_change_tracking 启动更改跟踪之后，可以通过为 @action 参数指定 start_background_updateindex 来执行 sp_fulltext_table。使用该选项可以在对表中的行进行更改时，将这些更改传播到全文索引。

    • 按需

      在该选项下，当执行 sp_fulltext_table 并为 @action 参数指定 update_index 时，将所有跟踪的更改存储到历史中并只将这些更改传播到全文索引。

    • 已调度

      可以使用 SQL 代理程序调度执行 sp_fulltext_table 并为 @action 参数指定 update_index 的周期性作业。这会将所有未完成的跟踪更改传播到索引。

  • 增量填充

    只调整自上次填充后添加、删除或修改的行的索引项。该功能要求索引表包含 timestamp 数据类型的列。如果表不包含 timestamp 列，则只能执行完全填充或更改跟踪填充。对不包含 timestamp 列的表请求进行增量填充将导致完全填充操作。

    如果为一个此前未与目录相关联的表定义新的全文索引，则对目录的下一个增量填充请求将为该表生成所有的项。

    如果自上次填充后更改了表的任何元数据，增量填充请求将作为完全填充执行。这包括更改列、索引或全文索引定义。

每个填充请求都被发送到 Microsoft 搜索服务内的索引服务：

  • 索引服务将适当的起始种子值传递给 SQL Server 处理程序。起始种子值包含这样的信息：如填充所涉及的表和索引，以及与上次为索引执行的完全填充或增量填充相关联的 timestamp 值（如果表有 timestamp 列）。

  • SQL Server 处理程序是一个驱动程序，包含从全文索引所涉及的 SQL Server 列析取文本数据的逻辑。该处理程序检索来自 SQL Server 的数据并将其传递回索引服务。对于完全填充，SQL Server 处理程序析取表中的所有行。对于增量填充，SQL Server 处理程序只从某些行中析取信息，这些行的当前 timestamp 值高于在起始种子中存储的、与上次填充相关联的 timestamp 值。

  • 之后，索引服务将索引标识符和要建立索引的字符串传递给索引引擎。索引引擎消除 a、and 或 the 这类干扰词，还确定词的边界，并生成一个覆盖从索引服务传递来的词的全文索引。该语言分析因编写文本所用语言的不而异。SQL Server 2000 支持几种语言的语言分析；语言通过 sp_fulltext_column 指定。全文索引存储在全文目录文件中。

  • 在填充的最后，索引服务计算一个新的起始种子值，以记录下一个增量填充的起始点。

请参见

全文目录和索引

全文索引

全文检索

Microsoft 搜索服务


全文查询支持

Microsoft® SQL Server™ 2000 在接收带全文构造的 Transact-SQL 语句时，使用全文提供程序从 Microsoft 搜索服务检索所需信息。全文构造是 CONTAINS 或 FREETEXT 谓词，或者是 CONTAINSTABLE 或 FREETEXTTABLE 行集函数。如果不知道包含搜索条件的列，全文构造可以在全文索引中引用多列。该进程的流程如下图所示。

这一进程涉及的步骤包括：

  1. 应用程序给 SQL Server 实例发送带全文构造的 Transact-SQL 语句。

  2. SQL Server 关系引擎通过查询系统表验证全文构造，确定全文索引是否覆盖列引用。关系引擎将每个 SQL 语句简化为一系列行集操作，并使用 OLE DB 将这些操作传递给基础组件，通常是存储引擎。关系引擎通过全文提供程序而不是存储引擎，将任何全文构造转换成对行集的请求。请求的行集是满足搜索条件和等级的键集，而这个等级表示每个键的数据满足搜索条件的程度。向全文提供程序发送的行集请求命令包括全文检索条件。

  3. 全文提供程序验证请求并将搜索条件更改为由Microsoft 搜索服务的查询支持组件使用的形式。将请求发送到搜索服务。

  4. 查询支持组件使用搜索引擎组件从全文索引析取所请求的数据。然后以行集的形式将这些数据传递回全文提供程序。

  5. 全文提供程序将这个行集返回给关系引擎。

  6. 关系引擎将它从存储引擎和全文提供程序收到的所有行集进行组合，以生成发送回客户端的最终结果集。

请参见

全文目录和索引

全文索引

全文检索

Microsoft 搜索服务


扩展存储过程构架

Microsoft® SQL Server™ 2000 扩展存储过程使您能够在动态链接库 (DLL) 文件所包含的函数中实现逻辑，从而扩展了 Transact-SQL 的功能，并且可以象调用 Transact-SQL 过程那样从 Transact-SQL 语句调用这些函数。动态链接库文件的文件扩展名为 .dll。扩展存储过程可以包括 Microsoft Win32® 和 COM 应用程序的大多数功能。

DLL 文件必须遵从扩展存储过程 API 才能作为扩展存储过程运行。对于 SQL Server，.dll 可以包含多个标识为扩展存储过程的函数；每个函数都由单独的扩展存储过程名标识。当 Transact-SQL 语句引用其中一个扩展存储过程时，关系数据库引擎调用与该扩展存储过程名相关联的函数。扩展存储过程可以与调用它们的 SQL Server 实例重新建立连接，或者连接到远程 SQL Server 安装。

扩展存储过程是关系数据库引擎的开放式数据服务层的一部分，而开放式数据服务层是该引擎和服务器 Net-library 之间的接口。服务器 Net-Library 接收客户端 TDS 数据包并将它们传递给开放式数据服务。开放式数据服务将 TDS 数据包转换成事件并传递到关系数据库引擎的其它部分。数据库引擎然后使用开放式数据服务，通过服务器 Net-Library 将回复发送回 SQL Server 客户端。

当关系数据库引擎确定 Transact-SQL 语句引用扩展存储过程时：

  • 关系数据库引擎将扩展存储过程请求传递到开放式数据服务层。

  • 然后开放式数据服务将包含扩展存储过程函数的 DLL 装载到 SQL Server 2000 地址空间（如果还没有装载）。

  • 开放式数据服务将请求传递到扩展存储过程。

  • 开放式数据服务将操作结果传递到数据库引擎。

过去，还使用开放式数据服务 API 编写服务器应用程序，例如连接到其它数据库系统的网关。这种应用程序已被更新的技术取代，这些技术包括：

  • 支持多个不同的数据库和其它数据源（如 OLE DB 和 ODBC）的数据库API。

    写入 OLE DB 或 ODBC API 的应用程序几乎不需要通过网关访问不同的数据库。

  • SQL Server 2000 支持异类分布式查询，使得 Transact-SQL 查询不必使用专门的服务器应用程序就能从任何 OLE DB 数据源中拉出数据。

  • MS DTC 使分布式事务处理得以跨越多个数据库进行。

  • Windows NT 组件服务，用于运行中层应用程序逻辑。

SQL Server 2000 不支持开放式数据服务 API 的废弃部分。对于原始的开放式数据服务 API，SQL Server 2000 仍支持的唯一部分是扩展存储过程，因此已将 API 重命名为扩展存储过程 API。

请参见

编写扩展存储过程


远程存储过程构架

远程存储过程是 Microsoft® SQL Server™ 2000 的一个传统功能。它们在 Transact-SQL 中的功能仅限于在远程 SQL Server 安装上执行存储过程。SQL Server 7.0 版引入的分布式查询支持这个功能，还支持直接通过本地 Transact-SQL 语句访问链接的异类 OLE DB 数据源上的表。在 SQL Server 2000 上不是使用远程存储过程调用，而是使用分布式查询和 EXECUTE 语句在远程服务器上执行存储过程。

SQL Server 2000 实例可以对 SQL Server 2000 和 SQL Server 7.0 版的实例发送和接收远程存储过程调用。SQL Server 2000 实例还可以对 SQL Server 6.0 版或对 SQL Server 6.5 版的实例发送和接收远程存储过程调用。运行 SQL Server 2000 的服务器可以从 SQL Server 4.21a 版的实例接收远程存储过程调用，但是 SQL Server 2000 实例无法对 SQL Server 4.21a 版的实例调用远程存储过程。SQL Server 4.21a 版的实例无法识别 SQL Server 2000 使用的表格格式数据流 (TDS) 版。

远程存储过程协议优化

用于 SQL Server 的 Microsoft OLE DB 提供程序和 SQL Server ODBC 驱动程序，都使用当初为支持远程存储过程而引入的 TDS 协议性能优化。在 SQL 事件探查器跟踪中可以看到此优化的使用情况。

SQL 事件探查器跟踪 SQL Server 实例中的事件，例如，在应用程序和 SQL Server 实例之间发送的表格格式数据流 (TDS) 数据包的接收和返回。TDS 是为 SQL Server 客户端/服务器通讯定义的应用程序级协议。

当应用程序发送要执行的 Transact-SQL 批处理命令时，使用执行 SQL 的通用数据包，这个通用数据包在 SQL 事件探查器跟踪中作为 SQL:BatchStarting 和 SQL:BatchCompleted 事件出现。当 SQL Server 的一个实例给 SQL Server 的另一个实例发送要求执行远程存储过程的请求时，使用专用的 RPC TDS 数据包。RPC 数据包被调整，以满足传输执行存储过程请求的需要。关系引擎也识别出这是一个专用数据包，并执行一些优化以加快存储过程的执行。这些在 SQL 事件探查器跟踪中作为 RPC:Starting 和 RPC:Completed 事件出现。

SQL Server 2000 并不仅限于在服务器之间的通讯中使用这些专用 RPC 数据包。在下列两种情况下，用于 SQL Server 的 OLE DB 提供程序和 SQL Server ODBC 驱动程序利用这个专用 RPC 数据包提高性能：

  • 如果应用程序使用 ODBC CALL 语法执行存储过程。

  • 当提供程序或驱动程序在内部生成对系统存储过程的调用时。

用户在从使用提供程序或驱动程序的应用程序分析 SQL 事件探查器跟踪时，可以看到这些 RPC TDS 事件。

请参见

配置远程服务器

调用存储过程

执行存储过程

调用存储过程 (OLE DB)

TSQL 事件分类


事务构架

尽管系统中发生错误，Microsoft® SQL Server™ 2000 仍然维持每个数据库的一致性和完整性。每个更新 SQL Server 数据库内数据的应用程序都使用事务完成这个任务。事务是由一系列语句（选择、插入、更新或删除）构成的逻辑工作单元。如果在事务执行过程中没有遇到错误，则事务中的所有修改成为数据库的永久部分。如果遇到错误，则不对数据库做任何修改。

事务经历下面几个阶段：

  • 事务启动前，数据库处于一致状态。

  • 应用程序发出启动事务的信号。这可以通过 BEGIN TRANSACTION 语句显式完成。或者，应用程序也可以设置在隐性事务模式下运行的选项；使新事务由前面的事务完成后所执行的第一个 Transact-SQL 语句自动启动。此时不向日志写入记录；当应用程序为数据修改生成第一个日志记录时，才向日志写入第一个记录。

  • 应用程序开始修改数据。一次只修改一个表中的数据。随着一系列的修改，数据库可能会处于暂时不一致的中间状态。

  • 当应用程序执行到全部修改均已成功完成且数据库再次处于一致状态时，应用程序提交事务。这使全部修改成为数据库的永久部分。

  • 如果应用程序遇到一些防碍事务完成的错误，则撤消或回滚所有数据修改。这将使数据库返回到事务启动前所处于的一致状态。

SQL Server 应用程序还可以在自动提交模式下运行。在自动提交模式下，如果成功则自动提交各个 Transact-SQL 语句，如果生成错误则自动回滚各个 Transact-SQL 语句。在自动提交模式下运行的应用程序不需要发出专门启动或结束事务的语句。

所有的 Transact-SQL 语句都在下列事务中运行：显式事务、隐性事务或自动提交事务。所有包含数据修改的 SQL Server 事务要么到达新的一致点并提交，要么回滚到原始的一致点。事务不会被留在使数据库不一致的中间状态中。

请参见

事务


事务恢复

每个 Microsoft® SQL Server™ 2000 数据库都有一个事务日志记录数据库内的数据修改。日志记录每个事务的开始和结束并将每个修改与一个事务相关联。SQL Server 实例在日志中存储足够的信息以恢复（前滚）或撤消（回滚）构成事务的数据修改。日志中的每条记录都由一个唯一的日志序号 (LSN) 标识。事务的所有日志记录都链接在一起。

SQL Server 实例在事务日志中记录多种不同类型的信息。SQL Server 2000 实例主要将所执行的逻辑操作记入日志。重新应用操作将前滚修改，反向执行逻辑操作将回滚修改。

每个 SQL Server 实例都控制将修改从其数据缓冲区写入磁盘的时间。SQL Server 实例可以将修改在缓冲区内高速缓存一段时间以优化磁盘写入。包含尚未写入磁盘的修改的缓冲区页称为脏页。将脏缓冲区页写入磁盘称为刷新页。对修改进行高速缓存时，务必注意确保在将相应的日志映像写入日志文件之前没有刷新任何数据修改。否则将产生不能在需要时进行回滚的修改。为确保能恢复所有修改，SQL Server 实例使用预写日志，这意味着所有日志映像都在相应的数据修改前写入磁盘。

提交操作将事务的所有日志记录强行写入日志文件，以使事务可以完全恢复，即使服务器已经关闭。只要所有日志记录都已刷新到磁盘，提交操作便不必将所有修改的数据页都强行刷新到磁盘。系统恢复可以只使用日志记录前滚或回滚事务。

SQL Server 实例定期确保刷新所有脏日志和数据页。这称为检查点。检查点减少了重新启动 SQL Server 实例时恢复所需的时间和资源。有关检查点处理的更多信息，请参见检查点和日志的活动部分。

回滚个别事务

如果在事务执行过程中出现任何错误，SQL Server 实例将使用日志文件中的信息回滚事务。这个回滚不影响同时在数据库内工作的任何其它用户的工作。通常情况下，错误被返回给应用程序，如果错误表明事务可能有问题，则应用程序发出 ROLLBACK 语句。一些错误（如 1205 号死锁错误）会自动回滚事务。如果在事务活动时由于任何原因中断了客户端和SQL Server 实例之间的通讯，SQL Server 实例将在收到网络或操作系统发出的中断通知时自动回滚事务。如果客户端应用程序终止，客户端计算机关闭或重新启动，或者如果客户端网络连接中断，可能会发生这种情况。在所有这些错误情况下，将回滚任何未完成的事务以保护数据库的完整性。

启动时恢复所有未完成的事务

SQL Server 实例有时可能停止处理（例如，如果操作员在用户正与数据库连接并进行工作时重新启动服务器）。这可能造成两个问题：

  • 可能有未知数目的 SQL Server 事务在实例停止时只部分完成。需要回滚这些未完成的事务。

  • 可能有未知数目的数据修改记录在 SQL Server 数据库日志文件中，但被修改的相应的数据页在服务器停止前没有刷新到数据文件。必须前滚任何已提交的修改。

每次启动 SQL Server 实例时，它都必须找出是否存在这些情况并加以解决。实例中的每个 SQL Server 数据库都采用下列步骤：

  • 与最小恢复 LSN 一起从数据库引导块读取上一个检查点的 LSN。

  • 从事务日志的最小恢复 LSN 扫描到日志的末端。通过重做日志记录中记录的逻辑操作前滚所有提交的脏页。

  • SQL Server 实例然后通过反向应用日志记录中记录的逻辑操作，向后扫描日志文件以回滚所有未完成的事务。

除非用户指定 NORECOVERY 选项，否则 RESTORE 语句也使用这种恢复类型。还原数据库序列、差异备份或日志备份以将数据库恢复到某个故障点时，在所有 RESTORE 语句上指定 NORECOVERY，但还原上次日志备份时除外。还原序列中的最后一次备份时，RESTORE 语句还必须确保回滚所有未完成的事务。在该 RESTORE 语句上指定 RECOVERY 选项，在这种情况下，该语句使用与启动恢复进程相同的逻辑回滚在最后一个日志的结尾处仍标记为未完成的所有事务。


并发构架

当许多人试图同时修改数据库内的数据时，必须执行控制系统以使某个人所做的修改不会对他人产生负面影响。这称为并发控制。

并发控制理论因创立并发控制的方法不同而分为两类：

  • 悲观并发控制

    锁定系统阻止用户以影响其它用户的方式修改数据。如果用户执行的操作导致应用了某个锁，则直到这个锁的所有者释放该锁，其它用户才能执行与该锁冲突的操作。该方法主要用在数据争夺激烈的环境中，以及出现并发冲突时用锁保护数据的成本比回滚事务的成本低的环境中，因此称该方法为悲观并发控制。

  • 乐观并发控制

    在乐观并发控制中，用户读数据时不锁定数据。在执行更新时，系统进行检查，查看另一个用户读过数据后是否更改了数据。如果另一个用户更新了数据，将产生一个错误。一般情况下，接收错误信息的用户将回滚事务并重新开始。该方法主要用在数据争夺少的环境内，以及偶尔回滚事务的成本超过读数据时锁定数据的成本的环境内，因此称该方法为乐观并发控制。

Microsoft® SQL Server™ 2000 支持广泛的乐观和悲观并发控制机制。通过指定下列各项，用户可以指定并发控制类型：

  • 用于连接的事务隔离级别。

  • 游标上的并发选项。

这些特性可以通过 Transact-SQL 语句或数据库 API（如 ADO、OLE DB 和 ODBC）的属性和特性定义。

请参见

四个并发问题

游标并发


锁定构架

锁是由软件使用的对象，用于表明用户与资源有某种相关性。软件不允许其它用户在资源上执行将对拥有锁的用户的相关性产生负面影响的操作。锁由系统软件在内部管理，并基于用户所执行的操作被获取和释放。

Microsoft® SQL Server™ 2000 使用锁在多个同时在数据库内执行修改的用户间实现悲观并发控制。默认情况下，SQL Server 基于每个连接管理事务和锁。例如，如果应用程序打开两个 SQL Server 连接，由一个连接获取的锁不能与另一个连接共享。两个连接都不能获取将与另一个连接所控制的锁冲突的锁。只有绑定连接不受该规则的影响。有关更多信息，请参见使用绑定连接。

SQL Server 锁在数据库内的不同粒度级别上应用。可以为行、页、键、键范围、索引、表或数据库获取锁。SQL Server 动态确定每个 Transact-SQL 语句的锁的适当的放置级别。获取锁的级别可能因同一查询所引用的不同对象而异；例如一个表可能很小，因此应用表锁，而另一个大表则可以应用行锁。应用表锁的级别不必由用户指定，而且不需要管理员配置。SQL Server 实例确保在一个粒度级上授予的锁不妨碍在另一个级别上授予的锁。例如，如果 UserA 试图在行上获取共享锁，SQL Server 实例也会试图在页和表上获取意向共享锁。如果 UserB 在页或表级上有一个排它锁，UserA 将被阻塞，直到 UserB 控制的锁被释放才能获取锁。

有几种锁模式：共享锁、更新锁、排它锁、意向锁和架构锁。锁模式表明连接与锁定对象所具有的相关性等级。SQL Server 控制锁模式的交互方式。例如，如果其它连接对资源具有共享锁，则不能获得排它锁。

锁保持的时间长度为保护所请求级别上的资源所需的时间长度。

  • 用于保护读取操作的共享锁的保持时间取决于事务隔离级别。采用 READ COMMITTED 的默认事务隔离级别时，只在读取页的期间内控制共享锁。在扫描中，直到在扫描内的下一页上获取锁时才释放锁。如果指定 HOLDLOCK 提示或者将事务隔离级别设置为 REPEATABLE READ 或 SERIALIZABLE，则直到事务结束才释放锁。

  • 根据为游标设置的并发选项，游标可以获取共享模式的滚动锁以保护提取。当需要滚动锁时，直到下一次提取或关闭游标（以先发生者为准）时才释放滚动锁。但是，如果指定 HOLDLOCK，则直到事务结束才释放滚动锁。

  • 用于保护更新的排它锁将直到事务结束才释放。

如果一个连接试图获取一个锁，而该锁与另一个连接所控制的锁冲突，则试图获取锁的连接将一直阻塞到：

  • 将冲突锁释放而且连接获取了所请求的锁。

  • 连接的超时间隔已到期。默认情况下没有超时间隔，但是一些应用程序设置超时间隔以防止无限期等待。

如果几个连接因在某个单独的资源上等待冲突的锁而被阻塞，那么在前面的连接释放锁时将按先来先服务的方式授予锁。

SQL Server 有一个算法可以检测死锁，即两个连接互相阻塞的情况。如果 SQL Server 实例检测到死锁，将终止一个事务，以使另一个事务继续。有关更多信息，请参见死锁。

SQL Server 可以动态升级或降级锁粒度或锁类型。例如，如果更新获取大量行锁而阻塞了表的大部分，将行锁升级到表锁。如果获取了表锁，将释放行锁。SQL Server 2000 很少需要升级锁；查询优化器在编译执行计划时通常选择正确的锁粒度。有关更多信息，请参见锁升级和动态锁定。

请参见

锁定

游标锁定


闩锁

闩锁是不重要的短期同步对象，用于保护在整个事务过程中不需要锁定的操作。它们主要用于在为连接读取行时对行进行保护。

当关系引擎处理查询时，每当需要基表或索引内的行时，关系引擎便使用 OLE DB API 请求存储引擎返回该行。当存储引擎正在积极地将行传输到关系引擎时，存储引擎必须确保没有其它任务修改该行的内容或某些页结构（如定位所读行的页偏移表条目）。存储引擎通过获取闩锁，将内存内的行传输到关系引擎，然后释放闩锁来完成这个任务。

SQL Server 性能监视器有一个 Latches 对象，该对象表明不能立即授予闩锁的次数以及线程等待被授予闩锁所需的时间。

请参见

SQL Server:Latches 对象


分布式事务构架

分布式事务是涉及来自两个或多个源的资源的事务。Microsoft® SQL Server™ 2000 支持分布式事务，使用户得以创建事务来更新多个 SQL Server 数据库和其它数据源。

分布式事务包括：

  • 资源管理器

    控制分布式事务所涉及的每个资源的软件称为资源管理器。分布式事务由各个资源管理器内的本地事务组成。每个资源管理器必须能够与分布式事务内的所有其它资源管理器相协调，以提交或回滚自己的本地事务。SQL Server 可以作为分布式事务内的资源管理器工作，并遵从用于分布式事务处理的 X/Open XA 规范。

  • 事务管理器

    提交或回滚分布式事务由称为事务管理器的软件组件控制。事务管理器与每个资源管理器相协调，确保一起提交或回滚所有组成分布式事务的本地事务。Microsoft 分布式事务处理协调器 (MS DTC) 服务如事务管理器一样工作。MS DTC 遵从用于分布式事务处理的 X/Open XA 规范。

  • 两阶段提交 (2PC)

    需要进行特殊的提交处理，以防止在管理跨越多个资源管理器的事务时出现问题。当刷新日志缓冲区使其可用时，提交大事务可能需要相对较长的时间。提交进程本身还可能遇到错误，需要强行回滚。如果事务管理器只是请求每个资源管理器提交，则可能从一些资源管理器返回成功状态，然后从某个资源管理器得到错误信息。这会导致冲突，因为所有分布式事务都应回滚，而部分事务已提交。两阶段提交通过将提交分成两相可以解决此问题：

    • 准备

      事务管理器给每个资源管理器发送一个准备提交的请求。然后，每个资源管理器执行完成提交进程所需的所有大量占用资源的操作，如刷新所有日志缓冲区。资源管理器只保留维护事务完整性所需的最少的锁，然后给事务管理器返回成功状态。

    • 提交

      如果所有资源管理对发给它们的准备请求返回成功状态，事务管理器将给每个资源管理器发送提交命令。然后，每个资源管理器快速将事务记录为已完成，并释放上次控制的资源。如果有任何资源管理器对准备请求返回错误信息，事务管理器将给每个资源管理器发送回滚命令。

有几种方法可以使应用程序在分布式事务内包括 SQL Server 2000：

  • 如果应用程序有本地事务并且发出分布式查询，本地事务将升级到分布式事务。

  • 发出 BEGIN DISTRIBUTED TRANSACTION 语句。

  • 如果应用程序有本地事务并且将 REMOTE_PROC_TRANSACTIONS 选项设置为 ON，则调用远程存储过程将使本地事务升级到分布式事务。

  • 使用用于 SQL Server 的 OLE DB 提供程序或 SQL Server ODBC 驱动程序的应用程序，可以使用 OLE DB 方法或 ODBC 函数让 SQL Server 连接联接由应用程序启动的分布式事务。

请参见

分布式事务

MS DTC 服务


游标构架

所有 SQL 语句都在行集上运行。SELECT 语句返回包含所有满足 SELECT 语句限定条件的行的完整结果集。应用程序需要一次处理结果集的一行或一个行块。游标是结果集的逻辑扩展，它使应用程序得以逐行处理结果集。

Microsoft® SQL Server™ 2000 支持多种指定游标的机制：

  • Transact-SQL 支持用于管理游标的 SQL-92 DECLARE CURSOR、OPEN、FETCH 和 CLOSE 语句。Transact-SQL 还支持游标扩展，如：
    • 允许对重新使用游标进行优化的 DEALLOCATE 语句。

    • 定义 Transact-SQL 变量以具有游标数据类型，然后用它引用游标。

    • 定义具有局部或全局作用域的游标。

    • 在 DECLARE CURSOR 语句内指定符合 OLE DB 和 ODBC 规范的游标类型（FORWARD_ONLY、STATIC、KEYSET 和 DYNAMIC）。
  • 用于 SQL Server 的 Microsoft OLE DB 提供程序支持 ADO 和 OLE DB API 的游标功能。

  • Microsoft SQL Server ODBC 驱动程序支持 ODBC、RDO、DAO 和 Microsoft 基础类数据库类 API 的游标功能。

  • 用于 C 语言的 Microsoft 嵌入式 SQL 支持嵌入式 SQL 标准的游标功能。

  • DB-Library API 支持与 OLE DB 和 ODBC API 相同级别的游标功能。

请参见

游标


SQL Server 可伸缩性

Microsoft® SQL Server™ 2000 在性能频谱的两端扩展 SQL Server 的可伸缩性。在 Microsoft Windows NT® 和 Windows® 2000 上运行的 SQL Server 2000 数据库引擎包括对 64 GB 物理内存和分布式分区视图等项目的支持，使您得以实现可根据最大型 Web 站点或企业数据系统处理要求进行升级的数据库服务器组。SQL Server CE 还可以在 Microsoft Windows CE 上运行，这为流动用户提供了增强的支持。这些增强使 SQL Server 2000 成为管理多种类型的数据库的较佳选择，从 Windows CE 设备上的 KB 大小的个人数据库到由成千上万 Internet 用户访问的 TB 数据库都可以管理。


大型服务器上的 SQL Server 2000

Microsoft® SQL Server™ 2000 和 SQL Server 7.0 版的主要设计目标之一就是提高执行数据库支持大型 Web 站点和企业系统的能力。尽管早期版本的 SQL Server 在支持大量并发用户方面表现很好，但是其运行实用工具、进行备份和还原操作所需的时间将可管理的 SQL Server 数据库大小限制在大约 200 GB 至 300 GB 之间。

SQL Server 2000 企业版能够处理由成千上万并发用户使用的 TB 数据库。使之得以实现的一些功能有：

  • 在运行 Microsoft Windows® 2000 DataCenter 的 SMP 计算机上，SQL Server 企业版可以有效地升级为多达 32 个微处理器。

  • SQL Server 2000 企业版在 Windows 2000 DataCenter 上可以使用高达 64 GB 的物理内存 (RAM)。有关更多信息，请参见使用 Windows 2000 上的 AWE 内存。

  • SQL Server 2000 企业版支持分布式分区视图，这使数据库服务器组得以支持大型 Web 站点或企业系统的工作负荷。这样的服务器组或联合体必须单独管理，但其提供的性能级别与数据库服务器群集相同。有关更多信息，请参见联合 SQL Server 2000 服务器。

  • SQL Server 2000 企业版支持索引视图。在视图上创建索引将使视图具体化，而且可以与表相同的格式存储其结果集。这对于某些视图类型将成倍地提高性能。有关更多信息，请参见视图索引。

  • 磁盘上的数据结构支持并行处理和连续的预读扫描。现在可以执行串行表扫描和索引扫描，这在确定数据仓库特性的联机分析处理 (OLAP) 中尤为有用。有关更多信息，请参见 I/O 构架。

  • SQL Server 2000 现在可以在本机支持用于执行 SQL 语句的准备/执行模型。它还有在连接之间共享查询执行计划的逻辑，而不需要应用程序准备语句。这些功能减少了与编译和执行语句有关的开销。有关更多信息，请参见执行计划的高速缓存和重新使用。

  • 哈希和合并联接类型提高了联接性能。有关更多信息，请参见高级查询优化概念。

  • SQL Server 2000 在有多个微处理器（即 CPU）的服务器上支持查询内并行度。单个 SQL 语句可以分成两个或更多的并发执行任务，以便更快地返回结果。有关更多信息，请参见并行查询处理。

  • SQL Server 2000 评估 SQL 语句并动态选择锁定粒度（行、页、表）以使并发吞吐量最大。有关更多信息，请参见锁定构架。

  • SQL Server 2000 使用 Microsoft Windows NT® 和 Windows 2000 异步 I/O 和散播-聚集 I/O 以及高速缓冲存储器管理算法来优化 OLAP 性能。有关更多信息，请参见 I/O 构架。

  • 在生产操作中，BACKUP 和 RESTORE 语句的速度足够运行这些语句，因为它们不会影响数据库的活动。当在多个备份设备上存储备份时，BACKUP 和 RESTORE 使用并行 I/O。BACKUP 选项（如差异备份和只备份文件或文件组）可减小备份的大小及其对系统的影响。有关更多信息，请参见备份/还原构架。

  • SQL Server 2000 和 SQL Server 7.0 的磁盘上数据结构比早期版本简单得多，因此也更可靠。另外，对数据库引擎进行了编码，使其在处理过程中较早地探测到错误，并在错误导致数据库本身出现问题前终止任务（快速失败逻辑）。这些改进使磁盘上结构出现的问题更少，并减少或消除了执行数据库完整性检查的需要。

  • SQL Server 2000 和 SQL Server 7.0 中的数据库完整性检查语句的算法比早期版本快得多。完整性检查语句现在可以在扫描数据库期间，对数据库执行单个连续扫描，并以并行方式检查对象。有关更多信息，请参见数据完整性验证。

  • SQL Server 2000 和 SQL Server 7.0 版大容量复制组件现在能够以更快的速度传输数据。bcp 大容量复制实用工具现在可以并行方式同时将数据从多个源复制到同一个文件中。有关更多信息，请参见并行数据装载。

  • SQL Server 2000 和 SQL Server 7.0 版现在支持直接在服务器上进行大容量装载，而无需通过客户端传输数据。这项工作由新的 BULK INSERT 语句完成，这是将大量数据装载到表中的最快方法。有关更多信息，请参见 BULK INSERT。

  • 分发内容统计表明索引键的选择性，由查询优化器在编译查询时用来选择最有效的索引。如果统计过期，优化器可能无法生成最佳执行计划。可以设置 SQL Server 2000 自动生成分发内容统计，这将提高查询优化器的效率。生成统计的采样进程也得到改进，它们现在为生成可靠的统计所要扫描的数据比 SQL Server 早期版本少。有关更多信息，请参见统计信息。

  • SQL Server 2000 定义了 OLE DB 扩展，OLE DB 提供程序可以使用这些扩展将分发内容统计报告给 SQL Server 2000 数据库引擎。这使得引擎可以更有效地优化分布式查询。用于 SQL Server 2000 的 Microsoft OLE DB 提供程序支持这些扩展，从而提高了分布式查询引用 SQL Server 数据库的性能。有关更多信息，请参见OLE DB 提供程序的分布统计要求。

  • SQL Server 包括对故障转移群集的支持。两到四个 Windows NT 或 Windows 2000 服务器可以有 SQL Server 实例，而且都可以访问拥有 SQL Server 数据库的群集磁盘集，每个实例都由单个虚拟服务器名标识。如果当前处理 SQL Server 请求的服务器发生故障，则其它 Windows 服务器中有一个将启动其 SQL Server 服务，恢复数据库日志中记录的任何未完成的事务，并代替发生故障的服务器开始运行。有关更多信息，请参见故障转移群集构架。

  • SQL Server 2000 引入了可用于维护备用服务器的日志传送功能。定期备份生产服务器的事务日志，并将其应用到备用服务器。如果生产服务器发生故障，则可以将备用服务器联机以代替生产服务器。有关更多信息，请参见日志传送。


桌面上的 SQL Server 2000数据库

还可以将这个支持成千上万个并发用户的 Microsoft® SQL Server™ 2000 数据库引擎安装在运行 Microsoft Windows® 98、Microsoft Windows NT® Workstation 或 Windows 2000 Professional 的膝上型电脑或台式机上。在这些操作系统上运行的 SQL Server 2000 有两种版本：

  • SQL Server 2000 个人版

    在个人工作站或小型工作组服务器上使用的 SQL Server 2000 版本。SQL Server 2000 个人版包括随 SQL Server 2000 标准板和 SQL Server 2000 企业版提供的管理工具（如 SQL Server 企业管理器）。

  • SQL Server 2000 Desktop Engine

    SQL Server 关系数据库引擎的可再分发版本，第三方软件开发商可以将其包括在使用 SQL Server 存储数据的应用程序中。SQL Server 2000 Desktop Engine 可作为一组 Windows 安装程序合并模块使用，并且可以包含在应用程序安装中。

    SQL Server 2000 Desktop Engine 不包括图形管理工具；分发引擎的应用程序通常被编码为执行任何需要的数据库管任务。可以通过 SQL Server 2000 图形工具管理随其它 SQL Server 版本一起安装的 Desktop Engine 实例。

    SQL Server 2000 Desktop Engine 支持所有编程 API 和 SQL Server 2000 其它版本的大多数功能，还包括用于管理调度任务的 SQLServerAgent 服务。虽然 Desktop Engine 不包括管理工具和向导，但是应用程序可以使用 SQL Server管理 API 充分管理 Desktop Engine 实例，如使用 SQL-DMO、DTS、复制编程对象或常规数据库 API（如 ADO、OLE DB 和 ODBC）。应用程序可以使用常规数据库 API 访问 Desktop Engine 中的数据，而且 Desktop Engine 可与 SQL Server 2000 的其它版本一起参与 DTS 转换和复制计划（但不能作为事务复制发布服务器运行）。有关 Desktop Engine 支持的功能的更多信息，请参见 SQL Server 2000 的各种版本所支持的功能。

对 SQL Server 2000 这两个版本中包括的数据库引擎已进行了调整，使其能够支持单个用户或小型工作组的典型工作负荷。数据库引擎为桌面用户提供的功能和 SQL Server 2000 标准版及 SQL Server 2000 企业版的功能基本上相同；不过，有两个例外：

  • 不支持主要在大型生产数据库中使用的某些功能，如并行语句处理和索引视图。有关 SQL Server 2000 各种版本中可用功能的更多信息，请参见 SQL Server 2000 的各种版本所支持的功能。

  • 并发工作负荷调控器限制了数据库引擎的性能。当同时执行五个以上的批处理命令时，个别 Transact-SQL 批处理命令的性能将降低。每个批处理命令性能降低的程度取决于除五个批处理命令外还有多少个批处理命令在同时执行，以及各批处理命令检索的数据量。同时执行的批处理命令越多，以及每个批处理命令检索的数据越多，调控器降低个别批处理命令性能的程度也越大。可以使用 DBCC CONCURRENCYVIOLATION 语句报告激活并发工作负荷调控器的频率。有关更多信息，请参见 DBCC CONCURRENCYVIOLATION。

同时，数据库引擎的易用特性使得用户只须做最少的配置调整即可使其运行在膝上型电脑或桌面环境中。数据库引擎自动对自身进行配置，以便根据需要获取或释放资源，如内存和磁盘空间。这意味着可以在最终用户的膝上型电脑或台式机上运行 SQL Server 2000 个人版和 SQL Server 2000 Desktop Engine，而不需要用户或数据库管理员始终调整数据库。

SQL Server 2000 个人版和 SQL Server 2000 Desktop Engine 支持的编程模型与 SQL Server 2000 标准版和 SQL Server 2000 企业版支持的一样。应用程序在所有 SQL Server 2000 版本中都使用相同的 API（如 ADO、OLE DB、ODBC、SQL-DMO等）访问数据。唯一的不同是级别更高的版本所支持的功能集（如故障转移群集或联合数据库服务器），虽然对大多数应用程序而言，这些功能中的大部分都是透明的管理功能或可伸缩的功能。

SQL Server 2000 中使用的数据库引擎支持优化，这使小型膝上型电脑或桌面系统的性能达到最佳，而且只占用很少的内存：

  • 数据库的内部数据结构（如混合扩展盘区）可以显著减小小型数据库或含许多小表的数据库的大小。

  • 当 SQL Server 在默认配置设置下运行时，会针对计算机上当前资源的使用情况对自身进行动态配置，而无须用户发出优化命令。

  • 很多在 SQL Server 6.5 版或更早版本中不得不手工设置的配置选项，已被数据库引擎中的内部逻辑所取代，该逻辑根据负荷自动配置这些选项。

  • 不用再手工更新分发内容统计；这些统计将自动更新。

  • 数据库文件根据数据量自动增长或收缩。

SQL Server 2000 的复制功能以及数据库引擎附加和分离数据库的能力，为有膝上型电脑的移动及脱接用户提供了一个很好的解决方案。这些用户可以定期连接到地区或部门的服务器，通过复制功能与主数据库重新同步数据库信息。或者，可以将数据库放在压缩磁盘上发送给远程用户，而远程用户只须将磁盘连接在他们的服务器上即可获得最新信息。


Windows 98 上的 SQL Server 2000

Microsoft® SQL Server™ 2000 包括两种可在 Microsoft Windows® 98 上运行的主要软件类型：

  • 客户端软件

    SQL Server 客户端访问许可协议包括的所有用户，都可以在 Microsoft Windows 98 计算机上安装 SQL Server 客户端软件。可以使用 SQL Server 安装选项"仅客户端工具"或"仅连接"，从支持 SQL Server 2000 标准版、SQL Server 2000 企业版或 SQL Server 2000 专业版的光盘安装客户端软件。客户端软件还经常由使用 SQL Server 存储数据的应用程序安装。SQL Server 2000 客户端软件还可在 Microsoft Windows 95 上运行。

  • 服务器软件

    任何购买了 SQL Server 2000 个人版的用户，都可以在运行 Windows 98 操作系统的计算机上，从 SQL Server 2000 个人版安装服务器软件。应用程序可以在 Windows 98 上安装 SQL Server 2000 桌面版。

Windows 98 和 Windows 95 上的 SQL Server 客户端软件

SQL Server 2000 客户端软件包括：

  • 用于管理 SQL Server 和执行 SQL Server 数据库特殊查询的实用工具。

  • 连接组件，例如用于 SQL Server 的 OLE DB 提供程序、SQL Server ODBC 驱动程序和客户端 Net-Library。任何连接到 SQL Server 实例的应用程序都使用这些连接组件。

SQL Server 2000 客户端软件在 Windows 98 或 Windows 95 计算机上运行的内容与其在 Microsoft Windows NT® 或 Windows 2000 计算机上运行的相同，但下列情况除外：

  • Windows 98 和 Windows 95 网络转向器不提供计算机浏览器支持。依靠这一功能获得服务器列表的 SQL Server 对话框不会在 Windows 98 或 Windows 95 上显示服务器列表。这包括"注册服务器"对话框、注册服务器向导和"查询分析器登录"对话框。

  • SQL Server 实用工具在 Windows 95 上不受支持。而在 Windows 98 上则受支持。
  • 轮询服务器状态的 SQL Server 工具（SQL Server 企业管理器、SQL Server 代理程序）必须按用户定义的轮询服务状态间隔积极地完成这项工作。
Windows 98 上的 SQL Server 2000 服务器组件

SQL Server 2000 个人版和 SQL Server 2000 Desktop Engine 是可在 Windows 98 上安装其服务器组件的唯一版本。

当SQL Server 2000 个人版和 SQL Server 2000 Desktop Engine 在 Windows 98 计算机上运行时，不能使用下列功能：

  • 无法在 Windows 98 上安装命名管道和 Banyan VINES 服务器 Net-Library。Windows 98 也不支持服务器 NWLink IPX/SPX Net-Library。在运行 Windows 98 操作系统的计算机上，SQL Server 2000 实例无法接受使用这些协议的连接。虽然 Windows 98 不支持这些服务器 Net-Library，但确实支持客户端 Net-Library。在 Windows 98 计算机上运行的 SQL Server 客户端，可以使用这些协议连接到 Windows NT 或 Windows 2000 计算机上的 SQL Server 实例。

  • 在 Windows 98 上不支持客户端和服务器 AppleTalk Net-Library。

  • Windows 98 不支持服务器端的 Windows 身份验证 API 功能。客户端无法使用 Windows 身份验证连接到 Windows 98 计算机上的 SQL Server 实例。但 Windows 98 确实支持客户端的 Windows 身份验证 API 功能。在 Windows 98 计算机上运行的 SQL Server 客户端，可以使用 Windows 身份验证连接到 Windows NT 或 Windows 2000 计算机上的 SQL Server 2000 实例。

  • Windows 98 不支持在服务器端使用多协议 Net-Library 加密。客户端无法使用多协议加密连接到 Windows 98 计算机上的SQL Server 2000 实例。但 Windows 98 确实支持客户端的多协议加密功能，因此在 Windows 98 计算机上运行的 SQL Server 客户端，可以使用多协议加密连接到 Windows NT 或 Windows 2000 计算机上的 SQL Server 实例。

  • Windows 98 不支持异步 I/O 和散播-聚集 I/O。由于这一原因，数据库引擎无法利用其在 Windows NT 和 Windows 2000 上使用的部分 I/O 优化来加大对许多并发用户的吞吐量。

  • 在 Windows 98 上，SQL Server 不是象在 Windows NT 和 Windows 2000 上那样将虚拟内存保持在使交换最少的那一点上，而是根据所进行的数据库工作量管理其内存要求。有关更多信息，请参见内存构架。

  • Windows 98 没有与 Window NT 或 Windows 2000 服务相对应的组件。SQL Server 数据库引擎和 SQL Server 代理程序在 Windows 98 和 Windows 95 上作为可执行程序运行。这些 SQL Server 组件无法作为服务自动启动。可以通过在 Windows 98 启动程序组中放置命令提示命令来启动它们，但之后它们将作为单独的 Microsoft MS-DOS® 窗口运行。

    SQL Server 服务管理器安装在 Windows 98 启动程序组中，并使用与其在 Windows NT 和 Windows 2000 中相同的用户界面运行。

  • Windows 98 没有事件日志。SQL Server 使用基于 SQL 事件探查器的机制在 Windows 98 上启动警报。

  • Windows 98 计算机上没有 SQL Server 性能监视器。在 Windows 98 上运行的 SQL Server 2000 实例无法实现性能监视器的计数器。Windows 98 客户端无法监视在 Windows NT 或 Windows 2000 上运行的 SQL Server 实例的性能计数器。


SQL Server 2000 和 Windows CE

Microsoft® SQL Server 2000™ Windows® CE 版为 Windows CE 设备提供可靠的关系数据库引擎：

  • 优化的 Windows CE

    Microsoft® SQL Server 2000™ Windows CE 版 (SQL Server CE) 被设计成可以在一般 Windows CE 设备上有效运行。SQL Server CE 占用的内存大约是 1 MB。SQL Server CE 的设计已从满足最基本的功能发展到综合考虑大小、RDBMS 功能、连接性和性能要求。

    SQL Server CE 作为动态链接库 (DLL) 集实现，而动态链接库作为 OLE DB CE 提供程序运行。这使 SQL Server CE 得以支持 ADOCE 和 OLE DB CE API，也意味着同时运行的多个应用程序可以共享一套常用的 DLL，从而节省了空间。

  • 集成的开发环境

    SQL Server 2000 CE 与 Windows CE 开发环境紧密地集成在一起，可以充分利用 SQL Server 开发人员的现有技能。SQL Server CE 支持基于 Windows CE 的 Microsoft® Visual Basic™ 和 Visual C++™ 各版本中的 ADOCE 和 OLE DB CE 数据访问 API。SQL Server CE 应用程序所使用的 SQL 语言和数据访问 API 一般是向上兼容 SQL Server 应用程序的。已习惯于使用其它 Windows 环境中的 ADO 或 OLE DB 开发 SQL Server 应用程序的程序员可以使用 SQL Server CE 快速开发出数据敏感的 Windows CE 应用程序。

  • SQL Server 2000 互相操作性

    SQL Server CE 可以与其它 Windows 平台上运行的 SQL Server 2000 实例交换数据，授予 Windows CE 应用程序对位于中央的数据的访问权限。SQL Server CE 支持广泛的连接选项，以满足不同设备的连接需要。SQL Server CE 可以从运行于其它 Windows 平台上的 SQL Server 2000 实例中，作为对发布的匿名合并复制订阅服务器运行。这使必须自治工作的脱接移动用户得以从中央数据库下载数据、脱机工作并将他们的工作内容合并回中央数据库。仍与网络保持连接的设备可以使用远程数据访问功能进行以下操作：

    • 连接到其它 Windows 平台上的 SQL Server 实例。

    • 执行 SQL 语句并将结果集作为记录集接收。

    • 另外，修改该记录集并将修改后的内容推回其它 Windows 平台上的 SQL Server 实例。

    通过一些网络功能（如可以减少数据传输的数据压缩和消息传递，从丢失的连接中可靠恢复等），对 SQL Server CE 连接选项进行调整，使之适合无线网络上的使用需要。


SQL Server 和邮件集成

Microsoft® SQL Server™ 提供了一组扩展存储过程，使得 SQL Server 可以作为启用了 MAPI 的电子邮件系统的工作组邮局运行。

必须将运行 SQL Server 的计算机设置为电子邮件客户端。可使用 SQL Server 企业管理器为 SQL Server 安装指派电子邮件帐户和密码。然后可以启用 SQL Server 的邮件组件，使其在 SQL Server 代理服务启动时自动启动。或者，可以使用 SQL Server 企业管理器或 xp_startmail、xp_stopmail 和 xp_sendmail 存储过程随意启动和停止邮件组件。

当 SQL Server 的邮件组件运行时，可用来：

  • 使用 xp_send_mail 从 Transact-SQL 批处理、脚本、存储过程和触发器发送电子邮件。电子邮件可以是：
    • 消息字符串。

    • 查询的结果集。

    • 要执行的 Transact-SQL 语句或批处理。

    • 电子呼叫程序的寻呼。
  • 使用 sp_processmail 或 xp_findnextmessage、xp_readmail 和 xp_deletemail 的组合阅读电子邮件。发送给 SQL Server 的消息一般包含将要执行的 Transact-SQL 语句或批处理。执行语句并将结果集作为带可选 CC: 列表的回复电子邮件返回。

SQL Server 事件和警报可与 SQL 邮件功能结合起来生成一个系统，在该系统中，运行 SQL Server 的服务器可以在有严重情况发生时自动给相关的管理员发电子邮件或寻呼。


管理构架

每个 Microsoft® SQL Server™ 的新版本都力求自动执行或消除数据库管理员所执行的重复工作。每个站点的数据库管理员通常在数据库方面都训练有素，这些改进使得作为宝贵资源的数据库管理员可以将更多的时间用在数据库的设计和应用程序的数据访问上。

SQL Server 2000 的管理具有以下特点：

  • SQL Server 2000 数据库服务器通过动态获取和释放资源，减少了许多环境中的管理工作。服务器可以在需要的时候自动获取内存和磁盘空间等资源，而在不再需要的时候，则可以释放这些资源。虽然具有关键性能的大型 OLTP 系统仍需由训练有素的管理员监视，但是 SQL Server 2000 还可以用于执行那些无需管理员持续监视的小型桌面数据库或工作组数据库。

  • SQL Server 2000 提供一系列图形工具，使管理员得以轻松有效地执行管理任务。

  • SQL Server 2000 提供一系列服务，使管理员得以调度自动执行的重复任务。

  • SQL Server 2000 管理员可以对服务器进行编程以处理异常情况，或者至少可以给值班的管理员发送电子邮件或寻呼信息。

  • SQL Server 2000 发布由 SQL Server 实用工具使用的相同的管理应用程序接口 (API)。这些 API 支持所有的 SQL Server 管理任务。这使开发人员在编写将 SQL Server 2000 用作数据存储的应用程序时，可以将用户与 SQL Server 2000 的管理完全隔离开。


DDL 和存储过程

Transact-SQL 语言适用于从所有应用程序发送到 Microsoft® SQL Server™ 2000 的命令。Transact-SQL 包含的语句支持在 SQL Server 中进行的所有管理工作。这些语句主要分为两类：

数据定义语言 (DDL)

SQL 语言主要有两种：一种是数据定义语言 (DDL)，用于定义和管理 SQL 数据库中的所有对象；另一种是数据操作语言 (DML)，用于选择、插入、更新和删除使用 DDL 定义的对象中的数据。Transact-SQL DDL 用于管理数据库、表和视图等对象，它在 SQL-92 DDL 语句的基础上进行了扩展。每个对象类通常都包含 CREATE、ALTER 和 DROP 语句，如 CREATE TABLE、ALTER TABLE 和 DROP TABLE。权限由 SQL-92 GRANT 和 REVOKE 语句以及 Transact-SQL DENY 语句控制。

系统存储过程

SQL-92 DDL 未涉及的管理任务通常由系统存储过程执行。这些存储过程的名称以 sp_ 或 xp_ 开头，并在安装 SQL Server 时安装。系统存储过程的部分示例如下：

  • sp_addtype（定义用户定义数据类型。）

  • sp_configure（管理服务器配置选项设置。）

  • xp_sendmail（发送电子邮件或寻呼信息。）

SQL Server 2000 还表现 SQL-DMO、SQL-NS、DTS 和复制组件 API。所有这些都由封装 DDL 或系统存储过程的 OLE 自动化对象组成。当应用程序调用其中一个对象时，该对象实际将请求转换为一个或多个 Transact-SQL DDL 或系统存储过程语句，然后再将它们发送给服务器。


SQL 分布式管理框架

SQL 分布式管理框架 (SQL-DMF) 是集成了对象、服务和组件的框架，用于管理 Microsoft® SQL Server™ 2000。SQL-DMF 提供能适应单位需要的灵活的可伸缩管理框架。它提供了可直接与 SQL Server 2000 进行交互的服务，从而减少了对用户值守的维护任务（例如数据库备份和警报提示）的需要。

SQL-DMF 的主要组件允许定义下列内容，使得可以事先对在网络上管理 SQL Server 实例进行设置：

  • 所有 SQL Server 对象及其权限。

  • 按照指定的间隔或时间来进行重复管理操作。

  • 检测到特定条件时，采取正确的操作。正确的操作可以是为解决问题所定义的任务，也可以是发送给可解决问题的某人的寻呼信息或电子邮件警报。

下图显示 SQL-DMF 的主要组件。


SQL-DMF 应用程序

使用 SQL-DMF 的应用程序主要有三类。这三类应用程序提供管理 Microsoft® SQL Server™ 2000 的用户界面：

SQL Server 工具

管理 SQL Server 数据库对象的 SQL Server 2000 工具使用 SQL-DMO API。使用 SQL-DMF 的主要 SQL Server 工具是 SQL Server 企业管理器。SQL Server 企业管理器为在网络上管理 SQL Server 实例提供了主要用户界面。另外，SQL 查询分析器包含与列出和管理数据库对象有关的功能（如对象浏览器）。这些功能都使用 SQL-DMF。

COM+ 应用程序和 Active Server Pages

SQL-DMF API 可用于 COM+ 应用程序和 Web 应用程序，如 Active Server Pages (ASP)。

应用程序和 ISV 工具

应用程序无论是在本公司内编写还是由独立软件开发商 (ISV) 编写，都可以使用 SQL-DMF API 来管理和配置 SQL Server 实例。如果应用程序选择内嵌 SQL Server 作为存储数据机制，这一功能可使该应用程序保护 SQL Server 的管理不受 SQL Server 用户的影响。生产服务器应用程序管理工具的 ISV 还使用 SQL-DMF API 生成某些功能，以便用他们的工具管理 SQL Server。


SQL-DMF API

应用程序可以使用三种 API 之一来访问 SQL-DMF 的核心功能：SQL 命名空间、SQL 分布式管理对象和分布式转换服务。这些 API 作为双接口的 COM 接口实现。

SQL 分布式管理对象

SQL 分布式管理对象 (SQL-DMO) API 由一系列对象组成，这些对象封装实体（如 Microsoft® SQL Server™ 数据库中找到的表、用户和视图）的管理特性。SQL-DMO 使 DDL、系统存储过程、注册表信息和操作系统资源的使用抽象化。SQL-DMO 可用于对 SQL Server 中的所有管理和配置任务进行编程。

数据转换服务

分布式转换服务 (DTS) API 表现 SQL Server 所提供的服务，以帮助生成数据仓库和数据集市。这些服务提供在异类 OLE DB 和 ODBC 数据源之间传输和转换数据的功能。可以按照调度的时间或间隔定期传输对象或查询的结果集中的数据，也可以进行特殊传输或查询。

Windows 管理规范

SQL Server 2000 光盘支持一个新的 API，该 API 允许通过使用 Windows 管理规范 (WMI) 管理 SQL Server 示例。WMI 是一个可伸缩的带有面向对象 API 的 Windows 2000 组件，它通过管理应用程序和脚本来监视、配置和控制操作系统和 Windows 网络中的设备、服务程序和应用程序。通过使用标准的 Windows 安全设置，WMI 只允许经过适当授权的用户管理系统。WMI 的核心组件还可用于 Windows NT® 4.0、Windows® 95 和 Windows 98。有关这些操作系统的 WMI 支持的更多信息，请参见 Microsoft Web 站点的 MSDN® 页。

通过提供 WMI 提供程序和定义 WMI 类架构，组件（如 SQL Server）可启用 WMI 支持。此架构为组件中可通过 WMI 管理的对象建立模型。SQL Server 2000 包含 SQL Server WMI 提供程序和一个架构类模型，该模型将 SQL Server 2000 的实例映射到 WMI 类。SQL Server WMI 架构为数据库和表这类对象建立模型。SQL Server WMI 实现提供如下管理功能：

  • 创建、改变或删除管理的对象。例如，创建一个数据库。

  • 管理管理的对象。例如，备份数据库和日志。

  • 枚举管理的对象。例如，列出数据库中的所有表。

  • 检索特定管理对象的信息。例如，确定是否在 Customers 表上启用了全文索引。

  • 查询满足特定条件的管理对象。例如，列出所有的加密存储过程。

  • 执行为管理对象定义的方法。例如，执行从表中大容量复制数据的方法。

  • 当创建、改变或删除管理的对象时生成事件（例如，当改变数据库选项时产生一个事件）。

  • 描述管理的对象之间的关系（例如，识别授权访问数据库的登录）。

所有 WMI 数据都可以远程使用且可以完全用于脚本。SQL Server 2000 WMI 实现映射在 SQL-DMO API 上，但不支持对复制进行管理。SQL Server WMI 实现可与 SQL Server 7.0 一起使用。

SQL Server 2000 安装程序不安装 SQL Server WMI 支持。所有 WMI 材料，包括单独的安装程序和文档，都包含在 SQL Server 2000 光盘上的 \x86\OTHER\wmi 文件夹中。

SQL 命名空间

SQL 命名空间 (SQL-NS) API 表现 SQL Server 企业管理器的用户界面 (UI) 元素。这使应用程序得以包括对话框和向导等 SQL Server 企业管理器 UI 元素。

请参见

开发 SQL-DMO 应用程序

DTS 应用程序设计

SQL-NS 应用程序设计


SQL Server 代理

SQL Server 代理程序运行在 Microsoft® SQL Server™ 2000 或 SQL Server 早期版本的实例所在的服务器上。SQL Server 代理程序负责：

  • 运行在特定的时间或间隔调度发生的 SQL Server 任务。

  • 检测特定的情况，管理员定义了在这些情况下所要执行的操作，例如通过寻呼信息或电子邮件给某人报警；或者执行一个任务来处理这些情况。

  • 运行管理员定义的复制任务。

SQL Server 代理程序类似于辅助操作员，负责处理重复任务以及通过其它 SQL-DMF 组件定义的异常错误处理情况。

请参见

DTS 概述

SQL 命名空间 API

SQL-DMO API

SQLServerAgent 服务


图形工具

Microsoft® SQL Server™ 2000 包含许多图形实用工具，使用户、程序员和管理员得以轻松快速地：

  • 管理和配置 SQL Server。

  • 确定 SQL Server 复本中的目录信息。

  • 设计和测试用于检索数据的查询。

除了这些工具外，SQL Server 还包含许多向导，可引导管理员和程序员一步步地完成更复杂的管理任务。


SQL Server 企业管理器

SQL Server 企业管理器是 Microsoft® SQL Server™ 2000 的主要管理工具，它提供了一个遵从 Microsoft 管理控制台 (MMC) 的用户界面，使用户得以：

  • 定义运行 SQL Server 的服务器组。

  • 将个别服务器注册到组中。

  • 为每个已注册的服务器配置所有 SQL Server 选项。

  • 在每个已注册的服务器中创建并管理所有 SQL Server 数据库、对象、登录、用户和权限。

  • 在每个已注册的服务器上定义并执行所有 SQL Server 管理任务。

  • 通过唤醒调用 SQL 查询分析器，交互地设计并测试 SQL 语句、批处理和脚本。

  • 唤醒调用为 SQL Server 定义的各种向导。

MMC 是一个工具，为在 Microsoft Windows® 网络中管理不同的服务器应用程序提供了公用界面。服务器应用程序提供一个称为 MMC 管理单元的组件，用以向 MMC 用户呈现一个用户界面来管理服务器应用程序。SQL Server 企业管理器是 Microsoft SQL Server 2000 的 MMC 管理单元。

若要启动 SQL Server 企业管理器，请选择 Microsoft SQL Server 程序组中的企业管理器图标。在运行 Windows 2000 的计算机上，可通过控制面板中的计算机管理启动 SQL Server 企业管理器。通过计算机管理启动的 MMC 管理单元不能打开默认情况下启用的子窗口。也许必须启用此选项才能使用所有的 SQL Server 企业管理器功能。

说明 如果在计算机管理中注册其它 SQL 服务器，然后关闭计算机管理或连接到另一台计算机，则这些服务器将不再出现在计算机管理中。已注册的服务器将出现在 SQL Server 企业管理器中。

请参见

如何在计算机管理控制台中启动 SQL Server 企业管理器 (Windows)

如何启用子窗口（企业管理器）

SQL Server 工具概述


SQL 查询分析器

SQL 查询分析器是一个图形用户界面，用以交互地设计和测试 Transact-SQL 语句、批处理和脚本。可以从 SQL Server 企业管理器调用 SQL 查询分析器。

SQL 查询分析器提供：

  • 用于键入 Transact-SQL 语句的自由格式文本编辑器。

  • 在 Transact-SQL 语法中使用不同的颜色，以提高复杂语句的易读性。

  • 对象浏览器和对象搜索工具，可以轻松查找数据库中的对象和对象结构。

  • 模板，可用于加快创建 SQL Server 对象的 Transact-SQL 语句的开发速度。模板是包含创建数据库对象所需的 Transact-SQL 语句基本结构的文件。

  • 用于分析存储过程的交互式调试工具。

  • 以网格或自由格式文本窗口的形式显示结果。

  • 显示计划信息的图形关系图，用以说明内置在 Transact-SQL 语句执行计划中的逻辑步骤。

    这使程序员得以确定在性能差的查询中，具体是哪一部分使用了大量资源。之后，程序员可以试着采用不同的方法更改查询，使查询使用的资源减到最小同时仍返回正确的数据。

  • 使用索引优化向导分析 Transact-SQL 语句以及它所引用的表，以了解通过添加其它索引是否可以提高查询的性能。

请参见

分析查询

索引优化向导

SQL 查询分析器概述


Windows 2000 系统监视器

Windows 2000 系统监视器（Windows NT 性能监视器）是一个监视运行 Microsoft® Windows NT® 或 Microsoft Windows® 2000 的计算机上的资源使用情况的工具。用户可以设置图表，以图形方式显示资源的使用情况。Windows 系统监视器有许多不同的计数器，每个计数器可以对计算机上的某些资源进行度量。

Windows 系统监视器可扩展，使服务器应用程序可以添加自己的性能计数器。Microsoft SQL Server™ 2000 在 Windows 系统监视器中添加了可对以下项目进行跟踪的计数器：

  • SQL Server I/O。

  • SQL Server 内存使用情况。

  • SQL Server 用户连接。

  • SQL Server 锁定。

  • 复制活动。

请参见

用 Windows 性能监视器进行监视


导入和导出数据

Microsoft® SQL Server™ 程序组中的"导入和导出数据"项启动数据转换服务 (DTS) 导入/导出向导。此向导引导用户逐步了解 DTS 的功能，如数据和对象的导入、导出、验证以及在异类 OLE DB 和 ODBC 数据源之间的转换。

请参见

DTS 导入/导出向导


SQL 事件探查器

SQL 事件探查器是从服务器捕获 Microsoft® SQL Server™ 2000 事件的工具。事件保存在一个跟踪文件中，可在以后对该文件进行分析，也可以在试图诊断某个问题时，用它来重播某一系列的步骤。SQL 事件探查器用于以下活动：

  • 逐步分析有问题的查询以找到问题的原因。

  • 查找并诊断运行慢的查询。

  • 捕获导致某个问题的一系列 SQL 语句。然后用所保存的跟踪在某台测试服务器上复制此问题，接着在该测试服务器上诊断问题。

  • 监视 SQL Server 的性能以精细地调整工作负荷。

SQL 事件探查器还支持对在 SQL Server 实例上执行的操作进行审核。审核将记录与安全相关的操作，供安全管理员以后复查。SQL Server 2000 审核满足 C2 安全证书要求。

请参见

使用 SQL 事件探查器进行监视

审核 SQL Server 活动


SQL Server 服务管理器

SQL Server 服务管理器用于启动、停止和暂停服务器上的 Microsoft® SQL Server™ 2000 组件。这些组件在 Microsoft Windows NT® 或 Microsoft Windows® 2000 上作为服务运行，并可在 Microsoft Windows 95 和 Microsoft Windows 98 上作为单独的可执行程序运行：

  • SQL Server 服务

    实现 SQL Server 数据库引擎。在计算机上运行的每个 SQL Server 实例都有一个 SQL Server 服务。

  • SQL Server 代理服务

    实现运行调度的 SQL Server 管理任务的代理程序。在计算机上运行的每个 SQL Server 实例都有一个 SQL Server 代理服务。

  • Microsoft 搜索服务（仅用于 Windows NT 和 Windows 2000）

    实现全文本检索引擎。不论计算机上有多少个 SQL Server 实例，都只有一个服务。

  • MSDTC 服务（仅用于 Windows NT 和 Windows 2000）

    管理分布式事务。不论计算机上有多少个 SQL Server 实例，都只有一个服务。

  • MSSQLServerOlAPService 服务（仅用于 Windows NT 和 Windows 2000）

    实现 SQL Server 2000 Analysis Services。不论计算机上有多少个 SQL Server 实例，都只有一个服务。

运行 SQL Server 服务管理器

SQL Server 服务管理器是一个任务栏应用程序，它遵从任务栏应用程序的标准行为。当 SQL Server 服务管理器图标最小化时，将显示在任务栏右边的任务栏时钟区域。若要获得包含 SQL Server 服务管理器所支持的所有任务的菜单，请右击任务栏项。

若要使 SQL Server 服务管理器最大化，只需双击其图标即可。当 SQL Server 服务管理器最大化时，单击 SQL Server 服务管理器窗口的关闭按钮不会终止该应用程序，而只是使 SQL Server 服务管理器最小化，并位于任务栏上。若要终止 SQL Server 服务管理器，请右击任务栏上的 SQL Server 服务管理器图标，然后选择"文件"/"退出"菜单项。

请参见

启动、暂停和停止 SQL Server


客户端网络实用工具

客户端网络实用工具用于管理客户端 Net-Library 以及定义服务器别名。还可以用来设置 DB-Library 应用程序所使用的默认选项。

大多数用户永远也不需要使用客户端网络实用工具。若要连接到 Microsoft® SQL Server™ 2000，用户只需指定运行 SQL Server 的服务器网络名称，也可以指定 SQL Server 实例的名称。

在有些情况下，可配置 SQL Server 实例监听备用网络地址。如果这样做了，则与实例相连的客户端应用程序必须显式指定备用地址。虽然应用程序可以根据每个连接请求指定备用地址，但使用客户端网络实用工具设置用于指定备用地址的别名更容易。这样一来，应用程序就可以指定别名来取代连接请求中的服务器网络名称。

请参见

通讯组件

管理客户端


服务器网络实用工具

服务器网络实用工具用于管理服务器 Net-Library。该实用工具用于指定：

  • Microsoft® SQL Server™ 2000 实例在其上监听客户端请求的网络协议栈。

  • 从应用程序建立连接时考虑使用的服务器 Net-Library 顺序。

  • Microsoft SQL Server 2000 实例监听的新网络地址。

大多数管理员永远不需要使用服务器网络实用工具。他们会在安装过程中指定 SQL Server 监听的服务器 Net-Library。

请参见

通讯组件

配置网络连接


其它实用工具

ODBC 管理器实用工具和服务实用工具也可用于管理 Microsoft® SQL Server™ 2000 的一部分：

ODBC 管理器

ODBC 管理器实用工具用于添加、删除和编辑计算机上所有 ODBC 驱动程序的 ODBC 数据源，包括 SQL Server ODBC 驱动程序的数据源。它还可以用来列出计算机上安装的所有 ODBC 驱动程序版本。在 Microsoft Windows NT®、Microsoft Windows® 95 和 Microsoft Windows 98 中，ODBC 实用工具位于"控制面板"中。在 Microsoft Windows 2000 中，该实用工具被命名为数据源 (ODBC) 实用工具，位于"控制面板"的 Administrative Tools 文件夹中。

服务（Windows NT 和 Windows 2000）

服务应用程序可用来启动、暂停和停止 Microsoft Windows NT 或 Windows 2000 服务，包括由 SQL Server 服务管理器管理的服务。在 Windows NT 中，服务实用工具位于"控制面板"中。在 Windows 2000 中，该实用工具位于"控制面板"的 Administrative Tools 文件夹中。

SQL Server 还安装了几个命令提示实用工具，可用于生成与 SQL Server 一起使用的 .cmd 文件。有关更多信息，请参见命令提示实用工具入门。


自动管理构架

Microsoft® SQL Server™ 2000 提供了一些功能，使管理员得以通过编程使服务器对许多重复操作或异常情况进行管理。这使管理员可以有更多时间从事一些重要的活动，如设计数据库，以及针对有效的数据库访问编码技术向程序员提出建议。任何厂商的应用程序都可以选择 SQL Server 作为其数据存储组件，并通过自动化管理任务，将要求客户执行的管理任务减到最少。

这些自动化功能并不局限于像调度备份这样的数据库管理任务。它们还可以帮助实现数据库所支持的业务实践活动的自动化。可以调度应用程序在特定的时间或按一定的间隔运行。如果某些应用程序需要在下一个调度时间之前执行，可以通过在系统中检测到的特定情况触发它们。

支持管理任务自动化的功能有：

SQL Server 代理

SQL Server 代理程序是一个单独的可执行程序，执行由系统管理员定义的管理作业和警报。SQL Server 代理程序在运行 Microsoft Windows NT® 或 Windows® 2000 的计算机上作为名为 SQLServerAgent 的服务运行，在运行 Microsoft Windows 95 或 Microsoft Windows 98 的计算机上则作为可执行文件运行。

作业

作业定义管理任务。每项作业都有一个或多个步骤；每个步骤都指定一个 Transact-SQL 语句、Windows 命令、可执行程序、复制代理程序或 Microsoft ActiveX® 脚本。作业可以只运行一次，也可以按照调度的时间间隔运行，或者可以指定在服务器空闲时运行。

作业使系统管理员能够定义管理任务的执行时间。每项作业可以组合各种操作系统命令、Transact-SQL 语句、存储过程和应用程序，以完成复杂的管理功能。每个作业步骤都可以非常复杂。例如，Windows 命令可以是一条命令，也可以是包含许多命令的批处理文件。按步执行的 Transact-SQL 语句可以是包含许多 Transact-SQL 语句的存储过程。

SQL Server 代理程序可以在指定的时间运行这些任务，无需人为干涉。可以将具有错误检查逻辑的复杂过程设计成一个作业，以处理作业最有可能遇到的情况。这些功能所带来的好处是可以生成复杂、可靠的作业来运行所有的定期维护任务。

事件和警报

在 Windows NT 或 Windows 2000 上运行的每个 SQL Server 2000 实例都将重要事件记入 Windows NT 或 Windows 2000 应用程序日志。日志中的每一项称为事件。SQL Server 管理员可以通过定义警报来指定当某一事件发生时应运行的作业。SQL Server 代理程序将应用程序日志中的 SQL Server 事件与管理员定义的警报进行比较。如果两者匹配，则执行警报中所指定的作业。

Windows 95 和 Windows 98 没有事件日志。在 Windows 95 或 Windows 98 上运行的 SQL Server 专业版的安装使用基于 SQL 事件探查器的机制，将事件传送到 SQL Server 代理程序。

SQL Server 为严重度达到 19 或更高的错误创建事件。如果用 WITH LOG 子句执行 RAISEERROR 语句，或执行 xp_logevent 系统存储过程，也会生成事件。这使 Transact-SQL 脚本、触发器、存储过程和应用程序得以生成可激发作业的事件。

操作员

操作员是为 SQL Server 定义的在警报中使用的电子邮件地址和寻呼地址。可以将警报定义为给某人发送电子邮件或寻呼信息。在 Windows NT 或 Windows 2000 上运行的 SQL Server 实例，也可使用 Windows NT 或 Windows 2000 的 net send 命令将网络消息发送到 Windows 用户或组。

触发器

触发器用于强制执行业务逻辑。可以使用 RAISERROR 或 xp_logevent 将自动化管理任务与触发器集成在一起，以生成可激发警报的事件。例如，假定某个零售公司有一个库存数据库，且该公司的所有供货商都接受电子定单。每天晚上，由一个调度的作业执行某个应用程序来检查所有的库存水平，并使用管理方制定的指导方针，或者为首选的供货商发去短缺货物定单，或者给购买代理商打印报告。这一过程还可以通过部件表上的 DELETE 触发器得到支持，一旦由于畅销而使当天的库存销售一空时，可由 DELETE 触发器激发类似的作业进行紧急定货。

请参见

自动化管理任务

用触发器强制执行业务规则


备份/还原构架

Microsoft® SQL Server™ 2000 的备份和还原组件使您得以创建数据库的复本。可将此复本存储在某个位置，以便一旦运行 SQL Server 实例的服务器出现故障时使用。如果运行 SQL Server 实例的服务器出现故障，或者如果数据库遭到某种程度的损坏，可以用备份复本重新创建或还原数据库。

SQL Server 2000 提供以下完善的备份和还原功能：

  • 有关如何备份和还原数据库的选项如下：
    • 完整数据库备份是数据库的完整复本。

    • 事务日志备份仅复制事务日志。

    • 差异备份仅复制自上一次完整数据库备份之后修改过的数据库页。

    • 文件或文件组还原仅允许恢复数据库中位于故障磁盘上的那部分。

    这些选项允许根据数据库中数据的重要程度调整备份和还原进程。可以不备份能够很容易从其它来源重新创建的非关键数据库，其它数据库可能需要简单的备份，即只将数据库恢复到故障发生前一天晚上的状态，而关键数据库则需进行完善的备份，即应将数据库还原到故障发生前的状态。

  • 由 BACKUP 和 RESTORE 语句控制。

    用户可以直接从应用程序、Transact-SQL 脚本、存储过程和触发器执行 BACKUP 和 RESTORE 语句。但是更常见的是使用 SQL Server 企业管理器定义备份调度，从而使 SQL Server 代理程序得以按照调度自动运行备份。数据库维护计划向导可用于定义和调度每个数据库的全套备份。这可使备份进程完全自动化，无需或只需很少的操作员操作。

  • 维护 msdb 数据库中的一系列备份历史记录表。

    备份历史记录表记录每个数据库的备份。如果不得不还原数据库，则 SQL Server 企业管理器的"还原数据库"对话框将为用户显示数据库的所有可用备份列表。"还原数据库"对话框还用一种逻辑显示使用历史记录中的哪个备份集，可以在最短时间内还原数据库。当显示该对话框时，还原数据库所需的备份都将被选中。如果用户知道其中的一个备份不可用（例如盒式磁带已损坏或丢失），则可以取消选择该备份，SQL Server 企业管理器将考虑新的还原方法。当用户同意使用新的方法进行还原时，SQL Server 企业管理器将还原数据库，并在需要时提示插入磁带。

  • 备份可以在数据库正在使用时执行，从而可以为必须不间断运行的系统进行备份。

    SQL Server 2000 的备份处理和内部数据结构已进行结构化，使备份在最大限度地提高数据传输率的同时，对事务吞吐量的影响保持最小。

  • 使备份和还原操作获得更快的数据传输率，从而使 SQL Server 2000 能够支持超大型数据库 (VLDB)。

    SQL Server 2000 数据库中的数据结构以及备份和还原算法支持备份和还原操作的高数据传输率。SQL Server 备份和还原操作还可以并行方式在多个备份文件或磁带驱动器上运行，从而进一步提高备份和还原的数据传输率。

  • 在必要时，RESTORE 语句将自动重新创建数据库。

    如果在执行RESTORE 语句时数据库不存在，那么这一功能可省去单独执行 CREATE DATABASE 或 CREATE DATABASE FOR LOAD 语句的必要。

  • 当中断的备份和还原操作重新开始时，将从接近中断点的位置开始。

  • 在尝试还原数据库之前，先对 SQL Server 2000 备份进行验证。这包括验证 SQL Server 实例是否支持数据库的排序规则。

应同时规划备份和还原过程。管理员必须首先确定数据库中的关键数据。他们必须确定这些数据是否可以将数据库还原到故障发生前一天晚上的状态，或者是否可以将数据库还原到尽可能接近故障发生的那一刻。他们还必须确定数据库在多长时间内不可用，是否必须尽快使数据库重新联机，或者是否不需要立即还原。

确定还原要求后，管理员就可以规划备份过程来维护满足还原要求的备份集。管理员可以选择在运行时对系统的影响最小，同时又能满足还原要求的备份过程。管理员还根据资源要求选择数据库的恢复模式。恢复模式将针对完全恢复数据的重要程度来平衡记录开销。恢复模式包括：

  • 完全

    数据非常重要并且必须能够恢复到故障点。记录所有的数据修改。可使用 SQL Server 2000 的所有恢复选项。

  • 大容量日志记录

    如有必要，可重播某些大容量操作（大容量复制操作、SELECT INTO、文本处理），因此不完全记录这些操作。只能恢复到上一次数据库或日志备份的末尾。

  • 简单

    自上次备份后所做的所有数据更改都是可替代的，或是可重做的。记录开销最小，但不能恢复自上次备份结束后的内容。

请参见

备份和还原数据库


备份设备

在 Microsoft® SQL Server™ 2000 和 SQL Server 7.0 版中创建的备份可使用 Microsoft 磁带格式 (MSTF) 存储。MSTF 不是磁带专用格式，还可用于磁盘或命名管道的备份。每次执行 SQL Server 备份，都会形成一个备份集。备份集存储在称为媒体的 MSTF 单元中。MSTF 媒体可以存储来自不同软件的备份集。

使用 MSTF 格式使 SQL Server 得以使用管理实用工具和其它厂商的的产品来管理 MSTF 格式备份。SQL Server 备份集可以与来自其它服务器软件的备份集共享媒体，如 MSTF 磁带驱动器。SQL Server 不压缩其备份集，但会利用 MSTF 备份设备所提供的压缩功能。

请参见

使用备份媒体


备份和还原过程的类型

Microsoft® SQL Server™ 2000 和 SQL Server 7.0 版支持四种类型的备份。可以将这四种类型组合成许多不同类型的备份和还原过程，每一种都针对不同的数据库可用性要求。这四种类型是：

  • 数据库

  • 事务日志

  • 差异

  • 文件和文件组

请参见

设计备份和还原策略


数据库备份和还原

数据库备份创建完整数据库的复本。并非将所有的页都复制到备份集，而只将实际包含数据的页复制到备份集。数据页和事务日志页均复制到备份集。

数据库备份集用于重新创建数据库，使其恢复到 BACKUP 语句完成时的状态。如果数据库只存在数据库备份，那么数据库只能恢复到服务器或数据库发生故障前最后一次数据库备份时的状态。

请参见

数据库备份


事务日志备份和还原

事务日志备份仅制作日志文件的复本。日志文件备份本身不能用于还原数据库。日志文件用于在数据库还原后将数据库恢复到原始故障点。例如，某站点在星期天晚上执行数据库备份，而在其它每个晚上执行日志备份。如果数据库的某个数据磁盘在星期二下午 2:30 丢失，则该站点可以：

  1. 备份当前事务日志。

  2. 还原从星期天晚上开始的数据库备份。

  3. 还原从星期一晚上开始的日志备份，以将数据库前滚。

  4. 还原故障之后的日志备份。这将使数据库前滚到故障发生的那一刻。

事务日志恢复需要从数据库备份的那一刻起到磁盘丢失那一刻之间所进行的一连串不间断的的事务日志备份。

请参见

事务日志备份


差异备份和还原

差异备份只创建数据库中自上一次数据库备份之后修改过的所有页的复本。差异日志主要用于使用频繁的系统，一旦这类系统中的数据库发生故障，必须尽快使其重新联机。差异备份比完整数据库备份小，因此对正在运行的系统影响较小。

例如，某个站点在星期天晚上执行完整数据库备份。在白天每隔 4 小时制作一个事务日志备份集，并用当天的备份重写头一天的备份。每晚则进行差异备份。如果数据库的某个数据磁盘在星期四上午 9:12 出现故障，则该站点可以：

  1. 备份当前事务日志。

  2. 还原从星期天晚上开始的数据库备份。

  3. 还原从星期三晚上开始的差异备份，将数据库前滚到这一时刻。

  4. 还原从早上 4 点到 8 点的事务日志备份，以将数据库前滚到早上 8 点。

  5. 还原故障之后的日志备份。这将使数据库前滚到故障发生的那一刻。

请参见

差异数据库备份


文件和文件组的备份及还原

Microsoft® SQL Server™ 2000 支持备份或还原数据库中的个别文件或文件组。这是一种相对较完善的备份和还原过程，通常用在具有较高可用性要求的超大型数据库 (VLDB) 中。如果可用的备份时间不足以支持完整数据库备份，则可以在不同的时间备份数据库的子集。

例如，某站点需要花三小时备份数据库，并且每天只能用两个小时执行备份。该站点可在一个晚上备份一半文件或文件组，并在第二个晚上备份另一半。如果包含数据库文件或文件组的磁盘出现故障，那么该站点可以只还原丢失的文件或文件组。该站点还必须进行事务日志备份，并且在备份文件或文件组之后必须还原所有事务日志备份。

还可以从完整数据库备份集中还原文件和文件组。这将加快恢复速度，因为在第一步只还原已损坏的文件或文件组，而不是整个数据库。

请参见

使用文件备份


模糊备份和还原操作

Microsoft® SQL Server™ 2000 和 SQL Server 7.0 版使用行业标准的模糊备份算法。这些新算法为用户提供几个显著优点：

  • BACKUP 语句的运行速度更快，并且减小了在语句处理过程中对用户修改数据的影响。

  • RESTORE 语句的运行速度更快。

RESTORE 操作将数据库还原到 BACKUP 语句结束时的状态。在 SQL Server 6.5 版及更早的版本中，LOAD 语句将数据库还原为 DUMP 语句开始时的状态。

使用 SQL Server 模糊备份和还原操作可以：

  • 将包含数据的扩展盘区写入备份集，而无需考虑使备份期间正由用户修改的页同步。这显著减小了备份对当前用户的影响。还使备份得以串行地复制页。取消了所有随机读取，从而加快使用频繁的系统中的备份过程。但这同时也意味着备份中的页以一种不一致的、无法恢复的状态存储。

  • 将事务日志作为备份的一部分复制。

RESTORE 语句：

  • 如果数据库不存在，则创建数据库，并初始化数据库中的扩展盘区。如果 RESTORE 语句执行时数据库已存在，则可以跳过这一步。

  • 复制备份集中的扩展盘区。因为所有的扩展盘区都按串行顺序排列，所以这个过程较快。将忽略未在备份集中找到的扩展盘区；它们将不作为空的扩展盘区进行初始化。

  • 使用事务日志恢复数据库。将日志中记录的数据修改前滚到日志末尾，然后回滚任何未完成的事务。这将使数据库返回到一致的已恢复状态，这种状态与数据库在 BACKUP 语句完成时的状态一致。


并行备份和还原

并行备份和还原操作可提高 Microsoft® SQL Server™ 2000 管理超大型数据库的能力。BACKUP 和 RESTORE 语句以多种方式使用并行 I/O：

  • 如果数据库的文件存储在几个磁盘设备上，则 BACKUP 在每个磁盘设备上使用一个线程来读取数据库中的扩展盘区。

  • 如果备份集存储在多个备份设备上，则 BACKUP 和 RESTORE 语句在每个备份设备上都是使用一个线程。

  • 如果数据库由几个磁盘驱动器上的文件定义，则 RESTORE 将不得不创建数据库，RESTORE 则在每个磁盘设备上使用一个线程来初始化数据库。


数据导入/导出构架

Microsoft® SQL Server™ 2000 有多个支持导入和导出数据的组件：

数据转换服务

可以用数据转换服务 (DTS) 在异类 OLE DB 和 ODBC 数据源之间导入和导出数据。在定义 DTS 包时指定源和目标 OLE DB 数据源；然后可根据需要执行该包，也可以按调度的时间或间隔执行。一个 DTS 包可以包含多个表。因为 DTS 包可以将某个查询指定为数据源，所以也不限制 DTS 包必须直接将数据从一个表传输到另一个表。这使包得以转换数据，例如，运行一个查询以返回聚集汇总值而非原始数据。

复制

复制用于创建单独数据库中的数据复本，并通过将一个复本中的修改复制到其它所有复本使所有复本同步。如果每个站点都可以接受略微过时的数据，则复制在分发数据时不需要分布式事务开销，来确保所有站点都具有与当前数据完全相同的复本。因此复制可以用相对较低的网络和计算资源成本支持数据分发。

大容量复制

SQL Server 的大容量复制功能允许高效地传输大量数据。大容量复制一次性地将数据传入一个表，或从一个表中传出。大容量复制支持以下大容量复制传输：

  • 从一个 SQL Server 表或视图到另一个表或视图。

  • 从一个 SQL Server 表或视图到一个数据文件，如文本文件或用制表符分隔的文件。

  • 将查询的结果集传输到表、视图或数据文件中。

  • 将数据文件的内容传输到表或视图中。

    可通过几种方法使用大容量复制功能：

  • bcp 命令提示实用工具。

  • 用于 SQL Server 的 OLE DB 提供程序有一个提供程序专用的 IRowsetFastLoad 接口用于大容量复制。

  • SQL Server ODBC 驱动程序支持一组大容量复制函数。

  • Transact-SQL BULK INSERT 语句。这是最快的大容量复制方法。此方法直接从 SQL Server 本身访问数据文件，从而消除了将数据从客户端应用程序传输到服务器的开销。

  • DB-Library API 支持一组大容量复制函数。

分布式查询

分布式查询使 Transact-SQL 语句得以引用 OLE DB 数据源中的数据。OLE DB 数据源可以是另一个 SQL Server 实例，也可以是 Microsoft Access 或 Oracle 等异类数据源。SELECT INTO 和 INSERT 语句可用于：

  • 将数据从 SQL Server 数据库中导出到 OLE DB 数据源中。

  • 将数据从 OLE DB 数据源导入 SQL Server。

请参见

分布式查询

导入和导出数据

DTS 概述

复制概述


数据完整性验证

Transact-SQL 有一组用于验证数据库完整性的 OBCC 语句。与 SQL Server 6.5 版中使用的 DBCC 语句相比，Microsoft® SQL Server™ 2000 和 SQL Server 7.0 版中的 DBCC 语句有几个改进：

  • 运行这些语句的必要性显著减少了。SQL Server 中两个构架的改变将数据库的可靠性提高到可不必验证其完整性的程度：
    • 数据库引擎具有快速失败的逻辑，以尽早检测出潜在的错误。这意味着错误不大可能持续很长时间，以至引发数据库中的问题。

    • 数据库中的数据结构变得更简单。这意味着数据结构更易于管理，且减小了发生错误的可能性。
  • 不必将 DBCC 验证语句作为正常备份或维护过程的一部分来运行。在进行重大改动前（例如，硬件或软件升级前，或硬件出现故障后）应将它们作为系统检查的一部分来运行。如果怀疑系统有任何问题，也应当运行这些语句。

  • SQL Server 2000 引入了一个新的 PHYSICAL_ONLY 选项，此选项仅检查很可能由硬件问题产生的问题类型，从而使 DBCC 语句运行得更快。如果怀疑数据库服务器的硬件有问题，则运行带 PHYSICAL_ONLY 的 DBCC 检查。

  • DBCC 语句本身的运行速度也显著加快。对复杂数据库的检查速度一般快 8 到 10 倍，而对某些个别对象的检查速度则快 300 倍以上。在 SQL Server 6.5 中，DBCC CHECKDB 串行地处理表。它首先检查每个表中的基础数据结构，然后检查个别的索引。这导致一种非常随机的读取模式。在 SQL Server 2000 中，DBCC CHECKDB 执行串行的数据库扫描，同时在扫描时对多个对象执行并行检查。当运行并行 DBCC 语句时，SQL Server 2000 还利用多个处理器的优点。

  • SQL Server 2000 DBCC 语句所要求的锁定级别比 SQL Server 7.0 低得多。DBCC 语句现在可与数据修改语句同时运行，从而大大降低了对使用数据库的用户的影响。

  • SQL Server 2000 DBCC 语句可以修复可能遇到的小问题。这些语句可以修复索引 B 树结构中的某些错误，或者修复某些分配结构中的错误。

请参见

DBCC

优化 DBCC 性能


复制构架

复制是一套技术，使您得以在多个站点（有时甚至是在几百个站点上）保留相同数据的复本。

复制使用发布-订阅模式分发数据：

  • 发布服务器是要复制的数据源所在的服务器。发布服务器为每个要作为复制源使用的表或其它数据库对象定义项目。同一数据库中的一个或多个相关项目被组织到发布中。发布是把要复制的相关数据和对象组合在一起的简便方法。

  • 订阅服务器是接收发布服务器复制的数据的服务器。订阅服务器定义对特定发布的订阅。订阅指定订阅服务器从发布服务器接收发布的时间，并将项目映射到订阅服务器中的表和其它数据库对象。

  • 分发服务器是在将项目从发布服务器移动到订阅服务器时，执行各种不同任务的服务器。实际执行的任务取决于所执行的复制类型。

Microsoft® SQL Server™ 还支持与异类数据源之间的相互复制。OLE DB 或 ODBC 数据源可以订阅 SQL Server 发布。SQL Server 还可以接收从很多数据源复制的数据，这些数据源包括 Microsoft Exchange、Microsoft Access、Oracle 和 DB2。

复制类型

SQL Server 2000 使用三种类型的复制：

快照复制

快照复制可精确地复制数据或数据库对象在任一时刻的瞬时状态。快照发布通常被定义为按调度发生。订阅服务器包含发布的项目在上次快照复制时的复本。当源数据相对来说是静态的，订阅服务器可能已有些过期，以及要复制的数据量很少时，使用快照复制。

事务复制

在事务复制中，一般先通过快照复制使订阅服务器与发布服务器同步，然后，当发布数据被修改时，捕获事务并将其发送到订阅服务器。通过在发布服务器上进行所有的修改，然后将所有修改复制到订阅服务器，得以在订阅服务器间维护事务完整性。当必须在数据被修改时对其进行复制，必须保留事务，以及发布服务器和订阅服务器通过网络可靠和/或经常地连接在一起时，使用事务复制。

合并复制

合并复制使多个站点得以自主地使用一组订阅服务器，然后过一段时间将工作合在一起合并到发布服务器。通过快照复制使订阅服务器与发布服务器同步。对订阅服务器和发布服务器上的更改进行跟踪。过一段时间，合并更改以形成单个的数据版本。在合并过程中，如果多个订阅服务器修改相同的数据，可能会发生冲突。合并复制支持冲突解决程序的定义，即用来定义如何解决上述冲突的规则集。也可以编写自定义冲突解决程序脚本，以处理正确解决复杂冲突情形所需的任何逻辑。当自主运行对于订阅服务器计算机（例如移动的脱接用户）很重要时，或者当多个订阅服务器必须更新相同的数据时，使用合并复制。

配置和管理复制

SQL Server 2000 提供下列几种定义和管理复制的机制：

  • SQL Server 企业管理器支持配置和监视复制。

  • 用于通过编程配置和监视复制的 SQL-DMO 接口。

  • 用于复制异类数据源的数据的编程接口。

  • 用于在自定义应用程序中嵌入复制功能的 Microsoft ActiveX® 控件。

  • 编写使用 Transact-SQL 系统存储过程的复制脚本。

请参见

复制概述

快照复制

快照复制工作机制

合并复制

合并复制的工作机制

事务复制

事务复制工作机制

复制和异类数据源

复制工具


数据仓库和联机分析处理

Microsoft® SQL Server™ 2000 提供可用于生成数据仓库或数据集市的组件。数据仓库或数据集市可用于先进的企业智能系统，以处理发现趋势和分析关键因素所需的查询。这些系统称为联机分析处理 (OLAP) 系统。数据仓库和数据集市中的数据组织方式与传统的事务处理数据库不同。

企业级关系数据库管理软件（如 SQL Server 2000）最初旨在集中存储由大公司或政府机构中的日常事务所产生的数据。在过去的几十年中，这些数据库已发展成为记录执行企业日常操作所需数据的高效系统。由于这些系统基于计算机并记录企业的业务事务，因此被称为联机事务处理 (OLTP) 系统。

OLTP 系统

OLTP 系统中的数据主要被组织为支持如下事务：

  • 记录来自销售点终端或通过 Web 站点输入的定单。

  • 当库存水平降到定义的水平时，订购更多的货物。

  • 跟踪在制造厂被组装为成品的组件。

  • 记录职员数据。

  • 记录执照的持有者，如餐馆营业执照或驾驶执照。

个别事务能够很快地完成，并且只需访问相对较少的数据。OLTP 系统旨在处理同时输入的成百上千的事务。

尽管 OLTP 系统擅长记录支持日常操作所需的数据，但是 OLTP 数据的组织方式不能很容易地为管理人员提供计划单位工作所需的信息。管理人员需要对信息进行汇总，以获取分析影响单位或小组的趋势所需的信息。他们需要找出影响单位成功的关键因素，以及如何最好地调整那些提高企业成功的因素。他们需要找出企业的工作负荷如何受季节和年度趋势的影响，以便可以预测完成将来的工作所需的职员和资源数量。

OLAP 系统

旨在处理发现趋势和关键因素所需的查询的系统称为联机分析处理 (OLAP) 系统。OLAP 查询通常需要大量的数据。例如，政府机动车辆执照部的领导可能需要一份报告，显示过去二十年中每年由该部门注册的车辆的牌号和型号。对 OLTP 系统中的原始详细数据运行这类查询有两个结果：

  • 查询需要花很长时间聚合 (sum) 过去二十年的全部详细记录，所以报告不能及时准备好。

  • 查询产成很大的工作负荷，至少会减慢系统的普通用户以正常水平记录事务的速度。

另一个问题是许多大企业并不是只使用一个 OLTP 系统记录所有的事务数据。多数大企业有多个 OLTP 系统，在这些系统中，有许多是在不同的时间使用不同的软件和硬件开发出来的。在许多情况下，一个系统中用于标识项目的代码和名称与另一个系统中所使用的代码和名称是不同的。管理人员在运行 OLAP 查询时，通常需要能从其中的几个 OLTP 系统中引用数据。

OLAP 数据被组织到多维数据集中。与组织到关系表中的数据相比，多维数据集中的数据结构为 OLAP 查询提供了更好的性能。多维数据集的基本单元称为度量值。度量值是所分析数据的组成单元。例如，一家经营硬件商店的公司想分析出售的不同产品的收入和折扣。度量值就是售出的部件数、收入以及折扣总和。度量值是按维度组织的。在这个例子中，一个三维数据集可以有三个维度：时间、商店和产品。设想这三个维度形成三维虚拟数据集的逻辑 x、y 和 z 轴。

每个维度被划分为称为成员的单元。维度的成员通常被组织到层次结构中。相似的成员组合在一起，构成层次结构的层次。例如，时间维度层次结构的顶层可以是年，下一层是月，然后是周、日，最后位于层次结构底层的是小时。在这三个维度的交叉点，记录与这三个维度值相匹配的度量值。例如，假设开始于 2000 年 2 月 19 日、星期六下午一点的小时是时间维度成员，New York 州 Albany 市的 Store #2 店是商店维度成员，Easy-Clean Mops 是产品维度成员。在这三个维度的交叉点，单元中记录着售出了 10 个拖把，收入为 $90,00，平均折扣为 $1,00。

在任何一个 OLAP 系统中，为多维数据集定义的特定维度和度量值都取决于各种分析，而这些分析对企业很重要。将关系表中的 OLTP 数据转换为 OLAP 多维数据集，以及多维数据集的设计，这些都是非常复杂的领域，许多第三方书籍对此有专门论述。

OLAP 系统在数据仓库或数据集市中的 OLAP 数据上操作。数据仓库存储企业级 OLAP 数据，而数据集市较小，通常只适用于组织内的一项功能。

请参见

创建和维护数据库概述

创建和使用数据仓库概述


将 OLTP 数据转换到 OLAP 数据仓库

转换 OLTP 数据使其在 OLAP 系统中提供可接受的性能，这种转换需要执行下列过程：

合并数据

必须能够将特定项目（产品、顾客、职员）的全部相关信息从多个 OLTP 系统合并到一个 OLAP 系统。合并过程必须解决不同 OLTP 系统间的编码差别问题。例如，一个系统可能为每个职员指派一个 ID，而其它系统没有职员 ID。合并过程必须能够匹配两个系统中的常用职员数据，这多半可通过比较职员姓名和地址实现。合并过程还必须能够将各 OLTP 系统中使用不同数据类型存储的数据转换成在某个 OLAP 系统中使用的单一数据类型。您也必须选择 OLTP 系统中的哪些列与 OLAP 系统无关，并将这些列排除在合并过程外。

为 OLAP 系统提供输入数据的系统并不局限于传统的、位于中央位置的 OLTP 系统。重要的信息可以存储在多个遗留位置上，有些情况下甚至可以在文件共享上存储相对较小的数据源，如 Microsoft® Excel 电子表格。

清理数据

将 OLTP 数据合并到数据仓库中后，便提供了一个清理数据的机会。您可能会发现不同的 OLTP 系统以不同的方式拼写项目，或者合并过程可能没有覆盖以前不知道的拼写错误。还可能发现其它的不一致，例如同一商店、职员或顾客的地址不同。在可以将数据装载到数据仓库中供 OLAP 系统使用之前，必须找出这些不一致。

聚合数据

OLTP 数据记录所有的事务详细信息。OLAP 查询通常需要汇总数据或是已以某种方式聚合的数据。例如，如果数据库只包含显示每种产品每天或每小时销售额的汇总行，则查询只用检索过去一年中每种产品的月销售总额，这比必须扫描过去一年中每个事务的详细记录要快得多。

对数据仓库内数据的聚合程度取决于许多设计因素，如 OLAP 查询的速度要求和分析所要求的粒度级。例如，如果将销售额详细信息汇总到每日汇总中，而不是每小时汇总中，OLAP 查询将会运行得更快，但是只有当不需要分析每小时的销售额时才可以这么做。

将数据组织到多维数据集中

关系 OLTP 数据的组织方式增加了分析处理的难度且很耗时。当将 OLTP 数据移入数据仓库时，必须对其结构进行转换，使之能够更好地支持决策支持分析。生成数据仓库的过程涉及将存储在关系表中的 OLTP 数据重组为存储在多维数据集中的数据。

转换阶段和数据仓库组件

通过 OLAP 应用程序使数据可用的过程一般经过下列三个阶段：

  1. 将数据从 OLTP 或遗留数据源析取到中间存储区域中。

  2. 将数据转换为更适合在 OLAP 系统中使用的格式。这涉及数据清理和聚合等操作。

  3. 将数据装载到数据仓库或数据集市中。

从 OLTP 和遗留数据源中析取数据并将其转换到仓库服务器中的过程称为 ETL 过程，通常定期运行，如每周一次或每月一次。

一旦将数据装载到数据仓库中，OLAP 系统的一个重要职能便是为决策者提供在数据仓库和数据集市中访问和分析数据的便利。

下图显示对 OLAP 系统用于提供这些服务的组件的一般分类。

数据源

OLTP 数据库和其它遗留数据源，其内包含的数据必须转换为数据仓库和数据集市中的 OLAP 数据。

中间数据存储

组合的数据存储区和对 OLTP 数据进行存储、清理并转换为有用的 OLAP 数据的过程。

仓库服务器

仓库服务器是运行包含数据仓库和数据集市数据的关系数据库的计算机，以及运行管理 OLAP 数据的服务器的计算机。

业务智能

用于查询 OLAP 数据并向企业决策者提供报表和信息的成套工具和应用程序。

元数据

不同 OLAP 组件中的数据和应用程序的结构模型。元数据描述 OLTP 数据库中的表、数据仓库和数据集市中的多维数据集这类对象，还记录哪些应用程序引用不同的记录块。

请参见

创建和使用数据仓库概述


SQL Server 2000 数据仓库和 OLAP 组件

Microsoft® SQL Server™ 2000 提供几个组件（如下图所示），允许将 OLTP 数据转换为 OLAP 数据，并使 OLAP 信息可由决策者使用。

扩展标记语言和 OLE DB

扩展标记语言 (XML) 是一个标准，用以定义独立于特定的数据存储或应用程序的格式和数据表示语言。在应用程序间或通过 Web 传输数据方面，XML 正成为一种日益重要的标准。SQL Server 2000 能够将查询的结果集以 XML 文档的形式返回，也可以从 XML 文档中析取数据并将这些数据存储在数据库内的相关表中。

OLE DB 是 Microsoft 定义的公用数据访问规范。许多数据存储产品（如电子表格、数据库或其它服务器应用程序）都提供有 OLE DB 提供程序，可供 OLE DB 应用程序在访问数据时使用。使用 OLE DB API 的应用程序可以访问任何有相应 OLE DB 提供程序的数据。OLE DB 可以将数据表示为 XML 文档。OLE DB 2.5 还包含多维扩展，使 OLE DB 提供程序能够表现多维数据集中的信息。

XML 和 OLE DB 是在各种不同的 SQL Server 2000 数据仓库组件之间交流数据的重要机制。一些组件所使用的某些概念化模型的定义就是基于 XML。

Microsoft ActiveX® 数据对象 (ADO) 是映射在 OLE DB 上的对象 API，但是更简明和更易于编码。与 OLE DB 一样，ADO 也可以将数据作为 XML 文档返回，而且也支持多维扩展。许多应用程序将 ADO 用作访问 OLTP 数据的 API。

SQL Server 2000 关系数据库引擎

SQL Server 2000 数据库引擎主要用在 OLTP 系统中，也用于在转换要存储在数据仓库或数据集市中的 OLTP 数据时存储中间数据存储，以及用于存储和管理数据仓库或数据集市中的数据。

数据转换服务

DTS 是一个组件，用于从 OLE DB 数据源获取数据、执行聚合数据 (SUM, MIN, MAX, AVG) 等操作，并将数据存储在目的 OLE DB 数据源中。DTS 由包组成，包定义构成逻辑工作项的特定工作集，并且包含与数据源的多个连接、要执行的任务以及将连接与任务连起来的工作流。任务示例包括将数据从源连接复制到目的连接，转换来自源连接的数据并将转换的数据放在目的连接中，在连接上执行一组 Microsoft ActiveX 脚本或 Transact-SQL 语句。

DTS 将存储在关系表中的 OLTP 数据转换为不同的结构，以便可以用作多维数据集的基础。虽然 OLTP 数据库中的数据存储在实体和关系表中，但 OLAP 数据仓库中的数据却存储在事实数据表和维度表中。事实数据表存储多维数据集中表现的度量值，维度表则存储有关维度成员的信息。

对于不得不重复访问一种格式的数据并将其转换为另一格式的任何系统，DTS 是非常强大的工具。DTS 的使用不仅限于生成数据仓库，而且该组件的实力和功能非常适合将 OLTP 数据转换为 OLAP 数据仓库数据。有关更多信息，请参见 DTS 概述。

Analysis Services 和数据挖掘

Analysis Services 是一套易于使用、综合的可伸缩组件，使您可以生成多维数据集并向应用程序提供对多维数据集的访问。Analysis Services 为多维数据集提供的存储机制类型非常灵活。多维数据集可以作为单独的高性能多维数据结构 (MOLAP) 或作为两者的混合组合 (HOLAP) 存储在关系数据库 (ROLAP) 中。Analysis Services 支持多种向导，使得定义维度和多维数据集等任务执行起来十分容易。有关更多信息，请参见 Analysis Services 构架。

Analysis Services 通过 OLE DB 提供程序将多维数据集中的数据表现给应用程序。Analysis Services 提供程序支持被定义为 OLE DB 2.5 组成部分的多维扩展，还支持 ActiveX 数据对象（多维）(ADO MD) API。有关更多信息，请参见 DTS 应用程序设计。

Analysis Services 也支持工业标准数据挖掘算法。数据挖掘支持用于发现数据中的趋势和预测未来结果的新的先进工具。有关更多信息，请参见数据挖掘模型。

English Query

English Query 允许最终用户就存储在 SQL Server 2000 数据库、数据仓库和 OLAP 多维数据集中的信息，用英语提出问题。English Query 管理员定义数据库或多维数据集中的各种表和列、维度及数据仓库中的度量值之间的逻辑和语义关系。可以编写应用程序代码，提示最终用户将英文查询键入窗体的字符字段中。该字符串然后被传递到 English Query 引擎。该引擎根据管理员提供的数据逻辑定义对问题进行分析。当查询 OLAP 多维数据集时，English Query 引擎给应用程序返回一个 SQL 语句，以便从数据库中析取所请求的信息。当查询数据仓库或数据集市时，English Query 引擎返回 MDX 查询。应用程序执行 SQL 语句或 MDX 查询并将结果返回给最终用户。有关更多信息，请参见 English Query 概述。

Meta Data Services

SQL Server 2000 Meta Data Services存储了一个模型，用以映射 SQL Server 2000 数据库和数据仓库中的数据结构。该信息主要用于第三方迅速开发的工具，这些工具既可以建立应用程序原型，也可以提供基于 Meta Data Services模型中的信息的应用程序模板。有关更多信息，请参见 Meta Data Services概述。

请参见

Analysis Services 概述

创建和维护数据库概述

创建和使用数据仓库概述

DTS 概述

English Query 概述

Meta Data Services 概述


应用程序开发构架

应用程序使用两种组件访问数据库：

  • 应用程序接口 (API) 或统一资源定位器 (URL)。

    数据库 API 定义如何编写应用程序代码使之与数据库连接，以及如何向数据库传递命令。对象模型 API 通常不依赖于语言，用于定义一组对象、属性和接口，而 C 语言或 Microsoft® Visual Basic® API 则为用 C、C++ 或 Visual Basic 语言编写的应用程序定义一组函数。

    统一资源定位器是一个字符串或数据流，Internet 应用程序可通过它访问 Internet 或 Intranet 上的资源。Microsoft SQL Server™ 2000 提供 ISAPI 动态链接库 (DLL)，可供 Microsoft Internet Information 服务 (IIS) 应用程序用来生成引用 SQL Server 2000 实例的 URL。

  • 数据库语言。

    数据库语言定义给数据库传递命令的语法。通过 API 传递的命令使应用程序得以访问和修改数据。它们还使应用程序得以创建和修改数据库中的对象。所有命令都受限于授予用户的权限。SQL Server 2000 支持两种语言：

    • 运行在 IIS 上的 Internet 应用程序可以对映射架构使用 XPath 查询。

    • Transact-SQL 语言。
  • 本节主题提供有关 SQL Server 2000 所支持的 API 的信息，以及选择在应用程序中使用的 API 时需要考虑的问题。
Transact-SQL

SQL Server 2000 支持的数据库语言是 Transact-SQL。Transact-SQL 不但遵从 Entry 级的 SQL-92 标准，而且支持 Intermediate 和 Full 级的一些功能。Transact-SQL 还支持 SQL-92 标准的一些强大扩展。有关更多信息，请参见 Transact-SQL 概述。

ODBC 规范定义了在 SQL-92 标准中所定义的 SQL 扩展。OLE DB 也支持这些 ODBC SQL 扩展。Transact-SQL 支持来自使用 Microsoft ActiveX® 数据对象 (ADO)、OLE DB、ODBC API 或在 ODBC 上分层的 API 的应用程序的 ODBC 扩展。不支持来自使用 DB-Library 或嵌入式 SQL API 的应用程序的 ODBC SQL 扩展。

XPath

SQL Server 2000 支持由 World Wide Web Consortium (W3C) 定义的 XPath 语言的子集。XPath 是一种图形导航语言，可用于从 XML 文档中选择节点。首先使用映射架构，为一个或多个 SQL Server 表和视图中的数据定义基于 XML 的视图。然后使用 XPath 查询从该映射架构中检索数据。

通常在 URL 或 ADO API 中使用 XPath 查询，OLE DB API 也支持 XPath 查询。

SQL Server 支持的 API

SQL Server 支持很多用于生成通用数据库应用程序的 API，如：

  • 下面是用一些数据库供应商支持的规范公开定义的开放式 API：
    • ActiveX 数据对象 (ADO)

    • OLE DB

    • 开放式数据库连接 (ODBC) 和在 ODBC 上生成的对象 API：远程数据对象 (RDO) 和数据访问对象 (DAO)

    • 用于 C 语言的嵌入式 SQL (ESQL)
  • 用于某些 C API 的传统 DB-Library，这些 API 是过去专为在 SQL-92 标准之前存在的 SQL Server 早期版本开发的。

Internet 应用程序也可以使用 URL 来指定引用 SQL Server 实例的 IIS 虚拟根。URL 可包含 XPath 查询、Transact-SQL 语句或模板。除使用 URL 外，Internet 应用程序还可以使用 ADO 或 OLE DB 来处理 XML 文档格式的数据。


选择 API

在使用 Microsoft® SQL Server™ 2000 的新应用程序中，建议使用下面的通用应用程序接口 (API)：

  • Microsoft ActiveX® 数据对象 (ADO)，用于大多数数据库应用程序。ADO 支持可靠应用程序的快速开发，而且能访问大多数 SQL Server 功能。在使用用于 SQL Server 的 Microsoft OLE DB 提供程序时，ADO 支持大多数应用程序所需的 SQL Server 功能。

  • URL，用于 HTML 或 ASP 页等 Internet 应用程序。

  • OLE DB，用于在基于 COM 的工具和实用程序或基于 COM 的系统级开发中，获得最佳性能或对 ADO 没有表现的 SQL Server 功能的访问能力。用于 SQL Server 的 OLE DB 提供程序使用提供程序特有的属性、接口和方法来表现 OLE DB 规范没有包括的 SQL Server 功能。这些提供程序特有的功能大多未通过 ADO 表现。

  • ODBC，用于与上面列出的属于同一类别、但不是基于 COM 的应用程序。
选择通用 API

当选择在 SQL Server 应用程序中使用的通用 API 时，需要考虑几个因素：

  • API 规范的成熟性。
    • 现有规范

      现有的 API 规范是成熟、稳定的规范。可以很容易地从第三方的书和课程中获得有关这类 API 的补充信息。目前有一批程序员十分熟悉这类 API。

    • 新兴规范

      新兴的 API 规范是近期出现的，可能会迅速演变。有关 API 最新版本的补充信息可能很少。只有比较少的程序员用过这类 API，但熟悉类似的 API 的程序员可以迅速掌握它。

    • 传统规范

      传统 API 规范很稳定但没有变化。它们可能不支持新特性，在将来某个时候很可能会被废止。可以很容易获得有关这类 API 的信息，但熟悉这类 API 的程序员群体可能在缩小。

  • 开销。
    • 本机 API

      本机 API 是用特定的提供程序或驱动程序实现的低级 API，这些提供程序或驱动程序使用表格格式数据流 (TDS) 协议直接与 SQL Server 通讯。它们是相对复杂的 API，但由于开销最小，因此能提供最佳性能。

    • 对象模型 API

      对象模型 API 使用相对简单的对象模型封装本机 API。它们必须将对象映射到基础本机 API，因此效率不如本机 API，但其性能对几乎所有应用程序都是可以接受的。使用对象模型 API 的程序很容易编写和维护。对象模型 API 可能不会支持基础本机 API 的所有功能。

    • 宿主 API

      宿主 API 也封装本机 API，但不使用对象模型。在效率、易用性和功能集方面，宿主 API 与对象模型 API 存在相似的问题。

  • 开发人员控制程度。

    API 在总体功能集上有所不同。ADO 这类简单的 API 易于学习、编程和维护，但它们不支持 OLE DB 和 ODBC 这类更复杂的 API 的所有功能。如果 ADO、RDO 和 ESQL 这类 API 能够提供应用程序所需的功能，则可以使用这些 API，以利用它们的易用性。

  • 对 SQL Server 功能的访问。

    一些 API 对它们能使用的 SQL Server 功能在数量或类型上有限制。

  • 对 Microsoft SQL Server 2000 Analysis Services 功能的访问。

    Analysis Services、ADO MD 和用于 OLAP 的 OLE DB 支持联机分析处理。可以使用用于 SQL Server 的 OLE DB 提供程序，将这些服务与 ADO 和 OLE DB 应用程序集成。

  • 编程语言和工具对 API 的支持。

下表将 SQL Server 支持的通用数据库 API 映射到前面所列的因素。

API | 成熟性 | 开销 | 开发人员控制程度 | SQL Server 2000 功能支持 | SQL Server 2000 XML 支持 | OLAP 服务功能支持 | 语言支持
ADO | 现有规范 | OLE DB 上的对象模型 | 中 | 大多数 | 是 | 是 | Microsoft Visual Basic® Microsoft Visual C++® Microsoft Visual J++®
URL | 新兴规范 | OLE DB 上的数据流 | 低 | 有限 | 是 | 否 | HTML 动态服务器页 (ASP)
OLE DB | 现有规范 | 本机 | 高 | 全部 | 是 | 是 | Visual C++
ODBC | 现有规范 | 本机 | 高 | 全部 | 否 | 否 | Visual C++
RDO | 现有规范 | ODBC 上的对象模型 | 中 | 大多数 | 否 | 否 | Visual Basic Visual J++
DAO | 传统规范 | ODBC 上的对象模型 | 低 | 有限 | 否 | 否 | Visual Basic Visual C++
ESQL | 传统规范 | DB-Library 上的宿主 | 低 | 有限 | 否 | 否 | Visual C++ COBOL
用于 C 语言的 DB-Library | 传统规范 | 本机 | 高 | 有限 | 否 | 否 | Visual C++

其它 API

SQL Server 还支持许多接口，这些接口使应用程序得以充分利用 SQL Server 的所有功能：

  • SQL 分布式管理对象 (SQL-DMO API)

    一组用于管理 SQL Server 的 COM 接口。

  • 复制组件（复制组件程序设计 API）

    一组用于对 SQL Server 数据库之间的复制进行定义和管理的 COM 接口。也可以将异类数据库中的数据复制到 SQL Server。

  • 数据转换服务（数据转换服务 API）

    一组用于在 OLE DB 数据提供程序之间定义和执行复杂数据转换的 COM 接口（基于 OLE DB）。

  • 扩展存储过程 API（扩展存储过程 API）

    用于编写 SQL Server 扩展存储过程的 C 语言 API。

  • English Query API（SQL Server 和 English Query）

    自动化 API，用于对字符串取值，该字符串包含用户就 SQL Server 数据库或 OLAP 多维数据集中的信息所提出的问题。English Query 服务器返回 SQL 语句或 MDX 查询，用以检索用户所提问题的答案。

  • Analysis Services API（Analysis Services 应用程序设计）

    Analysis Services 表现多个 API：用于管理 OLAP 和数据挖掘对象的决策支持对象，用于访问 OLAP 多维数据集的 ADO 多维 (ADO MD) 和 OLE DB OLAP 扩展，以及数据挖掘功能。

  • Meta Data Services（Meta Data Services 应用程序设计）

    自动化 API，使应用程序和编程工具可以访问 SQL Server 数据库中的元数据模型。

请参见

生成 SQL Server 应用程序概述


SQL Server 和 ADO

Microsoft® ActiveX® 数据对象是一组自动化对象，这组对象使用 OLE DB API，并使应用程序得以使用来自 OLE DB 数据源的数据。这包括以许多不同的格式存储的数据，而不仅仅是 SQL 数据库中的数据。任何用启用自动化的语言（如 Microsoft Visual Basic®、Microsoft Visual C++®、Microsoft Visual J++® 和 Microsoft Visual FoxPro®）编写的应用程序都可以使用 ActiveX 数据对象 (ADO) API。

ADO 应用程序通过 OLE DB 提供程序访问数据。Microsoft SQL Server™ 2000 包含用于 SQL Server 的本机 Microsoft OLE DB 提供程序，可由 ADO 应用程序用于访问 SQL Server 中的数据。在 SQL Server 6.5 版和更早的版本中，ADO 应用程序必须使用在 Microsoft SQL Server ODBC 驱动程序层上分层的、用于 ODBC 的 OLE DB 提供程序。虽然 ADO 应用程序仍能对 SQL Server ODBC 驱动程序使用用于 ODBC 的 OLE DB 提供程序，但只使用用于 SQL Server 的 OLE DB 提供程序效率更高。

如果对 SQL Server 进行通用数据访问，建议首选 ADO API，原因如下：

  • ADO 易于学习和编程。

  • ADO 具有大多数通用应用程序所需的功能集。

  • ADO 使程序员能够快速生成功能强健的应用程序。

OLE DB 规范的核心功能提供大多数应用程序所需的全部数据访问功能。另外，OLE DB 使得个别的提供程序可以定义提供程序特有的机制，以支持提供程序所访问的数据引擎的附加功能。ADO 表现 OLE DB 的核心功能，但不表现提供程序特有的功能。在通过用于 SQL Server 的 OLE DB 提供程序的提供程序特有功能表现的 SQL Server 功能中，有几种功能 ADO 应用程序不能访问，例如 IRowsetFastLoad 大容量复制方法、SQL Server 特有的扩展诊断信息以及自动提取游标。

ADO 还支持 SQL Server 2000 的 XML 功能。这为被编码为使用 ADO 检索行集，然后将行集转换为 XML 文档的 Internet 应用程序，提供了一种很容易的迁移路径。这类应用程序可改用 ADO 来执行 XPath 查询或带 FOR XML 子句的 SELECT 语句。采用这种方法后，将在服务器上直接生成 XML 文档形式的结果集，而不必再在应用程序计算机上转换结果集。

ADO 是从以前基于 ODBC 的远程数据对象 (RDO) 和数据访问对象 (DAO) API 发展而来的。可以将 RDO 和 DAO 应用程序转换成 ADO，RDO 和 DAO 程序员可以快速学习 ADO。ADO 在动态服务器页 (ASP) 中广泛使用。

请参见

ADO SQL Server 应用程序设计


SQL Server 和统一资源定位器

统一资源定位器 (URL) 是格式化的字符串或数据流，可由 Internet 应用程序用于引用 Internet 或 Intranet 上的资源。Microsoft® SQL Server™ 2000 支持 URL 使用 SQL Server 数据库中的数据，并将结果作为 XML 文档返回。URL 可执行引用映射架构的 XPath 查询，该架构为 SQL Server 表中的数据定义基于 XML 的视图。URL 还可执行 Transact-SQL 语句或模板。

虽然从严格意义上讲，URL 不是 API，但建议使用 URL 机制从运行在 Microsoft Internet Information 服务 (IIS) 上的 Web 应用程序访问 SQL Server 数据。URL 易于在基于 HTML 和 XML 的环境下（如 HTML 页或动态服务器页 (ASP)）集成。指定 URL 来执行返回 XML 文档的 XPath 查询或 Transact-SQL 语句，是将 SQL Server 结果集成到 Web 应用程序中的相对简单的方法。

请参见

XML 和 Internet 支持概述

URL Access


SQL Server 和 OLE DB

OLE DB是一种 API，它使 COM 应用程序得以使用来自 OLE DB 数据源的数据。OLE DB 数据源包括以很多不同的格式存储的数据，而不仅仅是 SQL 数据库中的数据。应用程序使用 OLE DB 提供程序访问 OLE DB 数据源。OLE DB 提供程序是一个 COM 组件，它接受对 OLE DB API 的调用并采取任何必要的操作来处理对数据源的请求。

Microsoft® SQL Server™ 2000 包含用于 SQL Server 的本机 Microsoft OLE DB 提供程序，可由 OLE DB 应用程序用于访问 SQL Server 中的数据。用于 SQL Server 的 OLE DB 提供程序遵从 OLE DB 2.0 规范。每个 OLE DB 提供程序支持一种命令语言；用于 SQL Server 的 OLE DB 提供程序接受按照 DBGUID_SQL 指定的命令语法。DBGUID_SQL 语法主要是带 ODBC 转义序列的 SQL-92 语法。

在 SQL Server 6.5 版或更早的版本中，OLE DB 应用程序必须使用在 Microsoft SQL Server ODBC 驱动程序上分层的、用于 ODBC 的 OLE DB 提供程序。虽然 OLE DB 应用程序仍能对 SQL Server ODBC 驱动程序使用用于 ODBC 的 OLE DB 提供程序，但只使用用于 SQL Server 的 OLE DB 提供程序效率更高。

建议对工具、实用程序或系统级开发使用 OLE DB API，以获得最佳的性能或对 ADO 没有表现的 SQL Server 功能的访问能力。OLE DB 规范的核心功能提供大多数应用程序所需的全部数据访问功能。另外，OLE DB 使得个别的提供程序可以定义提供程序特有的机制，以支持提供程序所访问的数据引擎的附加功能。在通过用于 SQL Server 的 OLE DB 提供程序的提供程序特有功能表现的 SQL Server 功能中，有几个功能 ADO 应用程序不能访问，因此应用程序如果需要使用用于 SQL Server 的 OLE DB 提供程序的提供程序特有功能，就必须使用 OLE DB API。这些功能包括：

  • IRowsetFastLoad 接口，用于连接到 SQL Server 大容量复制组件。

  • ISQLServerErrorInfo 接口，用于从消息和错误中得到 SQL Server 特有的信息。

  • LINKEDSERVERS 行集，用于表现在 SQL Server 分布式查询中使用的链接服务器内的目录信息。

  • 提供程序特有的各种属性，用于控制 SQL Server 特有的行为。

OLE DB 还支持 SQL Server 2000 的 XML 功能。这为被编码为使用 OLE DB 检索行集，然后将行集转换为 XML 文档的 Internet 应用程序，提供了一种很容易的迁移路径。这类应用程序可改用 OLE DB 来执行 XPath 查询或带 FOR XML 子句的 SELECT 语句，采用这种方法后，将在服务器上直接生成 XML 文档形式的结果集，而不必再在应用程序计算机上转换结果集。大多数使用 XML 的应用程序是用 ADO 编写的或是使用 URL，这比 OLE DB 简单。

请参见

OLE DB SQL Server 应用程序设计


SQL Server 和 ODBC

开放式数据库连接 (ODBC) 是一个调用级接口 (CLI)，该接口使 C 和 C++ 应用程序得以访问来自 ODBC 数据源的数据。CLI 是一个 API，包含由应用程序调用以获得一系列服务的函数。ODBC 数据源包括以不同的格式存储的数据，而不仅仅是 SQL 数据库中的数据。应用程序使用 ODBC 驱动程序访问数据源。ODBC 驱动程序是一个动态链接库 (DLL)，它接受对 ODBC API 函数的调用并采取任何必要的操作来处理对数据源的请求。

ODBC 遵从这些定义数据访问 CLI 的规范和标准：

  • X/Open CAE 规范"数据管理：SQL 调用级接口 (CLI)"

  • ISO/IEC 9075-3：1995(E) 调用级接口 (SQL/CLI)

ODBC 已被数据库程序员广泛接受，一些数据库供应商或第三方公司提供 ODBC 驱动程序。其它几个 Microsoft 数据访问 API 在 ODBC 上被定义为简化的对象模型，如：

  • 远程数据对象 (RDO)

  • 数据访问对象 (DAO)

  • Microsoft 基础类 (MFC) 数据库类

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 Server 功能的访问能力，且它们不是 COM 应用程序，则可以在其中使用 ODBC。与 OLE DB 一样，ODBC 也使得个别的驱动程序可以定义驱动程序特有的机制，以支持驱动程序所访问的数据引擎的附加功能。这些功能包括：

  • 一组基于以前的 DB-Library 大容量复制函数的大容量复制函数。

  • 对 ODBC 诊断功能和记录的扩展，以便从消息和错误中获得 SQL Server 特有的信息。

  • 一组表现目录信息的函数，这些信息来自在 SQL Server 分布式查询中使用的链接服务器。

  • 驱动程序特有的各种特性和连接字符串关键字，用于控制 SQL Server– 特有的行为。

请参见

ODBC SQL Server 应用程序设计


SQL-DMO API

SQL 分布式管理对象 (SQL-DMO) 封装 Microsoft® SQL Server™ 2000 数据库中的对象。SQL-DMO 允许用支持自动化或 COM 的语言编写应用程序，以管理 SQL Server 安装的所有部分。SQL-DMO 是 SQL Server 2000 中的 SQL Server 企业管理器所使用的应用程序接口 (API)；因此使用 SQL-DMO 的应用程序可以执行 SQL Server 企业管理器执行的所有功能。

SQL-DMO 用于必须包含 SQL Server 管理的任何自动化或 COM 应用程序，例如：

  • 封装 SQL Server 作为自己的数据存储并想尽量减少用户的 SQL Server 管理任务的应用程序。

  • 在程序本身并入了专门的管理逻辑的应用程序。

  • 想在自己的用户界面中集成 SQL Server 管理任务的应用程序。
Windows 管理规范

SQL Server 2000 光盘支持一个新的 API，此 API 使您得以使用 Windows 管理规范 (WMI) 管理 SQL Server 实例。WMI 是带有面向对象 API 的可升级的 Windows 2000 组件，它允许管理应用程序和脚本监视、配置和控制 Windows 网络中的操作系统和设备、服务及应用程序。通过使用标准的 Windows 安全设置，WMI 只允许适当授权的用户管理系统。WMI 核心组件可用于 Windows NT® 4.0、Windows 95 和 Windows 98。有关这些操作系统的 WMI 支持的更多信息，请参见位于 Microsoft Web 站点的 MSDN® 页。

组件（如 SQL Server）通过提供 WMI 提供程序和定义 WMI 类架构来启用 WMI 支持。此架构在可使用 WMI 管理的组件中建立对象模型。SQL Server 2000 包含 SQL Server WMI 提供程序和一个架构类模型，此模型将 SQL Server 2000 实例映射到 WMI 类。SQL Server WMI 架构建立对象模型，如数据库和表。SQL Server WMI 版本提供如下管理功能：

  • 创建、更改或删除被管理的对象。例如，创建一个数据库。

  • 管理被管理的对象。例如，备份数据库和日志。

  • 枚举被管理的对象。例如，列出数据库中的所有表。

  • 检索有关特定被管理对象的信息。例如，确定是否在 Customers 表上启用了全文索引。

  • 查询满足特定标准的被管理对象。例如，列出所有的加密存储过程。

  • 执行为被管理对象定义的方法。例如，执行从表中大容量复制数据的方法。

  • 当创建、更改或删除被管理对象时产生事件（例如，当更改数据库选项时产生事件）。

  • 描述被管理对象之间的关系（例如，识别有权访问数据库的登录）。

所有 WMI 数据都可远程使用且完全可编写脚本。SQL Server 2000 WMI 版本映射在 SQL-DMO API 上，但不支持对复制进行管理。SQL Server WMI 版本可与 SQL Server 7.0 一起使用。

SQL Server WMI 支持不是由 SQL Server 2000 安装程序安装的。所有 WMI 材料，包括独立的安装程序和文档，都包含在 SQL Server 2000 光盘上的 \x86\OTHER\wmi 文件夹中。

请参见

管理构架

开发 SQL-DMO 应用程序


SQL 命名空间 API

SQL 命名空间 (SQL-NS) 应用程序接口 (API) 是一组封装 SQL Server 企业管理器用户界面的对象。SQL-NS 允许用支持自动化或 COM 的语言编写应用程序，以在应用程序的用户界面中包括 SQL Server 企业管理器用户界面的各部分。

通过 SQL-NS，应用程序可以将下列 SQL Server 企业管理器元素合并到它的用户界面中：

  • 向导

  • 对话框（包括属性对话框）

当应用程序使用 SQL-NS 对象时，任何想要运行 SQL-NS 应用程序的客户端都必须安装 SQL Server 企业管理器。

请参见

管理构架

SQL-NS 应用程序设计


复制组件程序设计 API

除 SQL-DMO 中的复制对象外，Microsoft® SQL Server™ 2000 还包含一组复制对象。这些对象包括：

  • 复制分发服务器接口，当该接口与可对异类数据源执行更改跟踪的第三方程序合用时，使您得以以编程方式执行和管理异类事务复制。

  • Microsoft ActiveX® 控件，使您得以在自定义程序中提供分发代理程序或合并代理程序的功能。

请参见

管理构架

开发 SQL-DMO 应用程序

复制概述

使用 ActiveX 控件开发复制应用程序

执行从异类数据源的复制


数据转换服务 API

数据转换服务 (DTS) 应用程序接口 (API) 是一组对象，用以封装帮助生成数据仓库的服务。可以在用支持自动化或 COM 的语言编写的应用程序中使用 DTS：

  • DTS 在异类 OLE DB 数据源之间传输数据。

  • DTS 执行自定义转换，将详细的联机事务处理 (OLTP) 数据转换成汇总形式，以便更容易分析趋势信息。

请参见

DTS 概述

DTS 应用程序设计


SQL Server 和 English Query

English Query 提供一个自动化 API，该 API 使用户得以解决就 Microsoft® SQL Server™ 数据库中的信息用自然语言提出的问题。

给出与 SQL Server 数据库关联的实体和关系的定义后，English Query 将就数据库内的数据用自然语言提出的问题翻译成一组 SQL SELECT 语句，然后可以对这个 SQL Server 数据库执行这些语句以找到答案。

例如，假设有一个汽车销售数据库，应用程序可以给 English Query 发送一个字符串，其中包含这样的问题"How many blue Fords were sold in 1996?"（1996 年销售了多少辆蓝色"福特"牌汽车？）。

English Query 给应用程序返回如下的 SQL 语句：

SELECT COUNT(*)
FROM CarSales
WHERE Make = 'Ford'
  AND Color = 'Blue'
  AND DATEPART(yy, SalesDate) = '1996'

应用程序随后可以对这个 SQL Server 数据库执行该 SQL 语句，以获得可返回给用户的数字。

English Query 对规范化数据库效果最好。在应用程序中使用 English Query 有两方面的工作要做：

  1. 管理员为数据库定义 English Query 工程，并用该工程编译所谓的 English Query 应用程序文件。English Query 模型是定义数据库到English Query运行时引擎结构的模型。

    English Query 模型包含：

    • 实体的定义，这些实体通常与数据库的表和列相关联。

    • 实体间的关系定义。
  2. 用模型编辑器定义模型，并用测试工具对其进行测试。将结果保存为 English Query 工程 (.eqd) 文件。编译这个文件，使之形成 English Query 应用程序 (.eqd) 文件。

English Query 使用全文检索生成强大的查询，以便从全文索引所覆盖的 SQL Server 数据库列中析取数据。有关更多信息，请参见全文检索。

English Query 还生成查询，以便从存储在 Analysis Services 内的 OLAP 多维数据集中析取数据。当作为 Analysis Services 的前端使用时，English Query 生成从 OLAP 多维数据集中析取数据所需的 MDX 语句。有关更多信息，请参见 English Query 中的 Analysis Services。

English Query 是自动化服务器，可从任何自动化应用程序调用。自动化服务器或运行时引擎表现一个对象模型 API。自动化应用程序使用该 API 装载 English Query 应用程序文件，然后给运行时引擎发送用自然语言提出的问题。运行时引擎通常返回一个或一批 SQL 语句，这些语句将从 SQL Server 数据库中检索所需信息。运行时引擎有时会直接提供答案、请求澄清问题或返回错误。

请参见

安装 English Query


扩展存储过程 API

扩展存储过程应用程序接口 (API) 是 Microsoft® SQL Server™ 2000 专用的基于服务器的 API。该 API 可用于生成扩展存储过程。扩展存储过程是 C 或 C++ 动态链接库 (DLL)，可以使用与调用 Transact-SQL 存储过程相同的语法从 Transact-SQL 中调用它。扩展存储过程是一种扩展 Transact-SQL 功能的方法，以便包括可由 Microsoft Win32® 应用程序使用的任何资源或服务。

请参见

编写扩展存储过程


SQL Server 和嵌入式 SQL

嵌入式 SQL (ESQL) 是用于 SQL 数据库访问的 SQL-92 标准应用程序接口 (API)。ESQL 的编译需要分两步进行：

  1. 预编译器将嵌入式 SQL 语句翻译成编写该应用程序所使用的编程语言中的命令。生成的语句专供提供预编译器的数据库使用，因此，虽然原始源程序与 ESQL 同类，但生成的语句和最后的可执行文件专门用于某个数据库供应商。

  2. 然后，用应用程序编程语言的编译器编译由预编译器生成的源程序。

与 OLE DB 这类 COM API 或 ODBC 这类调用级接口相比，嵌入式 SQL 的语法更简单，因此更易于学习和编程。但嵌入式 SQL 不如 OLE DB 或 ODBC 灵活，在用 OLE DB 或 ODBC 精心编写的应用程序中，只需切换驱动程序或提供程序，即可从一个 DBMS 切换到另一个。在编译应用程序（例如开发按需查询工具时）时不识别 SQL 语句的环境中，更适合使用 OLE DB 和 ODBC。

Microsoft® SQL Server™ 2000 提供用于 C 应用程序的嵌入式 SQL 预编译器。这个 SQL Server 预编译器将嵌入式 SQL语句翻译成对适当 DB-Library API 函数的调用。Microsoft 实现的 ESQL 与 DB-Library 应用程序有相同的限制。

SQL Server 旨在支持用与 Microsoft SQL Server 兼容的第三方嵌入式 SQL 预编译器编译的 COBOL 嵌入式 SQL 应用程序。

请参见

用于 C 语言的嵌入式 SQL 程序设计


DB-Library API

DB-Library 是调用级接口，允许 C 应用程序访问 Microsoft® SQL Server™ 2000。DB-Library 是当初允许应用程序访问 SQL Server 的应用程序接口 (API)，一直为 SQL Server 所专用。

DB-Library API 的功能没有超过 SQL Server 6.5 版的水平。所有的 DB-Library 应用程序都能使用 SQL Server 2000，但只相当于 6.5 水平的客户端。SQL Server 2000 和 SQL Server 7.0 版中引入的功能不支持 DB-Library 应用程序。

SQL Server 2000 不包括用于 Microsoft Visual Basic® 的 DB-Library 编程环境。现有的用于 Visual Basic 应用程序的 DB-Library 能在 SQL Server 2000 上运行，但必须使用 SQL Server 6.5 版中的软件开发工具进行维护。开发任何访问 SQL Server 的新 Visual Basic 应用程序时，都应使用 Visual Basic 数据 API，如 Microsoft ActiveX® 数据对象 (ADO) 和远程数据对象 (RDO)。

请参见

用于 C 语言的 DB-Library 引用


SQL 语法建议

Microsoft® SQL Server™ 2000 Transact-SQL 版遵从 Entry 级 SQL-92标准，并支持 Intermediate 级和 Full 级标准中的很多附加功能。

开发 OLE DB 和 ODBC 应用程序接口 (API) 时的设想是：

  • 每当 SQL-92 语法提供应用程序所需功能时，应用程序都使用该语法。鉴于现在大多数数据库 SQL 语言都遵从 SQL-92 的 Entry 级标准，并支持 SQL-92 的 Intermediate 级和 Full 级标准中的很多功能，这意味着很多 OLE DB 提供程序和 ODBC 驱动程序只需直接传递大多数 SQL-92 语法即可，而不用将语法转换成数据库接受的形式。

  • 每当 SQL-92 的 ODBC 扩展提供应用程序需要但 SQL-92 不支持的功能时，应用程序都使用该扩展。

  • 每当数据库引擎的本机 SQL 语法提供应用程序需要但 SQL-92 和 ODBC 扩展不支持的功能时，应用程序都使用该语法。

这种方法使 OLE DB 提供程序和 ODBC 驱动程序的开销减到最小。提供程序和驱动程序只需分析 ODBC 转义序列的外来 SQL 语句或数据库不接受的 SQL-92 语法。任何 ODBC 转义序列和不支持的 SQL-92 语法都转换成数据库引擎接受的相应的 SQL 语法。所有其它的 SQL 语法直接传递给数据库引擎。

SQL Server 2000 应用程序在使用 OLE DB、ODBC 或其它封装两者的 API 时，应遵循下面的准则：

  • 每当 SQL-92 语法提供应用程序所需的功能时都使用该语法。

  • 每当 ODBC 转义序列提供应用程序需要但 SQL-92 不支持的功能时，都使用该序列。

  • 每当 Transact-SQL 语法提供应用程序需要但 SQL-92 或 ODBC 转义序列不支持的功能时，都使用该语法。
在 DB-Library 和嵌入式 SQL 中使用 SQL

DB-Library 仅支持 Transact-SQL。DB-Library 不支持 ODBC 转义序列和 XML 功能。

用于 C 语言的嵌入式 SQL 仅支持在用于 C 语言的嵌入式 SQL 和 Microsoft® SQL Server™ 中定义的 SQL 语法。

DB-Library 自 SQL Server 6.5 版后一直未扩展过。它作为 6.5 版水平的客户端运行，并且不能使用 Microsoft SQL Server 2000 和 Microsoft SQL Server 7.0 版中引入的新特性。嵌入式 SQL 使用 DB-Library 与 SQL Server 通讯，因此对它也有同样的限制。有关更多信息，请参见将早期版本客户端连接到 SQL Server 2000。


实施细则

本节中的主题提供 Microsoft® SQL Server™ 2000 的版本信息及支持这些版本的环境信息。还提供有关 SQL Server 2000 对象的最大容量和内存使用的信息。


SQL Server 2000 的各种版本

Microsoft® SQL Server™ 2000 的可用版本如下：

SQL Server 2000 企业版

作为生产数据库服务器使用。支持 SQL Server 2000 中的所有可用功能，并可根据支持最大的 Web 站点和企业联机事务处理 (OLTP) 及数据仓库系统所需的性能水平进行伸缩。

SQL Server 2000 标准版

作为小工作组或部门的数据库服务器使用。

SQL Server 2000 个人版

供移动的用户使用，这些用户有时从网络上断开，但所运行的应用程序需要 SQL Server 数据存储。在客户端计算机上运行需要本地 SQL Server 数据存储的独立应用程序时也使用个人版。

SQL Server 2000 开发版

供程序员用来开发将 SQL Server 2000 用作数据存储的应用程序。虽然开发版支持企业版的所有功能，使开发人员能够编写和测试可使用这些功能的应用程序，但是只能将开发版作为开发和测试系统使用，不能作为生产服务器使用。

SQL Server 2000 Windows CE 版

使用 Microsoft® SQL Server 2000™ Windows® CE 版 (SQL Server CE) 在 Windows CE 设备上进行数据存储。能用任何版本的 SQL Server 2000 复制数据，以使 Windows CE 数据与主数据库保持同步。

SQL Server 2000 企业评估版

可从 Web 上免费下载的功能完整的版本。仅用于评估 SQL Server 功能；下载 120 天后该版本将停止运行。

除了这些版本的 SQL Server 2000 之外，SQL Server 2000 Desktop Engine 组件允许应用程序开发人员用他们的应用程序分发 SQL Server 2000 关系数据库引擎的复本。因为 SQL Server 2000 Desktop Engine 中的数据库引擎的功能与 SQL Server 各版本中的数据库引擎相似，所以 Desktop Engine 数据库的大小不能超过 2 GB。

SQL Server 2000 桌面版和 SQL Server 2000 个人版都有一个并发工作负荷调控器，可在并发执行 5 个以上的批处理时限制数据库引擎的性能。有关并发工作负荷调控器的更多信息，请参见桌面上的 SQL Server 2000 数据库。

从一个版本升级到另一个版本

下面是在 SQL Server 2000 的功能版本和版次之间支持的一些升级途径：

  • 将 SQL Server 2000 个人版升级到 SQL Server 2000 企业版或 SQL Server 2000 标准版。

  • 将 SQL Server 2000 标准版升级到 SQL Server 2000 企业版。

  • 将 SQL Server 2000 Desktop Engine 升级到 SQL Server 2000 企业版或 SQL Server 2000 标准版。


SQL Server 2000 的各种版本所支持的操作系统

下表列出各 Microsoft® SQL Server™ 2000 版本支持的运行服务器软件的操作系统。

操作系统 | 企业版 | 标准版 | 个人版 | 开发版 | Desktop Engine | SQL Server CE | 企业评估版
Microsoft Windows® 2000 DataCenter | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持
Windows 2000 Advanced Server | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持
Windows 2000 Server | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持
Windows 2000 Professional | 暂缺 | 暂缺 | 支持 | 支持 | 支持 | 暂缺 | 支持
Microsoft Windows NT® 4.0 Server 企业版 | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持
Windows NT 4.0 Server | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持
Windows NT 4.0 Workstation | 暂缺 | 暂缺 | 支持 | 支持 | 支持 | 暂缺 | 支持
Microsoft Windows 98 | 暂缺 | 暂缺 | 支持 | 暂缺 | 支持 | 暂缺 | 暂缺
Microsoft Windows CE | 暂缺 | 暂缺 | 暂缺 | 暂缺 | 暂缺 | 支持 | 暂缺

说明 来自除 SQL Server Windows CE 外的所有 SQL Server 2000 版本的客户端软件可在任何版本的 Microsoft Windows NT、Microsoft Windows 2000 和 Microsoft Windows 98 上运行。只有服务器组件（如数据库引擎和分析服务器）必须在特定版本的操作系统上使用。例如，虽然 SQL Server 2000 企业版不在 Windows 2000 Professional、Windows NT Workstation 或 Windows 98 上运行，但是也能使用 SQL Server 2000 企业版光盘在这些操作系统上安装客户端软件。SQL Server 2000 中文版不支持英文版的 NT 4.0 企业版。

来自 SQL Server CE 的所有软件以独占方式在 Windows CE 操作系统上运行。


SQL Server 2000 的各种版本所支持的功能

本主题概述了不同的 Microsoft® SQL Server™ 2000 版本所支持的功能。

有关 SQL Server 2000 可寻址的物理内存量和每个版本在对称多处理器 (SMP) 计算机中支持的 CPU 数的更多信息，请参见最大容量说明。

SQL Server 2000 版本支持的数据库引擎功能

下表列出数据库引擎功能及支持它们的 SQL Server 2000 版本。

数据库引擎功能 | 企业版 | 标准版 | 个人版 | 开发版 | Desktop Engine | SQL Server CE | 企业评估版
支持多个实例 | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持
故障转移群集（最多四个节点） | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
支持 SQL Server 企业管理器中的故障转移 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
日志传送 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
并行 DBCC | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
并行 CREATE INDEX | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
增强的预读和扫描 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
索引视图 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
联合数据库服务器 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
支持系统区域网络 (SAN) | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
图形 DBA 和开发人员实用工具向导 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 暂缺 | 支持
支持语言设置的图形实用工具 | 支持 | 暂缺 | 暂缺 | 暂缺 | 暂缺 | 暂缺 | 暂缺
全文检索 | 支持 | 支持 | 支持（Windows 98 除外） | 支持 | 暂缺 | 暂缺 | 支持

SQL Server 2000 版本支持的复制功能

下表列出复制功能及支持它们的 SQL Server 2000 版本。

复制发布服务器功能 | 企业版 | 标准版 | 个人版 | 开发版 | Desktop Engine | SQL Server CE | 企业评估版
快照复制 | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持
事务复制 | 支持 | 支持 | 仅在订阅服务器上支持 | 支持 | 仅在订阅服务器上支持 | 暂缺 | 支持
合并复制 | 支持 | 支持 | 支持 | 支持 | 支持 | 仅在匿名订阅服务器上支持 | 支持
即时更新订阅 | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持
排队更新订阅服务器 | 支持 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 支持

SQL Server 2000 版本支持的 Analysis Services 功能

下表列出 Analysis Services 功能及支持它们的 SQL Server 2000 版本。

Analysis Services 功能 | 企业版 | 标准版 | 个人版 | 开发版 | Desktop Engine | SQL Server CE | 企业评估版
Analysis Services | 支持 | 支持 | 支持 | 支持 | 暂缺 | 暂缺 | 支持
用户定义 OLAP 分区 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
分区向导 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
链接 OLAP 多维数据集 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
ROLAP 维度支持 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
支持 HTTP Internet | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
自定义汇总 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 暂缺 | 支持
计算单元 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
回写到维度 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
支持超大型维度 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
对策 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 暂缺 | 支持
实时 OLAP | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
分布式分区多维数据集 | 支持 | 暂缺 | 暂缺 | 支持 | 暂缺 | 暂缺 | 支持
挖掘模型 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 暂缺 | 支持

SQL Server 2000 版本支持的数据转换和决策支持查询功能

下表列出数据转换和决策支持查询功能及支持它们的 SQL Server 2000 版本。

Analysis Services 功能 | 企业版 | 标准版 | 个人版 | 开发版 | Desktop Engine | SQL Server CE | 企业评估版
数据转换服务 | 支持 | 支持 | 支持 | 支持 | 仅在部署时支持 | 暂缺 | 支持
集成的数据挖掘 | 支持 | 支持 | 支持 | 支持 | 暂缺 | 暂缺 | 支持
English Query | 支持 | 支持 | 支持 | 支持 | 暂缺 | 暂缺 | 支持


最大容量说明

第一个表说明对于所有 Microsoft® SQL Server™ 2000 版本都相同的最大容量。第二个和第三个表说明因 SQL Server 2000 的版本和操作系统的不同而异的容量。

下表说明在 Microsoft SQL Server 数据库中定义的，或在 Transact-SQL 语句中引用的各种对象的最大值（数量或大小）。下表不包含 Microsoft® SQL Server 2000™ Windows® CE 版。

 | 最大值（数量或大小）
对象 | SQL Server 7.0 | SQL Server 2000
批处理大小 | 65,536 * 网络数据包大小1 | 65,536 * 网络数据包大小1
每个短字符串列的字节数 | 8,000 | 8,000
每个 text、ntext、或 image 列的字节数 | 2 GB－2 | 2 GB－2
每个 GROUP BY、ORDER BY的字节数 | 8,060 |
每个索引中的字节数 | 900 | 9002
每个外键的字节数 | 900 | 900
每个主键的字节数 | 900 | 900
每行字节数 | 8,060 | 8,060
存储过程源文本中的字节数 | 批处理大小之较小者或者 250 MB | 批处理大小之较小者或者 250 MB
每个数据表的聚集索引数 | 1 | 1
GROUP BY、ORDER BY 中的列数 | 只受字节数限制 |
GROUP BY WITH CUBE 或 WITH ROLLUP 语句中的列数或表达式数目 | 10 |
每个索引的列数 | 16 | 16
每个外键的列数 | 16 | 16
每个主键的列数 | 16 | 16
每个基础数据表的列数 | 1,024 | 1,024
每个SELECT 语句的列数 | 4,096 | 4,096
每个INSERT 语句的列数 | 1,024 | 1,024
每个客户端的连接个数 | 已配置连接的最大值 | 已配置连接的最大值
数据库大小 | 1,048,516 TB3 | 1,048,516 TB3
每个 SQL Server 实例的数据库个数 | 32,767 | 32,767
每个数据库的文件组个数 | 256 | 256
每个数据库的文件个数 | 32,767 | 32,767
文件大小（数据） | 32 TB | 32 TB
文件大小（日志） | 4 TB | 32 TB
每个数据表的外键表引用 | 253 | 253
标识符长度（以字符计） | 128 | 128
每台计算机的实例数 | 暂缺 | 16
包含 SQL 语句的字符串长度（批处理大小） | 65,536 * 网络数据包大小1 | 65,536 * 网络数据包大小1
每个连接的锁数 | 每个服务器的最大锁数 | 每个服务器的最大锁数
每个 SQL Server 实例的锁数 | 2,147,483,647（静态） SQL Server 40％ 的内存（动态） | 2,147,483,647（静态） SQL Server 40％ 的内存（动态）
嵌套存储过程层数 | 32 | 32
嵌套子查询 | 32 | 32
嵌套触发器层数 | 32 | 32
每个数据表的非聚集索引个数 | 249 | 249
SQL Server 实例中同时打开的对象个数4 | 2,147,483,647（或可用内存） | 2,147,483,647（或可用内存）
每个数据库中的对象个数 | 2,147,483,6474 | 2,147,483,6474
每个存储过程的参数个数 | 1,024 | 1,024
每个数据表的 REFERENCE 个数 | 253 | 253
每个数据表的行数 | 受可用存储资源限制 | 受可用存储资源限制
每个数据库的数据表个数 | 受数据库中的对象个数限制4 | 受数据库中的对象个数限制4
每个 SELECT 语句的数据表个数 | 256 | 256
每个数据表的触发器个数 | 受数据库中的对象个数限制4 | 受数据库中的对象个数限制4
每个数据表的 UNIQUE 索引个数或约束个数 | 249个非聚集索引和 1 个聚集索引 | 249个非聚集索引和 1 个聚集索引

1 网络数据包大小是表格格式数据方案 (TDS) 数据包的大小，该数据包用于应用程序和关系数据库引擎之间的通讯。默认的数据包大小为 4 KB，由 network packet size 配置选项控制。
2 在 SQL Server 2000 中，任何键的最大字节数不能超过 900。可以使用可变长度的列来定义键，只要在这种列中不插入数据超过 900 字节的行，其最大大小就可以在 900 以上。有关更多信息，请参见索引键的最大值。
3 当使用 SQL Server 2000 Desktop Engine 或 Microsoft 数据引擎 (MSDE) 1.0 时，数据库的大小不能超过 2 GB。
4数据库对象包括所有的表、视图、存储过程、扩展存储过程、触发器、规则、默认值及约束。一个数据库中所有对象的总数不得超过 2,147,483,647。

说明 SQL Server 2000 中文版不支持英文版的 NT 4.0 企业版。

SQL Server 2000 版本支持的最大处理器数

下表列出各 SQL Server 2000 版本中的数据库引擎在对称多处理 (SMP) 计算机上能够支持的处理器数。

操作系统 | 企业版 | 标准版 | 个人版 | 开发版 | Desktop Engine | SQL Server CE | 企业评估版
Microsoft Windows® 2000 DataCenter | 32 | 4 | 2 | 32 | 2 | 暂缺 | 32
Windows 2000 Advanced Server | 8 | 4 | 2 | 8 | 2 | 暂缺 | 8
Windows 2000 Server | 4 | 4 | 2 | 4 | 2 | 暂缺 | 4
Windows 2000 Professional | 暂缺 | 暂缺 | 2 | 2 | 2 | 暂缺 | 2
Microsoft Windows NT® 4.0 Server 企业版 | 8 | 8 | 2 | 8 | 2 | 暂缺 | 8
Windows NT 4.0 Server | 4 | 4 | 2 | 4 | 2 | 暂缺 | 4
Windows NT 4.0 Workstation | 暂缺 | 暂缺 | 2 | 2 | 2 | 暂缺 | 2
Microsoft Windows 98 | 暂缺 | 暂缺 | 1 | 使用 Desktop Engine | 1 | 暂缺 | 暂缺
Microsoft Windows CE | 暂缺 | 暂缺 | 暂缺 | 暂缺 | 暂缺 | 1 | 暂缺

SQL Server 2000 版本支持的最大物理内存量

下表列出各 SQL Server 2000 版中的数据引擎能够支持的最大物理内存量或 RAM。

操作系统 | 企业版 | 标准版 | 个人版 | 开发版 | Desktop Engine | SQL Server CE | 企业评估版
Windows 2000 DataCenter | 64 GB | 2 GB | 2 GB | 64 GB | 2 GB | 暂缺 | 64 GB
Windows 2000 Advanced Server | 8 GB | 2 GB | 2 GB | 8 GB | 2 GB | 暂缺 | 8 GB
Windows 2000 Server | 4 GB | 2 GB | 2 GB | 4 GB | 2 GB | 暂缺 | 4 GB
Windows 2000 Professional | 暂缺 | 暂缺 | 2 GB | 2 GB | 2 GB | 暂缺 | 2 GB
Windows NT 4.0 Server 企业版 | 3 GB | 2 GB | 2 GB | 3 GB | 2 GB | 暂缺 | 3 GB
Windows NT 4.0 Server | 2 GB | 2 GB | 2 GB | 2 GB | 2 GB | 暂缺 | 2 GB
Windows NT 4.0 Workstation | 暂缺 | 暂缺 | 2 GB | 2 GB | 2 GB | 暂缺 | 2 GB


配置选项说明

Microsoft® SQL Server™ 2000 包含控制计算机资源的改进算法。许多在 SQL Server 早期版本中必须手工配置的选项在 SQL Server 2000 中可以进行动态管理。这些配置选项不适用于 SQL Server 7.0，在下表中标记为"暂缺"。

在 SQL Server 2000 中，有些配置选项仍需指定；但这些选项并不指定静态分配的大小，而只是指定根据需要动态分配的对象数量的上限。这些选项在表中用星号 (*) 标示。下表中的信息不适用于 Microsoft® SQL Server 2000™ Windows® CE 版。

 | SQL Server 7.0 版 |  | SQL Server 2000
配置值 | 最小 | 最大 | 最小 | 最大
affinity mask | 0 | 2,147,483,647 | 0 | 2,147,483,647
allow updates | 0 | 1 | 0 | 1
AWE enabled | 暂缺 | 暂缺 | 0 | 1
c2 audit mode | 暂缺 | 暂缺 | 0 | 1
cost threshold for parallelism | 0 | 32,767 | 0 | 32,767
cursor threshold | -1 | 2,147,483,647 | -1 | 2,147,483,647
default full-text language | 暂缺 | 暂缺 | 0 | 2,147,483,647
default language | 0 | 9,999 | 0 | 9,999
default sort order id | 0 | 255 | 暂缺 | 暂缺
extended memory size (MB) | 0 | 2,147,483,647 | 暂缺 | 暂缺
fill factor (%) | 0 | 100 | 0 | 100
index create memory (K) | 704 | 1,600,000 | 704 | 2,147,483,647
language in cache | 3 | 100 | 暂缺 | 暂缺
language neutral full-text indexing | 0 | 1 | 暂缺 | 暂缺
lightweight pooling | 0 | 1 | 0 | 1
locks | 5,000* | 2,147,483,647* | 5,000* | 2,147,483,647*
max async IO | 1 | 255 | 暂缺 | 暂缺
max degree of parallelism | 0 | 32 | 0 | 32
max server memory (MB) | 4* | 2,147,483,647* | 4* | 2,147,483,647*
max text repl size | 0 | 2,147,483,647 | 0 | 2,147,483,647
max worker threads | 10 | 1,024 | 10 | 32,767
media retention | 0 | 365 | 0 | 365
min memory per query (K) | 512 | 2,147,483,647 | 512 | 2,147,483,647
min server memory (MB) | 0* | 2,147,483,647* | 0* | 2,147,483,647*
nested triggers (bytes) | 0 | 1 | 0 | 1
network packet size | 512 | 65,535 | 512 | 65,532
open objects | 0* | 2,147,483,647* | 0* | 2,147,483,647*
priority boost | 0 | 1 | 0 | 1
query governor cost limit | 0 | 2,147,483,647 | 0 | 2,147,483,647
query wait (sec) | -1 | 2,147,483,647 | -1 | 2,147,483,647
recovery interval (min) | 0 | 32,767 | 0 | 32,767
remote access | 0 | 1 | 0 | 1
remote login timeout (sec) | 0 | 2,147,483,647 | 0 | 2,147,483,647
remote proc trans | 0 | 1 | 0 | 1
remote query timeout (sec) | 0 | 2,147,483,647 | 0 | 2,147,483,647
resource timeout | 5 | 2,147,483,647 | 暂缺 | 暂缺
scan for startup procs | 0 | 1 | 0 | 1
set working set size | 0 | 1 | 0 | 1
show advanced options | 0 | 1 | 0 | 1
spin counter | 1 | 2,147,483,647 | 暂缺 | 暂缺
time slice | 50 | 1,000 | 暂缺 | 暂缺
two digit year cutoff | 1,752 | 9,999 | 1,752 | 9,999
unicode comparison style | 0 | 2,147,483,647 | 暂缺 | 暂缺
unicode locale id | 0 | 2,147,483,647 | 暂缺 | 暂缺
user connections | 0* | 32,767（服务器）* 1 | 0* | 32,767（实例）* 1
user options | 0 | 4,095 | 0 | 16,383

* 动态分配对象的上限或下限。
1 当并发执行 5 个以上的批处理时，SQL Server 2000 个人版和 SQL Server 2000 Desktop Engine 中的并发工作负荷调控器将限制性能。


SQL Server 对象内存使用情况说明

下表列出 Microsoft® SQL Server™ 中不同对象的内存使用量。下表中的信息不适用于 Microsoft® SQL Server 2000™ Windows® CE 版。

 | 对象大小
对象 | SQL Server 7.0 | SQL Server 2000
锁 | 96 字节 | 每个所有者 64 字节外加 32 字节。
开放式数据库 | 2.880 字节 | 每个文件 3924 字节外加 1640 字节，每个文件组 336 字节。
开放式对象1 | 276 字节 | 每个对象上打开的索引 256 字节外加 1724 字节2。
用户联接 | 12 KB +（3 * 网络数据包大小）3。 | 12 KB +（3 * 网络数据包大小）3。

3 开放式对象包括所有的表、视图、存储过程、扩展存储过程、触发器、规则、默认值及约束。
2 在表或视图上可以打开索引。
3 网络数据包大小是表格格式数据方案 (TDS) 数据包的大小，该数据包用于应用程序和关系数据库引擎之间的通讯。默认的数据包大小为 4 KB，由 network packet size 配置选项控制。


Active Directory 集成

®®™Microsoft® Windows® 2000 Active Directory™ 作为存储有关在 Windows 2000 网络上可用的用户、设备和服务信息的安全的中央资源进行运转。 ™Microsoft SQL Server™ 2000 支持在 Active Directory 中注册 SQL Server 关系引擎实例、数据库、复制发布和分析服务。 SQL Server 工具还提供一个对话框支持浏览在 Active Directory 中注册的复制发布。

Active Directory 层次结构中的 SQL Server 对象

Active Directory 使用层次结构表示用户、服务和设备（如计算机、扫描仪或打印机）等网络实体之间的关系。 层次结构从顶部的单个根节点开始，向下分支到表示网络中单个实体的叶节点。 层次结构中的中间级节点是包含对多个实体的引用的容器。 例如，为了管理目的，可将几个 Windows 用户集中到一个组中。 每个节点作为代表该节点的特定实体的 Active Directory 对象执行。

在 Active Directory 中注册 SQL Server 关系数据库引擎实例时，MS-SQL-SQLServer 对象作为服务连接点 (SCP) 对象添加到运行该实例的计算机的容器中。 SCP 是 Active Directory 对象的类型，表示在网络上可用的服务。 SCP 对象记录有关服务的信息，如连接信息。 分析服务器也注册为运行分析服务器的计算机的 SCP。

在 Active Directory 中注册 SQL Server 关系数据库引擎实例后,还可注册驻留在该实例中的复制发布。 将发布作为该实例的子代进行注册。 在 Active Directory 中注册发布后，创建请求订阅向导支持使用户得以搜索 Active Directory 中注册的发布的对话框。 有关更多信息，请参阅 Active Directory 服务。

在 Active Directory 中注册关系数据库引擎实例后，还可注册该实例中的任何数据库。 在 SQL Server 企业管理器中右击数据库并选择“属性”。 在“选项”选项卡的底部有一个复选框，可控制是否在 Active Directory 中注册该数据库。 选中该复选框后，在关闭“属性”对话框时便在 Active Directory 中注册该数据库。 在选定该复选框后，如果再打开“属性”对话框时，该复选框是选定的并在单击“确定”以关闭该对话框时保留其为选中状态，则每次关闭“属性”对话框时都将刷新 Active Directory 中的数据库对象。 还可使用 sp_ActiveDirectory_Obj 存储过程从 Transact-SQL 脚本或应用程序注册数据库。

可在 Active Directory 中注册分析服务器。 有关更多信息，请参阅使用带有 Analysis Service 的Active Directory。 SQL Server 2000 工具不提供任何用于浏览 Active Directory 以查找关系数据库引擎实例、分析服务器或关系数据库的设备。 可将应用程序进行编码以为用于注册这些 SQL Server 实体的对象浏览 Active Directory。

在 Windows 2000 Active Directory 架构中定义 SQL Server 2000 支持的 Active Directory 类对象：

Active Directory 对象名 | SQL Server 实体
MS-SQL-SQLServer | SQL Server 实例
MS-SQL-SQLPublication | 在 SQL Server 实例中复制发布定义的对象。
MS-SQL-SQLDatabase | SQL Server 实例中的数据库。
MS-SQL-OLAPServer | SQL Server 分析服务器的实例。

SQL Server 2000 对这些对象的定义不进行扩展；SQL Server 使用在 Windows 2000 Active Directory 架构中定义的对象。 ®http://www.microsoft.com/isapi/redir.dll?Prd=msdn&Ar=msdn&O1=redMicrosoft Web site还可对 Active Directory 服务 Interfaces (ADSI) 应用程序进行编码，该应用程序为注册的 SQL Server 实例、分析服务器、发布和数据库浏览 Active Directory。有关 ADSI 和 Active Directory 架构对象结构的更多信息，请访问http://www.microsoft.com/isapi/redir.dll?Prd=msdn&Ar=msdn&O1=redMicrosoft Web 站点e的 MSDN® Library。

SQL Server 2000 不使用在 Windows 2000 Active Directory 架构中定义的 MS-SQL-OLAPCube、MS-SQL-OLAPDatabase 或 MS-SQL-SQLRepository 类对象。

MSSQLServerADHelper Service_mssqlserveradhelper_service

sp_ActiveDirectory_SCP_sp_activedirectory_scp


MSSQLServerADHelper 服务

MSSQLServerADHelper 服务执行两项功能：

  • ®™®™在 Microsoft Windows® 2000 Active Directory™ 中添加和删除用于注册 Microsoft® SQL Server™ 2000 关系数据库引擎或分析服务器的对象。

  • 确保运行 SQL Server 服务的 Windows 帐户有权更新该实例的所有 Active Directory 对象以及该实例的复制发布和数据库。

该服务在必要时由 SQL Server 实例或 Analysis Manager 动态启动。 该服务完成工作后立即停止运行。

计算机容器中的 Active Directory 对象只能由特定的程序创建或删除，即已为其指派了域管理权限或是在 localsystem Windows 帐户下运行的程序。 很少有站点在这两类帐户下运行它们的 SQL Server 服务。 象 SQL Server 这样不执行网络管理任务的服务应用程序很少被授予完整的域管理权限。 不能为 localsystem 帐户授予远程计算机上的任何权限，因此，在该帐户下运行 SQL Server 会使许多 SQL Server 分布式功能无法发挥作用。 MSSQLServerADHelper 服务运行在 localsystem 帐户下，以便可以在 Active Directory 中添加和删除用于注册 SQL Server 实体的对象。

计算机上只有一个 MSSQLServerADHelper 服务。 就是这一个服务处理着所有 SQL Server 关系数据库引擎实例和计算机上运行的所有 Analysis Manager 应用程序的 Active Directory 对象。

注册 SQL Server 分析服务器

分析服务通过 Microsoft 管理控制台 (MMC) 应用程序 Analysis Manager 注册。 当 Analysis Manager 的用户请求在 Active Directory 中注册分析服务器时，该应用程序动态启动 MSSQLServerADHelper 服务并请求在 Active Directory 中创建 MS-SQL-OLAPServer 对象。 此帮助服务程序在完成了对象的创建后即停止运行，随后由 Analysis Manager 完成为对象填写信息的工作。 有关更多信息，请参阅在 Analysis Services 中使用 Active Directory。

注册 SQL Server 关系组件

对注册 SQL Server 实例以及各实例中的数据库和复制发布的管理工作均由该 SQL Server 实例的系统存储过程完成。 当用户在用户界面中指定 Active Directory 操作时，SQL Server 企业管理器调用系统存储过程。 所使用的存储过程包括：

  • sp_ActiveDirectory_SCP。 管理关系数据库引擎实例的注册。

  • sp_addpublication、sp_addmergepublication、sp_changepublication 或 sp_changemergepublication。 管理复制发布的注册。

  • sp_ActiveDirectory_Obj。 管理数据库的注册。

上述每个系统存储过程在内部调用一个内部组件，以使用 Active Directory 服务接口 (ADSI) 管理对象。 当必须在 Active Directory 中添加或删除 MS-SQL-SQLServer 对象或为其授权时，SQL Server ADSI 组件调用 MSSQLServerADHelper 服务执行任务。 SQL Server 服务在必要时使用 SQL Server ADSI 组件动态启动 MSSQLServerADHelper 服务。

SQL Server 服务在下列情况下动态调用 MSSQLServerADHelper 服务：

  • 当必须在 Active Directory 中创建用于注册 SQL Server 实例的 MS-SQL-SQLServer 对象时，SQL Server 服务调用 MSSQLServerADHelper 创建该对象。 MSSQLServerADHelper 创建该对象并为运行 SQL Server 服务的 Windows 帐户授予更新权限，然后 MSSQLServerADHelper 停止运行。 SQL Server 服务现在便具有了维护对象所需的权限，除非该对象被删除。 这些权限包括将 MS-SQL-SQLPublication 和 MS-SQL-SQLDatabase 对象创建为 MS-SQL-SQLServer 对象的子对象的权限。

  • 如果管理员更改了运行 SQL Server 服务的 Windows 帐户，当 SQL Server 服务下次尝试更新在帐户更改前已存在于 Active Directory 中的对象的任何信息时，会检测到这个更改。 SQL Server 服务自动启动 MSSQLServerADHelper。 该服务为新的 Windows 帐户重新指派对与当前的 SQL Server 实例相关的所有对象的更新权限。

  • 当有用户请求删除 MS-SQL-SQLServer 对象时，SQL Server ADSI 组件调用 MSSQLServerADHelper 服务删除该对象以及仍存在的任何子对象。

SQL Server 服务必须在有权启动 MSSQLServerADHelper 服务的 Windows 帐户下运行。 默认情况下，本地权限高的用户和本地管理员组的成员具有此权限。