SQL Server 管理概述

Microsoft® SQL Server™ 2000 管理应用程序及其随附的服务旨在协助系统管理员完成所有与维护和监视服务器性能和活动有关的管理任务。

主题 | 描述
启动、暂停和停止 SQL Server | 解释如何启动 SQL Server 实例，以及登录前后和登录过程中需要执行的操作。
故障转移群集 | 描述如何设置和使用故障转移群集。
导入和导出数据 | 描述如何从外部源检索数据并将数据传送到其它应用程序。
备份和还原数据库 | 针对各种潜在的系统问题，说明保护和恢复数据的方法。
使用复制数据库向导 | 描述如何在服务器之间复制或移动数据库，以及如何将数据库从 SQL Server 7.0 版升级到 SQL Server 2000。
管理服务器 | 描述如何注册和配置远程及链接服务器，如何添加或删除服务器以及如何修改服务器设置。
管理客户端 | 描述如何配置客户端与服务器组件的连接，以及如何更改默认网络协议以符合站点的需要。
自动化管理任务 | 说明如何建立定期发生的管理责任、如何定义作业和警报以及如何运行 SQL Server 代理。
安全管理 | 说明如何通过限制权限来保护数据库，使得只有经过授权的用户才可以访问它。
监视服务器性能和活动 | 说明如何开发一个策略以保证服务器和活动性能的水平可以接受。
使用 Web 助手向导 | 解释如何使用该向导创建 Web 页。


启动、暂停和停止 SQL Server

登录到 Microsoft® SQL Server® 实例前，需要知道如何启动、暂停和停止 SQL Server 实例。登录成功之后，便可执行各种任务，如管理服务器或查询数据库。

使用 SQL Server 服务

启动 SQL Server 实例时即启动了 SQL Server 服务。启动 SQL Server 服务之后，用户便可与服务器建立新连接。SQL Server 服务可在本地或远程作为 Microsoft Windows NT® 4.0 或 Windows® 2000 服务启动和停止。SQL Server 服务若是默认实例，则被称为 MSSQLServer；若是命名实例，则被称为 MSSQL$instancename。

使用 SQL Server 服务管理器

如果运行的是 Microsoft Windows 98，则 SQL Server 服务管理器可用于启动、暂停、停止和检查本地服务的状态，但不能远程管理服务。

如果必须重新启动计算机，SQL Server 服务管理器将自动出现并显示默认服务。可通过 SQL Server 服务管理器更改本地计算机上的默认服务。当重新启动计算机时，默认服务即显示在 SQL Server 服务管理器中。例如，如果将默认服务更改为 SQL Server 代理服务，然后关闭计算机，则下次启动时 SQL Server 代理服务将显示在 SQL Server 服务管理器中。

SQL Server 服务管理器也可用于启动、暂停或停止 SQL Server 2000 Analysis Services 的实例。

更改默认服务

服务管理器

服务管理器

使用 SQLServerAgent 服务

SQLServerAgent 是 Windows NT 4.0 或 Windows 2000 服务，用于执行作业、监视 SQL Server 以及激发警报。SQLServerAgent 是允许您自动执行某些管理任务的服务。所以必须启动 SQLServerAgent 服务，才能使本地或多服务器的管理任务自动运行。SQL Server 代理程序若是默认实例，则以名为 SQLServerAgent 的服务运行；若是命名实例则以名为 SQLAgent$instancename 的服务运行。

如果没有将 SQL Server 服务和 SQL Server 代理服务配置为自动启动，则必须手工启动它们。

设置轮询间隔

SQL Server 企业管理器和 SQL Server 服务管理器定期监视各种 SQL Server 组件的服务状态。它们都允许更改监视的间隔。

SQL Server 企业管理器

可以设置 SQL Server 企业管理器检查 SQL Server、SQL Server 代理程序、全文检索功能（作为 Microsoft 搜索服务运行）、SQL 邮件、复制监视器和 Microsoft 分布式事务处理协调器 (MS DTC) 状态的间隔，以确定它们是正在运行、已暂停还是已停止。通过 Microsoft 管理控制台 (MMC) 控制台树中的图标显示每种服务的状态。

SQL Server 服务管理器

可以设置 SQL Server 服务管理器检查 SQL Server、SQL Server 代理程序、全文检索功能和 MS DTC 状态的间隔，以确定它们是正在运行、已暂停还是已停止。通过单击 Windows 工具栏中的"SQL Server 服务管理器"图标可查看其状态。

设置轮询间隔

企业管理器

企业管理器

服务管理器

服务管理器

请参见

配置 SQLServerAgent 服务

注册服务器


启动 SQL Server

可以自动、手工或在命令提示符下启动 Microsoft® SQL Server™ 实例。自动方法和手工方法都将 SQL Server 实例作为 Microsoft Windows NT® 4.0 或 Windows® 2000 服务启动。如果在命令提示符下运行 sqlservr，则不能使用任何 net 命令将 SQL Server 实例作为 Windows NT 4.0 或 Windows 2000 服务暂停、停止或继续执行。

请参见

SQL Server 服务管理器

使用启动选项


自动启动 SQL Server

在安装过程中，可采用以下方法配置 Microsoft® SQL Server™ 自动启动：

  • 可配置在每次启动 Microsoft Windows NT® 4.0 或 Windows® 2000 操作系统时自动启动 SQL Server 实例。

  • 可配置运行 Microsoft Windows 98 的服务器自动启动。选择 SQL Server 服务管理器中的"当启动操作系统时自动启动服务"复选框。Windows 98 没有与 Window NT 4.0 和 Windows 2000 服务相对应的组件。SQL Server 数据库引擎和 SQL Server 代理程序在 Windows 98 上作为可执行程序运行。这些 SQL Server 组件无法作为服务自动启动。

    说明 SQL-DMO AutoStartServer 属性在 Windows 98 中无效。

  • 也可以使用"控制面板"中的"服务"应用程序。

安装完 SQL Server 后，可使用 SQL Server 企业管理器启用或禁用该服务器配置。有关更多信息，请参见 Windows NT 4.0 和 Windows 2000 文档。

自动启动 SQL Server 实例

企业管理器

企业管理器

SQL-DMO

关闭 SQL Server 的自动启动

企业管理器

企业管理器

SQL-DMO

请参见

使用启动选项


手工启动 SQL Server

可使用以下方法手工启动 Microsoft® SQL Server™ 实例。

方法 | 描述
SQL Server 企业管理器 | 在管理其它服务器和数据库的同一窗口内启动、暂停、继续执行和停止本地或远程 SQL Server 或 SQL Server 代理服务的实例。
SQL Server 服务管理器 | 启动、暂停、继续执行和停止本地或远程 SQL Server 或 SQL Server 代理服务的实例。
"控制面板"中的"服务"应用程序 | 启动、暂停、继续执行和停止本地服务器上的 SQL Server 或 SQL Server 代理服务的实例。
命令提示符 | 通过键入下列内容，在命令提示符下启动 SQL Server 或 SQL Server 代理服务的实例： net start mssqlserver、sqlservr 或 net start SQLServerAgent，或通过运行 SQLSERVR.EXE 来启动。如果引用的是 SQL Server 的命名实例，则必须指定 mssql$instancename 或 SQLAgent$instancename。

在选择启动方法前，应考虑下列问题：

  • 如果从命令提示符使用 sqlservr 启动 SQL Server 实例（独立于服务控制管理器）：
    • 所有的系统消息都将显示在用于启动 SQL Server 实例的窗口中。

    • 不能使用 SQL Server 企业管理器、SQL Server 服务管理器、"控制面板"中的"服务"应用程序或任何 net 命令（例如 net start、net pause、net stop 和 net continue），将 SQL Server 实例作为 Windows NT 4.0 或 Windows 2000 服务暂停、停止或继续执行。

    • 在注销 Windows NT 4.0 或 Windows 2000 前必须关闭 SQL Server 实例。
  • 如果在命令提示符下启动 SQL Server 实例：
    • 键入的任何命令提示选项都优先于由 SQL Server 安装程序写入 Windows 2000 注册表的默认命令提示选项。

    • SQL Server 服务管理器和 SQL Server 企业管理器将服务显示为已停止。
  • 可在不关闭 SQL Server 实例的情况下注销 Windows NT 4.0 或 Windows 2000 网络。

启动 SQL Server 的默认实例

企业管理器

企业管理器

服务管理器

服务管理器

命令提示符

命令提示符

SQL-DMO

启动 SQL Server 的命名实例

命令提示符

命令提示符

启动 SQL Server 的群集实例

服务管理器

服务管理器

请参见

使用启动选项


在单用户模式下启动 SQL Server

在某些情况下，可能需要使用启动选项 –m 以单用户模式启动 Microsoft® SQL Server™ 实例。例如，可能要更改服务器配置选项或恢复已损坏的 master 数据库或其它系统数据库。这些操作都需要在单用户模式下启动 SQL Server 实例。

当在单用户模式下启动 SQL Server 实例时：

  • 只有一个用户可以连接到服务器。

  • 不执行 CHECKPOINT 进程。默认情况下，在启动时自动执行该进程。

  • sp_configure 系统存储过程的 allow updates 选项处于启用状态。默认情况下，allow updates 选项被禁用。

在单用户模式下启动 SQL Server

命令提示符

命令提示符

请参见

allow updates 选项

CHECKPOINT

sp_configure

使用启动选项


以最低配置启动 SQL Server

如果存在防碍服务器启动的配置问题，可使用最低配置启动选项启动 Microsoft® SQL Server™ 实例。这便是启动选项 -f。以最低配置启动 SQL Server 实例将自动使服务器处于单用户模式。

当以最低配置模式启动 SQL Server 实例时：

  • 只有一个用户可以连接到服务器，并且不执行 CHECKPOINT 进程。

  • 禁用远程访问和预读功能。

  • 启动存储过程不运行。

  • sp_configure 存储过程的 allow updates 选项处于启用状态。默认情况下，allow updates 选项被禁用。

以最低配置启动服务器后，应适当更改服务器选项的值，然后停止并重新启动服务器。

重要 在以最低配置模式连接到 SQL Server 实例前应停止 SQL Server 代理服务。否则 SQL Server 代理服务将使用连接并使其阻塞。

以最低配置启动 SQL Server

命令提示符

命令提示符

请参见

设置配置选项

sp_configure

使用启动选项


使用启动选项

当安装 Microsoft® SQL Server™ 时，SQL Server 安装程序在 Microsoft Windows® 2000 注册表中写入一组默认启动选项。可以使用这些启动选项指定备用的 master 数据库文件、master 数据库日志文件或错误日志文件。

默认启动选项 | 描述
-d master_file_path | master 数据库文件的完全合法路径（通常是 C:\Program Files\Microsoft SQL Server\MSSQL\Data\Master.mdf）。如果没有提供此选项，则使用现有的注册表参数。
-e error_log_path | 错误日志文件的完全合法路径（通常是 C:\Program Files\Microsoft SQL Server\MSSQL\Log\Errorlog）。如果没有提供此选项，则使用现有的注册表参数。
-l master_log_path | master 数据库日志文件的完全合法路径（通常是 C:\Program Files\Microsoft SQL Server\MSSQL\Data\Mastlog.ldf）。

使用以下附加启动选项，可以临时替代默认启动选项并启动 SQL Server 实例。

其它启动选项 | 描述
-c | 独立于服务控制管理器来启动 SQL Server 实例，从而缩短了启动时间，并使 SQL Server 不作为 Microsoft Windows NT® 4.0 或 Windows 2000 服务运行。
-f | 以最低配置启动 SQL Server 实例。该选项在配置值的设置（如过度提交内存）防碍了服务器启动时很有用。将启用 sp_configure allow updates 选项。默认情况下，allow updates 选项被禁用。
-g 以兆字节为单位指定虚拟地址空间大小，SQL Server 将为 SQL Server 进程内的内存分配保留这一部分地址空间，但将其置于 SQL Server 内存池之外。这一区域由 SQL Server 用来装载诸如扩展过程 .dll 文件、分布式查询所引用的 OLE DB 提供程序、Transact-SQL 语句中所引用的自动化对象等项目。默认值是 128 MB。

使用该选项有助于调节内存分配，但仅当 SQL Server 2000 个人版或 SQL Server 2000 标准版的物理内存大于 2 GB 或 SQL Server 2000 企业版的物理内存大于 3 GB 时才适用。对于物理内存少于上述值的配置，即使使用该选项也不会有什么帮助。如果 SQL Server 的内存使用要求反常，并且 SQL Server 进程的虚拟地址空间全都在使用，那么在这样的大内存配置中适合使用该选项。不正确地使用该选项可能导致 SQL Server 实例无法启动或遇到运行时错误。

除非在 SQL Server 错误日志中看到下面的警告信息，否则应使用 –g 参数的默认值：

警告：Clearing procedure cache to free contiguous memory

此信息表明 SQL Server 正试图释放 SQL Server 内存池的部分空间，以便为扩展存储过程 .dll 文件或自动化对象等项目寻找空间。在这种情况下，可以考虑增加由 -g 开关保留的内存量。使用低于默认值的值可以增加缓冲池和线程栈中的可用内存量；在不使用很多扩展存储过程、分布式查询或自动化对象的系统中，这种方法可为需要大量内存的工作负荷带来性能方面的好处。
-m | 在单用户模式下启动 SQL Server 实例。当在单用户模式下启动 SQL Server 实例时，只有一个用户可进行连接，并且不启动 CHECKPOINT 进程。CHECKPOINT 保证将已完成的事务定期从磁盘高速缓存写入数据库设备。（一般在遇到需要修复系统数据库这样的问题时使用该选项。）将启用 sp_configure allow updates 选项。默认情况下，allow updates 选项被禁用。
-n | 不使用 Windows 应用程序日志记录 SQL Server 事件。如果用 -n 启动 SQL Server 实例，建议同时使用 -e 启动选项；否则将不会记录 SQL Server 事件。
-s | 允许启动 SQL Server 2000 命名实例。如果没有设置 -s 参数，将尝试启动默认实例。启动 sqlservr.exe 之前，必须在命令提示符下切换到实例的适当 BINN 目录。例如，如果 Instance1 在 \mssql$Instance1 下保存二进制文件，用户就必须在 \mssql$Instance1\binn 目录中启动 sqlservr.exe-sinstance1。
/T trace# | 表示应使用指定的有效跟踪标记 (trace#) 来启动 SQL Server 实例。跟踪标记用于以非标准行为启动服务器。
x | 不保留 CPU 时间和高速缓存命中率统计信息。可获得最大性能。

重要 用 /T 选项指定跟踪标记时，使用大写字母"T"传递跟踪标记号。SQL Server 可以接受小写字母"t"，但这将设置其它内部跟踪标记，而这些标记只有 SQL Server 技术支持工程师才需要。（不读取"控制面板"启动窗口中所指定的参数。）

请参见

CHECKPOINT


登录到 SQL Server

可使用任何图形管理工具或从命令提示符处登录到 Microsoft® SQL Server™ 实例。

当使用诸如 SQL Server 企业管理器或 SQL Server 查询分析器这类图形管理工具登录到 SQL Server 实例时，如有必要将提示您提供服务器名、登录 ID 和密码。登录到 SQL Server 实例的方式取决于 SQL Server 使用的是 Windows 身份验证还是混合模式（SQL Server 身份验证和 Windows 身份验证）。如果 SQL Server 使用的是 Windows 身份验证，每次访问注册的 SQL Server 时不用提供登录 ID。SQL Server 将使用 Microsoft Windows NT® 4.0 或 Windows® 2000 帐户自动登录。

说明 如果在安装 SQL Server 时选择了区分大小写的排序次序，那么登录 ID 也区分大小写。

登录到 SQL Server

命令提示符

命令提示符

请参见

身份验证模式

管理安全帐户

管理服务器

osql 实用工具

sp_password


运行 SQL Server

Microsoft® SQL Server™ 可以在网络上运行，也可以不在网络上运行。

在网络上运行 SQL Server

为了使 SQL Server 能在网络上通讯，SQL Server 服务必须处于运行状态。默认情况下，Microsoft Windows NT® 4.0 和 Windows® 2000 自动启动内置的 SQL Server 服务。若要了解 SQL Server 服务是否已启动，请在命令提示符下键入：

net start

如果 SQL Server 服务已经启动，在 net start 输出中将出现下列消息：

C:\> net start
These Windows NT services are started:

   ClipBook Server
   Computer Browser
   EventLog
   Messenger
   Network DDE
   Network DDE DSDM
   Server
   Workstation

The command completed successfully.

如果 SQL Server 服务没有启动，请在命令提示符下键入：

net start server

下列消息表示服务已启动：

The Server service was started successfully.

也可以使用"控制面板"中的"服务"应用程序查看服务状态以及启动和停止服务。有关更多信息，请参见 Windows NT 4.0 和 Windows 2000 文档。

不在网络上运行 SQL Server

当不在网络上运行 SQL Server 实例时，不需要启动内置的 SQL Server 服务。由于 SQL Server 企业管理器、SQL Server 服务管理器、net start 和 net stop 命令即使不在网络上运行也有效，因此无论是网络操作还是独立操作，启动和停止 SQL Server 实例的过程都是一样的。

当从本地客户端（如 osql）连接到独立的 SQL Server 实例时，将不使用网络而使用本地管道直接连接到该 SQL Server 实例。本地管道和网络管道的区别在于是否使用网络。除非另外指明，本地管道和网络管道都使用标准管道 (\pipe\sql\query) 与 SQL Server 实例建立连接。

如果在连接到本地 SQL Server 实例时不指定服务器名，所使用的就是本地管道。如果在连接到本地 SQL Server 实例时显式指定了服务器名，所使用的就是网络管道或另一种网络进程间通讯 (IPC) 机制，如互连网络数据包交换/有序数据包交换 (IPX/SPX)（假定已将 SQL Server 配置成使用多种网络）。由于独立的 SQL Server 不支持网络管道，当从客户端连接到该 SQL Server 实例时，必须省略不必要的 /S server_name 参数。例如，若要从 osql 连接到独立的 SQL Server 实例，请键入：

osql /Usa /P

请参见

命名管道客户端


暂停和继续运行 SQL Server

当暂停 Microsoft® SQL Server™ 实例时，已连接到服务器的用户可完成任务，但不允许有新的连接。例如，可以暂停 SQL Server 实例几分钟，并在关闭前给已连接的用户发送一条关闭消息。也可以继续执行 SQL Server 服务。

可在停止服务器之前暂停 SQL Server 实例。暂停 SQL Server 实例可防止新用户登录，并可留出一些时间向当前用户发送消息，要求他们在停止服务器之前注销。

说明 如果 SQL Server 实例是通过运行 sqlservr 启动的，则不能暂停 SQL Server 实例。只能暂停作为 Microsoft Windows NT® 4.0 或 Windows® 2000 服务启动的 SQL Server 服务。

有关从"控制面板"中的"服务"应用程序暂停和继续运行 SQL Server 实例的更多信息，请参见 Windows NT 4.0 或 Windows 2000 文档。

暂停和继续运行 SQL Server

服务管理器

服务管理器

命令提示符


停止 SQL Server

可从本地服务器或从远程客户端或另一台服务器停止 Microsoft® SQL Server™ 实例。如果没有暂停 SQL Server 实例便停止服务器，所有服务器进程将立即终止。停止 SQL Server 实例可防止新连接并与当前用户断开连接。

下表描述可用于停止 SQL Server 实例的方法。

方法 | 描述
SQL Server 企业管理器 | 停止 SQL Server 或 SQL Server 代理服务的本地或远程实例。
SQL Server 服务管理器 | 从单个窗口或从 Windows® 任务栏停止 SQL Server 或 SQL Server 代理服务的本地或远程实例。
SHUTDOWN 语句 | 在 osql 或其它查询工具中执行时停止 SQL Server 实例。使用 WITH NOWAIT 选项可立即停止 SQL Server 实例。
net stop mssqlserver | 如果运行的是 Microsoft Windows NT® 4.0 或 Windows® 2000 操作系统，将停止 SQL Server 的本地或远程实例。若要停止 SQL Server 2000 的命名实例，必须在命令提示符下输入 net stop mssql$instancename。
控制面板 | 使用"控制面板"中的"服务"应用程序停止 SQL Server 实例。
CTRL+C 键 | 如果 SQL Server 实例是在命令提示符下作为程序启动的，则停止该 SQL Server 实例。

停止 SQL Server 实例时，服务器在关闭前执行下列服务：

  • 禁止登录（系统管理员除外）。

  • 在每个数据库中执行 CHECKPOINT。但是，如果在命令提示符下使用 CTRL+C 停止 SQL Server 实例，则不会在每个数据库中执行 CHECKPOINT。因此，下次启动服务器时将需要更长的恢复时间。

  • 等待当前正在执行的所有 Transact-SQL 语句或存储过程执行完毕。

说明 如果要立即停止系统，可以从 osql 实用工具发出 SHUTDOWN WITH NOWAIT 语句。

停止 SQL Server

企业管理器

企业管理器

命令提示符

命令提示符

Transact-SQL

SQL-DMO

停止 SQL Server 的群集实例

服务管理器


广播关闭消息

在停止 Microsoft® SQL Server™ 实例前，可广播一条消息以警告用户即将关闭。可以在该消息中指明 SQL Server 实例将在何时停止，以便用户能够完成他们的工作。

广播关闭消息

命令提示符

命令提示符

如果不能使用 SQL Server 企业管理器或 SQL Server 服务管理器，可以从 osql 或其它查询工具发出 SHUTDOWN 命令来停止 SQL Server 实例。

SHUTDOWN 语句将使重新启动 SQL Server 实例时的自动恢复时间减到最少。SHUTDOWN 语句按下列方式停止 SQL Server 实例：

  1. 禁止登录（系统管理员除外）。若要列出所有当前用户，请使用 sp_who 系统存储过程。有关更多信息，请参见 sp_who。

  2. 允许正在执行的 Transact-SQL 语句或存储过程执行完毕。若要列出所有活动的进程和锁，请使用 sp_who 和 sp_lock 系统存储过程。有关更多信息，请参见 sp_who 和 sp_lock。

  3. 在每个数据库中执行CHECKPOINT。

    说明 执行 SHUTDOWN WITH NOWAIT 语句可立即停止服务器。但是，服务器下次启动时将需要更长的恢复时间，因为没有对任何数据库执行 CHECKPOINT。

立即停止 SQL Server

Transact-SQL

请参见

sp_lock

sp_who

SQL Server 服务管理器


故障转移群集

在 Microsoft® SQL Server™ 2000 企业版中，SQL Server 2000 故障转移群集支持高度可用性。例如，在操作系统发生故障或执行计划的升级时，可配置故障转移群集以转移到故障转移群集配置中的任何其它节点。这样，可以将系统停机时间减到最少，从而提供高度的服务器可用性。

若要安装、配置和维护故障转移群集，请使用 SQL Server 安装程序。有关升级到 SQL Server 2000 故障转移群集的信息，请参见升级到 SQL Server 2000 故障转移群集。

使用故障转移群集进行以下操作：

  • 在故障转移群集内的多个节点上安装 SQL Server。此操作只受操作系统支持的节点数的限制。

在安装故障转移群集之前，必须安装 Microsoft Windows NT® 4.0 企业版、Microsoft Windows® 2000 Advanced Server 或 Windows 2000 Datacenter Server 以及 Microsoft 群集服务 (MSCS)。

使用故障转移群集必须遵从特定的安装步骤。有关更多信息，请参见安装故障转移群集和处理故障转移群集安装。

  • 为各虚拟服务器指定多个 IP 地址。

SOL Server 2000 允许使用所有可用的网络 IP 子网，以便在一个子网出现故障时可以通过另外的方法连接，并且提高了网络的可伸缩性。例如，如果使用单个网卡，当网络出现故障时会使通讯中断。但是，如果在服务器中有多个网卡，而每个网卡都可以在不同的 IP 子网上。即使一个子网出现故障，至少还有一个连接可以继续工作。如果一个路由器出现故障，而 MSCS 继续运行，则所有 IP 地址仍然有效。然而，如果本地计算机上的网卡出现故障，则通讯仍将中断。有关更多信息，请参见创建故障转移群集。

  • 从群集 SQL Server 配置的任何节点上管理故障转移群集。若要执行安装任务，必须从群集磁盘资源控制下的节点上进行安装。有关更多信息，请参见创建故障转移群集。

  • 允许一台虚拟服务器将故障转移到故障转移群集配置上的任何其它节点。有关更多信息，请参见创建故障转移群集。

  • 使用安装程序在故障转移群集配置中添加或删除节点。有关更多信息，请参见维护故障转移群集。

  • 在不影响其它节点的情况下，在故障转移群集内的任意节点上重新安装或重建虚拟服务器。有关更多信息，请参见维护故障转移群集。

  • 使用 Microsoft 搜索服务与故障转移群集执行全文查询。有关更多信息，请参见在故障转移群集中使用 SQL Server 工具。
支持多个实例

故障转移群集还支持多个实例。多实例支持使其更便于在故障转移群集环境中生成、安装和配置虚拟服务器。应用程序可以连接单个计算机上的每个实例，其方法与连接运行在不同计算机上的 SQL Server 实例基本相同。有关虚拟服务器的更多信息，请参见创建故障转移群集。

使用多实例支持可以隔离工作环境（例如，将测试同生产隔离）或易变的应用程序环境，并为同一台计算机中的各 SQL Server 实例设置不同的系统管理员。有关更多信息，请参见多个 SQL Server 实例。

请参见

故障转移群集构架


故障转移群集支持

在 Microsoft® SQL Server™ 2000 企业版中，SQL Server 2000 故障转移群集支持的节点数取决于所运行的操作系统：

  • Microsoft Windows NT® 4.0 企业版、Microsoft Windows® 2000 Advanced Server 和 Microsoft Windows 2000 Datacenter Server 支持双节点故障转移群集。

  • Windows 2000 Datacenter Server 最多支持四节点故障转移群集，包括主动/主动/主动/主动的故障转移群集配置。

故障转移群集支持以下工具、功能和组件：

  • Microsoft 搜索服务。有关更多信息，请参见在故障转移群集中使用 SQL Server 工具。

  • 多实例。有关更多信息，请参见故障转移群集。

  • SQL Server 企业管理器。有关更多信息，请参见在故障转移群集中使用 SQL Server 工具。

  • 服务控制管理器。有关更多信息，请参见在故障转移群集中使用 SQL Server 工具。

  • 复制。有关更多信息，请参见创建故障转移群集。

  • SQL 事件探查器。有关更多信息，请参见在故障转移群集中使用 SQL Server 工具。

  • SQL 查询分析器。有关更多信息，请参见在故障转移群集中使用 SQL Server 工具。

  • SQL 邮件。有关更多信息，请参见在故障转移群集中使用 SQL Server 工具。

故障转移群集不支持以下组件：

  • SQL Server 2000 Analysis Services

说明 SQL Server 6.5 版或 SQL Server 7.0 在故障转移群集配置下不支持 Microsoft 数据访问组件 (MDAC) 2.6。

在使用故障转移群集之前，请考虑下列事项：

  • 仅当运行 SQL Server 2000 实例时才应使用故障转移群集资源（包括 IP 地址和网络名称）。不应将这些资源用于其它目的，如文件共享。

  • 在故障转移群集配置中，SQL Server 2000 支持 Windows NT 4.0 企业版，但是要求 SQL Server 服务（SQL Server 和 SQL Server 代理程序）的服务帐户必须是群集内所有节点的本地管理员。

重要 SQL Server 2000 在故障转移群集中既支持命名管道，也支持 TCP/IP 上的 TCP/IP 套接字。尽管如此，仍强烈建议在群集配置中使用 TCP/IP 套接字。


创建故障转移群集

若要创建 Microsoft® SQL Server™ 2000 故障转移群集，必须创建并配置运行故障转移群集的虚拟服务器。在 SQL Server 安装过程中创建虚拟服务器。Microsoft Windows NT® 4.0 或 Microsoft Windows® 2000 不提供虚拟服务器。

若要创建故障转移群集，您必须是本地管理员，具有作为一项服务登录的权限，以及在故障转移群集内的所有计算机上作为操作系统的一部分进行操作的权限。

虚拟服务器的元素

虚拟服务器包含：

  • Microsoft 群集服务 (MSCS) 群集组中的一个或多个磁盘的组合。

    每个 MSCS 群集组最多可包含一台虚拟 SQL Server。

  • 每台虚拟服务器的网络名称。该网络名称是虚拟服务器的名称。

  • 用于连接到各虚拟服务器的一个或多个 IP 地址。

  • 一个 SQL Server 2000 实例，包括 SQL Server 资源、SQL Server 代理程序资源和全文资源。

    如果管理员在虚拟服务器内卸载 SQL Server 2000 实例，则虚拟服务器（包括所有 IP 地址和网络名称）也将从 MSCS 群集组中被删除。

故障转移群集可以在一台或多台实际的 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 服务器上运行，也可以在参与群集节点的 Windows NT 4.0 企业版服务器上运行。但是，SQL Server 虚拟服务器始终以单个 Windows 2000 Advanced Server、Windows 2000 Datacenter Server 或 Microsoft Windows NT 4.0 企业版服务器出现在网络上。

命名虚拟服务器

SQL Server 2000 依赖于故障转移群集中的唯一注册表键值和服务名称，使操作在故障转移后继续正确进行。因此，为 SQL Server 2000 实例（包括默认实例）提供的名称在故障转移群集内的所有节点中以及故障转移群集内的所有虚拟服务器中都必须是唯一的。例如，如果所有实例都将故障转移到单台服务器，实例的服务名称和注册表键值将发生冲突。如果 INST1 是虚拟服务器 VIRTSRV1 上的一个命名实例，则在故障转移群集内，无论是作为故障转移群集配置的一部分还是作为独立安装实例，命名实例 INST1 都不能位于任何节点上。

另外，必须使用 VIRTUAL_SERVER\Instance-name 字符串连接虚拟服务器上运行的 SQL Server 2000 群集实例。如果使用群集实例在任何特定时间内碰巧驻留的计算机名称，则无法访问 SQL Server 2000 实例。SQL Server 2000 不在本地服务器的 IP 地址上监听，而仅在设置 SQL Server 2000 虚拟服务器时创建的群集 IP 地址上监听。

使用注意事项

在创建故障转移群集之前，需考虑下列事项：

  • 如果正在使用 Windows 2000 Address Windowing Extensions (AWE) API 以利用大于 3GB 的内存，则应确保在 SQL Server 的一个实例上配置的最大可用内存在故障转移到另一个节点后仍然可用。也就是说，如果故障转移节点的物理内存比原节点少，则 SQL Server 实例可能启动失败，或者可能在内存比在原节点上少的情况下启动。因此，必须：
    • 为群集内的各服务器提供相同数量的物理 RAM。

    • 确保所有实例的 max server memory设置的总和值小于故障转移群集内任一虚拟服务器上的最小可用物理 RAM 量。

    有关 AWE 的更多信息，请参见使用 Windows 2000 上的 AWE 内存。

  • 若需要在复制中采用具有高可用性的服务器，建议在故障转移群集上配置分发服务器时将 MSCS 群集文件共享用作快照文件夹。一旦服务器出故障，分发数据库将可用，并且可在分发服务器上继续配置复制。

    此外，创建发布时，应为其它快照文件的存储指定 MSCS 群集文件共享或将其指定为订阅服务器应用快照的位置。这样，快照文件就可用于群集的所有节点和必须访问该群集的所有订阅服务器。有关更多信息，请参见发布服务器、分发服务器和订阅服务器和备用快照位置。

  • 如果想要在故障转移群集中使用加密，则必须在故障转移群集中所有节点上安装服务器证书，该证书应带有虚拟服务器的完全限定的 DNS 名称。例如，如果具有一个双节点的群集（节点名称分别为 test1.redmond.corp.microsoft.com 和 test2.redmond.corp.microsoft.com）和一个虚拟 SQL Server"Virtsql"，则需要获得"virtsql.redmond.corp.microsoft.com"的证书，并在两个节点上都安装该证书。然后可以选取该 Server 网络实用工具中的"强制协议加密"复选框，配置您的故障转移群集使用加密。

  • 不能从 SQL Server 删除 BUILTIN/管理员帐户。IsAlive 线程运行于群集服务帐户而不是 SQL Server 服务帐户的上下文中。群集服务必须是该群集每个节点上的管理员组的一部分。如果删除 BUILTIN/管理员帐户，则 IsAlive 线程将不再能够创建信任连接，而且您将失去对虚拟服务器的访问权限。
创建故障转移群集

下面是使用安装程序创建故障转移群集的基本步骤：

  1. 确定创建虚拟服务器所需的信息（例如，群集磁盘资源、IP 地址和网络名称）以及故障转移可用的节点。

    用于故障转移群集的群集磁盘应全部位于单个群集组内，并且由运行安装程序的节点所拥有。在运行安装程序之前必须先进行此配置。通过 Windows NT 4.0 或 Windows 2000 中的群集管理器进行此配置。对每个要安装的虚拟服务器都需要有一个 MSCS 组。

  2. 启动安装程序以开始安装。输入了所有必需的信息后，安装程序将新的 SQL Server 二进制文件实例安装在群集内每一台计算机的本地磁盘上，而将系统数据库安装在指定的群集磁盘上。二进制文件以完全相同的路径安装在每个群集节点上，因此必须确保每个节点与群集中所有其它节点共享一个本地驱动器号。

    在 SQL Server 2000 中，故障转移期间只有数据库进行故障转移。在 SQL Server 6.5 版和 SQL Server 7.0 版中，故障转移期间 SQL Server 数据库和二进制文件都进行故障转移。

    如果由于某种原因出现资源（包括 SQL Server）故障，则这些服务（SQL Server、SQL Server 代理程序、全文检索和故障转移群集组中的所有服务）将故障转移至虚拟服务器中定义的任何可用节点。

  3. 安装一个 SQL Server 2000 实例，以创建一个新的虚拟服务器和所有资源。

如何创建新的故障转移群集

SQL 安装程序

SQL 安装程序

如何安装单节点故障转移群集

SQL 安装程序

SQL 安装程序

升级到 SQL Server 2000 故障转移群集

若要从 SQL Server 6.5 或 SQL Server 7.0 故障转移群集升级到 SQL Server 2000 故障转移群集，必须先对以前的安装取消群集。SQL Server 6.5 或 SQL Server 7.0 群集不能与故障转移群集位于同一台计算机中。有关升级的更多信息，请参见升级到 SQL Server 2000 故障转移群集。

从 SQL Server 6.5 主动/被动故障转移群集升级

SQL 安装程序

SQL 安装程序

从 SQL Server 6.5 主动/主动故障转移群集升级

SQL 安装程序

SQL 安装程序

从 SQL Server 7.0 主动/主动故障转移群集升级

SQL 安装程序

SQL 安装程序

从 SQL Server 7.0 主动/被动故障转移群集升级

SQL 安装程序


故障转移群集示例

下例说明如何配置 Microsoft® SQL Server™ 2000 故障转移群集。

CLUSTERNODEA 和 CLUSTERNODEB 是故障转移群集中的两台计算机。在 CLUSTERNODEA 上运行 SQL Server 安装程序，并创建一台名为"SQLCLUSTA"的虚拟服务器。然后，安装 SQL Server 2000 的默认实例，该实例既可在 CLUSTERNODEA 上运行又可在 CLUSTERNODEB 上运行。接下来，通过在连接字符串中将"SQLCLUSTA"指定为服务器名称连接该服务器。

在 CLUSTERNODEB 上再次运行安装程序。创建名为"SQLCLUSTB"的新虚拟服务器（属于另一个 Microsoft 群集服务 (MSCS) 群集组），并安装一个名为"Inst1"的实例，该实例既可在 CLUSTERNODEA 上运行又可在 CLUSTERNODEB 上运行。接下来，通过将"SQLCLUSTB\Inst1"指定为连接字符串连接该服务器。

两台虚拟服务器即在由 CLUSTERNODEA 和 CLUSTERNODEB 组成的 MSCS 群集中运行。而另一方面，它们又是彼此完全独立的。每台虚拟服务器驻留在不同的 MSCS 群集组中，并且各自有一组不同的 IP 地址、唯一的网络名称和驻留在不同的共享群集磁盘集上的数据文件。

MSCS 群集组中任一资源发生故障转移，则该组成员的所有资源也发生故障转移。对于 SQLCLUSTA，一旦达到故障转移阈值，磁盘资源、IP 地址、网络名称或虚拟服务器内的 SQL Server 2000 安装所出现的任何故障，都将导致该群集组的所有成员发生故障转移。

下图显示一个含有二进制文件和数据的两个节点的群集。在下图中，各虚拟服务器必须对存放数据/日志文件的磁盘具有独占所有权。

请参见

故障转移群集构架


升级到 SQL Server 2000 故障转移群集

当升级到 Microsoft® SQL Server™ 2000 故障转移群集时，只允许有一个默认实例。在升级到 SQL Server 2000 之前，使用 SQL Server 6.5 版或 SQL Server 7.0 中的群集向导对任何现有 SQL Server 6.5 或 SQL Server 7.0 群集实例取消群集。然后，在 SQL Server 2000 上运行 SQL Server 安装程序。

SQL Server 6.5 或 SQL Server 7.0 故障转移群集不能与 SQL Server 2000 故障转移群集共存于同一台计算机中。对于 SQL Server 6.5 或 SQL Server 7.0，在主动/主动配置中或主动/被动配置中（该配置中有一台服务器包含非群集 SQL Server）存在名称冲突。两台服务器都是默认实例。

重要 如果已安装了 SQL Server 2000，则无法在 SQL Server 6.5 或 SQL Server 7.0 中运行群集向导。

对于 SQL Server 2000，必须使用这些服务（SQL Server、SQL Server 代理程序和群集组中的所有服务）的域帐户。如果计算机运行在 Microsoft Windows NT® Server 4.0 企业版上，则该帐户必须是群集内所有计算机上的管理员。

说明 如果正在 SQL Server 6.5 或 7.0 故障转移群集上使用复制并准备升级到 SQL Server 2000 故障转移群集，则必须对以前的安装取消群集。删除所有发布、删除复制，然后在升级后重新配置复制。在将来的版本中从 SQL Server 2000 升级将不必这样做。

从 SQL Server 6.5 主动/被动故障转移群集升级

SQL Setup

SQL 安装程序

从 SQL Server 6.5 主动/主动故障转移群集升级

SQL Setup

SQL 安装程序

从 SQL Server 7.0 主动/主动故障转移群集升级

SQL Setup

SQL 安装程序

从 SQL Server 7.0 主动/被动故障转移群集升级

SQL Setup


处理故障转移群集安装

安装 Microsoft® SQL Server™ 2000 故障转移群集时，必须：

  • 确保正确安装操作系统，且操作系统支持故障转移群集。有关安装故障转移群集前的准备工作的更多信息，请参见安装故障转移群集前的准备工作。有关安装顺序的更多信息，请参见安装故障转移群集。

  • 考虑故障转移群集是否支持想要使用的 SQL Server 工具、功能和组件。有关更多信息，请参见故障转移群集支持。

  • 考虑故障转移群集是否依赖于想要使用的产品。有关更多信息，请参见故障转移群集的相关性。

  • 考虑如何创建新的故障转移群集。有关创建新的故障转移群集配置的更多信息，请参见创建故障转移群集。

  • 查看从 SQL Server 6.5 版或 SQL Server 7.0 版群集升级到 SQL Server 2000 故障转移群集的指导说明。有关更多信息，请参见升级到 SQL Server 2000 故障转移群集。


安装故障转移群集前的准备工作

在安装 Microsoft® SQL Server™ 2000 故障转移群集之前，必须选择计算机运行的操作系统。可以使用 Microsoft Windows NT® 4.0 企业版、Microsoft Windows® 2000 Advanced Server 或 Microsoft Windows 2000 Datacenter Server。还必须安装 Microsoft 群集服务 (MSCS)。

预安装一览表

在开始安装过程之前，请验证：

  • 在网络接口卡 (NIC) 和驱动器/阵列 (SCSI) 控制器之间没有 IRQ 共享。尽管确有某些硬件支持此种共享，但不推荐使用。

  • 您的硬件列在 Windows NT 硬件兼容性列表中。

    有关所支持硬件的完整列表，请参见 Microsoft Web 站点 Hardware Compatibility（硬件兼容性）列表。

    硬件系统必须按群集分类显示。同时添加的个别群集组件不构成核准系统。只有作为群集解决方案购买的系统和列在群集组中的系统才是核准系统。当检查列表时，按分类指定群集。所有其它分类用于 OEM。

  • 同时在所有节点上运行 Windows NT 4.0 企业版或 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 之前，MSCS 已完全安装在至少一个节点上。

    当使用 MSCS 时，必须确定一个节点处于共享的 SCSI 总线的控制下，而该总线优先于联机的其它节点。没有这样做可能会导致应用程序故障转移进入联机挂起状态。结果是，群集或者在其它节点上失败，或者完全失败。然而，如果硬件制造商有专用的安装过程，则应遵从硬件制造商的说明。

  • WINS 是根据 Microsoft Web 站点 Product Support Services 中的以下文章安装的：

    Q258750 Recommended Private "Heartbeat" Configuration on Cluster Server（Q258750 推荐的群集服务器上的专用"心跳信号"配置）

  • 两台服务器上的可群集磁盘的磁盘驱动器号必须相同。

  • 在开始 SQL Server 安装程序之前，对所有专用网卡禁用 NetBIOS。

  • 已清除所有节点中的系统日志，并再次查看了系统日志。确保在继续操作之前，日志中没有任何错误信息。


安装故障转移群集

如果是在 Microsoft Windows NT® 4.0 企业版上安装 Microsoft® SQL Server™ 2000 故障转移群集，则必须按照下面指定的顺序安装程序。但是，如果是在 Microsoft Windows® 2000 Advanced Server 或 Windows 2000 Datacenter Server 上安装故障转移群集，则没有这个必要。

注意 如果未按照下列顺序安装程序，则软件产品会在安装时失败，并需要完全重新初始化磁盘并重新启动安装。

在故障转移群集配置下安装 SQL Server 2000 之前，必须升级 SQL Server 2000 的任何发布前版本。

在 Windows NT 4.0 上安装故障转移群集

  1. 安装 Windows NT 4.0 企业版。

    Windows NT 4.0 企业版包括 Windows NT 4.0 Service Pack 3。安装 Microsoft 群集服务 (MSCS) 时必须用到 Service Pack 3。

    • 如果打算安装 Windows NT Option Pack，请不要直接使用 Service Pack 4 或更高版本。

    • 不要安装 Microsoft Internet 信息服务器 (IIS)。

    重要 默认情况下安装 IIS。建议在安装 Windows NT 4.0 的过程中清除该选项。

  2. 安装 MSCS。

  3. 安装 Microsoft Internet Explorer 5.0 版或更高版本。

  4. 手动创建 Microsoft 分布式事务处理协调器 (MS DTC) 兼容资源组，MS DTC 安装可以在该组中创建自己的资源。资源组包含 IP 地址、网络名称和群集磁盘资源。任何包含这三项的组都与 MS DTC 兼容。

    SQL Server 安装程序将在后面的步骤中安装 MS DTC。仅当除 MS DTC 之外还需要 Windows NT 4.0 Option Pack 的组件时才安装 Windows NT 4.0 Option Pack。

  5. 安装最新的 Windows NT 4.0 Service Pack（Service Pack 5 或更高版本）。单击"创建卸载目录"，单击"2000 年安装程序"，然后选择"用于基于 Intel 的系统的 Service Pack 安装"复选框。

    不要选择 Microsoft 消息队列服务器 (MSMQ 1.0) 或 IIS。SQL Server 2000 上不支持 MSMQ 1.0。建议 IIS 功能与 Windows NT 负载平衡服务 (WLBS) 一起使用。有关 WLBS 的更多信息，请搜索 Microsoft Web 站点 NT Server 上的"WLBS Features Overview"。

    在进行步骤 5 之前，建议将隐藏目录 $NTServicePackUninstall$ 重命名为 $NTServicePackUninstall$.service packnumber。安装 service pack 后，添加新目录。这样就使卸载目录变为可用，以防止这些目录被意外重写。

  6. 安装 SQL Server 2000。

说明 在安装任何其它应用程序前安装所有附加服务器产品。

在 Windows 2000 上安装故障转移群集

  1. 安装 Windows 2000 并接受默认应用程序选项。

  2. 在第一个节点上安装 Windows 2000 后（但在安装 MSCS 前），选择"开始"菜单，指向"程序"子菜单，找到"管理工具"子菜单，然后单击"配置服务器"命令。

  3. 选择"高级"菜单，单击"群集服务"命令，然后从右窗格中单击"进一步了解"按钮。

  4. 从"帮助"菜单中，检查 Windows 群集中的项目 2。

    在 Windows 2000 安装过程中和 SQL Server 2000 故障转移群集中使用 Windows 群集。遵照以下说明来安装 MSCS。

    重要 需要阅读"规划 Windows 群集/服务器群集要求"中的章节，并按照名为一览表：创建服务器群集的服务器群集一览表执行。可在"服务器群集"章节/服务器群集一览表下找到。

  5. 在成功安装了 MSCS 以后，需要配置 MS DTC 以在群集中运行。

    有关 MS DTC 的更多信息，请参见故障转移群集的相关性。

  6. 在"开始"菜单中，指向"程序"子菜单，选择"管理工具"子菜单下的"群集管理器"命令，然后单击"视图组"菜单中的"群集组"命令。如果该组包含 MS DTC 资源，则继续执行步骤 9。否则，完成后面的两步。

  7. 在"开始"菜单上指向"命令提示符"。在命令提示符处输入 comclust.exe。

  8. 在群集的其余节点上重复步骤 7，一次一个节点。

  9. 安装 SQL Server 2000。

说明 在安装任何用户应用程序前安装所有附加服务器产品。


故障转移群集的相关性

有几种产品与 Microsoft® SQL Server™ 2000 故障转移群集交互。若要确保故障转移群集正常发挥作用，需要了解故障转移群集在其它产品上的基本相关性。

Microsoft 分布式事务处理协调器 (MS DTC)

SQL Server 2000 在群集中执行分布式查询、两阶段提交事务以及某些复制功能时，都需要 Microsoft 分布式事务处理协调器 (MS DTC)。安装 Microsoft Windows® 2000 并配置群集之后，必须在所有节点上运行群集向导（comclust.exe 程序）以配置 MS DTC 在群集模式下运行。

群集向导将对 MS DTC 配置进行如下更改：

  • 在包含共享群集磁盘资源和网络名称资源的资源组中创建 MS DTC 资源。

  • 在 MS DTC 资源组中包含的共享群集磁盘上创建 MS DTC 日志文件。将 MS DTC 日志文件放在共享群集磁盘上，将使 MS DTC 事务管理器可从群集中的任何系统访问 MS DTC 日志文件。

  • 向共享群集注册表复制关键的 MS DTC 注册表项。
在群集模式下运行 MS DTC

当 MS DTC 运行在群集模式时，每次群集中只有一个节点运行 MS DTC 事务管理器。

在群集中的任意节点上运行的任何进程都可以使用 MS DTC。这些进程只需调用 MS DTC 代理，而由 MS DTC 代理自动将 MS DTC 调用转发给控制整个群集的 MS DTC 事务管理器。

如果运行 MS DTC 事务管理器的节点失败，MS DTC 事务管理器会自动在该群集的另一个节点上重新启动。最后重新启动的 MS DTC 事务管理器读取共享群集磁盘上的 MS DTC 日志文件，以确定挂起的结果和最新完成的事务。资源管理器重新与 MS DTC 事务管理器连接，执行恢复操作以确定是否有不确定的事务结果。应用程序与 MS DTC 重新连接以便可以开始新的事务处理。

例如，假定 MS DTC 事务管理器在系统 B 中是活动的。系统 A 中的应用程序和资源管理器调用 MS DTC 代理。系统 A 中的 MS DTC 代理将所有 MS DTC 调用转发至系统 B 中的 MS DTC 事务管理器中。

如果系统 B 失败，则系统 A 中的 MS DTC 事务管理器将接管。它将读取共享群集磁盘上的整个 MS DTC 日志文件，执行恢复，并作为整个群集的事务管理器提供服务。

说明 作为 Windows 2000 安装程序的一部分，MS DTC 事务管理器、MS DTC 代理和组件服务管理工具安装在使用 MSCS 的 Windows 2000 群集中的各节点上。

在运行 MSCS 的 Windows 2000 系统中手工安装 MS DTC

  1. 在群集中的每个节点上安装 Windows 2000。

  2. 使用 Windows 2000 配置服务器工具来配置群集。

  3. 在群集中的每个节点上，从命令提示符运行 comclust.exe。可在 system32 目录中找到 Comclust.exe。

在 Windows 2000 群集系统中自动安装 MS DTC

  1. 在群集中的每个节点上安装 Windows 2000，并使用自动安装脚本配置群集。

  2. 在群集中的每个节点上，从命令提示符运行 comclust.exe。可在 system32 目录中找到 Comclust.exe。

将非群集 Windows NT 4.0 SP4 系统升级到 Windows 2000 群集

  1. 把将成为该群集组成部分的各系统都升级到 Windows 2000。

  2. 使用 Windows 2000 配置服务器工具配置服务器。

  3. 在群集中的每个节点上，从命令提示符运行 comclust.exe。可在 system32 目录中找到 Comclust.exe。

将群集 Windows NT 4.0 SP4 系统升级到 Windows 2000 群集

  1. 在群集中的每个节点上安装 Windows 2000。

    MS DTC 要求该群集中的所有节点都要同时升级到 Windows 2000。

  2. 在群集中的每个节点上，从命令提示符运行 comclust.exe。可在 system32 目录中找到 Comclust.exe。

重要 SQL Server 或 Microsoft 群集服务 (MSCS) 不支持 Microsoft System Management Server 1.2。

从群集故障中恢复并在 Windows 2000 群集上重建 MS DTC

  1. 当一个节点丢失时，MS DTC 将继续在群集中的其余节点上工作。丢失的是主节点还是辅助节点并不重要。

  2. 当准备好还原丢失的节点时，请将丢失的节点联接回群集中。一旦该节点与群集联接上，请运行 Comclust.exe，在 system32 目录中可找到该程序。这将在该节点上重新配置 MS DTC。


维护故障转移群集

安装 Microsoft® SQL Server™ 2000 故障转移群集之后，可以更改或修复现有安装。例如，可以向故障转移群集中的虚拟服务器添加其它节点，将群集实例作为独立实例运行，从群集实例中删除节点或从故障转移群集失败中恢复。

向现有虚拟服务器中添加节点

在 SQL Server 安装过程中，系统将提供维护现有虚拟服务器的选项。如果选择该选项，则以后可将其它节点添加到故障转移群集配置中。在配置为运行于一个节点上的现有虚拟服务器中，最多可另外添加三个节点。

向现有虚拟服务器中添加节点

SQL Setup

SQL 安装程序

从现有故障转移群集中删除节点

可以从虚拟服务器中删除节点（例如，如果一个节点已损坏）。虚拟 SQL Server 中的每个节点都被认为是对等的，因此可以删除任何节点。

可以随时将已删除的节点重新添加到故障转移群集内。例如，在发生严重故障后，可以重建已删除的节点并将其重新添加到故障转移群集内。或者，如果某个节点暂时不可用而后来又重新联机，并且，受影响虚拟服务器内的 SQL Server 2000 实例仍存在，则在该节点上再次安装二进制文件之前，安装程序将从计算机中删除该实例。

说明 已损坏的节点不一定能被删除，但删除进程将不会从不可用的节点中卸载任何二进制文件。

从现有故障转移群集中删除节点

SQL Setup

SQL 安装程序

将 SQL Server 群集实例作为独立实例运行

通常情况下，在 Microsoft 群集服务 (MSCS) 的控制下运行 SQL Server 群集实例。然而，有时可能必须将 SQL Server 群集实例作为独立实例运行（例如，执行像在单用户模式下运行 SQL Server 实例这类管理操作时）。若要在独立模式下使用套接字连接 SQL Server 2000 群集实例，则对于安装了实例的虚拟服务器而言，IP 地址和网络名称资源都必须联机。

如果这些资源不能联机，可以使用命名管道进行连接。但是，必须在客户端创建一个别名，以便与 SQL Server 实例正在监听的管道名称"交谈"。使用 SQL Server 网络实用工具找出管道名称。有关更多信息，请参见故障转移群集疑难解答。

从故障转移群集失败中恢复

通常有两种情况会导致故障转移群集失败：

  • 第一种情况，失败由两节点群集的节点 1 中的硬件失败造成。这种硬件故障可能由 SCSI 卡或操作系统中的故障造成的。

    若要从该失败中恢复，首先请使用安装程序删除该故障转移群集。

    删除故障转移群集实例

    SQL Setup

    SQL 安装程序

    从第一种情况的故障转移群集失败中恢复

    SQL Setup

    SQL 安装程序

  • 第二种情况，失败由节点 1 关闭或脱机引起，但不是无法挽回的损坏。这可能是由操作系统故障造成的。然而，使用下面的步骤从操作系统故障中恢复会花费时间。如果可以容易地从操作系统故障中恢复，则避免使用第二种情况。

    若要从该失败中恢复，首先请使用安装程序删除该故障转移群集。

    删除故障转移群集实例

    SQL Setup

    SQL 安装程序

    从第二种情况的故障转移群集失败中恢复

    SQL Setup

    SQL 安装程序

更改服务帐户

在故障转移群集节点关闭或脱机时，不得更改任何 SQL Server 服务帐户的密码。如果一定要这么做，则在所有节点回到联机状态后，必须使用企业管理器重置该密码。

如果 SQL Server 的服务帐户不是群集中的管理员，则无法在该群集的任何节点上删除管理共享。管理共享必须在群集中可用，SQL Server 才可以运行。

请参见

处理故障转移群集安装

SQL Server 网络实用工具


在故障转移群集中使用 SQL Server 工具

可以在 Microsoft® SQL Server™ 2000 故障转移群集中使用各种 SQL Server 工具和功能。但是请查阅以下使用注意事项。

全文查询

若要在故障转移群集中使用 Microsoft 搜索服务执行全文查询，请考虑下列事项：

  • SQL Server 2000 实例在所有故障转移群集节点上必须运行于同一系统帐户下，以使全文查询在群集上运行。

  • 必须使用 SQL Server 企业管理器更改故障转移群集中的 SQL Server 2000 启动帐户。如果使用 Microsoft Windows® 2000 中的"控制面板"或服务应用程序，则将破坏 SQL Server 的全文配置。
SQL Server 企业管理器

若要在故障转移群集中使用 SQL Server 企业管理器，请考虑下列事项：

  • 必须使用 SQL Server 企业管理器更改故障转移群集中的 SQL Server 2000 启动帐户。如果使用 Microsoft Windows 2000 中的"控制面板"或服务应用程序，则可能会破坏服务器配置。

  • 创建或更改数据库时，只能查看本地虚拟服务器的群集磁盘。

  • 如果正在通过 SQL Server 企业管理器浏览表且在故障转移期间失去与 SQL Server 的连接，则会出现错误信息"通讯链接故障"。此时，必须按 ESC 键并撤消更改，以退出"SQL Server 企业管理器"窗口。不能单击"运行查询"、保存任何更改或编辑网格。

  • 如果使用企业管理器重置 SQL Server 服务帐户的属性，将提示您重新启动 SQL Server。当 SQL Server 运行于故障转移群集配置时，这将使全文和 SQL 代理程序资源以及 SQL Server 脱机。但是，当 SQL Server 重新启动时，它不会使全文或 SQL 代理程序资源恢复联机。您必须使用 Windows 群集管理器实用工具手工启动这些资源。
服务控制管理器

使用服务控制管理器启动或停止 SQL Server 群集实例。不能暂停 SQL Server 群集实例。

使用服务控制管理器启动 SQL Server 群集实例

服务管理器

服务管理器

使用服务控制管理器停止 SQL Server 群集实例

服务管理器

服务管理器

SQL 事件探查器

可在故障转移群集中使用SQL 事件探查器。但是，如果运行 SQL 事件探查器跟踪时服务器上发生故障转移，则在服务器重新联机后必须重新启动跟踪才能继续进行跟踪。

SQL 查询分析器

可在故障转移群集中使用 SQL 查询分析器。但是，如果执行查询时所在服务器上发生故障转移，则在服务器重新联机后必须重新启动查询才能继续执行该查询。

SQL 邮件

若要在故障转移群集中使用 SQL 邮件，请考虑下列事项：

  • SQL Server 2000 实例在所有故障转移群集节点上必须运行于同一 Microsoft Windows NT® 4.0 和 Windows 2000 帐户下，这样才能使"SQL 邮件"在故障转移群集上工作。

  • 每个故障转移群集节点必须拥有名称和设置都相同的 MAPI 配置文件。有关更多信息，请参见配置邮件配置文件。

请参见

SQL 邮件

Microsoft 搜索服务

SQL 查询分析器

使用 SQL 事件探查器进行监视

SQL Server 企业管理器

启动、暂停和停止 SQL Server


故障转移群集疑难解答

本主题提供有关以下方面的信息：

  • 解决常见 Microsoft® SQL Server™ 2000 故障转移群集的使用问题。

  • 优化故障转移群集性能。

  • 在故障转移群集运用使用 COM 对象的扩展存储过程。
解决常见的使用问题

下面的列表描述常见使用问题并解释如何解决这些问题：

  • SQL Server 2000 在迁移到另一个节点后无法登录网络。

    SQL Server 服务帐户密码在所有节点上必须一致，否则该节点无法重新启动从某故障节点迁移的 SQL Server 服务。

    如果更改其中一个节点的 SQL Server 服务帐户密码，也必须更改所有其它节点上的密码。但是，如果使用 SQL Server 企业管理器更改帐户，该任务将自动完成。

  • SQL Server 无法访问群集磁盘。

    如果共享群集磁盘使用不同的驱动器号，则节点将不能恢复从失败节点迁移过来的群集磁盘。两台服务器上的群集磁盘的磁盘驱动器号必须相同。如果不相同，请检查操作系统和 Microsoft 群集服务 (MSCS) 的原始安装。有关更多信息，请参见 Microsoft Windows NT® 4.0 企业版、Windows® 2000 Advanced Server 或 Windows 2000 Datacenter Server 文档。

  • 不想出现服务（如全文检索或 SQL Server 代理）失败导致故障转移。

    若要防止特定服务失败导致 SQL Server 组故障转移，请使用 Windows NT 4.0 或 Windows 2000 中的群集管理器配置这些服务。例如，若要防止全文检索服务失败导致 SQL Server 的故障转移，请清除"全文属性"对话框的"高级"选项卡上的"影响组"复选框。但是，如果 SQL Server 导致故障转移，则全文检索服务将重新启动。

  • SQL Server 不自动启动。

    使用 SQL Server 无法自动启动故障转移群集。在 MSCS 中必须使用群集管理器自动启动故障转移群集。

  • SQL Server 安装过程中出现错误信息"找不到兼容的资源组"。

    该错误是由 Windows NT 4.0 企业版上的 Microsoft 分布式事务处理协调器 (MS DTC) 安装程序造成的。在运行安装程序时，MS DTC 要求本地节点拥有一个包含网络名称、IP 地址和共享群集磁盘的组。如果出现该错误，请打开群集管理器，确定本地节点拥有一个满足上述要求的组。进行此操作的最简单的方法是将一个磁盘移动到已包含网络名和 IP 地址的群集组中。在本地节点上有该分组后单击"重试"按钮。

  • 安装过程中出现错误信息"此虚拟服务器可用的所有群集磁盘为其它节点所有"。

    在为安装数据文件选择驱动器和路径，而所选择的驱动器不为本地节点所拥有时会显示此消息。使用群集管理器将该磁盘移动到本地节点中。

  • SQL Server 安装过程中出现错误信息"无法删除 SQL Server 资源。它们必须手工删除。将继续卸载。"。

    当 SQL Server 安装程序无法删除所有的 SQL Server 资源时出现该消息。必须到"控制面板"中将试图在每个节点上删除的实例卸载。

  • 不能启用群集操作系统错误日志。

    MSCS 使用操作系统群集错误日志记录有关该群集的信息。使用该错误日志调试群集配置问题。若要启用群集错误日志，请设置系统环境变量 CLUSTERLOG=<path to file>（例如，CLUSTERLOG=c:\winnt\cluster\cluster.log）。在 Windows 2000 中，默认情况下该错误日志为打开状态。

  • 如果网络名称脱机且无法使用 TCP/IP 进行连接，则必须使用命名管道。

    若要使用命名管道进行连接，需要使用客户端网络实用工具创建一个别名以连接适当的计算机。例如，如果有一个包含两个节点（NodeA 和 NodeB）的群集和一个包含默认实例的虚拟服务器 (Virtsql)，则可以执行下列步骤连接网络名称资源已脱机的服务器：

    1. 使用群集管理器确定包含 SQL Server 实例的组正在哪个节点上运行。对于本例，此节点是 Node A。

    2. 使用 net start 命令在该计算机上启动 SQL Server 服务。有关使用 net start 命令的更多信息，请参见手工启动 SQL Server。

    3. 启动 Node A 上的 SQL Server 网络实用工具。查看服务器正在监听的管道名称。应类似于 \\.\$$\VIRTSQL\pipe\sql\query。

    4. 在客户端计算机上启动客户端网络实用工具。

    5. 创建别名 SQLTEST1 以通过命名管道连接到该管道名称。为此，应将 Node A 作为服务器名称并将管道编辑为 \\.\$$\VIRTSQL\pipe\sql\query。使用别名 SQLTEST1 作为服务器名称连接该实例。

    有关更多信息，请参见客户端 Net-Library 和网络协议。

优化故障转移群集的性能

若要在使用故障转移群集时优化性能，请考虑下列事项：

  • 如果磁盘控制器不在群集计算机以外，则必须关闭控制器内的写缓存以防止故障转移期间发生数据丢失。

  • 在群集中的主机控制器上使用回写高速缓存会影响性能。但是，如果使用外部控制器，则将继续提供性能收益。外部磁盘阵列不受故障转移群集的影响，甚至能通过 SCSI 总线使高速缓存正确地同步。

  • 建议不使用文件共享的群集驱动器。使用这些驱动器将影响恢复所需的时间，并会导致由于资源故障而引起的群集组的故障转移。
使用扩展存储过程和 COM 对象

如果在故障转移群集配置中使用扩展存储过程，则需将所有扩展存储过程都安装在共享群集磁盘中。这是为确保当某节点发生故障转移时，仍能继续使用扩展存储过程。

如果扩展存储过程使用 COM 组件，管理员需在该群集的各个节点中注册 COM 组件。用于装载和执行 COM 组件的信息必须在活动节点的注册表中才能创建 COM 组件。否则，该信息将保留在 COM 组件最先注册到的计算机的注册表中。有关更多信息，请参见扩展存储过程构架。


导入和导出数据

导入数据是从 Microsoft® SQL Server™ 的外部数据源（如 ASCII 文本文件）中检索数据，并将数据插入到 SQL Server 表的过程。导出数据是将 SQL Server 实例中的数据析取为某些用户指定格式的过程，例如将 SQL Server 表的内容复制到 Microsoft Access 数据库中。

将数据从外部数据源导入 SQL Server 实例很可能是建立数据库后要执行的第一步。数据导入 SQL Server 数据库后，即可开始使用该数据库。

将数据导入 SQL Server 实例可以是一次性操作，例如将另一个数据库系统中的数据迁移到 SQL Server 实例。在初次迁移完成后，该 SQL Server 数据库将直接用于所有与数据相关的任务，而不再使用原来的系统。不需要进一步导入数据。

导入数据也可以是不断进行的任务。例如，创建了用于行政报告的新 SQL Server 数据库，但是数据驻留在旧式系统中，并且该旧式系统由大量业务应用程序进行更新。在这种情况下，可以每天或每周将旧式系统中的数据复制或更新到 SQL Server 实例。

导出数据的发生频率通常较低。SQL Server 提供多种工具和功能，使应用程序（如 Access 或 Microsoft Excel）可以直接连接并操作数据，而不必在操作数据前先将所有数据从 SQL Server 实例复制到该工具中。但是，可能需要定期将数据从 SQL Server 实例导出。在这种情况下，可以将数据先导出到文本文件，然后由应用程序读取。或者，可以特殊复制数据。例如，可以将 SQL Server 实例中的数据析取为 Excel 电子表格格式，并将其存储在便携式计算机中以便在商务旅行中使用。

SQL Server 提供多种工具用于各种数据源的数据导入和导出，这些数据源包括文本文件、ODBC 数据源（例如 Oracle 数据库）、OLE DB 数据源（例如其它 SQL Server 实例）、ASCII 文本文件和 Excel 电子表格。

此外，SQL Server 复制使数据得以在整个企业内发布，在各个位置之间复制数据以及自动同步不同数据复本之间的更改。


选择用于导入和导出数据的工具

可以使用几种 SQL Server 工具和 Transact-SQL 语句导入和导出 Microsoft® SQL Server™ 实例中的数据。也可以使用 SQL Server 提供的编程模型和应用程序接口 (API)，自己编写程序以导入和导出数据。

可以通过下列方法将数据大容量复制到 SQL Server 实例，或从 SQL Server 实例向外大容量复制数据：

  • 使用数据转换服务 (DTS) 导入/导出向导或 DTS 设计器创建可用于导入、导出和转换数据的 DTS 包。

    有关更多信息，请参见 DTS 工具。

  • 使用 SQL Server 复制在整个企业内分发数据。

    SQL Server 中的复制技术使您得以制作数据复本，将这些复本移到不同位置，以及自动同步数据以使所有复本都具有相同的数据值。可以在同一服务器或通过 LAN、WAN 或 Internet 连接的不同服务器上的数据库之间执行复制。

    有关更多信息，请参见复制概述。

  • 使用 bcp 命令提示实用工具在 SQL Server 实例和数据文件之间导入和导出数据。

  • 从某个 OLE DB 提供程序中选择数据，并将数据从外部数据源复制到 SQL Server 实例。

  • 使用分布式查询从另一个数据源中选择数据并指定要插入的数据。

    有关更多信息，请参见分布式查询。

  • 使用 INSERT 语句将数据添加到现有表中。

    有关更多信息，请参见 INSERT。

  • 使用 BULK INSERT 语句将数据从数据文件导入到 SQL Server 实例。

    有关更多信息，请参见 BULK INSERT。

  • 使用 SELECT INTO 语句根据现有表创建新表。

    有关更多信息，请参见 SELECT。

选择的数据导入或导出方法取决于用户的要求，例如：

  • 源数据和目的数据的格式。

  • 源数据和目的数据的位置。

  • 导入和导出是一次性操作还是不断进行的任务。

  • 愿意使用命令提示实用工具、Transact-SQL 语句还是图形界面。

  • 导入或导出操作的性能。

下表描述了 SQL Server 中各种导入和导出选项的功能。

所需的 功能 | DTS 向导 | 复制 | bcp | BULK INSERT | SELECT INTO / INSERT
导入文本数据 | 是 |  | 是 | 是 | 是 (1)
导出文本数据 | 是 |  | 是 |  |
从 ODBC 数据源导入 | 是 | 是 |  |  |
导出到 ODBC 数据源 | 是 | 是 |  |  |
从 OLE DB 数据源导入 | 是 | 是 |  |  | 是 (1)
导出到 OLE DB 数据源 | 是 | 是 | 是 |  |
图形用户界面 (GUI) | 是 | 是 |  |  |
命令行提示/ 批处理脚本 | 是 | 是 | 是 |  |
Transact-SQL 脚本 |  | 是 |  | 是 | 是
自动调度 | 是 | 是 | 是 (2) | 是 (2) |
特殊导入/导出 | 是 |  | 是 | 是 | 是
反复导入/导出 | 是 | 是 | 是 |  |
最优性能 |  |  | 是 | 是 |
数据转换 | 是 |  |  |  |
编程接口 | 是 | 是 | 是 |  |

1 通过 OLE DB 提供程序使用分布式查询从外部数据源检索数据。
2 通过显式创建用 SQL Server 代理程序调度的作业。

请参见

bcp 实用工具


准备用于导入和导出的数据

为了使 bcp 和 BULK INSERT 实用工具能够插入数据，数据文件格式必须为行和列。只要能够描述终止符（用来分隔列和行的字符），Microsoft® SQL Server™ 就可以接受任何 ASCII 或二进制格式的数据。数据文件的结构不必与 SQL Server 表的结构相同，因为 bcp 和 BULK INSERT 都允许在大容量复制过程中跳过列或对列进行重新排序。

大容量复制到 SQL Server 实例的数据将附加到表中任何现有的内容上。从 SQL Server 实例大容量复制到数据文件的数据则将重写数据文件的原有内容。

大容量复制数据：

  • 如果导入数据，则目的表必须已经存在。如果将数据导出到某个文件，则 bcp 将创建该文件。

    数据文件中的字段数不必与表中的列数匹配，字段和列的顺序也可以不一致。

  • 数据文件中的数据必须是字符格式或先前由 bcp 实用工具生成的格式（如本机格式）。

    表中每一列都必须与要复制的数据文件中的字段兼容。例如，不可能使用本机格式 bcp 将 int 字段复制到 datetime 列中。

  • 若要大容量复制数据，需要对源文件和源表以及目的文件和目的表具有相应的权限。

    若要将数据从数据文件大容量复制到表中，则必须对该表具有 INSERT 和 SELECT 权限。若要将表或视图大容量复制到数据文件中，则必须对正在大容量复制的表或视图具有 SELECT 权限。

使用大容量复制操作之前，应考虑下列事项：

  • 可以指定从数据文件中装载的行数而非装载整个数据文件。例如，若要只装载 10,000 行的数据文件中的前 150 行，请在装载数据时指定 -L last_row 开关。这对于测试批处理装载过程是非常有用的。

  • 使用 -F first_row 开关指定表或视图中要大容量复制的起始行时，表或视图中的所有行都会首先返回到客户端，然后再由 bcp 实用工具决定跳过哪些行以及将哪些行写入数据文件。因此，指定 -F first_row 不会限制返回到客户端的数据量，也不会必然地导致大容量复制操作执行更快。

  • 由于 SQL Server 可以使用并行扫描检索数据，因此不能保证从 SQL Server 实例中大容量复制的数据将以特定的顺序排序，除非从查询中大容量复制数据并指定 ORDER BY 子句。

  • 若要使用本机格式数据文件从早期版本的 SQL Server 中复制数据，请使用同一版本的 bcp 进行文件的导入、导出和格式化。
导入和导出数据示例

若要将 pubs 数据库中 publishers 表的数据大容量复制到 ASCII 文本格式的 Publishers.txt 文件中，请在命令提示符下执行以下命令：

bcp pubs..publishers out publishers.txt -c -Sservername -Usa -Ppassword

Publishers.txt 文件的内容如下：

0736 | New Moon Books | Boston | MA | USA
0877 | Binnet & Hardley | Washington | DC | USA
1389 | Algodata Infosystems | Berkeley | CA | USA
1622 | Five Lakes Publishing | Chicago | IL | USA
1756 | Ramona Publishers | Dallas | TX | USA
9901 | GGG&G | München | -- | Germany
9952 | Scootney Books | New York | NY | USA
9999 | Lucerne Publishing | Paris | -- | France

反之，若要将 Publishers.txt 文件中的数据大容量复制到 pubs 数据库的 publishers2 表中，请在命令提示符下执行以下命令：

bcp pubs..publishers2 in publishers.txt -c -Sservername -Usa -Ppassword

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..publishers2 FROM 'c:\publishers.txt'
WITH (DATAFILETYPE = 'char')

说明 必须先创建 publishers2 表。

请参见

bcp 实用工具

BULK INSERT。

字符格式

ExportData 方法

ImportData 方法

管理安全帐户

本机格式


使用 bcp 和 BULK INSERT

bcp 命令行提示实用工具将 Microsoft® SQL Server™ 数据复制到某个数据文件或从某个数据文件复制数据。该实用工具最常用于将大量数据从其它程序（通常是另一种数据库管理系统 (DBMS)）传输到 SQL Server 表中。数据首先从源程序导出到数据文件，然后使用 bcp 将数据从该数据文件导入到 SQL Server 表。另外，bcp 还可以用来将数据从 SQL Server 表传输到数据文件中，以供其它程序使用。例如，可以将数据从 SQL Server 实例复制到某个数据文件。而其它程序可以从该数据文件中导入数据。

说明 bcp 实用工具是用 ODBC 大容量复制应用程序接口 (API) 编写的。而早期版本的 bcp 实用工具是用 DB-Library 大容量复制 API 编写的。

使用 BULK INSERT 语句，还可以将数据从数据文件传送到 SQL Server 表。然而，BULK INSERT 语句不能将数据从 SQL Server 实例大容量复制到数据文件。BULK INSERT 语句使您得以利用 Transact-SQL 语句而不是命令提示符来实现 bcp 实用工具的功能，将数据大容量复制到 SQL Server 实例。

还可以通过编写程序，使用大容量复制 API 在 SQL Server 和数据文件之间大容量复制数据。大容量复制 API 可以在基于 ODBC、OLE DB、SQL-DMO 和 DB-Library 的应用程序中使用。

触发器执行

所有大容量复制操作（BULK INSERT 语句、bcp 实用工具和大容量复制 API）均支持大容量复制提示 FIRE_TRIGGERS。在将行复制到表的大容量复制操作中，如果指定了 FIRE_TRIGGERS，则对大容量复制操作所插入的所有行均执行在目的表上定义的 INSERT 和 INSTEAD OF 触发器。默认情况下，大容量复制操作不执行触发器。

对于指定了 FIRE_TRIGGERS 的大容量复制操作，需考虑以下事项：

  • 通常在日志中记录最少的大容量复制操作将被完整地记录下来。

  • 触发器对大容量复制操作中的每个批处理触发一次。传送到触发器的 inserted 表包含该批处理插入的所有行。只有当大容量复制到带有 INSERT 和 INSTEAD OF 触发器（这两种触发器支持多行插入）的表时，才应指定 FIRE_TRIGGERS。

  • 插入触发器生成的结果集不返回执行大容量复制操作的客户端。

请参见

SQL Server 向后兼容性详细信息

大容量复制函数

大容量复制行集

BulkCopy 对象

BULK INSERT。

执行大容量复制操作


使用本机格式、字符格式和 Unicode 格式

通过在命令提示符下指定开关，bcp 实用工具可以创建或读取下面四种默认数据格式的数据文件。

数据格式 | bcp 实用工具开关 | BULK INSERT 子句
本机 | -n | DATAFILETYPE = 'native'
字符 | -c | DATAFILETYPE = 'char'
Unicode 字符 | -w | DATAFILETYPE = 'widechar'
Unicode 本机 | N | DATAFILETYPE = 'widenative'

默认情况下，bcp 实用工具以交互模式运行，并向 Microsoft® SQL Server™和用户查询指定数据格式所需的信息。然而，当使用 -n、-c、-w 或 -N 开关时，bcp 不按列查询有关 SQL Server 表的信息，而是使用指定的默认格式读取或写入数据。

默认情况下，BULK INSERT 语句在字符模式 (char) 下运行。不使用交互式模式。

此外，–V 开关将导致 bcp 实用工具将本机 (-n) 或字符 (-c) 数据修改为与早期版本的 SQL Server 客户端兼容的格式。有关更多信息，请参见从早期版本的 SQL Server 复制本机和字符格式的数据。

本机模式的大容量复制最适合于 sql_variant 列。与字符或 Unicode 大容量复制不同的是，本机模式大容量复制保留每个 sql_variant 值的元数据。

推荐的默认数据格式取决于大容量复制操作的类型。

大容量复制操作 | 本机 | 字符 | Unicode 字符 | Unicode 本机
使用数据文件在多个 SQL Server 实例之间大容量复制数据（不包括扩展/双字节字符集 (DBCS) 字符）。 | 是 1 | -- | -- | --
使用数据文件在多个 SQL Server 实例之间大容量复制数据（涉及扩展/DBCS 字符）。 | -- | -- | -- | 是
将数据导出到文本文件，以便在其它程序中使用。 | -- | 是 | -- | --
从其它程序生成的文本文件中导入数据。 | -- | 是 | -- | --
使用数据文件在多个 SQL Server 实例之间大容量复制数据（Unicode 数据/无扩展/DBCS 字符）。 | -- | -- | 是 | --

(1) 使用 bcp 从 SQL Server 大容量复制数据的最快方法。

请参见

指定数据格式


本机格式

-n 开关（或 BULK INSERT 语句 DATAFILETYPE 子句的 native 值）使用本机（数据库）数据类型。如果必须将信息从一个 Microsoft® SQL Server™ 实例复制到另一个，则以本机格式存储信息非常有用。使用本机格式可以节省时间和空间，避免在各数据类型与字符格式之间进行不必要的转换。但是，除 bcp 之外的其它任何程序都不能读取本机格式的数据文件。

例如，若要用本机数据格式将 pubs 数据库的 publishers 表大容量复制到 Publ.txt 数据文件中，可以使用以下命令：

bcp pubs..publishers out publ.txt -n -Sservername -Usa -Ppassword

在本机模式数据文件中存储为 SQLVARIANT 的 sql_variant 数据将保留其所有的特征。记录每个数据值的数据类型的元数据与数据值一同存储，用于在目的 sql_variant 列中重新创建具有相同数据类型的数据值。如果目的列的数据类型不是 sql_variant，则每个数据值都将按照隐性数据转换的一般规则转换为目的列的数据类型。如果发生数据转换错误，将回滚当前的批处理。在 sql_variant 列之间传输的 char 和 varchar 值可能会有代码页转换问题。有关更多信息，请参见在不同排序规则间复制数据。

bcp 实用工具在每个 char 或 varchar 字段的开头添加一个 ASCII 字符（与这些字段中的数据长度相等）。表中的非字符数据将以 SQL Server 内部二进制数据格式写入数据文件。

重要 使用本机模式时，默认情况下，bcp 在将字符数据大容量复制到 SQL Server 中之前，总是先将数据文件中的字符转换成 ANSI 字符；而在将字符数据大容量复制到数据文件之前，总是先将 SQL Server 中的字符转换成 OEM 字符。在从 OEM 字符转换到 ANSI 字符或从 ANSI 字符转换到 OEM 字符的过程中，扩展字符数据可能会丢失。为了防止丢失扩展字符，请使用 Unicode 本机格式，或者使用 –C（或 BULK INSERT 语句的 CODEPAGE 子句）为大容量复制操作指定代码页。

不同的和定义不正确的表

使用本机格式将数据大容量复制到定义不正确的表可能导致不正确地装载表。不正确的装载可能表现为目标表中不正常的数据格式。这也适用于以本地模式使用 bcp API 的客户端工具。

本机格式旨在用于定义相同的 SQL Server 表之间的高速数据传输。若要获得最佳的传输速率，应执行几个关于数据格式的检查。如果表未正确定义，则使用字符格式。

正确的表定义包括正确的列数、数据类型、长度和 NULL 状态。

装载 ASCII 文件

通常情况下，用户试图以 SQL Server 本机格式装载 ASCII 文件。这将导致错误地解释 ASCII 文件中的十六进制值，并且有时会出现"意外的文件结尾"错误信息。装载 ASCII 文件的正确方法是将数据文件中的每个字段表示为字符串（字符格式 bcp），并且让 SQL Server 在向表中插入行时将数据转换为内部数据类型（例如 int、float 或 datetime）。

请参见

BULK INSERT。

ServerBCPDataFileType 属性

Unicode 本机格式


字符格式

-c 开关（或 BULK INSERT 语句的 DATAFILETYPE 子句的 char 值）对所有列都使用字符 (char) 数据格式，在各字段之间使用制表符，并在每行的结尾使用换行符作为默认的终止符。如果数据要在其它程序（如电子表格）中使用，或需要将数据从其它数据库复制到 Microsoft® SQL Server™ 实例中，则以字符格式存储信息会非常有用。如果从其它程序复制数据，并且该程序能够以纯文本格式导入和导出数据，则倾向于使用字符格式。

例如，若要用字符格式将 pubs 数据库的 publishers 表大容量复制到 Publ.txt 数据文件中，可以使用以下命令：

bcp pubs..publishers out publ.txt -c -Sservername -Usa -Ppassword

下表显示 Publ.txt 文件的内容。

0736 | New Moon Books | Boston | MA | USA
0877 | Binnet & Hardley | Washington | DC | USA
1389 | Algodata Infosystems | Berkeley | CA | USA
1622 | Five Lakes Publishing | Chicago | IL | USA
1756 | Ramona Publishers | Dallas | TX | USA
9901 | GGG&G | München |  | Germany
9952 | Scootney Books | New York | NY | USA
9999 | Lucerne Publishing | Paris |  | France

若要使用与字符格式提供的默认终止符不同的字段终止符和行终止符，请指定如下参数。

终止符 | bcp 实用工具开关 | BULK INSERT 子句
字段 | -t | FIELDTERMINATOR
行 | -r | ROWTERMINATOR

例如，若要用字符格式将 pubs 数据库的 publishers 表大容量复制到 Publ.txt 数据文件中，以逗号作为字段终止符，以换行符 (\n) 作为行终止符，可以使用以下命令：

bcp pubs..publishers out publ.txt -c -t , -r \n -Sservername -Usa -Ppassword

Publ.txt 文件的内容如下：

0736,New Moon Books,Boston,MA,USA
0877,Binnet & Hardley,Washington,DC,USA
1389,Algodata Infosystems,Berkeley,CA,USA
1622,Five Lakes Publishing,Chicago,IL,USA
1756,Ramona Publishers,Dallas,TX,USA
9901,GGG&G,München,Germany
9952,Scootney Books,New York,NY,USA
9999,Lucerne Publishing,Paris,France

重要 使用字符模式时，默认情况下，bcp 在将字符数据大容量复制到 SQL Server 实例中之前，总是先将数据文件中的字符转换成 ANSI 字符；而在将字符数据大容量复制到数据文件之前，总是先将 SQL Server 中的字符转换成 OEM 字符。在从 OEM 字符转换到 ANSI 字符或从 ANSI 字符转换到 OEM 字符的过程中，扩展字符数据可能会丢失。为了防止丢失扩展字符，请使用 Unicode 本机格式，或者使用 –C（或 BULK INSERT 语句的 CODEPAGE 子句）为大容量复制操作指定代码页。

在字符模式文件中存储的 sql_variant 数据没有存储任何元数据。每个数据值都将按照隐性数据转换规则转换为 char。如果大容量复制到 sql_variant 目的列中，则数据将以 char 数据类型导入。如果大容量复制到数据类型不是 sql_variant 的目的列，数据值将按照隐性转换规则从 char 转换为目的数据类型。

说明 bcp 实用工具将 money 值导出到字符格式数据文件中时，不会带有诸如逗号分隔符之类的数字分组符号，但在小数点后会有四位数字。例如，包含值 1,234,567.123456 的 money 列将以字符串 1234567.1235 的形式大容量复制到数据文件。

请参见

在不同排序规则间复制数据

ServerBCPDataFileType 属性


从早期版本的 SQL Server 复制本机和字符格式的数据

若要从 Microsoft® SQL Server™ 7.0 或其早期版本复制本机和字符格式的数据，请使用 –V 开关。当指定该开关时，SQL Server 2000 使用 SQL Server 早期版本的数据类型。使用 –V 开关指定 bcp 数据文件是在 SQL Server 6.0 版 (-V 60)、SQL Server 6.5 版 (-V 65) 还是在 SQL Server 7.0 版 (-V 70) 的级别上。

–V 开关扩展了 SQL Server 7.0 中使用的 –6 开关的功能。使用 –6 开关与使用 –V 60 开关或 –V 65 开关相同。虽然 SQL Server 2000 仍支持 –6 开关，但推荐使用 –V 开关。

说明 –V 开关不适用于 BULK INSERT 语句。

如果从 SQL Server 7.0 或更早的版本将数据大容量复制到数据文件，请考虑下列事项：

  • bcp 不为任何 datetime 或 smalldatetime 数据生成 SQL Server 6.0 或 SQL Server 6.5 日期格式。日期将始终以 ODBC 格式写入。

  • bit 列中的空值作为 0 值写入，因为 SQL Server 6.5 及更早的版本不支持可为空的 bit 数据。

  • 在 SQL Server 6.5 或更早的版本中，bcp 将空值表示为长度为 0 的值，但是现在空值作为长度为 -1 的值存储。在 SQL Server 7.0 和 SQL Server 2000 中，0 值代表长度为零的列。

  • 将复制到 SQL Server 7.0、SQL Server 6.5 或 SQL Server 6.0 本机模式或 Unicode 本机模式数据文件的 bigint 数据存储为 decimal(19,0)。将字符模式或 Unicode 字符模式数据文件中的 bigint 数据存储为 [-]digits 形式的字符串或 Unicode 字符串（如 –25688904432)。

  • 在具有 char 或 varchar 字段的表中，bcp 实用工具将 ASCII 字符添加到等于数据长度的每个数据文件字段的开头。在包含 numeric 数据的表中，信息将以 SQL Server 内部二进制数据格式写入数据文件。
复制日期值

在 SQL Server 7.0 和 SQL Server 2000 中，bcp 使用 ODBC 大容量复制 API。因此，bcp 使用 ODBC 日期格式 (yyyy-mm-dd hh:mm:ss[.f...]) 导入日期值。然而，在 SQL Server 6.5 或更早的版本中，bcp 使用 DB-Library 大容量复制 API 和 DB-Library 日期格式。使用 –V 65 开关将日期格式从 SQL Server 6.5 或更早的版本复制到 SQL Server 7.0 和 SQL Server 2000。如果指定 –V 65，则 bcp 实用工具首先尝试使用 ODBC 日期格式转换数据文件中的日期值。如果转换失败，则 bcp 试图使用 DB-Library 格式转换日期值。

然而，bcp 实用工具始终对 datetime 和 smalldatetime 值使用 ODBC 默认格式导出字符格式，即使指定了 –V 65。例如，包含日期 1998 年 8 月 12 日的 datetime 列将以字符串 1998-08-12 00:00:00.000 的形式大容量复制到数据文件。

重要 使用 bcp 将数据导入 smalldatetime 字段时，一定要使秒的值是 00.000，否则 bcp 操作将失败。smalldatetime 数据类型仅包含最接近的分钟值。在这种情况下 BULK INSERT 不会失败，但会截断秒值。

因为需要开销来支持多日期转换，所以使用 –V 65 开关会影响性能。

请参见

使用 bcp 和 BULK INSERT

SQL Server 向后兼容性详细信息

CAST 和 CONVERT

Use6xCompatible 属性


Unicode 字符格式

-w 开关（或 BULK INSERT 语句的 DATAFILETYPE 子句的 widechar 值）对所有列都使用 Unicode 字符数据格式，在各字段之间使用制表符，并在每行的结尾使用换行符作为默认的终止符。这样，既可以从所用代码页与运行 bcp 的客户端所用的代码页不同的服务器复制数据，也可以将数据复制到与原服务器具有相同或不同代码页的另一台服务器：

  • 如果源和目的都是 Unicode 数据类型，则不会丢失任何字符数据。

  • 如果源和目的不是 Unicode 数据类型，则源数据中目的一方所不能表示的扩展字符会有最小限度的丢失。

例如，若要用 Unicode 字符格式将 pubs 数据库的 publishers 表大容量复制到 Publ.txt 数据文件中，可以使用以下命令：

bcp pubs..publishers out publ.txt -w -Sservername -Usa -Ppassword

Unicode 字符格式数据文件遵从 Unicode 文件规则：文件的前两个字节是十六进制数字 0xFEFF 或 0xFFFE。这两个字节用作字节顺序标记，指定在文件中高位字节是存储在前面还是后面。

若要使用与 Unicode 字符格式提供的默认终止符不同的字段终止符和行终止符，请指定如下参数。

终止符 | bcp 实用工具开关 | BULK INSERT 子句
字段 | -t | FIELDTERMINATOR
行 | -r | ROWTERMINATOR

例如，若要用 Unicode 字符格式将 publishers 表大容量复制到 Publ.txt 数据文件中，并以逗号作为字段终止符，以换行符 (\n) 作为行终止符，可以使用以下命令：

bcp pubs..publishers out publ.txt -w -t , -r \n -Sservername -Usa -Ppassword

Publ.txt 数据文件中的每个字符都使用两个字符位置，每个字段都由逗号分隔，每行都由换行符分隔。

Unicode 字符模式数据文件中存储的 sql_variant 数据与字符模式数据文件中存储的 sql_variant 数据操作方式相同，只是数据存储为 nchar 而不是 char 数据。

请参见

ServerBCPDataFileType 属性


Unicode 本机格式

-N 开关（或 BULK INSERT 语句 DATAFILETYPE 子句的 widechar 值）对所有非字符数据均使用本机（数据库）数据类型，而对所有字符（char、nchar、varchar、nvarchar、text 和 ntext）数据均使用 Unicode 字符数据格式。

如果必须将信息从一个 Microsoft® SQL Server™ 实例复制到另一个，则以 Unicode 本机格式存储信息非常有用。对非字符数据使用本机格式可以节省时间，避免在各数据类型与字符格式之间进行不必要的转换。在使用不同代码页的服务器之间大容量装载数据时，对所有字符数据使用 Unicode 字符格式可以防止丢失任何扩展字符。但是，以 Unicode 本机格式存储的数据文件只能用 bcp 实用工具和 BULK INSERT 语句读取。

例如，若要用本机 Unicode 数据格式将 pubs 数据库的 sales 表大容量复制到 Sales.dat 数据文件中，可以使用以下命令：

bcp pubs..sales out Sales.dat -N -Sservername -Usa -Ppassword

Unicode 本机模式数据文件中存储为 SQLVARIANT 的 sql_variant 数据与本机模式数据文件中存储的 sql_variant 数据操作方式相同，只是 char 和 varchar 值转换为 nchar 和 nvarchar。当大容量复制到目的列时，原来的元数据会保留，而值会转换回其原来的 char 和 varchar 数据类型。

请参见

ServerBCPDataFileType 属性


指定数据格式

如果正在 Microsoft® SQL Server™ 实例和其它程序（例如另一个数据库程序）之间复制数据，则默认的数据类型格式（本机、字符或 Unicode）可能与其它程序所预期的数据结构不兼容。因此，bcp 实用工具允许指定有关数据文件结构的更详细的信息。

如果没有指定 -n、-c、-w 或 -N 开关，则 bcp 实用工具会交互式地提示输入正在复制的每个列的进一步信息：

  • 文件存储类型

  • 前缀长度

  • 字段长度

  • 字段终止符

    说明 在使用 BULK INSERT 语句时不能使用交互模式。

根据源列或目的列的 SQL Server 数据类型，bcp 实用工具在每个提示中都会提供默认值。接受 bcp 在这些提示中提供的默认值将生成与本机格式 (-n) 相同的结果，并提供一种方法，以将数据从其它程序中大容量复制出来，以便日后重新装载到 SQL Server 中。

可以创建一个格式文件，用来存储对数据文件各字段的提示的响应，以便重复使用相同的响应而不必再次输入它们。格式文件可以提供将数据大容量复制到 SQL Server 实例，或从 SQL Server 实例大容量复制数据时所需的所有格式信息。格式文件提供了一种灵活的系统，用来写入很少需要或不需要编辑即可符合其它数据格式的数据文件，或者用来从其它软件中读取数据文件。

例如，若要交互式地将 publishers 表大容量复制到 Publ.txt 文件中，可以使用以下命令：

bcp pubs..publishers out publ.txt -Sservername -Usa -Ppassword

对 publishers 表的每一列，都会出现四个提示，并且在方括号中显示 bcp 提供的默认值。以下示例只是 publishers 表中 pub_id 列的情况。

Enter the file storage type of field pub_id [char]:
Enter prefix length of field pub_id [0]:
Enter length of field pub_id [4]:
Enter field terminator [none]:

按 ENTER 键接受所提供的默认值。若要指定与默认值不同的值，请在命令提示符下输入新值。

请参见

使用格式文件


文件存储类型

文件存储类型描述数据在数据文件中的存储方式。数据可以作为其数据库表类型（本机格式）、ASCII 格式的字符串（字符格式）或隐性转换所支持的任何数据类型复制到数据文件中（例如将 smallint 复制为 int）。用户定义的数据类型将复制为其基本类型。

若要以尽可能压缩存储的格式（本机数据格式）将数据从 Microsoft® SQL Server™ 实例大容量复制到数据文件中，请接受 bcp 提供的默认文件存储类型。

若要以 ASCII 文本格式将数据从 SQL Server 实例大容量复制到数据文件中，请指定 char 作为表中所有列的文件存储类型。

若要将数据从数据文件大容量复制到 SQL Server 实例中，对于纯 ASCII 文件，请将文件存储类型指定为 char，而对于以本机数据类型格式存储的数据，请指定为以下适当的文件存储类型。

文件存储类型 | 在命令提示符下输入
char | c[har]
varchar | c[har]
nchar | w
nvarchar | w
text | T[ext]
ntext | W
binary | x
varbinary | x
image | I[mage]
datetime | d[ate]
smalldatetime | D
decimal | n
numeric | n
float | f[loat]
real | r
Int | i[nt]
bigint | B[igint]
smallint | s[mallint]
tinyint | t[inyint]
money | m[oney]
smallmoney | M
Bit | b[it]
uniqueidentifier | u
sql_variant | V[ariant]
timestamp | x

如果输入的文件存储类型代表一种无效的隐性转换，则会导致 bcp 失败。例如，为 int 数据指定 smallint 会造成溢出错误，但是为 smallint 数据指定 int 则有效。当将任何数据类型从 SQL Server 实例大容量复制到数据文件中时，将文件存储类型指定为 char 总是有效的。

如果将非字符数据类型（例如 float、money、datetime 或 int）存储为其数据库类型，则数据将以 SQL Server 内部二进制数据格式写入数据文件。

也可以生成一个格式文件，用来保存对每个字段的文件存储类型的响应。当将数据文件中的数据大容量复制回 SQL Server 实例，或在其它时间从表中向外大容量复制数据时，可以使用该格式文件提供默认的信息，而不必重新指定格式。

在格式文件中，每种本机文件存储类型都记录为相应的宿主文件数据类型。

文件存储类型 | 宿主文件数据类型
char | SQLCHAR
varchar | SQLCHAR
nchar | SQLNCHAR
nvarchar | SQLNCHAR
text | SQLCHAR
ntext | SQLNCHAR
binary | SQLBINARY
varbinary | SQLBINARY
image | SQLBINARY
datetime | SQLDATETIME
smalldatetime | SQLDATETIM4
decimal | SQLDECIMAL
numeric | SQLNUMERIC
float | SQLFLT8
real | SQLFLT4
int | SQLINT
bigint | SQLBIGINT
smallint | SQLSMALLINT
tinyint | SQLTINYINT
money | SQLMONEY
smallmoney | SQLMONEY4
bit | SQLBIT
uniqueidentifier | SQLUNIQUEID
sql_variant | SQLVARIANT
timestamp | SQLBINARY

因为存储为 ASCII 文本的数据文件使用 char 作为文件存储类型，所以在这些情况下，格式文件中只会出现 SQLCHAR。

请参见

使用格式文件


前缀长度

当以本机格式将数据大容量复制到数据文件时，为使文件存储空间最为紧凑，bcp 将在每个字段前面使用一个或多个字符来表明字段的长度。这些字符称为长度前缀字符。所需长度前缀字符的数目称为前缀长度。

存储数据字段长度所需的长度前缀字符数目取决于文件存储类型、列的可为空性，以及数据是以其本机（数据库）数据类型还是作为 ASCII 字符（字符格式）存储在数据文件中。text 或 image 数据类型需要四个前缀字符存储字段长度，而 varchar 数据类型需要两个字符。

说明 这些长度前缀字符以 Microsoft® SQL Server™ 内部二进制数据格式存储在数据文件中。

当将空值从 SQL Server 实例复制到数据文件时，空值以空字段表示。为了表明该字段为空（表示 NULL），字段前缀值为 -1。任何允许空值的 SQL Server 列都需要字段前缀字符，并且根据文件存储类型的不同，需要的前缀长度为 1 或更大。

在将数据从 SQL Server 实例大容量复制到数据文件，并使用本机数据类型或作为 ASCII 字符（文本文件）存储数据时，请使用以下前缀长度。

SQL Server | 本机格式 |  | 字符格式
数据类型 | NOT NULL | NULL | NOT NULL | NULL
char | 2 | 2 | 2 | 2
varchar | 2 | 2 | 2 | 2
nchar | 2 | 2 | 2 | 2
nvarchar | 2 | 2 | 2 | 2
text | 4 | 4 | 4 | 4
ntext | 4 | 4 | 1 | 1
binary | 1 | 1 | 2 | 2
varbinary | 1 | 1 | 2 | 2
image | 4 | 4 | 4 | 4
datetime | 0 | 1 | 1 | 1
smalldatetime | 0 | 1 | 1 | 1
decimal | 1 | 1 | 1 | 1
numeric | 1 | 1 | 1 | 1
float | 0 | 1 | 1 | 1
real | 0 | 1 | 1 | 1
int | 0 | 1 | 1 | 1
bigint | 0 | 1 | 1 | 1
smallint | 0 | 1 | 1 | 1
tinyint | 0 | 1 | 1 | 1
money | 0 | 1 | 1 | 1
smallmoney | 0 | 1 | 1 | 1
bit | 0 | 1 | 0 | 1
uniqueidentifier | 1 | 1 | 1 | 1
timestamp | 1 | 1 | 2 | 2

如果将数据存储为 nchar 而不是 char，则所有数据类型的前缀长度都将与本机数据类型的长度值相同，但 char、varchar、text、ntext 和 image 除外，这些数据类型的前缀长度都为 1。

如果将数据大容量复制到 SQL Server 实例，则前缀长度是最初创建数据文件时指定的值。如果数据文件不是使用 bcp 创建的，则不大可能存在长度前缀字符。在这种情况下，将前缀长度指定为 0。

说明 提示中提供的默认值表示最有效率的前缀长度。


字段长度

以前缀长度 0 从 Microsoft® SQL Server™ 大容量复制 char、nchar 或 binary 数据时，bcp 还会提示输入字段长度。字段长度表明以字符格式表示数据所需的最大字符数。tinyint 类型的列中的值可以从 0 到 255；表示该范围内任意数字所需的最大字符数是三（用于表示 100 到 255 之间的值）。当 bcp 将非字符数据转换为字符数据时，会建议一个足以存储该数据的默认字段长度。

如果文件存储类型为非字符，数据将以 SQL Server 本机数据表示法（本机格式）存储，而 bcp 实用工具将不提示输入字段长度。

以下是要存储为 char 文件存储类型的数据的默认字段长度（可为空数据与非空数据的长度相同）。

数据类型 | 默认长度（字符数）
Char | 定义的列长度
Varchar | 定义的列长度
Nchar | 定义的列长度的两倍
Nvarchar | 定义的列长度的两倍
Text | 0
Ntext | 0
Bit | 1
Binary | 定义的列长度的两倍 + 1
Varbinary | 定义的列长度的两倍 + 1
Image | 0
Datetime | 24
Smalldatetime | 24
Float | 30
Real | 30
Int | 12
Bigint | 19
Smallint | 7
Tinyint | 5
Money | 30
Smallmoney | 30
Decimal | 41*
Numemic | 41*
Uniqueidentifier | 37
Timestamp | 17

*有关 decimal 和 numeric 数据类型的更多信息，请参见 decimal 和 numeric。

以下是要存储为本机文件存储类型的数据的默认字段长度（可为空数据与非空数据的长度相同，而字符数据始终以字符格式存储）。

数据类型 | 默认长度（字符数）
bit | 1
binary | 定义的列长度
varbinary | 定义的列长度
image | 0
datetime | 8
smalldatetime | 4
float | 8
real | 4
int | 4
bigint | 8
smallint | 2
tinyint | 1
money | 8
smallmoney | 4
decimal | *
numeric | *
uniqueidentifier | 16
timestamp | 8

*有关 decimal 和 numeric 数据类型的更多信息，请参见 decimal 和 numeric。

建议接受字段长度的 bcp 默认值。

说明 使用默认数据类型大小（字段长度）可能导致"意外的文件结尾"错误信息。这种情况通常发生在使用 money 和 datetime 数据类型时，在数据文件中出现的只是字段的一部分（例如 mm/dd/yy 形式的 datetime 值中没有时间部分），而不是 SQL Server 所预期的整个字符串。使用默认大小选项时，SQL Server 预期读取 24 个字符（以 char 格式存储时的 datetime 数据类型长度）。若要避免此问题，请使用字段终止符或固定长度数据字段进行数据的大容量复制。

在大容量复制数据时，如果为数值型数据指定的字段长度过短，则会使 bcp 输出溢出消息并且不复制数据。将 datetime 数据复制到数据文件时，如果复制为少于 26 字节的字符串，数据将截断并且不显示任何错误信息。创建 ASCII 数据文件时，请使用默认的字段长度，以确保数据不会截断，并且不会因数字溢出而导致 bcp 失败。若要更改默认字段长度，请提供另一个值。

说明 若要创建日后要重新装载到 SQL Server 中的数据文件，并使存储空间保持最小，请使用长度前缀字符及默认文件存储类型，并使用默认的字段长度。

在数据文件中，为存储为 char 文件存储类型的非字符数据分配的存储空间量也取决于是否指定了前缀长度或终止符：

  • 如果指定前缀长度为 1、2 或 4，则不使用字段长度。所用的数据文件存储空间是数据长度、前缀长度加上所有终止符的长度。

  • 如果指定前缀长度为 0 并且无终止符，则 bcp 将分配显示在字段长度提示中的最大空间量，因为该值是所述的数据类型可能需要的最大空间。该字段将视为固定长度的字段，因此确定一个字段的结束位置和下一个字段的开始位置是可能的。

  • 如果指定前缀长度为 0 并指定了终止符，则会忽略指定的字段长度。使用的数据文件存储空间是数据的长度加上所有终止符。

在数据文件中，SQL Server char 数据始终存储为定义的列的全长。例如，定义为 char(10) 的列总是在数据文件中占用 10 个字符，无论存储在该列中的数据长度如何；不足的部分将用空格来填充。有关更多信息，请参见 SET ANSI_PADDING。

数据的前缀长度 (P)、终止符 (T) 和数据的字段长度的相互作用决定了数据文件中所用的存储空间。在下面的示例中，每列的字段长度为 8，每次存储 6 个字符的值 "string"。破折号 (-) 表示追加的空格，省略号 (...) 表示每个字段均重复该模式。

以下是 SQL Server char 数据的模式。

 | 前缀长度 = 0 | 前缀长度 = 1、2 或 4
无终止符 | string--string--... | Pstring--Pstring--...
终止符 | string--Tstring--T... | Pstring--TPstring--T...

以下是转换为 char 存储的其它数据类型的模式。

 | 前缀长度 = 0 | 前缀长度 = 1、2 或 4
无终止符 | string--string--... | PstringPstring...
终止符 | stringTstringT... | PstringTPstringT...


字段终止符

可以使用可选的终止符标记字段或行的结束，分隔数据文件中相邻的字段或行。终止符为读取数据文件的程序指出一个字段或行的结束位置和下一个字段或行的开始位置。bcp 实用工具的默认设置是在数据文件中各字段和行之间不使用终止符。

如果数据文件不包含以下部分，则需要字段终止符：

  • 表示每个字段长度的长度前缀（或者当读取数据文件的程序不理解长度前缀时，也需要终止符）。

  • 固定长度的数据字段（或者当需要使存储空间减至最小时，也需要终止符）。

bcp 实用工具允许使用多种字符作为字段终止符或行终止符。

终止符 | 表示方法
制表符 | \t
换行符 | \n
回车 | \r
反斜杠 | \\
空终止符（不可见终止符） | \0
任何可打印的字符（控制字符是不可打印的，除空值、制表符、换行符和回车之外） | （*、A、t、l 等）
最长可达 10 个可打印字符的字符串，包括上面列出的部分或全部终止符 | （**\t**、end、!!!!!!!!!!、\t--\n 等）

说明 只有 t、n、r、\ 和 0 字符可以与反斜杠转义符一同使用以生成控制字符。

可以使用 bcp 的 -t 和 -r 开关更改默认的字段终止符和行终止符。当使用这些开关时，在交互式 bcp 提示的方括号中列出的所有字段和行的默认值都将更改为命令提示符下指定的值。可用 -t 更改默认的字段终止符，可用 -r 更改默认的行终止符。

若要将默认的字段终止符更改为逗号 (,)，而将默认的行终止符更改为换行符 (\n)，可以使用以下命令：

bcp pubs..publishers out publ.txt -t , -r \n -Sservername -Usa -Ppassword

重要 所选的终止符必须确保终止符的模式不会出现在任何数据中。例如，如果字段中的数据包含制表符，对该字段使用制表符终止符，则 bcp 将无法了解哪个制表符代表字段的结束。bcp 实用工具总是搜索与预期的终止符匹配的第一个可能的字符。使用数据中不存在的字符序列可以避免这一冲突。

本机格式的数据文件也可能和终止符冲突，因为此文件以 SQL Server 内部二进制数据格式存储。使用本机格式时，请使用长度前缀而不要使用字段终止符。

对于大容量复制操作，任何包含空值的数据列都看作是可变长度的。因此，需要用长度前缀或字段终止符指定每个字段的长度。

说明 无终止符和空终止符 (\0) 的值不同。无终止符值不会放置任何行终止符。空终止符值在列的后面放置一个空字符。空字符虽不可见，但实际存在。

因为 bcp 不提示输入行终止符，所以每行最后一列的字段终止符将用作行终止符。对于包含 10 列的行，第 10 列的字段终止符也是行终止符。因此，最后一个字段的终止符可以（但并非必须）与同一行中其它字段使用的字段终止符不同。对于表格格式的输出，可用换行符 (\n) 终止最后一个字段，而所有其它字段均用制表符 (\t) 终止。

在将 SQL Server 数据导出到 ASCII 数据文件时，常用的行终止符为 \r\n（回车、换行符）。同时使用这两个字符作为行终止符，可以确保数据文件中每一行数据都单独显示在一行中。但是，只有手工编辑 bcp 格式文件的终止符列时，才有必要输入字符 \r\n 作为终止符。交互使用 bcp 并指定 \n（换行符）作为行终止符时，bcp 自动加入 \r（回车）作为前缀。

请参见

ColumnDelimiter 属性

RowDelimiter 属性


使用格式文件

使用交互模式大容量复制数据时，bcp 实用工具会提示您存储有关存储类型、前缀长度、字段长度以及字段终止符和行终止符的信息。用来存储数据文件中每个字段的格式信息的文件称为格式文件：

Do you want to save this format information in a file? [Y/n] y
Host filename: [bcp.fmt]

尽管格式文件的默认名称为 Bcp.fmt，但也可以指定其它文件名。

当将数据文件中的数据大容量复制回 Microsoft® SQL Server™ 实例，或在其它时间从表中向外大容量复制数据时，可以使用该格式文件提供默认的信息，而不必重新指定格式。使用现有的格式文件将数据大容量复制到 SQL Server 实例或从 SQL Server 实例中向外复制数据时，bcp 不会提示输入文件存储类型、前缀长度、字段长度以及字段终止符，因为 bcp 使用已经记录的值。

将数据导入 SQL Server 实例时，若要使用以前创建的格式文件，请使用 bcp 实用工具的 -f 开关，或 BULK INSERT 语句的 FORMATFILE 子句。例如，若要使用以前创建的格式文件 (Authors.fmt) 将 New_auth.dat 数据文件中的内容大容量复制到 pubs 数据库的 authors2 表中，可以使用以下命令：

bcp pubs..authors2 in c:\new_auth.dat -fc:\authors.fmt -Sservername -Usa -Ppassword

BULK INSERT 语句可以使用 bcp 实用工具保存的格式文件。例如：

BULK INSERT pubs..authors2 FROM 'c:\new_auth.dat'
WITH (FORMATFILE = 'c:\authors.fmt')

格式文件是具有特殊结构的以制表符分隔的文本文件。

下表描述文件格式结构。

字段 | 描述
版本 | bcp 的版本号。
字段数目 | 数据文件中字段的数目。此数目必须对所有行都相同。
宿主文件字段顺序 | 数据文件中每个字段的位置。行中的第一个字段为 1，依此类推。
宿主文件数据类型 | 数据文件的特定字段中存储的数据类型。对于 ASCII 数据文件，使用 SQLCHAR；对于本机格式数据文件，使用默认的数据类型。有关更多信息，请参见文件存储类型。
前缀长度 | 字段长度前缀字符的数目。合法的前缀长度为 0、1、2 和 4。若要避免指定长度前缀，请将其设置为 0。如果字段中包含空值，则必须指定长度前缀。有关更多信息，请参见前缀长度。
宿主文件数据长度 | 数据文件的特定字段中所存储的数据类型的最大长度（按字节计）。有关更多信息，请参见字段长度。
终止符 | 用来分隔数据文件中各字段的分隔符。常用的终止符为逗号 (,)、制表符 (\t) 和行结束符 (\r\n)。有关更多信息，请参见字段终止符。
服务器列顺序 | 各列在 SQL Server 表中出现的顺序。例如，如果数据文件中的第四个字段映射为 SQL Server 表中的第六列，则第四个字段的服务器列顺序为 6。 在接收数据文件中的数据时，若要忽略表中的某个列，请将服务器列顺序值设置为 0。
服务器列名 | 从 SQL Server 表中获取的列名。不必使用字段的实际名称。唯一的条件就是格式文件中的该字段不为空。
排序规则 | 排序规则用于在大容量复制数据文件中存储字符和 Unicode 数据。

说明 如果数据文件中不存在某个字段，可通过将前缀长度、字段长度、服务器列顺序都指定为 0，并且指定无终止符，在向表中导入列时跳过该列。这种方法实际上表明数据文件中不存在该数据字段，服务器列不应装载其数据。

有选择地复制数据

格式文件提供了将数据文件中的数据有选择地大容量复制到 SQL Server 实例中的方法。这样，如果数据文件中的字段和表中的列之间存在不匹配时，仍允许向表中传输数据。当数据文件中的字段存在以下情况时，可以使用这种方法：

  • 数目少于表中的列数。

  • 数目多于表中的列数。

  • 与表中各列的顺序不同。

通过使用格式文件，可以将数据大容量复制到 SQL Server 实例中，而不必在数据文件中添加或删除不必要的数据或者重新排序数据文件中现有的数据。

随后的三个主题中包含有选择地复制数据的示例。为了执行随后的这些示例，需要首先在 pubs 数据库中制作 authors 表的一份复本，名为 authors2。若要制作一份 authors 表的复本，请执行以下命令：

USE pubs
GO
SELECT * INTO authors2 FROM authors
GO

请参见

FormatFilePath 属性


使用带有较少字段的数据文件

在某些情况下，数据文件包含的字段数可能少于表中的列数。例如，New_auth.dat 数据文件（ASCII 格式，即字符格式）不包含与 authors2 表中 address 和 zip 列匹配的字段。

New_auth.dat 文件的内容如下：

777-77-7777,Smith,Chris,303 555-1213,Denver,CO,1
888-88-8888,Doe,John,206 555-1214,Seattle,WA,0
999-99-9999,Door,Jane,406 555-1234,Bozeman,MT,1

若要将数据有选择地大容量复制到 authors2 的适当列中，请使用以下命令创建默认的格式文件（Authors.fmt）：

bcp pubs..authors2 out c:\authors.txt -Sservername -Usa -Ppassword

bcp 实用工具将提示输入 authors2 中每一列的文件存储类型、前缀长度、字段长度和字段终止符。每列的字段终止符均应为逗号 (,)，但 contract 列除外，该列应使用行终止符 \n（换行符），因为该列是行中的最后一列。另外，因为该数据文件为 ASCII 文件，所以 contract 列的文件存储类型是 char。address 和 zip 列不应有字段终止符，并且应将其字段长度设置为 0。在提示输入格式文件名时，请指定 Authors.fmt。

Authors.fmt 文件的内容如下：

8.0
9
1  SQLCHAR  0  11 ","      1  au_id       SQL_Latin1_General_Cp437_BIN
2  SQLCHAR  0  40 ","      2  au_lname    SQL_Latin1_General_Cp437_BIN
3  SQLCHAR  0  20 ","      3  au_fname    SQL_Latin1_General_Cp437_BIN
4  SQLCHAR  0  12 ","      4  phone       SQL_Latin1_General_Cp437_BIN
5  SQLCHAR  0  0  ""       5  address     SQL_Latin1_General_Cp437_BIN
6  SQLCHAR  0  20 ","      6  city        SQL_Latin1_General_Cp437_BIN
7  SQLCHAR  0  2  ","      7  state       SQL_Latin1_General_Cp437_BIN
8  SQLCHAR  0  0  ""       8  zip         SQL_Latin1_General_Cp437_BIN
9  SQLCHAR  0  1  "\r\n"   9  contract    SQL_Latin1_General_Cp437_BIN

该格式文件包含将数据从数据文件大容量复制到 Microsoft® SQL Server™ 表所需的全部信息。address 和 zip 的前缀长度为 0、字段长度为 0 且没有字段终止符，这表明数据文件中不存在这两列。但是，必须使用文本编辑器进一步修改格式文件，以确保不会将任何数据装载到 address 和 zip 中。这两列的服务器列号（格式文件中的第六个字段）应为 0：

8.0
9
1  SQLCHAR  0  11 ","      1  au_id       SQL_Latin1_General_Cp437_BIN
2  SQLCHAR  0  40 ","      2  au_lname    SQL_Latin1_General_Cp437_BIN
3  SQLCHAR  0  20 ","      3  au_fname    SQL_Latin1_General_Cp437_BIN
4  SQLCHAR  0  12 ","      4  phone       SQL_Latin1_General_Cp437_BIN
5  SQLCHAR  0  0  ""       0  address     SQL_Latin1_General_Cp437_BIN
6  SQLCHAR  0  20 ","      6  city        SQL_Latin1_General_Cp437_BIN
7  SQLCHAR  0  2  ","      7  state       SQL_Latin1_General_Cp437_BIN
8  SQLCHAR  0  0  ""       0  zip         SQL_Latin1_General_Cp437_BIN
9  SQLCHAR  0  1  "\r\n"   9  contract    SQL_Latin1_General_Cp437_BIN

现在若要将该数据文件中的数据大容量复制到 authors2 中，可以使用以下命令：

bcp pubs..authors2 in c:\new_auth.dat -fc:\authors.fmt -Sservername -Usa -Ppassword

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..authors2 FROM 'c:\new_auth.dat'
WITH (FORMATFILE = 'c:\authors.fmt')

说明 因为数据文件中没有 address 和 zip 列，所以如果没有定义 DEFAULT 值，则 SQL Server 表中的这两列将包含 NULL。因此，authors2 必须允许这两列中包含空值。


使用带有较多字段的数据文件

在某些情况下，数据文件包含的字段数可能多于表中的列数。例如，New_auth.dat 数据文件（ASCII 格式，即字符格式）包含 authors2 表中不包含的两个字段（age 和 salutation）。这两个字段将在大容量复制过程中忽略（即跳过）。

New_auth.dat 文件的内容如下：

777-77-7777,Smith,Chris,303 555-1213,27 College Ave,Denver,CO,80220,1,28,Ms.
888-88-8888,Doe,John,206 555-1214,123 Maple Street,Seattle,WA,95099,0,35,Mr.
999-99-9999,Door,Jane,406 555-1234,45 East Main,Bozeman,MT,59715,1,33,Mrs.

若要有选择地只将所需数据大容量复制到 authors2 的适当列中，请使用以下命令创建默认的格式文件 (Authors.fmt)：

bcp pubs..authors2 out c:\authors.txt -Sservername -Usa -Ppassword

bcp 实用工具将提示输入 authors2 中每一列的文件存储类型、前缀长度、字段长度和字段终止符。每列的字段终止符均应为逗号 (,)。另外，因为该数据文件为 ASCII 文件，所以 contract 列的文件存储类型是 char。在提示输入格式文件名时，请指定 Authors.fmt。

Authors.fmt 文件的内容如下：

8.0
9
1  SQLCHAR  0  11 ","      1  au_id       SQL_Latin1_General_Cp437_BIN
2  SQLCHAR  0  40 ","      2  au_lname    SQL_Latin1_General_Cp437_BIN
3  SQLCHAR  0  20 ","      3  au_fname    SQL_Latin1_General_Cp437_BIN
4  SQLCHAR  0  12 ","      4  phone       SQL_Latin1_General_Cp437_BIN
5  SQLCHAR  0  40 ","      5  address     SQL_Latin1_General_Cp437_BIN
6  SQLCHAR  0  20 ","      6  city        SQL_Latin1_General_Cp437_BIN
7  SQLCHAR  0  2  ","      7  state       SQL_Latin1_General_Cp437_BIN
8  SQLCHAR  0  5  ","      8  zip         SQL_Latin1_General_Cp437_BIN
9  SQLCHAR  0  1  "\r\n"   9  contract    SQL_Latin1_General_Cp437_BIN

该格式文件包含将数据从数据文件大容量复制到 Microsoft® SQL Server™ 表所需的全部信息。但是，需要使用文本编辑器进一步修改格式文件，以反映新添加的两列：age 和 salutation。格式文件的第二行指定了列数，该列数现在应改为 11，因为数据文件中有 11 个字段。需要在格式文件的末尾添加两个新行，以便提供新增字段的格式信息。行终止符需要从 contract 列移到 salutation 列，age 和 salutation 列的服务器列号（格式文件中的第六个字段）应为 0：

8.0
11
1  SQLCHAR  0  11 ","      1  au_id       SQL_Latin1_General_Cp437_BIN
2  SQLCHAR  0  40 ","      2  au_lname    SQL_Latin1_General_Cp437_BIN
3  SQLCHAR  0  20 ","      3  au_fname    SQL_Latin1_General_Cp437_BIN
4  SQLCHAR  0  12 ","      4  phone       SQL_Latin1_General_Cp437_BIN
5  SQLCHAR  0  40 ","      5  address     SQL_Latin1_General_Cp437_BIN
6  SQLCHAR  0  20 ","      6  city        SQL_Latin1_General_Cp437_BIN
7  SQLCHAR  0  2  ","      7  state       SQL_Latin1_General_Cp437_BIN
8  SQLCHAR  0  5  ","      8  zip         SQL_Latin1_General_Cp437_BIN
9  SQLCHAR  0  1  ","      9  contract    SQL_Latin1_General_Cp437_BIN
10 SQLCHAR  0  0  ","      0  age         SQL_Latin1_General_Cp437_BIN
11 SQLCHAR  0  0  "\r\n"   0  salutation  SQL_Latin1_General_Cp437_BIN

现在若要将该数据文件中的数据大容量复制到 authors2 中，可以使用以下命令：

bcp pubs..authors2 in c:\new_auth.dat -fc:\authors.fmt -Sservername -Usa -Ppassword

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..authors2 FROM 'c:\new_auth.dat'
WITH (FORMATFILE = 'c:\authors.fmt')


使用字段顺序不同的数据文件

在某些情况下，数据文件中包含的字段与表中对应列的顺序可能不同。例如，New_auth.dat 数据文件（ASCII 格式，即字符格式）与 authors2 表包含相同的字段数，但是 au_lname 和 au_fname 字段的次序相反。这两个字段在大容量复制过程中将重新排序。

New_auth.dat 文件的内容如下：

777-77-7777,Chris,Smith,303 555-1213,27 College Ave,Denver,CO,80220,1
888-88-8888,John,Doe,206 555-1214,123 Maple Street,Seattle,WA,95099,0
999-99-9999,Jane,Door,406 555-1234,45 East Main,Bozeman,MT,59715,1

若要将数据有选择地大容量复制到 authors2 的适当列中，请使用以下命令创建默认的格式文件 (Authors.fmt)：

bcp pubs..authors2 out c:\authors.txt -Sservername -Usa -Ppassword

bcp 实用工具将提示输入 authors2 中每一列的文件存储类型、前缀长度、字段长度和字段终止符。每列的字段终止符均应为逗号 (,)，但 contract 列除外，该列应使用行终止符 \n（换行符），因为该列是行中的最后一列。另外，因为该数据文件为 ASCII 文件，所以 contract 列的文件存储类型是 char。在提示输入格式文件名时，请指定 Authors.fmt。

Authors.fmt 文件的内容如下：

8.0
9
1  SQLCHAR  0  11 ","      1  au_id       SQL_Latin1_General_Cp437_BIN
2  SQLCHAR  0  40 ","      2  au_lname    SQL_Latin1_General_Cp437_BIN
3  SQLCHAR  0  20 ","      3  au_fname    SQL_Latin1_General_Cp437_BIN
4  SQLCHAR  0  12 ","      4  phone       SQL_Latin1_General_Cp437_BIN
5  SQLCHAR  0  40 ","      5  address     SQL_Latin1_General_Cp437_BIN
6  SQLCHAR  0  20 ","      6  city        SQL_Latin1_General_Cp437_BIN
7  SQLCHAR  0  2  ","      7  state       SQL_Latin1_General_Cp437_BIN
8  SQLCHAR  0  5  ","      8  zip         SQL_Latin1_General_Cp437_BIN
9  SQLCHAR  0  1  "\r\n"   9  contract    SQL_Latin1_General_Cp437_BIN

该格式文件包含将数据从数据文件大容量复制到 Microsoft® SQL Server™ 表所需的全部信息。不过，但是，需要使用文本编辑器进一步修改格式文件，以更改 au_lname 和 au_fname 字段的服务器列顺序（格式文件中的第六个字段）。

8.0
9
1  SQLCHAR  0  11 ","      1  au_id       SQL_Latin1_General_Cp437_BIN
2  SQLCHAR  0  40 ","      3  au_lname    SQL_Latin1_General_Cp437_BIN
3  SQLCHAR  0  20 ","      2  au_fname    SQL_Latin1_General_Cp437_BIN
4  SQLCHAR  0  12 ","      4  phone       SQL_Latin1_General_Cp437_BIN
5  SQLCHAR  0  40 ","      5  address     SQL_Latin1_General_Cp437_BIN
6  SQLCHAR  0  20 ","      6  city        SQL_Latin1_General_Cp437_BIN
7  SQLCHAR  0  2  ","      7  state       SQL_Latin1_General_Cp437_BIN
8  SQLCHAR  0  5  ","      8  zip         SQL_Latin1_General_Cp437_BIN
9  SQLCHAR  0  1  "\r\n"   9  contract    SQL_Latin1_General_Cp437_BIN

现在若要将该数据文件中的数据大容量复制到 authors2 中，可以使用以下命令：

bcp pubs..authors2 in c:\new_auth.dat -fc:\authors.fmt -Sservername -Usa -Ppassword

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..authors2 FROM 'c:\new_auth.dat'
WITH (FORMATFILE = 'c:\authors.fmt')


复制数据

使用 bcp 或 BULK INSERT 复制数据有以下六种方式：

主题 | 描述
在服务器间复制数据 | 描述在 Microsoft® SQL Server™实例之间复制数据时使用哪种数据格式。
将数据从数据文件复制到 SQL Server | 描述如何将数据从数据文件复制到 SQL Server 实例，包括如何处理标识值和 image 数据。
将数据从查询复制到数据文件 | 描述如何将结果集从 Transact SQL 语句复制到数据文件。
向临时表复制数据或从临时表向外复制数据 | 描述如何向临时表复制数据或从临时表向外复制数据。
向（或从）视图中复制数据 | 描述如何向视图复制数据或从视图向外复制数据。
在不同排序规则间复制数据 | 描述如何在不同排序规则间复制数据，包括列级排序规则的用法。


在服务器间复制数据

若要将数据从一个 Microsoft® SQL Server™ 数据库大容量复制到另一个，必须首先将源数据库中的数据大容量复制到某个文件。然后将该文件大容量复制到目的数据库。

将数据大容量复制到表中后，如果恢复模式是简单模式，则建议使用完整备份或差异备份。如果恢复模式是大容量日志记录模式或完整模式，使用日志备份就足够了。

说明 本机、字符和 Unicode 格式 bcp 可用于在不同处理器构架上运行的不同 SQL Server 实例之间大容量复制数据。然而，导入和导出必须使用相同的格式。

如果必须将信息从一个 SQL Server 实例复制到另一个，则以 Unicode 本机格式存储信息会非常有用。对非字符数据使用本机格式可以节省时间，避免在各数据类型与字符格式之间进行不必要的转换。在使用不同代码页的服务器之间大容量装载数据时，对所有字符数据使用 Unicode 字符格式可以防止丢失任何扩展字符（将扩展字符复制到非 Unicode 列时，如果无法表示这些扩展字符，则可能会丢失字符）。但是，除 bcp 和 BULK INSERT 语句之外的其它任何程序都不能读取 Unicode 本机格式的数据文件。

也可以使用以下方法在 SQL Server 数据库之间复制数据：

  • DTS 导入/导出向导。

  • Transact-SQL 语句 BACKUP 和 RESTORE（复制整个数据库）。

  • 作为 INSERT 语句一部分的分布式查询。

  • SELECT INTO 语句。

请参见

BACKUP

分布式查询

DTS 导入/导出向导

INSERT

优化大容量复制性能

RESTORE

SELECT

Unicode 字符格式


将数据从数据文件复制到 SQL Server

若要将数据文件大容量复制到 Microsoft® SQL Server™ 实例，请遵循以下准则：

  • 将数据大容量复制到没有索引的表中时，如果在通常情况下使用完整恢复模式，则将恢复模式设置为大容量日志记录模式。

    这是推荐的方法，因为日志不记录行插入操作，所以有助于防止事务日志耗尽空间。系统管理员或数据库所有者可以设置此选项。有关更多信息，请参见有日志记录和最小日志记录的大容量复制操作。

  • 如果要装载的数据与表中已存在的数据相比数量较大，在执行大容量复制操作之前删除表的索引会提高大容量复制速度。

    反之，如果要装载的数据与表中已存在的数据相比数量较小，则不必删除索引，因为重建索引的时间可能比执行大容量复制操作的时间要长。有关更多信息，请参见优化大容量复制性能。

  • 确保用 bcp（或使用 BULK INSERT 语句时的查询工具）登录到 SQL Server 时所用的用户帐户对表具有 SELECT 和 INSERT 权限（由表的所有者指派）。

    说明 只有 sysadmin 固定服务器角色的成员可以执行 BULK INSERT 语句。

  • 如果恢复模式是简单模式，则建议使用完整备份或差异备份；如果恢复模式是大容量日志记录模式或完整恢复模式，使用日志备份就足够了。有关更多信息，请参见备份和还原操作。

  • 为了使用 bcp 实用工具或 BULK INSERT 语句将数据从数据文件成功地大容量复制到表中，必须了解并指定数据文件中的终止符。

说明 当试图将数据大容量复制到 SQL Server 实例中时，ASCII 数据文件中的隐藏字符可能导致问题，出现"发现意外的空值"错误信息。许多实用工具和文本编辑器可显示隐藏字符，通常可以在数据文件的底部找到这些字符。找到并删除这些字符可以解决此问题。

Newpubs.dat 文件为：

1111,Stone Age Books,Boston,MA,USA
2222   ,Harley & Davidson,Washington,DC,USA
3333   ,Infodata Algosystems,Berkeley,CA,USA

因为该数据文件均为字符数据，所以需要指定以下选项和开关。

大容量复制选项 | bcp 实用工具开关 | BULK INSERT 子句
字符模式格式 | -c | DATAFILETYPE = 'char'
字段终止符 | -t | FIELDTERMINATOR
行终止符 | -r | ROWTERMINATOR

在 Newpubs.dat 文件中，行中每个字段均以逗号 (,) 结束，而每行均以换行符 (\n) 结束。

下例中的 publishers2 表可以通过执行以下命令创建：

USE pubs
GO
SELECT * INTO publishers2 FROM publishers
GO

若要将数据从 Newpubs.dat 大容量复制到 publishers2，可以使用以下命令：

bcp pubs..publishers2 in newpubs.dat -c -t , -r \n -Sservername -Usa -Ppassword

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..publishers2 FROM 'c:\newpubs.dat'
WITH (
   DATAFILETYPE = 'char',
   FIELDTERMINATOR = ',',
   ROWTERMINATOR = '\n'
)

Newpubs.dat 文件中的数据现在已追加到 publishers2 中：

Pub_id | pub_name | city | state | Country
------ | ---------------- | ---------- | ----- | -----
0736 | New Moon Books | Boston | MA | USA
0877 | Binnet & Hardley | Washington | DC | USA
1111 | Stone Age Books | Boston | MA | USA
1389 | Algodata Infosystems | Berkeley | CA | USA
1622 | Five Lakes Publishing | Chicago | IL | USA
1756 | Ramona Publishers | Dallas | TX | USA
2222 | Harley & Davidson | Washington | DC | USA
3333 | Infodata Algosystems | Berkeley | CA | USA
9901 | GGG&G | München |  | Germany
9952 | Scootney Books | New York | NY | USA
9999 | Lucerne Publishing | Paris |  | France

复制包含标识值的数据

bcp 实用工具和 BULK INSERT 语句允许将包含标识值的数据文件大容量复制到 SQL Server 实例中。为防止 SQL Server 提供标识值，bcp 实用工具接受 -E 开关，并且 BULK INSERT 语句接受 KEEPIDENTITY 子句。当数据文件中的行大容量复制到表中时，SQL Server 不会自动地指派唯一标识值；标识值将从数据文件中获得。

如果未提供这些选项，则将忽略被导入数据文件中标识符列的值，而是由 SQL Server 根据表创建期间指定的种子值和增量值自动指派唯一值。如果数据文件不包含表中标识符列的值，则使用格式文件指定导入数据时应跳过的标识符列。SQL Server 自动赋给该列唯一值。

导入 image 数据

可以将数据文件作为 image 数据大容量复制到 SQL Server 实例中。使用 bcp 实用工具将数据文件 Test.doc 装载到 pubs 数据库的 bitmap 表中的命令是：

bcp pubs..bitmap in test.doc -Usa -Ppassword -Sservername

bcp 将提示：

Enter the file storage type of field c1 [image]:
Enter the prefix length of field c1 [4]: 0
Enter length of field c1 [4096]: 5578
Enter the field terminator [none]:

在该示例中，数据文件将装载到列 c1，而 5578 是数据文件的长度。

使用 BULK INSERT 语句时，需要首先创建格式文件，然后用该文件提供格式信息。若要创建格式文件，请使用 bcp 实用工具：

bcp pubs..bitmap out c:\bitmap.txt -Sservername -Usa -Ppassword

bcp 实用工具提示输入 bitmap 中每一列的文件存储类型、前缀长度、字段长度和字段终止符。下表列出了 c1 列的值。

提示 | 值
文件存储类型 | Image
前缀长度 | 0
字段长度 | 5578
字段终止符 | 无

Bcp.fmt 文件的内容如下：

8.0
1
1   SQLIMAGE   0   5578      ""      1   c1

使用 BULK INSERT 语句将 Test.doc 数据文件大容量复制到 pubs 数据库的 bitmap 表中时，请从 SQL 查询分析器这样的查询工具中执行：

BULK INSERT pubs..bitmap FROM 'c:\test.doc'
WITH (
   FORMATFILE = 'c:\Bcp.fmt'
)

说明 不能将数据大容量复制到含有 DEFAULT 值的 text、ntext 和 image 列中。

请参见

bcp 实用工具

BULK INSERT。

ImportData 方法

IncludeIdentityValues 属性

SuspendIndexing 属性

UseBulkCopyOption 属性

使用带有较少字段的数据文件


将数据从查询复制到数据文件

bcp 实用工具使您得以将 Transact-SQL 语句的结果集复制到数据文件中。该 Transact-SQL 语句可以是任何可返回结果集的有效语句，例如分布式查询或联接多个表的 SELECT 语句。例如，若要将所有作者的姓名从 pubs 数据库的 authors 表复制到 Authors.txt 文件，并按姓氏排序，可在命令提示符下执行以下命令：

bcp "SELECT au_fname, au_lname FROM pubs..authors ORDER BY au_lname" queryout Authors.txt -c -Sservername -Usa -Ppassword

如果要确保数据的原有顺序在数据文件中得以保留，则应从查询大容量复制数据；从表或视图大容量复制数据时，不能保证数据写入数据文件的顺序。在数据文件中保留数据顺序使您得以在将数据从数据文件大容量复制回表中时，可以利用 ORDER 提示。使用 ORDER 提示可以显著提高大容量复制的性能。有关更多信息，请参见优化大容量复制性能。

如果 Transact-SQL 语句返回多个结果集（例如指定 COMPUTE 子句的 SELECT 语句，或执行包含多个 SELECT 语句的存储过程），则只复制第一个结果集而忽略随后的结果集。

请参见

bcp 实用工具

有序数据文件


向临时表复制数据或从临时表向外复制数据

使用 bcp 或 BULK INSERT 大容量复制全局临时表的数据时，必须在命令提示符下指定该表名，包括开头的数字符号 (##)。例如，若要将数据从全局临时表 ##temp_authors 大容量复制到 Temp_authors.txt 数据文件，请在命令提示符下执行以下命令：

bcp ##temp_authors out temp_authors.txt -c -Sservername -Usa -Ppassword

但是，使用全局临时表时不要指定数据库名，因为临时表仅存在于 tempdb 中。只有在使用 BULK INSERT 语句大容量复制数据时，才有可能使用局部临时表（例如 #temp_authors）。


向（或从）视图中复制数据

数据可以大容量复制到视图或从视图向外大容量复制。这包括从多个联接的表中复制数据，添加 WHERE 子句，或进行特殊的格式设置（例如使用 CONVERT 函数更改数据格式）。例如，若要将数据从 pubs 数据库的视图 titleview 复制到 Titleview.txt 数据文件，请在命令提示符下执行以下命令：

bcp pubs..titleview out titleview.txt -c -Sservername -Usa -Ppassword

若要使用 bcp 或 BULK INSERT 语句将数据大容量复制到视图中，应遵循将数据插入视图的规则。

说明 将数据大容量复制到视图中时将插入 NULL 值，即使已为字段定义了默认值。

请参见

通过视图修改数据


在不同排序规则间复制数据

当使用本机或字符格式大容量复制数据时，默认情况下，bcp 将字符数据转换为：

  • OEM 代码页字符（当从 Microsoft® SQL Server™ 实例导出数据时）。

  • ANSI/Microsoft Windows® 代码页字符（当将数据导入 SQL Server 实例时）。

这可能导致在 OEM 和 ANSI 代码页之间的转换过程中丢失扩展字符或 DBCS 字符。为了防止扩展字符或 DBCS 字符的丢失，bcp 可以使用以下格式创建数据文件：

  • Unicode 本机数据格式 (-N)。

  • Unicode 字符格式 (-w)。

  • 特定的代码页 (-C)。

在大容量复制过程中，Unicode 本机格式和 Unicode 字符格式将字符数据转换为 Unicode，这样不会导致扩展字符的丢失。

通过使用 -C（代码页）开关，bcp 实用工具可以使用由用户指定的代码页创建或读取数据文件。例如，若要使用代码页 850 将 pubs 数据库中的 authors2 表大容量复制到 Authors.txt 数据文件，请在命令提示符下执行：

bcp pubs..authors2 out authors.txt -c -C850 -Sservername -Usa -Ppassword

另外，使用 CODEPAGE 子句，BULK INSERT 语句也可以使用由用户指定的代码页读取数据文件。例如，若要使用代码页 850 将 Authors.txt 数据文件大容量复制到 pubs 数据库的 authors2 表中，可从 SQL 查询分析器这样的查询工具中执行：

BULK INSERT pubs..authors2 FROM 'c:\authors.txt'
WITH (
   CODEPAGE = 850
)

下面是代码页的有效值。

代码页值 | 描述
ACP | 将数据导入 SQL Server 实例时，数据类型为 char、varchar 或 text 的列从 ANSI/Windows 代码页 (ISO 1252) 转换为 SQL Server 代码页，从 SQL Server 实例导出数据时相反。
OEM（默认值） | 将数据导入 SQL Server 实例时，数据类型为 char、varchar 或 text 的列从系统 OEM 代码页转换为 SQL Server 代码页，从 SQL Server 实例导出数据时相反。
RAW | 这是最快的选项，因为不会发生从一个代码页到另一个代码页的转换。
<值> | 特定的代码页号码，例如 850。

列级排序规则

在 SQL Server 2000 中，可以为大容量复制操作指定列级排序规则。这些排序规则定义字符和 Unicode 数据如何存储在数据文件中指定的列内。

用户和应用程序只需指定在数据文件中存储数据的排序规则。大容量复制组件内部执行所需的数据文件排序规则和数据库中的源或目的列的排序规则之间的转换。

在向外大容量复制操作中，列和默认排序规则说明定义了用于在大容量复制结果数据文件中生成所有 SQLCHAR 数据的代码页。在向内大容量复制操作中，列和默认排序规则说明定义了用于从源数据文件读取 SQLCHAR 数据的代码页。

如果在向内大容量复制操作中指定了 SORTED 提示，则在 SORTED 提示中所引用的任意字符和 Unicode 列上所定义的排序规则将定义预期的数据序列。

在向内大容量复制操作中，必须确保所作出的排序规则说明符合大容量复制数据文件中给出的排序规则。

SQL Server 2000 中的格式文件支持第八列，在其中可以提供排序规则说明，以定义如何将该列的数据存储在数据文件中：

  • "RAW" 指定数据按 –C 开关、BCPFILECP 提示或 CODEPAGE 选项中指定的排序规则存储。如果这些均未指定，则数据文件的排序规则就是大容量复制客户计算机的 OEM 代码页中的排序规则。

  • "name" 指定将数据存储到数据文件中时所用排序规则的名称。

  • "" 与 RAW 含义相同。

以下是指定了列排序规则的格式文件示例：

8.0
5
1  SQLCHAR  0   4  "/t" pub_id   1   "SQL_LATIN1_General_Cp1_CI_AS_KI_WI"
2  SQLCHAR  0  40  "/t" pub_name 2   "SQL_LATIN1_General_Cp850_BIN"
3  SQLCHAR  0  20  "/t" city     3   "RAW"
4  SQLCHAR  0   2  "/t" state    4   "RAW"
5  SQLCHAR  0  30  "/t" country  5   ""

对于没有将 SQLCHAR 或 SQLNCHAR 指定为其宿主数据类型的列，将忽略其列排序规则说明。在向外大容量复制操作中将忽略 SQLNCHAR 列的排序规则，它们只适用于在 SORTED 提示中引用了 SQLNCHAR 列的向内大容量复制操作。排序规则对向内和向外操作中的 SQLCHAR 列都会应用。

在向外大容量复制操作中，排序规则说明只控制用于在大容量复制数据文件中存储字符数据的代码页。它将应用于：

  • 字符模式数据文件中的所有列。

  • 本机模式文件中所有将 SQLCHAR 指定为宿主文件数据类型的列。

  • 值大于 127 或小于 32 的SQLCHAR 字符。排序规则将应用到值在 32 和 127 之间的字符，但是所有代码页都将相同的字符映射为 32 至 127 之间的值，因此应用不同的排序规则没有明显的影响。

下列规则确定了何种排序规则用于向外大容量复制：

  • 如果用格式文件或 bcp_setcolfmt 指定了排序规则，则将使用与该排序规则相关联的 ANSI 代码页存储字符数据。这将替代指定排序规则的所有其它方法。

  • 如果没有指定列排序规则，但是指定了 bcp –C 开关或 bcp_control BCPFILECP 提示，则将使用 BCPFILECP 或 –C 所指定的代码页存储没有列排序规则说明的列中的所有 SQLCHAR 数据。在没有格式文件的情况下生成字符模式数据文件时，将不为任何列指定列排序规则。当列排序规则指定为 "" 或 "RAW" 时，也适用此规则。

  • 如果根本没有指定任何排序规则（没有列排序规则说明，没有 –C 开关，也没有 BCPFILECP 提示），则使用大容量复制客户计算机的 OEM 代码页存储 SQLCHAR 数据。

在向内大容量复制操作中，排序规则说明将控制：

  • 大容量复制操作解释数据文件中 SQLCHAR 列代码页时试图采用的方式。

  • 大容量复制操作应用 ORDER 提示的方式。

对于向内大容量操作，代码页解释只应用于数据文件中存储为 SQLCHAR 的列。字符模式数据文件中的所有列都存储为 SQLCHAR。它还应用于用格式文件或 bcp_setcolfmt 指定为 SQLCHAR 的任意列：

  • 如果用格式文件或 bcp_setcolfmt指定了列排序规则，则将使用与指定的列排序规则相关联的 ANSI 代码页解释数据文件中的 SQLCHAR 数据。

  • 如果未指定列排序规则，但是使用 BULK INSERT CODEPAGE 选项、bcp –C 开关或 bcp_control BCPFILECP 提示指定了默认代码页，则使用 CODEPAGE、–C 或 BCPFILECP 中所指定的代码页解释 SQLCHAR 数据。

  • 如果用户没有指定任何排序规则（没有列排序规则、BULK INSERT CODEPAGE 选项、bcp –C 开关和 BCPFILECP 提示），则使用客户计算机的 OEM 代码页解释 SQLCHAR 列中的数据。

向内大容量复制操作还使用排序规则正确地解释 ORDER 大容量复制提示。这将应用到 SQLCHAR 和 SQLNCHAR 列中。SORTED 提示引用的列中的数据必须按照映射到这些列的排序规则所定义的序列排列。

请参见

bcp 实用工具

BULK INSERT。

SetCodePage 方法

Unicode 字符格式

Unicode 本机格式


大容量复制性能考虑

若要使大容量复制数据的速度尽可能快，应了解数据是如何复制的，以及可以使用哪些选项指定复制数据的方式。

主题 | 描述
查询处理器 | 描述 bcp 和 BULK INSERT 如何与查询处理器协同工作。
有日志记录和无日志记录的大容量复制操作 | 描述何时记录大容量复制操作以及如何执行无日志记录的大容量复制操作。
并行数据装载 | 描述以并行方式将数据从多个客户端大容量复制到单个表。
批处理开关 | 描述用于控制在大容量复制操作中使用的批处理大小的开关。
约束检查 | 描述如何指定是否在大容量复制操作期间检查约束。
有序数据文件 | 描述如何指定数据文件中的数据顺序。
回避 DEFAULT定义 | 描述如何回避目的表中指定的默认值。
控制锁定行为 | 描述如何指定在大容量复制操作期间使用的锁定行为。

请参见

优化大容量复制性能


查询处理器

bcp 实用工具与查询处理器协同工作，以将数据插入到 Microsoft® SQL Server™ 实例中。bcp 实用工具生成客户端 OLE DB 行集，发送到 SQL Server 并由查询处理器插入到表中。这样做的好处是：查询处理器可以计划并优化向 SQL Server 实例导入和从 SQL Server 实例导出数据的查询。此外，还可以优化索引维护、约束检查以及并行数据装载操作。BULK INSERT 语句与查询处理器协同工作，以将数据大容量复制到 SQL Server 实例中。

任何使用大容量复制 API 编写的程序均利用客户端 OLE DB 行集和 SQL Server 查询处理器插入数据。

请参见

大容量复制行集

约束检查

并行数据装载

查询处理器构架


有日志记录和最小日志记录的大容量复制操作

使用完整恢复模式时，所有由 bcp 执行的行插入操作都记录在事务日志中。如果数据量较大，会造成事物日志迅速写满。为了防止事务日志耗尽空间，当符合以下全部条件时，可以执行最小日志记录的大容量复制：

  • 恢复模式是简单模式或大容量日志记录模式。

  • 没有正在复制目标表。

  • 目标表没有任何触发器。

  • 目标表具有 0 行或没有索引。

  • 指定了 TABLOCK 提示。有关更多信息，请参见控制锁定行为。

任何不满足上述条件的到 Microsoft® SQL Server™ 实例的大容量复制都将记入日志。

在进行大容量复制操作前，如果在通常情况下使用完整恢复模式，则建议将恢复模式设置为大容量日志记录模式。这样可以防止大容量复制操作过多使用日志空间而可能写满日志。然而，即使使用大容量日志恢复模式，也将使用一些事务日志空间。可能需要在大容量复制操作期间创建事务日志备份以释放事务日志空间。

当要将大量的行大容量复制到带有索引的表中时，可以通过删除所有索引，执行大容量复制，然后再重新创建索引来提高速度。有关更多信息，请参见优化大容量复制性能。

说明 尽管在执行最小日志记录的大容量复制操作时，数据插入操作没有记录在事务日志中，但 SQL Server 仍会在每次为表分配新的扩展盘区时记录扩展盘区的分配。

请参见

BACKUP

sp_dboption

SuspendIndexing 属性

UseBulkCopyOption 属性


并行数据装载

Microsoft® SQL Server™ 允许使用 bcp 实用工具或 BULK INSERT 语句，以并行方式将数据从多个客户端大容量复制到单个表中。这样可以提高数据装载操作的性能。若要以并行方式将数据大容量复制到 SQL Server 实例中，请执行以下步骤：

  • 如果通常使用完整恢复模式，则将数据库设置为大容量日志记录恢复模式。

  • 指定 TABLOCK 提示。有关更多信息，请参见控制锁定行为。

  • 确保该表没有索引。

说明 如果应用程序（包括 bcp 实用工具）基于 SQL Server 6.5 版或更早版本提供的 DB-Library 客户端库，则不能参与向 SQL Server 实例进行的并行数据装载操作。只有使用基于 ODBC 或 SQL OLE DB 的 API 的应用程序才可以执行将数据并行装载到单个表中的操作。

数据从多个客户端大容量复制到单个表之后，所有需要创建的非聚集索引也可以并行创建，只需从不同的客户端同时创建每个非聚集索引即可。

说明 创建非聚集索引之前，应当首先从一个客户端创建表上的聚集索引。

请参见

bcp 实用工具

有日志记录和无日志记录的大容量复制操作

优化大容量复制性能


批处理开关

bcp 实用工具和 BULK INSERT 语句接受以下两个开关，使用户得以指定在大容量复制操作中发送给 Microsoft® SQL Server™ 的每个批处理的行数。

Bcp 实用工具开关 | BULK INSERT 子句
-b batch_size | BATCHSIZE = batch_size
-h "ROWS_PER_BATCH = bb" | ROWS_PER_BATCH = rows_per_batch

这两个开关的使用对数据插入操作如何记入日志有很大影响。

使用 -b 开关或 BATCHSIZE 子句

每一批行均作为单独的事务插入。如果因为某种原因，大容量复制操作尚未完成即终止，则只回滚当前的事务。例如，如果数据文件包含 1000 行，而使用的批处理大小为 100，SQL Server 会将该操作作为 10 个单独的事务来记录，每个事务将 100 行插入到目的表中。如果大容量复制操作在复制到 750 行时终止，SQL Server 回滚当前事务时只删除此前的 49 行。目的表中仍会包含前 700 行。

使用 ROWS_PER_BATCH

如果没有使用 -b 开关或 BATCHSIZE 子句，则将整个文件发送到 SQL Server，并将大容量复制操作视为单个事务。在这种情况下，ROWS_PER_BATCH 提示或 ROWS_PER_BATCH 子句可以用来提供估计的行数。SQL Server 根据批处理大小的值自动优化装载操作，从而优化性能。

说明 通常，批处理的大小越大，大容量复制操作的性能越好。使批处理的大小尽可能地大，尽管提示中的准确性并不重要。

如果因为某种原因，该操作尚未完成即终止，则将回滚整个事务，并且目的表中不会添加新行。

尽管数据文件中的所有行在一个批处理中复制到 SQL Server实例中，但 bcp 每发送 1000 行，就会显示"已将 1000 行发送到 SQL Server"的消息。该消息仅作为信息提供，使用任何大小的批处理均会出现该消息。

说明 以不同的批处理大小同时提供上述两个开关会生成错误信息。

将较大的数据文件大容量复制到 SQL Server 实例中时，在大容量复制尚未完成时，事务日志可能已经写满，即使不记录行插入操作而只是记录扩展盘区的分配。在这种情况下，需扩大事务日志，允许它自动增长或使用 -b 或 BATCHSIZE 开关执行大容量复制，并将恢复模式设置为简单模式。因为只能截断已提交的事务，所以如果没有使用 -b 开关，则此选项在大容量复制操作过程中将不释放空间；整个操作作为单个事务记入日志。

bcp 实用工具和 BULK INSERT 语句还分别接受 KILOBYTES_PER_BATCH 提示或 KILOBYTES_PER_BATCH 子句，它们可以用来指定批处理中大约包含的数据量（以 KB 为单位）。SQL Server 可根据该值的设置优化大容量装载操作。

将数据从 SQL Server 实例大容量复制到数据文件时，批处理大小不适用。

请参见

BACKUP

bcp 实用工具

BULK INSERT。

ImportRowsPerBatch 属性

优化大容量复制性能

sp_dboption


约束检查

bcp 实用工具和 BULK INSERT 语句分别接受 CHECK_CONSTRAINTS 提示和 CHECK_CONSTRAINT 子句，它们使用户得以指定在大容量装载过程中是否检查约束。

默认情况下，在大容量装载过程中忽略约束。这样可以提高大容量装载的性能，但是也使插入到表中的数据有侵犯现有约束的可能性。CHECK_CONSTRAINTS 指定在大容量装载过程中强制约束。这样会降低大容量装载的性能，但是可以确保插入的所有数据均不侵犯任何现有的约束。例如，若要将数据从 Authors.txt 数据文件大容量复制到 pubs 数据库的 authors2 表，并指定应强制所有约束，请在命令提示符下执行以下命令：

bcp pubs..authors2 in authors.txt -c -t, -Sservername -Usa -Ppassword -h "CHECK_CONSTRAINTS"

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..authors2 FROM 'c:\authors.txt'
WITH (
   DATAFILETYPE = 'char',
   FIELDTERMINATOR = ',',
   CHECK_CONSTRAINTS
)

当数据复制到表中时，将忽略该表上定义的所有触发器。

若要查明是否有违反约束或触发器的行，必须使用查询手工检查已复制的数据。将数据大容量复制到表中，然后运行测试约束或触发器条件的查询或存储过程，例如：

UPDATE pubs..authors2 SET au_fname = au_fname

尽管此查询不将数据更改为其它值，但使 Microsoft® SQL Server™ 将 au_fname 列中的每个值更新为自身的值。这样将导致测试所有的约束或触发器。

说明 默认情况下，尽管在不指定 CHECK_CONSTRAINTS 时大容量复制操作不会检查表的约束，但对于并发进行其它操作（例如 INSERT、UPDATE 或 DELETE），这些约束仍会起到应有的作用。

请参见

bcp 实用工具

BULK INSERT。

DBCC CHECKCONSTRAINTS


有序数据文件

bcp 实用工具和 BULK INSERT 语句分别接受 ORDER 提示和 ORDER 子句，它们使用户得以指定数据文件中的数据如何排序。尽管数据文件中的数据与表中的数据排序次序不必相同，但相同的排序可以提高大容量复制操作的性能。

表中数据的顺序由聚集索引确定。ORDER 提示或 ORDER 子句中列出的顺序和列必须匹配聚集索引中的各列，并且顺序相同，以便提高大容量复制操作的性能。

例如，若要将数据从 Authors.txt 数据文件大容量复制到 pubs 数据库的 authors2 表，并指定数据文件的 au_id 列以升序排序，请在命令提示符下执行以下命令：

bcp pubs..authors2 in authors.txt -c -t, -Sservername -Usa -Ppassword -h "ORDER (au_id ASC)"

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..authors2 FROM 'c:\authors.txt'
WITH (
   DATAFILETYPE = 'char',
   FIELDTERMINATOR = ',',
   ORDER (au_id ASC)
)

默认情况下，大容量复制操作假设数据文件未排序。

请参见

bcp 实用工具

BULK INSERT

优化大容量复制性能


回避 DEFAULT定义

bcp 实用工具接受 -k 开关，BULK INSERT 语句接受 KEEPNULLS 子句，它们可以用来指定在大容量复制操作过程中，空列应保持空值，而不是在这些列中插入默认值。

说明 如果不插入默认值，则该列必须定义为允许空值。

默认情况下，如果使用 bcp 实用工具或 BULK INSERT 语句将数据复制到表中，则表中为这些列定义的默认值都会得到遵守。例如，如果数据文件中包含一个空字段，则就会装载该列的默认值。

例如，数据文件 Publishers.txt 包括以下两行：

0111,New Moon Books,Boston,MA,
0222,Binnet & Hardley,Washington,DC,USA

逗号分隔各字段，换行符分隔各行。第一行中没有国家。如果 publishers 表的 country 列具有默认值"USA"，则当没有指定 -k 开关或 KEEPNULLS 子句时，用 bcp 或 BULK INSERT 语句将这些行大容量装载到表中，如下所示：

0111   New Moon Books                  Boston                MA      USA
0222   Binnet & Hardley                Washington            DC      USA

而若要将数据从 Publishers.txt 数据文件大容量复制到 pubs 数据库的 publishers 表中，并要在 country 列中插入空值而不是默认值"USA"，请在命令提示符下执行以下命令：

bcp pubs..publishers in publishers.txt -c -t, -Sservername -Usa -Ppassword -k

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..publishers FROM 'c:\publishers.txt'
WITH (
   DATAFILETYPE = 'char',
   FIELDTERMINATOR = ',',
   KEEPNULLS
)

说明 尽管如果指定了 -k 或 KEEPNULLS，大容量复制操作就不会检查表的 DEFAULT 定义，但是对其它并发执行的INSERT 语句，DEFAULT 定义仍会起到应有的作用。

请参见

BACKUP

bcp 实用工具

创建和修改 DEFAULT 定义

ServerBCPKeepNulls 属性


控制锁定行为

bcp 实用工具和 BULK INSERT 语句接受 TABLOCK 提示，该提示使用户得以指定所使用的锁定行为TABLOCK 指定在大容量复制过程中获取一个大容量更新表级锁。使用 TABLOCK 可以提高大容量复制操作的性能，因为减少了表上的锁争夺。例如，若要将数据从 Authors.txt 数据文件大容量复制到 pubs 数据库的 authors2 表中，并指定表级锁，请在命令提示符下执行以下命令：

bcp pubs..authors2 in authors.txt -c -t, -Sservername -Usa -Ppassword -h "TABLOCK"

另外，也可以在 SQL 查询分析器这样的查询工具中使用 BULK INSERT 语句来大容量复制数据：

BULK INSERT pubs..authors2 FROM 'c:\authors.txt'
WITH (
   DATAFILETYPE = 'char',
   FIELDTERMINATOR = ',',
   TABLOCK
)

如果没有指定 TABLOCK，默认为使用行级锁，除非 table lock on bulk load 选项的设置为 on。使用 sp_tableoption 设置 table lock on bulk load 选项可以为表设置大容量装载过程中的锁定行为。

Table lock on bulk load | 表锁定行为
Off | 使用行级锁
On | 使用表级锁

如果指定了 TABLOCK 提示，则用 sp_tableoption 为该表设置的默认设置将在大容量装载过程中被替代。

说明 以并行方式将数据从多个客户端大容量装载到表中时，不必使用 TABLOCK 提示，但这样做可以提高性能。

请参见

bcp 实用工具

BULK INSERT。

sp_tableoption

SQL Server 中的锁定介绍


备份和还原数据库

Microsoft® SQL Server™ 2000 备份和还原组件为存储在 SQL Server 数据库中的关键数据提供重要的保护手段。

通过正确设计，可以从多种故障中恢复，包括：

  • 媒体故障。

  • 用户错误。

  • 服务器永久丢失。

另外，也可出于其它目的备份和还原数据库，如将数据库从一台服务器复制到另一台服务器。通过备份一台计算机上的数据库，再将该数据库还原到另一台计算机上，可以快速容易地生成数据库的复本。

本节提供执行完整备份和恢复计划所需的信息。

主题 | 描述
设计备份和还原策略 | 帮助分析和提炼数据可用性要求，并为每个数据库选择恢复模型。
使用恢复模型 | 详细描述每个恢复模型以及适当的备份和还原策略。该主题还描述如何在恢复模型之间进行切换。
备份和还原操作 | 描述各种可用的备份类型以及如何使用它们。该主题还描述时点恢复、重新启动失败的备份或还原、恢复到特定的事务以及恢复数据库的一部分等内容。
管理备份 | 描述备份设备、备份格式以及可移动媒体这些术语。这部分还描述密码安全性和媒体管理，包括格式化、追加、重写、列出和验证媒体内容。
备份和还原系统数据库 | 描述保护和恢复系统数据库所需的过程。
处理大型使命关键环境 | 描述适合高度可用或大型生产数据库的功能和技术，包括使用多个备份设备、文件和文件组备份、文件差异备份和快照备份。
将数据库复制到其它服务器 | 描述利用备份和还原将数据库快速传送到另一台服务器。

请参见

备份/还原构架

将数据库复制到其它服务器

数据库

事务


设计备份和还原策略

必须确定数据的可用性要求，以便选择适当的备份和还原策略。总体备份策略定义备份的类型和频率以及所需的硬件特性和速度。

强烈建议彻底测试备份和恢复过程。测试有助于确保拥有从各种故障中恢复所需的备份，并且当真正的故障发生时可以快速平稳地执行恢复过程。

本节包括下列主题：

主题 | 描述
分析可用性和恢复要求 | 阐述制订备份和还原计划的基本要求。
灾难恢复计划 | 阐述如何制订灾难（例如，服务器完全丢失）恢复计划。
选择恢复模型 | 介绍 Microsoft® SQL Server™ 2000 恢复模型，对可用性要求进行分析后将从这些模型中执行。


分析可用性和恢复要求

为了制定成功的备份和还原计划，必须了解何时需要访问数据以及数据丢失对公司的潜在影响。回答下列问题可以帮助确定可用性要求和对数据丢失的敏感度。有了这些信息后，可以为数据库选择正确的 Microsoft® SQL Server™ 2000 恢复模型，并在技术和财力之间进行必要的权衡。

下面是帮助分析可用性和恢复要求的基本问题：

  • 您的可用性要求是什么？每天的什么时间数据库必须处于联机状态？

  • 服务器故障时间将对公司造成多大的经济损失？

  • 如果遇到媒体故障，如磁盘驱动器发生故障，可接受的故障时间是多长？

  • 一旦发生灾难，如因火灾丢失服务器，可接受的故障时间是多长？

  • 不丢失任何更改的重要程度如何？

  • 重新创建丢失的数据的难易程度如何？

  • 单位是否雇用系统或数据库管理员？

  • 谁将对执行备份和恢复操作负责，如何培训这些人？

下面的问题可帮助选择适合站点的工具、技术和硬件：

  • 每个数据库多大？

  • 每个数据库内的数据更改是否频繁？

  • 有些表是否比其它表修改得频繁？

  • 何时为关键数据库生产周期？

  • 什么时候大量使用数据库，导致频繁的插入和更新操作？

  • 事务日志空间消耗是否由于大量的更新活动而可能是一个问题？

  • 数据库是否受限于定期的大容量数据装载？

  • 数据库是否遭受可能不会立即检测到的危险更新和应用程序错误？

  • 数据库服务器是否是 SQL Server 2000 故障转移群集的一部分，以便获得高度可用性？

  • 数据库是否在集中管理的多服务器环境中？
管理媒体

备份和还原数据库时，需要将数据备份到媒体（例如，磁带和磁盘）上。建议在备份计划中包括管理媒体的条款，例如：

  • 用于存储和重复利用备份集的跟踪和管理计划。

  • 用于重写备份媒体的调度。

  • 在多服务器环境中，使用集中或分布式备份的决策。

  • 跟踪媒体有效生存周期的方法。

  • 使丢失备份集或备份媒体（如磁带）所造成的影响减到最小的过程。

  • 将备份集存储在站点内或站点外的决策，以及对这样做将如何影响恢复时间所进行的分析。


灾难恢复计划

需要创建灾难恢复计划以便确保当发生自然灾难（如火灾）或技术灾难（如 RAID-5 阵列的双磁盘故障）时，可以将所有的系统和数据快速还原到正常操作状态。当创建灾难恢复计划时，准备当灾难性事件发生时必须采取的所有操作。建议通过模拟灾难性事件验证灾难恢复计划。

在考虑灾难恢复计划时需根据自己的环境和业务需要。例如，假定发生火灾，毁灭了 24 小时的数据中心。有把握恢复吗？需要多长时间恢复系统并使其可用？用户能接受的数据丢失量是多少？

理想情况是，灾难恢复计划应规定恢复所需的时间以及用户可以期望的最终数据库状态。例如，可以确定获得指定的硬件后，应该在 48 小时内完成恢复，而且保证最多能将数据恢复到上一个周末时的状态。

灾难恢复计划可通过许多方式构建，并且可以包含多种类型的信息，如：

  • 硬件获取计划。

  • 通讯计划。

  • 灾难发生时的联系人名单。

  • 与负责处理灾难的人员的联系方式。

  • 对计划拥有管理权的人员信息。
运行基本功能脚本

通常，应包括一个基本功能脚本，作为灾难恢复计划的一部分，以便确认每件事是否如预想的那样运转。基本功能脚本为系统管理员或数据库管理员提供可靠工具，使这些管理员不靠最终用户验证就能看到数据库回到切实可行的状态。通常情况下，这是一个带批处理 SQL 语句的 .sql 文件，这些语句在服务器中通过 osql 运行。对于其它应用程序，.bat 文件更合适，因为它可以包含 bcp 和 osql 命令。这个基本功能脚本是应用程序专用脚本，可以有多种不同的形式。例如，在决策支持/报告系统上，该脚本可能只是几个主要报告查询的复本。而对于联机事务处理 (OLTP) 应用程序，该脚本则可能是执行 INSERT、UPDATE 和 DELETE 语句的批处理存储过程的执行计划。

防灾

为了防灾，建议定期执行下列步骤：

  • 定期执行数据库和事务日志备份以使数据丢失减到最低程度。建议同时备份系统和用户数据库。

  • 在安全模式下维护系统日志。保留同时为 Microsoft® Windows NT® 4.0 或 Windows® 2000 和 Microsoft SQL Server™ 安装的所有服务包的记录。保留所使用的网络库、安全模式和 sa 密码的记录。

  • 维护基本功能脚本以快速评估最小能力。

  • 在另一台服务器上提前对灾难恢复所需的步骤进行评估，如有必要修改这些步骤以使其符合您的环境。
灾难恢复

若要从灾难中恢复，请在获得适当的替换硬件后执行下列步骤：

  1. 安装 Windows NT Server 4.0 或 Windows 2000 并应用适当的服务包。验证是否存在适当的域功能。

  2. 安装 SQL Server 并应用适当的服务包。还原 master 和 msdb 数据库备份。还原 master 数据库后重新启动服务器。

  3. 针对适当的网络库和安全模式重新配置服务器。

  4. 检查 SQL Server 服务管理器和 Windows 应用程序日志，确认 SQL Server 运行是否正常。如果 Windows NT 4.0 和 Windows 2000 名称已更改，使用 sp_dropserver 和 sp_addserver 使此名称与 SQL Server 计算机名称相匹配。

  5. 根据每个数据库的恢复计划还原和恢复数据库。

  6. 验证系统的可用性。运行基本功能脚本以确定操作是否正确。

  7. 使用户重新正常使用。

请参见

管理权限

sqlservr 应用程序


选择恢复模型

Microsoft® SQL Server™ 提供了三种恢复模型，用以：

  • 简化恢复计划。

  • 简化备份和恢复过程。

  • 阐明系统操作要求之间的权衡。

这些模型中的每个都是针对不同的性能、磁盘和磁带空间以及保护数据丢失的需要。例如，当选择恢复模型时，必须考虑下列业务要求之间的权衡：

  • 大规模操作的性能（如创建索引或大容量装载）。

  • 数据丢失表现（如已提交的事务丢失）。

  • 事务日志空间损耗

  • 备份和恢复过程的简化。

根据正在执行的操作，可以有多个适合的模型。选择了恢复模型后，设计所需的备份和恢复过程。

下表提供了三种恢复模型的优点和含义的概述。

恢复模型 | 优点 | 工作损失表现 | 能否恢复到即时点？
简单 | 允许高性能大容量复制操作。 收回日志空间以使空间要求最小。 | 必须重做自最新的数据库或差异备份后所发生的更改。 | 可以恢复到任何备份的结尾处。随后必须重做更改。
完全 | 数据文件丢失或损坏不会导致工作损失。 可以恢复到任意即时点（例如，应用程序或用户错误之前）。 | 正常情况下没有。 如果日志损坏，则必须重做自最新的日志备份后所发生的更改。 | 可以恢复到任何即时点。
大容量日志记录的 | 允许高性能大容量复制操作。 大容量操作使用最少的日志空间。 | 如果日志损坏，或者自最新的日志备份后发生了大容量操作，则必须重做自上次备份后所做的更改。 否则不丢失任何工作。 | 可以恢复到任何备份的结尾处。随后必须重做更改。

数据库在创建时具有与 model 数据库相同的恢复模型。若要更改默认恢复模型，请使用 ALTER DATABASE 更改 model 数据库的恢复模型。可以使用 ALTER DATABASE 语句的 RECOVERY 子句设置恢复模型。有关更多信息，请参见 ALTER DATABASE。

简单恢复

简单恢复所需的管理最少。在简单恢复模型中，数据只能恢复到最新的完整数据库备份或差异备份的状态。不使用事务日志备份，而使用最小事务日志空间。一旦不再需要日志空间从服务器故障中恢复，日志空间便可重新使用。

与完整模型或大容量日志记录模型相比，简单恢复模型更容易管理，但如果数据文件损坏，则数据损失表现会更高。

重要 简单恢复不适合生产系统，因为对生产系统而言，任何最新更改的丢失都是不能接受的。

如果使用简单恢复，备份间隔应足够长以使备份开销不影响生产工作，但也要足够短以防止丢失大量的数据。

有关更多信息，请参见简单恢复。

完全恢复和大容量日志记录恢复

完全恢复和大容量日志记录恢复模型为数据提供了最大的保护性。这些模型依靠事务日志提供完全的可恢复性，并防止最大范围的故障情形所造成的工作损失。

完全恢复模型提供最大的灵活性，可将数据库恢复到更早的即时点。有关更多信息，请参见完全恢复。

大容量日志记录模型为某些大规模操作（如创建索引或大容量复制）提供了更高的性能和更低的日志空间损耗。不过这将牺牲时点恢复的某些灵活性。有关更多信息，请参见大容量日志记录恢复。

很多数据库都要经历大容量装载或索引创建的阶段，因此可能希望在大容量日志记录模型和完全恢复模型之间进行切换。有关更多信息，请参见切换恢复模型。

请参见

ALTER DATABASE


使用恢复模型

可以为 Microsoft® SQL Server™ 2000 中的每个数据库选择三种恢复模型中的一种，以确定如何备份数据以及能承受何种程度的数据丢失。下面是可以选择的三种恢复模型：

  • 简单恢复

    简单恢复允许将数据库恢复到最新的备份。

  • 完全恢复

    完全恢复允许将数据库恢复到故障点状态。

  • 大容量日志记录恢复

    大容量日志记录恢复允许大容量日志记录操作。

当创建新的数据库时，新的数据库继承 model 数据库的恢复模型。

说明 SQL Server 2000 个人版和 SQL Server 2000 Desktop Engine 中的新数据库恢复模型默认为简单恢复模型。


简单恢复

使用简单恢复模型可以将数据库恢复到上次备份的即时点。不过，无法将数据库还原到故障点或特定的即时点。若要还原到这些点，请选择完全恢复或大容量日志记录恢复。

简单恢复的备份策略包括：

  • 数据库备份。

  • 差异备份（可选）。

说明 此模型类似于在 Microsoft® SQL Server™ 7.0 版或更早版本中设置 trunc. log on chkpt. 数据库选项。

在媒体发生故障时进行恢复

  1. 还原最新的完整数据库备份。

  2. 如果有差异备份，则还原最新的那个备份。

上次的数据库备份或差异备份后的更改将丢失。

创建数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

还原数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

创建差异数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

还原差异数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

选择恢复模型

完全恢复

大容量日志记录恢复


完全恢复

完全恢复模型使用数据库备份和事务日志备份提供对媒体故障的完全防范。如果一个或多个数据文件损坏，则媒体恢复可以还原所有已提交的事务。正在进行的事务将回滚。

完全恢复提供将数据库恢复到故障点或特定即时点的能力。为保证这种恢复程度，包括大容量操作（如 SELECT INTO、CREATE INDEX 和大容量装载数据）在内的所有操作都将完整地记入日志。

完全恢复的备份策略包括：

  • 数据库备份。

  • 差异备份（可选）。

  • 事务日志备份。

  • 完全恢复和大容量日志记录恢复很相似，而且很多使用完全恢复模型的用户有时将使用大容量日志记录模型。有关更多信息，请参见大容量日志记录恢复。
在媒体发生故障时进行恢复

如果数据库的当前事务日志文件可用而且没有损坏，则可以将数据库还原到故障点发生时的状态。若要将数据库还原到故障点：

  1. 备份当前活动事务日志。有关更多信息，请参见事务日志备份。

  2. 还原最新的数据库备份但不恢复数据库。

  3. 如果有差异备份，则还原最新的那个备份。

  4. 按照创建时的相同顺序，还原自数据库备份或差异备份后创建的每个事务日志备份，但不恢复数据库。

  5. 应用最新的日志备份（在步骤 1 中创建的）并恢复数据库。

    重要 在完全恢复模型中为防止事务损失，必须保护事务日志不受损坏。强烈建议使用容错磁盘存储事务日志。

创建数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

还原数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

创建差异数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

还原差异数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

选择恢复模型

简单恢复


大容量日志记录恢复

大容量日志记录恢复模型提供对媒体故障的防范，并对某些大规模或大容量复制操作提供最佳性能和最少的日志使用空间。下列操作为最小日志记录操作：

  • SELECT INTO。

  • 大容量装载操作（bcp 和 BULK INSERT）。

  • CREATE INDEX（包括索引视图）。

  • text 和 image 操作（WRITETEXT 和 UPDATETEXT）。

在大容量日志记录恢复模型中，这些大容量复制操作的数据丢失程度要比完全恢复模型严重。虽然在完全恢复模型下记录大容量复制操作的完整日志，但在大容量日志记录恢复模型下，只记录这些操作的最小日志，而且无法逐个控制这些操作。在大容量日志记录恢复模型中，数据文件损坏可能导致必须手工重做工作。

另外，当日志备份包含大容量更改时，大容量日志记录恢复模型只允许数据库恢复到事务日志备份的结尾处。不支持时点恢复。

在 Microsoft® SQL Server™ 2000 中，可以很容易地在完全恢复模型和大容量日志记录恢复模型之间进行切换。在大容量日志记录恢复模型中，不需要在完成大容量复制操作后执行完整数据库备份。在这个模型中，事务日志备份捕获日志和上次备份后执行的任何大容量操作的结果。

大容量日志记录恢复的备份策略包括：

  • 数据库备份。

  • 差异备份（可选）。

  • 日志备份。

    备份包含大容量日志记录操作的日志时，需要访问数据库内的所有数据文件。如果数据文件不可访问，则无法备份最后的事务日志，而且该日志中所有已提交的操作都将丢失。

在媒体发生故障时进行恢复

  1. 备份当前活动事务日志。有关更多信息，请参见事务日志备份。

  2. 还原最新的完整数据库备份。

  3. 如果有差异备份，则还原最新的那个备份。

  4. 按顺序应用自最新的差异备份或完整数据库备份后创建的所有事务日志备份。

  5. 手工重做最新日志备份后的所有更改。

重要 如果活动事务日志丢失（例如，由于包含该事务日志文件的磁盘发生硬件故障），则该日志中的所有事务都将丢失。若要防止活动事务日志丢失，请将事务日志文件放到镜像磁盘上。

创建数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

创建事务日志备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

当数据库损坏时备份事务日志

Transact-SQL

Transact-SQL

SQL-DMO

还原数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

应用事务日志备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

将数据库还原到前一个状态

事务日志

事务

使用文件或文件组备份


切换恢复模型

可以将数据库从一个恢复模型切换到另一个恢复模型，以满足不断变化的业务要求。例如，使命关键的联机事务处理 (OLTP) 系统需要完全的可恢复性，而且可以定期进行大容量装载和索引操作。可以在装载和索引操作的过程中，将数据库的恢复模型更改到大容量日志记录模型，然后再返回到完全恢复。这将提高性能并减少所需的日志空间，同时保持服务器保护。

说明 允许在进行大容量装载操作时切换恢复模型。大容量操作的日志记录将相应更改。

下表列出从一个恢复模型切换到另一个恢复模型时应采取的措施。

原模型 | 切换模型 | 对策 | 描述
完全恢复 | 大容量日志记录恢复 | 无需任何操作 | 无需更改备份策略。继续执行定期数据库备份、日志备份和差异备份（可选）。
完全恢复 | 简单恢复 | 可选择在更改之前备份事务日志 | 在更改允许恢复到那一点之前立即执行日志备份。切换为简单模型后请停止执行日志备份。
大容量日志记录恢复 | 完全恢复 | 无需任何操作 | 无需更改备份策略。完成下一次日志备份后可以恢复到任一即时点。如果时点恢复很重要，请在切换后立即执行日志备份。
大容量日志记录恢复 | 简单恢复 | 可选择在更改之前备份事务日志 | 在更改允许恢复到那一点之前立即执行日志备份。切换为简单模型后请停止执行日志备份。
简单恢复 | 完全恢复 | 更改后备份数据库 | 切换为完全恢复模型后执行数据库或差异备份。开始执行定期数据库备份、日志备份和差异备份（可选）。
简单恢复 | 大容量日志记录恢复 | 更改后备份数据库 | 切换为大容量日志记录模型后执行数据库或差异备份。开始执行定期数据库备份、日志备份和差异备份（可选）。


备份和还原操作

Microsoft® SQL Server™ 支持单独使用一种备份方式或组合使用多种备份方式。选择的恢复模型将决定总体备份策略，包括可以使用的备份类型。有关更多信息，请参见设计备份和还原策略和使用恢复模型。

下表说明适用于每种恢复模型的备份类型。

模型 | 备份类型
 | 数据库 | 数据库差异 | 事务日志 | 文件或文件差异
简单 | 必需 | 可选 | 不允许 | 不允许
完全 | 必需 （或文件备份） | 可选 | 必需 | 可选
大容量日志记录 | 必需 （或文件备份） | 可选 | 必需 | 可选

备份创建在备份设备上，如磁盘或磁带媒体。使用 SQL Server 可以决定如何在备份设备上创建备份。例如，可以重写过期的备份或者将新备份追加到备份媒体上。有关更多信息，请参见管理备份。

执行备份操作对运行中的事务影响很小，因此可以在正常操作过程中执行备份操作。

说明 正在备份数据库或事务日志时不能创建或删除数据库文件。如果在备份操作正在进行时尝试创建或删除数据库文件，则创建或删除将失败。如果正在创建或删除数据库文件时尝试启动备份操作，则备份操作将一直等到创建或删除完成或备份操作超时。

请参见

选择恢复模型

分析可用性和恢复要求

灾难恢复计划


数据库备份

数据库备份创建备份完成时数据库内存在的数据的副本。这是单个操作，通常按常规时间间隔调度。 数据库备份为自包含。

可以通过还原数据库，只用一步即完成从数据库备份重新创建整个数据库。还原进程重写现有数据库，如果现有数据库不存在则创建。已还原的数据库将与备份完成时的数据库状态相匹配，但不包括任何未提交的事务。恢复数据库时回滚未提交的事务。

与事务日志备份和差异数据库备份相比，数据库备份中的每个备份使用的存储空间更多。因此，数据库备份完成备份操作需要更多的时间，所以数据库备份的创建频率通常比差异数据库或事务日志备份低。有关更多信息，请参见事务日志备份和差异数据库备份。

还原数据库备份

还原数据库备份将重新创建数据库和备份完成时数据库中存在的所有相关文件。但是，自创建备份后所做的任何数据库修改都将丢失。若要还原创建数据库备份后所发生的事务，必须使用事务日志备份或差异备份。

还原数据库时，Microsoft® SQL Server™：

  1. 将备份中的所有数据复制到数据库中。数据库的其余部分作为未用空间创建。

  2. 回滚数据库备份中任何未完成的事务以确保数据库保持一致。

为防止意外重写数据库，还原操作自动执行安全检查。如果发生下列情况，还原操作将失败：

  • 还原操作中的数据库名称与备份集中记录的数据库名称不匹配。

  • 还原操作中命名的数据库已在服务器上，但是与数据库备份中包含的数据库不是同一个数据库。例如，数据库名称虽相同，但是各个数据库的创建方式不同。

  • 需要通过还原操作自动创建一个或多个文件，但已有同名的文件存在。

如果打算重写另一个数据库，可以禁用这些安全检查。有关更多信息，请参见 RESTORE。

说明 如果不是在创建备份的 SQL Server 实例上还原数据库，则可能需要运行 sp_change_users_login 以更新用户登录信息。 有关更多信息，请参见 sp_change_users_login。

备份全文索引

备份数据库不备份全文目录中的全文索引数据。不过，如果为表定义了全文索引，创建数据库备份时将备份元数据。还原数据库备份后，可以重新创建和重新填充全文索引目录。有关更多信息，请参见全文索引。

估计数据库备份的大小

在执行备份和还原策略前，需要估计数据库备份需要使用的磁盘空间量。在数据库备份过程中，备份操作只将数据库中的数据复制到备份文件。因为数据库备份只包含数据库内的实际数据，而不包含任何未用空间，所以数据库备份很可能比数据库本身小。可以通过使用 sp_spaceused 系统存储过程估计数据库备份的大小。有关更多信息，请参见 sp_spaceused。

创建数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

使用创建数据库备份向导创建数据库备份

企业管理器

企业管理器

还原数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

数据库维护计划向导

数据库

设置数据库选项


差异数据库备份

差异数据库备份只记录自上次数据库备份后发生更改的数据。差异数据库备份比数据库备份小而且备份速度快，因此可以更经常地备份，经常备份将减少丢失数据的危险。

说明 如果自上次完整数据库备份后创建了任何文件备份，则 Microsoft® SQL Server™ 2000 将在差异数据库备份开始时扫描这些文件。这可能导致差异数据库备份的性能有所降低。有关更多信息，请参见使用文件备份。

使用差异数据库备份将数据库还原到差异数据库备份完成时的那一点。若要恢复到精确的故障点，必须使用事务日志备份。有关更多信息，请参见事务日志备份。

在下列情况下，可考虑使用差异数据库备份：

  • 自上次数据库备份后数据库中只有相对较少的数据发生了更改。如果多次修改相同的数据，则差异数据库备份尤其有效。

  • 使用的是简单恢复模型，希望进行更频繁的备份，但不希望进行频繁的完整数据库备份。

  • 使用的是完全恢复模型或大容量日志记录恢复模型，希望需要最少的时间在还原数据库时前滚事务日志备份。

建议在执行差异数据库备份时使用如下过程：

  1. 创建定期的数据库备份。

  2. 在每个数据库备份之间定期创建差异数据库备份（例如，对于高度活动的系统，每隔四小时或四小时以上备份一次）。

  3. 如果使用完全恢复模型或大容量日志记录恢复模型，则创建事务日志备份的频率比差异数据库备份大，如每隔 30 分钟。

还原差异数据库备份的顺序为：

  1. 还原最新的数据库备份。

  2. 还原最后一次的差异数据库备份。

  3. 如果使用完全恢复或大容量日志记录恢复，则应用自上次创建差异数据库备份后创建的所有事务日志备份。

创建差异数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

还原差异数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

数据库备份

减少恢复时间


事务日志备份

事务日志是自上次备份事务日志后对数据库执行的所有事务的一系列记录。可以使用事务日志备份将数据库恢复到特定的即时点（如输入多余数据前的那一点）或恢复到故障点。

还原事务日志备份时，Microsoft® SQL Server™ 前滚事务日志中记录的所有更改。当 SQL Server 到达事务日志的最后时，已重新创建了与开始执行备份操作的那一刻完全相同的数据库状态。如果数据库已经恢复，则 SQL Server 将回滚备份操作开始时尚未完成的所有事务。

一般情况下，事务日志备份比数据库备份使用的资源少。因此可以比数据库备份更经常地创建事务日志备份。经常备份将减少丢失数据的危险。

说明 事务日志备份有时比数据库备份大。例如，数据库的事务率很高，从而导致事务日志迅速增大。在这种情况下，应更经常地创建事务日志备份。

事务日志备份只能与完全恢复模型和大容量日志记录恢复模型一起使用。有关更多信息，请参见使用恢复模型。

将事务日志备份与数据库备份一起使用

只有具有自上次数据库备份或差异数据库备份后的连续事务日志备份序列时，使用数据库备份和事务日志备份还原数据库才有效。 如果日志备份丢失或损坏，必须创建数据库备份或差异数据库备份并再次开始备份事务日志。如果打算将数据库还原到这些备份内的某个即时点，应保留以前的事务日志备份。

只有当启动事务日志备份序列时，数据库或差异数据库备份才必须与事务日志备份同步。每个事务日志备份序列都必须由数据库或差异数据库备份启动。

通常情况下，只有当第一次备份数据库或发生从简单恢复模型到大容量日志记录恢复模型的改变时才开始新的备份序列。有关更多信息，请参见切换恢复模型。

截断事务日志

SQL Server 在完成事务日志备份时将自动截断事务日志中的不活动部分。这些不活动的部分包含已完成的事务，因此在恢复过程中不再使用。相反，事务日志的活动部分包含仍在运行但尚未完成的事务。SQL Server 将重新使用事务日志中这些截断的非活动空间，而不是任由事务日志继续增大并占用更多的空间。

说明 虽然可以手工截断事务日志，但强烈建议最好不要这样做，因为这将断开日志备份链。在创建完整数据库备份前，将无法为数据库提供媒体故障保护。只有在非常特殊的环境中才使用手工日志截断，而且尽可能快地创建完整数据库备份。

事务日志非活动部分的终点（因此就是截断点）是下列事件的最早点：

  • 最近的检查点。

  • 最早的活动事务的起点，即尚未提交或回滚的事务。

    这代表在恢复过程中，SQL Server 必须回滚事务的最早点。

  • 最早事务的起点，这些事务包括已发布但尚未复制更改的复制对象。

    这代表 SQL Server 仍必须复制的最早点。

备份事务日志的条件

完整数据库备份或差异数据库备份执行期间不能备份事务日志。不过，在运行文件备份的同时可以备份事务日志。

下列情况不要备份事务日志：

  • 在由于事务日志包含自上次创建备份后数据库所发生的更改，而创建了数据库或文件备份之前。有关更多信息，请参见使用文件备份。

  • 事务日志已被显式截断。此时如果要备份事务日志，必须在事务日志截断发生后先创建数据库或差异数据库备份。
还原事务日志备份

必须满足以下条件才能应用事务日志备份：

  • 先还原事务日志备份之前的数据库备份或差异数据库备份。

  • 先应用在备份数据库或差异数据库之前创建的所有事务日志。

    如果以前的事务日志备份丢失或损坏，最多只能将事务日志还原到丢失的事务日志之前的最后一次备份。

  • 已经恢复了数据库，也已经前滚或回滚了所有未完成的事务。

    应用事务日志备份时，必须等应用了最后的事务日志后才能恢复数据库。如果允许在应用其中一个中间事务日志备份时进行恢复，则必须从数据库备份开始重新开始整个还原操作，才能还原过那一点。

创建事务日志备份序列

为创建备份集，通常应定期生成数据库备份（如每天），并以更短的间隔生成事务日志备份（如每隔 10 分钟）。必须至少有一个数据库备份或覆盖的文件备份集，才能有效地进行日志备份。备份之间的间隔因数据的关键性和服务器的工作负荷而异。如果事务日志损坏，则将丢失自最新的日志备份后所执行的工作。为此，建议经常对关键数据进行日志备份，并注意将日志文件放在容错存储上。

事务日志备份序列独立于数据库备份。可以生成一个事务日志备份序列，然后定期生成用于开始还原操作的数据库备份。例如，假设有下列事件序列。

时间 | 事件
上午 8:00 | 备份数据库
中午 | 备份事务日志
晚上 04:00:00 | 备份事务日志
下午 6:00 | 备份数据库
晚上 08:00:00 | 备份事务日志
晚上 10:00 | 出现故障

晚上 8:00 创建的事务日志备份包含从下午 4:00 到晚上 8:00 的事务日志记录，中间跨越下午 6:00 创建数据库备份的时间。事务日志备份序列从上午 8:00 创建的初始数据库备份到晚上 8:00 创建的最后一次事务日志备份是连续的。可以使用下列过程将数据库还原到晚上 10:00 的状态（故障点）：

使用最后一次创建的数据库备份还原数据库。

  1. 创建当前活动事务日志的备份。

  2. 还原下午 6:00 的数据库备份，然后应用晚上 8:00 的数据库备份和活动事务日志备份。

    还原进程检测到晚上 8:00 的事务日志备份包含自上次还原备份后所发生的事务。因此，还原操作向下扫描事务日志直至下午 6:00 完成数据库备份时对应的即时点，并且只前滚事务日志备份内自该点后所完成的事务。对晚上 10:00 的事务日志备份再执行一次上述操作。

使用以前的数据库备份（早于最后一次创建的数据库备份）还原数据库。

  1. 创建当前活动事务日志的备份。

  2. 还原上午 8:00 的数据库备份，然后按顺序还原全部四个事务日志备份。不要还原下午 6:00 的数据库备份。所有完成的事务都将前滚到晚上 10:00。

    这个进程所用的时间比还原下午 6:00 的数据库备份要长。

第二种还原数据库的方法注重由事务日志备份链所提供的冗余安全性，使用这个事务日志备份链，即使数据库备丢失份，也可以还原数据库。可以还原以前的数据库备份，然后还原创建该数据库备份后所创建的所有事务日志备份。

说明 不丢失事务日志备份很重要。可考虑生成日志备份集的多个复本。为此，可以将日志备份到磁盘，然后将磁盘文件复制到其它设备，如单独的磁盘或磁带。

恢复和事务日志

当完成还原操作并恢复数据库时，所有未完成的事务将回滚。这对还原数据库的完整性是必需的。

完成该操作后，不能再将其它事务日志备份应用到数据库。例如，一系列事务日志备份包含一个运行时间长的事务。该事务的起点记录在第一个事务日志备份中，终点记录在第二个事务日志备份中。第一个事务日志备份中没有任何关于提交或回滚操作的记录。因此，如果恢复操作在应用第一个事务日志备份时运行，则此运行时间长的事务被视为未完成。记录在事务的第一个事务日志备份中的数据修改将回滚。SQL Server 不允许在运行恢复操作后应用第二个事务日志备份。

因此，还原事务日志备份时，必须等到应用了最后的事务日志后才能恢复数据库。这可以防止部分回滚事务。只有在最后的还原操作结束时才需要回滚未完成的事务。


备份限制

在 Microsoft® SQL Server™ 中，可以在数据库联机或在正在使用时执行备份操作。但是，在数据库备份操作中，不允许进行下列操作：

  • 创建或删除数据库文件。

  • 在数据库（自动或手工）或数据库文件上执行收缩操作时截断文件。如果备份正在运行，则此操作将失败。可以在备份完成后执行截断操作。有关更多信息，请参见收缩数据库。

如果在上述某个操作正在进行时开始备份，则备份将等待该操作完成，直到会话超时所设置的时间限制到期。如果在备份操作执行过程中试图执行上面任一操作，该操作将失败，而备份操作继续进行。


将数据库还原到前一个状态

有时要将数据库还原到更早的即时点。例如，如果数据库内的某个早期事务错误地更改了某些数据，则需将数据库还原到早于错误数据输入时间的即时点。为此，需将整个数据库恢复到事务日志内的某个点。可以将数据库恢复到事务日志内的特定即时点，或恢复到以前插入到日志中的某个命名标记。

创建事务日志备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

数据库损坏时备份事务日志

Transact-SQL

Transact-SQL

SQL-DMO

还原到故障点

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

BACKUP


恢复到即时点

可以通过只恢复在事务日志备份内的特定即时点之前发生的事务来恢复到即时点，而不用恢复整个备份。通过查看每个事务日志备份的标题信息或 msdb 中 backupset 表内的信息，可以快速识别哪个备份包含要将数据库还原到的即时点。然后只需将事务日志备份应用到该点。

不能跳过特定的事务。因为这将危及数据库内的数据完整性。在要撤消的事务之后发生的事务可能取决于该撤消事务所修改的数据。

如果不想还原特定的即时点之后对数据库所做的任何修改，则：

  • 不恢复数据库而还原最后一次数据库备份。

  • 按照与创建事务日志备份时相同的顺序应用每个事务日志备份。

  • 在事务日志备份内的期望的即时点处恢复数据库。

如果在某个即时点之后创建的某些事务日志备份丢失或损坏，也可用该进程还原数据库和事务日志。

还原到某个即时点

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

RESTORE HEADERONLY


恢复到命名事务

Microsoft® SQL Server™ 2000 支持在事务日志中插入命名标记以允许恢复到特定的标记。日志标记是事务性的，只有在提交与它们相关联的事务时才插入。因此可将标记绑定到特定的工作上，而且可恢复到包含或排除此工作的点。

将命名标记插入到事务日志前，请考虑下列事项：

  • 由于事务标记消耗日志空间，应只对在数据库恢复策略中起重要作用的事务使用标记。

  • 对于每个提交的带标记的事务，在 msdb 中的 logmarkhistory 表中都会插入一行。

  • 如果一个带标记的事务跨越同一数据库服务器或不同服务器上的多个数据库，这些标记将记录在所有受影响的数据库的日志内。有关更多信息，请参见相关数据库的备份和还原。
将命名标记插入到事务日志

使用 BEGIN TRANSACTION 语句和 WITH MARK [description] 子句在事务日志中插入标记。由于标记的名称与其事务相同，因此必需要有事务名称。description 是标记的文本描述，是可选的。

事务日志记录标记名称、描述、数据库、用户、datetime 信息和日志序列号 (LSN)。为了可以重新使用它们，不要求事务名称是唯一的。datetime 信息与事务名称一起使用，唯一地标识标记。

恢复到某个标记

有两种方法可以恢复到日志中的某个标记：

  • 使用 RESTORE LOG 和 WITH STOPATMARK='mark_name' 子句前滚到该标记且包括带该标记的事务。

  • 使用 RESTORE LOG 和 WITH STOPBEFOREMARK='mark_name' 子句前滚到该标记且不包括带该标记的事务。

WITH STOPATMARK 和 WITH STOPBEFOREMARK 子句支持可选的 AFTER datetime 子句。如果省略 AFTER datetime，恢复操作将在含有指定名称的第一个标记处停止。如果指定 AFTER datetime，恢复操作则在带指定名称的第一个标记处停止，或在 datetime 后停止。

说明 恢复到某个标记所受的限制与时点恢复相同。特别是在数据库进行大容量日志记录操作的间歇期内不允许恢复到某个标记。


恢复路径

如果将数据库恢复到更早的即时点并开始使用该点的数据库，就会创建一条新的恢复路径。此恢复路径将包含使之具有唯一性的新事务。如果需要再次还原数据库，则不可能从两条恢复路径组合数据，而只能沿着其中的一条路径还原数据。

说明 还原完整的数据库备份并恢复数据库，而不使用任何其它类型的备份，这不会导致出现新的恢复路径。

创建新的恢复路径的示例包括：

  • 还原完整数据库备份和差异备份并恢复数据库，且不应用现有的事务日志备份。

  • 在最新的差异备份以外的其它差异备份的结尾处恢复数据库。

  • 在最新的事务日志备份以外的其它事务日志备份的结尾处恢复数据库。

  • 在特定时间或事务日志备份内某个标记的事务处恢复数据库。

在上面的示例中，创建了一个完整数据库备份和四个日志备份序列。然后，通过还原完整数据库备份、日志备份 1 和日志备份 2 将数据库还原到日志备份 2 的结尾处。数据库在此点恢复，并创建新恢复路径。然后，使用此数据库一段时间后，又进一步创建了两个事务日志备份：日志备份 5 和日志备份 6。如果再次还原完整数据库备份并应用事务日志备份，则必须沿着下列两条恢复路径之一：

  • 日志备份 1、日志备份 2、日志备份 3 和日志备份 4

    -或-

  • 日志备份 1、日志备份 2、日志备份 5 和日志备份 6

可以沿着任何一条路径在任何即时点恢复数据库，但是不可能组合两条路径中的数据。例如，不能按顺序还原日志备份 1 到 6，这是因为日志备份 3 和 4 包含的数据与日志备份 5 和 6 不一致。


部分数据库还原操作

应用程序或用户错误经常影响到数据库的某个孤立部分（如表）。为支持从这些事件中恢复，Microsoft® SQL Server™ 提供一种机制，将数据库的一部分还原到另一个位置，以使损坏或丢失的数据可以复制回原始数据库。例如，如果应用程序错误地除去了一个表，可能只想还原数据库中包含这个表的那部分。日志备份或差异备份可以将这个表还原到除去该表前的那一点。然后可以析取表的内容并重新装载到原始数据库中。

在下列情况中，执行部分还原操作也很有用：

  • 出于开发和生成报表的目的在另一台服务器上创建数据库的一个子集。

  • 还原存档数据。

部分还原操作使用数据库文件组。主要文件组始终同指定的文件及其相应的文件组一起还原。还原结果是数据库的一个子集。没有还原的文件组被标记为脱机，不能对其进行访问。

说明 由于还原了主文件，所有目录（全文目录除外）也得到还原，甚至与还原操作中所没有包括的文件相关联的目录也得到还原。

部分还原操作由 RESTORE 语句的 PARTIAL 子句完成。在还原完整数据库备份时，还可以使用 PARTIAL 选项。不支持文件备份的部分数据库还原。

执行部分还原操作

  1. 执行使用完整数据库备份的 RESTORE DATABASE 语句，并指定：
    • 要还原的数据库名称。除非计划重写原始数据库或正在不同的服务器上还原数据库，否则给数据库指定一个新名称。

    • 要从其中还原数据库备份的备份设备。

    • 为每个要还原的文件或文件组指定 FILEGROUP 子句。

      说明 如果指定一个文件，也将还原其文件组内的所有文件。

    • 用于还原的 MOVE 子句（如果正将文件还原到新位置）。

    • PARTIAL 子句。

    • NORECOVERY 子句（如果有要应用的事务日志备份或差异备份）。否则指定 RECOVERY 子句。
  2. 可以选择执行 RESTORE DATABASE 语句以还原差异数据库备份，同时指定：
    • 差异数据库备份将应用到的数据库的名称。

    • 要从其中还原差异数据库备份的备份设备。

    • NORECOVERY 子句，前提是在还原差异数据库备份后，还要应用事务日志备份，否则应指定 RECOVERY 子句。
  3. 执行 RESTORE LOG 语句以应用每个事务日志备份，同时指定：
    • 将对其应用事务日志的数据库名称。

    • 要从其中还原事务日志备份的备份设备。

    • NORECOVERY 子句（如果有其它要应用的事务日志备份）。否则指定 RECOVERY 子句。
示例

下例在名为 mywind 的数据库中执行部分还原操作。mywind 使用的是完全恢复模型。数据库创建在两个文件组上，即包含文件 mywind_data_1 的 new_customers 和包含文件 mywind_data_2 的 sales。

CREATE DATABASE mywind
GO

ALTER DATABASE mywind ADD FILEGROUP new_customers
ALTER DATABASE mywind ADD FILEGROUP sales
GO

ALTER DATABASE mywind ADD FILE
   (NAME='mywind_data_1',
   FILENAME='g:\mw.dat1')
   TO FILEGROUP new_customers
ALTER DATABASE mywind
   ADD FILE
   (NAME='mywind_data_2',
   FILENAME='g:\mw.dat2')
   TO FILEGROUP sales
GO

执行完整数据库备份。然后在 new_customers 上创建表 t1，在 sales 上创建表 t2。备份事务日志：

BACKUP DATABASE mywind
   TO DISK ='g:\mywind.dmp'
   WITH INIT
GO

USE mywind
GO

CREATE TABLE t1 (id int) ON new_customers
CREATE TABLE t2 (id int) ON sales
GO

BACKUP LOG mywind TO DISK='g:\mywind.dmp'
WITH NOINIT
GO

在某些时候，有必要还原 sales 文件组上的表 t2。RESTORE FILELISTONLY 语句列出数据库文件及其所在的文件组。RESTORE HEADERONLY 语句列出备份媒体的内容：

RESTORE FILELISTONLY FROM DISK='g:\mywind.dmp'
GO
RESTORE HEADERONLY FROM DISK='g:\mywind.dmp'
GO

RESTORE DATABASE 语句使用 WITH PARTIAL 和 NORECOVERY 选项以另一个名称还原数据库和 sales 文件组。另外，还将主文件和文件组 (mywind)、事务日志 (mywind_log) 和已还原的文件组中的所有文件（本例中 sales 中只有 mywind_data_2 文件）移到新位置。日志即得到恢复。

RESTORE DATABASE mywind_part
   FILEGROUP = 'sales'
   FROM DISK='g:\mywind.dmp'
   WITH FILE=1,NORECOVERY,PARTIAL,
   MOVE 'mywind' TO 'g:\mw2.pri',
   MOVE 'mywind_log' TO 'g:\mw2.log',
   MOVE 'mywind_data_2' TO 'g:\mw2.dat2'
GO

RESTORE LOG mywind_part
   FROM DISK = 'g:\mywind.dmp'
   WITH FILE = 2,RECOVERY
GO

Notice that t2 is accessible after the partial restore operation.
SELECT COUNT(*) FROM mywind_part..t2

下面是结果：

---------------
0

注意在部分还原操作后无法访问 t1。

SELECT COUNT(*) FROM mywind_part..t1

下面是所得到的消息：

The query processor is unable to produce a plan because
the table 'mywind_part..t1' is marked OFFLINE.

请参见

恢复到即时点

RESTORE


恢复数据库但不还原

通常情况下，在还原上一个备份时恢复数据库。也可以恢复数据库但不还原备份。这在下列情况下很必要：

  • 上一次还原时没有恢复数据库，但是现在要使用数据库。

  • 数据库为备用模式，想不应用其它日志备份即可更新此数据库。

不还原而恢复数据库

Transact-SQL

Transact-SQL

SQL-DMO


重新开始被中断的备份和还原操作

如果备份或还原操作被中断（如因电源故障），可以从中断点重新开始备份或还原操作。这在将大型数据库作为自动进程还原到其它服务器上时很有用。如果该自动进程在还原操作即将结束时失败，可以尝试从中断点重新开始还原操作，而不必从起点开始还原整个数据库。

重新开始被中断的备份操作

Transact-SQL

Transact-SQL

SQL-DMO

重新开始被中断的还原操作

Transact-SQL

Transact-SQL

SQL-DMO


相关数据库的备份和还原

如果有两个或两个以上的数据库必须在逻辑上保持一致，可能需要执行特殊的过程以确保这些数据库的可恢复性。

考虑整个数据库集的恢复目标很重要。最坏的情况是需要考虑恢复所有数据库所需的时间。为了避免过多恢复大量的数据库，需要避免在备份时共享媒体，还需要有足够的硬件并行还原数据库。

下面是三个可能的相关数据库情形：

  • 遇到媒体故障，影响了一个或多个数据库，但事务日志没有损坏。希望恢复到当前时间。

  • 一个或多个事务日志已毁坏。需要将数据库集还原到上次日志备份时的一致状态。

  • 需要将整个数据库集还原到更早的即时点时的相互一致状态。

在所有上述三种情形中，都必须对这些数据库使用完全恢复模型。有关更多信息，请参见完全恢复。

第一种情形不要求执行任何特殊的恢复过程。若要恢复损坏的数据库，需备份日志的尾部，还原损坏的文件或数据库，然后使用事务日志备份前滚。未损坏的数据库不需要任何操作。

其它两种情形要求使用特殊的过程来确保可恢复性，这个过程就是标记数据库内的事务。

标记事务基础知识

可以在相关数据库间标记事务，并使用这些标记事务将相关数据库恢复到同一事务一致即时点。为此，可在备份任何数据库中的日志前，在所有数据库间放置分布式标记。这将确保所有日志备份都具有将在所有数据库中出现的标记。无需同步备份。相反，在事务日志中放置标记使得可以在还原过程中同步。使用完全恢复模型确保所有标记都有效。

重要 相关数据库恢复不允许恢复到某个特定的即时点。相关数据库的恢复只能通过恢复到标记事务来完成。

银行便是相关数据库恢复的一个示例。银行有包含支票帐户数据的数据库和包含存款帐户数据的数据库。这两个数据库位于不同的服务器上，而且支票帐户和存款帐户间存在大量的来回转帐事务。如果在转帐事务在系统中处于活动时备份数据库，那么即使同时备份了数据库，仍有可能出现某些转帐事务已在一个数据库中提交但未在另一个数据库中提交的情况。标记事务可用于备份这些数据库，并可在以后将这些数据库还原到所有事务的结果在两个已还原数据库中都相同的点。

本示例的备份策略应为：

  1. 将两个数据库的恢复模型都设置为完全恢复模型。

  2. 备份每个数据库。

    可以串行或并行备份数据库。

  3. 在备份事务日志前，运行跨越每个数据库的标记事务。

  4. 备份每个数据库上的事务日志。

还原备份：

  1. 还原每个数据库备份。

  2. 还原每个日志备份，到标记事务处停止。

  3. 恢复每个数据库。

当媒体发生故障时，如果希望将所有数据库恢复到标记事务，必须确定可用于所有事务日志的最新标记事务。此信息存储在所有服务器的 msdb 数据库内的 logmarkhistory 表中。

当已确定希望还原到的标记事务时：

  1. 识别所有包含此标记的相关数据库的日志备份。

  2. 按照需要在未损坏的数据库上创建事务日志备份。

  3. 解决硬件问题。

  4. 将所有相关数据库还原和恢复到目标标记。
创建标记事务

可以在已有事务中嵌套 BEGIN TRAN new_name WITH MARK 语句。一旦这样做了，new_name 将变成事务的标记名称，尽管该名称可能已赋予事务。如果发出另一个嵌套 BEGIN TRAN...WITH MARK 语句，将产生警告（但不是错误）信息：

Server: Msg 3920, Level 16, State 1, Line 2
WITH MARK option only applies to the first BEGIN TRAN WITH MARK.
The option is ignored.

事务标记仅放在由标记事务更新的数据库日志中。另外，包含标记的数据库只能是执行 BEGIN TRAN...WITH MARK 语句的服务器上的数据库。下例显示如何在多个数据库中放入标记：

BEGIN TRAN T1
UPDATE db1.dbo.table1 set column1 = 2
BEGIN TRAN M2 WITH MARK
UPDATE db2.dbo.table1 set column1 = 2
UPDATE server2.db21.dbo.table1 set column1 = 2
SELECT * from db3.dbo.table1
COMMIT TRAN M2
UPDATE db4.dbo.table1 set column1 = 2
COMMIT TRAN T1

在此例中，标记名为 M2，将放在数据库 db1、db2 和 db4 的日志中。当为 COMMIT TRAN T1 语句生成事务提交日志记录时，该标记被放在日志中。即使在实际标记事务前执行更新，也会标记 db1。即使已访问过 db3，也不标记 db3，这是因为 db3 中没有进行过任何更新。另外，即使在事务内更新了其它服务器上的 db21，也不标记 db21，因为服务器 2 上实际未执行任何 BEGIN TRAN...WITH MARK。

正如本例显示的那样，当事务扩展到其它服务器时，事务标记名称不会自动分发到其它服务器。为了强制使标记扩展到其它服务器，必须编写包含 BEGIN TRAN name WITH MARK 的存储过程。然后，必须在发起服务器中的事务作用域下，在远程服务器上执行该存储过程。例如，假设有一个位于多个 Microsoft® SQL Server™ 实例上的分区数据库。每个实例上都有一个名为 coyote 的数据库。首先，在每个数据库中创建存储过程 sp_SetMark：

CREATE PROCEDURE sp_SetMark
@name nvarchar (128)
AS
BEGIN TRANSACTION @name WITH MARK
UPDATE coyote.dbo.Marks SET on = 1
COMMIT TRANSACTION
GO

其次，创建存储过程 sp_MarkAll，此过程包含将在每个数据库中放置标记的事务。可以从任何实例中运行 sp_MarkAll：

CREATE PROCEDURE sp_MarkAll
@name nvarchar (128)
AS
BEGIN TRANSACTION
EXEC instance0.coyote.dbo.sp_SetMark @name
EXEC instance1.coyote.dbo.sp_SetMark @name
EXEC instance2.coyote.dbo.sp_SetMark @name
COMMIT TRANSACTION
GO

当提交标记事务时，标记事务中的每个数据库提交日志记录都放在日志的某一点处，以使任何日志中不存在有疑问的事务。此点保证不存在这样的事务：在一个日志中显示为提交，在另一个日志中则显示为未提交。为此，可在提交标记事务的过程中执行下列步骤：

说明 分布式事务的提交分两个阶段进行：准备阶段和提交阶段。

  1. 标记事务的准备阶段将停止所有新的准备和提交。

  2. 只允许继续提交已准备好的事务。

  3. 标记事务阶段此时等待所有已准备的事务全部完成（带超时设置）。

  4. 准备并提交标记事务。

  5. 取消停止新的准备和提交。

由跨多个数据库的标记事务所产生的停止会降低服务器的事务处理性能。

虽然在实际中很少见，但分布式（跨服务器）标记事务有可能与其它同时提交的分布式事务发生死锁。 当发生这种情况时，正在标记的事务将被选作死锁牺牲品并回滚。当此错误发生时，应用程序会重试标记事务。当多个标记事务尝试同时提交时，死锁的可能性更大。因此，建议不要同时运行多个标记事务。

如果数据库使用日志备份，且日志备份链处于活动状态，则可在 logmarkhistory 表中跟踪日志标记：

  • 在事务提交后在后台运行。

  • 每个标记数据库占一行，包含标记名称、描述、提交 LSN 和时间。

  • 生成提交记录前计算时间。

  • 分布式标记的所有条目在给定的 msdb 数据库中具有相同的时间。

  • 全部时间在提交日志记录中都位于时间戳之前。

请参见

BEGIN TRANSACTION

RESTORE

分布式事务构架


管理备份

认真管理备份以确保需要时可还原系统。每个备份都包含创建备份时提供的描述文本以及过期时间信息。这些信息可用于：

  • 标识备份。

  • 确定何时可以放心地重写备份。

  • 标识备份媒体（如磁带）上的所有备份，以确定需要还原的备份。

另外，msdb 数据库包含服务器上所有备份和还原操作的完整历史记录。SQL Server 企业管理器使用这个信息提出和执行还原计划，如果需要还原数据库，就可以执行这个计划。例如，如果每晚创建一次用户数据库的数据库备份，而且白天每小时创建一次事务日志备份，则这些备份历史记录信息就存储在 msdb 数据库中。如果需要还原用户数据库，当使用存储于 msdb 中的历史记录信息还原数据库备份时，SQL Server 企业管理器可以应用与特定数据库备份相关的所有事务日志备份。

说明 如果需要还原 msdb 数据库，最后一次创建 msdb 备份后保存的任何备份历史记录信息都将丢失。

使用备份时：

  • 在安全的地方维护备份，最好在存放数据以外的站点。

  • 将旧备份保留一段指定的时间，以防最新的备份损坏、毁坏或丢失。

  • 建立重写备份的系统，首先重新使用最早的备份。

  • 在备份上使用过期时间，以防过早重写。

  • 标注备份媒体以防重写关键的备份。这样一来，还可以更容易识别备份媒体或特定备份集上存储的数据。

请参见

使用备份媒体

使用媒体集及媒体家族

查看有关备份的信息


备份设备

创建备份时，必须选择存放备份数据的备份设备。Microsoft® SQL Server™ 2000 将数据库、事务日志和文件备份到磁盘和磁带设备上。

磁盘设备

磁盘备份设备是硬盘或其它磁盘存储媒体上的文件，与常规操作系统文件一样。引用磁盘备份设备与引用任何其它操作系统文件一样。可以在服务器的本地磁盘上或共享网络资源的远程磁盘上定义磁盘备份设备，磁盘备份设备根据需要可大可小。最大的文件大小相当于磁盘上可用的闲置空间。

如果在网络上将文件备份到远程计算机上的磁盘，使用通用命名规则名称 (UNC)，以 \\Servername\Sharename\Path\File 格式指定文件的位置。将文件写入本地硬盘时，必须给 SQL Server 使用的用户帐户授予适当的权限，以在远程磁盘上读写该文件。

在网络上备份数据可能受错误的影响，因此请在完成备份后验证备份操作。有关更多信息，请参见验证备份。

重要 建议不要备份到数据库所在的同一物理磁盘上的文件中。如果包含数据库的磁盘设备发生故障，由于备份位于同一发生故障的磁盘上，因此无法恢复数据库。

磁带设备

磁带备份设备的用法与磁盘设备相同，除了：

  • 必须将磁带设备物理连接到运行 SQL Server 实例的计算机上。

    不支持备份到远程磁带设备上。

  • 如果磁带备份设备在备份操作过程中已满，但还需要写入一些数据，SQL Server 将提示更换新磁带并继续备份操作。

说明 无法在运行于 Microsoft Windows® 98 上的 SQL Server 2000 实例上执行备份到磁带设备的操作。

若要将 SQL Server（或 Microsoft Windows NT® 4.0 或 Windows® 2000）数据备份到磁带，请使用 Windows NT 4.0 或 Windows 2000 支持的磁带备份设备或磁带驱动器。另外，对特定的磁带驱动器只使用推荐的磁带（按照驱动器制造商的建议）。有关安装磁带驱动器的更多信息，请参见 Windows NT 4.0 和 Windows 2000 文档。

物理和逻辑设备

SQL Server 使用物理设备名称或逻辑设备名称标识备份设备。

物理备份设备是操作系统用来标识备份设备的名称，如 C:\Backups\Accounting\Full.bak。

逻辑备份设备是用来标识物理备份设备的别名或公用名称。逻辑设备名称永久地存储在 SQL Server 内的系统表中。使用逻辑备份设备的优点是引用它比引用物理设备名称简单。例如，逻辑设备名称可以是 Accounting_Backup，而物理设备名称则是 C:\Backups\Accounting\Full.bak。

备份或还原数据库时，可以交替使用物理或逻辑备份设备名称。

例如，可以用逻辑或物理设备名称执行 BACKUP 语句：

-- Specify the logical backup device.
BACKUP DATABASE accounting
   TO Accounting_Backup
-- Or, specify the physical backup device.
BACKUP DATABASE accounting
   TO DISK = 'C:\Backups\Accounting\Full.Bak'

创建逻辑磁盘备份设备

Transact-SQL

企业管理器

企业管理器

SQL-DMO

创建逻辑磁带备份设备

Transact-SQL

企业管理器

企业管理器

SQL-DMO

删除逻辑备份设备

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

BACKUP

备份设备

RESTORE

创建 SQL Server 文件权限

使用多个媒体或设备


使用备份媒体

备份媒体是备份设备用来存储备份的实际物理存储。备份媒体可以是磁盘，也可以是磁带。

例如，备份设备可以是文件 C:\Backups\Accounting\Full.bak。备份媒体是包含该文件的磁盘。同样，对于磁带，备份设备可以是本地计算机上的 \\.\TAPE0 磁带设备，备份媒体是用来存储备份的物理磁带。

本节讨论备份媒体使用方面的下列内容：

主题 | 描述
使用媒体集及媒体家族 | Microsoft® SQL Server™ 使用媒体集、媒体家族、序列号及其它方法，来正确组织备份并确保每个备份和还原操作都使用正确的媒体。
初始化备份媒体 | 在第一次使用备份媒体前，SQL Server 必须初始化或格式化媒体并写入媒体首部。
密码保护 | SQL Server 2000 允许用密码保护备份。媒体和备份本身不受密码保护。
重写备份媒体 | SQL Server 有防止意外重写媒体的安全措施。另外，SQL Server 可以自动重写已到达预定义过期日期的备份集。
追加备份集 | 可以将新备份集追加到现有媒体上，以便最大可能地利用可用空间。
标识要还原的备份集 | 对备份集进行编号，以便用户可以指定将还原媒体上的哪个备份集。

请参见

BACKUP

RESTORE

使用媒体集及媒体家族


使用媒体集及媒体家族

媒体集可以包含一个或多个备份集并描述那些备份集所用的全部媒体，与所用媒体或备份设备的数量无关。例如，如果使用四个磁带备份设备创建数据库备份，每个磁带备份设备使用五盘磁带存储备份，则媒体集包含 20 盘磁带。

媒体家族描述用于单个备份集的单个备份设备所用的全部媒体。在前面的示例中有四个媒体家族，每个媒体家族由每个磁带备份设备所用的五盘磁带组成。

初始化媒体是媒体家族中的第一个媒体。如果在备份过程中初始化媒体已满，将使用其它的媒体，直到完成备份操作为止。媒体家族中除初始化媒体外的所有其它媒体都称为延续媒体。

说明 只有磁带备份设备使用延续媒体，这使 Microsoft® SQL Server™ 得以在初始化磁带已满后继续写入备份。

为区分媒体家族内使用的每个物理媒体，每个媒体都标记有一个序列号以指定该媒体的使用顺序。初始化媒体的标记为 1，第二个媒体（第一个延续媒体）的标记为 2，依此类推。还原备份集时使用这些序列号，以确保操作员在还原备份时按正确的顺序安装正确的媒体。另外，媒体集内的媒体家族按顺序编号。

当将备份集追加到包含多个媒体家族的媒体集上时，必须装入家族中的最后一个媒体。如果没有装入最后一个媒体，SQL Server 将扫描到媒体的结尾处，并要求更换媒体直到正确装入家族中的最后一个媒体。

每个 SQL Server 备份都存储在媒体集上，与单个备份操作使用的备份设备的数量无关。媒体集的示例包括：

  • 单个磁盘文件。

  • 单个磁带。

  • 一个由一个备份设备写入的磁带集。这个磁带集由单个媒体家族（一个初始化媒体以及一个或多个延续媒体）组成。

  • 一个由四个备份设备写入的磁带集。每个由一个备份设备写入的磁带集是一个媒体家族。每个媒体家族包含一个初始化媒体以及一个或多个延续媒体。

  • 由三个磁盘文件组成的集合，用于一个或多个备份操作，每个备份操作使用三个备份设备。

使用多个备份设备时：

  • 备份操作所创建的整个媒体集必须用于以后的所有备份操作。例如，如果使用两个磁带备份设备创建了一个媒体集，以后所有涉及该媒体集的备份操作都必须使用这两个备份设备。

  • 使用磁带设备还原时，备份设备数不必和创建备份时媒体集所用的数目相同。例如，将数据库移到另一台服务器时可能需要使用很少的备份设备进行还原，因为服务器上可能只有很少的物理备份设备。可以并行还原多个媒体家族。但是，必须还原完一个完整的媒体家族后，才能在给定的磁带设备上开始另一个媒体家族。

请参见

使用备份媒体


初始化备份媒体

在磁带备份设备上首次创建备份时，Microsoft® SQL Server™ 需要在创建备份前初始化备份媒体。初始化媒体时将导致写入媒体首部并删除任何现有的媒体首部，从而有效地删除磁带上以前的内容。初始化磁带后，磁带上以前的信息将无法恢复。

初始化磁盘媒体只涉及备份操作指定的备份设备文件。磁盘上的其它文件不受影响。首次使用备份设备时，SQL Server 自动创建备份设备在备份操作中所需的文件。重新初始化磁盘备份设备将重写备份设备所使用的文件内容并编写新的媒体首部。

创建备份时首次初始化媒体

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO


密码保护

Microsoft® SQL Server™ 2000 对备份媒体和备份集提供密码保护支持。执行备份操作时不需要密码，不过密码可提供额外的安全级别。可以将这些安全级别作为对使用 SQL Server安全角色的补充。使用密码保护将有助于防范：

  • 未经授权地还原数据库。

  • 未经授权地追加到媒体上。

  • 意外重写媒体。

重要 密码安全不能防止通过格式化媒体或对延续卷使用密码来重写媒体。另外，指定密码不会以任何方式加密数据。

可以对媒体集或备份集使用密码：

  • 媒体集密码保护所有保存到此媒体的数据。媒体集密码在写媒体首部时设置，而且不能更改。如果为媒体集指定了密码，必须提供这个密码才能执行任何追加或还原操作。

    只能对 SQL Server 备份和还原操作使用媒体。指定媒体集密码将使 Microsoft Windows NT® 4.0 或 Windows® 2000 备份无法共享媒体。

  • 备份集密码只保护特定的备份集。可以对媒体上的每个备份集使用不同的备份集密码。备份集密码在将备份集写入媒体时设置。如果为一个备份集指定了密码，必须提供这个密--才能对该备份集执行任何还原操作。


重写备份媒体

通过重写媒体上的备份，备份集的现有内容将由新备份重写而不再可用。对于磁盘备份媒体，只重写备份操作中指定的备份设备所使用的文件；磁盘上的其它文件不受影响。重写备份时，可以保留现有的媒体首部，而将新备份创建为备份设备上的第一个备份。如果没有现有的媒体首部，将自动编写一个带相关媒体名称和媒体描述的有效媒体首部。如果现有的媒体首部无效，备份操作将终止。

满足下列任一条件时不重写备份媒体：

  • 媒体上的现有备份尚未过期。

    过期时间指定备份已过期，可由另一个备份重写的日期。创建备份时可以指定过期时间。默认情况下，过期时间由 sp_configure 设置的 media retention 选项确定。

  • 媒体名称（若有）与备份媒体上的名称不匹配。

    媒体名称是一个描述性名称，用于方便地识别媒体。

然而，如果确信要重写现有媒体（例如知道不再需要磁带上的备份），可以显式跳过这些检查。

如果备份媒体受 Microsoft® Windows NT® 4.0 或 Windows® 2000 的密码保护，则 Microsoft SQL Server™ 不写入媒体。若要重写有密码保护的媒体，需要重新初始化媒体。

创建数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

sp_configure


追加备份集

可以将来自相同或不同数据库的、在不同时间执行的备份存储在同一个媒体上。另外，Microsoft® SQL Server™ 数据以外的其它数据可以存储在同一个媒体上，如 Microsoft Windows NT® 4.0 文件备份。通过在现有媒体上追加新的备份集，使媒体上以前的内容保持完好无损，并在媒体上最后一次备份的末尾后写入新备份。

SQL Server 在默认情况下始终在媒体上追加新备份。只能在媒体的末尾追加备份。例如，如果媒体包含五个备份集，则不能跳过前三个备份集而用新备份集重写第四个备份集。

如果将 BACKUP WITH NOREWIND 用于磁带备份，则磁带在操作结束时将保持打开状态。这使您得以在磁带中追加其它的备份，而不用倒带然后再次往前扫描以查找上一个备份集。通过查询 master 数据库中的 sysopentapes 表，可找到当前打开的磁带列表。

Windows NT 4.0、Microsoft Windows® 2000 备份和 SQL Server 备份之间不能相互操作。虽然这两者之间可以共享媒体，但是 SQL Server 备份无法用来备份 Windows NT 4.0 数据。如果没有运行 SQL Server 实例，则可以使用 NTBackup 备份数据库文件。如果正在运行 SQL Server 实例，则不应该依靠 NTBackup 进行文件级备份。

在现有媒体上追加新备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

BACKUP


标识要还原的备份集

将媒体上的每个备份集（包括象 Microsoft® Windows NT® 4.0 文件备份这样的外部备份集）编号。这样将便于引用要还原的备份集。例如，下列媒体包含四个备份集：两个 Microsoft SQL Server™ 备份和两个外部备份集（如 Windows NT 4.0 文件）。

若要还原特定的备份集，请指定想还原的备份集的位置编号。例如，若要还原第二个 SQL Server 备份集（媒体上的第四个备份集），请指定 4 作为要还原的备份集。

还原特定的数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

BACKUP

查看有关备份的信息


备份格式

用于备份或还原操作的所有媒体都使用称为 Microsoft® 磁带格式 (MTF) 的标准备份格式。MTF 使 Microsoft SQL Server™ 备份与非 SQL Server 备份（外部备份集）能够共存于同一个媒体上，只要两个备份都使用 MTF。例如，SQL Server 备份可以与 Microsoft Windows NT® 4.0 和 Windows® 2000 备份共存于同一媒体上。

可以使用同一个磁带媒体存储来自不同应用程序的各种备份，因此将支持 MTF 的任何备份集成到单个磁带上可以减少备份媒体的存储空间需求、成本和管理开销。

所有媒体的开始位置都有一个描述媒体的媒体首部。媒体首部通常只写一次，而且在媒体的生存周期内保持不变。这使得可以对每个媒体进行跟踪。媒体首部可以包含媒体名称，该名称是为具体某个媒体提供的并由第一个使用该媒体的人指派。一致地使用媒体名称可帮助识别媒体和防止错误。

请参见

BACKUP

使用备份媒体

RESTORE HEADERONLY

RESTORE LABELONLY


查看有关备份的信息

创建备份后，可能需要查看有关备份的信息，如：

  • 包含在特定备份集内的数据库文件和事务日志文件列表。

  • 特定备份媒体上的所有备份的备份首部信息。

  • 特定备份媒体的媒体首部信息。
列出数据库文件和事务日志文件

在列出备份内的数据库文件和事务日志文件时所显示的信息包括逻辑名称、物理名称、文件类型（数据库文件或日志文件）、文件组成员资格、文件大小（字节数）、允许的文件最大大小和预定义的文件增长大小（字节数）。在下列情况下，这些信息对于在还原数据库备份之前确定数据库备份内的文件名很有用：

  • 丢失了包含数据库内的一个或多个文件的磁盘驱动器。

    可以列出数据库备份内的文件以确定哪些文件受到影响，然后在还原整个数据库时将那些文件还原到另一个驱动器上，或者只还原那些文件并应用进行数据库备份后创建的任何事务日志备份。

  • 将数据库从一个服务器还原到另一个服务器上，但是目录结构和驱动器映射在这个服务器上不存在。

    列出备份内的文件使您得以确定哪些文件受到影响。例如，备份中包含一个需要还原到驱动器 E 的文件，而目的计算机上却没有驱动器 E。在还原该文件时，需要将它重新定位到其它位置（如驱动器 C）。

查看首部信息

查看备份首部时，将显示媒体上的所有 Microsoft® SQL Server™ 和外部备份集的信息。显示的信息包括使用的备份设备类型、备份类型（数据库备份、事务备份、文件备份还是差异数据库备份）以及备份开始和停止的日期/时间等信息。这些信息对确定还原磁带上的哪个备份集或确定媒体上包含的备份很有用。

说明 查看备份首部信息时需要扫描整个媒体以显示有关媒体上每个备份的信息，因此对高容量磁带可能需要很长时间。

查看媒体首部时显示有关媒体本身的信息，而不显示有关媒体上的备份的信息。显示的媒体首部信息包括媒体名称、描述、创建媒体首部的软件名称以及媒体首部的编写日期。有关所显示首部信息的详细列表的更多信息，请参见 RESTORE LABELONLY。

说明 查看媒体首部很快，因为一次定位在媒体开始位置后就只是读媒体首部了。

下列图表举例说明了备份首部和媒体首部信息的查看方法上的差别。例如，还原下列包含两个 SQL Server 备份和两个外部（Microsoft Windows NT® 4.0 或 Microsoft Windows® 2000）备份的磁带媒体的备份首部信息时，需要检索媒体上所有备份集的信息并扫描整个磁带。然而，还原媒体首部则只需要写在待检索磁带开始处的单个媒体首部中的信息。

查看备份集内的数据和日志文件

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看备份首部信息

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看媒体首部信息

Transact-SQL

企业管理器

企业管理器

SQL-DMO


验证备份

尽管不是必需的，但验证备份仍会检查备份在物理上是否完好无损，以及在需要时该备份是否可以放心使用。验证备份涉及：

  • 检查备份集以确保已写入所有文件。

  • 检查并确定可以读取备份中的文件。

验证备份时不检查备份集内的数据结构是否正确。例如，可能已正确写入了备份集，但是组成备份集的数据库文件中可能存在某种数据库完整性问题。若要在创建备份前验证数据结构，可以执行数据库一致性检查。有关运行数据库一致性检查的更多信息，请参见数据完整性验证。

验证备份集

Transact-SQL

企业管理器

企业管理器

SQL-DMO


备份和还原系统数据库

在备份用户数据库时需要备份系统数据库。这使得在系统或数据库发生故障（例如，如果硬盘发生故障）时可以重建系统。有下列系统数据库的定期备份很重要：

  • master 数据库

  • msdb 数据库

  • distribution 数据库（当服务器配置为复制分发服务器时）

  • model 数据库（如果已修改）

说明 不可能备份 tempdb 系统数据库，因为每次启动 Microsoft® SQL Server™ 实例时都重建 tempdb。SQL Server 实例在关闭时将永久删除 tempdb 中的所有数据。


备份 master 数据库

必须备份 master 数据库。如果 master 数据库以某种方式被损坏（如由于媒体故障），可能无法启动 Microsoft® SQL Server™ 实例。这种情况下，必须重建 master 数据库，然后从备份还原数据库。

在执行任何语句或系统过程更改 master 数据库中的信息（如更改服务器范围的配置选项）后，应考虑备份 master 数据库。如果 master 数据库更改后没有进行备份，任何自上次备份后的更改都将在还原备份时丢失。例如，在备份 master 后创建了一个用户数据库，并将表和数据添加到该数据库。如果后来因硬盘故障而还原 master，则该用户数据库对 SQL Server 将是未知的，因为在已还原的 master 数据库中没有关于此新用户数据库的条目。在这种情况下，如果组成这个用户数据库的所有数据库文件仍在磁盘上，可以通过附加这些数据库文件创建该用户数据库。有关更多信息，请参见附加和分离数据库。

说明 建议不要在 master 数据库中创建用户对象，否则需要更频繁地备份 master 数据库。另外，用户对象会同系统对象争夺空间。

导致 master 数据库更新并需要执行备份的操作类型包括：

  • 创建或删除用户数据库。

    如果用户数据库自动增长以便容纳新数据，这不会影响 master 数据库。删除文件和文件组不影响 master 数据库。

  • 添加登录或执行其它与登录安全有关的操作。

    数据库安全操作（如向数据库中添加用户）对 master 数据库没有影响。

  • 更改任何服务器范围的配置选项或数据库配置选项。

  • 创建或删除逻辑备份设备。

  • 将服务器配置为分布式查询和远程过程调用，如添加链接服务器或远程登录。

说明 只能创建 master 数据库的完整数据库备份。

创建数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

还原 master 数据库


还原 master 数据库

如果 master 数据库以某种方式被损坏（如由于媒体故障），而且损失很严重，则可能无法启动 Microsoft® SQL Server™ 实例。有两种方法将 master 数据库返回到可用状态：

  • 从当前备份还原。

  • 用重建主控实用工具完全重建。

重要 保留最新的 master 数据库备份。使用重建主控实用工具重建 master 数据库时，将导致以前存储在 master 数据库中的所有数据永久丢失。SQL Server 仍能访问其它数据库。

如果由于可以访问 master 数据库（至少部分可用）而能够启动 SQL Server 实例，则可以从完整数据库备份中还原 master 数据库。然而，如果由于 master 数据库严重损坏而无法启动 SQL Server 实例，则不能立即还原 master 数据库的备份，因为 SQL Server 实例需要处于运行状态才能还原任何数据库。首先需要使用重建主控实用工具重建 master 数据库，然后才可以用普通方法还原当前数据库备份。


从当前备份还原 master 数据库

如果创建数据库备份后 master 数据库有任何更改，那些更改将在还原备份时丢失。因此，必须通过执行重新创建丢失的更改所需的语句，在从备份还原 master 数据库后手工重新创建那些更改。例如，如果执行备份后创建了任何 Microsoft® SQL Server™ 登录，那些登录将在还原 master 数据库时丢失。使用 SQL Server 企业管理器或用来创建登录的原始脚本来重新创建登录。

只能从在 SQL Server 2000 实例上创建的备份还原 master 数据库。不支持从在 SQL Server 7.0 版或更早的版本上创建的 master 数据库备份还原。

说明 以前与需要重新创建的登录相关的任何数据库用户都因登录丢失而成为孤立用户。有关使现有的数据库用户与新 SQL Server 登录相关联的信息，请参见 sp_addlogin。有关将现有数据库用户与 Microsoft Windows NT® 4.0 或 Windows® 2000 用户相关联的信息，请参见 sp_grantlogin。

如果备份 master 数据库后创建了任何用户数据库，则一旦还原 master 数据库后将无法访问那些数据库，除非：

  • 从备份还原数据库。

-或-

  • 将数据库重新附加到 SQL Server。建议附加数据库以消除还原时间。

将数据库附加到 SQL Server 会重新创建所需的系统表条目，并使数据库处于 master 数据库还原前的相同状态。不必先重新创建数据库；附加文件时不用知道数据库的创建方式，只需附加组成数据库的所有文件即可。

只有当数据库的数据和事务日志文件已不存在或不可用，或者由于媒体故障而遭到某种形式的破坏时，才需要还原数据库备份。

例如，如果在备份 master 数据库后删除了任何对象、登录或数据库，则应从 master 数据库中将那些对象、登录和数据库删除。

重要 如果有些数据库已不存在，但在还原的 master 数据库备份中引用了这些数据库，那么 SQL Server 可能因找不到那些数据库而在启动时报告错误。还原备份后应除去那些数据库。

还原 master 数据库后，SQL Server 实例将自动停止。如果需要做进一步的修复并希望防止有多个连接与服务器连接，应再次以单用户模式启动服务器。否则，服务器会以正常方式重新启动。如果选择以单用户模式重新启动服务器，应停止所有 SQL Server 服务（SQL Server 本身除外）和实用工具（如 SQL Server 代理程序），因为它们可能尝试访问 SQL Server 实例。

还原了 master 数据库且重新应用了任何更改后，应立即备份 master 数据库。

在单用户模式下启动 SQL Server 的默认实例

命令提示符

命令提示符

在单用户模式下启动 SQL Server 的命名实例

命令提示符

如何在单用户模式下启动 SQL Server 的命名实例（命令提示）

还原 master 数据库

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

附加数据库

Transact-SQL

SQL-DMO

请参见

附加和分离数据库

在单用户模式下启动 SQL Server

系统表


重建 master 数据库

在下列情况下，可以使用重建主控实用工具重建 master 数据库：

  • master 数据库的当前备份不可用。

  • Microsoft® SQL Server™ 实例因 master 数据库已严重损坏而无法启动，因此无法还原备份。

重建 master 数据库后，可以还原 master 数据库的当前备份，或者可以使用 SQL Server 企业管理器或用于创建那些条目的原始脚本，重新创建用户数据库、备份设备、SQL Server 登录等等。

重要 重建主控实用工具完全重建 master 数据库。因为还可能重建 msdb 和 model 系统数据库，所以正常情况下必须还原那些数据库的备份。

如果没有备份可用，完全重建 master 数据库所需的一般步骤是：

  • 运行重建主控实用工具以重建系统数据库。

    重要 重建 master 数据库需要含 SQL Server 安装软件的光盘或共享网络目录。

  • 重新创建任何必需的备份设备。

  • 重新执行安全操作。

  • 如有必要，还原 msdb 数据库。

  • 如有必要，还原 model 数据库。

  • 如有必要，还原 distribution 数据库。

  • 如有必要，还原或附加用户数据库。

重新创建了 master 数据库且重新应用了任何更改后，立即备份 master 数据库。

重建 master 数据库

命令提示符

命令提示符

在单用户模式下启动 SQL Server

命令提示符

命令提示符

还原数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

附加数据库

Transact-SQL

SQL-DMO

请参见

附加和分离数据库

系统表


备份 model、msdb 和 distribution 数据库

model、msdb 和 distribution 数据库的备份方式与用户数据库一样，应在更改后定期备份。这些数据库执行下列功能：

  • 在创建其它数据库（如 tempdb 或用户数据库）时，model 数据库是 Microsoft® SQL Server™ 使用的临时数据库。创建数据库时，model 数据库的全部内容（包括数据库选项）将复制到新数据库中。

  • SQL Server、SQL Server 企业管理器和 SQL Server 代理程序使用 msdb 数据库存储数据，包括调度信息以及备份和还原历史记录的信息。

    SQL Server 在 msdb 数据库中自动维护一个完整的联机备份和还原历史记录。这些信息包括执行备份的人、备份执行时间和存储备份的设备或文件。SQL Server 企业管理器利用这些信息，自动提出一个还原数据库和应用任何事务日志备份的计划。将记录所有数据库的备份事件，即使它们是由自定义应用程序或第三方工具创建的。例如，如果使用 Microsoft Visual Basic® 应用程序调用 SQL-DMO 对象执行备份操作，该事件将记录在 msdb 系统表、Microsoft Windows® 应用程序日志和 SQL Server 错误日志中。

    如果在恢复用户数据库时使用 msdb 中的备份和还原历史记录信息，建议对 msdb 数据库使用将完全恢复模型。另外，考虑将 msdb 事务日志放在容错存储中。

  • SQL Server 的复制组件（如分发代理程序）使用 distribution 数据库存储数据，包括事务、快照作业、同步状态和复制历史记录信息。被配置为远程分发服务器或发布/分发服务器组合的服务器有 distribution 数据库。
备份注意事项

执行任何更新数据库的操作后备份 model、msdb 和 distribution 数据库很重要：

  • 如果 model 数据库因媒体故障而受到某种程度的损坏，而且没有可用的当前备份，任何添加到 model 数据库中的用户专用模板信息都将丢失，需要手工重新创建。

  • 如果 msdb 数据库已损坏，SQL Server 代理程序所使用的任何调度信息都将丢失，需要使用 SQL Server 企业管理器手工重新创建。备份和还原历史记录信息也将丢失。

  • 如果 distribution 数据库已损坏，而且没有可用的当前备份，SQL Server 复制实用工具所使用的任何复制信息都将丢失，需要手工重新创建。为此，应考虑对 distribution 数据库使用完全恢复模型。

model、msdb 和 distribution 数据库支持所有恢复模型。

修改 model、msdb 和 distribution 数据库

可以通过下列方式修改 model、msdb 和 distribution 数据库：

  • 只有特定的用户更改才能修改 model 数据库。

  • msdb 数据库由下列操作自动更改：
    • 调度任务。

    • 将用 DTS 导入/导出向导创建的数据转换服务 (DTS) 包存储到 SQL Server 实例。

    • 维护联机备份和还原历史记录。

    • 复制。
  • distribution 数据库由下列实用工具自动更改：
    • 复制日志读取器代理程序实用工具。

    • 复制分发代理程序实用工具。

    • 复制快照代理程序实用工具。

    • 复制合并代理程序实用工具。

与 master 数据库一样，建议不要在 msdb 和 distribution 数据库中创建用户对象，否则 msdb 和 distribution 数据库需要更频繁地备份。另外，用户对象会同系统对象争夺空间。

请参见

备份和还原数据库

备份和还原复制数据库

配置 SQLServerAgent 服务

复制概述

系统表

使用恢复模型


还原 model、msdb 和 distribution 数据库

在下列情况下，可能需要从备份还原 model、msdb 或 distribution 数据库：

  • 使用 Rebuild master 命令提示实用工具重建了 master 数据库。

  • model、msdb 或 distribution 数据库已损坏（例如由于媒体故障）。

  • 已经修改 model 数据库。在这种情况下，重建 master 数据库时必须从备份还原 model 数据库，因为重建主控实用工具删除和重新创建 model 数据库。

model 和 msdb 数据库只能从在 Microsoft® SQL Server™ 2000 服务器上创建的备份还原。不支持从在 SQL Server 7.0 版或更早的版本上创建的备份还原这些数据库。

如果 msdb 包含系统使用的调度数据或其它数据，则重建 master 数据库时必须还原 msdb 数据库，因为实用工具删除并重建了 msdb 数据库。这将导致丢失所有调度信息以及备份和还原历史记录。如果 msdb 数据库没有还原且无法访问，SQL Server 代理程序则无法访问或启动任何以前的调度任务。

Meta Data Services 将 msdb 用作默认知识库数据库。Meta Data Services 和 msdb 数据库之间打开的连接将中断 msdb 还原。若要释放该连接，请重新启动企业管理器并还原 msdb 数据库。在完全还原 msdb 数据库之前，不要单击企业管理器中的 Meta Data Services 节点。

在使用重建主控实用工具重建 master 数据库时不自动重建 distribution 数据库，因此重建 master 数据库后不必还原 distribution 数据库。如果 distribution 数据库仍没有被改动过，则可通过将数据库附加到 SQL Server 自动重新创建 distribution。另一种方法是还原 distribution 数据库备份。

但是，如果不是通过还原备份或附加数据库重新创建 distribution 数据库，SQL Server 复制实用工具不会运行，这样会防止进行数据复制。如果许多发布服务器都使用 distribution 数据库复制数据，将影响许多系统。

不能还原用户正在访问的数据库。因此，还原 msdb 数据库时，应停止 SQL Server 代理程序。如果 SQL Server 代理程序正在运行，它可能会访问 msdb 数据库。同样，还原 distribution 数据库时，应停止 SQL Server 复制实用工具。如果 SQL Server 复制实用工具正在运行，它可能会访问 distribution 数据库。

必须停止的复制实用工具包括：

  • 复制日志读取器代理程序实用工具。

  • 复制分发代理程序实用工具。

  • 复制快照代理程序实用工具。

  • 复制合并代理程序实用工具。

请参见

附加和分离数据库

备份和还原复制数据库

配置 SQLServerAgent 服务

复制概述


处理大型使命关键环境

使命关键环境通常要求数据库连续可用，或者在最短故障扩展时间内完成维护任务。因此，发生意外事故（如硬件故障）时，还原数据库所需的时间应尽量保持最短。另外，使命关键数据库通常很大，需要较长的时间备份和还原。Microsoft® SQL Server™ 提供了几种提高备份和还原操作速度的方法，从而将在进行这两种操作时对用户造成的影响减到最小：

以下做法将很有帮助：

  • 同时使用多个备份设备，使得备份可以同时写入所有设备。同样，也可以同时从多个设备还原备份。

  • 使用数据库备份、差异数据库备份和事务日志备份的组合，使得将数据库恢复到故障点所用的备份数量减到最少。

  • 使用文件和文件组备份以及事务日志备份，使得可以只备份或还原那些包含相关数据的文件，而不用备份整个数据库。

  • 使用快照备份将备份和还原时间减到最少。第三方供应商支持快照备份。有关更多信息，请参见快照备份。


使用多个媒体或设备

可以在备份和还原操作中使用多个备份设备。这使 Microsoft® SQL Server™ 得以使用并行 I/O 提高备份和还原操作的速度，因为每个备份设备都可以与其它备份设备同时写入或读取。对于有大型数据库的企业，使用多个备份设备可以减少备份和还原操作所需的时间。SQL Server 支持在单个备份操作中最多使用 64 个备份设备。

但是，单个备份（和随之发生的还原）操作中使用的所有备份设备必须属于同一类型（磁盘、磁带）。例如，如果每天使用数据库备份和差异数据库备份将 sales_db 数据库备份到磁带上，则只能使用多个磁带驱动器。

说明 必须在物理上将磁带备份设备附加到服务器上。无法在远程计算机上使用磁带备份设备。

使用多个备份设备创建和还原备份与使用单个设备创建和还原备份相同。两者间的唯一差别是前者要指定操作所涉及的全部备份设备，而不只是一个。例如，如果使用三个磁带备份设备（如 \\.\TAPE0、\\.\TAPE1 和 \\.\TAPE2）创建数据库备份，则需将每个磁带设备指定为备份操作的一部分，尽管以后还原备份时很少会用到这些磁带备份设备。

在可移动介质上使用多个备份设备创建备份时，每个备份媒体不需要具有相同的大小、相同的可用存储量和相同的操作速度。如果在创建备份时备份设备所用的一个备份媒体空间不足，SQL Server 将停止写入这个备份设备，并提示需要新的媒体以继续写入该备份设备。只要这些设备所用的备份媒体有可用空间，备份操作就会在等待有新的媒体插入备份设备的同时，继续将数据写入备份操作所用的任何其它备份设备中。

例如，使用三个速度相同的磁带备份设备存储数据库备份。前两个磁带媒体的大小是 10 吉字节 (GB)，而第三个磁带媒体的大小只有 5 GB。如果将 sales 数据库（其大小为 20 GB）同时备份到所有三个磁带备份设备，备份操作在向第三个备份设备写入 5 GB 的数据后，将停止写入这个设备并提示需要新的磁带。但是，备份操作继续向其它两个备份设备写入数据。用新磁带替换第三个备份设备上的磁带媒体后，备份操作将继续向第三个备份设备写入数据。

将数据库备份写入多个备份设备时会出现几个内部同步点。最重要的同步点出现在已备份完数据库内的所有数据，即将开始备份事务日志时。在这些同步点中，备份操作中使用的所有备份设备都不能被阻塞，否则整个备份操作将被阻塞，直到所有备份媒体都可用为止。例如，使用三个磁带备份设备存储数据库备份，第二个磁带备份设备被阻塞，因为现有磁带上的空间已全部用完，需要用新磁带替换它。如果这时出现同步点，整个备份操作都将停止，直到替换第二个备份设备中的磁带为止。

重要 使用多个备份设备执行备份操作时，所用的备份媒体只能用于 SQL Server 备份操作。有关更多信息，请参见使用备份媒体。

请参见

使用备份媒体

优化备份和还原性能


减少恢复时间

将数据库备份、差异数据库备份和事务日志备份一起使用，可以减少将数据库还原到创建数据库备份后的任何即时点所需的时间。另外，既创建差异数据库备份又创建事务日志备份，可以在事务日志备份或差异数据库备份不可用时（如由于媒体故障），提高备份过程的可靠性。

对使用数据库备份、差异数据库备份和事务日志备份的典型备份过程，以较长的间隔创建数据库备份，以中等间隔创建差异数据库备份，以较短的间隔创建事务日志备份。例如，每周创建一次数据库备份，每天创建一次或多次差异数据库备份，每十分钟创建一次事务日志备份。

如果需要将数据库恢复到故障点（如由于系统故障）：

  1. 备份当前活动事务日志。如果事务日志已损坏，此操作将失败。

  2. 还原上次创建的数据库备份。

  3. 还原自创建数据库备份后创建的最后一个差异备份。

  4. 按顺序应用自上次创建差异备份后创建的所有事务日志备份，直到应用在第 1 步中创建的事务日志备份为止。

说明 如果无法备份活动事务日志，则只能将数据库还原到创建最后一个事务日志备份时的点。自上一次事务日志备份后对数据库所做的更改将丢失，必须手工重做。

通过一起使用差异数据库备份和事务日志备份将数据库还原到故障点，可以减少还原数据库所需的时间，因为只需要应用自上次创建差异数据库备份后创建的事务日志备份。如果没有创建差异数据库备份，则需要应用自备份数据库后创建的所有事务日志备份。

例如，使命关键的数据库系统要求每晚午夜创建一次数据库备份，从星期一到星期六每小时创建一次差异数据库备份，一天内每 10 分钟创建一次事务日志备份。如果需要将数据库还原到星期三凌晨 5:19 时的状态：

  1. 还原在星期二晚上创建的数据库备份。

  2. 还原在星期三凌晨 5:00 创建的差异数据库备份。

  3. 应用在星期三凌晨 5:10 创建的事务日志备份。

  4. 应用在星期三凌晨 5:20 创建的事务日志备份，并指定恢复进程只应用在凌晨 5:19 之前所发生的事务。

或者，如果需要将数据库还原到星期四凌晨 3:04 时的状态，但是在星期四凌晨 3:00 创建的差异数据库备份不可用：

  1. 还原在星期三晚上创建的数据库备份。

  2. 还原在星期四凌晨 2:00 创建的差异数据库备份。

  3. 应用从星期四凌晨 2:10 到凌晨 3:00 之间创建的所有事务日志备份。

  4. 应用在星期四凌晨 3:10 创建的事务日志备份，并指定恢复进程只应用在凌晨 3:04 之前所发生的事务。

创建数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

创建差异数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

创建事务日志备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

创建当前活动事务日志的备份

Transact-SQL

Transact-SQL

SQL-DMO

还原数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

还原差异数据库备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

应用事务日志备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

事务日志备份


使用文件备份

可以备份和还原数据库中的个别文件。这样将使您得以只还原已损坏的文件，而不用还原数据库的其余部分，从而加快了恢复速度。例如，如果数据库由几个在物理上位于不同磁盘上的文件组成，当其中一个磁盘发生故障时，只需还原发生了故障的磁盘上的文件。

文件备份和还原操作必须与事务日志备份一起使用。因此，文件备份只适用于完全恢复模型和大容量日志记录恢复模型。有关恢复模型的更多信息，请参见选择恢复模型。

文件备份提供了下列优点：

  • 能够更快地恢复已隔离的媒体故障。可以迅速还原损坏的文件。

  • 可以同时创建文件和事务日志备份，使您得以维护定期日志备份调度。

  • 文件备份在调度和媒体处理上具有更大的灵活性。例如，对于超大型数据库，完整数据库备份可能变得无法管理。

    这种灵活性还适用于大型数据库，这类数据库所包含的数据具有各种更新特性。

若要最大程度地发挥这些优势，应考虑数据的布局和使用模式。建议做如下工作：

  • 经常备份频繁改动的数据。

  • 不经常备份很少改动的数据。

  • 一次性备份只读数据。

说明 还原文件备份时，必须前滚事务日志以确保该文件与数据库的其余部分一致。为了避免在很少备份的文件上前滚许多事务日志备份，应使用文件差异备份。有关更多信息，请参见文件差异备份。

文件组备份与文件备份的作用相同。文件组备份是文件组中所有文件的单个备份，相当于在创建备份时显式列出文件组中的所有文件。可以还原文件组备份中的个别文件，也可以将所有文件作为一个整体还原。

一次只能进行一个文件备份操作。可以在一个操作中备份多个文件，但是如果只需还原一个文件，这样做将增加恢复时间，因为需读取整个备份以定位要还原的文件。

完整的文件备份集同覆盖文件备份创建时间的事务日志备份合在一起相当于数据库备份。

说明 可以从数据库备份还原个别的文件。这意味着可以将数据库备份和事务日志备份作为备份过程使用，而且仍能还原个别的文件。不过，从数据库备份定位和还原文件所需的时间比从文件备份长。

与数据库备份相比，文件备份的主要缺点是增加了管理的复杂性。必须注意维护完整的文件备份集和覆盖的日志备份。如果已损坏的文件没有备份，则媒体故障可能导致整个数据库无法恢复。

在创建文件备份时，备份操作不捕获事务日志。必须在创建文件备份后才能创建事务日志备份。还原文件后，必须还原自创建文件备份后创建的事务日志备份以使数据库处于一致状态。

  • 可以通过使用文件差异备份减少恢复时间。有关更多信息，请参见文件差异备份。
还原文件备份

还原文件后，必须还原自创建文件备份后创建的事务日志备份以使数据库处于一致状态。可以快速前滚事务日志备份，因为只应用已还原文件所应用的更改。

从文件备份还原已损坏的文件：

  1. 备份活动事务日志。如果因为日志已损坏而无法备份，则必须还原整个数据库。

  2. 从该文件的最新备份还原每个已损坏的文件。

  3. 按顺序还原事务日志备份，从包含最早的已还原文件的备份开始。

  4. 还原在步骤 1 中创建的活动事务日志备份。

  5. 恢复数据库。

重要 Microsoft® SQL Server™ 要求将文件恢复到与数据库其余部分一致的状态。不能提早停止恢复个别文件。因此，必须始终在还原文件备份前备份活动事务日志。如果事务日志损坏或想将整个数据库恢复到特定的即时点，则必须在应用事务日志备份前还原整个文件备份集。若要将事务日志损坏的危险性减到最低程度，请将事务日志存放在容错存储上。

还原整个数据库的过程与此类似。唯一的差别是所有文件都要还原。文件备份还可以用于将数据库还原到更早的即时点。为此，必须还原完整的文件备份集，然后按顺序还原事务日志备份以达到想要的即时点。可以在某个时间或某个标记的事务处停止。

有关时点恢复的更多信息，请参见将数据库还原到前一个状态。

备份文件和文件组

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

应用事务日志备份

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

还原文件和文件组

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

文件和文件组

在文件组上放置索引

在文件组上放置表


文件差异备份

可以创建文件差异备份，以便只备份自上次文件备份后所更改的数据。文件差异备份可以减少必须还原的事务日志量，从而大大减少了恢复时间。在 Microsoft® SQL Server™ 2000 中，文件差异备份的速度可以非常快，因为 SQL Server 2000 跟踪自上次备份文件后所发生的更改，因此不需扫描文件。

在下列情况下，可考虑使用文件差异备份：

  • 与其他人相比，很少备份某些文件。

  • 文件很大而且数据不常更新，或者重复更新相同的数据。

  • 已备份了只读文件。最新的文件差异备份将消除应用很多日志备份以恢复文件的需要。

文件差异备份只能与文件备份一起使用，而且只受完全恢复模型和大容量日志记录恢复模型的支持。有关更多信息，请参见使用文件备份和选择恢复模型。

从文件备份和文件差异备份还原已损坏的文件：

  1. 备份活动事务日志。如果因为日志已损坏而无法备份，则必须还原整个数据库。

  2. 从该文件的最新文件备份还原每个已损坏的文件。

  3. 还原在步骤 2 中还原的每个文件的最新文件差异备份。

  4. 按顺序还原事务日志备份，从包含最早的已还原文件的备份开始。

  5. 还原在步骤 1 中创建的活动事务日志备份。

  6. 恢复数据库。

还原整个数据库的过程与此类似。唯一的差别是所有文件都要还原，而且可以恢复到特定的即时点或某个命名事务处。

与可用备份有关的信息包含在 msdb 中。如果 msdb 不可用，则可以通过备份本身获得该信息。

最好不要在同一数据库上同时使用数据库差异备份和文件差异备份。


快照备份

Microsoft® SQL Server™ 2000 与独立的硬件和软件供应商合作，提供对快照备份和还原技术的支持。快照备份可避免使用服务器资源来完成备份。这对中等和大型数据库特别有益，在这些数据库中，可用性极其重要。此项技术的主要优点是：

  • 可以在很短的时间内创建备份（通常以秒为单位），且对生产影响很小甚至没有影响。

  • 可以极快的速度从磁盘备份完成还原。

  • 可以通过其它主机完成磁带备份，对生产系统没有任何影响。

  • 可以出于报告或测试的目的立即创建生产数据库的复本。

可以创建整个数据库或个别文件的快照备份。快照备份与普通的完整数据库备份和文件备份的作用相同，而且可以使用普通的差异备份和日志备份前滚。与其它备份一样，快照备份和还原记录在 msdb 中。

快照备份和还原功能可通过与第三方硬件和/或软件供应商的合作得以实现。这些供应商使用为此目的设计的 SQL Server 2000 功能。基础备份技术创建所备份数据的即时复本。这一点的实现方法一般是：拆分镜像磁盘集，或在写入磁盘块时创建复本以保留原始磁盘块。当还原时，使原始磁盘块立即可用并在后台完成基础磁盘的同步，并导致几乎即刻还原。

有关更多信息，请参见位于 Microsoft Web Site 的 SQL Server 页。另外，可以与企业存储和/或备份软件供应商联系。


将数据库复制到其它服务器

创建数据库备份使您得以将数据从一台计算机复制到另一台计算机。可以使用复制的数据库进行测试、一致性检查、软件开发、运行报表或远程分支操作可以使用的数据库生成。通过将数据库从一台计算机复制到另一台计算机，可以减少资源争夺，因为处理过程将卸载到其它计算机。还原到单独计算机上的复制数据库通常用于只读操作。

说明 在 Microsoft® SQL Server™ 2000 中，待复制数据库的排序次序和代码页已不再是问题。SQL Server 现在处理多种排序规则。

也可以将数据库复制到另一台计算机，使其作为备用服务器使用。定期将数据库和事务日志复制到另一台计算机，如果主计算机因某个原因发生故障，这台计算机可以作为主计算机联机使用。主计算机和备用服务器之间的同步级别取决于两个因素：主计算机进行定期备份的频率和备用服务器应用定期备份的频率。有关更多信息，请参见使用备用服务器。

说明 可以在运行 Microsoft Windows NT® 4.0、Windows® 2000 和 Windows® 98 上的 SQL Server 实例的计算机间备份和还原数据库。

在多个 SQL Server 实例间复制数据的其它方法包括：

  • 使用数据转换服务 (DTS) 导入/导出向导，在任何 ODBC、OLE DB 或文本数据源与 SQL Server 实例之间复制和修改数据。

  • 使用 bcp 实用工具，以本机、字符或 Unicode 模式在 SQL Server 实例与数据文件之间复制数据。

  • 使用 INSERT 语句，将分布式查询用作选择列表以从另一个数据源析取数据。

  • 使用复制数据库向导，在服务器之间复制或移动数据库及相关元数据。

请参见

bcp 实用工具

DTS 导入/导出向导

使用备用服务器

使用复制数据库向导


复制数据库

将数据库复制到另一台计算机所需的一般步骤是：

  1. 从运行 Microsoft® SQL Server™ 实例的源计算机备份数据库。

  2. 如果需要，在运行 SQL Server 实例的目的计算机上创建备份设备。

  3. 将数据库备份还原到目的计算机。还原备份前不必创建文件或数据库。
重新创建数据库文件

还原数据库将自动创建所需的文件，以将数据库备份还原到这些文件中。还原备份前不必创建数据库文件（也就是数据库）。默认情况下，SQL Server 在还原进程中创建的文件与源计算机上原始数据库中的备份文件使用相同的名称和路径。因此，提前知道由还原操作自动创建的文件很有用，因为：

  • 这些文件名可能在计算机上已经存在，这会导致错误。

  • 目录结构或驱动器映射可能在计算机上不存在。

    例如，备份中包含一个需要还原到驱动器 E 的文件，而目的计算机上却没有驱动器 E。

  • 如果允许替换数据库文件，则与备份中的文件同名的现有数据库和文件将被重写，除非这些文件属于不同的数据库。
移动数据库文件

如果由于前面提到的原因，无法将数据库备份内的文件还原到目的计算机上，则必须在还原这些文件时将它们移到新的位置。例如：

  • 由于容量方面的原因，可能必须将备份中的一些数据库文件还原到不同的驱动器上。这种情况很可能经常发生，因为单位中大多数计算机的磁盘驱动器的数目和大小不同或软件配置不同。

  • 可能需要出于测试的目的，在相同的计算机上创建现有数据库的复本。在这种情况下，原始数据库的数据库文件已经存在，因此在还原操作过程中创建数据库复本时，需要指定不同的文件名。
更改数据库名称

在将数据库还原到目的计算机时可以更改其名称，而不必先还原数据库然后手工更改名称。例如，可能有必要将数据库名称由 Sales 改成 SalesCopy，以指出这是数据库的一个复本。

还原数据库时显式提供的数据库名称自动用作新的数据库名称。因为数据库名称尚不存在，将使用备份中的文件创建新的数据库名称。

数据库所有权

将数据库还原到另一台计算机时，启动还原操作的 SQL Server 登录、Microsoft Windows NT® 4.0 或 Windows® 2000 用户自动成为新数据库的所有者。还原数据库时，系统管理员或新数据库所有者可以更改数据库所有权。若要防止未经授权地还原数据库，请使用媒体或备份集密码。有关更多信息，请参见密码保护。

还原全文索引数据

如果待复制的数据库中包含为全文索引定义的表，则目的计算机也必须已安装全文检索并启动 MSSearch 服务，才能重新创建和重新填充全文目录。

用于全文索引定义的元数据存储在数据库的系统表中，因此提前知道源计算机上的全文目录是否驻留在驱动器和目录上而不是默认的位置很重要。这些目录或驱动器映射可能在目的计算机上不存在，必须首先创建。若要查看全文目录在源计算机上的位置，请执行 sp_help_fulltext_catalogs 系统存储过程。PATH 列值是在目的计算机上重新创建全文目录的位置。如果结果集的 PATH 列值是 NULL，则表示默认的全文目录位置。

查看备份集内的数据和日志文件

Transact-SQL

企业管理器

企业管理器

SQL-DMO

在现有文件上还原文件和文件组

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

将文件和文件组还原到新位置

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

用新名称还原数据库

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

重新开始被中断的还原操作

Transact-SQL

Transact-SQL

SQL-DMO

更改数据库的所有者

Transact-SQL

SQL-DMO

请参见

RESTORE

RESTORE FILELISTONLY

事务日志备份


从早期的 SQL Server 版本复制数据库

在 Microsoft® SQL Server™ 2000 中，可以还原使用 SQL Server 7.0 版创建的数据库备份。也可以使用复制数据库向导从 SQL Server 7.0 中复制数据库。有关更多信息，请参见使用复制数据库向导。

然而，不能通过 SQL Server 2000 还原使用 SQL Server 7.0 创建的 master、model 和 msdb 备份。另外，也不能还原使用 SQL Server 6.5 版或更早的版本创建的数据库备份。使用 SQL Server 6.5 版或更早的版本创建的数据库备份的格式与 SQL Server 2000 不兼容。

不过，可以通过以下操作之一，将使用 SQL Server 6.5 版或更早的版本创建的数据库转换为 SQL Server 2000 数据库：

  • 升级到 SQL Server 2000。

    任何数据库都自动升级。现在可以将新备份从运行 SQL Server 的升级计算机还原到另一台运行 SQL Server 2000 实例的计算机中。

  • 使用数据转换服务 (DTS) 导入/导出向导在多个 SQL Server 实例间复制数据。

  • 使用 bcp 实用工具将数据从运行 SQL Server 6.5 或更早版本实例的计算机复制到一个数据文件，然后将这个数据文件中的数据复制到运行 SQL Server 2000 实例的计算机中。

请参见

DTS 导入/导出向导

导入和导出数据

升级 SQL Server 6.5 数据库（升级向导）


使用复制数据库向导

复制数据库向导使您得以在服务器之间复制或移动数据库。可以在 Microsoft® SQL Server™ 2000 的不同实例之间移动和复制数据库，还可将数据库从 SQL Server 7.0 版升级到 SQL Server 2000。有关更多信息，请参见升级 SQL Server 7.0 数据库（复制数据库向导）。

使用复制数据库向导联机升级数据库

向导

向导

还可以通过将 SQL Server 7.0 版或 SQL Server 2000 的多个实例集成为单个 SQL Server 2000 实例，或者集为一台计算机上的多个命名实例，简化数据库的管理和维护工作。

除复制实际的数据库外，还可以复制相关联的元数据（例如，所复制的数据库所需的、来自 master 数据库的登录和对象）。

说明 不能用复制数据库向导复制或移动 model、msdb 或 master 数据库。

复制和移动过程

若要使用复制数据库向导，必须是系统管理员或者是 sysadmin 角色成员。如果您正在运行 Microsoft Windows NT® 4.0 或 Microsoft Windows® 2000，则您的用户帐户必须有管理员权限。

若要使用复制数据库向导，必须指定：

  • 要复制的数据库所驻留的源服务器。

  • 目的服务器，即数据库要复制或移动到的服务器。

    数据库在目的服务器上的名称与在源服务器上的名称保持一致。因而，只有源名称在目的服务器上不存在的数据库才能复制或移动。在移动或复制操作过程中，不能重命名数据库。必须在移动或复制数据库之前手工解决名称冲突。

  • 要移动或复制的数据库。

    为避免数据丢失或不一致，必须确保正在移动或复制的数据库上没有活动会话。如果存在活动会话，复制数据库向导将不会运行。

  • 要复制或移动的其它对象（例如来自 master 数据库的登录和共享对象、作业和维护计划以及用户定义的错误信息）。

  • 复制或移动操作的调度（如果希望以后运行该操作）。

当在不同的服务器或磁盘驱动器之间移动数据库时，复制数据库向导将把数据库复制到目的服务器，并验证其是否联机。该向导不会从源服务器中删除数据库。验证了复本完全可操作后，必须从源服务器中手工删除相关文件。当在同一台服务器上的两个实例之间移动数据库时，会执行文件系统移动操作。


管理服务器

Microsoft® SQL Server™ 服务器管理由多种管理任务组成，其中包括：

  • 注册服务器和指派密码。

  • 重新配置网络连接。

  • 配置链接服务器，从而使您得以对整个企业内的 OLE DB 数据源执行分布式查询和分布式事务。

  • 配置远程服务器，使您得以使用某个 SQL Server 实例执行驻留在另一 SQL Server 实例上的存储过程。

  • 配置备用服务器。

  • 设置服务器配置选项。

  • 管理 SQL Server 消息。

  • 设置轮询间隔。

在大多数情况下，您无须重新配置服务器。SQL Server 安装过程中将按照默认设置对服务器组件进行配置，使您得以在安装结束时立即运行 SQL Server。但是在下列情况下需要进行服务器管理：如要添加新的服务器，设置特定的服务器配置，更改网络连接，或者设置服务器配置选项以提高 SQL Server 性能。


注册服务器

必须注册本地或远程服务器后，才能使用 SQL Server 企业管理器来管理这些服务器。在注册服务器时必须指定：

  • 服务器的名称。

  • 登录到服务器时使用的安全类型。

  • 如果需要，指定登录名和密码。

  • 注册了服务器后想将该服务器列入其中的组的名称。

还可以选择显示控制台中的 Microsoft® SQL Server™ 状态、自动启动 SQL Server 实例或显示系统数据库和系统对象。当注册服务器时，前两个选项是默认选择。

第一次运行 SQL Server 企业管理器时，它将自动注册本地 SQL Server 所有已安装实例。但是，如果有一个已注册的 SQL Server 实例，然后安装更多的 SQL Server 实例，则只注册最初的 SQL Server 实例。可以启动注册服务器向导或使用"已注册的 SQL Server 属性"对话框来注册其它的服务器。"已注册的 SQL Server 属性"对话框由所有 SQL Server 本地实例的名称填充。

如果连接到远程服务器有困难，可以使用客户端网络实用工具来配置对该服务器的访问。

注册服务器

企业管理器

企业管理器

Transact-SQL

SQL-DMO

删除 SQL Server 服务器

企业管理器

企业管理器

SQL-DMO

更改服务器的注册

企业管理器

企业管理器

SQL-DMO

连接运行 SQL Server 的注册服务器

企业管理器

企业管理器

断开与运行 SQL Server 的注册服务器的连接

企业管理器

企业管理器

请参见

配置远程服务器

客户端网络实用工具


创建服务器组

可以在 SQL Server 企业管理器内创建一个服务器组，并将服务器放在该服务器组中。服务器组提供了一种便捷方法，可将大量的服务器组织在几个易于管理的组中。

创建服务器组

企业管理器

企业管理器

SQL-DMO


访问服务器注册选项

Microsoft® SQL Server™ 使您得以维护共享或专用的注册信息。共享的注册信息允许多个用户使用同一台本地计算机或中央计算机中的相同配置。与此相反，专用注册信息可防止其他人访问您的配置。

有两种方法可以访问服务器注册信息：

  • 远程访问，注册信息位于称作中央存储的中央计算机上。

    远程访问存储在中央计算机上的服务器信息使不同的客户计算机得以查看共享的注册信息。例如，系统管理员注册服务器 x、y 和 z 来查看服务器活动。利用中央注册存储，系统管理员能够从任何客户端查看所有的服务器。

    说明 若要从远程服务器读取服务器注册信息，必须注册服务器并在远程计算机上禁用"与用户无关的存储"选项。

  • 本地访问，访问专用或共享信息。

    系统管理员可以从本地计算机更改中央存储，并在不启用"与用户无关的存储"选项的情况下配置 SQL Server 企业管理器来保存注册信息。"与用户无关的存储"选项使所有的用户得以共享注册信息。当该选项禁用时，中央存储将为每个用户维护专用注册信息。

建立服务器注册信息的中央存储

企业管理器

企业管理器

设置对您显示的服务器和组的访问

企业管理器

企业管理器

SQL-DMO


指派 sa 密码

安装 Microsoft® SQL Server™ 时，SQL Server 安装程序不给 sa 登录指派密码。可以在安装完服务器后给 sa 指派密码。

如果将服务器安全性设置为混合模式，应指派 sa 密码。如果将服务器设置为 Windows 身份验证模式，则不需要 sa 密码，因为 sa 是 SQL Server 登录。

重要 如果不能提供正确的 sa 密码，就必须重新安装 SQL Server。

第一次登录到 SQL Server 实例时，请使用 sa 作为登录标识并且不使用密码。在登录之后，请更改 sa 密码以防止其他用户使用 sa 权限。

说明 必须先注册服务器以使用 SQL Server 企业管理器，才能更改 sa 密码。

在新安装的服务器上指派 sa 密码

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

安全管理


管理 AWE 内存

Microsoft® SQL Server™ 2000 使用 Microsoft Windows® 2000 Address Windowing Extensions (AWE) API 以支持非常大的内存空间。SQL Server 2000 可使用 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 允许使用的所有内存空间。有关 AWE API 的更多信息，请在 MSDN® Online Microsoft Web 中搜索"awe memory"主题。

说明 仅有 SQL Server 2000 企业版和开发版提供此项功能。

使用 AWE 内存

若要使用 AWE 内存，必须在 Windows 2000 帐户下运行 SQL Server 2000 数据库引擎，并且已为该帐户指派了 Windows 2000 的"锁定内存页"特权。

SQL Server 安装程序将自动授予 MSSQLServer 服务帐户使用"锁定内存页"选项的权限。如果正在使用 sqlservr.exe 从命令提示符下启动 SQL Server 2000 实例，则必须使用 Windows 2000 组策略实用工具 (gpedit.msc) 为交互式用户帐户手工指派该权限，否则在未作为服务运行时，SQL Server 将不能使用 AWE 内存。

启用锁定内存页选项

Windows

Windows

若要使 SQL Server 2000 实例能够使用 AWE 内存，应设置 sp_configure 选项为 awe enabled。然后，重新启动 SQL Server 以激活 AWE。因为从 SQL Server 启动到 SQL Server 关机这段时间内一直启用 AWE 选项，所以，当 awe enabled 处于使用状态时，SQL Server 将通过向 SQL Server 错误日志发送"已启用 Address Windowing Extension"消息通知用户。有关 awe enabled 配置选项的更多信息，请参见 awe enabled 选项。

有关使用 AWE 内存的更多信息，请参见 Windows 2000 文档。

AWE 内存和系统资源

当启用 AWE 内存时，SQL Server 2000 实例并不动态管理地址空间的大小。因此，当启用 AWE 内存并启动 SQL Server 2000 实例时，将出现以下情况：

  • 如果已设置 sp_configure max server memory 并且计算机上至少有 3 吉字节 (GB) 的可用空间，则实例将获得 max server memory 所指定的内存空间。如果计算机上可用内存空间小于 max server memory（但大于 3 GB），则实例将获得几乎所有的可用内存，并可能至多剩下 128 兆字节 (MB) 的可用内存。

  • 如果尚未设置 max server memory 并且计算机上至少有 3 GB 的可用内存，则实例将获得几乎所有的可用内存并可能至多剩下 128 MB 的可用内存。

  • 如果计算机上可用内存不足 3 GB，则动态分配内存，并且，不管 awe enabled 的参数设置如何，SQL Server 都将以非 AWE 的模式运行。
评估内存使用

不能将使用 AWE 的 SQL Server 2000 实例的内存池换出到页文件中。如果 Windows 2000 需要使用附加的物理内存，则必须换出其它应用程序，但这可能干扰其它应用程序的性能。

因此，必须确保除所有 SQL Server 实例使用的内存之外还有足够的内存，可满足计算机上运行的其它应用程序的虚拟内存需求。

使用系统监视器（Microsoft Windows NT® 4.0 中的性能监视器）检索有关 SQL Server 内存使用及可用内存的信息。任务管理器不为 AWE 提供准确的内存使用信息。因此，报告的 sqlservr.exe 所占用的内存量并不正确。若要获得正确的 SQL Server 内存使用情况，可使用"总的服务器内存 (KB)"性能计数器（该计数器可通过系统监视器激活），或从 sysperfinfo 中选择内存使用。有关更多信息，请参见监视内存的使用。

运行多个实例

如果正在同一台计算机上运行多个 SQL Server 2000 实例，而每个实例都使用 AWE 内存，则必须确保：

  • 每一个实例都有 max server memory 设置。

  • 所有实例的 max server memory 值的总和小于计算机的物理内存量。

    如果设置总和超过了计算机的物理内存，则一些实例或者不能启动，或者其内存将小于 max server memory 中指定的内存大小。例如，假设某计算机具有 16 GB 的物理 RAM，并且该计算机上运行 3 个 SQL Server 2000 实例。此外，每个实例的 max server memory 设置为 8 GB。如果停止并重新运行所有 3 个实例，则：

    • 第一个实例启动时使用全部 8 GB 内存。

    • 第二个实例启动时使用的内存将略低于 8 GB（最多减少 128 MB）。

    • 第三个实例将以动态内存模式启动，此时只剩 128 MB 或更少的可用内存。
Windows 2000 使用考虑

针对 AWE 内存配置 Windows 2000 之前，请考虑以下事项：

  • 若要启用 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 支持大于 4 GB 的物理内存，必须将参数 /pae 添加到 boot.ini 文件中。

  • 若要启用 Windows 2000 Advanced Server 和 Windows 2000 Datacenter Server 支持 3-GB 虚拟地址空间，必须将参数 /3gb 添加到 boot.ini 文件中。这使用户应用程序得以对 3 GB 的虚拟内存进行寻址，并为操作系统保留 1 GB的虚拟内存。

    但是，如果计算机上有超过 16 GB 的可用物理内存，Windows 2000 则需要 2 GB 的虚拟内存地址空间供系统使用，因此，只能支持 2-GB 的虚拟地址空间。

    为了使 AWE 能够使用超过 16 GB 的内存范围，应确保 boot.ini 文件中无参数 /3gb。否则，Windows 2000 将不能对超过 16 GB 的任何内存进行寻址。当在 32-GB 系统上分配 SQL Server AWE 内存时，Windows 2000 可能需要至少 1 GB 的可用内存以便管理 AWE。因此，在启用 AWE 的情况下启动 SQL Server 实例时，建议最好不要使用默认的 max server memory 设置，而应将其限制为 31 GB 或更少。

有关更多信息，请参见使用 Windows 2000 上的 AWE 内存。

使用故障转移群集

如果正在使用 SQL Server 2000 故障转移群集和 AWE 内存，则必须确保所有实例的 max server memory 设置值总和小于故障转移群集内任何服务器的最小可用物理 RAM 量。如果故障转移节点的物理内存比原节点少，则 SQL Server 2000 实例可能无法启动，或者可能以比在原节点上少的内存启动。

请参见

SQL Server:Buffer Manager 对象

sp_configure

故障转移群集


配置网络连接

服务器管理包括重新配置 Microsoft® SQL Server™ 服务器网络连接。大多数情况下，无须更改服务器网络连接。仅在下列情况中才需重新配置服务器连接：

  • 配置 SQL Server 实例以在特定的网络协议上监听。

  • 使用代理服务器连接 SQL Server 实例。

  • 使用防火墙系统将包含 SQL Server 实例的网络与 Internet 的其余部分隔开。


Net-Library 和网络协议

必须在客户计算机和服务器计算机上安装一对匹配的 Microsoft® SQL Server™ Net-Library 以支持特定的网络协议（例如，客户端 TCP/IP 套接字 Net-Library 与服务器 TCP/IP 套接字 Net-Library）。一些 Net-Library，例如命名管道和多协议，可支持多个网络协议。

所有 SQL Server 客户端 Net-Library 和服务器 Net-Library 都由 SQL Server 安装程序安装。默认情况下，在安装期间：

  • 命名管道与 TCP/IP 套接字在 Microsoft Windows NT® 4.0 或 Windows® 2000 服务器上监听。

  • TCP/IP 与共享内存在 Microsoft Windows 98 服务器上监听。（共享内存是仅用于同一台计算机上的客户端/服务器连接的 Net-Library。共享内存 Net-Library 不需要配置。）

安装和配置了网络连接后，SQL Server 可以同时监听任何服务器 Net-Library 的组合。

客户端和服务器上应已安装了正确的网络协议。网络协议通常在 Windows 安装过程中安装；它们不是 SQL Server 安装的一部分。只有当客户端和服务器上都已安装了与 SQL Server Net-Library 相对应的网络协议时，SQL Server Net-Library 才有效。

启动后激活服务器 Net-Library

如果已经安装了 SQL Server 并想更改服务器 Net-Library，请启动 SQL Server 网络实用工具。此实用程序使您得以激活、停用和重新配置服务器 Net-Library，以便在与其相对应的网络协议上监听客户端。

Windows 98 服务器和命名管道

当 SQL Server 在 Windows 98 上运行时，它不支持服务器命名管道 Net-Library。如果 SQL Server 运行在 Windows 98 服务器上，则必须将客户端的默认 Net-Library 更改为 TCP/IP 套接字或多协议，或者必须在客户端创建使用上述 Net-Library 之一的新配置项。

配置客户端

在激活适当的服务器 Net-Library 以支持特定的网络协议之后，必须配置所有通过该网络协议访问服务器的客户机。使用客户端网络实用工具：

  • 设置新的配置项以连接到特定的服务器。

  • 更改客户端使用的默认 Net-Library，以支持在服务器上新配置的 Net-Library；不过，所选择的客户端 Net-Library 将成为该客户端建立的所有连接的默认 Net-Library。

请参见

客户端网络实用工具

通讯组件

配置客户端网络连接

管理客户端

客户端 Net-Library 和网络协议

SQL Server 网络实用工具


SQL Server 网络实用工具

大多数情况下，不需要重新配置 Microsoft® SQL Server™ 在其它的服务器 Net-Library 上监听。然而，如果默认情况下 SQL Server 不在服务器所使用的网络协议上监听（例如，如果服务器使用的是 NWLink IPX/SPX），并且没有激活用于该协议的 SQL Server 服务器 Net-Library 以监听 SQL Server 客户端，则必须使用 SQL Server 网络实用工具。

尽管服务器 Net-Library 配置操作对使 SQL Server 应用程序能够连接任何 SQL Server 实例并不是必不可少的，但仍可以：

  • 在数据库计算机中为每个 SQL Server 实例管理服务器 Net-Library 属性。

  • 启用 SQL Server 实例将要监听的服务器协议。例如，启用用于 VIA（虚拟接口构架）的协议。当该协议与特定硬件一起使用时，将提供高可靠性和高效的数据传输。若要使 VIA 发挥作用，必须使用支持的硬件（Giganet）。VIA 不适用于运行 Microsoft Windows® 98 的系统。有关 VIA 的更多信息，请参见 VIA 客户端。

  • 禁用不再需要的服务器协议。

  • 指定或更改每个启用的协议将要监听的网络地址。

    在运行多个 SQL Server 实例的计算机上手工输入网络地址时，一定不能在实例间复制网络地址。可以为 TCP/IP 协议指定以逗号分隔的端口地址列表。如果指定端口地址列表，SQL Server 实例将在运行该实例的计算机上的每个可用 IP 地址端口上进行监听。

    如果该实例正在 SQL Server 2000 故障转移群集上运行，它将在 SQL Server 安装过程中为 SQL Server 选择的每个 IP 地址的端口上进行监听。

  • 为所有已启用的服务器协议启用安全套接字层 (SSL) 加密。可对整个已启用服务器协议打开或关闭加密功能，但不能针对特定的协议指定加密功能。有关 SSL 加密的更多信息，请参见 Net-Library 加密。

    若要使用 SSL 加密，必须用运行 SQL Server 2000 实例的计算机的完全合格的域名安装证书。有关证书的更多信息，请参见 Windows 2000 文档。

  • 启用 WinSock 代理服务器。有关设置代理服务器的更多信息，请参见通过代理服务器连接到 SQL Server。

SQL Server 网络实用工具将自动检测所指定的 SQL Server 实例是否在故障转移群集上。如果实例在故障转移群集上，为实例指定的所有信息将自动复制到所有节点。但是，如果您要对故障转移群集使用加密，则必须在该故障群集的所有节点上用完全合格的虚拟服务器 DNS 名来安装服务器证书。例如，如果您有一个具有两个节点的群集，其包括名称分别为 test1.redmond.corp.microsoft.com 和 test2.redmond.corp.microsoft.com 的节点和虚拟 SQL Server"Virtsql"，则需要获得用于"virtsql.redmond.corp.microsoft.com"的证书并将该证书安装在这两个节点上。然后，您就可以在服务器网络实用工具上复选"强制协议加密"复选框来对故障转移群集进行加密配置了。

使用客户端网络实用工具配置与任何激活的服务器 Net-Library对应的客户端 Net-Library。

启动 SQL Server 网络实用工具

Network Utility

网络实用工具

装载已安装的服务器网络库

Network Utility

网络实用工具

编辑服务器网络库配置

Network Utility

网络实用工具

查看已安装的 SQL Server 网络库

Network Utility

网络实用工具

停用服务器网络库配置

Network Utility

网络实用工具

请参见

配置客户端网络连接

客户端 Net-Library 和网络协议


通过代理服务器连接到 SQL Server

可以通过 Microsoft 代理服务器这个提供安全数据访问的独立程序连接到 Microsoft® SQL Server™ 实例。从而可以防止未经授权的用户连接到专用网络。这样就通过控制对监听端口的权限和访问而保证了敏感数据的安全。Microsoft 代理服务器与 Microsoft Windows® 2000 Server 用户身份验证集成在一起。可以按 IP 地址范围、域或个别用户来阻断对受限站点的访问，以确保用户适当地使用其 Internet 权限。

有关远程监听和接受呼叫上下文中的本地地址表 (LAT) 配置的更多信息，请参见 Microsoft 代理服务器文档。

通过 Microsoft 代理服务器连接到 SQL Server 实例

SQL Setup

SQL 安装程序

请参见

Net-Library 和网络协议


通过 Internet 连接到 SQL Server

可以使用基于 ODBC 或 DB-Library 的 SQL 查询分析器或客户端应用程序，通过 Internet 连接到 Microsoft® SQL Server™ 实例。

为了在 Internet 上共享数据，必须将客户端和服务器连接到 Internet。另外，必须使用 TCP/IP 或多协议 Net-Library。如果使用多协议 Net-Library，请确保启用 TCP/IP 支持。如果服务器已注册域名系统 (DNS)，就可以用其注册名进行连接。

尽管这种连接不如通过 Microsoft 代理服务器连接安全，但使用防火墙或加密连接有助于保证敏感数据的安全。

对 SQL Server 使用防火墙系统

许多公司使用防火墙系统防止从 Internet 无计划地访问其网络。防火墙可用于限制 Internet 应用程序访问您的网络，其方法是只转发目标为本地网络中的特定 TCP/IP 地址的请求。对所有其它网络地址的请求都将被防火墙阻塞。通过配置防火墙使之转发指定 SQL Server 实例的网络地址的网络请求，即可允许 Internet 应用程序访问本地网络中的 SQL Server 实例。

若要使防火墙有效地工作，必须确保 SQL Server 实例始终在配置防火墙转发的网络地址上监听。SQL Server 的 TCP/IP 网络地址由两部分组成：与计算机中的一个或多个网卡相关联的 IP 地址，以及专用于 SQL Server 实例的 TCP 端口地址。默认情况下，SQL Server 默认实例使用 1433 号 TCP 端口。但是，命名实例在首次启动时，动态分配未使用的 TCP 端口号。如果另一个应用程序正在使用起始的 TCP 端口号，则该命名实例在以后启动时还可动态更改其 TCP 端口地址。如果当前正在其上监听的某个未使用的 TCP 端口还未动态选定，则 SQL Server 只动态更改到该端口。也就是说，如果该端口是静态（手工）选定，则 SQL Server 将显示错误并继续在其它端口上监听。另一个应用程序尝试使用 1433 不太可能，因为该端口已注册为 SQL Server 已知的地址。

当对防火墙使用 SQL Server 命名实例时，请使用 SQL Server 网络实用工具配置该命名实例，使之在特定的 TCP 端口上监听。必须挑出在同一台计算机或群集上运行的另一个应用程序还未使用的 TCP 端口。有关各种应用程序注册用于使用的已知端口列表，请参见 http://www.ise.edu/in-notes/iana/assignments/port-numbers。

请网络管理员配置防火墙以转发 SQL Server 实例正在其上监听的 IP 地址和 TCP 端口（使用默认实例的 1433，或使用配置命名实例在其上监听的 TCP 端口）。还应配置防火墙使其转发对同一 IP 地址上的 1434 号 UDP 端口的请求。SQL Server 2000 使用 1434 号 UDP 端口从应用程序建立通讯链接。

例如，考虑有一台运行 SQL Server 的一个默认实例和两个命名实例的计算机。配置该计算机以便这三个实例监听的网络地址都具有相同的 IP 地址。默认实例将在 1433 号 TCP 端口上监听，一个命名实例可以分配 1433 号 TCP 端口，而另一个命名实例分配 1954 号 TCP 端口。然后应配置防火墙以转发对该 IP 地址上的 1434 号 UDP 端口以及 1433 号、1434 号和 1954 号 TCP 端口的网络请求。

建立加密连接

如果希望用户能与 SQL Server 实例建立加密连接，则可通过对多协议 Net-Library 启用加密功能来实现。

安装 SQL Server 后启用加密功能

Network Utility


配置链接服务器

链接服务器配置允许 Microsoft® SQL Server™ 对其它服务器上的 OLE DB 数据源执行命令。链接服务器具有以下优点：

  • 远程服务器访问。

  • 对整个企业内的异类数据源执行分布式查询、更新、命令和事务的能力。

  • 能够以相似的方式确定不同的数据源。
链接服务器组件

链接服务器的定义指定了 OLE DB 提供程序和 OLE DB 数据源。

OLE DB 提供程序是管理特定数据源和与特定数据源进行交互的动态链接库 (DLL)。OLE DB 数据源标识可通过 OLE DB 访问的特定数据库。尽管通过链接服务器的定义所查询的数据源通常是数据库，但也存在适用于多种文件和文件格式的 OLE DB 提供程序，包括文本文件、电子表格数据和全文内容检索结果。下表说明了最常用于 SQL Server 的 OLE DB 提供程序和数据源示例。

OLE DB 提供程序 | OLE DB 数据源
用于 SQL Server 的 Microsoft OLE DB 提供程序 | SQL Server 实例（格式为 servername\instancename）和数据库，如 pubs 或 Northwind
用于 Jet 的 Microsoft OLE DB 提供程序 | mdb 数据库文件的路径名
用于 ODBC 的 Microsoft OLE DB 提供程序 | 指向某个具体数据库的 ODBC 数据源名称
用于 Oracle 的 Microsoft OLE DB 提供程序 | 指向 Oracle 数据库的 SQL*Net 别名
用于索引服务的 Microsoft OLE DB 提供程序 | 能够对其执行属性搜索或全文检索的内容文件

说明 SQL Server 只针对分别用于 SQL Server、Jet、Oracle、索引服务和 ODBC 的 Microsoft OLE DB 提供程序进行了测试。然而，SQL Server 分布式查询旨在与任何实现了必需的 OLE DB 接口的 OLE DB 提供程序一起使用。

为了使数据源能够通过链接服务器返回数据，那个数据源的 OLE DB 提供程序 (DLL) 必须位于 SQL Server 所在的服务器上。

链接服务器详细信息

下图说明了链接服务器配置的基本工作方式。

链接服务器一般用来处理分布式查询。当客户端应用程序通过链接服务器执行分布式查询时，SQL Server 将分析该命令，并向 OLE DB 发送行集请求。行集请求的形式可以是对提供程序执行查询或从提供程序打开基表。

管理链接服务器的定义

设置链接服务器时，请注册 SQL Server 的连接信息和数据源信息。完成注册后，该数据源总可以用单个逻辑名称引用。

可以使用存储过程或 SQL Server 企业管理器来创建或删除链接服务器的定义。

  • 使用存储过程：
    • 使用 sp_addlinkedserver 创建链接服务器的定义。若要查看有关给定的 SQL Server 实例中定义的链接服务器的信息，请使用 sp_linkedservers。有关更多信息，请参见 sp_addlinkedserver 和 sp_linkedservers。

    • 使用 sp_dropserver 删除链接服务器的定义。还可以使用此存储过程删除远程服务器。有关更多信息，请参见 sp_dropserver。
  • 使用 SQL Server 企业管理器：
    • 使用 SQL Server 企业管理器控制台树和"链接服务器"节点（在"安全性"文件夹内）来创建链接服务器的定义。为链接服务器定义名称、提供程序属性、服务器选项和安全选项。有关各种为不同的 OLE DB 数据源设置链接服务器的方式以及要使用的参数值的更多信息，请参见 sp_addlinkedserver。

    • 通过右击链接服务器并单击"属性"命令，可编辑链接服务器的定义。

    • 通过右击链接服务器并单击"删除"命令，可删除链接服务器的定义。

当对链接服务器执行分布式查询时，请对每个要查询的数据源指定完全合法的、由四部分组成的表名。这个由四部分组成的名称的格式应是：linked_server_name.catalog.schema.object_name。有关更多信息，请参见分布式查询。

请参见

使用链接服务器名称标识数据源

用 SQL Server 测试过的 OLE DB 提供程序

在分布式查询中使用事务


建立链接服务器的安全性

在链接服务器的连接过程（如处理分布式查询时）中，发送服务器提供登录名和密码以代表自己连接到接收服务器。为了使该连接有效，请使用 Microsoft® SQL Server™ 存储过程在链接服务器之间创建登录映射。

链接服务器登录映射可通过 sp_addlinkedsrvlogin 添加，通过 sp_droplinkedsrvlogin 删除。链接服务器登录映射为给定的链接服务器和本地登录建立远程登录和远程密码。SQL Server 在连接到链接服务器以执行分布式查询或存储过程时，将查找正在执行查询或存储过程的当前登录的任何登录映射。如果有一个登录映射，SQL Server 在连接到链接服务器时将发送相应的远程登录和密码。

假设使用远程密码"my_pwd"为链接服务器 S1 建立了一个从本地登录 U1 到远程登录 U2 的映射。如果本地登录 U1 执行了分布式查询来访问链接服务器 S1 中存储的表，当 SQL Server 连接到链接服务器 S1 时，U2 和 my_pwd 将作为用户 ID 和密码传递到该服务器。

例如，使用远程密码"my pwd"为链接服务器 S1 建立了一个从本地登录 U1 到远程登录 U2 的映射。如果本地登录 U1 执行分布式查询来访问链接服务器 S1 中存储的表，当 SQL Server 连接到链接服务器 S1 时，U2 和 my pwd 将作为用户 ID 和密码传递到该服务器。

链接服务器配置的默认映射模拟了登录的当前安全凭据。这类映射称为自映射。如果使用 sp_addlinkedserver 添加链接服务器，则将为所有本地登录添加默认自映射。

如果安全帐户委托在客户端或发送服务器上不可用，或者链接服务器/提供程序不能识别 Windows 身份验证模式，则自映射对 Windows 授权登录不起作用。因此，需要建立从 Windows 授权登录到链接服务器上的特定登录的本地登录映射。这种情况下，如果链接服务器是 SQL Server 实例，则远程登录将是 SQL Server 授权登录。

如果安全帐户委托可用且链接服务器支持 Windows 身份验证，则支持 Windows 授权登录的自映射。有关安全帐户委托的更多信息，请参见安全帐户委托。

分布式查询受限于链接服务器在远程表上授予远程登录的权限。处理分布式查询时，SQL Server 在编译时不执行任何权限验证。提供程序在查询执行时检测并报告任何违反权限的行为。

添加链接服务器的登录

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

sp_addlinkedserver

sp_addlinkedsrvlogin

sp_droplinkedsrvlogin

sp_dropserver

sp_linkedservers

sp_serveroption


为分布式查询配置 OLE DB 提供程序

Microsoft® SQL Server™ 提供许多用于管理分布式查询的高级选项。这些选项中，有些在 Microsoft Windows® 2000 注册表中的提供程序级进行管理，有些通过 sp_serveroption 在链接服务器级进行管理。这些选项只应由有经验的系统管理员进行配置，配置的目的是尽量提高对链接服务器的分布式查询的性能。

OLE DB 提供程序选项

管理分布式查询的 OLE DB 提供程序选项用 SQL Server 企业管理器进行设置。在 SQL Server 企业管理器的左窗格中，右击一个链接服务器定义，该定义使用了要为其设置属性的 OLE DB 提供程序。在"常规"选项卡上，单击"选项"按钮，然后设置属性。

提供程序选项 | 描述
动态参数 | 如果非零，表明提供程序允许对参数化查询使用"?"参数标记语法。仅当提供程序支持 ICommandWithParameters 接口并支持"?"作为参数标记时才应设置该选项。设置该选项使 SQL Server 得以对提供程序执行参数化查询。这种对提供程序执行参数化查询的能力会提高某些查询的性能。
NestedQueries | 如果非零，表明提供程序允许在 FROM 子句中使用嵌套 SELECT 语句。设置该选项使 SQL Server 得以将某些查询委托给要求在 FROM 子句中使用嵌套 SELECT 语句的提供程序。
LevelZeroOnly | 如果非零，只对提供程序唤醒调用级别为 0 的 OLE DB 接口。
AllowInProcess | 如果非零，SQL Server 允许将提供程序创建为进程内服务器实例。如果在注册表中没有设置该选项，默认行为是在 SQL Server 进程外创建提供程序的实例。在 SQL Server 进程外创建提供程序的实例可保护 SQL Server 进程不受提供程序中的错误影响。在 SQL Server 进程外创建提供程序的实例时，不允许更新或插入引用长列（text、ntext 或 image）。
NonTransactedUpdates | 如果非零，即使 ITransactionLocal 不可用，SQL Server 也允许更新。如果启用该选项，对提供程序的更新将不可恢复，因为该提供程序不支持事务。
IndexAsAccessPath | 如果非零，SQL Server 将尝试使用提供程序索引来提取数据。默认情况下，索引仅用于元数据且永远不打开。
DisallowAdhocAccess | 如果设置了非零值，SQL Server 将不允许通过 OpenRowset() 和 OpenDataSource() 函数对 OLE DB 提供程序进行特殊访问。如果没有设置该选项，则默认行为是允许 OpenRowset 和 OpenDataSource。

这些选项在提供程序级进行操作。如果为提供程序设置了选项，则设置将应用于所有使用同一 OLE DB 提供程序的链接服务器定义。

将 DynamicParameters 或 NestedQueries 设置为非零值后，SQL Server 就可以向 OLE DB 提供程序发送需要此语法的查询以执行远程查询。只有当提供程序支持这两个选项的语法时，才应设置这两个选项。

链接服务器选项

通过 sp_serveroption，可在链接服务器级使用几个选项来管理分布式查询。服务器级选项（相对于提供程序级选项）只影响指定链接服务器上的行为。

下表描述了各种链接服务器选项。

链接服务器选项 | 描述
use remote collation | 如果此选项设置为 true，SQL Server 将使用来自链接服务器的字符列排序规则信息。如果链接服务器是 SQL Server 实例，则排序规则信息自动从 SQL Server OLE-DB 提供程序接口派生出来。如果链接服务器不是 SQL Server 实例，SQL Server 将使用 collation name 选项中的排序规则设置。 如果此选项设置为 false，SQL Server 将以本地 SQL Server 实例的默认排序规则解释来自指定链接服务器的字符数据。
collation name | 如果 use remote collation 设置为 true，则此选项指定用于来自链接服务器的字符数据的排序规则。如果 use remote collation 设置为 false，或者链接服务器是 SQL Server 实例，将忽略此选项。
connection timeout | 此选项指定当 SQL Server 尝试与链接服务器建立连接时所使用的超时数值（以秒为单位）。如果未设置此选项，则全局配置选项 remote login timeout 的当前值集将作为默认值。
lazy schema validation | 如果该选项设置为 false（默认值），则 SQL Server 将检查从编译远程表以来发生的架构更改。此情况发生在执行查询开始前。如果架构发生变化，SQL Server 将用新架构重新编译查询。 如果此选项设置为 true，则对远程表架构的检查将一直延迟到执行查询时。如果远程表的架构在编译和执行查询之间已发生更改，则该选项可能会导致分布式查询失败并出错。 如果正在对链接 SQL Server 使用分布式、分区视图，则可能需要将此选项设置为 true。参与分区视图的给定表实际上可能并不用于执行对视图的指定查询，因此延迟架构验证会有助于提高性能。

请参见

建立链接服务器的安全性

sp_addlinkedserver

sp_serveroption


配置远程服务器

远程服务器配置允许客户端连接到一个 Microsoft® SQL Server™ 实例，然后不用另外建立连接即可在其它的 SQL Server 实例上执行存储过程。客户端所连接的服务器接受客户端的请求，并代表客户端将该请求发送到远程服务器。远程服务器处理请求并将结果返回给原服务器，原服务器进而将结果传递给客户端。

如果打算设置服务器配置，以便在另一台服务器上执行存储过程，并且没有现有的远程服务器配置，此时应使用链接服务器而非远程服务器。可以对链接服务器执行存储过程和分布式查询；但对远程服务器只能执行存储过程。

说明 支持远程服务器只是为了向后兼容。新的应用程序如果必须对 SQL Server 的远程实例执行存储过程，应该使用链接服务器。

远程服务器详细信息

远程服务器是成对设置的。若要设置一对远程服务器，请将这两台服务器配置为彼此将对方识别为远程服务器。然后，验证这两台服务器的配置选项设置是否正确，以使每个 SQL Server 实例都允许远程用户执行过程调用。检查本地和远程服务器上的"服务器属性"对话框中的配置选项。

大多数情况下，不需要为远程服务器设置配置选项；SQL Server 安装程序在本地和远程计算机上设置的默认值允许建立远程服务器连接。

为使远程服务器能够工作，必须在本地和远程计算机上将控制远程服务器登录的 remote access 配置选项设为 1（默认设置）。如果更改了其中一台服务器的 remote access 选项设置，必须将一台或两台服务器的选项重新设回 1 才能允许远程访问。这可通过 SQL Server 企业管理器或 Transact-SQL sp_configure 语句完成。

可以在本地服务器上禁用远程服务器配置，以防止用户访问该服务器。

设置远程服务器

Transact-SQL

Transact-SQL

SQL-DMO

检查和设置远程服务器配置选项

企业管理器

企业管理器

SQL-DMO

禁用远程服务器设置

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

请参见

配置链接服务器

RECONFIGURE

remote access 选项

sp_configure


建立远程服务器的安全性

设置对远程服务器执行远程存储过程调用 (RPC) 的安全性时，涉及的工作包括在远程服务器中建立登录映射，可能还包括在运行 Microsoft® SQL Server™ 实例的本地服务器中建立登录映射。

说明 支持远程服务器只是为了向后兼容。新的应用程序如果必须对 SQL Server 的远程实例执行存储过程，应该使用链接服务器。

设置远程服务器

必须在远程服务器上设置远程登录映射。使用这些映射，远程服务器将来自特定服务器的 RPC 连接的外来登录映射到本地登录。可以使用 sp_addremotelogin 存储过程在远程服务器上设置远程登录映射。

设置本地服务器

在 SQL Server 2000 内，通过以下方法为 Windows 身份验证创建的远程服务器登录创建远程服务器连接：

  • 可在本地服务器上设置本地登录映射，定义 SQL Server 实例与远程服务器建立 RPC 连接时所使用的登录和密码。

    对于 Windows 身份验证所创建的登录，必须创建到登录名和密码的映射。此登录名和密码必须与远程服务器所需的外来登录和密码相匹配。

  • 使用 sp_addlinkedsrvlogin 存储过程创建本地登录映射。

    说明 对于 SQL Server 身份验证所创建的登录，不必为了对远程服务器执行存储过程而创建任何本地登录映射。

远程服务器安全性示例

假设有两个 SQL Server 安装：serverSend 和 serverReceive。serverReceive 配置为将来自 serverSend 的名为 Sales_Mary 的外来登录映射到 serverReceive 中名为 Alice 的 SQL Server 授权登录。另一个将来自 serverSend 的名为 Joe 的外来登录映射到 serverReceive 中名为 Joe 的 SQL Server 授权登录。

可以执行下面的 Transact-SQL 代码，以配置 serverSend 对 serverReceive 执行 RPC：

--Create remote server entry for RPCs from serverSend.
EXEC sp_addserver 'serverSend'
GO

--Create remote login mapping for login 'Sales_Mary' from serverSend
--to Alice.
EXEC sp_addremotelogin 'serverSend', 'Alice', 'Sales_Mary'
GO

--Set trusted option on for this mapping to disable password checking
--for Sales_Mary from serverSend.
EXEC sp_remoteoption 'serverSend', 'Alice', 'Sales_Mary', trusted, true
GO

--Create remote login mapping for login Joe from serverReceive to same login;
--assumes same password for Joe in both servers.
EXEC sp_addremotelogin 'serverSend', 'Joe', 'Joe'
GO

在 serverSend 上创建本地登录映射，将 Windows 授权登录 Sales\Mary 映射到登录 Sales_Mary。Joe 不需要本地映射，因为默认设置是使用相同的登录名和密码，并且 serverReceive 中有 Joe 的映射：

--Create a remote server entry for RPCs from serverReceive.
EXEC sp_addserver 'serverReceive'
GO

--Create a local login mapping for the Windows Authenticated login.
--Sales\Mary to Sales_Mary.
EXEC sp_addlinkedsrvlogin 'serverReceive', false, 'Sales\Mary',
   'Sales_Mary,' NULL
GO

请参见

配置远程服务器

sp_addremotelogin

sysremotelogins


查看本地或远程服务器属性

可以在某个方便的位置查看本地或远程服务器的服务器特性（如 Microsoft® SQL Server™ 的版本号、计算机中处理器的数目及类型、操作系统的版本等）。从本地服务器可以查看远程服务器的数据库、文件、登录和工具。

查看服务器属性

企业管理器

企业管理器

Transact-SQL


使用备用服务器

备用服务器是当主生产服务器发生故障时可联机使用的第二个服务器。备用服务器包含主服务器数据库的复本。当主服务器因已调度的维护而不可用时，也可以使用备用服务器。例如，如果主服务器需要硬件或软件升级，即可使用备用服务器。

备用服务器使用户得以在主服务器不可用时还能继续使用数据库。当主服务器再次可用时，必须将数据库复本在备用服务器上所发生的任何更改都还原到主服务器上。否则，这些更改都将丢失。当用户重新开始使用主服务器时，应将它的数据库进行备份并再次在备用服务器上还原。

备用服务器的实现包括三个阶段：

  • 在主服务器上创建数据库和正在进行的事务日志的备份。

  • 通过对主服务器上的数据库进行备份并在备用服务器上还原来设置并维护备用服务器。

  • 如果主服务器出现故障，使备用服务器联机。

    重要 当主服务器不可用时，所有用户进程都必须登录到备用服务器，并重新启动刚才正在执行的任何任务。用户进程不会自动切换到备用服务器上执行，并且不在主服务器和备用服务器之间维护事务。如果使主服务器脱离网络或对其手工重命名，同时重命名备用服务器，则备用服务器的网络名称和地址将不同于用户以前使用的服务器。

主服务器数据库中的事务日志备份定期应用到备用服务器，以保证备用服务器与主服务器保持同步。一旦主服务器或者只是一个数据库出现故障，备用服务器上的数据库即可用于用户进程。任何不能访问主服务器的用户进程都可转而使用备用服务器。

备用服务器配置与 Microsoft® SQL Server™ 2000 故障转移群集中使用的虚拟服务器配置不同。备用服务器中包含 SQL Server 数据库的另一个复本。在虚拟服务器配置中，单个的数据库复本装载在共享群集磁盘上，由构成虚拟服务器基础的主要和次要物理服务器共享。

在主服务器上创建备份

在主服务器上：

  1. 为每个要复制的数据库创建完整数据库备份。有关更多信息，请参见数据库备份。

  2. 定期为每个要复制的数据库创建事务日志备份。有关更多信息，请参见事务日志备份。

    在主服务器上创建事务日志备份的频率取决于生产服务器数据库的事务更改量。如果主数据库中的事务发生频率高，经常备份事务日志对降低故障中丢失数据的可能性很有帮助。

    重要 将 master 的复本从生产服务器还原到备用服务器时，不能备份 master 的事务日志。只能备份和还原 master 数据库。

设置和维护备用服务器

备用服务器按如下方式进行设置和维护：

  1. 在备用模式下将主服务器上的数据库备份还原到备用服务器上，并指定撤消文件（每个数据库一个撤消文件）。

    在备用模式下恢复数据库或事务日志时，需要回滚任何未提交的事务，以使数据库在逻辑上保持一致的状态并在需要时用于只读目的。受未提交的回滚事务影响的数据库页将被修改。这将撤消未提交事务最初作出的更改。在恢复过程修改这些页的内容之前，将用撤消文件保存这些页的内容，以防未提交事务所执行的更改丢失。在下次将后续的事务日志备份应用于数据库之前，必须首先重新应用先前由恢复过程回滚的未提交事务。将撤消文件中保存的更改重新应用于数据库，然后再应用下一个事务日志。

    说明 必须有足够的磁盘空间供撤消文件增长，以使撤消文件能够包含数据库中由回滚的未提交事务修改的所有不重复的页。

  2. 定期将主服务器上创建的每个后续事务日志应用于备用服务器上的数据库。在备用模式下应用每个事务日志，并指定先前还原数据库时所使用的同一撤消文件。

    对备用服务器应用事务日志备份的频率取决于主生产服务器数据库的事务日志备份频率。经常应用事务日志可减少在生产系统出现故障时使备用服务器联机所需要做的工作。

在备用模式下，只能对数据库执行只读操作，例如不尝试修改数据库的数据库查询。这使数据库得以用于决策支持查询或 DBCC 检查。

使备用服务器联机

当主服务器开始不可用时，备用服务器上的所有数据库都完全同步不太可能。一些在主服务器上创建的事务日志备份可能还没有应用于备用服务器。另外，自事务日志上次备份后，主服务器数据库很可能有一些改动，尤其是在使用频繁的系统中。在用户使用备用复本之前，主数据库有可能与备用复本同步且备用服务器可通过以下方法联机：

  1. 按顺序将在主服务器上创建的、尚未应用的任何事务日志备份应用于备用服务器。

  2. 在主服务器上创建活动事务日志的备份，并将其应用于备用服务器上的数据库。活动事务日志的备份在应用于备用服务器时，将使用户得以使用故障发生前一刻的主数据库复本，但任何未提交的事务都将永远丢失。有关更多信息，请参见事务日志备份。

    如果主服务器没有损坏，则当计划的维护或升级发生时，可以使用 NORECOVERY 备份活动事务日志。这将使数据库处于还原状态，并使您得以用来自辅助服务器的事务日志备份更新主服务器。然后无需创建辅助服务器的完整数据库备份即可切换回主服务器。有关更多信息，请参见 BACKUP。

  3. 恢复备用服务器上的数据库。这将在不创建撤消文件的情况下恢复数据库，使用户得以修改数据库。

一台备用服务器可以包含来自多个 SQL Server 实例的数据库备份。例如，某个部门可能有五台服务器，每台服务器都运行使命关键的数据库系统。可以使用一台备用服务器，而不必使用五台单独的备用服务器。五个主系统上的数据库备份都可以装载到这个备份系统中，从而减少必需的资源量并节省开支。不太可能出现多个主系统同时出现故障的情况。另外，备用服务器的规格可以比各主服务器高，以应付多个主系统在某一特定时刻同时不可用的极少见情况。

设置和维护备用服务器并使其联机

Transact-SQL

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

RESTORE

将数据库还原到前一个状态


日志传送

在 Microsoft® SQL Server™ 2000 企业版中，可以使用日志传送不间断地将事务日志从一个数据库提供给另一个。不间断地从源数据库中备份事务日志，然后将它们复制并还原到目的数据库，使目的数据库与源数据库保持同步。这使您得以有一台备用服务器，为将查询处理从主计算机（源服务器）卸载到只读目的服务器上提供了一条途径。

日志传送模型

下图说明了日志传送模型。

在下例中，企业有五台服务器：服务器 A、服务器 B、服务器 C、服务器 D 和服务器 E。服务器 B 是源服务器，在该服务器上执行和复制日志的备份和还原。服务器 C、服务器 D和服务器 E 包含目的数据库，而服务器 B 的日志备份将还原到目的数据库，以保持这些服务器与服务器 B 同步。服务器 A 是监视服务器，在该服务器上监视整个企业内的日志传送。每台目的服务器或源服务器只由一台监视服务器维护。数据库维护计划向导用于定义服务器 B 备份日志备份的时间与服务器 C、D 和 E 必须还原日志备份的时间之间的适当延迟。如果延迟超出了定义的时间，服务器 A 将使用 SQL Server 代理程序生成警报。该警报助于诊断目的服务器还原备份失败的原因。

不要将监视服务器作为源服务器，因为监视服务器用于维护关于日志传送系统的关键信息。应定期备份监视服务器。保持监视服务器独立对性能也有益，因为监视会增加不必要的开销。而且，源服务器作为支持生产工作负荷的服务器，最有可能出现故障，从而使监视中断。源服务器和目的服务器可以位于同一台计算机上。但在这种情况下，SQL Server 2000 故障转移群集可能提供更好的结果。有关更多信息，请参见故障转移群集。

使用数据库维护计划向导配置日志传送

若要很容易地配置日志传送，请使用数据库维护计划向导。利用此向导您将可以：

  • 定义日志生成频率、备份与还原操作之间的时间以及什么时候目的服务器与源服务器异步。

  • 注册任何新的服务器。

  • 在所有目的服务器上创建源数据库。在通过数据库维护计划向导添加目的数据库时，可以选择在目的服务器上创建数据库或使用现有数据库。在为日志传送配置数据库之前，任何现有数据库必须为备用模式。

  • 指定哪台目的服务器可以采用源服务器角色。

  • 设置还原延迟。还原延迟定义还原事务日志前必须等待的时间。如果源服务器出现故障，该延迟将为损坏的日志被还原到目的服务器上之前提供额外时间。

  • 创建调度来设置备份调度。

在使用数据库维护计划向导之前，需要考虑下列事项：

  • 配置日志传送的用户必须是 sysadmin 服务器角色成员，以便有权修改要进行日志传送的数据库。

  • 一次只能在一个数据库上配置日志传送。如果选择的数据库不止一个，向导上的日志传送选项将禁用。

  • 用于启动 MSSQLServer 和 SQLServerAgent 服务的登录必须能够访问日志传送计划作业、源服务器和目的服务器。

  • 当使用数据库维护计划向导配置日志传送时，只能将日志传送到磁盘。备份到磁带选项不可用。
手工配置日志传送

如果在运行 SQL Server 7.0 Service Pack 2 (SP2) 的计算机上启用挂起升级选项，则 SQL Server 2000 支持从 SP2 事务日志手工传送日志。

若要启用此选项，请执行下列代码：

EXEC sp_dboption 'database name', 'pending upgrade', 'true'

但是，当在传送日志后还原数据库时，只能使用 NORECOVERY 选项恢复数据库。

说明 在运行 SP2 的计算机和运行 SQL Server 2000 实例的计算机之间手工配置日志传送时，不能使用 SQL Server 复制。

有关更多信息，请参见 SP2 文档。

配置日志传送

企业管理器

企业管理器

删除日志传送

企业管理器

企业管理器

更改日志传送角色

SQL Server 2000 允许通过系统存储过程实现日志传送角色的更改。在更改角色前，必须执行几个预备任务。有关更多信息，请参见如何设置和执行日志传送角色转变 (Transact-SQL)。

请参见

故障转移群集

数据库维护计划向导


修改日志传送

配置日志传送后，可以添加、删除或编辑目的服务器。例如，可以更改事务日志的目的地，指定是想在目的服务器上创建新的数据库还是使用现有数据库。如果选择创建新的数据库，必须指定数据和日志的数据库名称和文件目录。

添加或编辑目的服务器

企业管理器

企业管理器

删除目的服务器

企业管理器

企业管理器

从日志传送监视器 (Transact-SQL) 中删除日志传送对

Transact-SQL


监视日志传送

配置日志传送后，请使用监视服务器查看有关所有日志传送服务器状态的信息。

监视服务器提供了日志传送的所有详细信息，例如：

  • 源服务器上次备份的时间，以及目的服务器上次复制和还原备份文件的时间。

  • 有关备份失败警报的信息。

  • 有关警报生成抑制的详细信息。

使用监视服务器，也可以：

  • 为源服务器和目的服务器编辑警报生成抑制信息。警报抑制用于在特定日期和时间内抑制备份失败时的警报。

  • 将某服务器的角色从目的服务器改为源服务器（如果原先配置该目的服务器采用此角色）。

查看为日志传送配置的服务器状态

企业管理器

企业管理器

查看或编辑有关源服务器的信息

企业管理器

企业管理器

如何查看或编辑有关目的服务器的信息

企业管理器


并发管理操作

下图说明允许或不允许同时运行的管理任务。

说明 文件收缩操作将大部分处理时间用在将页重新分配到收缩完成后所保留的区域中，然后尝试将文件大小更改为上一步的大小。如果在文件收缩操作尝试更改文件大小之前备份已完成，则可以在运行备份时启动文件收缩操作。


管理 SQL Server 消息

Microsoft® SQL Server™ 提供管理服务器消息的工具，使管理员得以：

  • 通过筛选搜索特定的错误信息，筛选条件包括消息正文、错误号、严重级别、消息是否是用户定义的、以及是否将消息记入日志等。

  • 创建新消息。

  • 编辑用户定义的消息。

  • 删除用户定义的消息。

添加新的 SQL Server 消息

企业管理器

企业管理器

管理 SQL Server 消息

企业管理器

企业管理器

编辑 SQL Server 消息

企业管理器

企业管理器

删除 SQL Server 消息

企业管理器

企业管理器

请参见

错误信息


SQL 邮件

SQL 邮件提供一种可以接收 Microsoft® SQL Server™ 生成的电子邮件的方法。可以触发消息以提供作业状态或由警报产生的警告。SQL 邮件在回复包含查询的电子邮件消息时，会在回复中包含一个结果集。SQL 邮件使 SQL Server 得以通过与邮件服务器建立客户端连接来发送和接收电子邮件。

SQL Server 使用两种服务处理邮件。MSSQLServer 处理所有邮件存储过程的邮件。SQLServerAgent 并不用 SQL 邮件发送电子邮件。而是使用自己的与 SQL 邮件分开配置和操作的邮件功能。

SQL Server 代理程序的邮件功能将被称作 SQLAgentMail，以区别于 MSSQLServer 提供的 SQL 邮件功能。SQL 邮件利用邮件主机建立扩展的MAPI 连接，而 SQLAgentMail 主动建立扩展的 MAPI 连接。SQL 邮件和 SQLAgentMail 都能与 Microsoft Exchange Server、Microsoft Windows NT® Mail 或 Post Office Protocol 3 (POP3) 服务器连接。

SQL 邮件需要一个邮局连接、一个邮件存储区（邮箱）、一个邮件配置文件以及 Windows NT 4.0 或 Microsoft Windows® 2000 域用户帐户，才能登录到 SQL Server 实例。SQL 邮件由许多存储过程组成，SQL Server 可使用这些过程处理指定的 SQL 邮件帐户邮箱中收到的电子邮件，或者回复存储过程 xp_sendmail 生成的电子邮件。使用 SQL 邮件扩展存储过程，消息可通过触发器或存储过程发送。SQL 邮件存储过程能操作数据，处理通过电子邮件发来的查询，并通过创建回复电子邮件返回结果集。

处理 SQL Server 收到的电子邮件请求

若要自动处理电子邮件，必须创建一个使用存储过程 sp_processmail 的定期调度作业。sp_processmail 检查 SQL 邮件邮件配置文件，然后检查邮箱里的邮件。sp_processmail 使用 xp_sendmail 执行电子邮件正文中包含的查询请求，然后给原发件人及所有其他收件人返回结果集。例如，可以允许供应商执行存储过程，以生成有关该单位所供应的全部材料的当前库存水平的信息。

SQLAgentMail

SQLAgentMail 可使用自己的域帐户和与 SQL 邮件中的设置不同的邮件配置文件。使用 SQL Server，可以配置 SQLAgentMail 在下列情况下发送电子邮件消息：

  • 警报触发时。

    可以配置警报针对发生的特定事件发送电子邮件通知，而无需执行 SQL 邮件。例如，可以配置警报将需要立即采取对策的特定数据库事件通知给操作员。

    有关配置警报的更多信息，请参见定义警报。

  • 已调度的任务（例如数据库的备份或复制事件）成功或失败时。

可以给一组收件人发送电子邮件消息，通知他们所调度作业的状态，以便用户采取可能的对策。可以扩展作业的功能，增加通过电子邮件给一组收件人发送结果集的能力。例如，月度库存报告可以给指定的操作员发送 SQLAgentMail 通知，给采购经理和供应商发送结果集。


配置SQL 邮件

SQL 邮件必须使用邮件配置文件来运行，该配置文件在启动 Microsoft® SQL Server™ 实例时所使用的同一域帐户中创建。在 SQL Server 企业管理器的 Support Services 文件夹下，可以看到对 SQL 邮件服务的图形描述，并可以确定该服务是否正在运行。可通过单击"SQL 邮件配置"对话框内"常规"选项卡上的"SQL Server 启动时自动启动 SQL 邮件"自动启动 SQL 邮件。SQL 邮件启动后，即可以使用存储过程发送和接收邮件。

配置邮件配置文件

Windows

Windows

设置 SQL 邮件

企业管理器


配置邮件配置文件

SQL 邮件和 SQLAgentMail 可以使用相同或不同的邮件配置文件。如有必要，每个邮件配置文件可以在各自的域帐户中进行配置。

配置 SQL 邮件配置文件

邮件配置文件一经配置，即专门用于 Microsoft® Windows NT® 4.0 或 Windows® 2000 用户域帐户，当用户成功登录到 Windows NT 4.0 或 Windows 2000 时，此用户帐户被激活。SQL 邮件必须在启动 Microsoft SQL Server™ 实例时所使用的同一用户域帐户或环境中创建邮件配置文件。当一个邮件存储过程执行时，SQL 邮件将在触发该过程的域帐户中查找已定义的邮件配置文件。

如果打算使用邮件存储过程，必须：

  • 有一个遵从扩展 MAPI 的邮件服务器。

  • 配置邮件配置文件，供 MSSQLServer 用于连接您的邮件服务器。

配置邮件配置文件

Windows

Windows

设置 SQL 邮件

企业管理器

企业管理器

配置 SQLAgentMail 配置文件

如果打算通过电子邮件或呼叫程序给操作员发送通知，必须：

  • 有一个遵从扩展 MAPI 的邮件服务器。

  • 配置邮件配置文件，供 SQL Server 用于连接您的邮件服务器。

  • 有一个能与呼叫程序通讯的邮件服务器。

SQLAgentMail 必须使用邮件配置文件，才能通过电子邮件或呼叫程序启动邮件会话或发送通知。SQL Server 代理程序邮件会话在 SQLServerAgent 服务每次启动时启动。可以使用安装在本地 SQL Server 计算机上的邮件客户程序（如 Microsoft Outlook®）来创建配置文件。

配置邮件配置文件

Windows

Windows

设置 SQLAgentMail

企业管理器

企业管理器

与 SQL 邮件共享配置文件

可以配置 SQL 邮件和 SQLAgentMail 会话使用相同的 Windows NT 4.0 或 Windows 2000 域用户帐户。当使用相同的域帐户时，SQL 邮件和 SQLAgentMail 可以共享使用共同邮箱的同一个邮件配置文件。

SQL Server 使用两个单独的邮件会话：

  • MSSQLServer 服务使用称为 SQL 邮件的邮件会话。

    当数据库应用程序执行 xp_sendmail 扩展存储过程给收件人发送消息或查询结果集时，SQL Server 使用此邮件会话。

  • SQLAgentMail 使用与 SQL Server 代理程序活动互斥的邮件会话。
创建单独的配置文件

可以通过创建单独的邮件配置文件为 SQL 邮件和 SQLAgentMail 配置单独的邮箱。有两种方法可以完成这项工作：

  • 对每个服务使用单独的域帐户。这需要为每个用户帐户各配置一个邮件配置文件。

  • 对每个服务使用相同的域帐户并创建多个邮件配置文件。

有关设置和配置邮件客户程序及邮件配置文件的更多信息，请参见 Windows NT 4.0 和 Windows 2000 文档。


使用 SQL 邮件存储过程

SQL 邮件中包含许多存储过程，这些存储过程使您得以开发触发器、应用程序和其它存储过程。这些存储过程随后可用于操作邮件、运行查询、将结果集返回给一系列收件人，或回复含有简单查询或存储过程的电子邮件。

下表简要介绍了扩展过程及其使用方法。

SQL 邮件过程 | 函数
xp_startmail | 启动邮件客户程序会话。必须先启动邮件客户程序会话才能使用其它邮件存储过程。
xp_stopmail | 关闭 Microsoft® SQL Server™ 邮件客户程序会话。
xp_findnextmsg | 与 sp_processmail 一起使用，以便通过接受输入的消息 ID 和返回输出的消息 ID 来处理 SQL 邮件收件箱中的邮件。
xp_readmail | 由 sp_processmail 用来从 SQL 邮件收件箱中读取邮件消息。
xp_deletemail | 由 sp_processmail 用来从 SQL 邮件收件箱中删除消息。
xp_sendmail | 由 sp_processmail 使用或者作为存储过程或触发器的一部分。可与警报一起使用。向指定的收件人发送邮件和查询结果集附件。
sp_processmail | 使用扩展存储过程（xp_findnextmessage、xp_readmail 和 xp_deletemail）处理传入的邮件消息（应只是单个查询），并使用 xp_sendmail 将结果集返回给消息发件人。必须将 sp_processmail 设置成定期调度的作业以检查 SQL 邮件收件箱中接收的邮件。

使用 SQL 邮件

Transact-SQL


设置配置选项

通过使用 SQL Server 企业管理器或 sp_configure 系统存储过程配置选项，可以管理和优化 Microsoft® SQL Server™ 资源。大部分最常用的服务器配置选项都可以用 SQL Server 企业管理器来管理；而所有配置选项都可通过 sp_configure 访问。在设置这些选项之前应该认真考虑这些选项对系统的影响。

重要 高级选项是只能由有经验的系统管理员或认证的 SQL Server 技术人员来更改的选项。

使用sp_configure 系统存储过程

使用 sp_configure 时，必须在设置一个配置选项后运行 RECONFIGURE 或者 RECONFIGURE WITH OVERRIDE。RECONFIGURE WITH OVERRIDE 语句通常保留用于需要加倍小心的配置选项（例如，将 allow updates 选项设置为 1 使用户得以更新系统表中的字段）。但是，RECONFIGURE WITH OVERRIDE 可用于所有的配置选项，并且可以用它代替 RECONFIGURE。

下面是一个脚本示例，本示例使用 sp_configure 将 fill factor 选项从默认设置更改为值 100：

sp_configure 'fill factor', 100
GO
RECONFIGURE
GO
配置选项的分类

配置选项在下面两种情况下生效：

  • 在设置选项并发出 RECONFIGURE（在某些情况下 RECONFIGURE WITH OVERRIDE）语句之后立即生效。

    -或-

  • 完成上述操作后，停止并重新启动 SQL Server 实例。

若要用 sp_configure 配置高级选项，必须首先在将 show advanced options 选项设置为 1 的情况下运行 sp_configure，然后运行 RECONFIGURE：

sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
sp_configure 'cursor threshold', 0
GO
RECONFIGURE
GO

在前面的示例中，将 cursor threshold 选项重新配置为一个新值，该值立即生效。如果再次运行 sp_configure，则 resource timeout 的新值出现在配置选项的 run_value 列中。

但有些选项需要停止并重新启动服务器后，新的配置值才能生效。例如，在配置 affinity mask 选项前必须先将 show advanced options 设置为 1，运行 RECONFIGURE，然后停止并重新启动服务器。如果设置新值后在没有停止并重新启动服务器的情况下即运行 sp_configure，则新值将出现在配置选项的config_value 栏中，而不出现在 run_value 列中。停止并重新启动服务器之后，新值将出现在 run_value 列中。

如果使用 SQL Server 企业管理器更改一个配置选项，而该配置选项需要服务器停止并重新启动才能生效，则 SQL Server 将显示一个对话框询问是否想停止并重新启动服务器。

自配置选项指 SQL Server 根据系统需要进行调整的选项。在大多数情况下，这省去了手工设置这些选项的必要。这样的例子包括 min server memory、max server memory 和 user connections 选项。

配置选项表

下表列出了所有可用的配置选项、可能的设置范围及其默认值。配置选项旁的字母代码分别表示：

  • 高级选项（只能由认证的 SQL Server 技术人员更改，并且更改前需要将 show advanced options 设为 1），用"A"标识。

  • 需要服务器重新启动才能生效的选项，用"RR"标识。

  • 自配置选项（由 SQL Server 根据系统需要自行配置的选项），用"SC"标识。
配置选项 | 最小值 | 最大值 | 默认值
affinity mask (A, RR) | 0 | 2147483647 | 0
allow updates | 0 | 1 | 0
awe enabled (A, RR) | 0 | 1 | 0
c2 audit mode (A, RR) | 0 | 1 | 0
cost threshold for parallelism (A) | 0 | 32767 | 5
cursor threshold (A) | –1 | 2147483647 | -1
default full-text language (A) | 0 | 2147483647 | 1033
default language | 0 | 9999 | 0
fill factor (A, RR) | 0 | 100 | 0
index create memory (A, SC) | 704 | 2147483647 | 0
lightweight pooling (A, RR) | 0 | 1 | 0
locks (A, RR, SC) | 5000 | 2147483647 | 0
max degree of parallelism (A) | 0 | 32 | 0
max server memory (A, SC) | 4 | 2147483647 | 2147483647
max text repl size | 0 | 2147483647 | 65536
max worker threads (A, RR) | 32 | 32767 | 255
media retention (A, RR) | 0 | 365 | 0
min memory per query (A) | 512 | 2147483647 | 1024
min server memory (A, SC) | 0 | 2147483647 | 0
使用嵌套触发器 | 0 | 1 | 1
network packet size (A) | 512 | 65536 | 4096
open objects (A, RR, SC) | 0 | 2147483647 | 0
priority boost (A, RR) | 0 | 1 | 0
query governor cost limit (A) | 0 | 2147483647 | 0
query wait (A) | -1 | 2147483647 | -1
recovery interval (A, SC) | 0 | 32767 | 0
remote access (RR) | 0 | 1 | 1
remote login timeout | 0 | 2147483647 | 20
remote proc trans | 0 | 1 | 0
remote query timeout | 0 | 2147483647 | 600
scan for startup procs (A, RR) | 0 | 1 | 0
set working set size (A, RR) | 0 | 1 | 0
show advanced options | 0 | 1 | 0
two digit year cutoff | 1753 | 9999 | 2049
user connections (A, RR, SC) | 0 | 32767 | 0
user options | 0 | 32767 | 0

请参见

sp_configure

使用 SQL Server 中的选项


affinity mask 选项

在 Microsoft® Windows NT® 4.0 和 Windows® 2000 中，进行中的活动（线程）可以在处理器间迁移，每次迁移都刷新处理器高速缓存。在系统负荷繁重的情况下，指定一个处理器运行某特定的线程可以提高系统性能，方法是减少处理器缓存重新加载的次数。处理器和线程之间的关联称为处理器亲和力。

利用 affinity mask 选项可以在系统负荷过重时提高对称多处理器 (SMP) 系统（多于 4 个处理器）的性能。可以将线程与特定的处理器相关联，并指定 Microsoft SQL Server™ 要使用的处理器。也可以使 SQL Server 的活动在已由 Windows NT 4.0 或 Windows 2000 操作系统指派了特定工作负荷的处理器之外的处理器上运行。

如果将代表某处理器的位设为 1，则该处理器将被选择进行线程分配。如果将 affinity mask 设为 0（默认值），则由 Windows NT 4.0 或 Windows 2000 调度算法设置线程的亲和力。当把 affinity mask 设为任一非零值，SQL Server 亲和力逻辑将该值解释为指定可选处理器的位掩码。使 SQL Server 线程不运行在特定的处理器上有助于评估系统对 Windows NT 4.0 或 Windows 2000 专用进程的处理能力。例如，可以使用 affinity mask 评估其它网络接口卡 (NIC) 是否提高了性能，或评定负荷增加时的 NIC 性能。

由于 SQL Server 处理器亲和力是一项特殊的操作，建议仅在需要时才使用该功能。大多数情况下，Windows NT 4.0 或 Windows 2000 的默认亲和力可提供最佳性能。

在更改 affinity mask 设置前，要注意 Windows NT 4.0 和 Windows 2000 将与 NIC 相关联的延迟进程调用 (DPC) 活动指派给系统中编号最大的处理器。在安装了多块活动的 NIC 的系统中，每一块额外卡的活动都分配给系统中下一个最高数字代号的处理器。例如，一个有八个处理器、两块 NIC 卡的系统分别把其 DPC 安排给处理器 7 和处理器 6。

说明 可以使用系统监视器（在 Windows NT 4.0 中是性能监视器）查看并分析个别处理器的使用情况。

例如，如果处理器 1、2 和 5 是可用的，且位 1、2 和 5 均设为 1，而位 0、3、4、6 和 7为 0，则指定十六进制值 0x26，即十进制值的 38。将位从右至左进行编号。最右边的位为位 0。设置位 1、2 和 5（即第 3、第 5 和第 6 位）为 1，则根据指定的位计算而得的数字为为二进制的 00100110，亦即十进制的 38 或十六进制的 0x26。

下面是一个八处理器系统的 affinity mask 值。

十进制值 | 二进制掩码 | 允许 SQL Server 线程运行在哪些处理器上
1 | 00000001 | 0
3 | 00000011 | 0 和 1
7 | 00000111 | 0、1 和 2
15 | 00001111 | 0、1、2 和 3
31 | 00011111 | 0、1、2、3 和 4
63 | 00111111 | 0、1、2、3、4 和 5
127 | 01111111 | 0、1、2、3、4、5 和 6（仅使 SQL Server 活动与 DPC 处理器隔离）

affinity mask 是一个高级选项。如果使用 sp_configure 系统存储过程更改设置，则仅当 show advanced options 设置为 1 时才能更改 affinity mask。该设置在服务器停止并重新启动后生效。

配置亲和力掩码

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

使用系统监视器进行监视

RECONFIGURE

设置配置选项

sp_configure

SQL Server 任务调度


allow updates 选项

使用 allow updates 选项指定是否可以直接更新系统表。默认情况下，allow updates 选项被禁用（设为 0），所以用户不能通过特殊更新来更新系统表，而只能通过系统存储过程更新系统表。当禁用 allow updates 选项时，尽管您可能有足够的权限（由 GRANT 语句赋予），仍不能进行更新。

当启用 allow updates（设为 1），任何具有适当权限的用户都可以直接用特殊更新来更新系统表，或者创建可更新系统表的存储过程。

注意 更新系统表中的字段会防碍 Microsoft® SQL Server™ 实例运行或导致数据丢失。当您在启用 allow updates 选项时创建存储过程，则这些存储过程始终都可以更新系统表，即使在禁用 allow updates 时也如此。在生产系统中，除非有 Microsoft 产品支持服务的说明，否则应该禁用允许更新。

系统表对 SQL Server的运行非常关键，因此只应在严格控制的条件下启用 allow updates。若要在直接更新系统表时防止其他用户访问 SQL Server，可在命令提示符下运行 sqlservr –m 以重新启动 SQL Server 实例，该命令将在单用户模式下启动 SQL Server 实例并启用 allow updates。有关更多信息，请参见以最低配置启动 SQL Server。

如果使用 sp_configure 系统存储过程将 allow updates 设置为 1，则必须使用 RECONFIGURE WITH OVERRIDE 语句。该设置立即生效（无需停止并重新启动服务器）。

设置 allow updates 选项

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

GRANT

RECONFIGURE

设置配置选项

sp_configure


awe enabled 选项

在 Microsoft® SQL Server™ 2000 中，可以使用 Microsoft Windows® 2000 地址窗口扩展 (AWE) API 支持最多达 64 GB 的物理内存。可使用的具体内存量取决于硬件配置和操作系统支持能力。

说明 该功能仅适用于 SQL Server 2000 企业版和开发版。

启用 AWE

若要启用 AWE，请将 awe enabled 设置为 1。除非指定了 max server memory 的值，否则 SQL Server 将保留几乎所有可用内存，只留下 128 MB 或更少。

如果已成功启用该选项，则当 SQL Server 2000 实例启动时，SQL Server 错误日志中将出现"已启用地址窗口扩展"这条消息。

awe enabled 是高级选项。如果正在使用 sp_configure 系统存储过程更改该设置，则只有当 show advanced options 设置为 1 时才能更改 awe enabled。必须重新启动 SQL Server 2000 实例才能使更改生效。

禁用 AWE

若要禁用 AWE，请将 awe enabled 设置为 0。该设置是默认值。将不使用 AWE API。SQL Server 2000 运行在标准动态内存分配模式下，而且物理内存限制为 3GB。

使用注意事项

在启用 AWE 之前，请考虑下列事项：

  • 当将 awe enabled 设置为 1 时，SQL Server 2000 实例不能动态管理地址空间的大小。当服务器启动时，SQL Server 将保留并锁定几乎所有的可用内存（如果已设置该选项，则 SQL Server 将保留并锁定 max server memory 的值）。强烈建议每次启用 AWE 时为 max server memory 选项设置一个值。否则其它应用程序或 SQL Server 2000 实例将在不足 128 MB 的物理内存下运行。

  • 如果全部可用内存少于 3 GB，则 SQL Server 2000 实例将在非 AWE 模式下启动，即使 awe enabled 已设置为 1。这种情况下不需要管理 AWE 内存，因为已自动使用动态内存分配。

  • 可以通过识别在计算机上使用的所有其它应用程序启动之后还有多少内存可用，来确定可安全分配给 SQL Server 2000 实例的内存量。

    使用 SQL Server 性能监视器"总的服务器内存 (KB)"计数器确定在 AWE 模式下运行的 SQL Server 实例所分配的内存量。配置 max server memory 选项留出一些额外的可用内存以备其它应用程序和 Windows 2000 的各种需要。有关更多信息，请参见监视内存的使用。

重要 使用 awe enabled 选项和 max server memory 设置会对其它应用程序的性能或在多实例或群集环境中运行的 SQL Server 的性能造成负面影响。有关使用 AWE 内存的更多信息，请参见管理 AWE 内存。

示例

下例显示如何启用 AWE 并将 max server memory 配置在 6 GB 的限度：

sp_configure 'show advanced options', 1
RECONFIGURE
GO
sp_configure 'awe enabled', 1
RECONFIGURE
GO
sp_configure 'max server memory', 6144
RECONFIGURE
GO

请参见

内存构架

SQL Server:Buffer Manager 对象

RECONFIGURE

设置配置选项

sp_configure


c2 audit mode 选项

在 Microsoft® SQL Server™ 2000 中，可以使用 c2 audit mode 选项查看对语句和对象的成功和不成功的访问操作。通过这些信息，可以记录系统活动并找出违反安全策略的行为。

C2 审核跟踪 C2 审核事件并将它们记录到 SQL Server 2000 默认实例的 \mssql\data 目录中的某个文件内或 SQL Server 2000 命名实例的 \mssql$instancename\data 目录中的某个文件内。如果该文件达到了 200 兆字节 (MB) 的大小限制，则 C2 审核将启动新文件、关闭旧文件并将所有新审核记录写入新文件。该进程将一直继续，直到 SQL Server 关闭或审核关闭。

启用和禁用 C2 审核

在启用和禁用 C2 审核之前，请考虑下列事项：

  • 只有 sysadmin 角色成员才能启用或禁用 C2 审核。

  • c2 audit mode 是高级选项。如果使用 sp_configure 系统存储过程更改该设置，则只有在将 show advanced options 设置为 1 时才能更改 c2 audit mode。

  • 如果审核目录已满，SQL Server 实例将停止运行。如果未将审核设置为自动启动，则可以重新启动 SQL Server 实例。但是如果已将审核设置为自动启动，则在可以重新启动 SQL Server 实例之前必须为审核日志释放磁盘空间。

    另外，还可以用 –f 标记重新启动实例，该标记将回避所有审核。如果想禁用审核直到可以释放额外的磁盘空间，或在没有足够的磁盘空间分配给 200 MB 审核文件的紧急情况下禁用审核，则这种方法很有用。

若要启用 C2 审核，请将 c2 audit mode 选项设置为 1。该设置建立 C2 审核跟踪，并打开使服务器在由于任何原因不能写入审核文件时停止运行的选项。将该选项设置为 1 后，请重新启动服务器以开始 C2 审核跟踪。若要停止 C2 审核跟踪，请将 c2 audit mode 设置为 0。

重要 如果为所有对象打开所有审核计数器，可能会对服务器性能造成显著影响。

请参见

RECONFIGURE

设置配置选项

sp_configure


cost threshod for parallelism 选项

使用 cost threshold for parallelism 选项指定 Microsoft® SQL Server™ 创建和执行并行计划时的阈值。仅当为同一查询执行串行计划的估计成本比在 cost threshold for parallelism 选项中设定的值大时，SQL Server 才为该查询创建并执行一个并行计划。此处成本指的是在特定硬件配置中执行串行计划估计需要花费的时间（以秒为单位）。cost threshold for parallelism 只能在对称多处理器 (SMP) 系统中设置。

并行计划对需时较长的查询通常更有用；因其性能优势可以抵消并行计划初始化、同步和结束所需要的额外时间开销。cost threshold for parallelism 选项通常在短时间和长时间查询混合执行的情况下才会被积极地使用，短查询执行串行计划，而长查询执行并行计划。cost threshold for parallelism 的值确定了哪些查询是短查询，并且只执行串行计划。

在某些情况下，即使查询的成本计划小于当前 cost threshold for parallelism 的设置值，也有可能选择并行计划。这是因为，就 cost threshold for parallelism 而言，使用并行还是串行计划的决定是在全部优化完成前，根据所提供的估计成本做出的。

cost threshold for parallelism 选项可设置为 0 到 32767 之间的任何值。默认值为 5。

如果计算机只有一个处理器，或者由于 affinity mask 配置值的原因仅有一个处理器对SQL Server 可用，或者 max degree of parallelism 选项设为 1，则 SQL Server 将忽略 cost threshold for parallelism 选项。

cost threshold for parallelism 是一个高级选项。如果使用 sp_configure 系统存储过程更改该设置，则仅当 show advanced options 设为 1 时才可更改 cost threshold for parallelism。更改后该设置立即生效（无需服务器停止并重新启动）。

配置并行性成本阈值

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

affinity mask 选项

max degree of parallelism 选项

并行查询处理

RECONFIGURE

设置配置选项

sp_configure


cursor threshold 选项

使用 cursor threshold 选项指定游标集的行数，游标键集在该游标集中异步产生。如果将 cursor threshold 设为 –1，则所有游标键集将同步产生，这对于小游标集很有用。如果将 cursor threshold 设为 0，则所有游标键集异步产生。如果 cursor threshold 为其它值，查询优化器将比较游标集中所期望的行数和游标阈值的设置值，如果前者大于后者，则游标键异步产生。不要把 cursor threshold 值设得太低，因为小结果集以同步方式创建会更好一些。

当游标为某个结果集生成一个键集时，查询优化器估计将为该结果集返回的行数。如果查询优化器估计返回行的数目大于该阈值，则游标异步产生，使用户能够在游标继续填充的同时从中提取行。否则，游标同步产生，查询将等待所有的行返回。

查询优化器估计键集中行数的准确性取决于游标中各表统计的当前值。

cursor threshold 是一个高级选项。如果使用 sp_configure 系统存储过程更改该设置，则仅当 show advanced options 设为 1 时才可更改 cursor threshold。该设置立即生效（无需停止并重新启动服务器）。

设置 cursor threshold 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure

UPDATE STATISTICS


default full-text language 选项

使用 default full-text language 选项指定全文索引列的默认语言值。对所有全文索引的数据都执行语言分析，而语言分析依赖于数据的语言。该选项的默认值是服务器的语言。

如果未使用 sp_fulltext_column 指定列的语言，将使用 default full-text language 选项的值。如果对于指定的值没有可用的语言分析包，则使用中性。当列包含多种语言的数据或者如果不支持所使用的语言时，应使用中性。

下列语言分析包是 Microsoft® SQL Server™ 2000 的一部分。

语言 | 设置
简体中文 | 2052
繁体中文 | 1028
荷兰语 | 1043
英语（英国） | 2057
英语（美国） | 1033
法语 | 1036
德国 | 1031
意大利 | 1040
日语 | 1041
朝鲜语 | 1042
中性 | 0
现代西班牙语 | 3082
默认瑞典语 | 1053

可以添加其它语言（例如，独立软件开发商可以提供其它语言）。

default full-text language 选项取代了 SQL Server 7.0 版中的 language neutral full-text 选项。在从 SQL Server 7.0 升级时，需要根据 SQL Server 7.0 配置选项 Unicode locale id 和 default full-text language 的值来设置 language neutral full-text 值。这样做将获得与 SQL Server 7.0 应用程序的兼容性。

default full-text language 是一个高级选项。如果使用 sp_configure 系统存储过程更改该设置，则只有当 show advanced options 设置为 1 时才能更改 default full-text language。

设置 default full-text language 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure

sp_fulltext_column


default language 选项

使用 default language 选项为所有新创建的登录指定默认语言。若要设置 default language，请从 syslanguages 表中列出的语言中指定所需语言的 langid 值。有关更多信息，请参见 syslanguages。

可以使用 sp_addlogin 或 sp_defaultlanguage 替代登录的默认语言。会话的默认语言是该会话登录的语言，除非使用 ODBC 或 OLEDB API 替代每个会话的默认语言。

说明 会话语言可以在会话过程中通过 SET LANGUAGE 更改。有关更多信息，请参见 SET LANGUAGE。

有关会话语言所确定内容的信息，请参见 SQL Server 语言支持。

设置默认语言

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


fill factor 选项

使用 fill factor 选项指定当使用现有数据创建新索引时，Microsoft® SQL Server™ 应使每一页填满的程度。由于 SQL Server 必须在填充时花费时间分割这些页面，所以 fill factor 百分比会影响系统性能。

fill factor 百分比仅在创建索引时使用。这些页面都不可能被维护在任何特定的饱满水平上。

fill factor 的默认值为 0；其有效值是从 0 到 100。fill factor 的值为 0 并不表示页面的填满程度为 0%。类似于 fill factor 设置为 100 的情况，SQL Server 在 fill factor 值为 0 时，会用页面全部为数据的页来创建聚集索引，用页面全部为数据的叶子页来创建非聚集索引。与 fill factor 设置为 100 的情况不同的是，SQL Server 在索引树的高层级别上预留空间。很少有理由去改变 fill factor 的默认值，因为可以使用 CREATE INDEX 命令来覆盖它。

较小的 fill factor 值将导致 SQL Server 以不饱满的页面创建新索引。例如，将 fill factor 值设置为10 对于想在一个最终将保持较少数据的表上创建索引是合适的。越小的 fill factor 值将导致每一个索引占用更多的存储空间，但同时也允许以后可不进行页面拆分进行插入操作。

如果设置 fill factor 值为 100，SQL Server 以100% 的饱满度创建聚集和非聚集索引。设置 fill factor 的值为 100 仅对只读表是合适的，因为数据从来不被添加到此类表中。

fill factor 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把当 show advanced options 设置为 1 时仅能更改 fill factor，该选项在停止并重新启动服务器后生效。

设置固定的填充因子

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

CREATE INDEX

RECONFIGURE

设置配置选项

sp_configure


index create memory 选项

index create memory 选项用来控制索引创建排序时所需的内存数量。index create memory 选项是自配置选项，在大多数情况下不需调整即可正常工作。然而，如果创建索引时遇到困难，则考虑增加该选项的运行值。查询排序由 min memory per query 选项控制。

本选项的默认值是 0（自动配置）。

index create memory 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1。该选项立即生效（无需停止并重新启动服务器）。

设置 index create memory 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

服务器内存选项

设置配置选项

sp_configure


lightweight pooling 选项

使用 lightweight pooling 选项提供一种方法，以减少有时在对称多处理器 (SMP) 环境下遇到的、与过多的上下文切换有关的系统开销。如果过多的上下文切换情况出现，lightweight pooling 可以通过上下文切换内联化，从而降低 User/Kernel 环的转换频率，达到提高吞吐量的目的。

将 lightweight pooling 设置为 1 将使 Microsoft® SQL Server™ 切换到纤程模式调度。该选项的默认值为 0。

lightweight pooling 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该选项在停止并重新启动服务器后生效。

设置 lightweight pooling 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure

SQL Server 任务调度

使用 lightweight pooling 选项


locks 选项

使用 locks 选项设置可用锁的最大数量，以限制 Microsoft® SQL Server™ 用于锁的内存量。默认设置为 0，即允许 SQL Server 根据系统需要动态分配和收回锁。

当服务器以 locks 的设置为 0 启动，锁管理器分配 SQL Server 可用内存的 %2 给锁结构初始池当锁池耗尽时，系统会分配另外的锁，动态锁池的内存分配不能多于 SQL Server分配到的内存的 %40。

通常情况下，如果锁需要的内存比当前可用的内存少，而更多的服务器内存是可用的（max server memory 上限还没有达到），则 SQL Server 动态分配内存满足锁的需求。然而，如果内存分配导致操作系统级的换页（例如，如果另一个应用程序与 SQL Server 实例运行于同一台计算机上并使用该计算机上的内存），则将分配更多的锁空间。

建议让 SQL Server 动态使用锁。然而，可以设置 locks 从而覆盖 SQL Server 动态分配锁资源的能力。如果SQL Server显示已经没有可用的锁的消息，请增大该选项的值。由于每一个锁都需要消耗内存（每一个锁需 96 字节），增加该值将增加整个服务器对内存的需要。

locks 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为1，该选项在停止并重新启动服务器后生效。

设置 locks 选项

Transact-SQL

SQL-DMO

请参见

锁定

RECONFIGURE

设置配置选项

sp_configure


max degree of parallelism 选项

使用 max degree of parallelism 选项限制在并行计划执行中使用的处理器数（最多 32 个）。默认值为 0，亦即使用实际 CPU 的数量。设置 max degree of parallelism 为 1 将禁止并行计划产生若将该值设置为大于 1 的数，则单个查询执行中可用的处理器最大数量被限制为这个数。如果值比指定的可用 CPU 数大，则使用实际可用的 CPU 数。

说明 在对称多处理器 (SMP) 系统中，如果 affinity mask 选项未设置为默认值，则 Microsoft® SQL Server™ 可使用的 CPU 数可能受到限制。

对于在 SMP 计算机上运行的服务器不应经常更改 max degree of parallelism 选项。如果计算机中仅有一个处理器，那么 max degree of parallelism 的值被忽略。

max degree of parallelism 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该选项立即生效（无需服务器停止并重新启动）。

除了查询之外，该选项还控制 DBCC CHECKTABLE、DBCC CHECKDB 和 DBCC CHECKFILEGROUP 的并行度。使用跟踪标记 2528 可替代并行检查。有关更多信息，请参见跟踪标记。

设置 max degree of parallelism 选项

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

affinity mask 选项

cost threshold for parallelism 选项

RECONFIGURE

设置配置选项

sp_configure


max text repl size 选项

使用 max text repl size 选项可以设定在执行单个INSERT、UPDATE、WRITEEXT或者UPDATEEXT命令时可以增添到复制字段的 text 和 image 数据的大小（单位为字节）。

该设置立即生效（无需停止并重新启动服务器）。

设置 max text repl size 选项

Transact-SQL

SQL-DMO

请参见

INSERT

RECONFIGURE

复制概述

设置配置选项

sp_configure

UPDATE

UPDATETEXT

WRITETEXT


max worker threads 选项

使用 max worker threads 选项配置 Microsoft® SQL Server™ 进程的可用工作线程数。SQL Server 使用 Microsoft Windows NT® 4.0 或 Windows® 2000 操作系统的本机线程服务，以使一个或多个线程支持 SQL Server 同时支持的每一网络，另一个线程处理数据库检查点，而线程池处理所有用户。

当大量客户连接到服务器上时，线程池能够帮助优化系统性能。通常地，对于每一个客户都创建一个独立的操作系统线程，每一线程耗费很少的系统资源。然而，由于同时有数百个连接，为每一连接创建一个线程可能耗费大量的系统资源。max worker threads 使得 SQL Server 能够为大量的客户连接建立工作线程池，从而提高性能。

max worker threads 的默认设置值 (255) 对大多数系统是最优的。然而，取决于您的系统配置，将 max worker threads 设置为一个稍小的值有时会提高性能。

当实际的用户连接数量少于 max worker threads 的设置值时，每一个线程处理一个连接。但如果实际的连接数量大于 max worker threads 中的设置数量时，SQL Server 建立工作线程池以便下一个可用的工作线程可以处理用户请求。

当达到工作线程的最大数量时，SQL Server 返回如下信息：

The working thread limit of 255 has been reached.

Windows 98 不支持线程池，因此该选项在这些系统中无效。

max worker threads 是一个高级选项。如果要使用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该选项立即生效（无需服务器停止并重新启动）。

配置最大工作线程数目

企业管理器

企业管理器 企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure

SQL Server 任务调度


media retention 选项

media retention 选项能够改变系统范围的在进行数据库或事务日志备份后媒体保持的时间。media retention 选项使得在指定的日期没有到期前所做的备份不被覆盖。如果设置了 media retention 选项，则没有必要在每次进行系统备份时都要指定媒体需要保持的时间默认为 0 天。如果在备份媒体没有超过设置的天数前就使用它，则 Microsoft® SQL Server™ 将发出一条警告信息。除非改变默认值，否则 SQL Server 不给出警告信息。

本选项可以由BACKUP 命令的 RETAINDAYS 子句覆盖。

media retention 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该设置在停止并重新启动服务器后生效。

设置备份保持期

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

备份和还原数据库

BACKUP

RECONFIGURE

设置配置选项

sp_configure


min memory per query 选项

使用 min memory per query 选项指定将分配给查询执行时所需要的最小内存量（以 KB 为单位）。例如，如果将 min memory per query 设置为 2048 KB，则查询保证将至少获取那么多的总内存。可以将 min memory per query 设置为从 512 到 2147483647 KB (2 GB) 之间的任何值。默认设置为 1024KB。

Microsoft® SQL Server™ 2000 查询处理器尝试确定分配给查询的最佳内存量。min memory per query 选项允许管理员指定任何一个查询将获得的最小内存量。如果查询需对大量数据执行哈希和排序操作，则这些查询获得的内存通常比该选项指定的最小内存多。对于一些小型查询和中等大小的查询，增大 min memory per query 的值可以提高性能，但会导致内存资源争夺加剧。min memory per query 包括分配给排序的内存，并替换 SQL Server 7.0 版或早期版本中的 sort pages 选项。

min memory per query 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把"显示高级选项"设置为 1，该选项立即生效（无需服务器停止并重新启动）。

设置最小查询内存

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


nested triggers 选项

nested triggers 选项用来控制一个触发器是否能够嵌套（即能够执行某项操作初始化另一个触发器，该触发器又能初始化另外一个，如此等等）。当将 nested triggers 设置为0时，触发器不能层叠。如果 nested triggers 设置为 1（默认值），触发器最多能够层叠到 32 层。

该设置立即生效（无需停止并重新启动服务器）。

设置 nested triggers 选项

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

使用嵌套触发器

RECONFIGURE

设置配置选项

sp_configure


network packet size 选项

使用 network packet size 选项设置整个网络中使用的包的大小（以字节为单位）。包是固定大小的数据块，它们在客户端和服务器之间传输请求和结果。Microsoft® SQL Server™ 设置的默认数据包大小为 4096 字节。如果一个应用程序要进行大量的拷贝操作，或者发送或接收大量的 text 或 image 数据，比默认值更大一些的包大小能够提高效率，因为它能够减少网络读写的次数。如果应用程序发送和接收较小数量的信息，可以设置包的大小为 512 字节，这对大多数数据传输已足够。

说明 除非您确信能够提高性能，不要改变包大小。对于大多数应用程序而言，最好使用默认包大小。

在使用不同网络协议的系统中，设置 network packet size 为最常用的协议包的大小。当网络协议支持大数据包时，network packet size 能够提升网络性能。客户应用程序可以替代该值。

您也可以调用 OLE DB、ODBC 和 DB-Library 函数来改变包大小。

network packet size 是一个高级选项。如果要使用 sp_configure 系统存储过程改变该设置，只有在 show advanced options 设置为 1 时才能更改network packet size。该设置更改后所创建的所有连接都接收新值。

配置数据包的大小

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


open objects 选项

使用 open objects 选项设置在 Microsoft® SQL Server™ 实例上可同时打开的数据库对象的最大数。数据库对象是指那些定义在表 sysobjects 中的对象，包括表、视图、规则、存储过程、默认值和触发器。

默认情况下，open objects 是动态自配置选项（当该值设置为 0 时）。也就是说，SQL Server 根据当前需要设置该值。在大多数情况下，没有必要改变该值。

如果 SQL Server 显示一条"打开的对象过多"的消息，应该考虑增大 open objects 的设置值。由于打开对象要耗费内存，增大该选项值将减少 SQL Server 使用的其它内存，并将引起整个服务器对内存的需要变化。默认值是允许 SQL Server 根据需要设置和增加 open objects。

在服务器启动时，SQL Server 服务器在内存中将创建一个描述符数据结构池，用来在数据库对象被引用时描述该对象。而创建的描述符数量等于 open objects 选项的设置值。当一个数据库对象第一次被引用时，SQL Server 从空闲的描述符数据池中取出一个并分配给此对象。如果多个任务同时引用同一个对象，仅视为一个打开的对象。

例如，两个任务同时发出如下命令：

UPDATE table_a SET cola = @variable

此时只有一个描述符分配给了 table_a，而 table_a 被视为一个打开的对象。然而，如果 table_a 有一个更新触发器，系统将分配第二个描述符给该触发器，把它作为第二个打开的对象。

每一个分配了的描述符都有一个使用计数器，该计数器指明有多少个并发查询正在引用它描述符所定义的对象。使用计数器在一个查询开始时增加 1，在查询结束时减少 1。在上一个例子中，table_a 描述符在那两个查询结束前有 2 个使用计数；查询都结束后则减为 0。

在所有空闲的描述符池用光之后，当需要分配一个新的描述符时，SQL Server 开始重新使用那些非活动的描述符。非活动描述符的使用记数为 1。SQL Server 第一次被迫重新使用一个描述符时将向错误日志中发出如下消息：

Warning: OPEN OBJECTS parameter may be too low;
attempt was made to free up descriptors in localdes().
Run sp_configure to increase parameter value.

以后 SQL Server 在被迫重新使用一个描述符每达到 1000 次后，就会重复一次该消息。如果注意到错误日志中有频繁记录的的该消息，请设置 open objects 选项为一个较高的值。

open objects 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该设置在停止并重新启动服务器后生效。

设置 open objects 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


priority boost 选项

使用 priority boost 选项指定 Microsoft® SQL Server™ 运行所基于的 Microsoft Windows NT® 4.0 或 Windows® 2000 调度优先级是否应比同一台计算机上的其它进程高。如果将该选项设置为 1，则 SQL Server 以 Windows NT 4.0 或 Windows 2000 调度程序的优先级基数 13 运行。默认值为 0，优先级基数为 7。

priority boost 应仅应用于 SQL Server 专用计算机上，而且应具有对称多处理器 (SMP) 配置。

注意 若将 SQL Server 优先级提升过高，将会耗尽基本操作系统和网络功能运行所需的资源，导致关闭 SQL Server 或在该服务器上运行其它 Windows NT 4.0 或 Windows 2000 任务时出现问题。

在某些情况下，设置 priority boost 选项为除默认值之外的任何其它值将导致下面的通信错误，该错误被记录于 SQL Server 错误日志中。

Error: 17824, Severity: 10, State: 0 Unable to write to ListenOn
connection '<servername>', loginname '<login ID>', hostname '<hostname>'
OS Error: 64, The specified network name is no longer available.

错误 17824 表示 SQL Server 试图向客户端写信息时出现连接问题。该通信问题可能由于网络有问题所致，比如客户停止响应或者客户端已被重新启动，但错误 17824 并不一定总是说明网络有故障。此时应检查 priority boost 选项确保该选项设置为默认值，该值偏离了默认值也可能导致错误 17824。

priority boost 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该设置在停止并重新启动服务器后生效。

设置优先级提升选项

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure

线程和纤程执行


query governor cost limit 选项

query governor cost limit 选项用来指定一个查询所能运行的最高时间限制。查询成本是指在特定的硬件配置中，执行查询所耗费的估计时间（以秒为单位）。

如果为该选项指定一个非零、非负的数值，则查询调控器将不允许执行估计成本超过该值的查询。指定为 0（默认值）则将关闭查询调控器。在这种情况下，所有查询都允许运行。

如果用 sp_configure 来改变 query governor cost limit 值，则值的改变在整个服务器范围有效。若要在每个连接的基础上改变该值，请使用 SET QUERY_GOVERNOR_COST_LIMIT 命令。

query governor cost limit 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该选项立即生效（无需服务器停止并重新启动）。

设置 query governor cost limit 选项

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

SET QUERY_GOVERNOR_COST_LIMIT

设置配置选项

sp_configure


query wait 选项

在 Microsoft® SQL Server™ 中，当没有足够的内存运行查询时，大量占用内存的查询（如那些涉及排序和哈希操作的查询）将排队等待。查询在一段时间之后将会超时，该时间或者由 SQL Server 计算（估计查询耗费时间的 25 倍），或者由查询等待选项设定的非负数值确定。

query wait 选项可以设定一个查询在超时前等待所需资源的时间（以秒为单位，范围从 0 到2147483647）。如果使用默认值 –1 或指定 –1，则超时时间通过计算得到，是预计查询成本的 25 倍。

重要 包含等待查询的事务在查询等待内存时可以控制锁。在极个别的情况下，可能会发生无法检测到的死锁。减少查询等待时间可降低这类死锁的概率。最终，等待的查询将被终止并且事务锁将被释放。但是，增大等待时间将增大该类查询被终止的时间。不建议改变该选项。

query wait 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该选项立即生效（无需服务器停止并重新启动）。

设置 query wait 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure

线程和纤程执行


recovery interval 选项

使用 recovery interval 选项设置 Microsoft® SQL Server™ 恢复数据库所需的最大分钟数。SQL Server 实例每次启动时，将恢复每个数据库，回滚没有提交的事务，前滚已提交但在 SQL Server 实例停止时未将更改写入磁盘的事务。该配置选项设置了 SQL Server 在恢复每一个数据库时所应花时间的上限。默认值为 0，表示由 SQL Server 自动配置。实际上，这表示每个数据库的恢复时间不超过 1 分钟，对于每个活动的数据库大约每 1 分钟有一个检查点。

recovery interval 决定了在每一个数据库中 SQL Server 何时进行一次检查。检查点操作在每一个数据库基上进行。在一个检查点上，SQL Server 确保所有日志信息和所有更改了的页面都被从内存刷新到磁盘上。这样通过减少前滚事务的数量减少了数据库恢复所需要的时间。因为在检查点上所有更改都已经被刷新到磁盘，所以就不需要向前滚回事务。

recovery interval 不影响恢复长时间事务。例如，如果一个长时间事务在服务器失效前进行了 2 个小时的更新操作，那么实际的恢复操作会很正常地花比 recovery interval 值大的时间回滚该长时间事务。

SQL Server 将估计在恢复时间间隔期间可以前滚多少更改的数据。一个数据库中，当最近一个检查点之后数据更改操作达到了 SQL Server 认为可以在恢复时间间隔更新的数量时，SQL Server 将进行一个检查点操作。如果数据更改操作还未达到估计的数字，有时 SQL Server 将在日志达到 70% 时发出检查点命令。有关更多信息，请参见检查点和日志的活动部分。

每一个数据库的检查点发生频率取决于数据更改的数量，而不是以时间为基础的方式来确定。主要用于只读操作的数据库没有很多检查点。而事务数据库则具有经常发生的检查点。

保持 recovery interval 设置为 0（自配置），除非注意到检查点发生得太过频繁而削弱了性能。如果上述情况发生，则尝试以较小增量增加该值。

recovery interval 是一个高级选项。如果要使用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为 1，该选项立即生效（无需服务器停止并重新启动）。

设置恢复间歇

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure

sp_dboption


remote access 选项

使用 remote access 选项控制从运行 Microsoft® SQL Server™ 实例的远程服务器的登录。remote access 与远程存储过程一起使用。设置 remote access 为 1（默认值）表示允许从远程服务器上登录。设置该选项为 0 则防止从从远程服务器上访问该本地服务器。

该设置在停止并重新启动服务器后生效。

设置远程服务器访问

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


remote login timeout 选项

remote login timeout 选项用来指定远程登录失败返回前等待的秒数。例如，如果试图登录到一个远程服务器而该服务器已关闭，remote login timeout 确保您在计算机停止登录尝试前不必无限期地等待下去。

remote login timeout 影响与 OLE DB 提供程序的连接，该程序是为异类查询而开发的。remote login timeout 的默认设置为 20 秒。0 值允许无限时等待。

该设置立即生效（无需停止并重新启动服务器）。

设置 remote login timeout 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


remote proc trans 选项

使用 remote proc trans 选项在 Microsoft® 分布式事务处理协调器 (MS DTS) 事务中保护服务器之间过程的操作。把 remote proc trans 设置为 1 来提供一个由 MS DTC 协调的分布式事务，该事务能保护事务的 ACID 属性。设置该选项为 1 后所有新开始的会话将继承该设置并把它作为默认值。

该设置立即生效（无需停止并重新启动服务器）。

有关 ACID 属性的更多信息，请参见事务。

有关 MS DTC 的更多信息，请参见 Microsoft 分布式事务处理协调器文档。

为远程过程强制分布式事务处理

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


remote query timeout 选项

使用 remote query timeout 选项指定在处理远程操作时，命令超时（Microsoft® SQL Server™ 认为命令已失败或查询执行的时间太长）前需等待的秒数。默认值为 600，表示允许等待十分钟。

对于异类查询，remote query timeout 指定远程提供程序在查询超时前应等待的秒数（由命令对象使用 DBPROP_COMMANDTIMEOUT rowset 属性初始化）。如果远程提供程序支持该值，则该值还用于设置 DBPROP_GENERALTIMEOUT。这将导致任何其它操作在指定的秒数后超时。

对于远程存储过程，remote query timeout 指定在发出一个远程"EXEC sp"之后，在远程存储过程超时前必须等待的秒数。

该设置立即生效（无需停止并重新启动服务器）。

设置远程查询时间限制

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

行集属性和行为

设置配置选项

sp_configure


scan for startup procs 选项

使用 scan for startup procs 选项在 Microsoft® SQL Server™ 启动时扫描自动执行的存储过程。如果该选项设置为 1，SQL Server 将扫描并执行服务器上定义的所有自动执行的存储过程。scan for startup procs 的默认设置是 0（不扫描）。

该选项的值可由 sp_configure设置；然而，如果使用 sp_procoption，则会自动进行设置，sp_procoption 可用于将存储过程标志成或取消标志成自动执行 (autoprocs)。当 sp_procoption 把第一个存储过程标志为一个自动执行过程 (autoproc)，该选项被自动设置为值 1。当 sp_procoption 把最后一个存储过程取消标志为自动执行过程 (autoproc)，该选项被自动设置为值 0。如果用 sp_procoption 标志或取消标志自动处理 (autoproc)，而且总是在删除它们前进行取消标志，所以没有必要手工设置该选项。

scan for startup procs 是一个高级选项。如果要使用 sp_configure 系统存储过程改变该选项，必须把 show advanced options 设置为 1，该设置在停止并重新启动服务器后生效。

设置 scan for startup procs 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure

sp_procoption


服务器内存选项

使用两个服务器内存选项 min server memory 和 max server memory 重新配置缓冲池中 Microsoft® SQL Server™ 实例所使用的内存量（以 MB 为单位）。

默认情况下，SQL Server 能够可用系统资源动态改变它的内存需求。min server memory 的默认设置为 0，max server memory 的默认设置为 2147483647。可以为 max server memory 指定的最小内存量为 4 MB。

当 SQL Server 动态使用内存时，它要求系统定期地检测可用的物理内存数量。SQL Server 根据服务器活动增大或收缩高速缓冲存储器，以使可用物理内存保持在 4 MB 到 10 MB 之间。这就避免了 Microsoft Windows NT® 4.0 或 Windows® 2000 换页。如果有较少可用内存，则 SQL Server 将内存释放给 Windows NT 或 Windows 2000，后者通常继续使用可用列表。如果有更多可用内存，则 SQL Server 将内存再提交到高速缓冲存储器。SQL Server 仅在其工作负荷需要更多的内存时才增加高速缓冲存储器的内存；处于休眠状态的服务器不增大其高速缓冲存储器。

允许 SQL Server 动态使用内存是推荐使用的配置；然而，可以手工设置内存选项并且可以禁止 SQL Server 动态使用内存的能力。在设置 SQL Server 使用的内存量之前，应确定适当的内存设置，方法是从全部物理内存中减去 Windows NT 4.0 或 Windows 2000 以及 SQL Server 的任何其它实例所需要的内存（以及其它系统使用的内存，如果该计算机不为 SQL Server 专用）。这就是可以分配给 SQL Server 使用的最大内存量。

说明 如果您已经安装并且运行了全文检索支持功能（Microsoft 检索服务，亦即 MSSearch），那么您必须手工设置 max server memory 选项，为 MSSearch 服务运行预留足够的内存。max server memory 设置必须与 Windows NT 4.0 虚拟内存大小一起进行调整，以便使得保留给全文检索的虚拟内存是物理内存的 1.5 倍（不包括计算机中其它服务所需的虚拟内存）。应这样配置 SQL Server max server memory 选项，使得留有足够的虚拟内存满足全文检索内存需求。全部虚拟内存 -（SQL Server 最大虚拟内存 + 其它服务需要的虚拟内存）>= 1.5 倍物理内存。

手工设置内存选项

手工设置 SQL Server 内存选项有两种主要方法：

  • 第一种方法，设置 min server memory 和 max server memory 为同一数值。该数值与分配给 SQL Server 的固定内存量相对应。

  • 第二种方法，把 min server memory 和 max server memory 数量设置到一个范围段内。这种方法在系统或数据库管理员希望配置 SQL Server 实例，使其适应在同一台计算机上运行的其它应用程序的内存需求时很有用。

min server memory 保证了 SQL Server 实例使用的最小内存量。SQL Server 启动时不立即分配 min server memory 中所指定的内存量。但是，当内存使用由于客户端负荷而达到该值后，SQL Server 将无法从已分配的缓冲池中释放内存，除非减少 min server memory 值。

说明 不保证 SQL Server 分配 min server memory 中所指定的内存量。如果服务器上的负荷从不需要分配 min server memory 中所指定的内存量，则 SQL Server 将以较少的内存运行。

max server memory 则可防止 SQL Server 使用多于指定数量的内存，这样剩余的可用内存可以快速运行其它应用程序。SQL Server 启动时不立即分配 max server memory 中所指定的内存。内存使用随 SQL Server 的需要而增长，直到达到 max server memory 中所指定的值。SQL Server 无法超过该内存使用值，除非增加 max server memory 值。

重要 服务器启动时，在地址窗口扩展 (AWE) 内存模式下运行的 SQL Server 实例确实分配 max server memory 中所指定的全部内存量。有关 AWE 内存的更多信息，请参见管理 AWE 内存。

在应用程序启动和 SQL Server 释放内存之间将有一个较短的时间延迟，使用 max server memory 可以避免该延迟，从而可以提高其它应用程序的性能。仅当与 SQL Server 共享同一台服务器的新应用程序在启动时显示有问题时，才设置 min server memory。最好让 SQL Server 使用全部可用的内存。

如果手工设置内存选项，应确保适当地设置用于复制的服务器。如果服务器是一个远程分发者或者是一个出版者/分发者的组合，则必须为它分配至少 16 MB 的内存。

理想情况下，在不引起系统交换页面到磁盘的前提下，应尽可能多地分配内存给 SQL Server。该值因系统不同而有很大差别。例如，在一个 32 MB 系统中，分配 16 MB 给 SQL Server可能是合适的；在一个 64 MB 系统中，则可能适合分配 48 MB。

说明 当增大 SQL Server 内存数量时，应确保有足够的磁盘空间来容纳操作系统虚拟内存的支持文件（Pagefile.sys）。有关虚拟内存支持文件的更多信息，请参见 Windows NT 4.0 和 Windows 2000 文档。

指定的内存数量必需满足 SQL Server 的静态内存（核心开销、打开的对象、锁等等）以及数据缓存（亦称高速缓存）的需要。

如有必要，在系统监视器（在 Windows NT 4.0 中为性能监视器）中使用统计功能帮助调整内存值。应该只有在您添加或减少内存，或者改变系统使用方式时改变这些值。

虚拟内存管理器

Windows NT 4.0 和 Windows 2000 随时提供一个 4 GB 的虚拟地址空间，其中较低的 2 GB 地址空间对于每个进程是专用的，并可由应用程序使用。较高的 2 GB 地址由系统保留使用。Windows NT Server 企业版为每个 Microsoft Win32® 应用程序提供 4 GB 的虚拟地址空间，其中较低的 3 GB 地址空间是每个进程专用的，并可由应用程序使用。较高的 1 GB 地址由系统保留使用。

4-GB 的地址空间由 Windows NT V虚拟内存管理器（VMM）映射到可用的物理内存空间。取决于硬件平台的支持，可用的物理内存可以高达 4 GB。

Win32 应用程序（如 SQL Server）只能识别虚拟（或称逻辑）地址，而不是物理地址。在给定的某一时刻一个应用程序使用多少物理内存由可用的物理内存和 VMM所决定。应用程序不能直接控制物理内存。

象 Windows NT 4.0 或 Windows 2000 这样的虚拟地址系统允许过度提交物理内存，这使虚拟内存和物理内存的比率大于 1:1。因此，较大的程序可以运行在具有不同物理内存配置的计算机上。然而应用比组合平均工作集大得多的虚拟内存可能导致较差的性能。

SQL Server 可以将内存锁定为工作集。因为内存被锁定了，当运行其它应用程序时可能出现内存不足的错误。如果出现内存不足的错误，则可能是分配给 SQL Server 的内存太多。set working set size选项（通过 sp_configure 或 SQL Server 企业管理器设置) 可以使锁定内存为工作集功能失效。默认情况下，set working set size 选项处于禁用状态。

手工配置给 SQL Server 多于物理内存数量的虚拟内存会导致性能较低。而且，必须考虑 Windows NT 4.0 或 Windows 2000 操作系统的内存需求（大约 12 MB，因应用程序的开销而略有不同）。当 SQL Server 的配置参数上调时，系统的开销可能也会增长，因为 Windows NT 4.0 或 Windows 2000 需要更多的常驻内存来支持附加的线程、页表等。允许 SQL Server to 动态使用内存可以避免内存相关的性能问题。

min server memory 和 max server memory 是高级选项。如果要使用 sp_configure 系统存储过程改变该选项，必须把 show advanced options 设置为 1，该选项立即生效（无需停止并重新启动服务器）。

设置固定的内存量

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

监视服务器性能和活动

RECONFIGURE

复制概述

设置配置选项

sp_configure


set working set size 选项

使用 set working set size 选项为 Microsoft® SQL Server™ 保留等于服务器内存设置的物理内存空间。服务器内存设置由 SQL Server 根据工作负荷和可用资源自动配置，其大小在 min server memory 和 max server memory 之间动态变化。设置 set working set size 表示即使当 SQL Server 空闲时，另一个进程可以很容易地使用 SQL Server 页，Microsoft Windows NT® 4.0 或 Windows® 2000 也不会将 SQL Server 页交换出去。

不要设置 set working set size 选项，如果允许 SQL Server 动态使用内存的话。在设置 set working set size 为 1 前，应把 min server memory 和 max server memory 设置为同一个数值，该值应为希望 SQL Server 使用的内存数量。

set working set size 是一个高级选项。如果要用 sp_configure 系统存储过程改变该选项，必须把 show advanced options 设置为 1，该选项在停止并重新启动服务器后生效。

设置工作集大小选项

企业管理器

企业管理器

Transact-SQL

请参见

RECONFIGURE

服务器内存选项

设置配置选项

sp_configure


show advanced options 选项

show advanced options 选项用来显示 sp_configure 系统存储过程高级选项。当设置 show advanced options 为 1 时，才可以使用 sp_configure 列出高级选项。默认值为 0。

该设置立即生效（无需停止并重新启动服务器）。

设置 show advanced options 选项

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


two digit year cutoff 选项

two digit year cutoff 选项为了解释 2 数字年份为 4 数字年份，从 1753 到 9999 之间选出一个整数来表示世纪结尾年份。

一个比结尾年份的后两位数字小或者与其相等的两数字年份与该结尾年份处于同一个世纪。A而一个比结尾年份的后两位数字大的两数字年份所处的世纪比与该结尾年份所处的世纪要早。比如，如果 two digit year cutoff 是 2049（默认值），那么两数字年份 49 被解释为 2049 年，而两数字年份 50 被解释为 1950。

说明 Microsoft® SQL Server™ 使用 2049 作为日期的截止年份；而 OLE 自动化对象则用 2030 作为截止年份。可以使用 two digit year cutoff 选项使 SQL Server 和客户应用程序之间的日期值一致。然而，为了在使用日期时避免含糊歧义，请在日期中使用 4 位数字的年份。

设置两位数年份截止点选项

企业管理器

企业管理器

Transact-SQL


user connections 选项

使用 user connections 选项指定允许同时连接到 Microsoft® SQL Server™ 的最大用户数。实际允许的用户连接数还取决于正使用的 SQL Server 版本以及应用程序和硬件的限制。SQL Server 最多允许同时 32,767 个用户连接。

因为 user connections 是动态的（自动配置选项），SQL Server 将根据需要自动调整用户连接的最大用户数，最大不超过允许的最大值。例如，如果仅有 10 个用户登录，则要分配 10 个用户连接对象。在大多数情况下，没有必要改变该选项的值。

可以使用 SQL 查询分析器和下面的 Transact-SQL 语句来确定系统允许的最大用户连接数：

SELECT @@MAX_CONNECTIONS

user connections 可以避免服务器因过多的并发连接而过载。可以根据系统和用户需求估计连接数量。例如，在一个有许多用户的系统中，通常每一个用户可能不需要一个唯一的连接，连接可以在用户中间共享。运行 OLE DB 应用程序的用户需要为每个打开的连接对象启动一个连接，运行 ODBC 应用程序的用户需要为应用程序中的每个活动连接句柄启动一个连接，而运行 DB-Library 应用程序的用户需要为调用 DB-Library dbopen 函数的每个进程启动一个连接。

重要 如果必须使用该选项，则不要将值设置得太高，因为不论是否使用连接，每个连接都需要大约 40 KB 的开销。如果超过了用户连接的最大允许值，将收到一条错误信息，而且直到出现一个可用连接之前不能够建立连接。

user connections 是一个高级选项。如果要用 sp_configure 系统存储过程改变该选项，必须把 show advanced options 设置为 1，该设置在停止并重新启动服务器后生效。

设置用户连接

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


user options 选项

user options 选项指定对所有用户有效的默认值。系统在用户的工作会话期间，将建立一个默认查询处理选项列表。user options 允许更改这些 SET 选项的默认值（如果服务器的默认设置不合适）。用户可以用 SET 命令来覆盖这些默认值。对于每个新的登录用户都可以动态配置 user options。在改变 user options 的设置值之后，新的登录用户将使用新的设置，当前登录的用户不受影响。

值 | 配置 | 描述
1 | DISABLE_DEF_CNST_CHK | 控制临时或延迟约束检查。
2 | IMPLICIT_TRANSACTIONS | 控制当一个命令执行后，事务是否隐性启动。
4 | CURSOR_CLOSE_ON_COMMIT | 控制提交操作执行后游标的行为。
8 | ANSI_WARNINGS | 控制集合警告中的截尾和 NULL 符。
16 | ANSI_PADDING | 控制定长变量的填充。
32 | ANSI_NULLS | 当使用相等运算符时控制 NULL 处理。
64 | ARITHABORT | 在查询执行过程中发生溢出或被零除错误时终止查询。
128 | ARITHIGNORE | 查询中如发生溢出或被零除错误返回 NULL。
256 | QUOTED_IDENTIFIER | 表达式分析时区分单引号和双引号。
512 | NOCOUNT | 关闭在每个命令执行后报告有多少行被改变的提示信息。
1024 | ANSI_NULL_DFLT_ON | 改变会话使用 ANSI 兼容的空值。没有明确指明是否使用空值的新列定义为允许使用空值。
2048 | ANSI_NULL_DFLT_OFF | 改变会话不使用 ANSI 兼容的空值。没有明确指明是否使用空值的新列定义为不允许使用空值。
4096 | CONCAT_NULL_YIELDS_NULL | 当将 NULL 值与字符串串联时返回 NULL。
8192 | NUMERIC_ROUNDABORT | 当表达式中发生精度损失时生成错误。
16384 | XACT_ABORT | 如果 Transact- SQL 语句产生了运行时错误，则回滚事务。

说明 并不是所有的 user options 配置值之间互相兼容。例如，当ANSI_NULL_DFLT_OFF 已启用时，ANSI_NULL_DFLT_ON 不能启用。

user options 中的字位位置与 @@OPTIONS 中的字位位置相同。每一个连接都有其自己的 @@OPTIONS 函数，该函数表示自己的配置环境。当登录到 Microsoft® SQL Server™ 时，默认情况下，系统将当前的 user options 值赋给 @@OPTIONS。对 user options 执行 SET 命令会影响当前会话 @@OPTIONS 中的相对应的值。

在该设置更改之后创建的所有连接都接收新值。

配置用户选项

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

RECONFIGURE

设置配置选项

sp_configure


管理客户端

客户程序是前端应用程序，它使用服务器提供的服务。该应用程序的宿主计算机称为客户计算机。客户端软件使计算机可以连接到网络中的 Microsoft® SQL Server™ 实例。

SQL Server 客户程序可以包括各种应用程序，如：

  • OLE DB 使用者。

    这些应用程序使用用于 SQL Server 的 Microsoft OLE DB 提供程序或用于 ODBC 的 Microsoft OLE DB 提供程序连接到 SQL Server 实例。OLE DB 提供程序充当 SQL Server 和客户端应用程序之间的中介，这些客户端应用程序使用 SQL Server 数据作为 OLE DB 行集。

  • ODBC 应用程序。

    这些程序包括与 SQL Server 一起安装的客户端实用工具，如 SQL Server 企业管理器和 SQL 查询分析器，以及其它使用 SQL Server ODBC 驱动程序连接到 SQL Server 实例的应用程序。

  • DB-Library 客户程序

    这些客户程序包括 SQL Server isql 命令提示实用工具和写到 DB-Library 中的客户程序。

无论应用程序是何类型，管理客户端主要包括配置它与 SQL Server 服务器组件的连接。根据您的站点要求，客户端管理的范围可以从小到输入服务器计算机名称，大到生成自定义配置项目库以满足各种多服务器环境。

简单客户端管理

对多数客户端而言，可以不加修改地使用在 SQL Server 安装过程中安装的默认网络配置。对那些能够连接的客户端而言，只需提供运行 SQL Server 的一个或多个实例的服务器的网络名称即能连接。对 ODBC 客户端而言，可能需要向客户端提供 ODBC 数据源名称并知道如何配置 ODBC 数据源。

高级客户端管理

高级用户可以创建和保存个别的网络协议配置。这在 SQL Server 客户端与多台运行不同网络协议的服务器连接时，或在使用了独特的站点设置（如非标准端口地址）时很有用。

配置客户端之前

在配置 SQL Server 客户端之前：

  • 必须在客户机和服务器上安装 SQL Server Net-Library 的匹配对。默认情况下，所有的 SQL Server 客户端 Net-Library 和服务器端 Net-Library 都在执行安装程序时自动安装。每一对 Net-Library 支持一个特定的网络协议（例如，客户端 TC/IP 套接字 Net-Library 和服务器端 TC/IP 套接字 Net-Library 支持 TCP/IP）。在安装中或安装后，应使用 SQL Server 网络实用工具激活某些 SQL Server 服务器 Net-Library（如 NWLink IPX/SPX）来监听客户端。

  • 在客户端和服务器上必须安装正确的网络协议。网络协议一般是在 Microsoft Windows® 安装过程中安装的；它们不是 SQL Server 安装程序或配置的一部分。只有当客户端和服务器上都已安装了与 SQL Server Net-Library 相对应的网络协议时，SQL Server Net-Library 才有效。
客户端管理工具

下列工具用于管理大多数类型的 SQL Server 客户程序：

  • 客户端网络实用工具使您得以更改默认的网络协议，并创建和保存定义如何连接指定服务器的项。

    该应用程序作为标准 SQL Server 客户端安装程序的一部分安装。SQL Server 客户端网络注册为客户端网络协议配置和默认网络协议创建注册表项。不要使用该应用程序安装 SQL Server Net-Library 或网络协议。

  • 安装程序和 SQL Server 网络库配置使您得以选择和激活服务器端 Net-Library（所有客户端和服务器端 Net-Library 都在安装过程中安装）。

    激活服务器端 Net-Library 使 SQL Server 得以在对应的网络协议上监听客户端。实际的网络协议作为 Windows 安装的一部分（或通过"控制面板"中的"网络"）安装。

  • ODBC 数据源管理器（可通过"控制面板"中的"ODBC"使用）使您能在运行 Microsoft Windows NT® 4.0、Windows 2000、Windows 95 或 Windows 98 操作系统的计算机上配置 ODBC 数据源。

请参见

SQL Server 网络实用工具


客户端 Net-Library 和网络协议

Microsoft® SQL Server™ 使用一个称为 Net-Library 的动态链接库 (DLL) 与特定的网络协议通讯。匹配的 Net-Library 对在客户端和服务器计算机上必须是活动的，才能支持所需的网络协议。例如，若要使客户端应用程序能通过 TCP/IP 与特定的 SQL Server 实例通讯，必须在客户计算机上将客户端 TCP/IP 套接字 Net-Library (DBNETLIB.dll) 配置为与那台服务器连接，同时服务器 TCP/IP 套接字 Net-Library (SSNETLIB.dll) 必须在服务器计算机上监听。

对于一对 Net-Library，本身并不支持客户端/服务器连接。客户端和服务器也必须都运行支持 Net-Library 的协议栈。例如，如果服务器 TCP/IP 套接字 Net-Library 在服务器计算机上监听，并且客户计算机上的客户端 TCP/IP 套接字 Net-Library 被配置成与那台服务器连接，那么，客户端只有在两台计算机上都安装了 TCP/IP 协议栈时才能连接到服务器上。

多网络协议支持

命名管道和多协议 Net-Library 都支持多网络协议（NW Link IPX/SPX、NetBEUI 和TCP/IP），并将自动选择任何所支持的可用网络协议。如果客户端必须连接到多个运行不同网络协议的服务器上，而您不想为每一个服务器-网络协议组合都创建和管理配置项，则使用这些 Net-Library 的其中一个是有用的。

Net-Library 的安装和默认设置

在 SQL Server 安装过程中安装客户端 Net-Library。通过客户端网络实用工具，定义使用哪些客户端 Net-Library 连接到特定的 SQL Server 实例。可以为所有连接指定一个默认的 Net-Library，还可以定义使用特定的 Net-Library 连接特定的 SQL Server 实例。在运行 Microsoft Windows NT® 4.0、Windows® 2000、Windows 95 或 Windows 98 操作系统的客户端上，TCP/IP 是默认协议。

SQL Server 可以同时监听任意组合的服务器 Net-Library。在安装过程中或安装完成后使用 SQL Server 网络库配置来选择已激活的服务器端 Net-Library。

对于运行 Windows NT 4.0 或 Windows 2000 的计算机，默认服务器 Net-Library 是：

  • TCP/IP 套接字。

  • 命名管道。

对于运行 Windows 98 的计算机，默认服务器 Net-Library 是：

  • TCP/IP 套接字。

  • 共享内存。

当在工作站上安装 SQL Server 客户端实用工具时，SQL Server 安装程序将 TCP/IP 作为默认客户端协议安装。

如果大多数将要连接的服务器没有配置为支持当前的默认客户端协议，则可以将默认设置更改为另一个协议。

有关 SQL Server Net-Library 及其所支持的网络协议的更多信息，请参见通讯组件

SQL Server 2000 可以使用安全套接字层 (SSL) 加密在应用程序计算机与数据库计算机上的 SQL Server 实例之间传输的所有数据。客户计算机和服务器计算机都必须安装适当的证书才能使 SSL 加密发挥作用。

由于共享内存 Net-Library 只用于计算机内通讯，因此具备固有的安全性，无需加密。有关更多信息，请参见 Net-Library 加密。


配置客户端网络连接

Microsoft® SQL Server™ 2000 的每个实例都在一组唯一的网络地址上监听，因此应用程序可以连接到不同的实例。SQL Server 2000 客户端不需要任何特殊的配置即可连接 SQL Server 2000 实例。SQL Server 2000 客户端组件查询运行一个或多个 SQL Server 2000 实例的计算机以确定用于每个实例的 Net-Library 和网络地址。客户端组件然后自动为连接选择所支持的 Net-Library 和地址，而无需在客户端上进行任何配置。应用程序必须提供的唯一信息是计算机名和实例名。

SQL Server 2000 默认实例在与 SQL Server 7.0 版或更早版本相同的网络地址上监听，因此使用早期版本的客户端连接组件的应用程序可以继续连接到默认实例，而无需进行任何更改。但是，命名 SQL Server 2000 实例在备用网络地址上监听，所以必须将使用早期版本客户端连接组件的客户计算机设置为连接备用地址。

默认情况下，在运行 Windows NT 4.0 和 Windows 2000 的计算机上，SQL Server 实例监听服务器 TCP/IP 套接字和命名管道 Net-Library。在运行 Windows 98 的计算机上，SQL Server 实例监听 TCP/IP 套接字和多协议 Net-Library。如果是在一台计算机上进行本地连接（客户端和服务器位于同一台计算机上），则 SQL Server 实例监听服务器共享内存 Net-Library。

有关早期版本的客户端网络实用工具的兼容性问题的信息，请参见 SQL Server 2000 和 SQL Server 7.0 版。


配置客户端 Net-Library

客户端网络实用工具作为 Microsoft® SQL Server™ 客户端安装程序的一部分安装。该应用程序中包括几个选项卡和对话框，可以在其中：

  • 创建到指定服务器的客户端连接，并将这些连接保存为配置项，配置项包括一个服务器别名、客户端 Net-Library 和任何相关的连接参数，如管道文件名称或端口号。当想重新配置客户端连接时，可以使用任何保存的配置项。

  • 更改默认的客户端 Net-Library。

  • 显示有关系统上当前安装的 SQL Server 客户端 Net-Library 的信息。

  • 显示系统上当前安装的 DB-Library 版本，并为 DB-Library 选项设置默认值。

    重要 客户端网络实用工具为服务器别名配置和默认的客户端 Net-Library 创建注册表项。该程序不安装 SQL Server 客户端 Net-Library 和网络协议。SQL Server 客户端 Net-Library 在 SQL Server 安装过程中安装。网络协议作为 Microsoft Windows® 安装程序的一部分（或通过"控制面板"中的"网络"）进行安装。特定的网络协议可能不会作为 Windows 安装程序的一部分提供。有关安装这些网络协议的更多信息，请参见供应商文档。

查看网络库信息

如果客户端网络实用工具没有显示 Net-Library 的版本号，而您正在使用由 Microsoft 提供的 Net-Library ，则可能发生了下列问题：

  • 使用的版本已不再受到支持。

  • 客户端网络实用工具找不到路径中指定的库。

  • 找不到选定的默认网络库所需的组件。

显示网络库文件和版本信息

Client Network Utility

客户端实用工具

更改默认配置

客户端网络实用工具的大多数功能是为打算创建和编辑客户端配置项的高级用户设计的。大多数情况下，客户端默认设置都有效。

对于使用 SQL Server 2000 客户端连接组件连接到 SQL Server 2000 命名实例的应用程序，配置 Net-Library 的工作已得到了极大的简化。只需：

  • 在安装过程中选择安装在应用程序计算机上的客户端协议。

  • 在安装 SQL Server 实例的过程中选择启用的服务器协议。

不需要进行其它配置。然后即可通过指定数据库计算机的网络名称和实例名连接到 SQL Server 2000 的任何实例。

说明 如果配置的别名正与错误的服务器或实例进行连接，则请禁用并重新启用相关联的网络协议。这将清除任何已缓存的连接信息并允许进行正确的连接。

客户端网络实用工具和 SQL Server 网络实用工具都不列出共享内存 Net-Library。通常情况下，共享内存是为本地连接启用的，没有可配置的属性。

说明 可以使用客户端网络实用工具禁用共享内存 Net-Library。这有助于隔离连接问题。

虽然在只连接到 SQL Server 2000 实例的 SQL Server 2000 应用程序计算机上不需要任何配置操作，但可以将客户端网络实用工具用于：

  • 启用客户端协议（如果需要连接到不支持已启用的客户端协议之一的 SQL Server 实例）。

  • 禁用不再需要的客户端协议。

  • 更改在连接 SQL Server 实例时 SQL Server 考虑使用的客户端协议的顺序。

  • 为所有的计算机间的连接启用安全套接字层 (SSL) 加密。

    在启用 SSL 加密之前，必须在数据库计算机上安装由证书颁发机构颁发的服务器证书，而客户端也必须已安装了由同一证书颁发机构颁发的根 CA 证书。有关 SSL 加密的更多信息，请参见 Net-Library 加密。

如果使用 SQL Server 2000 客户端组件的应用程序计算机连接到运行 SQL Server 7.0 版或更早版本实例的数据库计算机，则只有当 SQL Server 不在默认网络地址上监听时，才需要配置客户端 Net-Library。当在客户端网络实用工具中添加命名管道别名时，可以在"计算机名称"框中单独指定数据库计算机的网络名称。

配置多协议别名

在配置多协议别名时，可以启用加密。该加密功能只适用于多协议 Net-Library，而且与 SQL Server 7.0 版和更早版本中提供的多协议加密相同。提供该加密功能只是为与现有应用程序兼容。建议 SQL Server 2000 客户端使用客户端网络实用工具的"启用协议加密"复选框中"常规"选项卡上指定的 SSL 加密。

启动客户端网络实用工具

Client Network Utility


设置客户端配置项

默认情况下，在 Microsoft® Windows NT® 4.0、Microsoft Windows® 2000、Windows 95 或 Windows 98 操作系统上运行的客户端使用客户端 TCP/IP 协议。如果是下面的情况，可能需要使用备用的 Net-Library：

  • 需要添加特定的客户端配置以与特定的服务器通讯。

  • 要与之通讯的服务器被配置为监听另一个端口。

在上述任一情况下，必须在客户端上创建配置项。

客户端网络实用工具使您得以配置下列任何网络协议以便与特定服务器进行通讯：

  • 命名管道

  • TCP/IP 套接字

  • 多协议

  • NWLink IPX/SPX

  • AppleTalk

  • Banyan VINES

  • 其它（用于第三方提供的网络协议）

必须先安装协议的 Net-Library 才能设置配置。如果没有安装某个网络协议的客户端 Net-Library，则该协议不会列在"网络库"选项卡上。也可以通过"添加网络库配置"对话框中的"其它"选项，为第三方提供的网络协议设置配置。

重要 客户端为了能够连接到 Microsoft SQL Server™ 实例，必须使用与某一监听服务器的协议相匹配的协议。例如，如果客户端试图使用 TCP/IP 连接到 SQL Server 的实例，而服务器上只安装了 NWLink IPX/SPX 协议，则客户端将不能建立连接。在这种情况下，必须使用服务器上的 SQL Server 网络实用工具激活服务器 NWLink IPX/SPX 协议，而且必须使用客户端上的 SQL Server 网络实用工具将客户端 NWLink IPX/SPX 协议配置为连接到该服务器。客户端和服务器都必须运行相同的网络协议。

SQL Server 按下列方式使用客户端配置信息：

  • 如果服务器名称与"服务器别名配置"列表中指定的服务器匹配，则客户端使用与该配置相关联的协议和参数建立连接。

  • 如果服务器名称与"服务器别名配置"列表中指定的服务器不匹配，则使用默认协议。

  • 如果没有定义默认协议，则使用 TCP/IP。

添加网络库配置

Client Network Utility

客户端实用工具

编辑网络库配置

Client Network Utility

客户端实用工具

删除网络库配置

Client Network Utility


TCP/IP 套接字客户端

Microsoft® SQL Server™ 支持与使用标准 Microsoft Windows® 套接字的 TCP/IP 网络协议进行客户端通讯。

重要 在支持平台上，已针对 TCP/IP 套接字 Net-Library 与 SQL Server 实例的连接性能做了广泛的测试。如果从第三方供应商购买了一个非 TCP/IP 套接字网络协议并想用它连接到 SQL Server，那么，如果该协议正确支持 TCP/IP 套接字，则连接应当能够建立。然而，不保证一定能在这些平台上使用第三方 TCP/IP 协议。可以从命令行使用 ping 命令来测试套接字能否运行。

通过使用 DHCP 和 WINS 简化系统管理

Microsoft Windows NT® 3.5 版或更高版本提供了管理大型 TCP/IP 网络的简单方法，该方法为自动 TCP/IP 配置提供动态主机配置协议 (DHCP) 服务，并为网络名称和地址的动态映射提供 Windows Internet 名称服务 (WINS)。这使用户几乎不需要管理支持即可在大型 TCP/IP 网络环境下操作。

如果网络有 DHCP 服务和 WINS，则可以使用 SQL Server 实例名指定与服务器的连接。如果网络没有这些服务，应通过 IP 地址指定服务器。

配置使用 TCP/IP（客户端网络实用工具）的客户端

Client Network Utility


命名管道客户端

命名管道客户端通常使用默认管道上的服务器实例名建立连接。但是，如果服务器设置为监听一个备用管道，则客户端也必须配置为与那个管道通讯。

将客户的别名设置为一个备用管道

Client Network Utility


多协议客户端

多协议选择有两个主要功能：

  • 自动选择与 Microsoft® SQL Server™ 实例通讯的可用网络协议。

    若想连接到多个运行不同网络协议的服务器上，但不想为每一个服务器重新配置客户端连接，则该功能很方便。如果在客户端和服务器上安装了 TCP/IP 套接字、NWLink IPX/SPX 或命名管道的客户端和服务器端 Net-Library，多协议 Net-Library 将自动选择第一个可用的网络协议建立连接。

  • 客户端加密。

    在运行 Microsoft Windows NT® 4.0、Windows® 2000、Windows 95 或 Windows 98 操作系统的客户端上，可以对多协议 Net-Library 强制加密以防止其他人截取和查看敏感数据。

多协议 Net-Library 利用 Windows NT 4.0 和 Windows 2000 的远程过程调用 (RPC) 功能，该功能可提供 Windows 身份验证。对多协议 Net-Library，客户端使用服务器名称来确定服务器地址。

使用注意事项

在使用多协议 Net-Library 之前,应考虑下列事项：

  • 多协议 Net-Library 不支持 SQL Server 2000 命名实例。可以使用多协议 Net-Library 连接计算机上的 SQL Server 默认实例，但不能连接任何命名实例。

  • 多协议 Net-Library 不支持服务器枚举。从可以通过调用 dbserverenum 列出服务器的应用程序中，无法识别运行 SQL Server 实例和监听多协议 Net-Library 的服务器。
多协议名称解析

利用通过多协议 Net-Library 调用的 RPC 运行时，客户端可以使用多种其它协议连接到服务器。建立连接时，多协议 Net-Library 将计算机名称传递给 RPC 运行时，RPC 运行时确定可用的网络协议并尝试每一种协议直到建立连接。（只有 NWLink IPX/SPX、TCP/IP 套接字和命名管道已经过测试并得到支持。）

为了实现计算机名称与节点的连接，RPC运行时使用与所用的网络协议兼容的名称服务（对 TCP/IP 使用 WINS，对 NWLink IPX/SPX 使用 SAP，对命名管道使用 Net BIOS 广播）。只需指定计算机名称，因为使用本地 RPC 数据库来解析所支持协议上的名称。

客户端加密

可以在每个客户端对多协议 Net-Library 强制加密。只有该客户端的通讯被加密。其它使用多协议 Net-Library 但未设置该参数的客户端不使用加密。

配置使用多协议 Net-Library 的客户端

Client Network Utility


NetWare Link IPX/SPX 客户端

通过使用与 NW Link IPX/SPX 兼容的传输——Novell NetWare 网络的本机协议，可以将 Microsoft® SQL Server™ 客户端配置为与 SQL Server 实例通讯。

客户端网络实用工具为创建 NW Link IPX/SPX 网络协议配置提供以下两种说明方法：

  • 按服务名称和端口号

  • 按网络地址、端口号和网络号

在设置配置之前向网络管理员咨询这方面的信息。

将客户端配置为使用 NWLink IPX/SPX 网络库

Client Network Utility


AppleTalk ADSP 客户端

Microsoft® SQL Server™ 可以与使用 AppleTalk ADSP 网络协议的客户端通讯。

AppleTalk Net-Library 不支持服务器枚举。从可以通过调用 dbserverenum 列出服务器的应用程序中，无法识别监听 AppleTalk Net-Library 的 SQL Server 实例。

如果通过 AppleTalk 从客户端建立连接时遇到困难，可查看 Microsoft Windows® 应用程序日志和 SQL Server 错误日志中列出的错误信息，并检查是否正确装载了 AppleTalk Net-Library。

如果 AppleTalk Net-Library 已正确装载在服务器上，则会在 Windows 应用程序日志或 SQL Server 错误日志中看到类似下面的消息：

Using 'SSMSADSN.DLL' version '6.00.0.0' to listen on 'servicename'

将客户端配置为使用 AppleTalk 网络库

Client Network Utility


Banyan VINES 客户端

Microsoft® SQL Server™ 支持 Banyan VINES IP 网络协议上的 Banyan VINES 顺序数据包协议 (SPP)。

运行 Microsoft Windows NT® 4.0 或 Windows® 2000 操作系统的客户端需要 Banyan VINES 客户端软件 5.56(2) 版或更高版本。

在 StreetTalk 语言中，基于 PC 的服务名称的格式是：servicename@group@org，这里 servicename 是服务器使用的 StreetTalk 基于 PC 的服务名称。

说明 必须使用 Banyan VINES 软件中包含的 MSERVICE 程序先创建服务器使用的服务名称。

如果客户程序提供了 StreetTalk 名称的一部分（不包含组和单位的名称）作为服务器名称，VINES SPP Net-Library 将通过标准的 VINES 服务，使用登录默认设置补全 StreetTalk 名称的剩余部分。如果在用户自己的组和单位中找不到与服务器名称匹配的基于 PC 的服务或别名，VINES SPP Net-library 将在单位中查找一个叫做 MSSQL 的特殊组。这使网络管理员得以定义一个 SQL Server 组，该组可通过同一单位内所有组中的一部分名称来访问。

通过使用客户端网络实用工具修改 Banyan VINE 属性，可以替代默认名称 MSSQL。

VINES SPP Net-Library 文件不支持在 StreetTalk 名称中包含嵌入式空格，它们对每个服务器使用一个 VINES IP 套接字，对每个数据库连接使用一个 SPP 连接。

将客户端配置为使用 Banyan VINES 网络库

Client Network Utility


VIA 客户端

Microsoft® SQL Server™ 2000 引入了一些新的 Net-Library，可用于在同一数据中心的服务器之间进行高度可靠、快速、高效的数据传输。这些新的 Net-Library 包含适合基于虚拟接口构架 (VIA) 的不同硬件设备的功能。SQL Server 2000 附带了支持来自 Giganet 的硬件的 Net-Library。

配置客户端使用 VIA 网络库

Client Network Utility

客户端网络实用工具

请参见

SQL Server 网络实用工具

通讯组件


其它网络协议客户端

可以为"添加网络库配置"对话框中未列出的网络协议创建网络配置。为此，请使用"其它"选项。若要使用该选项，必须已经安装了支持该网络协议的客户端和服务器端 Net-Library。

如果与客户端通讯的服务器监听第三方提供的协议，例如 NLSPY32，使用"其它"选项。

若要使用该选项，必须了解：

  • 第三方提供的网络库的 DLL 名称。

  • 任何所需参数及其格式。

将客户端配置为使用非标准的网络库

Client Network Utility


配置 ODBC 数据源

ODBC 应用程序使用数据源连接到 Microsoft® SQL Server™ 实例。数据源是一个存储定义，记录：

  • 连接到数据源所使用的 ODBC 驱动程序。

  • ODBC 驱动程序连接到数据源所使用的信息。

  • 连接所使用的驱动程序特有的选项。例如，SQL Server ODBC 数据源可以记录要使用的 SQL-92 选项，或者驱动程序是否应记录性能统计。

客户端上的每个 ODBC 数据源都有一个唯一的数据源名称 (DSN)。SQL Server ODBC 驱动程序的 ODBC 数据源包含用于连接到 SQL Server 实例的全部信息以及任何基本选项。


使用 ODBC 数据源管理器

若要配置 Microsoft® SQL Server™ ODBC 数据源，请使用 ODBC 数据源管理器。有关更多信息，请参见其它实用工具。

使用 ODBC 数据源管理器可以：

  • 显示系统上当前安装的 SQL Server ODBC 驱动程序的版本信息。

  • 添加、更改和删除 SQL Server ODBC 驱动程序的数据源。

ODBC 数据源管理器可以为用户、系统和文件数据源创建选项卡。

用户数据源专门用于在创建时即生效的 Microsoft Windows NT® 4.0、Windows® 2000、Windows 95 或 Windows 98 帐户。用户数据源对任何其它的登录帐户是不可见的。对于在运行 Windows NT 4.0 或 Windows 2000 的计算机上作为服务运行的应用程序，用户数据源并不总是可见的。

系统数据源对客户端上的所有登录帐户都是可见的。对于在运行 Windows NT 4.0 或 Windows 2000 的计算机上作为服务运行的应用程序，系统数据源始终是可见的。

ODBC 3.0 版中新增了文件数据源。文件数据源不存储在系统注册表中，而是存储在客户端的文件中。

当选择了数据源类型后，ODBC 数据源管理器便启动 SQL Server DSN 配置向导，指导您一步步地添加 ODBC 数据源。

查看 ODBC SQL Server 驱动程序版本

Client Network Utility


使用 ODBC API 函数

也可以通过将下列 ODBC API 函数之一写入应用程序来添加 ODBC 数据源，以连接 Microsoft® SQL Server™ 实例。

SQLConfigDataSource

ODBC 应用程序可以调用 fRequest 参数设为 ODBC_ADD_DSN 或 ODBC_ADD_SYS_DSN 的 SQLConfigDataSource 函数，来创建用户或系统数据源。

SQLWriteFileDSN

ODBC 应用程序可以调用 SQLWriteFileDSN 函数创建文件数据源。

SQLDriverConnect

如果应用程序在成功调用 SQLDriverConnect 所使用的连接字符串中指定了 SAVEFILE 关键字，则使用 SQLDriverConnect 连接字符串中指定的信息创建文件数据源。

SQLCreateDataSource

ODBC 应用程序可以调用函数 SQLCreateDataSource 以显示一个 ODBC 对话框，指导用户逐步创建数据源。

引用 SQL Server ODBC 驱动程序的数据源中包含驱动程序特有的信息和选项。当使用 SQLConfigDataSource 或 SQLWriteFileDSN 创建数据源时，所有驱动程序特有的信息都通过传给该函数的字符串中的关键字值对来提供。当使用"ODBC 数据源管理器"或"SQLCreateDataSource"对话框创建数据源时，将唤醒调用 SQL Server DSN 配置向导以帮助指定驱动程序特有的信息。

请参见

SQLConfigDataSource

SQLDriverConnect

SQLPrepare


添加或删除 ODBC 数据源

必须添加 ODBC 数据源才能将 ODBC 客户端添加到 Microsoft® SQL Server™ 实例。可以使用"控制面板"中的"ODBC 数据源管理器"和 SQL Server DSN 配置向导完成此项工作。也可以使用几个 ODBC API 函数之一，通过编程添加数据源；然而，只建议高级用户使用这些方法。

可以使用几种方法删除 ODBC 数据源：

  • 使用"控制面板"中的"ODBC 数据源管理器"实用工具。

  • 调用 SQLConfigDataSource，并将 fRequest 参数设为 SQL_REMOVE_DSN 或 SQL_REMOVE_SYS_DSN。

  • 删除包含数据源的文件。

添加数据源

ODBC

ODBC

删除数据源

ODBC

ODBC

请参见

添加数据源

SQLConfigDataSource


配置 OLE DB 客户端

配置 OLE DB 客户端连接到 Microsoft® SQL Server™ 时，需要通过 OLE DB 提供程序使服务器名称和连接信息可由客户端（或 OLE DB 使用者）使用。通过 OLE DB 建立 SQL Server 连接一般使用：

  • 用于 SQL Server 的 Microsoft OLE DB 提供程序 (SQLOLEDB)。

  • 用于 ODBC 的 Microsoft OLE DB 提供程序。
连接 SQLOLEDB 客户端

SQLOLEDB 是 SQL Server 的本机 OLE DB 提供程序，它为那些想访问一个或更多 SQL Server 实例上的数据的使用者表现接口。使用 SQLOLEDB 使您得以开发出为 SQL Server 数据库进行优化的 OLE DB 使用者。与用于 ODBC 的 Microsoft OLE DB 提供程序（该程序可从许多遵从 OLE DB 的 ODBC 应用程序访问数据）不同，只能使用 SQLOLEDB。不能使用 ODBC SQL Server 数据源名 (DSN) 中的信息进行连接。

通过用于 SQL Server 的 Microsoft OLE DB 提供程序设置客户端时，客户端应提供必需的连接特性，并且提示输入连接数据，或者从保存在持续文件中的 OLE DB 数据源中提供该数据。

连接用于 ODBC 客户端的 OLE DB 提供程序

通过用于 ODBC 的 Microsoft OLE DB，可以使用单个 OLE DB 提供程序连接到多个 ODBC 数据源，其中包括 SQL Server。然而，与用于 SQL Server 的本机 Microsoft OLE DB 提供程序相比，通过此提供程序连接到 SQL Server 客户端需要更大的管理开销。

通常情况下，当通过用于 ODBC 的 Microsoft OLE DB 提供程序连接到 SQL Server 实例时，所需信息通过 ODBC 数据源管理器创建并保存在 SQL Server ODBC DSN 中（作为用户、系统或文件 DSN）。因此，可以编写应用程序代码以使用 SQL Server DSN 建立连接。

请参见

OLE DB SQL Server 应用程序设计


DB-Library 选项

客户端网络实用工具中包含安装在计算机上的 DB-Library 的文件信息，以及用来设置 DB-Library 首选项的选项。这些选项包括：

  • DB-Library 信息

    包括当前安装的 DB-Library 的文件名、版本、日期和大小。此类信息在您遇到与 DB-Library 有关的技术支持问题时很有用。

  • ANSI 到 OEM 自动转换

    使 DB-Library 能在与 Microsoft® SQL Server™ 实例通讯时将字符由 OEM 转换为 ANSI，并在从 SQL Server 实例与客户端通讯时将字符由 ANSI 转换为 OEM。默认情况下，为运行 Microsoft Windows NT® 4.0、Windows® 2000、Windows 95 或 Windows 98 的客户机选择"ANSI 到 OEM 自动转换"选项。有关更多信息，请参见使用 DB-Library 中的 ANSI 到 OEM 自动转换选项。

  • 使用国际设置

    使 DB-Library 能从系统中获得日期、时间和货币格式，而不是使用硬编码参数或 Sqlcommn.loc 中指定的参数。默认情况下，对于运行 Windows NT 4.0、Windows 2000、Windows 95 或 Windows 98 的客户端，选择"使用国际设置"选项。

设置 DB-Library 转换首选项

Client Network Utility


使用 DB-Library 中的 ANSI 到OEM 自动转换选项

当启用"ANSI 到 OEM 自动转换"选项时，该选项将在进行下列通讯时转换字符集：

  • 从 ANSI 客户端到 OEM 服务器。

  • 从 OEM 客户端到 ANSI 服务器。

默认情况下启用该选项。当禁用该选项时，对所有连接都禁用字符转换。

如果客户端代码页与 SQL Server 实例上的代码页不同，则应转换字符集。Microsoft Windows NT®、Microsoft Windows® 2000、Windows 95 以及 Windows 98 既有 ANSI 字符集又有 OEM 字符集，这些字符集是在安装过程中设置的。对于美国英语，Windows NT、Windows 2000、Windows 95 和 Windows 98 使用代码页 1252 的默认 ANSI 字符集和代码页 437 的默认 OEM 字符集。Windows 3.x 作为 MS-DOS 的扩展运行，只包含代码页 1252 的默认 ANSI 字符集。Windows NT 4.0 和 Windows 2000 控制台内部是 Unicode，Unicode 的表现与 OEM 字符集一样。

任何运行 Windows NT 4.0、Windows 2000、Windows 95 或 Windows 98 的客户端都被视作 ANSI 客户端。基于控制台的应用程序（如 isql 实用工具）则被视作 OEM 客户端。

包含默认代码页 12xx（如 1252）的服务器被视作 ANSI 服务器，包含任何其它代码页（例如，代码页 850 或 437）的服务器则被视作 OEM 服务器。

虽然 ANSI 和 OEM 都有默认的代码页值，但在转换字符时，由客户端的当前操作系统代码页来确定转换值。


检查保存数据的有效性

可以使用 Transact-SQL 字符串函数 ASCII(char_expr) 显示保存在 Microsoft® SQL Server™ 数据库中的字符。也可以使用 ASCII(column_name) 函数显示数据库中具体某列的 ASCII 值。

另一种显示代码页的方法是将"ANSI 到 OEM 自动转换"选项设为 OFF，并从 SQL 查询分析器查询数据。

例如，假定在使用 OEM 代码页 437 的服务器上保存了字符"?"，如果在"ANSI 到 OEM 自动转换"选项打开的情况下，从 SQL 查询分析器（该分析器使用 ANSI 代码页 1252）中选择了此数据，就会看到"?"字符。OEM 437"?"（它的 ASCII 值是 241）已经转换为 ANSI 1252"?"(ASCII 177)。然而，如果在"ANSI 到 OEM 自动转换"选项关闭的情况下从 SQL 查询分析器中选择此数据，看到的则是"ñ"字符 (ASCII 241)。OEM 437 的 ASCII 值 241 已直接由 ANSI 1252 的 ASCII 值 241 取代。

ANSI 到 OEM 自动转换 | OEM 代码页 437 | ANSI 代码页 1252
ON | ± (ASCII 241) | ± (ASCII 177)
OFF | ± (ASCII 241) | ñ (ASCII 241)


代码页不兼容性

当一个代码页中的某个字符在另一个代码页中不存在而发生转换时，该字符被转换成另一个代码页中与它最接近的字符。例如，代码页 1252 中的 ASCII 156 (œ) 在代码页 437 中转换成 ASCII 111 (o)，因为这是代码页 437 中与其最相似的字符。当将此 ANSI 字符转换回代码页 1252 时，结果是 ASCII 111 (o)，因为两个代码页中都有 ASCII 111 (o)。原来的 1252 字符 (œ) 丢失。这意味着如果一个代码页中的字符在另一个代码页中不存在，并且"ANSI 到 OEM 自动转换"是打开的，则数据库中保存的将是错误的数据。

转换 | ANSI 代码页 1252 | OEM 代码页 437
ANSI 到 OEM | œ (ASCII 156) | 不存在。代以 o (ASCII 111)。
OEM 到 ANSI | o (ASCII 111) | o (ASCII 111)。

在服务器上保存数据时，如果使用的代码页与客户端使用的代码页不同，一定要测试数据的准确性。如果可能，选择可以很容易地在 ANSI 和 OEM 之间转换的字符。


自动化管理任务

自动化管理就是按照计划对可预测的管理职责和服务器事件作出响应。通过使用自动化管理，可以节省时间以执行无法预见或无法编程响应而需要创造力的管理任务。

例如，如果希望在每个工作日结束后，备份公司的所有服务器，那么可以创建一项作业来执行该任务。调度该作业在所需的时间运行。作业遇到问题时，SQL Server 代理程序能够记录该事件并发出寻呼。

如果正在运行 Microsoft® SQL Server™ 的多个实例，请使用多服务器管理来自动执行任务。有关更多信息，请参见多服务器管理。

若要使管理自动化，必须：

  • 确定哪些管理职责或服务器事件定期执行并可以通过编程方式进行管理。

  • 使用 SQL Server 企业管理器、Transact-SQL 脚本或 SQL-DMO 对象来定义一组作业、警报和操作员。有关更多信息，请参见创建作业。

  • 运行 SQL Server 代理服务。
自动化管理组件

作业、操作员和警报是自动化管理的三个主要组件。

作业

作业是由 SQL Server 代理程序执行的一系列指定操作。可以使用作业定义一个能执行一次或多次的管理任务，其每次的执行结果是成功还是失败也可以受到监控。作业：

  • 在一个本地服务器上或多个远程服务器上执行。

  • 按照一个或多个调度执行。

  • 由一个或多个警报触发执行。

有关更多信息，请参见创建作业。

警报

警报信号通知指定的操作员发生了某个事件。例如，事件可以是作业启动或系统资源达到阈值。可以定义警报产生的条件。还可以定义警报采取以下哪一种操作：

  • 通知一个或多个操作员。

  • 将事件转发给其它服务器。

  • 执行作业。

有关更多信息，请参见定义警报。

操作员

操作员是负责维护一台或多台运行 SQL Server 实例的计算机的个人。在有些企业中，操作员由单独一个人担任。在那些拥有很多服务器的大型企业中，操作员由多人一起担任。

采用以下一种或多种方式通知操作员有警报发生：

  • 电子邮件

    可以将操作员的电子邮件别名定义为一组个人的电子邮件别名。通过这种方式，那组的所有成员都能同时收到通知。

  • 寻呼机（通过电子邮件）

  • net send

有关更多信息，请参见定义操作员。


多服务器管理

多服务器管理是在多个 Microsoft® SQL Server™ 实例间使管理自动化的过程。

在下列情况下使用多服务器管理：

  • 管理两个或更多的服务器。

  • 为数据仓库在企业服务器之间调度信息数据流。

进行多服务器管理时，必须有至少一个主服务器和至少一个目标服务器。主服务器向目标服务器分发作业，并从目标服务器接收事件。主服务器存储着主要的作业定义复本，这些作业定义是为在目标服务器上运行的作业设定的。目标服务器周期性地连接到主服务器，以更新它们要执行的作业的列表。如果存在新的作业，目标服务器下载这个作业，然后与主服务器断开连接。目标服务器完成作业后，重新连接到主服务器并报告作业执行情况。

例如，如果管理整个大企业内的部门服务器，可以定义：

  • 一个包含作业步骤的备份作业。

  • 出现故障时通知的操作员。

  • 执行调度。

将该备份作业一次性写入主服务器，然后将部门服务器登记为目标服务器。通过这种方式，尽管只定义了一次备份作业，但所有部门服务器都能够运行同一个备份作业。

多服务器管理功能用于 sysadmin 角色成员。但目标服务器上的 sysadmin 角色成员不能对主服务器在目标服务器上执行的操作进行修改。这项安全措施可防止意外删除作业步骤，并可防止目标服务器上的操作中断。

创建多服务器环境

若要创建多服务器环境，请使用创建主服务器向导。该向导引导您逐个执行以下步骤：

  • 在所有将成为目标服务器的服务器上检查 SQL Server 代理程序服务和 SQL Server 服务的安全设置。

    建议在 Microsoft Windows NT® 或 Windows® 2000 域帐户下运行这两种服务。

  • 在主服务器上创建一个主服务器操作员 (MSXOperator)。

    MSXOperator 是唯一一个能够接收多服务器作业通知的操作员。

  • 在主服务器上启动 SQL Server 代理程序服务。

  • 将一台或多台服务器登记为目标服务器。

如果有大量的目标服务器，建议在非生产服务器上定义主服务器，这样生产将不会因目标服务器的流量而减慢。如果还将事件转发到该服务器，则可以在一台服务器上集中管理。有关更多信息，请参见管理事件。

创建多服务器环境时，需考虑如下事项：

  • 每个目标服务器只向一个主服务器报告。在将目标服务器登记到另一个主服务器上之前，必须使它同现有的主服务器脱离。

  • 主服务器和目标服务器必须在 Windows NT 4.0 或 Windows 2000 操作系统中运行。

  • 更改目标服务器的名称时，必须在更改名称之前与主服务器脱离，并在更改后重新登记。

  • 若要取消多服务器配置，必须使所有目标服务器脱离主服务器。

创建主服务器

企业管理器

企业管理器

Transact-SQL

创建目标服务器

企业管理器

企业管理器

Transact-SQL

SQL-DMO

从主服务器登记目标服务器

企业管理器

企业管理器

Transact-SQL

SQL-DMO

使目标服务器脱离主服务器

企业管理器

企业管理器

Transact-SQL

SQL-DMO

使多台目标服务器脱离主服务器

企业管理器

企业管理器

检查目标服务器的状态

企业管理器

企业管理器

Transact-SQL

SQL-DMO

服务器轮询

轮询间隔的默认值是一分钟，它控制目标服务器下载操作和上载作业执行结果的频率。因此，如果多服务器作业的执行频率比轮询间隔的频率高，那么不是所有的作业执行结果都能上载。这种情况下，必须查看目标服务器上的作业历史记录，以了解所有的作业执行结果。

当目标服务器轮询主服务器时，它从 msdb 数据库的 sysdownloadlist 表中读取分配给目标服务器的操作。这些操作控制多服务器作业和目标服务器行为的不同方面。操作的例子包括删除作业、插入作业、启动作业和更新目标服务器的轮询间隔。

有两种方式可将操作发布到 sysdownloadlist 表中：

  • 显式发布，使用 sp_post_msx_operation。

  • 隐性发布，使用其它作业存储过程。

若使用作业存储过程修改多服务器作业调度或作业步骤，或使用 SQL-DMO 对象控制多服务器作业，在修改完多服务器作业步骤或调度后，运行下列指令以保持目标服务器与当前作业定义同步：

EXECUTE msdb.dbo.sp_post_msx_operation 'INSERT', 'JOB', '<job id>'

在下列情况下，不需要显式发布操作：

  • 使用 SQL Server 企业管理器控制多服务器作业。

  • 使用不修改作业调度或作业步骤的作业存储过程。

请参见

SQL Server 2000 与 SQL Server 7,0 版

ApplyToTargetServerGroup 方法

注册服务器

JobSchedule 对象

JobServer 对象

JobStep 对象

sp_add_targetservergroup

sp_delete_targetserver

sp_delete_targetservergroup

sp_help_downloadlist

sp_help_jobserver

sp_help_targetservergroup

sp_resync_targetserver

sp_update_targetservergroup

sysjobservers

syslogins

systargetservers


配置 SQLServerAgent 服务

SQLServerAgent 是执行作业、监视 Microsoft SQL Server ™ 及激发警报的 Microsoft® Windows NT® 4.0 或 Windows® 2000 服务。SQLServerAgent 是允许您自动执行某些管理任务的服务。所以必须启动 SQLServerAgent 服务，才能使本地或多服务器的管理任务自动运行。Microsoft Windows 98 操作系统也支持 SQL Server 代理程序，但它在 Windows 98 上运行时不能和 Windows 身份认证一起使用。

在安装 SQL Server 时可以为 SQL Server 代理程序指定一些配置选项。完整的配置选项只有通过 SQL Server 企业管理器才能获得。

说明 可以在 SQL Server 企业管理器的控制台树中单击 SQL Server 代理程序，来管理作业、操作员、警报和 SQL Server 代理程序服务。

请参见

安全级别

手工启动 SQL Server


启动 SQLServerAgent 服务

服务启动帐户定义 SQLServerAgent 服务在哪个 Microsoft® Windows NT® 4.0 或 Windows® 2000 帐户下运行。此信息决定了 SQLServerAgent 服务的网络权限。可以使用的选项有：

  • 系统帐户

    系统帐户是内置的本地系统管理员帐户。该帐户是本地计算机上的"管理员"组成员，因此也是 Microsoft SQL Server™ 中的 sysadmin 角色成员。

    如果作业仅需要使用本地系统上的资源，请单击"系统帐户"。

  • 本帐户

    "本帐户"可以指定 SQLServerAgent 在哪个 Windows NT 4.0 或 Windows 2000 域帐户下运行。指定的域帐户必须是在运行 SQL Server 实例的本地服务器上的 sysadmin 角色成员。

    在下列情况下选择"本帐户"：

    • 希望将事件转发到其它运行 Windows NT 4.0 或 Windows 2000 操作系统的计算机的应用程序日志中。

    • 作业需要通过网络获得资源，包括复制资源。

    • 希望通过电子邮件或寻呼机通知操作员。

      说明 如果 Microsoft Exchange 或 Microsoft Outlook® 客户端被配置为将邮件发送到有密码保护的个人文件夹中，SQL Server 代理程序将无法启动其邮件会话。为避免这种情况发生，请从 .pst 文件中删除密码保护。

如果在 Windows NT 4.0 或 Windows 2000 域帐户以外的帐户下运行 SQLServerAgent，则将发生以下情况：

  • 非系统管理员拥有的作业的 CmdExec 和 ActiveScripting 步骤会失败。

  • SQLServerAgent 的自动重启功能将不起作用。

  • 空闲时作业调度不允许作业运行。

为获得最佳结果，请使用 Windows NT 4.0 或 Windows 2000 域帐户，该帐户在整个域中具有足够权限可对执行 SQL Server 代理程序作业所需的信息进行访问。可将 SQLServerAgent 服务帐户更改为非 Windows NT 4.0 管理员帐户。但是，Windows NT 4.0 帐户必须是 sysadmin 固定服务器角色的成员以运行 SQL Server 代理程序。

设置 SQL Server 代理程序的服务启动帐户：

企业管理器

企业管理器

说明 如果是在 Windows NT 4.0 或 Windows 2000 上运行 SQL Server 代理程序，可以使用 SQL Server 服务管理器指定在操作系统启动时自动启动 SQL Server 代理程序。但该选项在 Windows 98 操作系统上不可用。

设置 SQL Server 代理程序的邮件配置文件

企业管理器

企业管理器

请参见

设置 Windows 服务帐户


连接 SQL Server

有两种方法可以定义 SQL Server 代理程序服务如何与本地 Microsoft® SQL Server™ 实例连接。不管选择哪种方法，所使用的帐户在 SQL Server 中必须具有系统管理员的权限。

  • 使用 Windows 身份验证

    这种方法强制 SQL Server 代理程序服务使用被定义为服务启动帐户的 Microsoft Windows NT® 4.0 或 Windows® 2000 域帐户与 SQL Server 实例连接。

  • 使用 SQL Server 身份验证

    这种方法强制 SQL Server 代理服务使用 SQL Server 授权登录与 SQL Server 实例连接。仅有 sysadmin 角色成员可以这样登录。

    如果不是在运行 Windows NT 4.0 或 Windows 2000 操作系统的服务器上运行 SQLServerAgent，请选择"使用 SQL Server 身份验证"。

这两个选项都可以设置登录的时间限制。如果 SQLServerAgent 服务连接到本地 SQL Server 实例所需的时间比指定的时间长，登录会话将超时。可以在 5 秒到 45 秒的范围内指定登录超时时间。

设置 SQL Server 连接

企业管理器


指定 SQL Server 别名

默认情况下，SQL Server 代理程序通过命名管道使用动态服务器名称连接到 Microsoft® SQL Server™ 实例，不需要额外的客户端配置。

只有在下列情况下才必须指定服务器连接别名：

  • 使用非默认的网络传输连接到 SQL Server 实例。

  • 连接到监听可选命名管道的 SQL Server 实例。

设置 SQL Server 别名

企业管理器


使用 SQL Server 代理程序错误日志

SQL Server 代理程序默认情况下创建一个错误日志来记录警告和错误。SQL Server 代理程序错误日志中显示下列三种类型的消息：

  • 警告消息，提供有关潜在问题的信息，例如"作业测试在执行时被删除"。

  • 错误信息，通常是那些需要系统管理员干预才能解决的问题，例如"无法启动邮件会话"。错误信息可以通过网络弹出式消息发送给特定的人或者计算机。

SQL Server 最多可以包含九个 SQL Server 代理程序错误日志。每个存档的错误日志都有一个扩展名，表示该错误日志的新旧程度。例如，扩展名 .1 表示最新的存档错误日志，而一个扩展名 .9 表示最旧的存档错误日志。

默认情况下，执行跟踪消息不写入 SQL Server 代理程序错误日志，因为它很快就会将日志填满，从而影响您选择和分析更严重的错误。由于 SQL Server 代理程序错误日志会给服务器带来额外的负担，应考虑是否值得将执行跟踪消息捕获到错误日志中。通常情况下，最好只在对某个特定的问题进行调试时才捕获所有消息。

当 SQL Server 代理程序停止运行时，就可以修改错误日志的保存位置。当 Microsoft® SQL Server™ 错误日志为空时，将无法查看该日志。

查看 SQL Server 代理程序错误日志

企业管理器

企业管理器

查看主 SQL Server 代理程序错误日志

企业管理器

企业管理器

重命名 SQL Server 代理程序错误日志

企业管理器

企业管理器

发送 SQL Server 代理程序错误信息

企业管理器

企业管理器

将执行跟踪消息写入 SQL Server 代理程序错误日志

企业管理器

企业管理器

请参见

监视环境

监视错误日志


执行作业

利用 SQL Server 代理程序作业，可以使管理任务自动执行和定期运行。可以手工执行一个作业，也可以对其进行调度，使之响应调度表或警报而运行。

下图显示当 SQL Server 代理程序运行一个作业时，作业执行和作业步骤处理的情况。

可以编写作业使其在 Microsoft® SQL Server™ 的本地实例上运行或在多服务器上运行。要在多个服务器上运行作业，必须设置至少一个主服务器以及一个或更多的目标服务器。

任何人都可以创建作业，但作业只能被它的所有者或者 sysadmin 角色的成员编辑。


创建作业

作业是由 SQL Server 代理程序按顺序执行的一系列指定的操作。作业可以执行更广泛的活动，包括运行 Transact-SQL 脚本、命令行应用程序和 Microsoft® ActiveX® 脚本。可以创建作业来执行经常重复和可调度的任务，并且作业可产生警报以通知用户作业的状态。

创建作业

企业管理器

企业管理器

Transact-SQL

SQL-DMO

将作业所有权给予其他人

企业管理器

企业管理器

Transact-SQL

SQL-DMO

组织作业

Microsoft SQL Server™ 2000 提供作业分类，可帮助您组织作业以便轻松筛选和组合。例如，可以将所有数据库备份作业组织到"数据库维护"分类中。此外，还可以创建自己的作业类别。

多服务器分类只在主服务器上存在。只有一个仅在主服务器上可获得的默认作业类别。[未分类（多服务器）]。当一个多服务器作业被下载后，它在目标服务器上的分类就变为"来自 MSX 的作业"。

创建作业分类

企业管理器

企业管理器

Transact-SQL

SQL-DMO

删除作业分类

企业管理器

企业管理器

Transact-SQL

SQL-DMO

将作业指派给作业分类

企业管理器

企业管理器

Transact-SQL

SQL-DMO

更改作业分类的成员资格

企业管理器

企业管理器

Transact-SQL

SQL-DMO

列出分类信息

Transact-SQL

SQL-DMO

更改作业所有权

为安全起见，只有作业所有者或 sysadmin 成员角色才能更改现有作业的定义、启动或停止作业，或者给予其他用户作业的所有权。

然而，如果创建一个需要驱动器号或通用命名规范 (UNC) 路径名的作业，则在测试过程时，可在 Microsoft Windows NT® 4.0 或 Windows® 2000 用户帐户下运行该作业。当 SQL Server 代理程序随后运行该作业时，可能没有执行该作业所需的权限、驱动器号配置或对所需驱动器的访问权。有关更多信息，请参见安全管理。

请参见

创建作业步骤

多服务器管理

调度作业

运行作业

修改和查看作业


创建作业步骤

作业步骤是作业对一个数据库或者一个服务器执行的动作。每个作业必须至少有一个作业步骤。作业步骤可以是操作系统命令、Transact-SQL 语句、Microsoft ® ActiveX® 脚本或复制任务。

CmdExec 作业步骤

CmdExec 作业步骤是操作系统命令或者以 .bat、.cmd、.com 或 .exe 结尾的可执行程序。

当创建 CmdExec 作业步骤时，必须指定：

  • 命令成功完成时返回的进程退出代码。

  • CmdExec 命令，例如：
    C:\Program Files\Microsoft SQL Server\MSSQL\Binn\Osql.exe\E\QServer\80\Tools\Binn\Osql.exe\E\Q "sp_who"。

  • 指向所有可执行文件的完整路径。

创建 CmdExec 作业步骤

企业管理器

企业管理器

Transact-SQL

SQL-DMO

重置 SQLAgentCmdExec 权限

企业管理器

企业管理器

Transact-SQL 作业步骤

当创建 Transact-SQL 作业步骤时，必须：

  • 说明要执行该作业的数据库。

  • 编写 Transact-SQL 语句、存储过程或扩展存储过程。

或者可以将现有的 Transact-SQL 文件作为作业步骤的命令打开。

sysadmin 角色成员可以编写在其他数据库用户的环境中运行的作业步骤。例如，系统管理员可以运行一个作业，代表数据库的其他用户在 pubs 数据库中创建数据库对象。

说明 一个 Transact-SQL 作业步骤能够包含多个批处理。Transact-SQL 作业步骤可以像 osql.exe 一样包含内嵌的 GO 命令。

创建 Transact-SQL 作业步骤

企业管理器

企业管理器

Transact-SQL

SQL-DMO

定义 Transact-SQL 作业步骤选项

企业管理器

企业管理器

SQL-DMO

ActiveX 脚本作业步骤

当创建 ActiveX 脚本作业步骤时，必须：

  • 说明作业步骤所使用的脚本语言。

  • 编写 ActiveX 脚本。

也可以将现有的 ActiveX 脚本文件作为作业步骤的命令打开。ActiveX 脚本命令也可以在外部编译好（例如使用 Visual Basic®），然后作为 CmdExec 可执行文件运行。

当作业步骤命令是 ActiveX 脚本时，可以使用 SQLActiveScriptHost 对象将作业输出打印到步骤历史记录或创建 COM 对象。SQLActiveScriptHost 是一个全局对象，由 SQL Server 代理程序的宿主系统引入脚本命名空间。对象有两种方法（PrintObject 和 CreateObject）。下列示例说明 ActiveX 脚本如何在 Microsoft Visual Basic Scripting Edition (VBScript) 和 PerlScript 中工作。

Rem VBScript job step example:
Sub main()
    Set DMOServer = CreateObject("SQLDMO.SQLServer")
    DMOServer.LoginSecure = True
    DMOServer.Connect "myserver"
    Print DMOServer.Name
    DMOServer.Disconnect
    Set DMOServer = Nothing
End Sub

#PerlScript job step example:
Sub main()
{
$DMOServer = $SQLActiveScriptHost->CreateObject("SQLDMO.SQLServer");
    $DMOServer->Connect("myserver", "sa");
    $SQLActiveScriptHost->Print($DMOServer->Name);
    $DMOServer->Disconnect();
    $DMOServer = undef;
}

创建 ActiveX 脚本作业步骤

企业管理器

企业管理器

Transact-SQL

SQL-DMO

复制作业步骤

当使用复制来创建发布时，可以自动创建复制作业。复制的类型（快照、事务或合并）和选项决定创建的作业类型。

复制作业步骤执行下列复制代理程序之一：

  • 分发代理程序（分发作业）

  • 日志读取器代理程序（日志读取器作业）

  • 合并代理程序（合并作业）

  • 队列读取器代理程序（队列读取器作业）

  • 快照代理程序（快照作业）

建立起复制之后，复制代理程序可在 SQL Server 代理程序启动后连续运行、根据需要运行或者根据调度运行。

说明 建议使用复制监视器控制复制作业步骤。


处理多个作业步骤

若作业有一个以上的作业步骤时，必须在作业步骤中加入执行顺序。我们称之为流控制。可以在任何时候加入新的作业步骤并重新安排作业步骤流。这些更改在下一次作业运行时生效。下图展示了一个数据库备份作业的流控制。

为每个作业步骤的成功和失败都定义一个流控制动作。必须指定当作业步骤成功或者作业步骤失败时所执行的动作。也可以定义对失败的作业步骤进行重试的次数和每次重试之间的时间间隔。

作业步骤必须是原子性的。作业不能在作业步骤之间传递布尔值、数据或者数值。可以使用永久表或全局临时表将数值从一个 Transact-SQL 作业步骤传递给另一个。可以使用文件将值从一个 CmdExec 作业步骤传递给另一个。

说明 如果创建循环作业步骤（作业步骤一后面跟着作业步骤二，然后作业步骤二又返回到作业步骤一），在使用 SQL Server 企业管理器创建这个作业的时候就会产生一条警告消息。

SQL Server 代理程序在作业历史记录中记录作业和作业步骤的执行信息。

设置作业步骤的成功流或失败流

企业管理器

企业管理器

Transact-SQL

SQL-DMO

设置作业历史记录日志

企业管理器

企业管理器

查看作业历史记录

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

如何监视复制代理程序性能（企业管理器）

sp_add_job

sysjobhistory

sysjobs

sysjobsteps


调度作业

调度管理作业是实现管理任务自动化的一种方式。可以调度本地作业或多服务器作业。可以定义作业在下列情况下运行：

  • 每当 SQL Server 代理程序启动时。

  • 每当计算机的 CPU 使用率处于定义为空闲状态的水平时。

  • 在特定日期和时间运行一次。

  • 按循环调度运行。

  • 响应警报。

也可以手工执行一个作业；调度作业是可选的。

说明 一次只能运行一个作业实例。若在一个作业按调度执行时手工执行它，则 SQL Server 代理程序会拒绝这个请求。

默认情况下，所有作业都是启用的。为防止作业按照它的调度执行，必须禁用这个调度。此时这个作业仍然可以响应警报执行，或通过用户手工执行。

SQL Server 代理程序自动禁用不再是当前的调度。若在调度被 SQL Server 代理程序禁用后对其进行编辑，则必须显式地重新启用它。在下列情况下，调度被禁用：

  • 调度被定义为在某个特定日期和时间运行一次，而该时间已过。

  • 调度被定义为循环调度运行，而结束时间已过。
CPU 空闲调度

为最大限度地利用 CPU 资源，可以为 SQL Server 代理程序定义一个 CPU 空闲状态。SQL Server 代理程序利用 CPU 空闲状态设置来决定执行作业的最佳时间。

例如，可将每日备份作业调度到 CPU 空闲时及低业务量时进行。

在把作业定义为在 CPU 空闲时执行之前，应确定作业所需的 CPU 工作量。可以使用 SQL 事件探查器或系统监视器（Windows NT 4.0 中的性能监视器）监视服务器流通并收集统计信息。可利用收集到的信息设置 CPU 空闲时间百分比。

将 CPU 空闲状态定义为一个百分比，在该百分比以下，CPU 平均使用率必须保持指定的时间长度。下一步，设置这段时间长度。在超过该时间长度后，SQL Server 代理程序启动所有有 CPU 空闲时间调度的作业。

调度作业

企业管理器

企业管理器

Transact-SQL

SQL-DMO

禁用作业

企业管理器

企业管理器

Transact-SQL

SQL-DMO

设置 CPU 空闲时间和持续时间

企业管理器

企业管理器

请参见

sp_help_jobschedule

sysjobschedules


指定作业响应

可以指定在作业完成之后产生作业响应。典型的作业响应包括：

  • 使用电子邮件、电子呼叫或 net send 消息通知操作员。

    若操作员必须执行重复的操作，应使用这些作业响应中的一种。例如，当一个备份作业成功地完成之后，必须通知操作员取出备份磁带并将其存放在安全处。

  • 将事件消息写入 Microsoft® Windows® 应用程序日志。

    可以只对失败的作业发生这种响应。

  • 自动删除作业。

    若确信不需要再次运行该作业，可以使用这种响应。

通知操作员作业的状态

企业管理器

企业管理器

Transact-SQL

SQL-DMO

将作业状态写入 Windows 应用程序日志

企业管理器

企业管理器

Transact-SQL

SQL-DMO

自动删除作业

企业管理器

企业管理器

Transact-SQL

SQL-DMO

设置目标服务器的轮询间隔

企业管理器

企业管理器

Transact-SQL

SQL-DMO


运行作业

可能需要经常（但不是定期）执行一个作业。在这种情况下，可以编写一次作业，然后在需要的时候手工执行它。也可以手工执行那些已被分配了调度的作业。例如，尽管已经将一个 master 数据库的备份作业安排在晚上执行，但您想在更改系统表之后马上备份一次数据库。

如果一个作业已经根据调度开始执行，则在所调度的作业完成之前，无法在同一个服务器上执行该作业的另一个实例。在多服务器的环境中，每个目标服务器都能够同时运行同一个作业的一个实例。

如果不想运行某个作业，可以禁用它。也可以在作业执行过程中停止它。大多数情况下，当发出停止命令时，当前的作业步骤就会被取消，所有的重试逻辑都会被忽略。有些作业步骤，例如一些长时间运行的 Transact-SQL 语句（BACKUP）或一些 DBCC 命令，可能不会对停止请求很快做出响应。当停止一个作业时，会在作业历史记录里记录一个作业已取消的条目。

多服务器作业处理

一个多服务器作业可以在一个或更多的目标服务器上运行。每个目标服务器周期性地与主服务器连接，下载指派给目标服务器的任何新作业的实际复本，然后与主服务器断开连接。目标服务器在本地保存作业的一个完整复本，然后再与主服务器建立连接，上载作业的结果状态。

说明 如果在目标服务器试图上载作业状态时主服务器无法访问，则作业被置于假脱机状态，直到主服务器再次可以访问。

启动作业

企业管理器

企业管理器

Transact-SQL

SQL-DMO

停止作业

企业管理器

企业管理器

Transact-SQL

SQL-DMO

强制目标服务器轮询主服务器

企业管理器

企业管理器

设置目标服务器的轮询间隔

企业管理器

企业管理器

Transact-SQL

请参见

sysdownloadlist


修改和查看作业

创建完一个作业后，可以查看作业的定义。执行完一个作业后，可以查看它的历史记录。如果作业要求发生改变，可以修改作业使其按其它方式执行。

说明 作业必须至少运行一次，才会有作业历史记录。可以限制作业历史记录总的大小，和其中每个作业的大小。

可以修改：

  • 响应选项。

  • 调度。

  • 作业步骤。

  • 所有权。

  • 作业分类。

  • 目标服务器（仅适用于多服务器作业）

若在 SQL Server 企业管理器外对多服务器作业定义进行了更改，必须将更改发布到下载列表中，以便目标服务器可以再次下载更新后的作业。为确保目标服务器具有最新的作业定义，更新完多服务器作业后，请发布一条 INSERT 指令。

EXECUTE sp_post_msx_operation 'INSERT', 'JOB', '<job id>'

必须手工通知目标服务器：使用下列任一过程修改完多服务器作业的调度和步骤后，已使用上述命令修改了该作业：

  • sp_add_jobstep

  • sp_update_jobstep

  • sp_delete_jobstep

  • sp_add_jobschedule

  • sp_update_jobschedule

  • sp_delete_jobschedule

    说明 调用 sp_update_job 或 sp_delete_job 后不需要调用 sp_post_msx_operation，因为这些存储过程会自动向下载列表发布所需的更改。

查看作业

企业管理器

企业管理器

Transact-SQL

SQL-DMO

查看作业历史记录

企业管理器

企业管理器

Transact-SQL

SQL-DMO

检查目标服务器的状态

企业管理器

企业管理器

Transact-SQL

SQL-DMO

调整作业历史记录日志的大小

企业管理器

企业管理器

清除作业历史记录日志

企业管理器

企业管理器

Transact-SQL

SQL-DMO

修改作业

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

修改作业的目标服务器

企业管理器

企业管理器

Transact-SQL

SQL-DMO

修改目标服务器的位置

企业管理器

企业管理器

Transact-SQL

SQL-DMO

删除作业

企业管理器

企业管理器

Transact-SQL

SQL-DMO

同步目标服务器的时钟

企业管理器

企业管理器

Transact-SQL

强制目标服务器轮询主服务器

企业管理器

企业管理器

Transact-SQL

请参见

sp_delete_jobserver

sp_update_job

sysjobhistory


使用 Transact-SQL 编写作业脚本

可以生成 Transact-SQL 脚本以创建所定义的作业。通过编写作业脚本，可以：

  • 控制作业创建源代码的版本。

  • 从测试向生产迁移作业。

  • 编写警报和操作员的脚本。

在运行 Microsoft® SQL Server™ 2000 实例的计算机上创建的脚本在运行 SQL Server 7.0 版的计算机上也可以运行。如果选择创建与 SQL Server 7.0 兼容的脚本，将忽略某些 SQL Server 2000 的功能，比如：

  • 列级排序规则。

  • 用户定义的函数、扩展属性。

  • 表和视图上的 INSTEAD OF 触发器。

  • 视图上的索引（索引视图）。

  • 计算列上的索引。

  • 降序索引。

  • 视图上的引用权限。

    此选项仅在运行 SQL Server 2000 实例的计算机上可以使用。

使用 Transact-SQL 编写作业脚本

企业管理器

企业管理器

创建 SQL Server 7.0 兼容脚本

企业管理器


响应事件

Microsoft® SQL Server™ 事件写入 Microsoft Windows® 应用程序日志。可以定义对一个或更多的事件的警报，以指定 SQL Server 代理程序应该如何响应。

SQL Server 代理程序监视 Windows 应用程序日志中的 SQL Server 事件。当定义为需要采取行动的事件发生时，SQL Server 代理程序自动根据说明作出响应。例如，当一个严重度为 17 的事件发生时，可以指定立即通知操作者。

自动的事件响应称为"报警"。当发生一个事件时，SQL Server 代理程序将事件的详细信息与 SQL Server 管理员所定义的警报做比较。如果SQL Server 代理程序发现两者相符，就执行所定义的响应。

可以定义警报以：

  • 通知操作员。

  • 执行作业。

  • 将事件转发到其它服务器上的 Windows 应用程序日志。


定义操作员

操作员的主要属性是姓名和联系信息。建议在定义警报之前定义操作员。必须设置以下一种或多种方式以便通知操作员：

  • 发送电子邮件需要遵从 MAPI-1 的电子邮件客户程序。

    SQL Server 代理程序需要一个有效的邮件配置文件才能发送电子邮件。MAPI-1 客户程序的例子包括 Microsoft® Outlook® 和 Microsoft Exchange 客户程序。

  • 寻呼机，第三方的寻呼机到电子邮件的软件和/或硬件。

    需要具备这些条件才能使用寻呼机通知功能。

  • 若要使用 net send 通知，必须运行 Microsoft Windows NT® 4.0 或 Windows® 2000 操作系统。
命名操作员

每个操作员必须有一个名字。操作员的名字必须是唯一的，并且长度不得超过 128 个字符。

提供联系信息

操作员的联系信息决定了如何通知这个操作员。可以使用电子邮件、寻呼机或者 net send 通知操作员：

  • 电子邮件通知

    SQL Server 代理程序使用由"SQL 代理程序属性"对话框提供的邮件配置信息来建立自己的邮件会话。

  • 寻呼机通知

    呼叫是通过电子邮件实现的。为设置寻呼机通知，必须在邮件服务器上安装相应的软件，处理入站邮件并将其转换为寻呼机信息。该软件可以采用下列几种方法中的一种：

    • 将邮件转发到寻呼服务提供商站点的远程邮件服务器上。

      寻呼服务提供商必须提供这项服务，尽管所需的软件通常是作为本地邮件系统的一部分提供的。有关更多信息，请参见寻呼机文档。

    • 通过 Internet 将邮件传送到寻呼服务提供商的邮件服务器。

      这是第一种方法的变种。

    • 处理入站邮件并用附加的调制解调器拨号。

      该软件为寻呼服务提供商所有。它很像一个邮件客户程序，周期性地处理收件箱里的邮件，把电子邮件的全部或部分地址信息解释为寻呼机的号码，或通过转换表将电子邮件名称与寻呼机号码匹配。

如果所有操作员使用同一个寻呼服务提供商的服务，可以使用 SQL Server 企业管理器指定寻呼机到电子邮件系统需要的任何特殊电子邮件格式。这个特殊格式可以是前缀或者后缀：

  • 主题行

  • 抄送行

  • 收件人

    说明 若使用的是一个小容量的字母数字呼叫系统（例如，每页限制在 64 个字符内），可以通过从寻呼机通知中剔除错误信息文本，缩短发送文本的长度。

  • net send

    net send 通知方法指定网络消息的接收者（计算机或用户）。Windows 98 操作系统不支持该方法。

指派防故障操作员

当给所有指定的操作员发送寻呼机通知都失败后，将通知防故障操作员。例如，如果设置了三个接收寻呼机通知的操作员，但所有指定的操作员都无法呼叫，此时就通知防故障操作员。

在下列情况下将通知防故障操作员：

  • 无法呼叫负责处理警报的操作员。

    这种情况的原因包括寻呼机地址错误和操作员已经下班。

  • SQL Server 代理程序无法访问 msdb 数据库中的系统表。

    sysnotifications 系统表指定负责处理警报的操作员。

因为防故障操作员是一种安全功能，因而在没有将防故障职责重新指派给另一个操作员或没有删除防故障指派的情况下，不能删除已给其指派了防故障职责的操作员。

创建操作员

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

将警报指派给操作员

企业管理器

企业管理器

Transact-SQL

SQL-DMO

设置呼叫程序地址的格式

企业管理器

企业管理器

SQL-DMO

指派防故障操作员

企业管理器

企业管理器

SQL-DMO

请参见

AddNotification 方法

AlertSystem 对象

Operator 对象

sp_add_alert

sp_add_operator

sp_help_notification

sp_help_operator


修改和查看操作员

由于操作员的职责和作业调度不断变化，可能需要经常更新操作员信息。在操作员创建之后，可以：

  • 查看操作员的信息。

    可以查看该操作员负责的警报。可以查看 SQL Server 代理程序最近几次试图通知操作员的日期。

  • 编辑操作员信息。

    可以编辑通知地址、可用的寻呼机调度表、已指派的警报以及通知方法。

  • 更改操作员的可用性。

    默认情况下，操作员一旦创建就能够接收通知（启用）。可以在创建操作员时或在这之后的任何时候将操作员指定为不能接收通知（禁用）。

    例如，当一个被指定为操作员的人去休假时，可以禁用这个操作员。指派给该操作员的警报和这些警报的通知方式都没有改变；只是操作员不能对警报作出响应。当这个人休假回来之后，您不需要重新定义操作员，而只需重新启用这个操作员。

  • 删除操作员。

    当某人不再具有操作员职责时，可以删除这个操作员。当删除操作员时，也同时删除了这个操作员的所有警报通知。若操作员被指定为防故障操作员，则不能删除。在删除一个操作员之前，必须首先解除该操作员的防故障职责，或将防故障职责指派给另一个操作员。

查看操作员信息

企业管理器

企业管理器

Transact-SQL

SQL-DMO

编辑操作员

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

更改操作员的可用性

企业管理器

企业管理器

Transact-SQL

SQL-DMO

删除操作员

企业管理器

企业管理器

Transact-SQL

SQL-DMO


向操作员报警

可以选择发生警报时要通知的操作员。可以使用寻呼机指定操作员轮流接收通知。例如，当一个或多个定义的警报发生在星期一、星期三或星期五时，通知小莉。如果是发生在星期二、星期四或星期六的警报就通知小王。如果小莉或小王不能在各自负责的日子里被通知到，或者警报发生在星期日，就通知防故障操作员。

可以使用下列一种或多种方法通知操作员：

  • 电子邮件

  • 呼叫程序

  • net send

SQLServerAgent 服务使用 SQL Server 代理程序活动专用的邮件会话。如果对 MSSQLServer 服务使用 SQL 邮件会话，建议让 SQL Server 代理程序和 Microsoft® SQL Server™ 使用相同的 Microsoft Windows NT® 4.0 或 Windows® 2000 域用户帐户。这样可以让这两个邮件会话使用相同的邮件配置文件。如果 SQL Server 代理程序和 SQL Server 使用单独的域用户帐户，必须为每个服务配置邮件配置文件。

定义对警报的响应

企业管理器

企业管理器

Transact-SQL

SQL-DMO

设置 SQL Server 代理程序的邮件配置文件

企业管理器

企业管理器

请参见

配置邮件配置文件


定义警报

错误及消息或者事件由 Microsoft® SQL Server™ 产生并记入 Microsoft Windows® 应用程序日志。SQL Server 代理程序读取该应用程序日志，将事件同定义的警报比较。当 SQL Server 代理程序发现与之匹配时，它就会发出警报。

默认情况下，下列 SQL Server 事件记入 Windows 应用程序日志：

  • 严重度为 19 或更高的 sysmessages 错误。

    若要记录严重度低于 19 的错误信息，可以用 sp_altermessage 将某些特定的 sysmessages 错误指定为"始终记录"。

  • 所有使用 WITH LOG 语法唤醒调用的 RAISERROR 语句。

    建议使用 RAISERROR WITH LOG 从 SQL Server 实例写入 Windows 应用程序日志。

  • 所有使用 xp_logevent 记录的应用程序。

    说明 确保 Windows 应用程序日志足够大以免丢失 SQL Server 事件信息。

必须先定义警报，才能发出通知。警报的主要属性包括名称和事件或性能条件的说明。

命名警报

每个警报都必须有一个名称。警报名必须唯一，并且不能超过 128 个字符。

选择事件

可以指定一个警报响应一个或几个事件。可按照下列条件指定一组触发一个警报的事件：

  • 错误号。

    SQL Server 代理程序在发生特定的错误时发出警报。

  • 严重级别。

    SQL Server 代理程序在发生特定严重度的错误时发出警报。

  • 数据库。

    若要对警报进行限制，可以指定事件所发生的数据库。

  • 事件文本。

    若要对警报进行限制，在事件消息中指定一个文本字符串。

选择性能状况

可以指定一种要监视的性能状况，当达到性能阈值时即发出警报。若要设置性能状况，必须对以下几项进行定义：

  • 对象。

    要监视的 SQL Server 性能范围。

  • 计数器。

    所监视部分的属性。性能数据被周期性地采样，这会在达到阈值与发出性能警报之间造成短暂的延迟（几秒钟）。

  • 实例。

    所监控的属性的特定实例（如果有的话）。

  • 计数器/值的警报条件。

    导致激发警报的计数器的行为或计数器实例的行为。

创建用户定义的事件消息

如果有特殊的事件跟踪需要，而 SQL Server 事件消息未予满足，可以创建用户定义的事件消息。用户定义的事件消息产生大于 50.000 的错误号。另外，还可以定义它们的严重度。

用户定义的事件消息必须唯一，并且有唯一的错误号。它们中的每一个都可以有唯一的语言。

说明 在使用 SQL Server 企业管理器时，应该选择"写入 Windows NT 应用程序事件日志"的选项。默认情况下，严重度低于 19 的用户定义消息不发送到 Windows应用程序日志，因此不会触发 SQL Server 代理程序警报。

如果管理多语种 SQL Server 环境，应用所支持的每种语言创建用户定义消息。例如，如果创建一个新事件消息，既用于英语服务器也用于德语服务器，则在两个服务器上应使用相同的事件号，但为每个服务器指定一种不同的语言。

使用错误号创建警报

企业管理器

企业管理器

Transact-SQL

SQL-DMO

使用严重级别创建警报

企业管理器

企业管理器

Transact-SQL

SQL-DMO

定义对警报的响应

企业管理器

企业管理器

Transact-SQL

SQL-DMO

创建用户定义的事件错误信息

企业管理器

企业管理器

Transact-SQL

编辑用户定义的事件错误信息

企业管理器

企业管理器

Transact-SQL

删除用户定义的事件错误信息

企业管理器

企业管理器

Transact-SQL

禁用或重新激活警报

企业管理器

企业管理器

Transact-SQL

SQL-DMO

请参见

xp_logevent


修改和查看警报

创建警报后，可以：

  • 查看警报信息。

    可以查看一个警报的特征，该警报最新发生及其响应的日期，以及自计数器重置以来该警报发生的次数。

  • 修改警报的信息。

    例如，可以添加新操作员，重置警报发生的次数，禁用警报，或更改数据库。

  • 删除警报。

    可以删除不再需要的警报。在删除警报时，同时也将删除该警报的所有操作员通知。

查看有关警报的信息

企业管理器

企业管理器

Transact-SQL

SQL-DMO

编辑警报

企业管理器

企业管理器

Transact-SQL

SQL-DMO

删除警报

企业管理器

企业管理器

Transact-SQL

SQL-DMO


将操作员或警报复制到其它服务器

可以生成一个 Transact-SQL 脚本，以创建一个或全部所定义的操作员或警报。如果同一组操作员都负责对其它服务器上的同一个警报作出响应，可以自动为所有预定义的操作员和警报编写脚本，然后再复制到这些服务器上，以节省时间。

使用 Transact-SQL 编写操作员脚本

企业管理器

企业管理器

使用 Transact-SQL 编写警报脚本

企业管理器


管理事件

可以将达到或超过某个特定错误严重级别的所有 Microsoft® SQL Server™ 事件消息转发到一个 SQL Server 实例。转发服务器是一个专用服务器，同时也可以是一个主服务器。可以利用事件转发对一组服务器进行集中警报管理。这样可以减少负担繁重的服务器的工作量。

在多服务器的环境下，建议将主服务器指定为警报管理服务器。

优点

设置警报管理服务器的优点包括：

  • 集中管理。

    可以从单个服务器对多个 SQL Server 实例的事件进行集中控制，并获得这些事件的合并视图。

  • 可伸缩性。

    许多物理服务器可以作为一个逻辑服务器来管理。可以根据需要在这个物理服务器组中添加或删除服务器。

  • 高效。

    由于只需要在一个服务器上一次性定义警报和操作员，所以减少了配置工作所需的时间。

缺点

设置警报管理服务器的缺点包括：

  • 数据流量增加。

    向警报管理服务器转发事件增加了网络的数据流量，尽管这可以通过将转发的事件限制为指定严重度级别以上的事件得到缓解。

  • 单个故障点。

  • 服务器负荷。

    处理转发事件的警报导致警报转发服务器处理负荷增加。

指导方针

在配置事件转发时，应遵从这些指导方针：

  • 避免在警报转发服务器上运行关键的或负荷沉重的应用程序。

  • 避免将同一个转发服务器配置给过多的服务器使用。如果发生阻塞，减少警报管理服务器管理的服务器的数目。

    已经在 SQL Server 企业管理器中注册的服务器组成一个列表，作为候选的警报转发服务器。

  • 定义警报，要求在 SQL Server 的本地实例上作出服务器特有的响应而不是转发警报。

    警报转发服务器将所有向它转发的服务器当作一个逻辑整体看待。例如，一个警报转发服务器用同一方式响应发自服务器 A 和服务器 B 的 605 事件。

  • 配置了报警系统后，定期检查 Microsoft Windows® 应用程序日志中的 SQL Server 代理程序事件。

    警报引擎将所遇到的失败情况写入带有 SQL Server 代理程序源名称的本地 Windows 应用程序日志中。例如，如果 SQL Server 代理程序无法按照定义发出电子邮件，应用程序日志将会记录一个事件。

如果一个本地定义的警报被禁用后，发生本来会触发该警报的事件，则事件被转发给警报转发服务器（如果它满足警报转发的条件）。这允许本地站点上的用户按照需要关闭和打开本地替代警报（即同时也在警报转发服务器上定义的本地定义的警报）。也可以要求事件转发总是处于打开状态，即使它们由本地警报处理。

指派事件转发服务器

企业管理器

企业管理器

SQL-DMO

定义对警报的响应

企业管理器

企业管理器

Transact-SQL

SQL-DMO

运行事件触发作业

可以定义一个作业，使之在响应一个警报时执行。例如，可以执行一个作业，对警报查出的问题进行改正或做进一步的诊断。

说明 如果一个作业可以造成一个事件，应注意防止创建递归的警报作业循环。

请参见

sysmessages


监视环境

SQL Server 代理程序监视自身和 Microsoft® SQL Server™ 服务。

自我监视

SQL Server 代理程序启动 xp_sqlagent_monitor 扩展存储过程（SQL Server 代理监视器）监视 SQLServerAgent 服务，以确保该服务可以用于执行所调度的作业、激发警报以及通知操作员。如果 SQLServerAgent 服务意外终止，SQL Server 代理监视器将重新启动该服务。

重新启动 SQL Server 服务

如果运行本地实例的 SQL Server 非正常终止，SQL Server 代理程序可以重新启动 SQL Server 的本地实例。自动重启在默认情况下是启用的。SQL Server 代理程序检测到非正常终止时，将重新启动 SQL Server 实例。这使得可以对此事件设置一个警报。

说明 如果使用 SQL Server 2000 故障转移群集，则必须禁用自动重新启动以使故障转移发挥作用。

设置作业执行关闭

企业管理器

企业管理器

自动启动 SQL Server 代理程序监视器

企业管理器

企业管理器

SQL-DMO

发送 SQL Server 代理程序错误信息

企业管理器

企业管理器

查看 SQL Server 代理程序错误日志

企业管理器

企业管理器

重命名 SQL Server 代理程序错误日志

企业管理器

企业管理器

查看主 SQL Server 代理程序错误日志

企业管理器

企业管理器

请参见

StopMonitor 方法


安全管理

数据库必须具有坚固的安全系统，才能控制可以执行的活动以及可以查看和修改的信息。无论用户如何获得对数据库的访问权限，坚固的安全系统都可确保对数据进行保护。

本节描述 Microsoft® SQL Server™ 2000 内置的安全工具，并包含下列信息：

  • 安全构架

  • 计划安全性

  • 创建安全帐户

  • 管理安全帐户

  • 管理权限

  • 高级安全主题

  • 审核 SQL Server 活动


安全构架

安全系统的构架建立在用户和用户组的基础上。下图说明 Microsoft® Windows NT® 4.0 和 Windows® 2000 中的用户和本地组及全局组可以如何映射到 Microsoft SQL Server™ 中的安全帐户，以及 SQL Server 可以如何独立于 Windows NT 4.0 和 Windows 2000 中的帐户来处理安全帐户。

CORPUSERS 本地组中含有两个用户和一个全局组 Mktg，这个全局组中又含有两个用户。SQL Server 允许直接使用 Windows NT 4.0 和 Windows 2000 本地组和全局组来组织 SQL Server 的用户帐户。此外，Windows NT 4.0 用户 Fred 和 Jerry 虽不属于 Windows NT 4.0 组，但可以作为 Windows NT 4.0 用户（如 Fred）或作为 SQL Server 用户 (Jerry) 直接添加到 SQL Server 实例中。

通过使用角色，SQL Server 进一步扩展了上面的模型。角色是为了进行管理而组织的用户组，与 Windows NT 4.0 或 Windows 2000 组相同，但是当等价的 Windows NT 4.0 或 Windows 2000 组不存在时，将在 SQL Server 中创建这些角色。例如，Managers 角色中包含 Windows NT 4.0 Mktg 全局组，以及 Windows NT 4.0 用户 Frank 和 Fred。

此外，SQL Server 还通过使用单个数据库应用程序角色在应用程序级别提供安全。

有关更多信息，请参见 Windows NT 4.0 或 Windows 2000 文档。

请参见

创建安全帐户


计划安全性

安全计划标识哪些用户可以在数据库中查看哪些数据以及执行哪些活动。对于制定安全计划：

  1. 列出数据库中所有必须通过安全控制的项目和活动。

  2. 标识公司中的个人和组。

  3. 交叉引用两个列表以标识哪些用户可以在数据库中查看哪些数据集以及执行哪些活动。

请参见

单个人员安全性示例

小型公司安全性示例

公司环境安全性示例


单个人员安全性示例

在可能的最简单的安全系统中，单个人员负责数据库各方面的事务并且是数据库的唯一用户。这个假想的用户（伦敦的 Tom Brown）必须能够：

  • 创建数据库及其表。

  • 编写数据接口程序。

  • 装载和维护数据。

  • 生成报表。

本示例的用户活动映射列出了单个用户及其需要执行的活动。

用户帐户 | 活动
LONDON\tombrown | 访问全部数据库

创建安全系统的第一步是添加 Microsoft® SQL Server™ 登录 LONDON\tombrown，以使该用户可以访问 SQL Server。预定义的 sysadmin 角色含有该用户所需的全部权限，因此，LONDON\tombrown SQL Server 登录应添加为 sysadmin 角色成员。当 LONDON\tombrown 连接到 SQL Server 实例时，SQL Server 回叫 Microsoft Windows NT® 4.0 或 Windows® 2000 以验证连接。如果此连接经验证后被接受，则允许该用户基于与 sysadmin 角色相关联的权限执行活动。

如果 Tom Brown 没有 Windows NT 4.0 或 Windows 2000 登录，那么他可能有 SQL Server 登录。在这种情况下，需要在"混合模式"下运行 SQL Server 实例，以使用户得以在 Windows NT 4.0、Windows 2000 或 SQL Server 登录下登录。可以将名为 tombro 的登录添加到 SQL Server，该登录独立于 Windows NT 4.0 或 Windows 2000 登录，然后可以将 tombro 添加到 sysadmin 角色。当该用户登录到 Windows NT 4.0 或 Windows 2000 并尝试与 SQL Server 实例连接时，必须指定 SQL Server 知道的 tombro 登录名和密码。


小型公司安全性示例

在复杂程度适中的安全系统中，多个人员在数据库中执行各种任务。例如，数据库管理员负责管理数据库环境，包括：创建数据库、表和安全帐户，进行备份，以及优化数据库。两个开发人员负责编写提供数据接口的客户端应用程序。经理根据数据库准备信息报表，因此需要具有对所有可用数据的访问权限。管理人员输入客户和销售数据，因此必须能够查看所有数据。

本示例的用户到活动映射要比单个用户数据库的略微复杂一些。

用户帐户 | 活动
LONDON\joetuck | 访问全部数据库。
LONDON\marysmith、LONDON\billb | 完全访问数据并且能够创建过程。
LONDON\managers | 完全访问全部数据。
LONDON\admins | 完全访问客户数据和销售信息。对所有其它数据进行只读访问。

安装本示例安全性的第一步是添加 LONDON\joetuck 的登录权限。于是，因为 LONDON\joetuck 登录要求完全的访问权限，所以下一步是将该用户添加到 sysadmin 角色中。

也应为开发人员添加登录权限。这样做的一种方法是授予个别开发人员（LONDON\marysmith 和 LONDON\billb）访问数据的权限。但是，如果另一个开发人员（或另外 10 个开发人员）加入到这个项目中，则必须分别为每个新人员添加权限，这是十分耗时的任务。更好的解决方案是添加名为 Developers 的 SQL Server 数据库角色，并给该角色授予访问数据和创建过程的权限。当 LONDON\marysmith、LONDON\billb 或其他新开发人员的帐户添加到 Developers 角色中时，他们的用户帐户将获得授予该角色的权限。

角色只适用于数据库级别。也就是说，角色解决控制数据库用户访问的问题。不必给 10 个开发人员分别授予数据库访问权限，而是可以创建一个角色，将 10 个开发人员添加到该角色，然后给该角色授予数据库访问权限。

最后，必须向 SQL Server 中添加 LONDON\managers 和 LONDON\admins 的登录权限。经理在连接时被识别为现有 Microsoft Windows NT® 4.0 和 Windows® 2000 组的成员，可以基于授予该组的权限来执行活动。对于 LONDON\admins 也如此。


公司环境安全性示例

在大型公司安全系统中，由执行特定的排它任务的用户构成了复杂的网络。

每个人负责数据库应用程序的各个方面。少数几个人负责数据库和表的创建，但禁止他们看到其合作者的相关敏感人事信息（有时甚至包括他们自己）。有一个夜间值班小组对数据进行备份，但这些工作人员并不需要看到数据，也不需要创建表和数据库。人事部门必须有访问一般职员信息的权限，并且人事部门中少数几个挑选出的个人是公司中唯一对保密和敏感职员信息有访问权限的人。另外还有客户服务职员，他们需要应客户的请求查看产品说明，但不做更改。

本示例的用户到活动映射相当复杂。

用户帐户 | 活动
LONDON\annej | 访问全部数据库
LONDON\dbadmins | 创建数据库
LONDON\dboperations | 进行夜间备份
LONDON\personnel | 对一般职员数据有完全访问权
LONDON\mikebo、LONDON\marym、LONDON\billsm | 对保密数据有完全访问权限
LONDON\custservice | 对产品信息有只读访问权限

必须授予 LONDON\annej 用户帐户登录到 Microsoft® SQL Server™ 的权限并将该用户添加到 sysadmin 角色，因为 sysadmin 角色具有对整个服务器的完整权限。必须将 LONDON\dbadmins Microsoft Windows NT® 4.0 和 Windows® 2000 组用户帐户添加到 SQL Server 中，并授予其创建数据库的权限。另外还应添加 LONDON\operations Windows NT 4.0 组，并只授予其 BACKUP DATABASE 权限以允许他们执行备份。

应添加 LONDON\personnel Windows NT 4.0 和 Windows 2000 组，并授予其只能查看 employees 表中非敏感列的权限，以及查看其它表的权限。

用户 LONDON\mikebo、LONDON\marym 和 LONDON\billsm 都是 LONDON\personnel Windows NT 4.0 组的成员，所以他们已有做大部分工作所需的权限。但是，他们还需要对敏感职员信息列的特殊访问权限。若要满足这种需求，可以在 SQL Server 中创建称为 PersonnelSecure 的数据库角色，并授予其查看敏感职员信息所需的权限。单个用户在添加到该角色后就获得在 SQL Server 中的特殊权限。或者，直接向其用户帐户添加特殊权限。

最后一步是在 SQL Server 中添加 LONDON\custservice Windows NT 4.0 组的帐户，并授予其查看产品信息的权限。


安全级别

在 Microsoft® SQL Server™ 中工作时，用户要经过两个安全性阶段：身份验证和授权（权限验证）。授权阶段使用登录帐户标识用户并只验证用户连接 SQL Server 实例的能力。如果身份验证成功，用户即可连接到 SQL Server 实例。然后用户需要访问服务器上数据库的权限，为此需授予每个数据库中映射到用户登录的帐户访问权限。权限验证阶段控制用户在 SQL Server 数据库中所允许进行的活动。


身份验证模式

Microsoft® SQL Server™ 可以在两种安全（身份验证）模式之一下工作：

  • Windows 身份验证模式（Windows 身份验证）

    Windows 身份验证模式使用户得以通过 Microsoft Windows NT® 4.0 或 Windows® 2000 用户帐户进行连接。

  • 混合模式（Windows 身份验证和 SQL Server 身份验证）

    混合模式使用户得以使用 Windows 身份验证或 SQL Server 身份验证与 SQL Server 实例连接。在 Windows 身份验证模式或混合模式下，通过 Windows NT 4.0 或 Windows 2000 用户帐户连接的用户可以使用信任连接。

    提供 SQL Server 身份验证是为了向后兼容。例如，如果创建单个 Windows 2000 组并向该组添加所需的所有用户，则需要授予 Windows 2000 组登录到 SQL Server 的权限以及对任何必需数据库的访问权限。

Windows 身份验证

当用户通过 Windows NT 4.0 或 Windows 2000 用户帐户进行连接时，SQL Server 通过回叫 Windows NT 4.0 或 Windows 2000 以获得信息，重新验证帐户名和密码。

SQL Server 通过使用网络用户的安全特性控制登录访问，以实现与 Windows NT 4.0 或 Windows 2000 的登录安全集成。用户的网络安全特性在网络登录时建立，并通过 Windows 域控制器进行验证。当网络用户尝试连接时，SQL Server 使用基于 Windows 的功能确定经过验证的网络用户名。SQL Server 于是验证此人是否是如其所说的那个人，然后只基于网络用户名允许或拒绝登录访问，而不要求单独的登录名和密码。

登录安全集成在 SQL Server 中任何受支持的网络协议上运行。

说明 如果用户试图通过提供空白登录名称连接到 SQL Server 的实例，SQL Server 将使用 Windows 身份验证。此外，如果用户试图使用特定的登录连接到配置为 Windows 身份验证模式的 SQL Server 实例，则将忽略该登录并使用 Windows 身份验证。

与 SQL Server 身份验证相比，Windows 身份验证有某些优点，主要是由于它与 Windows NT 4.0 和 Windows 2000 安全系统的集成。Windows NT 4.0 和 Windows 2000 安全系统提供更多的功能，如安全验证和密码加密、审核、密码过期、最短密码长度，以及在多次登录请求无效后锁定帐户。

由于 Windows NT 4.0 和 Windows 2000 用户和组只由 Windows NT 4.0 或 Windows 2000 维护，因此当用户进行连接时，SQL Server 将读取有关该用户在组中的成员资格信息。如果对已连接用户的可访问权限进行更改，则当用户下次连接到 SQL Server 实例或登录到 Windows NT 4.0 或 Windows 2000 时（取决于更改的类型），这些更改会生效。

说明 当 SQL Server 实例在 Windows 98 或 Microsoft Windows Millennium 版上运行时，Windows 身份验证模式不可用。

SQL Server 身份验证

当用户用指定的登录名称和密码从非信任连接进行连接时，SQL Server 通过检查是否已设置 SQL Server 登录帐户，以及指定的密码是否与以前记录的密码匹配，自己进行身份验证。如果 SQL Server 未设置登录帐户，则身份验证将失败，而且用户收到错误信息。

提供 SQL Server 身份验证是为了向后兼容性，因为为 SQL Server 7.0 版或更早的版本编写的应用程序可能要求使用 SQL Server 登录和密码。另外，当 SQL Server 实例在 Windows 98 上运行时，必须使用 SQL Server 身份验证，因为在 Windows 98 上不支持 Windows 身份验证模式。因此，SQL Server 在 Windows 98 上运行时使用混合模式（但只支持 SQL Server 身份验证）。

应用程序开发人员和数据库用户也许更喜欢 SQL Server 身份验证，因为他们熟悉登录和密码功能。对于连接到 Windows NT 4.0 和 Windows 2000 客户端以外的其它客户端，可能也必须使用 SQL Server 身份验证。

说明 当使用命名管道连接到在 Windows NT 4.0 或 Windows 2000 上运行的 SQL Server 实例时，用户必须有连接到 Windows NT 命名管道 IPC \\<computername>\IPC$ 的权限。如果用户没有连接权限，则不能使用命名管道连接到 SQL Server 实例，除非计算机上的 Windows NT 4.0 或 Windows 2000 guest 帐户已启用（默认情况下禁用），或者给用户帐户授予"从网络访问该计算机"的权限。

设置 Windows 身份验证模式安全性

企业管理器

企业管理器

SQL-DMO

设置混合模式安全性

企业管理器

企业管理器

SQL-DMO

请参见

向后兼容性


安全帐户委托

安全帐户委托是指连接到多个服务器的能力，以及随着每个服务器更改，保留原始客户端的身份验证凭据的能力。例如，如果用户 (LONDON\joetuck) 连接到 ServerA，而 ServerA 又连接到 ServerB，则 ServerB 知道连接安全标识是 LONDON\joetuck。

若要使用委托，将要连接的所有服务器都必须运行 Microsoft® Windows® 2000，启用 Kerberos 支持，并且必须使用 Microsoft Active Directory™（Windows 2000 的目录服务）。必须如下指定 Active Directory 中的下列选项，委托才能正常工作：

  • 一定不要为请求委托的用户选择"帐户是敏感帐户，不能被委托"复选框。

  • 必须为 SQL Server 的服务帐户选择"帐户可以信任，可用来委托"复选框。

  • 必须为运行 Microsoft SQL Server™ 实例的服务器选择"计算机可以信任，可用来委托"复选框。

若要使用安全帐户委托，SQL Server 必须有：

  • Windows 2000 帐户域管理员指派的服务准则名 (SPN)。

    必须在特定的计算机上将 SPN 指派给 SQL Server 服务的服务帐户。委托强制相互间的身份验证。SPN 证实 Windows 2000 帐户域管理员以特定的套接字地址在特定的服务器上验证了 SQL Server。可以使域管理员通过 Windows 2000 资源工具包使用 setspn 实用工具为 SQL Server 建立 SPN。

    若要为 SQL Server 创建 SPN，请在命令提示符下输入下列代码：

    setspn -A MSSQLSvc/Host:port serviceaccount

    例如：

    setspn -A MSSQLSvc/server1.redmond.microsoft.com sqlaccount

    有关 setspn 实用工具的更多信息，请参见 Windows 2000 文档。

在启用委托之前，请考虑下列事项：

  • 必须使用 TCP/IP。不能使用命名管道，因为 SPN 将特定的 TCP/IP 套接字作为目标。如果使用多个端口，必须在每个端口上都有一个 SPN。

  • 还可以通过在 LocalSystem 帐户下运行来启用委托。SQL Server 将在服务启动时自行注册并自动注册 SPN。该选项比使用域用户帐户启用委托容易。但是，当 SQL Server 关闭时，将取消为 LocalSystem 帐户注册的 SPN。

    说明 如果更改 SQL Server 的服务帐户，则需要删除任何以前的 SPN 并创建新的 SPN。

将 SPN 添加到 SQL Server

若要使用服务帐户 MYDOMAIN\sqlsvc 在名为"myserver.microsoft.com"的 SQL Server 实例上，为监听端口 1433 的实例添加 SPN，请在命令提示符下运行下列代码：

setspn -A MSSQLSvc/myserver.microsoft.com:1433 sqlsvc

不能使用 Netbios 名称。必须使用完全合法的 DSN 名称。不能指定服务帐户的域限定符。必须只使用帐户名。

若要更改和使用 LocalSystem 帐户，请在命令提示符下输入下列代码以删除先前注册的 SPN：

setspn -D MSSQLSvc/myserver.microsoft.com:1433 sqlsvc

有关安全帐户委托的更多信息，请参见 Windows 2000 文档。


权限验证

当验证了用户的身份并允许其登录到 Microsoft® SQL Server™ 实例之后，在用户必须访问的每个数据库中都要求单独的用户帐户。在每个数据库中都要求用户帐户可防止用户连接到 SQL Server 实例并访问服务器上的所有数据库。例如，如果一个服务器上含有 personnel 数据库和 recruiting 数据库，可以访问 recruiting 数据库但不能访问 personnel 数据库的用户将只有在 recruiting 数据库中创建的用户帐户。

每个数据库中的用户帐户都用于为该数据库中的对象（表、视图和存储过程等）应用安全权限。可从 Microsoft Windows NT® 4.0 和 Windows® 2000 用户帐户、用户所属的 Windows NT 4.0 和 Windows 2000 组或者 SQL Server 登录帐户映射该用户帐户。如果没有直接映射的帐户，就可以允许用户以 guest 帐户在数据库中工作，前提是该帐户存在。用户所准予的活动由获得数据库访问权限时所使用用户帐户的权限控制。

用户获得对数据库的访问权限后，SQL Server 即接受命令。用户在数据库中所进行的所有活动都通过 Transact-SQL 语句传到 SQL Server 中。当 SQL Server 实例接收到 Transact-SQL 语句时，将确定用户是否有在数据库中执行该语句的权限。如果用户没有执行语句的权限，或者没有访问该语句所使用对象的权限，则 SQL Server 将返回权限错误。


层次安全性

Microsoft SQL Server™ 中的安全环境通过用户的层次结构系统进行存储、管理和强制执行。为简化对很多用户的管理，SQL Server 使用组和角色：

  • 组是 Microsoft Windows NT® 4.0 和 Windows® 2000 内的管理单元，其中包含 Windows NT 4.0 和 Windows 2000 用户或其它组。

  • 角色是 SQL Server 内的管理单元，其中包含 SQL Server 登录、Windows NT 4.0 和 Windows 2000 登录、组或其它角色。

将用户分成组或角色可以更方便地同时对许多用户授予或拒绝权限。对组定义的安全设置适用于该组中的所有成员。当某个组是更高级别组中的成员时，除为该组自身或用户帐户定义的安全设置外，该组中的所有成员还将继承更高级别组的安全设置。

安全系统的结构化图表通常与公司的结构化图表一致。

这两个结构化图表在很大程度上是一致的，但是对于公司结构化层次结构，有一个不适用于该安全模型的共同规则：只向一个经理报告个别图表。这条规则意味着一个职员只能在层次结构模型的一个分支中，如关系图中所示。

数据库安全系统要求超过了这种一个管理人员的限制；职员属于安全组，该组不在公司的严格组织计划范围内。例如，管理人员在公司的每个分支中，并且无论组织分支如何，都要求安全性权限。为支持这种更广泛的模型，Windows NT 4.0、Windows 2000 和 SQL Server 中的安全系统允许在整个层次结构内定义组。所创建的 Administrative 组可以含有从 Corporate 组到 Payroll 组、公司每个分支的管理人员。

这种安全性组的层次结构系统简化了安全设置的管理。它允许安全设置集体应用到所有组成员，而不必对每个人重复定义。另外，层次结构模型还包含只应用到单个用户的安全设置。


创建安全帐户

每个用户必须通过登录帐户建立自己的连接能力（身份验证），以获得对 Microsoft® SQL Server™ 实例的访问权限。然后，该登录必须映射到用于控制在数据库中所执行的活动（权限验证）的 SQL Server 用户帐户。因此，单个登录映射到在该登录正在访问的每个数据库中创建的一个用户帐户。如果数据库中没有用户帐户，则即使用户能够连接到 SQL Server 实例，也无法访问该数据库。

登录创建在 Microsoft Windows NT® 4.0 或 Windows® 2000 中，而非 SQL Server 中。该登录随后被授予连接到 SQL Server 实例的权限。该登录在 SQL Server 内被授予访问权限。


安全规则

Microsoft® SQL Server™ 登录、用户、角色和密码可以包含 1 到 128 个字符，包括字母、符号和数字（例如，Andrew-Fuller、Margaret Peacock 或 13&#57abc）。因此，Microsoft Windows NT® 4.0、Windows 2000® 或 Microsoft Windows 98 用户名可以用作 SQL Server 登录。

但是，因为在 Transact-SQL 语句中经常使用登录、用户名、角色和密码，所以必须用双引号 (") 或方括号 ([ ]) 分隔某些符号。当 SQL Server 登录、用户、角色或密码为以下情况时，请在 Transact-SQL 语句中使用分隔符：

  • 含有空白字符或以空白字符开头。

  • 以字符 $ 或 @ 开头。

    说明 在将登录、用户、角色或密码输入 SQL Server 图形客户端工具（如 SQL Server 企业管理器）的文本框时，不必指定分隔符。

此外，SQL Server 登录、用户或角色不能：

  • 包含反斜线 (\) 字符，除非是引用现有的 Windows NT 4.0 或 Windows 2000 用户或组。反斜线将 Windows NT 4.0 或 Windows 2000 计算机名或域名与用户名分开。

  • 已存在于当前数据库中（或者仅就登录而言，不能存在于 master 中）。

  • 为 NULL 或空字符串 ("")。

请参见

分隔标识符


添加 Windows 用户或组

在 Microsoft® Windows NT® 4.0 和 Windows 2000 帐户（用户或组）可以访问数据库之前，必须给其授予连接到 Microsoft SQL Server™ 实例的权限。如果 Windows NT 4.0 或 Windows 2000 组的所有成员都将与 SQL Server 实例连接，则可以将组作为一个整体来授予权限。管理组的权限比管理个别用户的权限容易得多。如果不能给该组集体授予权限，则可以分别给每个 Windows NT 4.0 或 Windows 2000 用户授予连接到 SQL Server 实例的权限。

用户

当授予 Windows NT 4.0 或 Windows 2000 用户连接到 SQL Server 实例的权限时，请指定用户所属的 Windows NT 4.0 或 Windows 2000 域名或计算机名，然后依次输入反斜线和用户名。例如，若要给 Windows NT 4.0 或 Windows 2000 用户 Andrew 授予访问权限，请在 Windows NT 4.0 或 Windows 2000 域 LONDON 中，将 LONDON\Andrew 指定为用户名。

本地组和全局组

有多种类型的 Windows NT 4.0 和 Windows 2000 组，包括全局组和本地组：

  • 全局组包含来自 Windows NT 4.0 或 Windows 2000 域中的用户帐户，全局组就创建在该域中。全局组不能包含来自其它域的其它组或用户，并且不能在运行 Microsoft Windows NT 4.0 Workstation 或 Windows 2000 Professional 的计算机上创建。

  • 本地组中可以含有来自域的用户帐户和全局组，该域必须是创建本地组的域或任何信任域。本地组中不能含有其它本地组。

另外，Windows NT 4.0 和 Windows 2000 包含预定义的内置本地组，如 Administrators、Users 和 Guests。

当授予 Windows NT 4.0 或 Windows 2000 本地组或全局组连接到 SQL Server 实例的权限时，请指定在其上定义该组的域名或计算机名，然后依次输入反斜线和组名。例如，若要给 SQL_Users 全局组授予访问权限，请在 LONDON 域中指定 LONDON\SQL_Users 作为组名。

若要授予访问 Windows NT 4.0 或 Windows 2000 内置本地组的权限，请指定 BUILTIN 代替域名或计算机名。但是，若要给内置 Windows NT 4.0 和 Windows 2000 本地组 Administrators 授予访问权限，请指定 BUILTIN\Administrators 作为组名。

有关这些帐户的更多信息，请参见 Windows NT 4.0 和 Windows 2000 文档。

授予 Windows 用户或组登录访问 SQL Server 的权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO


授权 Windows NT 的用户或组访问数据库

管理 SQL Server

授予 Windows 用户或组访问数据库的权限

若要获得对 Microsoft® SQL Server™ 数据库的访问权限，Microsoft Windows NT® 4.0 和 Windows® 2000 用户或组在需要访问的每个数据库中，必须有相应的用户帐户。此外，必须对该用户帐户应用权限。

虽有可能，但是如果 Windows NT 4.0 和 Windows 2000 组中的所有成员都执行相同的活动，则不必在数据库中分别为组中的每个 Windows NT 4.0 和 Windows 2000 用户添加用户帐户。可以为组而不是为每个成员添加帐户。当组成员需要在数据库中工作时，是通过他们在 Windows NT 4.0 和 Windows 2000 组中的成员资格对其授权的；组中没有用于个别用户的特定帐户。例如，Windows NT 4.0 和 Windows 2000 组 London\Managers 包含 Windows NT 4.0 和 Windows 2000 用户 London\JoeB。SQL Server 系统管理员只向 London\Managers 授予登录访问权限。数据库 Accounts 的所有者只对 London\Managers 授予访问 Accounts 的权限。虽然没有对 London\JoeB 显式授予连接到 SQL Server 实例或访问 Accounts 的权限，但由于其在 London\Managers 中的成员资格，他可以连接到 SQL Server 实例并访问 Accounts。

只有当个别 Windows NT 4.0 和 Windows 2000 用户执行与任何 Windows NT 4.0 或 Windows 2000 组中其他成员不同的活动时（例如特殊的数据库管理任务），才需要将该用户添加到数据库中。

说明 那些通过自身在 Windows NT 4.0 或 Windows 2000 组中的成员资格获准访问 SQL Server 实例的用户，在系统表中没有针对他们个人 Windows NT 4.0 或 Windows 2000 用户帐户的项。但是，如果他们在 SQL Server 数据库中创建对象（如表或存储过程），则会针对他们的个人NT 用户帐户而创建一项。

授予 Windows 用户或组访问数据库的权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO


添加 SQL Server 登录

在下列情况下，通过指定的登录名和密码而不是 Microsoft Windows NT® 4.0 或 Windows® 2000 用户或组帐户来添加允许连接的 Microsoft® SQL Server™ 登录帐户：

  • 将 SQL Server 配置为在混合模式下运行。

  • SQL Server 实例正在 Microsoft Windows 98 上运行。

对于下列情况必须添加 SQL Server 登录：

  • 为与包含从其它数据库供应商导入的数据的应用程序兼容。

  • 为没有 Windows NT 4.0 或 Windows 2000 帐户的一般用户而设计的应用程序。

  • 连接到在 Windows 98 上运行的 SQL Server 实例，因为 Windows 身份验证在 Windows 98 上不可用。

添加 SQL Server 登录

Transact-SQL

企业管理器

企业管理器

SQL-DMO


系统管理员 (sa) 登录

系统管理员 (sa) 是为向后兼容而提供的特殊登录。默认情况下，它指派给固定服务器角色 sysadmin，并不能进行更改。虽然 sa 是内置的管理员登录，但不应例行公事地使用它。相反，应使系统管理员成为 sysadmin 固定服务器角色的成员，并让他们使用自己的登录来登录。只有当没有其它方法登录到 Microsoft® SQL Server™ 实例（例如，当其它系统管理员不可用或忘记了密码）时才使用 sa。

说明 在安装 SQL Server 时，如果请求混合模式身份验证，则 SQL Server 安装程序将提示更改 sa 登录密码。建议立即指派密码以防未经授权地使用 sa 登录访问 SQL Server 实例。

请参见

指派 sa 密码


授权 SQL Server 登录访问数据库

对于每个要求访问数据库的 SQL Server 登录，将其 Microsoft® SQL Server™ 用户帐户添加到每个数据库。如果用户未在数据库中创建，则 SQL Server 登录就无法访问数据库。

若要授权某个 SQL Server 登录访问数据库的权限，则该 SQL Server 登录必须已经存在。而且，必须逐个授权 SQL Server 登录访问数据库。

授权 SQL Server 登录访问数据库

Transact-SQL

企业管理器

企业管理器

SQL-DMO


数据库所有者 (dbo)

dbo 是具有在数据库中执行所有活动的暗示性权限的用户。将固定服务器角色 sysadmin 的任何成员都映射到每个数据库内称为 dbo 的一个特殊用户上。另外，由固定服务器角色 sysadmin 的任何成员创建的任何对象都自动属于 dbo。

例如，如果用户 Andrew 是固定服务器角色 sysadmin 的成员，并创建表 T1，则表 T1 属于 dbo，并以 dbo.T1 而不是 Andrew.T1 进行限定。相反，如果 Andrew 不是固定服务器角色 sysadmin 的成员，而只是固定数据库角色 db_owner 的成员，并创建表 T1，则 T1 属于 Andrew，并限定为 Andrew.T1。该表属于 Andrew，因为该成员没有将表限定为 dbo.T1。

无法删除 dbo 用户，且此用户始终出现在每个数据库中。

只有由 sysadmin 固定服务器角色成员（或 dbo 用户）创建的对象才属于 dbo。由任何其他也不是 syadmin 固定服务器角色成员的用户（包括 db_owner 固定数据库角色成员）创建的对象：

  • 属于创建该对象的用户，而不是 dbo。

  • 用创建该对象的用户名限定。

请参见

分隔标识符

sp_changedbowner


数据库对象所有者

创建数据库对象（表、索引、视图、触发器、函数或存储过程）的用户称为数据库对象所有者。创建数据库对象的权限必须由数据库所有者或系统管理员授予。但是，在授予数据库对象这些权限后，数据库对象所有者就可以创建对象并授予其他用户使用该对象的权限。

数据库对象所有者没有特殊的登录 ID 或密码。对象创建者被隐性授予数据库的所有权限，但其他用户必须被显式授予权限后才能访问该对象。

引用数据库对象

当用户访问另一个用户所创建的对象时，应使用对象所有者的名称对该对象进行限定；否则，Microsoft® SQL Server™ 可能不知道使用哪个对象，因为不同的用户可能拥有许多同名的对象。如果引用对象时不是用对象所有者进行限定，例如使用 my_table 而不是 owner.my_table，则 SQL Server 将按下列顺序在数据库中查找对象：

  1. 为当前用户所拥有。

  2. 为 dbo 所拥有。

如果找不到对象，就会返回错误信息。

例如，用户 John 是固定数据库角色 db_owner 的成员，但不是固定服务器角色 sysadmin 的成员，他创建表 T1。除 John 外的所有想访问 T1 的用户必须用用户名 John 限定 T1。如果未用用户名 John 限定 T1，则 SQL Server 将首先查找由当前用户所拥有的、名为 T1 的表，然后查找由 dbo 所拥有的同名表。如果当前用户和 dbo 不拥有名为 T1 的表，就会返回错误信息。如果当前用户或 dbo 拥有另一个名为 T1的表，则使用该 T1 表而不是 John.T1。

如果必须从数据库中删除数据库对象所有者，则必须首先除去其所拥有的对象，或者必须将其所有权转让给另一个用户。

说明 SQL Server 允许将角色或 Microsoft Windows NT® 4.0 或 Windows® 2000 组指定为对象所有者。例如，若要创建由 Windows NT 4.0 或 Windows 2000 组 LONDON\Users 所拥有的表 group_table，请将 [LONDON\Users].group_table 指定为合法表名。LONDON\Users 组中的所有成员都有 group_table 上的数据库对象所有者权限。

请参见

分隔标识符

sp_changeobjectowner


guest 用户

guest 用户帐户允许没有用户帐户的登录访问数据库。当满足下列所有条件时，登录采用 guest 用户的标识：

  • 登录有访问 Microsoft® SQL Server™ 实例的权限，但没有通过自己的用户帐户访问数据库的权限。

  • 数据库中含有 guest 用户帐户。

可以将权限应用到 guest 用户，就如同它是任何其它用户帐户一样。可以在除 master 和 tempdb 外（在这两个数据库中它必须始终存在）的所有数据库中添加或删除 guest 用户。默认情况下，新建的数据库中没有 guest 用户帐户。

例如，若要将 guest 用户帐户添加到名为 Accounts 的数据库中，请在 SQL 查询分析器中运行下列代码：

USE Accounts
GO
EXECUTE sp_grantdbaccess guest

授权 SQL Server 登录访问数据库

Transact-SQL

企业管理器

企业管理器

SQL-DMO


创建用户定义的 SQL Server 数据库角色

管理 SQL Server

创建用户定义 SQL Server 数据库角色

当一组用户需要在 SQL Server 中执行一组指定的活动且满足下列条件之一时，创建 Microsoft® SQL Server™ 数据库角色：

  • 没有适用的 Microsoft Windows NT® 4.0 或 Windows® 2000 组。

  • 没有管理 Windows NT 4.0 或 Windows 2000 用户帐户的权限。

说明 请避免角色的深层嵌套以免影响性能。

例如，一个公司可能成立慈善活动委员会，其中包括来自不同部门，来自组织中各种不同级别的职员。这些职员需要访问数据库中特殊的项目表。没有只包括这些职员的现有 Windows NT 4.0 或 Windows 2000 组，而且没有其它理由在 Windows NT 4.0 或 Windows 2000 中创建这样一个组。可以为此项目创建一个自定义 SQL Server 数据库角色 CharityEvent，并将个别的 Windows NT 和 Windows 2000 用户添加到此数据库角色。当应用权限后，数据库角色中的用户便获得对表的访问权限。其它数据库活动的权限不受影响，只有 CharityEvent 用户可以使用该项目表。

SQL Server 角色存在于一个数据库中，不能跨多个数据库。

使用数据库角色的好处包括：

  • 对于任何用户，都可以随时让多个数据库角色处于活动状态。

  • 如果所有用户、组和角色都在当前数据库中，则 SQL Server 角色可以包含 Windows NT 4.0 或 Windows 2000 组和用户，以及 SQL Server 用户和其它角色。

  • 在同一数据库中，一个用户可属于多个角色。

  • 提供了可伸缩模型以便在数据库中设置正确的安全级别。

说明 数据库角色要么在创建角色时由明确指定为所有者的用户所拥有，要么在未指定所有者时为创建角色的用户所拥有。角色的所有者决定可以在角色中添加或删除谁。但是，因为角色不是数据库对象，不能在同一数据库中创建由不同用户所拥有的多个同名角色。

创建 SQL Server 数据库角色

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

SQL Server 向后兼容性详细信息


将成员添加到 SQL Server 数据库角色

当在 Microsoft® SQL Server™ 中添加新用户帐户，或者更改现有用户的权限时，可以向 SQL Server 数据库角色添加此用户，而不要直接将权限应用到帐户上。对于用户数目众多或安全系统复杂的数据库，角色可以简化其安全管理。

SQL Server 用户、Microsoft Windows NT® 4.0 或 Windows® 2000 用户和组以及其它 SQL Server 数据库角色都可以添加为角色成员。因为角色仅限于在单个数据库中使用，而且不能从一个数据库添加到另一个，所以可以添加只能被那个数据库识别的用户、组和角色。

说明 当将在数据库内没有用户帐户的 Windows NT 4.0 或 Windows 2000 登录添加到 SQL Server 数据库角色时，SQL Server 自动在数据库内创建用户帐户，即使 Windows NT 4.0 或 Windows 2000 登录原本无法访问该数据库。

用户帐户可以是同一数据库中任意多个角色的成员，并且可以持有每个角色的适当权限。例如，一个 SQL Server 用户在同一数据库中可以既是 admin 角色的成员，又是 users 角色的成员，并且每个角色有不同的权限。授予多个角色成员的对象权限是这些角色的累计权限。但是，一个角色中的拒绝权限优先于在另一个角色中授予的同一权限。例如，admin 角色可能授权访问某个表，但是 users 角色拒绝对该表的访问。属于两个角色的成员将被拒绝访问该表，因为被拒绝的访问权限更具限制性并具有优先权。

要添加到用户定义数据库角色中的用户，必须已经具有访问含有用户定义角色的数据库的权限。

将成员添加到 SQL Server 数据库角色

Transact-SQL

企业管理器

企业管理器

SQL-DMO


将成员添加到预定义角色中

Microsoft® SQL Server™ 中的安全机制包括几个具有暗示性权限的预定义角色，这些暗示性权限不能授予其它用户帐户。如果有用户需要这些权限，则必须将其帐户添加到这些预定义角色。两类预定义角色为固定服务器角色和固定数据库角色。

固定服务器角色

无法创建的固定服务器角色在服务器级别上定义，并存在于各数据库的外部。若要将用户添加到固定服务器角色，用户必须具有 SQL Server 或 Microsoft Windows NT® 4.0 或 Windows® 2000 登录帐户。固定服务器角色的任何成员都可以添加其它登录。

重要 身为 BUILTIN\Administrators 组成员的 Windows NT 4.0 或 Windows 2000 用户自动成为 sysadmin 固定服务器角色成员。

下表描述固定服务器角色。

固定服务器角色 | 描述
sysadmin | 在 SQL Server 中进行任何活动。该角色的权限跨越所有其它固定服务器角色。
serveradmin | 配置服务器范围的设置。
setupadmin | 添加和删除链接服务器，并执行某些系统存储过程（如 sp_serveroption）。
securityadmin | 管理服务器登录。
processadmin | 管理在 SQL Server 实例中运行的进程。
dbcreator | 创建和改变数据库。
diskadmin | 管理磁盘文件。
bulkadmin | 执行 BULK INSERT 语句。

对 sysadmin 角色成员以外的所有用户，securityadmin 具有执行 sp_password 存储过程的权限。

bulkadmin 固定服务器角色具有执行 BULK INSERT 语句的权限。与所有指定固定服务器角色成员一样，bulkadmin 角色成员也可以将其它登录添加到角色。但是，由于与执行 BULK INSERT 语句相关联的安全含义（BULK INSERT 语句要求对运行服务器的网络和计算机上的任何数据具有读权限），bulkadmin 角色成员授予其它角色成员权限可能并不理想。bulkadmin 角色为 sysadmin 固定服务器角色成员提供了一种方法，可以委托要求执行 BULK INSERT 语句的任务，而不用授予用户 sysadmin 权限。允许 bulkadmin 角色成员执行 BULK INSERT 语句，但是这些成员对要插入数据的表仍必须具有 INSERT 权限。

向固定服务器角色添加成员

Transact-SQL

企业管理器

企业管理器

SQL-DMO

固定数据库角色

可以创建的固定数据库角色在数据库级别上定义，并存在于每个数据库中。可将任何有效的用户帐户（Windows NT 4.0 或 Windows 2000 用户或组，或 SQL Server 用户或角色）添加为固定数据库角色成员。每个成员都获得应用于固定数据库角色的权限。固定数据库角色的任何成员都可将其他用户添加到角色中。

下表描述固定数据库角色。

固定数据库角色 | 描述
db_owner | 进行所有数据库角色的活动，以及数据库中的其它维护和配置活动。该角色的权限跨越所有其它固定数据库角色。
db_accessadmin | 在数据库中添加或删除 Windows NT 4.0 或 Windows 2000 组和用户以及 SQL Server 用户。
db_datareader | 查看来自数据库中所有用户表的全部数据。
db_datawriter | 添加、更改或删除来自数据库中所有用户表的数据。
db_ddladmin | 添加、修改或除去数据库中的对象（运行所有 DDL）。
db_securityadmin | 管理 SQL Server 2000 数据库角色的角色和成员，并管理数据库中的语句和对象权限。
db_backupoperator | 有备份数据库的权限。
db_denydatareader | 拒绝选择数据库数据的权限。
db_denydatawriter | 拒绝更改数据库数据的权限。

向 SQL Server（固定）数据库角色添加成员

Transact-SQL

企业管理器

企业管理器

SQL-DMO


public 角色

public 角色是一个特殊的数据库角色，每个数据库用户都属于它。public 角色：

  • 捕获数据库中用户的所有默认权限。

  • 无法将用户、组或角色指派给它，因为默认情况下它们即属于该角色。

  • 含在每个数据库中，包括 master、msdb、tempdb、model 和所有用户数据库。

  • 无法除去。


使用创建登录向导

虽然授权登录访问 Microsoft® SQL Server™ 和数据库所需的步骤可以分开执行，但创建登录向导可简化该过程。创建登录向导使您得以：

  • 选择用于连接 SQL Server 实例的身份验证模式（Windows 身份验证模式或混合模式）。

  • 添加 Microsoft Windows NT® 4.0、Windows® 2000 或 SQL Server 登录。

  • 将 Windows NT 4.0、Windows 2000 或 SQL Server 用户添加到固定服务器角色。

  • 将 Windows NT 4.0、Windows 2000 或 SQL Server 用户添加到一个或多个数据库，从而授权用户访问这些数据库。

通过创建登录向导向用户授予 SQL Server 登录访问权限

企业管理器


管理安全帐户

将安全帐户添加到 Microsoft® SQL Server™ 之后，可以随着业务需要的变化进行修改。通常包括查看、修改和删除数据库中的安全帐户以满足业务需要。


查看登录

查看 Microsoft® SQL Server™ 登录可以帮助确定用户或 Microsoft Windows NT® 4.0 或 Windows® 2000 组是否具有连接到 SQL Server 实例的权限，以及识别登录可以访问哪些数据库。另外，在删除登录之前先查看该登录，了解必须删除哪些数据库用户；必须先删除相关的用户，然后才能删除登录。

可以查看：

  • 每个数据库中与该登录相关的用户。

  • 当用户初次连接到 SQL Server 实例时该登录所使用的默认数据库和语言。

  • Windows NT 4.0 或 Windows 2000 安全标识符 (SID)。

说明 除非密码为 NULL，否则不可能查看任何登录的密码。在密码存储到 SQL Server 时会对其进行加密。

查看 SQL Server 登录或 Windows 用户或组

Transact-SQL

企业管理器

企业管理器

SQL-DMO


修改登录

在创建登录后，有时需要更改密码、默认数据库或默认语言。例如，用户可能忘了自己的密码，出于安全考虑而想更改密码，需要定期使用另一个数据库，或者需要查看以另一种语言显示的消息。

说明 如果用户忘记了密码，sysadmin 或 securityadmin 固定服务器角色成员可以在不知道原密码的情况下更改密码。如果用户忘记了密码，则无法更改它。securityadmin 角色成员无法更改 sysadmin 角色成员的密码。

更改 SQL Server 登录的密码

Transact-SQL

企业管理器

企业管理器

SQL-DMO

更改登录的默认数据库

Transact-SQL

企业管理器

企业管理器

SQL-DMO

更改登录的默认语言

Transact-SQL

企业管理器

企业管理器

SQL-DMO


删除登录和用户

停用安全帐户（例如当某个职员离开了公司时）的过程与添加新用户的过程相似。首先删除用户的 Windows NT 4.0 或 Windows 2000 用户帐户，即可更新 Microsoft® Windows NT® 4.0 或 Windows® 2000 中的安全机制。如果该用户有 Microsoft SQL Server™ 用户帐户，则应将该帐户连同任何为该用户专门定义的 SQL Server 数据库角色一起从 SQL Server 中删除。最后，删除任何 SQL Server 登录。

从 SQL Server 数据库中删除 SQL Server 用户、Windows NT 4.0 或 Windows 2000 用户或组时，将自动删除为该用户或组定义的权限，并防止该用户通过原安全帐户使用数据库。权限的删除不必逐个进行。但是，如果某个用户当前拥有数据库中的对象（表、过程或视图），就不可能从 SQL Server 中删除该用户。如果该用户拥有对象，则或者在删除该用户前先除去这些对象，或者通过使用 sp_changeobjectowner 系统存储过程将所有权转让给另一个已有用户。

删除用户并不会自动删除登录，因此不会防止用户连接到 SQL Server 实例。在被删除后，用户只可以通过 guest 帐户登录到数据库并在其相应权限下进行活动。若要防止用户连接到 SQL Server 实例，请删除该用户的登录。

如果已设置了链接服务器登录但以后不再需要它了，则删除它以防止未经授权而对链接服务器进行访问，并使安全系统尽量简单。

从数据库中删除用户或组

Transact-SQL

企业管理器

企业管理器

SQL-DMO

删除 SQL Server 登录

Transact-SQL

企业管理器

企业管理器

SQL-DMO

从 SQL Server 中废除 Windows 用户或组登录访问

Transact-SQL

企业管理器

企业管理器

SQL-DMO

删除链接服务器登录

Transact-SQL

企业管理器

企业管理器

SQL-DMO

请参见

sp_changeobjectowner


拒绝 Windows NT 帐户的登录访问

如果 Microsoft® Windows NT® 4.0 或 Windows® 2000 用户所属的 Windows NT 4.0 或 Windows 2000 组在 Microsoft SQL Server™ 中有登录帐户，则允许用户通过组登录连接。但是，有些时候可能需要防止这些用户或组连接到 SQL Server 实例。可以拒绝任何 Windows NT 4.0 或 Windows 2000 用户或组的登录访问。如果用户帐户或用户所属组的登录访问被拒绝，这些用户就无法连接到 SQL Server 实例。

拒绝 Windows NT 用户或组的登录访问

Transact-SQL

企业管理器

企业管理器

SQL-DMO


查看角色

创建和使用数据库时，可能需要查找有关 Microsoft® SQL Server™ 数据库角色或固定服务器角色的信息。例如，可能需要查看在当前数据库中有哪些角色，或者列出固定服务器角色。

查看当前数据库中定义的角色

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看当前数据库中定义的固定数据库角色

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看固定服务器角色

Transact-SQL

企业管理器

企业管理器

SQL-DMO


查看和修改角色成员

管理 SQL Server

查看和修改角色成员资格

在使用数据库时，可能需要列出数据库角色或固定服务器角色的成员。或者，当 Microsoft® SQL Server™ 用户不再需要自己所属的角色（包括用户定义角色、固定数据库角色或固定服务器角色）所具有的权限时，可能希望从角色中删除该用户，以使安全系统尽可能保持简单。

查看数据库角色的成员

Transact-SQL

企业管理器

企业管理器

SQL-DMO

从数据库角色中删除用户帐户

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看固定服务器角色的成员

Transact-SQL

企业管理器

企业管理器

SQL-DMO

从固定服务器角色中删除登录

Transact-SQL

企业管理器

企业管理器

SQL-DMO


删除 SQL Server 数据库角色

不断变化的数据库安全要求可能导致 Microsoft® SQL Server™ 数据库角色过时。当已删除所有用户并肯定将来不再需要某些角色及其权限时，应删除这些角色。如果新用户可能需要此权限，则可以保存空角色。但是，从管理角度讲，处理没有多余的安全角色引起混乱的安全系统容易得多。安全系统越简单，SQL Server 运行速度就越快，但是在角色的数目不是极大时这不是问题。

说明 固定服务器角色或固定数据库角色不能删除。

删除 SQL Server 角色

Transact-SQL

企业管理器

企业管理器

SQL-DMO


查看数据库用户

查看数据库中的 Microsoft® SQL Server™ 用户帐户可以显示：

  • 用户是哪个角色的成员。

  • 与该用户关联的 SQL Server 登录。

  • 默认数据库。

使用此信息有助于理解用户如何与数据库的安全系统相适应。

查看数据库用户

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看对当前数据库有访问权限的 Windows 组

Transact-SQL

SQL-DMO


管理权限

当用户连接到 Microsoft® SQL Server™ 实例后，他们可以执行的活动由授予以下帐户的权限确定：

  • 用户的安全帐户。

  • 用户的安全帐户所属的 Microsoft Windows NT® 4.0 或 Windows® 2000 组或角色层次结构。

用户若要进行任何涉及更改数据库定义或访问数据的活动，则必须有相应的权限。

管理权限包括授予或废除执行以下活动的用户权限：

  • 处理数据和执行过程（对象权限）。

  • 创建数据库或数据库中的项目（语句权限）。

  • 利用授予预定义角色的权限（暗示性权限）。
对象权限

处理数据或执行过程时需要称为对象权限的权限类别：

  • SELECT、INSERT、UPDATE 和 DELETE 语句权限，它们可以应用到整个表或视图中。

  • SELECT 和 UPDATE 语句权限，它们可以有选择性地应用到表或视图中的单个列上。

  • SELECT 权限，它们可以应用到用户定义函数。

  • INSERT 和 DELETE 语句权限，它们会影响整行，因此只可以应用到表或视图中，而不能应用到单个列上。

  • EXECUTE 语句权限，它们可以影响存储过程和函数。
语句权限

创建数据库或数据库中的项（如表或存储过程）所涉及的活动要求另一类称为语句权限的权限。例如，如果用户必须能够在数据库中创建表，则应该向该用户授予 CREATE TABLE 语句权限。语句权限（如 CREATE DATABASE）适用于语句自身，而不适用于数据库中定义的特定对象。

语句权限有：

  • BACKUP DATABASE

  • BACKUP LOG

  • CREATE DATABASE

  • CREATE DEFAULT

  • CREATE FUNCTION

  • CREATE PROCEDURE

  • CREATE RULE

  • CREATE TABLE

  • CREATE VIEW
暗示性权限

暗示性权限控制那些只能由预定义系统角色的成员或数据库对象所有者执行的活动。例如，sysadmin 固定服务器角色成员自动继承在 SQL Server 安装中进行操作或查看的全部权限。

数据库对象所有者还有暗示性权限，可以对所拥有的对象执行一切活动。例如，拥有表的用户可以查看、添加或删除数据，更改表定义，或控制允许其他用户对表进行操作的权限。

请参见

BACKUP DATABASE

BACKUP LOG

CREATE DATABASE

CREATE DEFAULT

CREATE FUNCTION

CREATE PROCEDURE

CREATE RULE

CREATE TABLE

CREATE VIEW


授予权限

授予允许用户帐户执行下列活动的语句权限和对象权限：

  • 在当前数据库中执行活动或处理数据。

  • 限制它们执行某些活动或获取某些信息，这些活动或信息都不是其预期功能的一部分。

    例如，您可能想对 personnel 角色的所有成员授予 payroll 表上的 SELECT 对象权限，以允许 personnel 的所有成员查看 payroll。数月过后，您也许无意中听到 personnel 的成员在谈论管理人员的薪水，这一消息本不想让所有 personnel 成员都看到。这种情况下，可向 personnel 授予 payroll 中除 salary 列外的所有列的 SELECT 访问权限。

说明 可以只向当前数据库中的用户帐户授予当前数据库中的对象的权限。如果用户需要另一个数据库中的对象的权限，请在该数据库中创建用户帐户，或者授权用户帐户访问该数据库以及当前数据库。系统存储过程例外，因为 EXECUTE 权限已授予 public 角色，允许每个人执行。但是，在发出 EXECUTE 后，系统存储过程会检查用户的角色成员资格。如果该用户不是运行存储过程所需的固定服务器角色或固定数据库角色的成员，则存储过程不会继续。

通过授权允许访问（对象上）

Transact-SQL

企业管理器

企业管理器

SQL-DMO

向用户授予数据库中的语句权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO

向用户、组或角色授予多个对象的权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO

授予、拒绝或废除用户定义角色在多个对象上的权限

企业管理器


拒绝权限

Microsoft® SQL Server™ 允许 Microsoft Windows NT® 4.0 或 Windows® 2000 用户和组、SQL Server 用户和 SQL Server 数据库角色成为其它角色的成员。这就形成层次安全系统，允许权限通过多个级别的角色和成员而得以应用。但有时可能想限制某些用户或角色的权限。拒绝用户帐户上的权限：

  • 删除以前授予用户、组或角色的权限。

  • 停用从其它角色继承的权限。

  • 确保用户、组或角色将来不继承更高级别的组或角色的权限。

例如，可能需要向公司中的所有终身职员提供访问数据库中若干个表的权限，但分布于整个组织内的几个新职员例外，希望防止他们看到 CorporateSecrets 表。

可以为公司内的每个部门创建一个角色，并将所有职员都添加到相应的部门角色中。然后可以创建一个公司范围的 Corporate 角色，将每个单独的部门角色添加到其中，并授予查看表的权限。此时，公司中的每个职员都可以看到所有表，因为他们通过自己的部门角色从 Corporate 角色继承了权限。

若要有选择性地防止职员查看 CorporateSecrets，则请创建 Nonsecure 角色，将不应该看到该表的每个职员都添加到此角色中。当对 Nonsecure 拒绝查看 CorporateSecrets 的权限时，将从 Nonsecure 的所有成员中删除该访问权限，而公司中的其他职员不受影响。

另外，也可对单个用户拒绝权限。在上一个示例中，非本公司职员在参与数据库中的短期项目时可能有 Windows NT 4.0 或 Windows 2000 帐户。为此，可以拒绝这些人的个人用户帐户查看 CorporateSecrets 的权限，而无须创建 SQL Server 数据库角色。

说明 对于当前数据库中的对象，只可以在当前数据库中对用户帐户拒绝权限。

通过拒绝权限防止访问（在对象上）

Transact-SQL

企业管理器

企业管理器

SQL-DMO

拒绝用户在数据库中的语句权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO

拒绝用户、组或角色在多个对象上的权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO


废除权限

可以废除以前授予或拒绝的权限。废除类似于拒绝，因为二者都是在同一级别上删除已授予的权限。但是，废除权限是删除已授予的权限，并不妨碍用户、组或角色从更高级别继承已授予的权限。因此，如果废除用户查看表的权限，不一定能防止用户查看该表，因为已将查看该表的权限授予了用户所属的角色。

例如，从 HumanResources 角色中删除 Employees 表上的 SELECT 访问权限将废除该权限，从而使 HumanResources 不能再使用该表。如果 HumanResources 是 Administration 角色的成员。如果以后将 Employees 上的 SELECT 权限授予了 Administration，则 HumanResources 的成员可以通过 Administration 中的成员资格看到该表。但是，如果对 HumanResources 拒绝权限，则即使以后向 Administration 授予权限，HumanResources 也不会继承该权限，因为拒绝权限不能由另一级别上的权限撤消。

类似地，通过废除对权限的拒绝也可以删除已拒绝的权限。但是，如果用户在组或角色级别有其它已拒绝权限，则其访问权限仍被拒绝。

说明 对于当前数据库中的对象，只可以对当前数据库中的用户帐户废除权限。

废除对象上的权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO

废除用户在数据库中的语句权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO

废除用户、组或角色在多个对象上的权限

Transact-SQL

企业管理器

企业管理器

SQL-DMO


解决权限冲突

授予组或角色的权限由该组或角色的成员继承。虽然用户可能在一个级别上授予或废除权限，但如果这些权限与更高级别上的权限发生冲突（例如因角色成员资格引起冲突），则可能会禁止或允许用户访问对象。

拒绝

拒绝权限始终优先。在任何级别（用户、组或角色）的拒绝权限都拒绝该对象上的权限，无论该用户现有的权限是已授予权限还是已废除权限。例如，如果用户 John 为 sales 角色成员，而该角色被授予 customer 表上的 SELECT 权限，但 John 被显式拒绝 customer 表上的 SELECT 权限，则他不能再访问该表。类似地，如果 sales 角色被拒绝了对 customer 的访问权限，但 John 被授予访问权限，则其访问将被拒绝。

说明 Microsoft® SQL Server™ 总是首先处理被拒绝的权限。如果对 public 拒绝权限，则将禁止任何用户访问对象，包括发出 DENY 语句的用户。

废除

废除权限只删除所废除级别（用户、组或角色）上的已授予权限或已拒绝权限。而在另一级别（如包含该用户、组或角色的组或角色）上所授予或拒绝的同一权限仍然适用。例如，如果 sales 角色被授予 customer 表上的 SELECT 权限，而 John（sales 角色成员）被显式废除 customer 表上的 SELECT 权限，则 John 仍可以访问该表，因为他有 sales 角色的成员资格。若要防止 John 访问 customer 表，请执行下列操作之一：

  • 废除权限（假定没有在别处授予其它权限）。

  • 拒绝 sales 角色的权限（防止所有 sales 成员访问该表）。

  • 显式拒绝 John 在 customer 上的 SELECT 权限。
授权

授予权限删除所授予级别（用户、组或角色）上的已拒绝权限或已废除权限。而在另一级别（如包含该用户的组或角色）上所拒绝的同一权限仍然适用。但是，虽然在另一级别上所废除的同一权限仍然适用，但它并不阻止用户访问该对象。例如，如果 John 已被显式拒绝 customer 表的访问权限，sales 表被废除访问权限，然后向 John 显式授予 customer 上的访问权限，则他现在可以访问 customer，因为拒绝已被删除。对 sales 的废除权限和对 John 的授予权限相结合使得最后对 John 授予权限。

因此，用户得到的是对象上所授予、拒绝或废除的全部权限的并集，其中拒绝权限比另一级别上授予或撤消的同一权限优先。

下面的关系图显示三种权限管理活动如何影响用户帐户的权限状态。

数据库访问与对象访问

作为权限冲突的示例，假设 Microsoft Windows NT® 4.0 用户 LONDON\joe 属于 LONDON\clerks 和 LONDON\secretaries Windows 4.0 组。因为已授予 LONDON\clerks 组连接到 SQL Server 实例的权限，所以 LONDON\joe 可以登录到 SQL Server 实例。此外，LONDON\joe 可以访问 secrets 数据库，因为 LONDON\secretaries 组已被授予访问该数据库的权限。

说明 此时，LONDON\joe 在 SQL Server 系统表 sysusers 和 syslogins 中没有特定的条目。这些系统表中只含有 LONDON\clerks 和 LONDON\secretaries 组的条目。

LONDON\joe 在 secrets 数据库中创建表 joetable。此时，在 sysusers 表中为 LONDON\joe 创建新条目，指定其为对象所有者，但不授予其数据库访问权限。如果将 LONDON\joe 从 LONDON\secretaries 组中除去，他就不再能访问 secrets 数据库了，但仍拥有数据库中的对象 joetable。

请参见

添加 Windows NT 用户或组


用户定义函数的权限

函数是由一个或多个 Transact-SQL 语句组成的子程序，可用于封装代码以便重新使用。Microsoft® SQL Server™ 2000 使用户得以创建自己的用户定义函数。

通过下列语句管理用户定义函数：

  • CREATE FUNCTION，可以创建用户定义函数。

  • ALTER FUNCTION，可以修改用户定义函数。

  • DROP FUNCTION，可以除去用户定义函数。

每个完全合法的用户定义函数名 (database_name.owner_name.function_name) 必须唯一。

必须被授予 CREATE FUNCTION 权限才能创建、修改或除去用户定义函数。函数所有者以外的用户可以在 Transact-SQL 语句中使用此函数前，必须先被授予此函数上的 EXECUTE 权限（如果此函数是标量值函数）。如果函数是表值函数，则用户在引用函数前必须对函数具有 SELECT 权限。如果 CREATE TABLE 或 ALTER TABLE 语句在 CHECK 约束、DEFAULT 子句或计算列中引用用户定义函数，则表所有者也必须拥有此函数。如果要对函数进行架构绑定，则必须在此函数所引用的表、视图和函数上有 REFERENCE 权限。

可以通过 GRANT 语句将 REFERENCE 权限授予视图、用户定义函数以及表。

请参见

用户定义函数


使用所有权链

视图或存储过程为赋予用户访问数据与执行操作的能力提供了第二种方法。它们使用户可以访问数据库中的基础项，并回避为特定对象和语句直接定义的权限。

视图可以基于其它视图或表。过程可以基于其它过程、视图或表。可以将这些相关性视为所有权链。所有权链只适用于 SELECT、INSERT、UPDATE 和 DELETE 语句。

通常，视图的所有者还拥有基础对象（其它视图或表），而存储过程的所有者经常拥有引用的所有过程、表和视图。另外，视图或基础对象通常都在同一数据库中，存储过程和所有引用的对象也如此。当在存储过程内创建临时临时对象时，它们由过程所有者拥有而不是由当前执行过程的用户拥有。

当用户访问某个视图时，如果该视图的基础对象和此视图都为同一用户所有，或者如果该视图及其所有基础对象都在同一数据库中，则 Microsoft® SQL Server™ 不检查该视图基础对象上的权限。如果同一用户拥有存储过程及其所引用的所有视图和表，或者如果存储过程及其对象都在同一数据库中，SQL Server 就只检查过程上的权限。

如果过程或视图的所有权链破坏了（链中的所有对象并不为同一用户所有），SQL Server 就会检查在链中每个下一个更低链接为另一用户所有的对象上的权限。通过这种方式，SQL Server 使得原始数据的所有者可以保留对原始数据可用性的控制。

通常情况下，创建视图的用户只能授予该视图上的权限。例如，Mary 在其所拥有的 authors 表上创建了名为 auview1 的视图。如果 Mary 授予 Sue 使用 auview1 的权限，SQL Server 就允许 Sue 访问它而不检查在 authors 上的权限。

如果用户创建的视图或存储过程取决于另一用户所拥有的对象，则创建者必须意识到：他（她）所授予的任何权限都取决于另一个所有者所允许的权限。

例如，Joe 创建名为 procedure1 的过程，该过程取决于 procedure2（也为 Joe 所拥有）和 procedure3（为 Sue 所拥有）。这些过程依次取决于 Joe 和 Sue 所拥有的其它表和视图。

Joe 授予 Mary 使用 procedure1 的权限。SQL Server 检查 procedure1、procedure3、view2、table2 和 table3 上的权限以核查是否允许 Mary 使用它们。


使用视图作为安全机制

通过限制可由用户使用的数据，可以将视图作为安全机制。用户可以访问某些数据，进行查询和修改，但是表或数据库的其余部分是不可见的，也不能进行访问。无论在基础表（一个或多个）上的权限集合有多大，都必须授予、拒绝或废除访问视图中数据子集的权限。

例如，某个表的 salary 列中含有保密职员信息，但其余列中含有的信息可以由所有用户使用。可以定义一个视图，它包含表中除敏感的 salary 列外所有的列。只要表和视图的所有者相同，授予视图上的 SELECT 权限就使用户得以查看视图中的非保密列而无须对表本身具有任何权限。

通过定义不同的视图及有选择地授予视图上的权限，可以将用户、组或角色限制在不同的数据子集内。例如：

  • 可以将访问限制在基表中行的子集内。例如，可以定义一个视图，其中只含有商业书籍或心理书籍的行，并向用户隐藏有关其它类型书籍的信息。

  • 可以将访问限制在基表中列的子集内。例如，可以定义一个视图，其中含有 titles 表中的所有行，但省略了 royalty 和 advance 列，因为这些信息比较敏感。

  • 可以将访问限制在基表中列和行的子集内。

  • 可以将访问限制在符合多个基表联接的行内。例如，可以定义一个视图，它联接表 titles、authors 和 titleauthor 表以显示作者姓名及其撰写的书籍。该视图隐藏作者的个人信息以及著作的财务信息。

  • 可以将访问限制在基表中数据的统计汇总内。例如，可以定义一个视图，其中只含有每类书籍的平均价格。

  • 可以将访问限制在另一个视图的子集内或视图和基表组合的子集内。
权限和 ALTER VIEW

使用 ALTER VIEW Transact-SQL 语句可以更改视图的定义而不必除去视图并重新应用权限。应用到视图中列上的任何权限均基于视图中定义的列名，而不是表中的基础列。因此，如果用 ALTER VIEW 更改视图的定义，且使用相同的列名，但使用表中不同的基础列，则新列的权限相同。下例假定用户 Fred 在 pubs 数据库中：

USE pubs
GO
CREATE VIEW v1 AS SELECT title_id, title FROM titles
GO
GRANT SELECT(title_id) ON v1 TO Fred
GO
ALTER VIEW v1 AS SELECT qty AS 'title_id' FROM sales
GO

虽然视图发生改变，title_id 列名引用 sales 表中的 qty 列，而不是 titles 表中的 title_id 列，但授予 Fred 在 title_id 列名上的 SELECT 权限仍然适用。

请参见

ALTER VIEW

CREATE VIEW


使用存储过程作为安全机制

存储过程通常用作执行复杂活动的接口，并且可按与视图几乎相同的方法自定义安全权限。

例如，在存档方案中，存储过程可以将存在时间超过指定间隔的数据复制到存档表中，然后从主表中删除这些数据。可以使用权限防止用户直接从主表中删除行或者将行插入到存档表中，而不从主表中删除。可以创建过程以确保这两种活动一起进行，然后授权用户执行该过程。

请参见

CREATE PROCEDURE


高级安全主题

下面介绍的安全主题超出了 Microsoft® SQL Server™ 安全性的基本用法，并提供了有关专用应用程序的更多详细信息。


建立应用程序安全性和应用程序角色

Microsoft® SQL Server™ 中的安全系统在最低级别，即数据库本身上实现。无论使用什么应用程序与 SQL Server 通讯，这都是控制用户活动的最佳方法。但是，有时必须自定义安全控制以适应个别应用程序的特殊需要，尤其是当处理复杂数据库和含有大表的数据库时。

此外，可能希望限制用户只能通过特定应用程序（例如使用 SQL 查询分析器或 Microsoft Excel）来访问数据或防止用户直接访问数据。限制用户的这种访问方式将禁止用户使用应用程序（如 SQL 查询分析器）连接到 SQL Server 实例并执行编写质量差的查询，以免对整个服务器的性能造成负面影响。

SQL Server 通过使用应用程序角色适应这些要求。应用程序角色与标准角色有以下区别：

  • 应用程序角色不包含成员。

    不能将 Microsoft Windows NT® 4.0 或 Windows® 2000 组、用户和角色添加到应用程序角色；当通过特定的应用程序为用户连接激活应用程序角色时，将获得该应用程序角色的权限。用户之所以与应用程序角色关联，是由于用户能够运行激活该角色的应用程序，而不是因为其是角色成员。

  • 默认情况下，应用程序角色是非活动的，需要用密码激活。

  • 应用程序角色不使用标准权限。

    当一个应用程序角色被该应用程序激活以用于连接时，连接会在连接期间永久地失去数据库中所有用来登录的权限、用户帐户、其它组或数据库角色。连接获得与数据库的应用程序角色相关联的权限，应用程序角色存在于该数据库中。因为应用程序角色只能应用于它们所存在的数据库中，所以连接只能通过授予其它数据库中 guest 用户帐户的权限，获得对另一个数据库的访问。因此，如果数据库中没有 guest 用户帐户，则连接无法获得对该数据库的访问。如果 guest 用户帐户确实存在于数据库中，但是访问对象的权限没有显式地授予 guest，则无论是谁创建了对象，连接都不能访问该对象。用户从应用程序角色中获得的权限一直有效，直到连接从 SQL Server 退出为止。

若要确保可以执行应用程序的所有函数，连接必须在连接期间失去应用于登录和用户帐户或所有数据库中的其它组或数据库角色的默认权限，并获得与应用程序角色相关联的权限。例如，如果应用程序必须访问通常拒绝用户访问的表，则应废除对该用户拒绝的访问权限，以使用户能够成功使用该应用程序。应用程序角色通过临时挂起用户的默认权限并只对他们指派应用程序角色的权限而克服任何与用户的默认权限发生的冲突。

应用程序角色允许应用程序（而不是 SQL Server）接管验证用户身份的责任。但是，SQL Server 在应用程序访问数据库时仍需对其进行验证，因此应用程序必须提供密码，因为没有其它方法可以验证应用程序。

如果不需要对数据库进行特殊访问，则不需要授予用户和 Windows NT 4.0 或 Windows 2000 组任何权限，因为所有权限都可以由它们用来访问数据库的应用程序指派。在这种环境下，假设对应用程序的访问是安全的，则在系统范围内统一使用指派给应用程序角色的密码是可能的。

有几个选项可用于管理应用程序角色密码而无须将其硬编码到应用程序中。例如，可以使用存储在注册表（或 SQL Server 数据库）中的加密键，只有应用程序有加密键的解密代码。应用程序读取键，对其进行解密，并使用其值设置应用程序角色。如果使用多协议 Net-Library，则含有密码的网络数据包也可以被加密。另外，当角色被激活时，可以在发送到 SQL Server 实例前将密码加密。

如果应用程序用户使用 Windows 身份验证模式连接到 SQL Server 实例，则在使用应用程序时，可以使用应用程序角色设置 Windows NT 4.0 或 Windows 2000 用户在数据库中拥有的权限。这种方法使得当用户使用应用程序时，对用户帐户的 Windows NT 4.0 或 Windows 2000 审核及对用户权限的控制容易维护。

如果使用 SQL Server 身份验证，并且不要求审核用户在数据库中的访问，则应用程序可以更容易地使用预定义的 SQL Server 登录连接到 SQL Server 实例。例如，订单输入应用程序验证运行该应用程序的用户，然后用相同的 OrderEntry 登录连接到 SQL Server 实例。所有连接都使用同一登录，相关权限授予该登录。

说明 应用程序角色可以和两种身份验证模式一起使用。

示例

作为应用程序角色使用的示例，假设用户 Sue 运行销售应用程序，该应用程序要求在数据库 Sales 中的表 Products 和 Orders 上有 SELECT、UPDATE 和 INSERT 权限，但她在使用 SQL 查询分析器或任何其它工具访问 Products 或 Orders 表时不应有 SELECT、INSERT 或 UPDATE 权限。若要确保如此，可以创建一个拒绝 Products 和 Orders 表上的 SELECT、INSERT 或 UPDATE 权限的用户-数据库角色，然后将 Sue 添加为该数据库角色的成员。接着在 Sales 数据库中创建带有 Products 和 Orders 表上的 SELECT、INSERT 和 UPDATE 权限的应用程序角色。当应用程序运行时，它通过使用 sp_setapprole 提供密码激活应用程序，并获得访问 Products 和 Orders 表的权限。如果 Sue 尝试使用除该应用程序外的任何其它工具登录到 SQL Server 实例，则将无法访问 Products 或 Orders 表。

创建应用程序角色

Transact-SQL

企业管理器

企业管理器

SQL-DMO

设置应用程序角色

Transact-SQL

更改应用程序角色的密码

Transact-SQL

SQL-DMO

删除应用程序角色

Transact-SQL

企业管理器

企业管理器

SQL-DMO


允许其它帐户授予对象权限

在将对象权限授予数据库中的用户帐户时，可以选择指定 WITH GRANT OPTION 子句，该子句允许用户帐户将该对象权限授予其它帐户。用户帐户可以是 Microsoft® Windows NT® 4.0 或 Windows® 2000 用户或组，也可以是 Microsoft SQL Server™ 用户或角色。

例如，如果在向用户 user_a 授予 salaries 表的权限时使用 WITH GRANT OPTION 子句，user_a 就能够向该数据库中的任何其它用户帐户授予该表上的相同权限。对于组和角色，如果指定 WITH GRANT OPTION 子句向角色 role_a 授予 salaries 表的权限，倘若指定 GRANT 语句的 AS 子句，则 role_a 的每个成员都可以向任何其它用户帐户授予对象权限。有关更多信息，请参见 GRANT。

重要 在使用 WITH GRANT OPTION 子句时，无法进一步控制哪些安全帐户将接收该权限。

当使用 WITH GRANT OPTION 子句废除所授予权限时，请指定 CASCADE 子句以从该用户帐户和从初始帐户接收权限的任何其它帐户废除权限。

例如，指定 WITH GRANT OPTION 向用户 user_a 授予权限，User_a 通过指定 WITH GRANT OPTION 向用户 user_b 授予权限，user_b 又向 user_c 授予权限。User_a 离开了公司，但如果某用户帐户已通过指定 WITH GRANT OPTION 子句而向另一个帐户授予权限，SQL Server 就不允许您删除该用户帐户。指定 WITH GRANT OPTION 子句就是创建了从 user_a 到 user_b 再到 user_c 的链。直到废除了 user_b 和 user_c 的权限才可以删除 user_a 的帐户。当废除 user_a 的权限并指定 CASCADE 选项时，该权限就会从 user_a、user 和 user_c 帐户中删除。然后可以删除 user_a 帐户。


创建 SQL Server 文件权限

Microsoft® SQL Server™ 必须创建和访问存储数据库、数据库备份、错误日志等的文件。该 SQL Server 进程必须在有必需权限的安全帐户环境中运行，才能创建和访问这些文件，无论这些文件是在本地计算机上还是在远程计算机的网络驱动器上。SQL Server 所使用的安全帐户取决于用于启动 SQL Server 实例的方法。如果启动 SQL Server 实例，则：

  • 作为 Microsoft Windows NT® 4.0 或 Windows® 2000 上使用服务控制管理器的服务，SQL Server 使用指派给 SQL Server 服务的安全帐户。

  • 在命令提示符处，独立于服务控制管理器，SQL Server 使用已登录用户的安全帐户。

  • 在 Microsoft Windows 98 和 Microsoft Windows Millennium 版中，SQL Server 使用已登录用户的安全帐户。

SQL Server 所使用的安全帐户要求对文件系统具有创建、读、写、删除和执行文件的完全访问权限。例如，如果使用 NTFS 文件系统，则 SQL Server 所使用的安全帐户要求具有用 NTFS 完全控制权限创建文件的授权。

若要防止未经授权而对 SQL Server 所使用的文件进行访问，请直接调整文件上的权限，以便只允许 SQL Server 所使用的安全帐户访问这些文件。

说明 如果 SQL Server 使用 Windows NT 4.0 和 Windows 2000 LocalSystem 内置安全帐户，则必须给运行 SQL Server 实例的本地计算机的 SYSTEM 帐户授予文件权限。

保护 Windows NT 注册表

对于不是 SQL Server 系统管理员的用户，SQL Server 安装程序从 Windows 2000 注册表的 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers 键中删除这些用户的写权限。这防止了不是管理员的用户在使用 SQL Server 企业管理器时，为链接服务器定义设置提供程序选项。

请参见

设置 Windows 服务帐户

启动 SQL Server


使用加密方法

加密是通过将数据更改为不可读形式而使敏感数据得以保密的方法。加密通过对每个人都隐藏信息而确保数据安全，即使有人直接查看加密数据仍然如此。解密是将加密数据更改为原始形式以便授权用户读取的过程。

Microsoft® SQL Server™ 加密或可以加密：

  • SQL Server 中存储的登录和应用程序角色密码。

  • 作为网络数据包而在客户端和服务器端之间发送的数据。

  • 存储过程定义。

  • 用户定义函数定义。

  • 视图定义。

  • 触发器定义。

  • 默认值定义。

  • 规则定义。

说明 如果正在运行 Microsoft Windows® 2000 且希望使用 Windows 2000 加密文件系统加密任何 SQL Server 文件，则必须在更改 SQL Server 服务帐户前解密文件。如果没有解密文件且之后重置了 SQL Server 服务帐户，将无法解密文件。

登录和应用程序角色密码

SQL Server 系统表中存储的登录和应用程序角色密码总是被加密。这可防止用户（包括系统管理员）查看任何密码，包括自己的密码。此外，在网络上发送应用程序角色密码之前，当应用程序角色激活时，就可以对其进行加密。

说明 如果需要，使用 sp_addlogin 系统存储过程就可以添加密码未加密的 SQL Server 登录。但不建议这样做，除非密码因正从其它 SQL Server 实例导入而已被加密。

网络数据包中的数据

SQL Server 允许对客户端和服务器端之间发送的数据进行加密。这样可确保任何在网络上截取数据包的应用程序或用户无法查看保密或敏感数据，例如，当用户登录到 SQL Server 实例时在网络上发送的密码。SQL Server 可以使用安全套接字层 (SSL) 加密在应用程序计算机与 SQL Server 实例之间传输的所有数据。SSL 加密在超级套接字 Net-Library（Dbnetlib.dll 和 Ssnetlib.dll）内执行并应用于 SQL Server 2000 所支持的所有计算机间协议。启用加密会降低 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。有关 SSL 的更多信息，请参见 Net-Library 加密。

配置多协议别名

配置多协议别名时启用加密功能。该加密功能只适用于多协议 Net-Library。提供该加密功能只是为与现有应用程序兼容。SQL Server 客户端应使用 SSL 加密，而该加密是在客户端网络实用工具的"启用协议加密"复选框中的"常规"选项卡上指定的。有关客户端网络实用工具的更多信息，请参见配置客户端 Net-Library。

启动客户端网络实用工具

Client Network Utility

客户端网络实用工具

配置使用多协议 Net-Library 的客户端

Client Utility

客户端实用工具

存储过程、函数、视图和触发器定义

在 syscomments 系统表中保存存储过程、函数、触发器或视图的定义时，可以对其进行加密（例如，如果 SQL Server 系统包含专有的存储过程、函数、触发器或视图，则其定义不应由用户和第三方查看）。

请参见

客户端和服务器 Net-Library

CREATE DEFAULT

CREATE FUNCTION

CREATE PROCEDURE

CREATE RULE

CREATE TRIGGER

CREATE VIEW

多协议客户端

Net-Library 加密

sp_addlogin

sp_addrole

sp_approlepassword

sp_setapprole


在网络上公布 SQL Server

在安装 Microsoft® SQL Server™ 时，SQL Server 安装程序将在 Microsoft Windows® 2000 注册表中生成一项，以使命名管道客户端能够在 SQL 查询分析器的服务器枚举框中看到 SQL Server。SQL Server 自动在命名管道上将自身作为服务公布，以使定位运行 SQL Server 实例的服务器更容易。但是，如果正在使用 Active Directory™（Windows 2000 中包含的目录服务），则无须再使用此功能。

通过带 /HIDDEN:YES 开关运行 NET CONFIG SERVER 命令，可以阻止 SQL Server 将自身在命名管道上公布。可以随时公布服务器。

在网络上显示或取消 SQL Server 公告

Windows NT


编写 Internet Explorer 中数据访问控件的脚本

随 Microsoft® SQL Server™ 提供几个数据访问控件：

  • SQL 命名空间 (SQL-NS)

  • SQL 分发控件（复制）

  • SQL 合并控件（复制）

这些控件已签名并标有"对于初始化和脚本是安全的"，可用于 Microsoft Internet Explorer 5 版或更高版本。

在部署可以连接到数据源的控件前，应该完全了解安全含义。当使用任何 SQL Server 控件时，主要的安全考虑是能否通过 Windows 身份验证登录到 SQL Server 实例，并在授权的用户帐户下运行。含有脚本控件的 Web 页是用浏览该页面的用户的网络标识运行的。如果数据源连接是基于已连接用户的网络标识（使用 Windows 身份验证登录），则该控件可以访问浏览页面的用户可以访问的任何数据。如果有使用该控件的 Web 页发送给用户，则该控件具有浏览 Web 页的用户所具有的权限。然后，控件可以在用户不知道的情况下读取或更改数据库。

为防止未经授权对数据库进行访问或更改，所有标有"对于脚本是安全的"的数据访问控件，在装载到 Internet Explorer 4.0 或更高版本时均会考虑安全性区域设置。如果控件未标有"对于脚本是安全的"，则它只能在 Internet Explorer 的"低"安全模式下在 Internet Explorer 内运行脚本，甚至只能在用户对说明脚本将要运行的消息作出响应之后才能运行。处理此问题的另一个方法是删除用户使用 Windows 身份验证登录的能力。

Internet Explorer 4.0 不提供针对数据访问的显式安全选项。因此，所有标有"对于脚本是安全的"的控件都根据所用的安全性区域而允许、提示或禁止脚本。下表显示 Internet Explorer 4.0 的设置。

安全性区域 | Internet Explorer 4.0 提示
本地计算机区域 | 控件可被初始化或编成脚本，并与数据源和脚本无关。
本地 Intranet 区域 | 在装载页面前通知用户潜在的安全威胁。用户可以接受或拒绝初始化或编入脚本。
信任站点区域 | 控件可被初始化或编成脚本，并与数据源和脚本无关。
Internet 区域 | 在装载页面前通知用户潜在的安全威胁。用户可以接受或拒绝初始化或编入脚本。
受限站点区域 | 如果用户试图查看页面和执行脚本，就会发生脚本错误。

与 Internet Explorer 4.0 相反，Internet Explorer 5 版支持一种用于数据访问的显式安全选项，称为"跨域访问数据源"。可以自定义该选项，此操作的设置用于决定控件在 Internet Explorer 5 中运行时的行为。Internet Explorer 5 中的默认设置与 Internet Explorer 4.0 中的程序化设置相同。

出于安全性考虑，必须采取特别的措施以保护系统。只有在具备使用 Windows 身份验证登录能力的用户正确地配置安全设置，并且正确地应答所有安全性提示后，SQL Server 才可免受安全性攻击。

说明 这些保护系统的一般步骤适用于任何脚本主机，包括 Microsoft Excel 电子表格或 Microsoft Word 文档。能够使用 Windows 身份验证登录的用户应始终启用应用程序的宏警告功能或类似的安全设置，以检测并防范任何对数据的攻击。

请参见

开发 SQL-DMO 应用程序

SQL-NS 应用程序设计


审核 SQL Server 活动

Microsoft® SQL Server™ 2000 提供审核功能，用以跟踪和记录每个 SQL Server 实例上已发生的活动（如成功和失败的记录）。SQL Server 2000 还提供管理审核记录的接口，即 SQL 事件探查器。只有 sysadmin 固定安全角色的成员才能启用或修改审核，而且审核的每次修改都是可审核的事件。

有两种类型的审核：

  • 审核，提供某种级别的审核，但不要求与 C2 审核相同的策略数。

  • C2 审核，要求遵从十分明确的安全策略。有关 C2 审核的更多信息，请参见 C2 审核。

这两种审核都可以通过使用 SQL 事件探查器完成。

使用 SQL 事件探查器

SQL 事件探查器为审核事件提供用户界面。可使用 SQL 事件探查器进行审核的事件分为几类，如：

  • 最终用户活动（所有 SQL 命令、注销/登录和应用程序角色的启用）

  • DBA 活动（DDL、授予/废除/拒绝和安全事件之外的 DBA 活动、配置 DB 或服务器）。

  • 安全事件（授予/废除/拒绝、登录用户/角色的添加/删除/配置）。

  • 实用工具事件（备份/还原/大容量插入/BCP/DBCC 命令）。

  • 服务器事件（关闭、暂停、启动）。

  • 审核事件（添加审核、修改审核、停止审核）。

有关可以监视的事件分类的更多信息，请参见安全审核事件分类。

可以通过 SQL 事件探查器审核 SQL Server 的下列方面：

  • 事件的日期和时间。

  • 导致事件发生的用户。

  • 事件类型。

  • 事件的成功或失败。

  • 发出请求的起点（如 Microsoft Windows NT® 4.0 计算机名）。

  • 访问的对象名。

  • SQL 语句的文本（密码由 **** 替换）。

  • 如果您是 sysadmin 或 securityadmin 固定服务器角色的成员，并且通过使用含有全部指定的三个参数（'old_password'、'new_password'、'login'）的 sp_password 重置自己的密码，则审核记录将反映您正在更改其他人的密码。

审核对性能有显著影响。如果为所有对象打开所有审核计数器，可能会对性能造成很大的影响。必须根据所造成的性能影响，来估计需要进行审核的事件数。分析审核记录的费用可能很高，因此建议在与生产服务器不同的服务器上运行审核活动。

说明 如果用 -f 标志启动 SQL Server，则审核不会运行。

请参见

使用 SQL 事件探查器进行监视


使用审核日志

SQL 事件探查器系统存储过程支持文件翻转。审核日志的最大文件大小固定为 200 MB。当审核日志文件达到 200 MB 时，将创建新文件并将关闭旧文件句柄。如果目录已满（例如，如果服务用户帐户的磁盘配额已满或者磁盘已满），Microsoft® SQL Server™ 实例将停止运行。系统管理员需要为审核日志释放磁盘空间然后重新启动 SQL Server 实例，或者重新启动 SQL Server 实例（如果未将审核配置成自动启动）。

使用文件翻转可以避免审核跟踪由于审核日志已填满而失败。不过，SQL Server 不会关闭，除非用户在创建跟踪时特地请求了这个功能。审核失败事件将在 Microsoft Windows® 事件日志和 SQL Server 错误日志中生成一项。

强烈建议在 SQL Server 安装过程中创建新目录来包含审核文件。建议使用 \mssql\audit 路径。如果在命名实例上运行 SQL Server，则建议使用 MSSQL$Instance\audit 路径。


C2 审核

如果运行 C2 认证系统，则 C2 审核为必需。C2 认证系统符合定义安全级别的政府标准。若要拥有 C2 认证的 Microsoft® SQL Server™，必须以经过评估的 C2 配置对 SQL Server 进行配置。有关 C2 认证的更多信息，请参见《C2 管理员及用户安全指南》。


监视服务器性能和活动

Microsoft® SQL Server™ 2000 提供多种工具监视 SQL Server 实例的性能以及在数据库中发生的用户活动。通过监视使您得以确定数据库应用程序是否按预期有效地运行，即使应用程序、数据库和环境发生了变化。例如，随着更多的并发用户使用数据库应用程序，SQL Server 上的负荷可能会增加。通过监视，可以确定是否必须更改当前的 SQL Server 实例或系统配置以处理增加的工作负荷，或者确定增加的负荷是否对性能无显著的影响。

监视应用程序、SQL Server 实例或操作系统环境（硬件和软件）：

  • 确定监视目标。

  • 为要执行的监视类型选择合适的工具。

  • 使用工具监视 SQL Server 或系统环境并分析捕获的数据。

  • 识别要监视的事件。

    事件确定所要监视和捕获的活动。选择要监视的事件取决于要监视的目标和原因。例如，当监视磁盘活动时，没必要监视 SQL Server 锁。

  • 确定要捕获的事件数据。

    事件数据描述事件发生时的每个实例。例如，当监视锁事件时，可捕获描述受锁事件影响的表、用户和连接的数据。下面解释涉及捕获事件数据并使这些数据可供使用的过程。

    • 应用筛选限制收集的事件数据。

      限制事件数据使系统得以将精力集中在与监视方案有关的事件上。例如，若要监视慢速查询，可使用筛选只监视由应用程序发出的、对特定数据库执行时间超过 30 秒的查询。

    • 监视（捕获）事件。

      一旦启用，活动监视就从指定的应用程序、SQL Server 实例或操作系统捕获数据。例如，当使用系统监视器（Microsoft Windows NT® 4.0 中的性能监视器）监视磁盘活动时，监视将捕获事件数据（如磁盘读取和写入）并在屏幕上显示该数据。

    • 保存捕获的事件数据。

      保存捕获的数据使您得以稍后对其进行分析，甚至使用 SQL 事件探查器重播该数据。将捕获的事件数据保存到一个文件中，用户可以使用当初创建该文件的工具重新打开它进行分析。SQL 事件探查器还允许将事件数据保存到 SQL Server 表中。保存捕获的事件数据对创建性能基线至关重要。在比较最近捕获的事件数据以确定是否已获得最佳性能时，保存和使用性能基线数据。

    • 创建定义文件以包含为捕获事件指定的设置。

      定义文件包含有关事件本身、事件数据和用于捕获数据的筛选的说明。以后可以使用这些文件监视一组特定事件，而无须重新定义事件、事件数据和筛选。例如，若要经常监视死锁的数量和那些死锁所涉及的用户，可以创建一个文件定义那些事件、事件数据和事件筛选；保存定义；并在下次想监视死锁时重新应用筛选。为此，SQL 事件探查器使用跟踪定义文件。

    • 分析捕获的事件数据。

      为了进行分析，将捕获的已保存事件数据装载到捕获该数据的应用程序中。例如，可以将 SQL 事件探查器捕获的跟踪重新装载到 SQL 事件探查器中进行查看和分析。对事件数据的分析包括确定所发生的事件和发生原因。利用这些信息可以做一些修改以提高性能，如增加更多内存、纠正 Transact-SQL 语句或存储过程的编码错误、更改索引等，具体取决于所执行的分析类型。例如，可以使用索引优化向导自动分析从 SQL 事件探查器捕获的跟踪并基于结果生成索引建议。

    • 重播捕获的事件数据。

      事件重播使您得以建立捕获数据时的数据库环境的测试复本，并重复捕获事件，与当初在真实系统上发生的一样，但是只在 SQL 事件探查器中可用。可以按事件当初发生时的相同速度重播或尽可能快地重播（增加系统的压力），或者更可能的方式是一次重播一步（在每发生一个事件后对系统进行分析）。通过在测试环境中分析确切的事件，可以防止对生产系统产生任何有害的影响。

监视 SQL Server 使您得以：

  • 确定是否有可能提高性能。例如，通过监视常用查询的响应时间，可以确定是否有必要更改查询或表上的索引。

  • 评估用户活动。例如，通过监视试图连接到 SQL Server 实例的用户，可以确定安全设置是否得当并测试应用程序和开发系统。例如，通过在执行 SQL 查询时对其进行监视，可以确定这些查询是否编写正确并生成预期的结果。

  • 解决任何问题或调试应用程序组件（如存储过程）。

请参见

索引优化向导

数据库性能优化概述


评估性能

通过有效的网络流量、磁盘 I/O 和 CPU 时间，可获得最短的响应时间和最大的吞吐量，从而获得最佳性能。为达到此目的，需要彻底分析应用程序的要求，了解数据的逻辑结构和物理结构，并评估和协商解决数据库使用冲突（如联机事务处理 (OLTP) 与决策支持）的平衡措施。

响应时间与吞吐量

响应时间是这样度量的：以可视的形式确认正在处理查询并将结果集中的首行返回给用户所需的时间长度。

吞吐量是服务器在给定时间内处理的查询总数的度量值。

随着用户数的增加，对服务器资源的竞争也随之增加，转而导致响应时间增加和总体吞吐量减少。

影响性能的因素

下列方面影响 SQL Server 的性能：

  • 系统资源（硬件）

  • Microsoft Windows NT® 4.0 和 Windows® 2000 操作系统

  • 数据库应用程序

  • 客户端应用程序

  • 网络

必须知道在正常工作条件下的合理性能级别，才能监视这些方面。为此需建立服务器性能基线，即以定期的间隔监视 Microsoft® SQL Server™ 性能（即使没有发生问题时）。

解决问题

可以监视下列方面以解决问题：

  • SQL Server 存储过程或用户应用程序提交的批处理 SQL 语句。

  • 用户活动（如阻塞锁或死锁）。

  • 硬件活动（如磁盘使用）

问题可以包括：

  • 应用程序开发错误（包括错误编写 Transact-SQL 语句）。

  • 硬件错误（如磁盘错误或与网络有关的错误）。

  • 由于数据库设计不正确导致的过多阻塞。

可以使用 SQL 事件探查器监视和解决 Transact-SQL 问题和与应用程序有关的问题。可以使用系统监视器（Windows NT 4.0 中的性能监视器）监视硬件问题和其它与系统有关的问题。


建立性能基线

若要确定 Microsoft® SQL Server™ 系统的性能是否处于最佳状态，请取得不同时间的性能度量值并建立服务器性能基线。将每组新的度量值与以前取得的度量值进行比较。

建立服务器性能基线后，将基线统计与当前服务器性能进行比较。对远高于或远低于基线的数字需要做进一步调查。它们可能表明有需要调整或重新配置的区域。例如，如果执行一组查询所需的时间增加，检查这些查询以确定能否重新编写它们，或者是否必须添加列统计或新索引。

至少，使用基线度量值确定：

  • 操作的峰值时间和非峰值时间。

  • 生产查询或批命令响应时间。

  • 数据库备份和还原所需时间。

请参见

sp_configure


识别瓶颈

瓶颈是由于对系统资源过多需求所造成的，在每个系统中以不同的程度存在。通过监视 Microsoft® SQL Server™ 系统中的瓶颈，可以确定能否更改限制性能的组件以优化其性能。

发生瓶颈的原因包括：

  • 资源不足，需要添加或升级组件。

  • 同一类型的资源的工作负荷不均匀（例如一个磁盘被独占）。

  • 资源发生故障。

  • 资源配置不正确。
分析瓶颈

当分析事件数据时，小的数字与大的数字一样有意义。如果数字比预期的小，可能表明另一个方面的问题。例如：

  • 某个其它组件可能正防碍负荷到达该组件。

  • 网络拥塞可能正防碍客户端请求到达服务器。

  • 瓶颈可能正防碍客户端计算机如预期的那样频繁访问服务器。

  • 系统监视器（Microsoft Windows NT® 4.0 中的性能监视器）的部署可能不正确。例如，如果没有打开磁盘计数器，或正在查看错误的实例、错误的计数器或者在错误的计算机上，则事件数据数字可能看起来超乎寻常的小。

较小的数字还可能意味着系统的性能比预期的好。

下面是当跟踪服务器性能和识别瓶颈时应监视的五个主要方面。

潜在瓶颈 | 对服务器的影响
内存使用 | 分配的内存不足或可由 SQL Server 使用的内存不足将降低性能。数据不是驻留在数据高速缓存内，而是必须从磁盘连续读取。当需要页时，Windows NT 4.0 和 Microsoft Windows® 2000 与磁盘交换数据而导致过多的换页操作。
CPU 处理器使用 | 持续的 CPU 高使用率可能表明需要升级 CPU或添加多个处理器。
磁盘 I/O 性能 | 低磁盘 I/O（磁盘的读写活动）将导致事务吞吐量降低。
用户连接 | 不正确地配置用户数会导致系统运行速度变慢或限制本来可由 SQL Server 使用的内存量。
阻塞锁 | 一个进程可能正迫使另一个进程等待，因而减缓或停止阻塞进程。

请参见

监视 CPU 的使用

监视磁盘活动

监视内存的使用

SQL Server:General Statistics 对象

SQL Server:Locks 对象


确定用户活动

可以监视个别用户活动，以查明可能正阻塞其它事务的事务，或导致 Microsoft® SQL Server™ 的性能比预期的低的事务。

监视用户活动有助于识别趋势如某些用户运行的事务类型，执行低效率的特殊查询的数量，以及占用资源最多的事务类型。

若要收集有关用户的统计信息，请使用 SQL 事件探查器或系统监视器（Windows NT® 4.0 中的 Windows NT 性能监视器）。使用 SQL Server 企业管理器"当前活动"窗口对 SQL Server 执行特殊监视，这使您得以确定系统上的用户活动。

请参见

用 SQL Server 企业管理器进行监视

会话事件分类

SQL Server:General Statistics 对象


选择监视工具

Microsoft® SQL Server™ 提供一整套工具监视 SQL Server 中的事件。具体选择什么工具取决于监视类型和要监视的事件类型。例如，对于某个为确定当前连接到 SQL Server 实例的用户数而设置的特殊监视，可使用 sp_who 系统存储过程完成，而不用创建跟踪和使用 SQL 事件探查器。

SQL 事件探查器

使您能够监视服务器和数据库活动（如死锁数、严重错误、跟踪存储过程和 Transact-SQL 语句或登录活动等）。可以将 SQL 事件探查器数据捕获到 SQL Server 表或文件供以后分析，还可以逐步重播在 SQL Server 上捕获的事件以确切了解所发生的事。SQL 事件探查器跟踪引擎处理事件，如批处理或事务的开始。

系统监视器

通过使用预定义对象和计数器或用户定义的计数器监视事件，使您得以监视服务器的性能和活动。系统监视器（Microsoft Windows NT®4.0 中的性能监视器）收集事件数而不是关于事件的数据（例如内存使用、活动事务数、阻塞的锁数或 CPU 活动）。可以在特定的计数器上设置阈值以生成通知操作员的警告。系统监视器主要跟踪资源使用，如正在使用的缓冲区管理器页请求的次数。

系统监视器只在 Microsoft Windows® 2000 上工作，并且只能（远程或本地）监视 Windows NT 4.0 或 Windows 2000 上的 SQL Server 实例。

当前活动窗口（SQL Server 企业管理器）

以图形显示有关当前正在 SQL Server 实例上运行的进程、被阻塞的进程、锁和用户活动的信息。这对当前活动的特殊视图很有用。

错误日志

除了在别处可用的信息外，还包含有关 SQL Server 中的事件的额外信息。可以利用错误日志中的信息解决与 SQL Server 有关的问题。Windows 应用程序事件日志提供在 Windows NT 4.0 和 Windows 2000 系统上发生的事件，以及 SQL Server、SQL Server 代理程序和全文检索中的事件的总体描述。

sp_who

报告有关当前 SQL Server 用户和进程的快照信息，包括当前正在执行的语句以及该语句是否被阻塞。这是另一种在 SQL Server 企业管理器的当前活动窗口中查看用户活动的 Transact-SQL 方法。

sp_lock

有关锁的报表快照信息，包括对象 ID、索引 ID、锁的类型和锁应用的类型或资源。这是另一种在 SQL Server 企业管理器的当前活动窗口中查看锁活动的 Transact-SQL 方法。

sp_spaceused

显示对表（或整个数据库）所使用的当前硬盘空间量的估计。这是另一种在 SQL Server 企业管理器内查看数据库使用情况的 Transact-SQL 方法。

sp_monitor

显示统计，包括 CPU 使用、I/O 使用和自上次执行 sp_monitor 后的空闲时间。

DBCC 语句

使您能够检查性能统计和数据库的逻辑及物理一致性。有关更多信息，请参见 DBCC。

内置函数

显示自服务器启动后有关 SQL Server 活动的快照统计；这些统计存储在预定义的 SQL Server 计数器内。例如，@@CPU_BUSY 包含 CPU 一直执行 SQL Server 代码所用的时间；@@CONNECTIONS 包含 SQL Server 连接数或尝试连接数；@@PACKET_ERRORS 包含 SQL Server 连接上发生的网络数据包数。有关更多信息，请参见函数。

SQL 事件探查器存储过程和函数

使用 Transact-SQL 存储过程收集 SQL 事件探查器统计信息。有关更多信息，请参见系统存储过程。

跟踪标记

显示有关服务器内的特定活动的信息，用于诊断问题或性能问题（如死锁链）。有关更多信息，请参见跟踪标记。

简单网络管理协议 (SNMP)

简单网络管理协议 (SNMP) 是一个提供网络管理服务的应用程序协议。使用 SNMP 可以在不同的平台（例如 Windows NT 4.0、Windows 98 和 UNIX）间监视 SQL Server 实例。在 SQL Server 和 Microsoft SQL Server 管理信息库 (MSSQL-MIB) 中，可以使用 SNMP 应用程序来监视 SQL Server 的安装状态。可以监视性能信息，访问数据库，并查看服务器和数据库的配置参数。

具体选择什么监视工具取决于要监视的事件和活动的类型。

事件或活动 | SQL 事件探查器 | 系统监视器 | 当前活动窗口 | Transact-SQL | 错误日志
趋势分析 | 是 | 是 |  |  |
重播捕获的事件 | 是 |  |  |  |
特殊监视 | 是 |  | 是 | 是 | 是
生成警告 |  | 是 |  |  |
图形界面 | 是 | 是 | 是 |  | 是
在自定义应用程序内使用 | 是 1 |  |  | 是 |

1 使用 SQL 事件探查器系统存储过程。

两个主要监视工具（SQL 事件探查器和系统监视器）的主要区别是 SQL 事件探查器监视引擎事件，而系统监视器监视与服务器进程相关的资源使用。例如，SQL 事件探查器可用于监视死锁事件，包括死锁所涉及的用户和对象。系统监视器可用于监视发生在数据库内或特定对象上的死锁总数。

Windows NT 4.0 和 Windows 2000 还提供下列监视工具：

  • 任务管理器

    显示在系统上运行的进程和应用程序的提要。

  • 网络监视器代理程序

    帮助监视网络流通。

有关 Windows NT 4.0 或 Windows 2000 工具的更多信息，请参见 Windows NT 4.0 或 Windows 2000 文档。


使用 SQL 事件探查器进行监视

SQL 事件探查器是图形工具，使系统管理员得以监视 Microsoft® SQL Server™ 实例中的事件。可以捕获有关每个事件的数据并将其保存到文件或 SQL Server 表中供以后分析。例如，可以对生产环境进行监视，了解执行速度太慢而妨碍性能的存储过程。

使用 SQL 事件探查器只监视感兴趣的事件。如果跟踪变得太大，可以基于需要的信息进行筛选，以便只收集事件数据的子集。监视太多事件类会增加服务器和监视进程的开销，并且可能导致跟踪文件或跟踪表变得很大，尤其是在进行长时间监视时。

在跟踪事件后，SQL 事件探查器允许重播在 SQL Server 实例上捕获的事件数据，因此可以如事件当初发生时一样有效地重新执行保存的事件。

使用 SQL 事件探查器可以：

  • 监视 SQL Server 实例的性能。

  • 调试 Transact-SQL 语句和存储过程。

  • 识别执行慢的查询。

  • 在工程开发阶段，通过单步执行语句测试 SQL 语句和存储过程，以确认代码按预期运行。

  • 通过捕获生产系统中的事件并在测试系统中重播它们来解决 SQL Server 中的问题。这对测试和调试很有用，并使得用户可以不受干扰地继续使用生产系统。

  • 审核和复查在 SQL Server 实例中发生的活动。这使得安全管理员得以复查任何审核事件，包括登录尝试的成功与失败，以及访问语句和对象的权限成功与失败。

SQL 事件探查器为用于监视 SQL Server 实例的一组存储过程提供图形用户界面。例如，可以创建您自己的应用程序，以便使用 SQL 事件探查器存储过程监视 SQL Server。

必须有至少 10 MB 的可用空间用以运行 SQL 事件探查器。当使用 SQL 事件探查器时，如果可用空间降至 10 MB 以下，SQL 事件探查器的所有功能都将停止。

启动 SQL 事件探查器

SQL 事件探查器从 Microsoft® Windows NT® 4.0、Microsoft Windows® 2000 或 Microsoft Windows 98 的"开始"菜单或从 SQL Server 企业管理器启动。

使用 Windows 身份验证模式时，必须授予运行 SQL 事件探查器的用户帐户权限，用以连接到 SQL Server 实例。还必须授予登录帐户执行 SQL 事件探查器存储过程的权限。有关更多信息，请参见系统存储过程。

启动 SQL 事件探查器

企业管理器

企业管理器

请参见

SQL 事件探查器术语

系统存储过程


SQL 事件探查器键盘快捷方式

下表显示 SQL 事件探查器中可用的键盘快捷方式。

CTRL+Shift+Delete 组合键 | 清除跟踪窗口
CTRL+F4 | 关闭跟踪窗口
- | 折叠跟踪分组
CTRL+C 键 | 复制
ALT+Delete 组合键 | 删除跟踪
+ | 展开跟踪分组
CTRL+F | 查找
F3 功能键 | 查找下一项
Shift+F3 | 查找前一项
F1 功能键 | 显示可用的帮助
CTRL+N | 打开新跟踪
ALT+F7 | 重播设置
CTRL+F10 | 运行到游标处
F5 功能键 | 开始重播
F11 功能键 | 步骤
Shift+F5 | 停止重播
F9 功能键 | 切换断点


SQL 事件探查器术语

若要使用 SQL 事件探查器，需要了解描述工具功能的术语。例如，创建模板来定义要收集的数据。通过在模板中所定义的事件上运行跟踪来收集这些数据。当运行跟踪时，描述事件数据的事件类和数据列显示在 SQL 事件探查器中。

模板

模板定义想要使用 SQL 事件探查器监视的每个事件的准则。例如，可以创建一个模板以指定使用哪些事件、数据列和筛选。然后可以保存该模板，并用当前的模板设置启动跟踪。捕获的跟踪数据基于模板中指定的选项。模板不执行且必须用 .tdf 扩展名保存到文件。

跟踪

跟踪基于选定的事件、数据列和筛选捕获数据。例如，可创建模板监视异常错误。为此，应选择跟踪 Exception 事件类以及 Error、State 和 Severity 数据列，这些都是为了使跟踪结果提供有意义的数据而需收集的。保存模板后，便可将其作为跟踪运行，并且可收集关于服务器中发生的任何 Exception 事件的数据。可保存此跟踪数据，然后稍后重播或立即用于分析。

筛选

  • 当创建跟踪或模板时，可以定义筛选由事件收集的数据的准则。如果跟踪变得太大，可以基于想要的信息进行筛选，以便只收集事件数据的子集。如果没有设置筛选，跟踪输出中将返回选定事件类的所有事件。例如，可以将跟踪中的 Microsoft Windows® 2000 用户名限制为特定用户，以将输出数据减少到感兴趣的那些用户。
事件分类

事件分类定义事件的分组方法。例如，所有锁事件类都在锁事件分类内分组。但是，事件分类只存在于 SQL 事件探查器中。该术语不反映引擎事件的分组方法。

事件

事件是在 Microsoft® SQL Server™ 引擎中生成的操作。例如：

  • 登录连接、失败和断开。

  • Transact-SQL SELECT、INSERT、UPDATE 和 DELETE 语句。

  • 远程过程调用 (RPC) 批处理状态。

  • 存储过程的开始或结束。

  • 存储过程内的语句的开始或结束。

  • SQL 批处理的开始或结束。

  • 写入 SQL Server 错误日志的错误。

  • 在数据库对象上获取或释放的锁。

  • 打开的游标。

  • 安全权限检查。

由事件生成的所有数据显示在单个行中的跟踪内 。该行包含详细描述事件的数据列，称为事件类。

事件类

事件类是描述由服务器生成的事件的列。事件类确定收集的数据类型，因此并不是所有数据列都适用于所有事件类。事件类示例包括：

  • SQL:BatchCompleted，表示已完成 SQL 批处理。

  • 运行客户端的计算机的名称。

  • 受事件影响的对象 ID（如表名）。

  • 发出语句的用户的 SQL Server 名称。

  • 正在执行的 Transact-SQL 语句文本或存储过程文本。

  • 事件开始和结束的时间。
数据列

数据列描述为跟踪内捕获的每个事件类所收集的数据。事件类确定收集的数据类型，因此并不是所有数据列都适用于所有事件类。例如，为 Lock:Acquired 事件类捕获 Binary Data 数据列时，该数据列包含锁定的页 ID 或行的值，但没有 Integer Data 事件类的值。对于所有事件类，默认数据列均为自动填充。


SQL 事件探查器方案

通常情况下，使用 SQL 事件探查器可以：

  • 查找执行最差的查询

    例如，可以创建跟踪来捕获与 TSQL 和 Stored Procedure 事件类（尤其是 RPC:Completed 和 SQL:BatchCompleted）相关的事件。在这个跟踪内包含所有数据列，按 Duration 分组并指定事件准则。例如，如果指定事件的 Duration 至少为 1,000 毫秒，则可以跟踪中排除运行时间短的事件。根据需要可以增大 Duration 的最小值。如果想一次只监视一个数据库，为 Database ID 事件准则指定一个值。

  • 识别死锁原因

    例如，可以创建一个跟踪来捕获与 TSQL 和 Stored Procedure 事件类（RPC:Starting 和 SQL:BatchStarting）以及 Locks 事件类（Lock:Deadlock 和 Lock:Deadlock Chain）相关的事件。在这个跟踪内包括所有数据列并按 Event Class 分组。如果想一次只监视一个数据库，为 Database ID 事件准则指定一个值。

    若要查看死锁所涉及的连接，执行下列操作之一：

    • 打开包含捕获的数据的跟踪，按 ClientProcessID 将数据分组并展开死锁所涉及的两个连接。

    • 将捕获的数据保存到一个跟踪文件，然后打开这个跟踪文件两次，使其显示在两个单独的 SQL 事件探查器窗口内。按 ClientProcessID 将捕获的数据分组，然后展开死锁所涉及的进程 ID；每个死锁连接都在一个单独的窗口内。平铺窗口以查看导致死锁的事件。
  • 监视存储过程的性能

    例如，可以创建一个跟踪来捕获与 Stored Procedure 事件类（SP:Completed、SP:Starting、SP:StmtCompleted 和 SP:StmtStarting）和 TSQL 事件类（SQL:BatchStarting 和 SQL:BatchCompleted）相关的事件。在这个跟踪内包含所有数据列并按 ClientProcessID 分组。如果想一次只监视一个数据库，为 Database ID 事件准则指定一个值。同样，如果想一次只监视一个存储过程，为 Object ID 事件准则指定一个值。

  • 审核 Microsoft® SQL Server™ 活动

可以使用 SQL 事件探查器审核 SQL Server 中的活动。例如，如果安全管理员需要随时了解谁登录到了服务器，可以创建 SQL 事件探查器跟踪，提供已登录到服务器或从服务器注销的用户的完整视图。之后，可出于法律目的使用这些信息记录活动，和出于技术目的使用这些信息跟踪违反安全策略的行为。

若要设置 SQL 事件探查器跟踪来跟踪已登录到服务器或从服务器注销的用户，请执行下列操作：

  1. 创建跟踪并选择 Audit Login Event。

  2. 若要返回适当的信息，请指定下列数据列：

    EventClass（默认情况下选定）

    EventSubClass

    LoginSID

    LoginName

  • 监视每个用户的 Transact-SQL 活动。

    可以创建跟踪来捕获与 Sessions 事件类、ExistingConnection 和 TSQL 事件类相关的事件。将所有数据列包含在此跟踪内，不要指定任何事件准则，并按 DBUserName 将捕获的事件分组。

请参见

锁事件分类

会话事件分类

存储过程事件类

TSQL 事件分类


使用 SQL 事件探查器监控事件分类

在 SQL 事件探查器中使用事件分类监视 Microsoft® SQL Server™ 中的事件。事件分类包含已在 SQL 事件探查器用户界面内进行分组的事件类。有关更多信息，请参见 SQL 事件探查器术语。

下表描述 SQL 事件探查器事件分类及其相关的事件类。

事件分类 | 描述
游标 | 游标操作产生的事件类集合。
数据库 | 数据或日志文件自动增长或收缩时产生的事件类集合。
错误和警告 | 发生 SQL Server 错误或警告（例如，编译存储过程时发生的错误或 SQL Server 中的异常错误）时产生的事件类集合。
锁 | 获取、取消或释放锁等时产生的事件类集合。
对象 | 创建、打开、关闭、除去或删除数据库对象时产生的事件类集合。
性能 | 执行 SQL 数据操作语言 (DML) 运算符时产生的事件类集合。
扫描 | 扫描表和索引时产生的事件类集合。
安全审核 | 用于审核服务器活动的事件类集合。
会话 | 由连接到 SQL Server 实例的客户端和断开与 SQL Server 实例的连接的客户端产生的事件类集合。
存储过程 | 执行存储过程所产生的事件类集合。
事务 | 执行 Microsoft 分布式事务处理协调器 (MS DTC) 事务，或写入事务日志所产生的事件类集合。
TSQL | 执行从客户端传递到 SQL Server 实例的 Transact-SQL 语句所产生的事件类集合。
用户可配置 | 用户可配置的事件类集合。


SQL 事件探查器事件类

在 SQL 事件探查器中，事件类是描述正在跟踪的事件的行。在 SQL 事件探查器中，事件类在事件分类内分组。例如，所有锁事件类都在 Locks 事件分类内分组。有关更多信息，请参见 SQL 事件探查器术语。


SQL 事件探查器默认事件类

创建新跟踪后，用一组默认事件类定义新跟踪。创建新跟踪时可以删除这些事件类和添加其它事件类。除非显式删除，否则每次创建新跟踪时都会出现默认事件类。

下面是新跟踪的默认事件类。

默认事件类 | 描述
Audit Login Event | 收集自跟踪启动后发生的所有新的连接事件，例如客户端请求连接到运行 Microsoft® SQL Server™ 实例的服务器。
Audit Logout Event | 收集自跟踪启动后发生的所有新的断开连接事件，例如客户端发出断开连接命令。
ExistingConnection | 检测在启动跟踪之前连接到 SQL Server 实例的所有用户活动。
RPC:Completed | 表明已完成远程过程调用 (RPC)。
SQL:BatchCompleted | 表明完成 Transact-SQL 批处理。

请参见

创建并管理跟踪和模板


SQL 事件探查器数据列

SQL 事件探查器使您得以在创建模板时选择数据列。这些数据列表现在运行跟踪时希望返回的信息。在 SQL 事件探查器中显示的数据可以按事件发生的顺序显示，也可以按一个数据列或数据列组合分组显示。

例如，若要识别执行时间最长的用户事件，请按 DBUserName 和 Duration 对事件进行分组。SQL 事件探查器将显示每个事件的执行时间。该功能类似于 Transact-SQL 中的 GROUP BY 子句。有关更多信息，请参见 GROUP BY。

说明 不能按 StartTime 或 EndTime 数据列进行分组。

如果 SQL 事件探查器可以连接到捕获跟踪数据时所在的 Microsoft® SQL Server™ 实例，则将尝试用数据库、对象和索引的名称分别填充 Database ID、Object ID 和 Index ID 数据列。否则，将显示标识号 (ID)。

下表描述默认情况下选定的 SQL 事件探查器数据列。

数据列 | 列号 | 描述
Application Name1 | 10 | 创建与 SQL Server 实例的连接的客户端应用程序名。 该列由应用程序传递的值填充，而不是由所显示的程序名填充。
Binary Data | 2 | 与在跟踪中捕获的事件类相关的二进制值。
ClientProcessID1 | 9 | 由主机计算机分配给进程的 ID，在该进程中客户应用程序正在运行。如果客户端提供客户端进程 ID，则填充此数据列。
Column Permissions | 44 | 表明是否已设置了列权限。分析语句文本，以确定将哪些权限应用到了哪些列。
CPU | 18 | 事件所使用的 CPU 时间总计（以毫秒为单位）。
Database ID1 | 3 | USE database 语句所指定的数据库 ID，如果没有对给定实例发出过 USE database 语句，则是默认数据库。如果在跟踪内捕获 Server Name 数据列且服务器可用，则 SQL 事件探查器将显示数据库名。 通过使用 DB_ID 函数确定数据库的值。
DatabaseName | 35 | 正在运行用户语句的数据库的名称。
DBUserName1 | 40 | 客户端的 SQL Server 用户名。
Duration | 13 | 事件所花费的时间总计（以毫秒为单位）。
End Time | 15 | 事件结束时的时间。启动事件的事件类（如 SQL:BatchStarting 或 SP:Starting）的该列不填充。
Error | 31 | 给定事件的错误号。通常是存储在 sysmessages 中的错误号。
EventClass1 | 27 | 捕获的事件类类型。
EventSubClass1 | 21 | 事件子类的类型，提供有关每个事件类的进一步信息。例如，Execution Warning 事件类的事件子类值代表执行警告的类型： 1 = 查询等待。查询必须等待资源（如内存）才能执行。 2 = 查询超时。查询在等待执行所需的资源时超时。所有事件类的该数据列均不填充。
FileName | 36 | 所修改的文件的逻辑名称。
Handle | 33 | ODBC、OLE DB 或 DB-Library 所用的整数，用以协调服务器的执行。
Host Name1 | 8 | 正运行客户端的计算机名。如果客户端提供主机名，则填充此数据列。若要确定主机名，请使用 HOST_NAME 函数。
Index ID | 24 | 受事件影响的对象上的索引 ID。若要确定对象的索引 ID，请使用 sysindexes 系统表的 indid 列。
Integer Data | 25 | 与在跟踪中捕获的事件类相关的整型值。
LoginName | 11 | 用户的登录名（SQL Server 安全登录或 Microsoft Windows® 登录凭据，格式为 DOMAIN\Username）。
LoginSid1 | 41 | 登录用户的安全标识号 (SID)。可以在 master 数据库的 sysxlogins 表中找到该信息。对于服务器中的每个登录，SID 是唯一的。
Mode | 32 | 不同事件所用的整数，用于描述事件已接收或要请求的状态。
NestLevel | 29 | 表示 @@NESTLEVEL 所返回的数据的整数。
NT Domain Name1 | 7 | 用户所属的 Microsoft Windows NT® 4.0 或 Windows 2000 域。
NT User Name1 | 6 | Windows NT 4.0 或 Windows 2000 用户名。
Object ID | 22 | 系统分配的对象 ID。
ObjectName | 34 | 引用的对象名。
ObjectType | 28 | 表示事件中涉及的对象类型的值。该值对应于 sysobjects 中的 type 列。
Owner Name | 37 | 对象所有者的数据库用户名称。
Permissions | 19 | 表示所检查的权限类型的整型值。取值为： 1 = SELECT ALL 2 = UPDATE ALL 4 = REFERENCES ALL 8 = INSERT 16 = DELETE 32 = EXECUTE（仅限于过程） 4096 = SELECT ANY （至少一列） 8192 = UPDATE ANY 16384 = REFERENCES ANY
Reads | 16 | 服务器代表事件执行的逻辑磁盘读取数。
RoleName | 38 | 要启用的应用程序角色名。
Server Name1 | 26 | 跟踪的 SQL Server 实例名。
Severity | 20 | 异常错误的严重级别。
SPID1 | 12 | SQL Server 指派的与客户端相关的服务器进程 ID。
Start Time1 | 14 | 启动事件的时间（可用时）。
State | 30 | 等同于错误状态代码。
Success | 23 | 表示事件是否成功。取值包括： 1 = 成功。 0 = 失败 例如，1 表示权限检查成功，0 表示该检查失败。
TargetLoginName | 42 | 对于以登录为目标的操作（例如，添加新登录），是目标登录的名称。
TargetLoginSid | 43 | 对于以目标为登录的操作（例如，添加新登录），是目标登录的 SID。
TargetUserName | 39 | 对于以数据库用户为目标的操作（例如授予用户权限），是该用户的名称。
TextData | 1 | 与跟踪内捕获的事件类相关的文本值。但是，如果正在跟踪参数化查询，则不以 TextData 列中的数据值显示变量。
Transaction ID | 4 | 系统分配的事务 ID。
Writes | 17 | 服务器代表事件执行的物理磁盘写入数。

1 默认情况下，为所有事件填充这些数据列。


游标事件分类

使用游标事件分类监视游标操作。通过监视 CursorOpen、CursorExecute 和 CursorImplicitConversion 事件类，可以确定游标的执行时间和使用的游标类型。跟踪特定事件类对于确定 Microsoft® SQL Server™ 实例在操作时使用的实际游标类型，而不是由应用程序指定的游标类型很有用。

请参见

游标事件类

游标数据列


游标事件类

下表描述游标事件分类中的游标事件类。

事件类 | 描述
CursorClose | 关闭先前由 ODBC、OLE DB 或 DB-Library 在 Transact-SQL 语句上打开的游标。
CursorExecute | 执行先前由 ODBC、OLE DB 或 DB-Library 在 Transact-SQL 语句上准备的游标。有关更多信息，请参见如何准备和执行语句 (ODBC)。
CursorImplicitConversion | Transact-SQL 语句上的游标由 Microsoft® SQL Server™ 从一种类型转换到另一种类型。 为 ANSI 和非 ANSI 游标触发。
CursorOpen | ODBC、OLE DB 或 DB-Library 在 Transact-SQL 语句上打开游标。
CursorPrepare | ODBC、OLE DB 或 DB-Library在 Transact-SQL 语句上准备好游标以供使用。有关更多信息，请参见如何准备和执行语句 (ODBC)。
CursorRecompile | 由 ODBC 或 DB-Library 在 Transact-SQL 语句上打开的游标由于架构更改已直接或间接重新编译。 为 ANSI 和非 ANSI 游标触发。
CursorUnprepare | ODBC、OLE DB 或 DB-Library 删除在 Transact-SQL 语句上准备好的游标。

请参见

游标事件分类

游标数据列


游标数据列

下表列出游标事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
CursorClose | Event Class | 记录的事件类型 = 78。
 | Handle | 游标句柄。
CursorExecute | Event Class Handle Integer Data | 记录的事件类型 = 74。 游标句柄。 游标类型。取值为： 1 = 键集 2 = 动态 4 = 只进 8 = 静态 16 = 快进
CursorImplicitConversion | Event Class | 记录的事件类型 = 76。
 | Handle | 游标句柄。
 | Integer Data | 请求的游标类型。取值为： 1 = 键集 2 = 动态 4 = 只进 8 = 静态 16 = 快进
 | Binary Data | 所得的游标类型。取值为： 1 = 键集 2 = 动态 4 = 只进 8 = 静态 16 = 快进
CursorOpen | Event Class Handle Integer Data | 记录的事件类型 = 53。 游标句柄。 游标类型。取值为： 1 = 键集 2 = 动态 4 = 只进 8 = 静态 16 = 快进
CursorPrepare | Event Class | 记录的事件类型 = 70。
 | Handle | 已准备的游标句柄。
CursorRecompile | Event Class Handle | 记录的事件类型 = 75。 必须重新编译的游标句柄。
CursorUnprepare | Event Class Event Sub Class | 记录的事件类型 = 77。 CursorPrepare 创建的游标句柄。

请参见

游标

游标事件类

游标事件分类


数据库事件分类

使用数据库事件分类监视数据或日志文件何时自动增长或收缩。

请参见

数据库事件类

数据库数据列


数据库事件类

下表描述数据库事件分类中的数据库事件类。

事件类 | 描述
DataFileAutoGrow | 表示数据文件自动增长。如果通过 ALTER DATABASE 使数据文件显式增长，则不会触发该事件。
DataFileAutoShrink | 表明数据文件已收缩。
LogFileAutoGrow | 表示日志文件自动增长。如果通过 ALTER DATABASE 使日志文件显式增长，则不会触发该事件。
LogFileAutoShrink | 表明日志文件已收缩。

请参见

数据库事件分类

数据库数据列


数据库数据列

下面列出数据库事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
Data File Auto Grow | Event Class | 记录的事件类型 = 92。
 | End Time | 数据文件自动增长的结束时间。
 | Duration | 扩展文件所需的时间长度（以毫秒为单位）。
 | File Name | 扩展的文件的逻辑名称。
 | Integer Data | 文件增加所基于的 8 KB 页数。
Data File Auto Shrink | Event Class | 记录的事件类型 = 94。
 | End Time | 自动收缩的结束时间。
 | Duration | 收缩文件的时间（以毫秒为单位）。
 | File Name | 收缩的文件的逻辑名称。
 | Integer Data | 文件减小所基于的 8 KB 页数。
Log File Auto Grow | Event Class | 记录的事件类型 = 93。
 | End Time | 日志文件自动增长的结束时间。
 | Duration | 扩展文件所需的时间（以毫秒为单位）。
 | File Name | 扩展的文件的逻辑名称。
 | Integer Data | 文件增加所基于的 8 KB 页数。
Log File Auto Shrink | Event Class | 记录的事件类型 = 95。
 | End Time | 日志文件自动收缩的结束时间。
 | Duration | 收缩文件所需的时间（以毫秒为单位）。
 | File Name | 收缩的文件的逻辑名称。
 | Integer Data | 文件减小所基于的 8 KB 页数。

请参见

数据库事件分类

数据库事件类


错误和警告事件分类

使用错误和警告事件分类监视由 Microsoft® SQL Server™ 及其组件（如 OLE DB）产生的许多错误和警告。通常使用下列事件类查找在运行应用程序或执行过程时可能遇到的问题。

请参见

错误和警告事件类

错误和警告数据列


错误和警告事件类

下表描述错误和警告事件分类中的错误和警告事件类。

事件类 | 描述
Attention | 收集所有提示事件，如客户端中断请求或当客户端连接中断时。
ErrorLog | 错误事件已记入 Microsoft® SQL Server™ 错误日志。
EventLog | 事件已记入 Microsoft Windows® 应用程序日志。
Exception | SQL Server 中发生异常错误。
Execution Warnings | 在执行 SQL Server 语句或存储过程时出现的任何警告。
Hash Warning | 哈希操作可能遇到了问题。
Missing Column Statistics | 查询优化器的列统计不可用。
Missing Join Predicate | 执行查询时没有联接谓词。这可能会导致查询长时间运行。
OLEDB Errors | 发生 OLE DB 错误。
Sort Warnings | 排序操作不适合内存条件。不包括涉及索引创建的排序操作，只包括查询内的排序操作（例如 SELECT 语句中使用的 ORDER BY 子句）。

可以监视 ExecutionＷarnings 事件类，以确定如果查询在继续之前必须等待资源，则需等多久。这对于确定系统内是否有任何会影响性能并因此需要调查的争夺资源问题很重要。使用 Locks 事件类确定受影响的对象。

可以使用 Hash Warning 事件类监视在执行哈希操作时何时发生哈希递归或哈希解扣。当生成输入不适合内存条件时会发生哈希递归，导致输入分成多个分区分别进行处理。如果这些分区中任何一个仍然不适合内存条件，则将进一步分成子分区，然后分别进行处理。这一进程将持续到每个分区都适合内存条件或到达最大递归级别（在 Integer Data 数据列中显示），从而导致发生哈希解扣。

当哈希操作到达最大递归深度并还原到可选计划以处理剩余的分区数据时，发生哈希解扣。通常由于扭曲的数据、跟踪标记或位计数而发生哈希解扣。若要消除或减少哈希解扣的发生，请验证正在联接或分组的列上是否存在统计。有关更多信息，请参见统计信息。

如果每次执行查询时继续发生哈希解扣，可考虑使用优化程序提示，强制查询优化器使用不同的算法，然后比较查询性能。有关联接提示的更多信息，请参见 FROM。

通过监视 Missing Column Statistics 事件类，可以确定是否缺少查询所使用的列的统计。缺少统计会导致优化程序选择效率不高的查询计划。有关创建列统计的更多信息，请参见统计信息。

可以使用 Sort Warnings 事件类监视查询性能。如果涉及排序操作的查询生成 Event Sub Class 数据列值为 2 的 Sort Warnings 事件类，需要多次传递数据才能排序数据，因此可能会影响查询性能。进一步调查查询以确定是否可以消除排序操作。

请参见

错误和警告事件分类

错误和警告数据列


错误和警告数据列

下面是错误和警告事件分类中每个事件的数据列。

事件类 | 数据列 | 描述
提示 | Event Class | 记录的事件类型 = 16。
ErrorLog | Event Class | 记录的事件类型 = 22。
 | Error | 错误号。
 | Severity | 生成的错误的严重度。
 | Text Data | 错误信息文本。
EventLog | Event Class | 记录的事件类型 = 21。
 | Binary Data | 与在跟踪中捕获的事件类相关的二进制值。
 | Error | 错误号。
 | Severity | 错误严重度。
 | Text Data | 错误信息文本（若有）。
Exception | Event Class | 记录的事件类型 = 33。
 | Error | 错误号。
 | State | 服务器状态。
 | Severity | 错误严重度。
Execution Warnings | Event Class | 记录的事件类型 = 67。
 | Event Sub Class | 执行警告的类型。可以有下列值： 1 = 查询等待。查询必须等待资源（如内存）才能执行。 2 = 查询超时。查询在等待执行所需的资源时超时。
 | Error | 错误号。
Hash Warning | Event Class | 记录的事件类型 = 55。
 | Event Sub Class | 哈希操作的类型。可以有下列值： 0 = 哈希递归。 1 = 哈希解扣。
 | Integer Data | 递归级数（仅限于哈希递归）。
 | Object ID | 重新分区所涉及的哈希的根节点 ID。
Missing Column Statistics | Event Class | 记录的事件类型 = 79。
 | Text Data | 缺少统计的数据列列表。
Missing Join Predicate | Event Class | 记录的事件类型 = 80。
OLEDB Errors | Event Class | 记录的事件类型 = 61。
 | Text Data | 来自 OLE DB 的错误信息。
Sort Warnings | Event Class | 记录的事件类型 = 69。
 | Event Sub Class | 排序警告的类型。可以有下列值： 1 = 单次传递。将排序表写入磁盘时，只需再传递一次要排序的数据即可获得排序输出。 2 = 多次传递。将排序表写入磁盘时，必须多次传递要排序的数据才能获得排序输出。

请参见

错误信息

监视错误日志

错误和警告事件类

错误和警告事件分类


锁事件分类

使用锁事件分类监视 Microsoft® SQL Server™ 锁活动。通过监视锁事件类，可调查由并发使用数据库的用户和应用程序导致的争夺问题。

由于锁事件太多，捕获锁事件类可能会在所跟踪的服务器上招致重大的开销，并产生很大的跟踪文件或跟踪表。

请参见

锁事件类

锁数据列


锁事件类

下表描述锁事件分类中的锁事件类。

事件类 | 描述
Lock:Acquired | 已为资源（如数据页）获取锁。有关可锁定的资源的更多信息，请参见SQL Server 中的锁定介绍。
Lock:Cancel | 已取消为资源获取的锁（如由于死锁）。
Lock:Deadlock | 两个并发事务试图为对方拥有的资源获取不兼容的锁，致使它们相互死锁。有关更多信息，请参见死锁。
Lock:Deadlock Chain | 为每个会导致死锁的事件而产生的事件。
Lock:Escalation | 已由较精细的锁转换成较粗糙的锁（如由行锁转换成页锁）。
Lock:Released | 已释放资源（如页）上的锁。
Lock:Timeout | 对资源（如页）加锁的请求因另一个事务在所需资源上加有阻塞锁而超时。超时由 @@LOCK_TIMEOUT 系统函数决定，可用 SET LOCK_TIMEOUT 语句设置。有关更多信息，请参见自定义锁超时。

可以使用 Lock:Acquired 和 Lock:Released 事件类监视对象的锁定时间、所采用的锁类型以及锁保留了多长时间。长时间保留锁会导致争夺问题，应对此进行调查。例如，应用程序可以为表中的行获取锁，然后等待用户输入。由于用户输入可能要花很长时间，锁将阻塞其他用户。在这种情况下，应重新设计应用程序，使得只在需要时才请求锁，且在获取锁后不需要用户输入。

可以使用 Lock:Deadlock、Lock:Deadlock Chainn 和 Lock:Timeout 事件类监视死锁和超时情况发生的时间以及所涉及的对象。此信息有助于确定死锁和超时是否对应用程序的性能造成重大影响，以及涉及哪些对象。然后可以检查能够修改这些对象的应用程序代码，确定能否进行更改以将死锁和超时减到最少。有关减少死锁的更多信息，请参见避免死锁。

请参见

锁事件分类

锁数据列


锁数据列

下表列出锁事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
Lock:Acquired | Event Class | 记录的事件类型 = 24。
 | Mode | 获取的锁的锁模式，如意向排它。
 | Binary Data | 资源类型。
 | End Time | 事件的结束时间。
 | Duration | 发出锁请求和获取锁之间的等待时间。
 | Object ID | 锁已获取的对象 ID。
 | Index ID | 如果对象锁在索引上，则是索引 ID。
Lock:Cancel | Event Class | 记录的事件类型 = 26。
 | Mode | 取消的锁模式。
 | Binary Data | 资源类型。
 | End Time | 事件的结束时间。
 | Duration | 发出锁请求和取消锁之间的等待时间。
 | Object ID | 锁已取消的对象 ID。
 | Index ID | 如果对象锁在索引上，则是索引 ID。
Lock:Deadlock | Event Class | 记录的事件类型 = 25。
 | Mode | 触发死锁的锁模式。
 | Binary Data | 资源类型。
 | End Time | 死锁的结束时间。
 | Integer Data | 死锁编号。从服务器启动时起，从 0 开始按递增顺序指派每个死锁的编号。
 | Duration | 发出锁请求和发生死锁之间的等待时间。
 | Object ID | 争夺中的对象 ID。
 | Index ID | 如果对象锁在索引上，则是索引 ID。
Lock:Deadlock Chain | Event Class | 记录的事件类型 = 59。
 | Mode | 死锁链中的每个锁的锁模式。
 | Binary Data | 资源类型。
 | Integer Data | 死锁编号。从服务器启动时起，从 0 开始按递增顺序指派每个死锁的编号。
 | Object ID | 锁定的对象 ID。
 | Index ID | 如果对象锁在索引上，则是索引 ID。
Lock:Escalation | Event Class | 记录的事件类型 = 60。
 | Object ID | 锁已升级的对象 ID。
 | Index ID | 如果对象锁在索引上，则是索引 ID。
 | Mode | 升级后的锁模式。
Lock:Released | Event Class | 记录的事件类型 = 23。
 | Binary Data | 资源类型。
 | End Time | 事件的结束时间。
 | Duration | 发出锁请求和释放锁之间的等待时间。
 | Object ID | 锁已释放的对象 ID。
 | Index ID | 如果对象锁在索引上，则是索引 ID。
Lock:Timeout | Event Class | 记录的事件类型 = 27。
 | Mode | 已超时的请求锁的锁模式。
 | Binary Data | 资源类型。
 | End Time | 事件的结束时间。
 | Duration | 发出锁请求和释放锁之间的等待时间。
 | Object ID | 锁已超时的对象 ID。
 | Index ID | 如果对象锁在索引上，则是索引 ID。

请参见

锁定

锁事件分类

锁事件类


对象事件分类

使用对象事件类监视何时打开、创建、删除或使用对象（例如，数据库、表、索引、视图或存储过程）。

由于对象事件太多，捕获对象事件类可能会在所跟踪的服务器上招致重大的开销，并产生很大的跟踪文件或跟踪表。

请参见

对象事件类

对象数据列


对象事件类

下表描述对象事件分类中的对象事件类。

事件类 | 描述
Auto Stats | 表示发生自动创建和更新统计的时间。
Object: Closed | 表示打开的对象的关闭时间，例如在 SELECT、INSERT 或 DELETE 语句结束时。
Object: Created | 已创建对象，例如对于 CREATE INDEX、CREATE TABLE 和 CREATE DATABASE 语句。
Object: Deleted | 已删除对象，例如对于 DROP INDEX 和 DROP TABLE 语句。
Object: Opened | 表示访问对象的时间，例如对于 SELECT、INSERT 或 DELETE 语句。

可以使用 Object:Created 和 Object:Deleted 事件类确定是否正创建或删除（例如，通过经常创建临时存储过程的 ODBC 应用程序）很多特殊对象。通过除监视 Objects 事件类外还监视 DBUserName 和 NT User Name 默认数据列，可以确定正创建、删除或访问对象的用户名。这可用于确定是否正确实现了安全策略，例如，可以确认无权创建或删除对象的用户没有执行这些操作。

请参见

对象事件分类

对象数据列


对象数据列

下表列出对象事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
Auto Stats | Event Class | 记录的事件类型 = 58。
Object: Created | Event Class | 记录的事件类型 = 46。
 | Object Type | 创建的对象类型。
 | Object Name | 创建的对象名。
 | Object ID | 创建的对象 ID。
 | Index ID | 如果创建了索引，则是索引 ID。
Object: Deleted | Event Class | 记录的事件类型 = 47。
 | Object Type | 删除的对象类型。
 | Object Name | 删除的对象名。
 | Object ID | 删除的对象 ID。
 | Index ID | 如果删除了索引，则是索引 ID。

请参见

创建和维护数据库概述

对象事件分类

对象事件类


性能事件分类

使用性能事件分类监视显示计划事件类和由执行 SQL 数据操作语言 (DML) 运算符所产生的事件类。

请参见

性能事件类

性能数据列


性能事件类

下表描述性能事件分类中的性能事件类。

事件类 | 描述
Degree Of Parallelism11 | 描述分配给 SQL 语句的并行度。在执行 SELECT、INSERT、UPDATE 或 DELETE 语句之前发生。如果正在跟踪 Microsoft® SQL Server™ 7.0 版服务器，则该事件将跟踪 INSERT 语句。
Degree of Parallelism21 | 描述分配给 SQL 语句的并行度。在执行 SELECT、INSERT、UPDATE 或 DELETE 语句之前发生。如果跟踪 SQL Server 7.0 服务器，则该事件将跟踪 UPDATE 语句。
Degree of Parallelism31 | 描述分配给 SQL 语句的并行度。在执行 SELECT、INSERT、UPDATE 或 DELETE 语句之前发生。如果跟踪 SQL Server 7.0 服务器，则该事件将跟踪 DELETE 语句。
Degree of Parallelism41 | 描述分配给 SQL 语句的并行度。在执行 SELECT、INSERT、UPDATE 或 DELETE 语句之前发生。如果跟踪 SQL Server 7.0 服务器，则该事件将跟踪 SELECT 语句。
Execution Plan | 显示正在执行的 SQL 语句的计划树。
Show Plan All | 用正在执行 SQL 语句的完整的编译时细节显示查询计划（例如，预算成本和列列表）。
Show Plan Statistics | 用已执行 SQL 语句的完整的运行时细节显示查询计划（包括通过每次操作的实际行数）。
Show Plan Text | 显示正在执行的 SQL 语句的查询计划树。

1 如果正在跟踪 SQL Server 2000 服务器，则该事件将跟踪 SELECT、INSERT、UPDATE 或 DELETE 语句。

请参见

性能事件分类

性能数据列


性能数据列

下表列出性能事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
Degree of Parallelism1 | Event Class | 记录的事件类型 = 28。
 | Event Sub Class | 如果正在跟踪 Microsoft® SQL Server™ 2000 服务器，则 Event Sub Class 可以有下列反映语句类型的值： 1 = 选择 2 = 插入 3 = 更新 4 = 删除
 | Binary Data | 提供的二进制数据，是用于执行语句的 CPU 数。
 | Integer Data | 内存中用于查询计划的页数。
Degree of Parallelism2 | Event Class | 记录的事件类型 = 28。
 | Event Sub Class | 如果正在跟踪 SQL Server 2000 服务器，则 Event Sub Class 可以有下列反映语句类型的值： 1 = 选择 2 = 插入 3 = 更新 4 = 删除
 | Binary Data | 提供的二进制数据，是用于执行语句的 CPU 数。
 | Integer Data | 内存中用于查询计划的页数。
Degree of Parallelism3 | Event Class | 记录的事件类型 = 28。
 | Event Sub Class | 如果正在跟踪 SQL Server 2000 服务器，则 Event Sub Class 可以有下列反映语句类型的值： 1 = 选择 2 = 插入 3 = 更新 4 = 删除
 | Binary Data | 提供的二进制数据，是用于执行语句的 CPU 数。
 | Integer Data | 内存中用于查询计划的页数。
Degree of Parallelism4 | Event Class | 记录的事件类型 = 28。
 | Event Sub Class | 如果正在跟踪 SQL Server 2000 服务器，则 Event Sub Class 可以有下列反映语句类型的值： 1 = 选择 2 = 插入 3 = 更新 4 = 删除
 | Binary Data | 提供的二进制数据，是用于执行语句的 CPU 数。
 | Integer Data | 内存中用于查询计划的页数。
Execution Plan | Event Class | 记录的事件类型 = 68。
 | Binary Data | 执行计划的预计成本。
 | Object ID | 已更新统计的对象 ID。
 | Integer Data | 返回的行数
 | Text Data | 执行计划树。只表示 SQL 语句。不表示 Transact-SQL 构造。
Show Plan All | Event Class | 记录的事件类型 = 97。
 | Binary Data | 查询的预计成本。
 | Integer Data | 预期返回的行数。
 | Text Data | 语句的 Showplan ALL 结果。
Show Plan Statistics | Event Class | 记录的事件类型 = 98。
 | Binary Data | 查询的预计成本。
 | Integer Data | 预期返回的行数。
 | Text Data | 语句的 Showplan Statistics 结果。
Show Plan Text | Event Class | 记录的事件类型 = 96。
 | Binary Data | 查询的预计成本。
 | Integer Data | 预期返回的行数。
 | Text Data | 语句的 Showplan Text 结果。

请参见

性能事件分类

性能事件类


扫描事件分类

使用扫描事件类在查询执行过程中对表或索引扫描时进行监视。

使用 Scan:Started 和 Scan:Stopped 事件类时，可以监视正由特定对象上的查询执行的扫描类型。

请参见

扫描事件类

扫描数据列


扫描事件类

下表描述扫描事件分类中的扫描事件类。

事件类 | 描述
Scan: Started | 表或索引扫描已启动。
Scan: Stopped | 表或索引扫描已停止。

请参见

扫描事件分类

扫描数据列


扫描数据列

下表列出扫描事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
Scan: Started | Event Class | 记录的事件类型 = 51。
 | Mode | 扫描模式。可以有下列值： 1 = 普通 2 = 第一个 4 = 后退 8 = 无序 16 = 没有数据 32 = 保留 64 = Exlatch 128 = 索引提供 256 = 标记
 | Object ID | 正在扫描的对象 ID。
 | Index ID | 如果正在扫描索引，则是索引 ID。
 | Transaction ID | 包含扫描的事务 ID。
Scan: Stopped | Event Class | 记录的事件类型 = 52。
 | Mode | 用于执行扫描的模式。可以有下列值： 1 = 普通 2 = 第一个 4 = 后退 8 = 无序 16 = 没有数据 32 = 保留 64 = Exlatch 128 = 索引提供 256 = 标记
 | End Time | 事件的结束时间。
 | Duration | 扫描的持续时间。
 | Reads | 读取的逻辑页数。
 | Index ID | 如果正在扫描索引，则是索引 ID。
 | Object ID | 正在扫描的对象 ID。

通过监视 Index ID 默认数据列，可以确定正由特定查询使用的索引标识号。Index ID 数据列还包含下列任意一项：

  • 若正在扫描表的聚集索引，取值为 1。

    -或-

  • 若正在扫描表的非聚集索引，则该值大于 2 且小于 255。

请参见

扫描事件分类

扫描事件类


安全审核事件分类

使用安全审核事件分类监视审核活动。

请参见

安全审核事件类

安全审核数据列


安全审核事件类

下表描述安全审核事件分类中的安全审核事件类。

事件类 | 描述
Audit Add DB User Event | 记录数据库用户（Microsoft Windows NT® 4.0、Microsoft Windows® 2000 或 Microsoft SQL Server™）的添加和删除操作。
Audit Add Login to Server Role Event | 记录对固定服务器角色的添加或删除登录操作，针对 sp_addsrvrolemember 和 sp_dropsrvrolemember。
Audit Add Member to DB Role Event | 记录对数据库角色（固定或用户定义）的添加或删除成员操作，针对 sp_addrolemember、sp_droprolemember 和 sp_changegroup。
Audit Add Role Event | 记录对数据库角色的添加或除去操作，针对 sp_addrole 和 sp_droprole。
Audit Addlogin Event | 记录对 SQL Server 登录的添加和除去操作，针对 sp_addlogin 和 sp_droplogin。
Audit App Role Change Password Event | 记录对应用程序的密码所做的更改。
Audit Backup/Restore Event | 记录 BACKUP 和 RESTORE 事件。
Audit Change Audit Event | 记录 AUDIT 修改。
Audit DBCC Event | 记录已发出的 DBCC 命令。
Audit Login Event | 收集自跟踪启动后发生的所有新的连接事件，例如客户端请求连接到运行 SQL Server 实例的服务器。
Audit Login Change Password Event | 记录 SQL Server 登录密码更改。不记录密码。 如果您是 sysadmin 或 securityadmin 固定服务器角色的成员，并且通过使用含有全部指定的三个参数（'old_password'、'new_password'、'login'） 的 sp_password 重置自己的密码，则审核记录将反映您正在更改其他人的密码。
Audit Login Change Property Event | 记录对登录属性（除密码外）的修改，针对 sp_defaultdb 和 sp_defaultlanguage。
Audit Login Failed Event | 表示从客户端登录到 SQL Server 实例的尝试已失败。
Audit Login GDR Event | 记录对 Windows NT 4.0 或 Windows 2000 帐户登录权限的授权、废除和拒绝操作，针对 sp_grantlogin、sp_revokelogin 和 sp_denylogin。
Audit Logout Event | 收集自跟踪启动后发生的所有新的断开连接事件，如客户端发出断开连接命令。
Audit Object Derived Permission Event | 对指定的对象发出 CREATE、ALTER 或 DROP 命令时记录。
Audit Object GDR Event | 记录 GRANT、DENY、REVOKE 对象的权限事件。
Audit Object Permission Event | 记录对象权限的使用成功或失败。
Audit Server Starts and Stops Event | 记录服务的关闭、启动和暂停活动。
Audit Statement GDR Event | 记录 GRANT、DENY、REVOKE 语句的权限事件。
Audit Statement Permission | 记录语句权限的使用。

请参见

安全审核事件分类

安全审核数据列


安全审核数据列

下表列出安全审核事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
Audit Add DB User Event | Event Class | 记录的事件类型 = 109。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = sp_adduser 2 = sp_dropuser 3 = grantdbaccess 4 = revokedbaccess
 | Database Name | 要将用户添加到的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Target Login SID | 目标 Microsoft® Windows® 登录的 SID。
 | Target Login Name | 目标 Windows 登录名。
 | Target User Name | 添加到数据库的数据库用户名。
 | Role Name | 要将新数据库用户添加到的角色名。
Audit Add Login to Server Role Event | Event Class | 记录的事件类型 = 108。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 添加 2 = 除去
 | Target Login SID | 目标 Windows 登录的安全标识号 (SID)。
 | Target Login Name | 目标 Windows 登录名。
 | Role Name | 要将登录添加到的角色名。
Audit Add Member to DB Role Event | Event Class | 记录的事件类型 = 110。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 添加 2 = 除去
 | Database Name | 正在运行命令的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Target Login SID | 目标登录的 SID。
 | Target Login Name | 正在更改角色成员资格的登录名称。
 | Target User Name | 正在更改角色成员资格的用户名称。
Audit Add Role Event | Event Class | 记录的事件类型 = 111。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 添加 2 = 除去
 | Database Name | 正在运行命令的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Role Name | 要在数据库中创建的角色名。
Audit Addlogin Event | Event Class | 记录的事件类型 = 104。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 添加 2 = 除去
 | Target Login SID | 指派给添加登录的安全标识号 (SID)。
 | Target Login Name | 正在添加的登录名。
Audit App Role Change Password Event | Event Class | 记录的事件类型 = 112。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 始终 = 1
 | Database Name | 正在运行命令的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Role Name | 正在更改密码的数据库应用程序角色名。
Audit Backup/Restore Event | Event Class | 记录的事件类型 = 115。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 备份 2 = 还原
 | Database Name | 正在运行命令的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Text Data | 备份/还原语句的 SQL 文本。
Audit Change Audit Event | Event Class | 记录的事件类型 = 117。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 新审核已启动 2 = 审核已停止
Audit DBCC Event | Event Class | 记录的事件类型 = 116。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 始终 = 1
 | Database Name | 正在运行命令的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Text Data | DBCC 命令的 SQL 文本。
Audit Login Event | Event Class | 记录的事件类型 = 14。
 | Text Data | 所有集合选项的分隔列表。
 | Binary Data | 会话级别设置，包括 ANSI nulls、ANSI padding、cursor close on commit、null concatenation 和 quoted identifiers。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
Audit Login Change Password Event | Event Class | 记录的事件类型 = 107。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 用户更改了自己的密码。 2 = 用户更改了其他用户的密码。
 | Target Login SID | 目标 Windows 登录的安全标识号 (SID)。
 | Target Login Name | 目标 Windows 登录名。
Audit Login Change Property Event | Event Class | 记录的事件类型 = 106。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 默认数据库 2 = 默认语言
 | Target Login SID | 目标 Windows 登录的安全标识号 (SID)。
 | Target Login Name | 目标 Windows 登录名。
Audit Login Failed Event | Event Class | 记录的事件类型 = 20
 | Success | 表示审核是成功还是失败。取值始终为： 0 = 失败
Audit Login GDR Event | Event Class | 记录的事件类型 = 105。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 授予 2 = 废除 3 = 拒绝
 | Target Login SID | 目标 Windows 登录的安全标识号 (SID)。
 | Target Login Name | 目标 Windows 登录名。
Audit Logout Event | Event Class | 记录的事件类型 = 15。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | End Time | 注销的结束时间。
 | Duration | 自用户登录后用去的大概时间。
 | Reads | 在连接过程中由该用户发出的逻辑读 I/O 的数量。
 | Writes | 在连接过程中由该用户发出的逻辑写 I/O 的数量。
 | CPU | 在连接过程中由该用户使用的 CPU 数量。
Audit Object Derived Permission Event | Event Class | 记录的事件类型 = 118。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 创建对象 2 = 更改对象 3 = 除去对象
 | Database Name | 在其中创建、更改或除去对象的数据库名称。
 | DBUserName | 颁发者在数据库中的用户名。
 | Object Type | 创建、更改或除去的对象类型。取值为： 1 = 索引 2 = 数据库 3 = 用户对象 4 = CHECK 约束 5 = 默认或 DEFAULT 约束 6 = FOREIGN KEY 约束 7 = PRIMARY KEY 约束 8 = 存储过程 9 = 用户定义函数 (UDF) 10 = 规则 11 = 复制筛选存储过程 12 = 系统表 13 = 触发器 14 = 内嵌函数 15 = 表值 UDF 16 = UNIQUE 约束 17 = 用户表 18 = 视图 19 = 扩展存储过程 20 = 特殊查询 21 = 准备查询 22 = 统计
 | Object Name | 正在创建、更改或除去的对象名。
 | Owner Name | 正在创建、更改或除去的对象所有者的数据库用户名。
 | Text Data | 语句的 SQL 文本。
Audit Object GDR Event | Event Class | 记录的事件类型 = 103。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = 授予 2 = 废除 3 = 拒绝
 | Database Name | 运行对象权限的 GRANT/DENY/REVOKE 的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Owner Name | 拥有运行 GRANT/DENY/REVOKE 语句的对象的用户名。
 | Object Name | 正在将权限应用到的对象名。
 | Permissions | 发出的语句类型。取值为： 1 = SELECT ALL 2 = UPDATE ALL 4 = REFERENCES ALL 8 = INSERT 16 = DELETE 32 = EXECUTE（仅限于过程）
 | Column Permissions | 表示是否已设置了列权限。取值为： 0 = 否 1 = 是
 | Text Data | GRANT/REVOKE/DENY 语句的 SQL 文本。
Audit Object Permission Event | Event Class | 记录的事件类型 = 114。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 始终 = 1
 | Database Name | 正在运行命令的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Owner Name | 正在检查其权限的对象所有者名称。
 | Object Name | 正在检查其权限的对象名。
 | Permissions | 发出的语句类型。取值为： 1 = SELECT ALL 2 = UPDATE ALL 4 = REFERENCES ALL 8 = INSERT 16 = DELETE 32 = EXECUTE（仅限于过程）
 | Column Permissions | 表示是否使用了列权限。分析语句文本，以确定将哪些权限应用到了哪些列。
 | Text Data | 与捕获的事件类相关的文本值。
Audit Server Starts and Stops Event | Event Class | 记录的事件类型 = 118。
 | Event Sub Class | 事件中的事件类。取值为： 1 = 实例关闭 2 = 实例启动 3 = 实例暂停 4 = 实例继续
 | Login SID | 运行 Windows 登录的 GRANT/DENY/REVOKE 语句的登录安全标识号 (SID)。
 | Login Name | 运行 Windows 登录的 GRANT/DENY/REVOKE 语句的登录名。
Audit Statement GDR Event | Event Class | 记录的事件类型 = 102。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 1 = GRANT 2 = REVOKE 3 = DENY
 | Database Name | 正在将 GRANT/DENY/REVOKE 语句权限应用到的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Permissions | 发出的语句类型。取值为： 1 = CREATE DATABASE（仅限于 master 数据库） 2 = CREATE TABLE 4 = CREATE PROCEDURE 8 = CREATE VIEW 16 = CREATE RULE 32 = CREATE DEFAULT 64 = BACKUP DATABASE 128 = BACKUP LOG 512 = CREATE FUNCTION
 | Text Data | GRANT/DENY/REVOKE 语句的 SQL 文本。
Audit Statement Permission | Event Class | 记录的事件类型 = 113。
 | Success | 表示审核是成功还是失败。取值为： 0 = 失败 1 = 成功
 | Event Sub Class | 事件中的事件类。取值为： 始终 = 1
 | Database Name | 正在运行命令的数据库名。
 | DBUserName | 颁发者在数据库中的用户名。
 | Permissions | 发出的语句类型。取值为： 1 = CREATE DATABASE（仅限于 master 数据库） 2 = CREATE TABLE 4 = CREATE PROCEDURE 8 = CREATE VIEW 16 = CREATE RULE 32 = CREATE DEFAULT 64 = BACKUP DATABASE 128 = BACKUP LOG 512 = CREATE FUNCTION
 | Text Data | 与捕获的事件类相关的文本值。

请参见

安全事件分类

安全审核事件类


会话事件分类

使用会话事件分类监视 Microsoft® SQL Server™ 用户连接。

请参见

会话事件类

会话数据列


会话事件类

下表描述会话事件分类中的会话事件类。

事件类 | 描述
ExistingConnection | 检测在启动跟踪之前连接到 Microsoft® SQL Server™ 的所有用户活动。

使用 ExistingConnection 事件类时，可以监视每个连接到 SQL Server 实例的用户连接的时间长度，以及执行在该连接上提交的查询所花费的 SQL Server 处理器时间。这些信息对确定下列情况可能很有用：

  • 每个 SQL Server 用户使用的时间量和活动量。这可能有助于跟踪数据库活动，以及按照每个用户的活动时间和使用的 SQL Server CPU 时间（CPU 数据列）收取费用。

  • 系统安全性，通过检查正连接到和正在使用 SQL Server 实例的用户。

请参见

会话事件分类

会话数据列


会话数据列

下表列出会话事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
Existing Connection | Event Class | 记录的事件类型 = 17。
 | Binary Data | 会话级别设置，包括 ANSI nulls、ANSI padding、cursor close on commit、null concatenation 和 quoted identifiers。有关更多信息，请参见SET。

除了 Existing Connection 事件类特有的数据列外，还可以通过监视 DBUserName 和 NT User Name 默认数据列，将用户的名称映射到每个连接。

请参见

会话事件分类

会话事件类


存储过程事件类

使用存储过程事件类监视存储过程的执行。

请参见

存储过程事件类

存储过程数据列


存储过程事件类

下表描述存储过程事件类中的存储过程事件类。

事件类 | 描述
RPC Output Parameter | 显示有关先前执行的远程过程调用 (RPC) 的输出参数的信息。
RPC:Completed | 在已完成 RPC 后发生。
RPC:Starting | 在 RPC 已启动后发生。
SP:CacheHit | 在高速缓存内找到过程。
SP:CacheInsert | 有项目插入过程高速缓存内。
SP:CacheMiss | 在过程高速缓存内没找到存储过程。
SP:CacheRemove | 项目已从过程高速缓存中删除。
SP:Completed | 存储过程已完成。
SP:ExecContextHit | 在高速缓存内找到存储过程的执行版本。
SP:Recompile | 存储过程已重新编译。
SP:Starting | 存储过程已启动。
SP:StmtCompleted | 存储过程内的语句已完成。
SP:StmtStarting | 存储过程内的语句已启动。

通过监视 SP:CacheHit 和 SP:CacheMiss 事件类，可以确定当执行存储过程时在高速缓存内找到它的频率。例如，如果 SP:CacheMiss 事件类频繁发生，则可能表明 Microsoft® SQL Server™ 需要更多内存，从而增加过程高速缓存的大小。通过监视 SP:CacheHit 事件类的对象 ID，可以确定驻留在高速缓存中的存储过程。

可以使用 SP:CacheInsert、SP:CacheRemove 和 SP:Recompile 事件类确定哪些存储过程被带进高速缓存（第一次执行），随后从高速缓存中删除（因老化而从高速缓存中删除），以及何时被重新编译。有关重新编译存储过程的更多信息，请参见重新编译存储过程。此信息对确定应用程序正如何使用存储过程很有用。

存储过程有一个包含共享数据的编译版本和一个包含会话专用数据的执行环境版本。在高速缓存内查找存储过程时，先查找执行环境。如果没有找到，则在高速缓存内搜索编译的计划。使用 SP:ExecContextHit 事件类监视执行环境。如果没有为存储过程生成 SP:ExecContextHit 事件类，那么存储过程没有执行时间可高速缓存的查询。

SP:Starting、SP:StmtStarting、SP:StmtCompleted 和 SP:Completed 事件类和所有的 TSQL 事件类可以监视存储过程的执行。

说明 提供 SP:StmtStarting 只是为了向后兼容性。现在应使用 SQL:StmtStarting 跟踪该事件。如果选择跟踪 SP:StmtStarting，则 SQL 事件探查器将跟踪 SQL:StmtStarting，因为这两个事件一起映射。

请参见

存储过程事件类

存储过程数据列


存储过程数据列

下表描述存储过程事件类中每个事件类的数据列。

事件类 | 数据列 | 描述
RPC Output Parameter | Event Class | 记录的事件类型 = 100。
 | Object Name | 来自 RPC 事件（如句柄）的输出参数名。
 | Text Data | 在由远程过程调用 (RPC) 返回的对象名中命名的参数值。
RPC:Completed | Event Class | 记录的事件类型 = 10。
 | End Time | RPC 的结束时间。
 | Duration | RPC 的持续时间。
 | CPU | RPC 所使用的 CPU 数量。
 | Reads | 由 RPC 发出的页读取数。
 | Writes | 由 RPC 发出的页写入数。
 | Text Data | RPC 文本。
RPC:Starting | Event Class | 记录的事件类型 = 11。
 | Text Data | RPC 文本。
SP:CacheHit | Event Data | 记录的事件类型 = 38。
 | Object ID | 在高速缓存中找到的存储过程的对象 ID。
 | Object Name | 在高速缓存中找到的存储过程名。
 | Text Data | 在高速缓存中找到的 SQL 语句的文本。
SP:CacheInsert | Event Class | 记录的事件类型 = 35。
 | Object ID | 存储过程的对象 ID。
 | Object Name | 在高速缓存中找到的存储过程名。
 | Text Data | 正在高速缓存的 SQL 语句的文本。
SP:CacheMiss | Event Class | 记录的事件类型 = 34。
 | Event Sub Class | 存储过程的嵌套级。
 | Object Name | 在高速缓存中找到的存储过程名。
SP:CacheRemove | Event Class | 记录的事件类型 = 36。
 | Object ID | 存储过程的对象 ID。
 | Object Name | 在高速缓存中找到的存储过程名。
 | Text Data | 正在从高速缓存中删除的 SQL 语句的文本。
SP:Completed | Event Class | 记录的事件类型 = 43。
 | Nest Level | 存储过程的嵌套级。
 | End Time | 事件的结束时间。
 | Duration | 存储过程运行的时间长度。
 | Object ID | 存储过程的对象 ID。
 | Object Name | 在高速缓存中找到的存储过程名。
 | Object Type | 调用的存储过程类型。
 | Text Data | 存储过程调用的文本。
SP:ExecContextHit | Event Class | 记录的事件类型 = 39。
 | Object ID | 存储过程的对象 ID。
 | Object Name | 在高速缓存中找到的存储过程名。
 | Text Data | 在高速缓存中找到的存储过程的文本。
SP:Recompile | Event Class | 记录的事件类型 = 37。
 | Nest Level | 存储过程的嵌套级。
 | Object ID | 存储过程的对象 ID。
 | Object Name | 在高速缓存中找到的存储过程名。
 | Text Data | 触发重新编译的存储过程的文本。
SP:Starting | Event Class | 记录的事件类型 = 42。
 | Nest Level | 存储过程的嵌套级。
 | Object ID | 存储过程的对象 ID。
 | Object Name | 在高速缓存中找到的存储过程名。
 | Object Type | 正在启动的存储过程类型。
 | Text Data | 存储过程调用的文本。
SP:StmtCompleted | Event Class | 记录的事件类型 = 45。
 | Event Sub Class | 存储过程的嵌套级。
 | Integer Data | 语句返回的实际行数。
 | Object ID | 系统指派的存储过程 ID。
 | Text Data | 存储过程内的语句文本。
SP:StmtStarting | Event Class | 记录的事件类型 = 44。
 | Event Sub Class | 存储过程的嵌套级。
 | Object ID | 系统指派的存储过程 ID。
 | Text Data | 存储过程内的语句文本。

请参见

存储过程

存储过程事件类

存储过程事件类


事务事件分类

事务事件类可用于监视事务的状态。

请参见

事务事件类

事务数据列


事务事件类

下表描述事务事件分类中的事务事件类。

事件类 | 描述
DTCTransaction | 跟踪 Microsoft® 分布式事务处理协调器 (MS DTC) 在两个或更多的数据库之间协调的事务。
SQLTransaction | 跟踪 Transact-SQL BEGIN、COMMIT、SAVE 和 ROLLBACK TRANSACTION 语句。
TransactionLog | 在事务被写入事务日志时进行跟踪。

使用 DTCTransaction 事件类在 MS DTC 事务发生时监视其状态。这在测试使用分布式事务的应用程序时会很有用。

在测试应用程序存储过程或触发器时（例如，以便确定事务何时提交或回滚）监视 SQLTransaction 事件类。

当想监视 Microsoft SQL Server™ 事务日志中的活动时（例如，想要测试应用程序并确定日志活动类型），请使用 TransactionLog 事件类。

请参见

事务事件分类

事务数据列


事务数据列

下表列出事务事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
DTCTransaction | Event Class | 记录的事件类型 = 19。
 | Event Sub Class | Microsoft® 分布式事务处理协调器 (MS DTC) 状态。有关更多信息，请参见 MS DTC 文档。可能的值包括： 0 = GET_DTC_ADDRESS_SUB_CLASS 1 = PROPAGATE_XACT_SUB_CLASS 2 = DOWORK_SUB_CLASS 3 = CLOSE_CONN_SUB_CLASS 4 = DTC_VIRGIN_SUB_CLASS 5 = DTC_IDLE_SUB_CLASS 6 = DTC_BEG_DIST_SUB_CLASS 7 = DTC_ENLISTING_SUB_CLASS 8 = DTC_INT_ACTIVE_SUB_CLASS 9 = DTC_INT_COMMIT_SUB_CLASS 10 = DTC_INT_ABORT_SUB_CLASS 11 = DTC_INT_ASYNC_ABORT_SUB_CLASS 12 = DTC_ACTIVE_SUB_CLASS 13 = DTC_INIT_PREPARE_SUB_CLASS 14 = DTC_PREPARING_SUB_CLASS 15 = DTC_PREPARED_SUB_CLASS 16 = DTC_ABORTING_SUB_CLASS 17 = DTC_COMMITTING_SUB_CLASS 18 = DTC_DO_ASYNC_ABORT_SUB_CLASS 19 = DTC_DISASTER_SUB_CLASS 20 = DTC_DRAIN_ABORT_SUB_CLASS 21 = DTC_ASYNC_ABORT_SUB_CLASS 22 = DTC_TM_RECOVERY_SUB_CLASS
 | End Time | 事件的结束时间。
 | Duration | DTC 事务的长度。
 | Reads | 由 DTC 事务在本地生成的页读取数。
 | Writes | 由 DTC 事务在本地生成的页写入数。
 | CPU | 由 DTC 事务使用的 CPU 量。
 | Integer Data | 事务隔离级别。可能的值是： 256 = 未提交读 4096 = 提交读 65536 = 重复读 1048576 = 串行读 4294967295 = 未指定
 | Binary Data | 事务的全局唯一标识符 (GUID)（如果有），为十六进制格式。有关二进制数据的可能值，请参见下面的表 2。
SQLTransaction | Event Class | 记录的事件类型 = 50。
 | Event Sub Class | SQL 事务事件的类型。可能的值包括： 0 = 开始事务 1 = 提交事务 2 = 回滚事务 3 = 发出了保存点
 | End Time | 事件的结束时间。该选项只用于 COMMIT 或 ROLLBACK。
 | Duration | 事务运行的时间长度。该选项只用于 COMMIT 或 ROLLBACK。
 | Transaction ID | 事务的内部 ID 号。
 | Text Data | 保存点或回滚名称（如果已提供）。
 | Object Name | 事务名称（如果已提供）。
TransactionLog | Event Class | 记录的事件类型 = 54。
 | Event Sub Class | 事务日志事件的类型，如 BEGINXACT(null)。
 | Integer Data | 日志记录的长度。
 | Binary Data | 复制 log_pubid 是当前正在处理的发布 ID。如果正在使用复制并在表中查找 MSPublications，则有一个 publication_id 列。该值以二进制数据表示。可以用该 ID 查找发布及其关联的任何项目。
 | End Time | 事件的结束时间。
 | Reads | 为执行日志项而发出的读取 I/O 数。
 | Writes | 为执行日志项而发出的 I/O 数。
 | CPU | 为写入事务项而使用的 CPU 数量。
 | Transaction ID | 事务的内部 ID 号。
 | Object ID | 修改已记入日志的对象 ID。
 | Index ID | 修改已记入日志的索引 ID。

请参见

事务事件分类

事务事件类


TSQL 事件分类

TSQL 事件类可用于监视批处理和 Transact-SQL 语句的执行和完成情况。

请参见

TSQL 事件类

TSQL 数据列


TSQL 事件类

下表描述 TSQL 事件分类中的 TSQL 事件类。

事件类 | 描述
Exec Prepared SQL | 表示 ODBC、OLEDB 或 DB-Library 执行准备好的 SQL 语句的时间。
Prepare SQL | 表示 ODBC、OLEDB 或 DB-Library 将 SQL 语句准备好以便使用的时间。
SQL:BatchCompleted | Transact-SQL 批处理已完成。
SQL:BatchStarting | Transact-SQL 批处理已启动。
SQL:StmtCompleted | Transact-SQL 语句已完成。
SQL:StmtStarting | Transact-SQL 语句已启动。
Unprepare SQL | 表示 ODBC、OLEDB 或 DB-Library 撤消准备好的 SQL 语句的时间。

通过监视 TSQL 事件类并通过单步跟踪监视事件，可以监视应用程序查询。SQL:BatchStarting 事件类显示批处理内提交的 Transact-SQL，而 SQL:StmtStarting 事件类显示批处理内的个别语句。通过重播 SQL:BatchCompleted 事件类，可以显示由批处理返回的结果，并对其进行检查以确保其与预期的结果匹配。

通过监视 Start Time、End Time 和 Duration 默认数据列，可显示事件何时开始和完成以及完成每个远程过程调用 (RPC)、批处理或语句所用的时间。通过按 Duration 默认数据列将事件分组，可以很容易地确定运行时间最长的查询。监视 NT User Name 和 DBUserName 默认数据列还可以识别提交这些查询的用户。

请参见

TSQL 事件分类

TSQL 数据列


TSQL 数据列

下表列出 TSQL 事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
Exec Prepared SQL | Event Class | 记录的事件类型 = 72。
 | Handle | 准备好的 TSQL 语句的句柄。
Prepare SQL | Event Class | 记录的事件类型 = 71。
 | Handle | 准备好的 TSQL 语句的句柄。
SQL:BatchCompleted | Event Class | 记录的事件类型 = 12。
 | Duration | 事件的持续时间。
 | End Time | 事件的结束时间。
 | Reads | 由批处理导致的页读取 I/O 数。
 | Writes | 由批处理导致的页写入 I/O 数。
 | CPU | 批处理过程中使用的 CPU。
 | Text Data | 批处理的文本。
SQL:BatchStarting | Event Class | 记录的事件类型 = 13。
 | Text Data | 批处理的文本。
SQL:StmtCompleted | Event Class | 记录的事件类型 = 41。
 | Duration | 事件的持续时间。
 | End Time | 事件的结束时间。
 | Reads | 由 SQL 语句发出的页读取数。
 | Writes | 由 SQL 语句发出的页写入数。
 | CPU | 由 SQL 语句使用的 CPU。
 | Integer Data | 由 SQL 语句返回的行数。
 | Object ID | 如果曾在存储过程中运行 SQL 语句，则是父存储过程的对象 ID。
 | Nest Level | 如果曾在存储过程中运行 SQL 语句，则是存储过程的嵌套级。
 | Text Data | 将要执行的语句文本。
SQL:StmtStarting | Event Class | 记录的事件类型 = 40。
 | Object ID | 如果曾在存储过程中运行 SQL 语句，则是父存储过程的对象 ID。
 | Nest Level | 如果曾在存储过程中运行 SQL 语句，则是存储过程的嵌套级。
 | Text Data | 将要执行的语句文本。
Unprepare SQL | Event Class | 记录的事件类型 = 73。
 | Handle | 准备好的 TSQL 语句的句柄。

请参见

TSQL 事件分类

TSQL 事件类


用户可配置的事件分类

使用用户可配置的事件分类监视用户定义的事件。可创建用户定义的事件来监视不能由其它事件分类内系统提供的事件进行监视的事件。例如，可以创建一个用户定义的事件来监视测试的应用程序进度。应用程序运行时，能在预定义点生成事件，使您得以确定应用程序内的当前执行点。

请参见

用户可配置的事件类

用户可配置的数据列


用户可配置的事件类

当应用程序使用 sp_trace_generateevent 存储过程生成用户定义的事件时，指定的 event_class 参数确定对下列 10 个事件类中的哪些进行监视。

下表描述用户可配置的事件分类中的用户可配置的事件类。

事件类 | 描述
UserConfigurable (0-9) | 用户定义的事件数据。

请参见

用户可配置的事件分类

用户可配置的数据列


用户可配置的数据列

下表描述用户可配置的事件分类中每个事件类的数据列。

事件类 | 数据列 | 描述
UserConfigurable (0-9) | Text Data | 与跟踪中捕获的事件类相关的文本值。
 | Binary Data | 与在跟踪中捕获的事件类相关的二进制值。

并非为用户可配置的事件类产生所有的数据列。当创建跟踪时，可以选择以下列：

  • 应用程序名称

  • Binary Data

  • 数据库 ID

  • 主机名称

  • 登录名

  • Login SID

  • NT 域名

  • NT 用户名

  • 服务器名称

  • Text Data

创建用户定义的事件类

Transact-SQL

请参见

用户可配置的事件分类

用户可配置的事件类


创建并管理跟踪和模板

在 Microsoft® SQL Server™ 中，可以使用 SQL 事件探查器创建一个或多个模板，以定义要监视的每个事件的准则。可以将模板保存到带 .tdf 扩展名的文件。模板不会被执行。在定义模板后，运行跟踪来记录选定的每个事件的数据。

例如，可以创建一个模板以指定使用哪些事件、数据列和筛选。然后可以保存该模板，并用当前的模板设置启动跟踪。捕获的跟踪数据基于模板中指定的选项。可以指定跟踪结果的保存位置，例如保存在跟踪文件（带 .trc 扩展名的文件）或跟踪表中。

默认模板

在使用 SQL 事件探查器创建跟踪之前，可以指定默认跟踪模板。若要选择默认跟踪模板，请指向"工具"菜单并选择"选项"命令。

还可以指定：

  • 建立连接后立即启动默认跟踪。

  • 缓冲显示的跟踪数据的行数。如果禁用窗口自动滚动，而且达到了指定的限制，则跟踪将暂停，直到向下滚动到最后一行。这时，将删除顶端百分之十的行并继续进行跟踪。

  • 显示的跟踪数据所使用的字体。

  • 显示的跟踪数据所使用的字体大小。

创建跟踪时，可以指定下列内容：

  • 跟踪名称。

  • 要跟踪的 SQL Server 实例。

  • 保存跟踪数据的选项。例如，可以选择将跟踪数据捕获到服务器文件。如果选择该选项，则必须将跟踪数据捕获到正在跟踪的服务器，并设置服务器文件的最大文件大小。如果达到最大文件大小，则可以启用文件翻转选项，以创建存储跟踪数据的新文件。也可以将跟踪保存到文件、表或这些选项的组合中。如果要跟踪大量的数据，应将数据保存到服务器文件。这保证了产生的所有事件都将保存到该文件中。最大文件大小限制为 1 GB。

  • 跟踪停止时间。

  • 要跟踪的事件。有关可用事件类的更多信息，请参见使用 SQL Server 事件探查器事件分类进行监视。

  • 要捕获的数据列。有关可用数据列的更多信息，请参见使用 SQL Server 事件探查器事件分类进行监视。

  • 指定确定捕获哪些事件的准则的筛选。
使用系统存储过程

SQL 事件探查器使用系统存储过程创建跟踪并将跟踪输出发送到适当的目的。可以不使用 SQL 事件探查器，而是从自己的应用程序中使用这些存储过程手动创建跟踪。这使您得以针对企业的特定需要编写自定义应用程序。例如，使用存储过程创建跟踪时，可以：

  • 配置跟踪。

  • 将跟踪事件从一台或多台服务器转发到文件。

下表比较 SQL Server 2000 系统存储过程和 SQL Server 7.0 版存储过程。

7.0 扩展存储过程 | 2000 存储过程
xp_trace_geteventclassrequired | fn_trace_geteventinfo
xp_trace_getqueuecreateinfo | fn_trace_geteventinfo
xp_trace_getqueueproperties | fn_trace_geteventinfo
xp_trace_getqueuecreateinfo | fn_trace_getinfo
xp_trace_getqueuedestination | fn_trace_getinfo
xp_trace_getqueueproperties | fn_trace_getinfo
xp_trace_addnewqueue | sp_trace_create
xp_trace_setqueuecreateinfo | sp_trace_create
xp_trace_setqueuedestination | sp_trace_create
xp_trace_generate_event | sp_trace_setevent
xp_trace_addnewqueue | sp_trace_setevent
xp_trace_eventclassrequired | sp_trace_setevent
xp_trace_seteventclassrequired | sp_trace_setevent
xp_trace_destroyqueue | sp_trace_setstatus
xp_trace_pausequeue | sp_trace_setstatus
xp_trace_restartqueue | sp_trace_setstatus
xp_trace_startconsumer | sp_trace_setstatus
xp_trace_getappfilter | fn_trace_getfilterinfo
xp_trace_getconnectionidfilter | fn_trace_getfilterinfo
xp_trace_getcpufilter | fn_trace_getfilterinfo
xp_trace_getdbidfilter | fn_trace_getfilterinfo
xp_trace_getdurationfilter | fn_trace_getfilterinfo
xp_trace_geteventfilter | fn_trace_getfilterinfo
xp_trace_gethostfilter | fn_trace_getfilterinfo
xp_trace_gethpidfilter | fn_trace_getfilterinfo
xp_trace_getIndIdfilter | fn_trace_getfilterinfo
xp_trace_getntdmfilter | fn_trace_getfilterinfo
xp_trace_getntnmfilter | fn_trace_getfilterinfo
xp_trace_getobjidfilter | fn_trace_getfilterinfo
xp_trace_getreadfilter | fn_trace_getfilterinfo
xp_trace_getserverfilter | fn_trace_getfilterinfo
xp_trace_getseverityfilter | fn_trace_getfilterinfo
xp_trace_getspidfilter | fn_trace_getfilterinfo
xp_trace_getsysobjectsfilter | fn_trace_getfilterinfo
xp_trace_gettextfilter | fn_trace_getfilterinfo
xp_trace_getuserfilter | fn_trace_getfilterinfo
xp_trace_getwritefilter | fn_trace_getfilterinfo
xp_trace_setappfilter | sp_trace_setfilter
xp_trace_setconnectionidfilter | sp_trace_setfilter
xp_trace_setcpufilter | sp_trace_setfilter
xp_trace_setdbidfilter | sp_trace_setfilter
xp_trace_setdurationfilter | sp_trace_setfilter
xp_trace_seteventfilter | sp_trace_setfilter
xp_trace_sethostfilter | sp_trace_setfilter
xp_trace_sethpidfilter | sp_trace_setfilter
xp_trace_setIndIdfilter | sp_trace_setfilter
xp_trace_setntdmfilter | sp_trace_setfilter
xp_trace_setntnmfilter | sp_trace_setfilter
xp_trace_setobjidfilter | sp_trace_setfilter
xp_trace_setreadfilter | sp_trace_setfilter
xp_trace_setserverfilter | sp_trace_setfilter
xp_trace_setseverityfilter | sp_trace_setfilter
xp_trace_setspidfilter | sp_trace_setfilter
xp_trace_setsysobjectsfilter | sp_trace_setfilter
xp_trace_settextfilter | sp_trace_setfilter
xp_trace_setuserfilter | sp_trace_setfilter
xp_trace_setwritefilter | sp_trace_setfilter

系统存储过程表现创建跟踪所使用的基础构架。构架组件包括：

发生器

生成要监视的事件。产生锁事件的 SQL Server 锁管理器，是发生器的示例。有关更多信息，请参见锁事件分类。

筛选

限制由跟踪监视的数据。有关更多信息，请参见限制跟踪。

目的

将从跟踪中析取的事件数据存放在文件中。

使用存储过程定义自己的跟踪：

  1. 使用 sp_trace_setevent 指定要捕获的事件。

  2. 指定任何事件筛选。有关更多信息，请参见如何设置跟踪筛选 (Transact-SQL)。

  3. 使用 sp_trace_create 为捕获的事件数据指定目的。

设置跟踪定义默认值

事件探查器

事件探查器

设置跟踪显示默认值

事件探查器

事件探查器

创建跟踪

事件探查器

事件探查器

Transact-SQL

Transact-SQL

在跟踪模板中添加或删除事件

事件探查器

事件探查器

Transact-SQL


限制跟踪

如果没有设置筛选，跟踪输出中将返回选定事件类的所有事件。筛选限制跟踪内收集的事件。例如，通过将跟踪内的 Microsoft® Windows NT® 4.0 或 Windows® 2000 用户名限定为特定的用户，可以将输出数据减少到仅限于那些感兴趣的用户。

跟踪事件准则是一些参数，用来限制（筛选）跟踪内捕获的事件数据。例如，可以监视特定应用程序的活动或将应用程序排除在监视外（默认跟踪事件准则将 SQL 事件探查器本身排除在监视外）。例如，在监视查询以确定执行时间最长的批处理时，可以设置跟踪事件准则，只监视（跟踪）那些执行时间超过 30 秒的批处理（CPU 最小值是 30,000 毫秒）。可以通过右击适当的跟踪事件准则并输入信息来指定筛选。

筛选跟踪模板中的事件

事件探查器

事件探查器

Transact-SQL

Transact-SQL

修改筛选

事件探查器

事件探查器

每个跟踪事件准则参数都有一组值，用来确定在 SQL 事件探查器监视事件类时是否在跟踪内包括事件数据。适用的值取决于选择的事件准则。

事件准则选项 | 描述
同于 | 指定跟踪事件数据必须类似于输入的文本。允许多个值。
不同于 | 指定跟踪事件数据不能与输入的文本类似。允许多个值。
等于 | 指定跟踪事件数据必须等于输入的值。允许多个值。
不等于 | 指定跟踪事件数据不能等于输入的值。允许多个值。
大于或等于 | 指定跟踪事件数据必须大于或等于输入的值。
小于或等于 | 指定跟踪事件数据必须小于或等于输入的值。

下表列出跟踪事件准则（筛选）以及每个准则的可用选项。

跟踪事件准则 | 描述 | 同于 | 不同于 | 等于 | 不等于 | 大于或等于 | 小于或等于
Application Name | 生成事件的应用程序（例如查询分析器）。 | 是 | 是 |  |  |  |
Client ProcessID | 调用 Microsoft® SQL Server™ 的应用程序进程 ID。 |  |  | 是 | 是 | 是 | 是
Column Permissions | 表示是否已设置了列权限。 |  |  | 是 | 是 | 是 | 是
CPU | CPU 时间量（以毫秒为单位）。 |  |  | 是 | 是 | 是 | 是
Database ID | 指派给数据库的 ID。可以使用 DB_ID 函数确定数据库的值。 |  |  | 是 | 是 | 是 | 是
Database Name | 数据库名称，在该数据库中用户语句正在运行。 | 是 | 是 |  |  |  |
Duration | 远程过程调用 (RPC) 和语言语句、锁、会话以及其它定义了运行时间的事件所用的运行时间。 |  |  | 是 | 是 | 是 | 是
End Time | 事件结束时的时间。启动事件类（如 SQL:BatchStarting 或 SP:Starting）的该列不填充。 |  |  |  |  | 是 | 是
Error | 给定事件的错误号。通常是存储在 sysmessages 中的错误号。 |  |  | 是 | 是 | 是 | 是
File Name | 所修改的文件的逻辑名称。 | 是 | 是 |  |  |  |
Handle | 由 ODBC、OLEDB 或 DB-Library 用于协调与服务器的执行的整数。 |  |  | 是 | 是 | 是 | 是
Host Name | 生成事件的计算机的名称。若要确定主机名，请使用 HOST_NAME 函数。 | 是 | 是 |  |  |  |
Index ID | 对象的索引 ID。若要确定对象的索引 ID，请使用 sysindexes 系统表的 indid 列。 |  |  | 是 | 是 | 是 | 是
Login Name | 用户的登录名（SQL Server 安全登录或 Windows 登录凭据，格式为 DOMAIN\Username）。 | 是 | 是 |  |  |  |
Mode | 不同事件所用的整数，用于描述事件已接收或要请求的状态。 |  |  | 是 | 是 | 是 | 是
NT Domain Name | 生成事件的客户端的 Windows NT 或 Windows 2000 域。 | 是 | 是 |  |  |  |
NT User Name | 对生成事件负责的个人。 | 是 | 是 |  |  |  |
Object ID | 监视对象的唯一 ID。或者，通过选择"排除系统对象"复选框，可以监视所有对象，但不包括 sysobjects 表这类系统对象。 |  |  | 是 | 是 | 是 | 是
Object Name | 所引用的对象名。 | 是 | 是 |  |  |  |
Object Type | 表示事件中涉及的对象类型的值。该值对应于 sysobjects 中的类型列。 |  |  | 是 | 是 | 是 | 是
Owner Name | 对象所有者的数据库用户名称。 | 是 | 是 |  |  |  |
Permissions | 表示所检查的权限类型的整型值。取值为： 1 = SELECT ALL 2 = UPDATE ALL 4 = REFERENCES ALL 8 = INSERT 16 = DELETE 32 = EXECUTE（仅限于过程） 4096 = SELECT ANY （至少一列） 8192 = UPDATE ANY 16384 = REFERENCES ANY |  |  | 是 | 是 | 是 | 是
Reads | 由执行语句的服务器执行的逻辑读取数。 |  |  | 是 | 是 | 是 | 是
Role Name | 要启用的应用程序角色名。 | 是 | 是 |  |  |  |
Severity | 错误严重级别的范围。 |  |  | 是 | 是 | 是 | 是
SPID | 每个连接有一个唯一的 SPID。 |  |  | 是 | 是 | 是 | 是
DBUserName | 生成事件的用户。 | 是 | 是 |  |  |  |
Start Time | 启动事件的时间（可用时）。 |  |  |  |  | 是 | 是
State | 等同于错误状态代码。 |  |  | 是 | 是 | 是 | 是
Success | 1 = 成功。 0 = 失败（例如，1 表示权限检查成功，2 表示检查失败）。 |  |  | 是 | 是 | 是 | 是
Target Login Name | 对于以登录为目标的操作（例如，添加新登录），是目标登录的名称。 | 是 | 是 |  |  |  |
Target User Name | 对于以数据库用户为目标的操作（例如，向用户授予权限），是该用户的名称。 | 是 | 是 |  |  |  |
Text Data | 事件数据内包含的文本。 | 是 | 是 |  |  |  |
Writes | 由执行语句的服务器执行的磁盘写入数。 |  |  | 是 | 是 | 是 | 是

作为一种安全机制，SQL 事件探查器自动从跟踪中省略任何影响密码的、与安全有关的存储过程。这个安全机制不可配置且始终有效，以防止用户捕获密码，否则用户就会获得在 SQL Server 上跟踪所有活动的权限。

不监视下列与安全有关的存储过程：

请参见

sp_addapprole

sp_adddistpublisher

sp_adddistributiondb

sp_adddistributor

sp_addlinkedserver

sp_addlinkedsrvlogin

sp_addlogin

sp_addmergepullsubscription_agent

sp_addpullsubscription_agent

sp_addremotelogin

sp_addsubscriber

sp_approlepassword

sp_changedistpublisher

sp_changesubscriber

sp_dsninfo

sp_helpsubscription_properties

sp_link_publication

sp_password

sp_setapprole


最大文件大小和数据大小

使用"最大文件大小"和"最大行数"选项，可以指定存放跟踪信息的文件或表的最大大小，并控制由跟踪使用的空间量和资源量。

如果使用 SQL 事件探查器启动定义为将数据保存到文件的跟踪，而该文件已经存在，则可以追加到或重写该文件。如果选择追加到该文件，而此跟踪文件已经达到或超过指定的最大文件大小，则会通知您，并让您选择是增加最大文件大小还是指定新文件。对跟踪表也是如此。

最大文件大小

指定有最大文件大小的跟踪当达到最大文件大小时，会停止将跟踪信息保存到文件。 将跟踪数据保存到文件时必须使用最大文件大小选项。默认最大文件大小为 5 MB。将跟踪数据保存到文件时，默认情况下启用文件翻转选项。

最大文件大小选项的限制为 1 GB。

如何为跟踪文件设置最大文件大小

事件探查器

事件探查器

最大数据大小

在表中指定最大数据大小使运行无值守跟踪更容易。例如，如果需要启动一个跟踪以将跟踪数据保存到文件和/或表，但想在文件变得过大时停止跟踪，则可以自动这样做。通过指定最大文件大小和/或行数，用户可以保证跟踪文件或表不会增长到超出指定的范围。

通过 SQL 事件探查器用户界面设置最大数据大小后，跟踪在达到最大大小时继续运行，但是不再记录跟踪信息。但是，通过使用系统存储过程，可以指定跟踪在达到最大数据大小时停止运行。

如何为跟踪设置最大表大小

事件探查器

事件探查器

请参见

sp_trace_create


Datetime 筛选

可将跟踪设置为筛选出在指定时间内不发生的事件。例如，若想查看在凌晨 2:00 和凌晨 2:30 之间启动的事件，可以设置一个跟踪自动筛选出凌晨 2:00 之前和凌晨 2:30 之后启动的所有事件。"开始时间"筛选和"结束时间"筛选只捕获在指定时间内发生的事件。跟踪本身在这个时间内是活动的，不按"开始时间"和"结束时间"自动启动或停止。这些时间只影响筛选。

如何为跟踪设置开始时间筛选

事件探查器

事件探查器

如何为跟踪设置结束时间筛选

事件探查器


系统 SPID

可以定义一个跟踪只记录 Microsoft® SQL Server™ 进程，同时筛选出任何不必要的系统事件。当在繁忙的服务器上运行跟踪时，筛选出系统服务器进程 ID (SPID) 可节省系统资源和时间。

如何在跟踪中筛选系统 ID

事件探查器


保存跟踪和模板

保存跟踪涉及将捕获的事件数据保存到指定的位置。保存模板涉及保存跟踪定义，比如指定的数据列、事件和筛选。

保存事件数据

在需要以后分析或重播捕获的数据（例如，为了预测趋势或解决和调试应用程序问题）时，将捕获的事件数据保存到文件或 Microsoft® SQL Server™ 表中。可以：

  • 使用跟踪文件或跟踪表创建工作负荷，作为索引优化向导的输入。

  • 使用跟踪文件捕获事件并将跟踪文件发送给支持提供商供其分析。

  • 使用 SQL Server 中的查询处理工具访问数据或在 SQL 事件探查器中查看数据。不过，只有 sysadmin 固定服务器角色成员或表的创建者才能直接访问跟踪表。

    重要 将跟踪数据捕获到表比捕获到文件慢。另一种方法是将跟踪捕获到文件，打开该跟踪文件，然后将跟踪另存为跟踪表。

使用跟踪文件时，SQL 事件探查器将捕获的事件数据（而非跟踪定义）保存到 SQLProfiler (*.trc) 文件。保存跟踪文件时自动在文件名的末尾加上这个扩展名，不管是否有任何其它指定的扩展名。例如，如果指定一个名为 Trace.dat 的跟踪文件，则创建的文件名为 Trace.dat.trc。

说明 如果 SQL 事件探查器在 Microsoft Windows® 2000 或 Microsoft Windows NT® 4.0 上运行，则不能打开位于 Windows 98 共享目录中的跟踪或脚本文件。

保存模板

跟踪定义包括事件类、数据列、事件准则（筛选）和所有其它用来创建跟踪的属性（捕获的事件数据除外）。使用 SQL 事件探查器创建的模板保存在运行 SQL 事件探查器的计算机上的文件中。

如果经常监视 SQL Server，则保存模板以便分析性能。模板每次捕获相同的事件数据，并使用相同的跟踪定义监视同一事件，因而无须在每次创建跟踪时都定义事件类和数据列。另外，可以将模板提供给其他用户，供其监视特定的 SQL Server 事件。例如，支持提供商可提供给客户一个模板。客户使用这个模板捕获所需的事件数据，然后将这些数据发送给支持提供商供其分析。

将跟踪保存到文件

事件探查器

事件探查器

Transact-SQL

将跟踪保存到表

事件探查器

事件探查器

Transact-SQL

将跟踪保存到 Windows NT 应用程序日志

Transact-SQL

将事件数据转发到另一个服务器

Transact-SQL

保存跟踪定义

Transact-SQL


修改模板

可以修改保存在运行 SQL 事件探查器的本地计算机上的文件中的模板以及从文件导出的模板。如果没有记住当初用于创建跟踪的模板，或希望以后再次运行同一跟踪，则可能需要从跟踪文件导出模板。修改模板属性（如事件类和数据列）的方法与当初设置该属性的方法相同。可以添加和删除事件类和数据列，也可以对筛选进行更改。修改模板后，以同一名称保存它将重写原来的模板。有关更多信息，请参见创建并管理跟踪和模板。

当处理现有跟踪时，可以查看属性，但不能修改。

警告 使用相同的名称保存跟踪文件将重写原来的跟踪文件，这将导致任何当初捕获的事件或已删除或筛选的数据列丢失。

从跟踪文件或跟踪表导出模板

事件探查器

事件探查器

修改跟踪模板

事件探查器

事件探查器

Transact-SQL

Transact-SQL

在跟踪模板或跟踪文件中添加或删除事件

事件探查器

事件探查器

Transact-SQL

在跟踪模板中添加或删除数据列

事件探查器


启动、暂停和停止跟踪

在使用 SQL 事件探查器创建了模板后，可以使用新跟踪启动、暂停或停止捕获数据。

当启动跟踪且将服务器定义为源时，Microsoft® SQL Server™ 将创建一个队列，以便为捕获的服务器事件提供一个临时存放位置。

每个跟踪可以有多个发生器。发生器收集特定的事件分类内的事件，并将数据发送到队列。事件按其放入队列内的顺序读取。这种读取方法称为先进/先出 (FIFO)。

使用 SQL 事件探查器时，启动跟踪将打开一个新的跟踪窗口（如果没有窗口打开），并立即捕获数据。当使用 SQL Server 系统存储过程时，每次启用 SQL Server 实例时可手工或自动启动跟踪。一启动跟踪，就会立即捕获数据。启动跟踪后，只能修改跟踪的名称。

暂停跟踪可防止捕获更多的事件数据，直到重新启动。重新启动跟踪将继续执行跟踪操作。先前捕获的所有数据都不丢失。重新启动跟踪时，从启动的那一点起继续捕获数据。当暂停跟踪时，可以更改名称、事件、列和筛选。但是不能更改要将跟踪发送到的目的地或服务器连接。

停止跟踪将停止捕获数据。一旦停止了跟踪，除非已将数据捕获到了跟踪文件或跟踪表中，否则重新启动该跟踪将丢失以前捕获的数据。当停止跟踪时，将保留以前选择的所有跟踪属性。当停止跟踪时，可以更改名称、事件、列和筛选。

在跟踪暂停或停止之后运行跟踪

事件探查器

事件探查器

Transact-SQL

暂停跟踪

事件探查器

事件探查器

Transact-SQL

停止跟踪

事件探查器

事件探查器

清除跟踪窗口

事件探查器

事件探查器

关闭跟踪窗口

事件探查器

事件探查器

Transact-SQL


查看和分析跟踪

使用 SQL 事件探查器可以查看跟踪内捕获的事件数据。SQL 事件探查器基于定义的跟踪属性显示数据。分析 Microsoft® SQL Server™ 数据的一个方法是将数据复制到另一个程序，如 SQL 查询分析器或索引优化向导。索引优化向导可以使用包含 SQL 批处理和远程过程调用 (RPC) 事件（以及 Text 数据列）的跟踪文件。使用此向导时，通过指定服务器和数据库名称，可以对不同的服务器和数据库分析捕获的数据。有关更多信息，请参见索引优化向导。

使用 SQL 事件探查器打开跟踪时，如果跟踪文件是由 SQL 事件探查器或事件探查器存储过程创建的，则该文件不需要带 .trc 文件扩展名。

说明 SQL 事件探查器还可以读取 SQL 跟踪日志文件 (.log) 和类属 SQL 脚本文件。打开不带 .log 文件扩展名的 SQL 跟踪程序 .log 文件（如 trace.txt）时，将文件格式指定为 SQLTrace_Log。

可以用自定义的字体、字体大小、预览线和客户端缓冲区大小来配置 SQL 事件探查器的显示，以便有助于分析跟踪。

分析数据以解决问题

使用 SQL 事件探查器时，可以按 Duration、CPU、Reads 或 Writes 数据列将跟踪或跟踪文件分组以解决与数据有关的问题，如性能差或逻辑读取数特别高的查询。

通过将跟踪保存到表和使用 Transact-SQL 查询事件数据，可以找到附加的信息。例如，若要确定哪些 SQL:BatchCompleted 事件有过长的等待时间，可执行：

SELECT  TextData, Duration, CPU
FROM    trace_table_name
WHERE   EventClass = 12 -- SQL:BatchCompleted events
AND     CPU < (.4 * Duration)
查看跟踪时显示对象名称

如果在跟踪内捕获 Server Name 和 Database ID 数据列，SQL 事件探查器将显示对象名而非对象 ID（如显示 Orders 而不是数字 165575628）。同样，如果捕获 Server Name、Database ID 和 Object ID，SQL 事件探查器将显示索引名而非索引 ID。

如果选择按 Object ID 数据列分组，则先按 Server Name 和 Database ID 数据列分组，然后按 Object ID 分组。同样，如果选择按 Index ID 数据列分组，则先按 Server Name、Database ID 和 Object ID 数据列分组，然后按 Index ID 数据列分组。需要这样分组是因为，对象和索引 ID 在服务器和数据库（以及索引 ID的对象）之间不是唯一的。

查找跟踪内的特定事件

下面是查找和分组跟踪内事件的基本步骤：

  1. 创建跟踪。
    • 定义跟踪时，除了要捕获的任何其它数据列外，还要捕获 Event Class、ClientProcessID 和 Start Time 数据列。

    • 按 Event Class 数据列将捕获的数据分组，并将跟踪捕获到文件或表。
  2. 查找目标事件。
    • 打开跟踪文件或表，并展开想要的事件类的节点（如 Deadlock Chain）。（可以在跟踪写入文件时打开文件进行查看，除非跟踪位于运行 Microsoft Windows® 98 的计算机上。使用"查看"菜单中的"刷新"命令显示新行。）

    • 在跟踪内搜索直到找到正在查找的事件（可以使用 SQL 事件探查器的"编辑"菜单上的"查找"选项帮助查找跟踪内的值）。记下所需事件的 ClientProcessID 和 Start Time 数据列中的值。
  3. 在上下文中显示事件。
    • 显示跟踪数据列属性，并按 ClientProcessID 而不是 Event Class 分组。

    • 展开要查看的每个客户端进程 ID 的节点。手工搜索跟踪，或使用"查找"选项，直到找到前面记下的目标事件的 Start Time 值。这些事件与其它属于每个所选客户端进程 ID 的事件一起按时间顺序显示。例如，跟踪内捕获的 Deadlock 和 Deadlock Chain 事件紧接在展开的客户端进程 ID 中的 SQL:BatchStarting 事件之后显示。

可以使用同样的技巧查找按 Server Name、Database ID 和 Object ID 分组的事件。一旦找到要查找的事件，按 ClientProcessID、Application Name 或其它事件类分组，按时间顺序查看相关活动。

查看保存的跟踪

Transact-SQL

Transact-SQL

查看筛选信息

事件探查器

事件探查器

Transact-SQL

Transact-SQL

打开跟踪数据文件

事件探查器

事件探查器

如果跟踪文件位于运行 Microsoft Windows 95/98 的计算机上，则 SQL 事件探查器不能在跟踪文件正用于捕获事件时打开它。此外：

  • 运行在 Windows NT® 4.0 上的 SQL 事件探查器不能打开位于 Windows 95/98 共享目录的跟踪或脚本文件。

  • SQL 事件探查器访问远程计算机上的跟踪或脚本文件时，如果这些文件后来变得不可用，则 SQL 事件探查器会引起问题。

打开跟踪表

事件探查器

事件探查器

请参见

SQL 事件探查器性能考虑


重播跟踪

在创建或编辑跟踪时，可以保存跟踪供以后重播。SQL 事件探查器的特色是有一个多线程播放引擎，它能模拟用户连接和 SQL Server 身份验证，使用户得以重新产生跟踪内捕获的活动。因此，重播对解决应用程序或进程的问题很有帮助。识别出问题并进行了纠正后，对纠正后的应用程序或进程运行找到了潜在问题的那个跟踪，然后重播原来的跟踪并比较结果。

跟踪重播支持使用重播到断点和游标的方式进行调试，这在分析长脚本时尤为有用。有关更多信息，请参见单步跟踪。

重播要求

除任何其它要监视的事件类外，还必须在跟踪内捕获下列事件类才能重播跟踪：

  • 连接

  • CursorExecute（仅在重播服务器端游标时需要）

  • CursorOpen（仅在重播服务器端游标时需要）

  • CursorPrepare（仅在重播服务器端游标时需要）

  • 断开

  • Exec Prepared SQL（仅在重播服务器端准备 SQL 语句时需要）

  • ExistingConnection

  • Prepare SQL（仅在重播服务器端准备 SQL 语句时需要）

  • RPC:Starting

  • SQL:BatchStarting

除任何其它要捕获的数据列外，还必须在跟踪内捕获下列数据列才能重播跟踪：

  • Application Name

  • Binary Data

  • ClientProcessID or SPID

  • Database ID

  • Event Class

  • Event Sub Class

  • Host Name

  • Integer Data

  • Server Name

  • SQL User Name

  • Start Time

  • Text

    说明 对捕获数据以进行重播的跟踪使用样本跟踪模板 SQLProfilerTSQL_Replay。

为了在运行 Microsoft® SQL Server™ 的（目标）计算机上，而不是在当初跟踪的（源）计算机上重播跟踪：

  • 必须在目标上与源相同的数据库中创建跟踪内包含的所有登录和用户。

  • 目标上的所有登录和用户必须具有与它们在源中相同的权限。

  • 所有登录的密码必须与执行重播的用户密码相同。

重播与丢失的或不正确的登录相关的事件会导致重播错误，但重播操作会继续。

为了在 SQL Server 实例（目标），而不是在当初跟踪的（源）计算机上重播跟踪，需满足下列任一条件：

  • 目标上的数据库 ID 必须与源上的数据库 ID 相同。这可以通过从源创建 master 数据库的备份以及跟踪内所引用的任何用户数据库，然后在目标上还原这些数据库来实现。

  • 必须将跟踪内包含的每个登录的默认数据库在目标上设置成登录各自的目标数据库。例如，在源上，要重播的跟踪包含数据库 Fred_Db 内的登录 Fred 的活动。因此在目标上，必须将登录 Fred 的默认数据库设置成与 Fred_Db 相匹配的数据库（即使数据库名称不同）。若要设置登录的默认数据库，请使用 sp_defaultdb 系统存储过程。
重播选项

在重播捕获的跟踪前，可以指定：

  • 服务器

    服务器是要重播跟踪的 SQL Server 实例的名称。服务器必须遵守前面提到的重播要求。

  • 输出文件名

    输出文件包含跟踪的重播结果，可供以后查看。如果选择"进度"选项，以后也可以重播输出文件。默认情况下，SQL 事件探查器只在屏幕上显示重播跟踪的结果。

  • 重播选项
    • 按照被跟踪的顺序重播事件。此选项启用调试。

      指定按照被跟踪的顺序重播事件。这将使您得以使用调试方法，如逐个查看每个跟踪。

    • 使用多线程重播事件。此选项优化性能并禁用调试。

      指定使用多线程重播事件。这将优化性能，但是禁用调试。

    • 显示重播结果

      指定显示重播结果。这是默认选项。如果正在重播的跟踪非常大，可能需要禁用此选项以节省磁盘空间。

说明 为了获得最佳的重播性能，建议选择"使用多线程重播事件"，而不要选择"显示重播结果"。

重播注意事项

在下列情况下，SQL 事件探查器不能重播跟踪：

  • 跟踪从使用 Windows 身份验证模式与 SQL Server 实例建立的连接中捕获。有关 Windows 身份验证模式的信息，请参见身份验证模式。

  • 跟踪包含复制和其它事务日志活动。

  • 跟踪包含涉及全局唯一标识符 (GUID) 的操作。有关 GUID 的信息，请参见自动编号和标识符列。

  • 跟踪包含涉及 bcp 实用工具、BULK INSERT、READTEXT、WRITETEXT 和 UPDATETEXT 语句以及全文操作的 text、ntext 和 image 列上的操作。

  • 跟踪包含会话绑定：sp_getbindtoken 和 sp_bindsession 系统存储过程。

另外，SQL 事件探查器不能重播包含 SQL Server 6.5 服务器端游标语句 (sp_cursor) 的 SQL 跟踪程序 .log 文件。

如果没有将 Binary Data 数据列也捕获在跟踪内，重播包含会话事件类（Connect、Disconnect 和 Existing Connection）的跟踪时可能会发生异常结果或重播错误。会话事件类的 Binary Data 数据列包含设置 ANSI null、ANSI padding、cursor close on commit、concat null yields null 和 quoted identifier 等会话设置所需的信息。有关更多信息，请参见 SET。

SQL 事件探查器在重播包含并发连接的跟踪时为每个连接创建线程。因此，如果跟踪包含许多并发连接，重播跟踪的计算机的系统性能会受到影响。为减小对系统性能的影响，通过指定 Application Name、SQL User Name 或跟踪内捕获的其它数据列的值来筛选跟踪，以将跟踪限制在那些需要监视的事件上。

说明 如果不使用提供的重播模板 (SQLProfiler TSQL-Replay)，则在捕获当前数据库上下文时可能会遇到困难。有关更多信息，请参见 SQL 事件探查器疑难解答。

重播跟踪表

事件探查器

事件探查器

请参见

bcp 实用工具

BULK INSERT

全文索引

READTEXT

sp_defaultdb

UPDATETEXT

WRITETEXT


单步跟踪

SQL 事件探查器使您得以不必从头至尾全部重播跟踪内的所有事件，而按下面的方式重播跟踪：

  • 一次重播一个事件

    通过一次一个事件地重播跟踪，可以检查每个事件发生后的效果。使用单步跟踪继续重播跟踪时，重播下一个事件后跟踪再次暂停。

  • 重播到断点

    通过在跟踪内指定一个或多个断点，可以按重播选项指定的设置，重播带断点标记的事件之前的所有事件，无须用户干预，播完后跟踪重播将暂停。跟踪重播可以继续按一次一个事件、到下一个断点（若有）、到游标或到跟踪的结束处等方式重播跟踪。如果在重播跟踪时不想检查断点前的每个事件，则重播跟踪到断点的方式很有用。例如，已经调试了代码并确定了断点前的所有事件都按预期执行，不需要进一步检查这些事件。

  • 重播到游标

    通过重播跟踪到游标（跟踪内的突出显示事件），可重播突出显示事件前的所有事件，无须用户干预。但是，如果在跟踪内标记了一个断点，而这个断点位于游标和跟踪内下一个执行点之间，重播将在这个断点处停止，而不会继续重播到游标。删除跟踪内的所有断点以重播跟踪到游标。与断点一样，如果在重播跟踪时不想检查游标前的每个事件，重播跟踪到游标很有用。

单步跟踪有助于调试跟踪内捕获的事件。例如，可以创建一个跟踪，监视所有提交的批处理的执行。通过一次一个事件地（单步）重播跟踪内的事件，可以确定每个批处理发生时的效果，使您得以调试代码。这比在批处理间放置大量的调试代码有效得多。调试代码通常会产生更多需要从生成的实际结果中分离出来的输出，完成调试后必须正确地删除这些输出。

一次重播一个事件

事件探查器

事件探查器

重播到断点

事件探查器

事件探查器

重播到游标

事件探查器


删除跟踪

删除跟踪会是将其永久地删除。只应删除那些不再需要的跟踪。在删除跟踪前必须先停止它。

也可以不删除跟踪，而选择暂停或停止跟踪。有关更多信息，请参见启动、暂停和停止跟踪。

删除跟踪

Transact-SQL


SQL 事件探查器性能考虑

下面是一些有助于更有效地使用 SQL 事件探查器的提示和技巧。

运行的跟踪过多

如果 Microsoft® SQL Server™ 实例运行得过慢，则表明可能 SQL 事件探查器运行的跟踪过多或正在运行复杂的跟踪。停止任何运行的跟踪以观察性能是否有所提高。如果停止跟踪可使性能提高，则请仔细检查跟踪以确保只跟踪必要的信息。确保没有同时运行过多的复杂跟踪。

管理大跟踪文件

大跟踪文件会占用大量磁盘空间，在网络上发送时会很慢，也很昂贵。通过删除不必要的事件类型和/或数据列，并应用筛选将跟踪限制为特定的跟踪事件准则（如 ClientProcessID 或 SPID，或 Application Name 的值的集合），减小保存的跟踪文件的大小。使用相同的名称或新的名称保存跟踪文件。

警告 使用相同的名称保存跟踪文件将重写原来的文件，这将导致任何当初捕获的事件或已删除或筛选的数据列丢失。


使用系统监视器进行监视

如果运行的是 Microsoft® Windows® 2000 操作系统，则使用系统监视器（Microsoft Windows NT® 4.0 中的性能监视器）测量 Microsoft SQL Server™ 的性能。可以查看 SQL Server 对象和性能计数器以及其它对象的行为，这些对象包括处理器、内存、高速缓存、线程和进程。每个对象都有一个相关的的计数器集，用于测量设备使用情况、队列长度、延时情况，另外还有吞吐量及内部拥塞指示器。

系统监视器使获得最新的 SQL Server 活动及性能统计信息成为可能。使用这个图形界面工具，可以：

  • 同时查看任意多台计算机中的数据。

  • 查看及更改图表以反映当前的活动，以及显示计数器的值（该值按用户定义的频率进行更新）。

  • 从图表、日志、警报日志和报表向电子表格或数据库应用程序中导出数据，以便进一步操作或打印。

  • 添加系统警报，这些警报在警报日志中列出一个事件，并可以通过显示"警报"视图或发出网络警报通知您。

  • 在计数器值第一次或每次超过或低于用户定义的值时，运行一个预先定义的应用程序。

  • 创建日志文件，这些日志文件包含有关来自不同计算机的各种对象的数据。

  • 将其它现有日志文件中的选定区域追加到一个文件上，以形成长期存档。

  • 查看当前活动的报表，或从现有日志文件中创建报表。

  • 保存单独的图表、警报、日志或报表设置或整个工作区设置，以备必要时再次使用。

    说明 可以使用系统监视器或性能监视器执行这些任务。

有关 Windows NT 4.0和 Windows 2000 对象和计数器的信息，请参见 Windows NT 4.0 和 Windows 2000 文档。


监视磁盘活动

Microsoft® SQL Server™ 使用 Microsoft Windows NT® 4.0 或 Windows®2000I/O 调用来执行磁盘读写操作。SQL Server 对何时及如何执行磁盘 I/O 进行管理，而 Windows 操作系统执行基础的 I/O 操作。I/O 子系统包括系统总线、磁盘控制卡、磁盘、磁带驱动器、CD_ROM 驱动器以及许多其它 I/O 设备。 磁盘 I/O 是导致系统瓶颈的最常见的原因。

监视磁盘 I/O 及检测过度换页

可以对下面两个计数器进行监视以确定磁盘活动：

  • PhysicalDisk:% Disk Time

  • PhysicalDisk:平均Disk Queue Length

在系统监视器（Windows NT 4.0 中的性能监视器）中，PhysicalDisk:% Disk Time 计数器监视磁盘忙于读/写活动所用时间的百分比。如果 PhysicalDisk:% Disk Time 计数器的值很高（大于 90%），检查 PhysicalDisk:Current Disk Queue Length 计数器，看有多少系统请求在等待访问磁盘。等待 I/O 请求的数量，应该保持在不超过组成物理磁盘的轴数的 1.5 到 2 倍。大多数磁盘只有一个轴，但独立磁盘冗余阵列 (RAID) 设备通常有多个轴。硬件 RAID 设备在系统监视器中显示为一个物理磁盘；通过软件创建的 RAID 设备显示为多个实例。

用 Current Disk Queue Length 和 % Disk Time 计数器的值可以检测磁盘子系统中的瓶颈。如果 Current Disk Queue Length 和 % Disk Time 计数器的值一直很高，则考虑下列事项：

  • 使用速度更快的磁盘驱动器。

  • 将某些文件移到其它磁盘或服务器。

  • 如果正在使用一个 RAID 阵列，则在该阵列中添加另外的磁盘。

如果正使用一个 RAID 设备，% Disk Time 计数器可能会显示一个大于100% 的值。如果是这样，用 PhysicalDisk:Avg.Disk Queue Length 计数器确定平均有多少系统请求正在等待访问磁盘。

I/O 依赖的应用程序或系统可能会使磁盘持续处于活动状态。

监视 Memory:Page Faults/sec 计数器以保证磁盘活动不是由换页造成的。在 Windows NT 4.0 或 Windows 2000 中，换页的原因有：

  • 配置进程的占用了过多的内存。

  • 文件系统活动。

如果在同一硬盘上有多个逻辑分区，使用 Logical Disk 计数器而非 Physical Disk 计数器。查看逻辑磁盘计数器有助于确定哪些文件被频繁访问。当发现磁盘有大量读/写活动时，查看读写专用计数器（如 Logical Disk:Disk Write Bytes/sec），确定导致每个逻辑卷负荷增加的磁盘活动类型。

隔离 SQL Server 产生的磁盘活动

要确定由 SQL Server 组件产生的 I/O 操作量，检查以下操作的性能：

  • 向磁盘写入页

  • 从磁盘读取页

SQL Server 执行的页读写数可用 SQL Server:Buffer Manager Page Reads/sec 和 Page Writes/sec 计数器进行监视。若这些计数器的值将要达到硬件 I/O 子系统的容量极限，则需要减小这些值，方法是调整应用程序或数据库以减少 I/O 操作（如索引覆盖、索引优化或规范化），增加硬件的 I/O 容量或添加内存。


监视 CPU 的使用

定期监视 Microsoft® SQL Server™ 实例以确定 CPU 使用率是否在正常范围内。持续的高 CPU 使用率可能表明 CPU 需要升级或需要增加多个处理器。或者，高 CPU 使用率也可能表明应用程序的调整或设计不良。优化应用程序可以降低 CPU 的使用率。

确定这个的一个好方法是使用系统监视器（Microsoft Windows NT® 4.0 中的性能监视器）中的 Processor:% Processor Time 计数器。该计数器监视 CPU 处理非闲置线程所用的时间。持续 80% 到 90% 的状态可能表明需要 CPU 升级或需要增加更多的处理器。对于多处理器系统，应该为每个处理器监视一个该计数器的独立实例。这一数值代表了在一个特定处理器上的处理器时间之和。要确定所有处理器的平均时间，请用 System:%Total Processor Time 计数器。

也可监视：（可选）

  • Processor:% Privileged Time

    该计数器对应于处理器执行 Windows NT 4.0 或 Microsoft Windows® 2000 内核命令（如处理 SQL Server I/O 请求）所用时间的百分比。如果 Physical Disk 计数器的值很高时该计数器的值也一直很高，则考虑使用速度更快或效率更高的磁盘子系统。

    说明 不同的磁盘控制器和驱动程序所用的内核处理时间不同。高效的控制器和驱动程序所用的特权时间较少，可留出更多的处理器时间给用户应用程序，从而提高总体的吞吐量。

  • Processor:%User Time

    这一计数器值是处理器执行用户进程（如 SQL Server 进程）所用时间的百分比。

  • 系统:Processor Queue Length

    这一计数器表示等待处理器时间的线程数。当一个进程的线程需要的处理器循环数超过可获得的循环数时，就产生了处理器瓶颈。如果有很多进程在争用处理器时间，也许需要安装一个速度更快的处理器，或者如果使用的是多处理器系统则再增加一个处理器。

当检查处理器使用情况时，需考虑 SQL Sever 实例正在执行的工作类型。如果 SQL Server 正在做大量的运算，如包含聚合的查询，或不需要进行磁盘 I/O 的内存依赖查询，此时所用的处理器时间可能是 100%。如果这导致其它应用程序的性能下降，应尝试改变工作负荷，如让计算机只运行 SQL Server 实例。

若此数值为 100% 左右（表示有大量的客户端请求在处理），可能表示进程正在排队，等待处理器时间，并因而导致瓶颈出现。可以通过增加处理能力更强的处理器来解决这一问题。


监视内存的使用

定期监视 Microsoft® SQL Server™ 实例，确认内存的使用在正常范围内，并且没有进程（包括 SQL Server）缺少内存或消耗太多的内存。

若要监视内存不足情况，可从下列对象计数器开始：

  • Memory:Available Bytes

  • Memory:Pages/sec

Available Bytes 计数器表示当前进程可使用的内存字节数。Pages/sec 计数器表示由于缺页处理而从磁盘取回的页数，或由于缺页处理而写入磁盘以释放工作集空间的页数。

偏低的 Available Bytes 计数器值表示计算机从总体上短缺内存或一个应用程序没有释放内存。高比率的 Pages/sec 计数器值可能表示换页过度。监视 Memory:Page Faults/sec 计数器以保证磁盘活动不是由换页造成的。

换页率偏低（以及由此产生的换页错误）是正常的，即使计算机有大量的可用内存。Microsoft Windows NT® 虚拟内存管理器 (VMM) 在调整 SQL Server 和其它进程的工作集大小时，会盗用这些进程的页，从而导致换页错误。若要确定是 SQL Server 而非其它进程导致过度换页，请监视 Process:Page Faults/sec 计数器。

有关解决过多换页的更多信息，请参见 Windows NT 4.0 或 Microsoft Windows® 2000 文档。

隔离 SQL Server 所用的内存

默认情况下，SQL Server 会依据可获得的系统资源动态改变它的内存需求。如果 SQL Server 需要更多的内存，它会要求操作系统确定是否有空闲的物理内存可用，并使用可用的内存。若 SQL Server 不再需要当前分配给它的内存，它就将内存释放给操作系统。不过，可以用 min server memory、max server memory 和 set working set size 服务器配置选项替代动态使用内存的选项。有关更多信息，请参见服务器内存选项。

若要监视 SQL Server 正在使用的内存量，请检查下列性能计数器：

  • Process:Working Set

  • SQL Server:Buffer Manager:Buffer Cache Hit Ratio

  • SQL Server:Buffer Manager: Total Pages

  • SQL Server:Memory Manager:Total Server Memory (KB)

Working Set 计数器表示的是一个进程所占用的内存数量。若这一数值持续低于 SQL Server 配置使用的内存数量(由"最小服务器内存"和"最大服务器内存"服务器选项设置)，则表示 SQL Server 所配置的内存比它所需要的多。否则，用"设置工作集大小"服务器选项修改工作集大小。有关更多信息，请参见 set working set size 选项。

Buffer Cache Hit Ratio 计数器值依应用程序而定，但比率最好为 90% 或更高。增加内存直到这一数值持续高于 90%，表示 90% 以上的数据请求可以从数据缓冲区中获得所需数据。

若 Total Server Memory (KB) 计数器值与计算机的物理内存大小相比一直很高，可能表示需要更多的内存。


创建 SQL Server 数据库警报

使用系统监视器（Microsoft® Windows NT® 4.0 中的性能监视器），可以创建在达到系统监视器计数器的阈值时发出的警报。作为对警报的响应，系统监视器会启动一个应用程序，比如为处理警报情况而编写的自定义应用程序。例如，可以创建一个警报，在死锁数超过一个特定值时发出。

说明 性能条件警报只供最前面的 99 个数据库使用。接在最前面的 99 个数据库之后创建的任何数据库都不包括在 sysperfinfo 系统表中，并且，使用 sp_add_alert 过程会返回一个错误。

也可以用 SQL Server 企业管理器 和 SQL Server 代理程序定义警报。有关更多信息，请参见定义警报。

使用系统监视器设置 SQL Server 数据库警报

Windows 2000

Windows

有关使用系统监视器创建警报的更多信息，请参见 Microsoft Windows® 2000 文档。

使用性能监视器设置 SQL Server 数据库警报

Windows NT

Windows NT

有关使用性能监视器创建警报的更多信息，请参见 Windows NT 4.0 文档。

请参见

sp_add_alert

sysperfinfo


系统监视器方案

当监视 Microsoft® SQL Server™ 和操作系统以调查与性能有关的问题时，需首先集中在下面三个主要方面：

  • 磁盘活动。

  • 处理器使用率。

  • 内存使用。

在监视 Microsoft Windows NT® 4.0 或 Microsoft Windows® 2000 及 SQL Server 的同时，确定 SQL Server 性能和 Windows NT 4.0 或 Windows 2000 之间的相关性会很有用。例如，在监视 Windows NT 4.0 或 Windows 2000 磁盘 I/O 计数器及 SQL Server 缓冲区管理器的同时，可以显示整个系统的行为。

使用系统监视器（Windows NT 4.0 中的性能监视器）监视计算机对计算机的性能会有一点影响。因此，将系统监视器数据记录到另一个磁盘或计算机上，以减少对所监视计算机的影响，或者远程运行系统监视器。只监视您感兴趣的计数器。监视太多的计数器将增加监视进程的开销，并会影响所监视的计算机，还可能会影响结果。


运行系统监视器

系统监视器（Windows NT 4.0 中的性能监视器）使用远程过程调用 (RPC) 从 Microsoft SQL Server™ 中收集信息。任何经 Microsoft Windows® 2000 授权可运行系统监视器的用户都可用它监视 SQL Server。

说明 使用系统监视器或性能监视器时，不能连接到在 Microsoft Windows 98 下运行的 SQL Server 实例。

与用所有性能监视工具一样，用系统监视器对 SQL Server 进行监视时，需要一些性能方面的开销。在任何特定实例上的实际开销取决于硬件平台、计数器数量以及选定的更新时间间隔。但是，将系统监视器与 SQL Server 集成旨在尽量减少负面影响。

启动系统监视器

Windows

Windows

启动性能监视器

Windows


创建图表、警报、日志和报表

系统监视器（Microsoft® Windows NT® 4.0 中的性能监视器）允许创建图表、警报、日志和报表以监视 Microsoft® SQL Server™ 实例。

图表

图表可监视选定的对象和计数器的当前性能（如，CPU 使用情况或磁盘 I/O）。在图表中不仅可以添加系统监视器对象和计数器的各种组合，还可以添加 Windows NT 4.0 或 Microsoft Windows® 2000 对象和计数器的各种组合。

每个图表表示要监视的信息的一个子集。例如，第一个图表可跟踪内存使用统计信息，第二个图表可跟踪磁盘 I/O 统计信息。

图表的用途：

  • 分析一台计算机或一个应用程序运行缓慢或效率低下的原因。

  • 连续监视系统，以找出间歇性性能问题。

  • 找出需提高处理能力的原因。

  • 用折线图显示一种趋势。

  • 用柱状图显示比较结果。

图表对于短期、实时监视本地或远程计算机很有用，例如，希望在事件发生时对其进行监视。

警报

利用警报，系统监视器可跟踪特定的事件，并按要求向您通知这些事件。警报日志可以监视针对 SQL Server 中对象所选定的计数器和实例的当前性能。当计数器超过给定值时，日志记录下这一事件的日期和时间。事件也可产生网络警报。可在一个事件第一次出现或每次出现时运行一个特定的程序。例如，一个警报可以给所有的系统管理员发出一条网络消息，报告 SQL Server 实例的磁盘空间不足。

日志

日志可以记录选定对象和计算机的当前活动信息，以便日后查看和分析。可以将多个系统的数据收集到一个日志文件中。例如，可以创建各种日志文件，以积累各种计算机上所选对象的性能信息，供将来分析。可以在一个文件名下保存这些选择，当要创建另一用于比较的、具有相似信息的日志时再次使用它们。

日志文件提供丰富的信息，用于故障处理和系统规划。针对当前活动的图表、警报和报表提供即时的反馈，而日志文件可用于长期跟踪计数器，从而可更彻底地检查信息，记录系统性能。

报告

报表可对选定对象显示不断变化的计数器和实例值。每个实例的值记录在列中。可调整报表时间间隔、打印快照和导出数据。当需要显示原始数据时可使用报表。

有关图表、警报、日志和报表或有关 Windows NT 4.0 或 Windows 2000 对象和计数器的更多信息，请参见 Windows 4.0 或 Windows 2000 文档。


使用 SQL Server 对象

Microsoft® SQL Server™ 提供可由系统监视器（Microsoft Windows NT® 4.0 中的性能监视器）使用的对象和计数器，以监视运行 SQL Server 实例的计算机的活动。对象是任何 Windows NT 4.0、Microsoft Windows® 2000 或 SQL Server 资源，比如 SQL Server 锁或 Windows NT 4.0 或 Windows 2000 进程。每个对象有一个或多个计数器，用于确定所要监视对象的各方面信息。例如，SQL Server object 对象有名为 Number of Deadlocks/sec 或 Lock Timeouts/sec 的计数器。

如果在计算机上有某一个给定资源类型的多个资源，一些对象会有几个实例。例如，若一个系统有多个处理器，Processor 对象类型会有多个实例。SQL Server 上对每个数据库会有一个 Databases 对象类型的实例。一些对象类型（如，Memory Manager 对象）只有一个实例。如果一个对象类型有多个实例，可以增加计数器，以跟踪每个实例的统计数值，或在许多情况下，同时跟踪所有实例的统计信息。

说明 性能条件警报只供最前面的 99 个数据库使用。接在最前面的 99 个数据库之后创建的任何数据库都不包括在 sysperfinfo 系统表中，并且，使用 sp_add_alert 过程会返回一个错误。

通过在图表中增加或删除计数器并保存图表设置，可以指定系统监视器启动时所监视的 SQL Server 对象和计数器。

SQL Server 对象 | 计数器
SQL Server:Buffer Manager | Buffer Cache Hit Ratio
SQL Server:General Statistics | User Connections
SQL Server:Memory Manager | Total Server Memory (KB)
SQL Server:SQL Statistics | SQL Compilations/sec
SQL Server:Buffer Manager | Page Reads/sec
SQL Server:Buffer Manager | Page Writes/sec

可以配置系统监视器显示任何 SQL Server 计数器中的统计信息。另外，可以为任何 SQL Server 计数器设一个阈值，当计数器超过阈值时产生一个警报。有关设置警报的更多信息，请参见创建 SQL Server 数据库警报。

说明 SQL Server 统计信息只有在运行 SQL Server 实例时才显示。如果停止并重新启动 SQL Server 实例，SQL Server 统计信息的显示将中断，然后自动恢复。

以下是 SQL Server 对象。

SQL Server 对象 | 描述
SQL Server:Access Methods | 搜索并测量 SQL Server 数据库对象的分配（例如，索引搜索数或分配给索引和数据的页数）。
SQL Server:Backup Device | 提供有关备份和还原操作使用的备份设备的信息，如备份设备的吞吐量。
SQL Server:Buffer Manager | 提供有关 SQL Server 所用的内存缓冲区的信息，如可用内存和 buffer cache hit ratio。
SQL Server:Cache Manager | 提供有关 SQL Server 高速缓存的信息，该高速缓存用于存储如存储过程、触发器和查询计划这样的对象。
SQL Server:Databases | 提供有关 SQL Server 数据库的信息，如可用的日志空间数量或数据库中活动事务数。这个对象可有多个实例。
SQL Server:General Statistics | 提供有关服务器范围内的常规活动的信息，如连接到 SQL Server 实例的用户数。
SQL Server:Latches | 提供有关加在 SQL Server 所用的内部资源（如数据库页）上的闩锁的信息。
SQL Server:Locks | 提供有关 SQL Server 的单个锁请求的信息，如锁超时和死锁。这个对象可有多个实例。
SQL Server:Memory Manager | 提供有关 SQL Server 内存的使用信息，如当前分配的锁结构总数。
SQL Server:Replication Agents | 提供有关正在运行的 SQL Server 复制代理程序的信息。
SQL Server:Replication Dist. | 测量由分发代理程序从分发数据库中读出并传送到订阅服务器数据库的命令和事务数。
SQL Server:Replication Logreader | 测量由日志读取器代理程序从发布的数据库中读出并传送给分发数据库的命令和事务数。
SQL Server:Replication Merge | 提供有关 SQL Server 合并复制的信息，如产生的错误数，或从订阅服务器合并到发布服务器的复制行的数量。
SQL Server:Replication Snapshot | 提供有关 SQL Server 快照复制的信息，如从发布数据库大容量复制的行数。
SQL Server:SQL Statistics | 提供有关 SQL查询各个方面的信息，如 SQL Server 收到的 Transact-SQL 语句的批数。
SQL Server:User Settable Object | 执行自定义监视。每个计数器可以是一个自定义的存储过程或任何返回一个被监视值的 Transact-SQL 语句。


SQL Server:Access Methods 对象

Microsoft® SQL Server™ 中的 Access Methods 对象提供计数器，用于监视访问数据库中的逻辑页的方法。用 Buffer Manager 计数器监视对磁盘上的数据库页的物理访问。通过监视访问数据库页的方法，有助于确定是否可以通过增加或修改索引或重写查询来提高查询性能。Access Methods 计数器也可用于监视数据库中数据、索引和可用空间的数量，从而指示数据卷和碎片（过多的碎片会降低性能）。

下面是 SQL Server 的 Access Methods 计数器。

SQL Server Access Methods 计数器 | 描述
Extent Deallocations/sec | 每秒从存储索引或数据记录的数据库对象中释放的扩展盘区数。
Extents Allocated/sec | 每秒分配给存储索引或数据记录的数据库对象的扩展盘区数。
Forwarded Records/sec | 每秒通过正向记录指针提取的记录数。
FreeSpace Page Fetches/sec | 每秒由可用空间扫描返回的页数，该扫描是为满足插入记录片段的请求而进行的。
FreeSpace Scans/sec | 每秒为查找可用空间而进行的扫描次数，该空间用来插入新的记录片段。
Full Scans/sec | 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。
Index Searches/sec | 每秒索引搜索数。用于启动区域扫描和单索引记录提取，以及改变索引的位置。
Mixed Page Allocations/sec | 每秒从混合扩展盘区分配的页数。用于存储分配给一个索引或表的前八页。
Page Deallocations/sec | 每秒从存储索引或数据记录的数据库对象中释放的页数。
Page Splits/sec | 每秒由于索引页溢出而发生的页拆分的数量。
Pages Allocated/sec | 每秒分配给存储索引或数据记录的数据库对象的页数。
Probe Scans/sec | 每秒的探测扫描数。用于直接在一个索引或基本表中查找行。
Range Scans/sec | 每秒通过索引进行的、满足一定条件的区域扫描数。
Scan Point Revalidations/sec | 每秒必须对扫描点重新验证的次数（以便继续进行扫描）。
Skipped Ghosted Records/sec | 在扫描过程中每秒跳过的幻影记录数。
Table Lock Escalations/sec | 表中的锁的升级次数。
Workfiles Created/sec | 每秒创建的工作文件数。
Worktables Created/sec | 每秒创建的工作表数。
Worktables From Cache Ratio | 所创建的、初始页立即可在工作表高速缓存中使用的工作表的百分比。

请参见

索引

页和扩展盘区


SQL Server:Backup Device 对象

Backup Device 对象提供计数器，监视用于备份和还原操作的 Microsoft® SQL Server™ 备份设备。当想基于每个设备确定吞吐量或备份和还原操作的进度及性能时，监视备份设备。若要监视整个数据库备份或还原操作的吞吐量，可用 SQL Server Databases 对象的 Backup/Restore Throughput/sec 计数器。有关更多信息，请参见 SQL Server:Databases 对象。

以下是 SQL Server Backup Device 计数器。

SQL Server Backup Device 计数器 | 描述
Device Throughput Bytes/sec | 一个备份设备在备份或还原数据库时所用的读写操作的吞吐量（以每秒字节数表示）。这一计数器只有在备份或还原操作执行时才存在。

请参见

备份设备


SQL Server:Buffer Manager 对象

Buffer Manager 对象提供计数器以监视 Microsoft® SQL Server™ 如何使用：

  • 内存存储数据页、内部数据结构和过程高速缓存。

  • 计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O。

监视 SQL Server 所使用的内存和计数器有助于确定：

  • 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。

  • 是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。

  • SQL Server 需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。

还可以用 AWE 计数器监视 SQL Server 中的 Microsoft Windows® 2000 地址窗口扩展 (AWE) 活动。例如，可以确保 SQL Server 有足够的内存分配给 AWE，使其正常运行。有关更多信息，请参见使用 Windows 2000 上的 AWE 内存或 awe enabled 选项。

以下是 SQL Server Buffer Manager 计数器。

SQL Server Buffer Manager 计数器 | 描述
AWE Lookup Maps/sec | 数据库页被服务器请求、在缓冲池中找到和映射的次数。数据库页映射后便成为服务器虚拟地址空间的一部分。
AWE Stolen Maps/sec | 缓冲区被从可用列表中取出和映射的次数。
AWE Unmap Call/Sec | 对未映射缓冲区的调用次数。缓冲区若未映射，将被排除在虚拟服务器地址空间的范围之外。每次调用时可能有一个或多个缓冲区未映射。
AWE Unmap Pages/Sec | 未映射的 SQL Server 缓冲区数。
AWE Write Maps/Sec | 必须映射到脏缓冲区中的次数，经过该次数后才能写入磁盘。
Buffer Cache Hit Ratio | 可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后，这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。通常，可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。
Checkpoint pages/sec | 由要求刷新所有脏页的检查点或其它操作每秒刷新到磁盘的页数。
Database pages | 缓冲池中有数据库内容的页的数目。
Free list stall/sec | 必须等待可用页的请求数目。
Free pages | 所有可用列表页总数。
Lazy Writes/sec | 每秒被缓冲区管理器的惰性写入器写入的缓冲区数。惰性写入器是一个系统进程，其主要任务是刷新成批的老化的脏缓冲区（指包含更改的缓冲区，这些更改必须写回磁盘，才能使该缓冲区由其它页重新使用），并使之可由用户进程使用。 惰性写入器消除了为创建可用缓冲区而频繁执行检查点的需要。
Page life expectancy | 页若不被引用将在缓冲区池中停留的秒数。
Page lookups/sec | 在缓冲区池中查找页的请求次数。
Page Reads/sec | 每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
Page Writes/sec | 所发出的物理数据库页写入的数目。
Procedure cache pages | 用于存储已编译查询的页的数目。
Readahead Pages/sec | 预期使用时读取的页的数目。
Reserved Pages | 缓冲区池保留的页的数目。
Stolen Pages | 用来满足其它服务器功能的页的数目（包括过程高速缓存）。
Target Pages | 缓冲池中理想的页的数目。
Total Pages | 缓冲区池中页的数目（包括数据库、可用页和被盗用页）。

请参见

页和扩展盘区

服务器内存选项

SQL Server:Cache Manager 对象


SQL Server: Buffer Partition 对象

Buffer Partition 对象提供用于监视 Microsoft® SQL Server™ 如何使用可用页的计数器。

SQL Server Buffer Partition 计数器 | 描述
Free list empty/sec | 请求可用页但没有使用的次数。
Free list requests/sec | 可用页被请求的次数。
Free pages | 所有可用列表页总数。


SQL Server:Cache Manager 对象

Cache Manager 对象提供计数器，用于监视 Microsoft® SQL Server™ 如何使用内存存储对象，如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。可同时监视 Cache Manager 对象的多个实例，每个实例代表一个要监视的不同类型的计划。

高速缓存管理器实例 | 描述
特殊SQL计划 | 由一个特殊 Transact-SQL 查询产生的查询计划，包括自动参数化的查询。SQL Server 将特殊 SQL 语句的计划存入高速缓存，以便将来需要执行同样的 Transact-SQL 语句时再次使用。
各种规范化树 | 视图、规则、计算列和检查约束的规范化树。
准备好的SQL计划 | 用sp_prepare、sp_cursorprepare 或自动参数化准备好的、与 Transact-SQL 语句对应的查询计划。用户参数化的查询（即使未显式准备）也作为准备好的 SQL 计划监视。
过程计划 | 通过创建存储过程而产生的查询计划。
复制过程计划 | 复制系统的存储过程的查询计划。
触发器计划 | 通过创建触发器而产生的查询计划。

下面是 SQL Server Cache Manager 计数器。

SQL Server Cache Manager 计数器 | 描述
Cache Hit Ratio | 高速缓存命中次数和查找次数的比率。
Cache Object Counts | 高速缓存中高速缓存的对象数。
Cache Pages | 高速缓存对象所使用的 8 (KB) 页的数目。
Cache Use Counts/sec | 每类高速缓存对象已使用的次数。

有关高速缓存查询计划的更多信息，请参见执行计划的高速缓存和重新使用。

请参见

服务器内存选项

SQL Server:Buffer Manager 对象


SQL Server:Databases 对象

Microsoft® SQL Server™ 中的 Databases 对象提供计数器，用于监视大容量复制操作、备份及还原吞吐量和事务日志活动。监视事务及事务日志确定数据库中进行的用户活动数量及事务日志的饱满程度。用户活动数量可以确定数据库的性能并影响日志大小、锁和复制。监视低级日志活动以估计用户活动和资源使用情况，有利于查明性能瓶颈。

可以同时监视 Databases 对象的多个实例，每个实例代表一个数据库。

下面是 SQL Server Databases 计数器。

SQL Server Databases 计数器 | 描述
Active Transactions | 数据库的活动事务数。
Backup/Restore Throughput/sec | 每秒一个数据库的备份和还原操作的读/写吞吐量。例如，当多个备份设备同时使用或当使用更快的设备时，可以测量数据库备份操作性能的变化情况。数据库的备份或还原操作的吞吐量可以确定备份和还原操作的过程和性能。
Bulk Copy Rows/sec | 每秒大容量复制的行数。
Bulk Copy Throughput/sec | 每秒大容量复制的数据量 (KB)。
Data File(s) Size (KB) | 数据库中所有的数据文件的累计大小 (KB)，包括任何自动增长。监视这一计数器非常有用，例如，可以确定 tempdb 的正确大小。
DBCC Logical Scan Bytes/sec | 数据库一致性检查器 (DBCC) 语句每秒逻辑读扫描的字节数。
Log Bytes Flushed/sec | 刷新的日志字节总数。
Log Cache Hit Ratio | 日志高速缓存所满足的日志高速缓存读取的百分比。
Log Cache Reads/sec | 每秒通过日志管理器高速缓存进行的读取。
Log File(s) Size (KB) | 数据库中所有的事务日志文件的累计大小 (KB)。
Log File(s) Used Size (KB) | 数据库中全部日志文件的已用部分累积大小。
Log Flush Wait Time | 为刷新日志而花费的总等待时间（毫秒）。
Log Flush Waits/sec | 每秒等待日志刷新的提交数。
Log Flushes/sec | 每秒日志刷新数。
Log Growths | 数据库事务日志增长的总次数。
Log Shrinks | 数据库事务日志收缩的总次数。
Log Truncations | 数据库事务日志截断的总次数。
Percent Log Used | 正在使用的日志中的剩余空间百分比。
Repl.Pending Xacts | 发布数据库事务日志中已做复制标记，但还未传送给分发数据库的事务个数。
Repl. Trans. Rate | 每秒从发布数据库事务日志中读出，并传送给分发数据库的事务个数。
Shrink Data Movement Bytes/sec | 每秒由自动收缩操作或由 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 语句移动的数据量。
Transactions/sec | 每秒为数据库启动的事务数。

请参见

事务日志

事务


SQL Server:General Statistics 对象

Microsoft® SQL Server™ 中的 General Statistics 对象提供计数器，用于监视服务器范围内的常规活动，如当前的连接数以及每秒与运行 SQL Server 实例的计算机连接和断开的用户数。这在大型联机事务处理 (OLTP) 类型系统（该系统中有很多客户端与 SQL Server 实例连接和断开连接）上工作时会很有用。

以下是 SQL Server General Statistics 计数器。

SQL Server General Statistics 计数器 | 描述
Logins/sec | 每秒启动的登录数。
Logouts/sec | 每秒开始的注销操作总数。
User Connections | 用户连接数。由于每个用户连接都消耗一些内存，配置的用户连接数过高会影响吞吐量。将用户连接数设置为预期的最大并发用户数。


SQL Server:Latches 对象

Microsoft® SQL Server™ 中的 Latches 对象提供计数器，用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。

以下是 SQL Server Latches 计数器。

SQL Server Latches 计数器 | 描述
Average Latch Wait Time (ms) | 必须等待的闩锁请求的平均闩锁等待时间（毫秒）。
Latch Waits/sec | 不能立即授予的闩锁请求数。
Total Latch Wait Time (ms) | 闩锁请求在最后一秒内的闩锁总等待时间（以毫秒为单位）。

请参见

闩锁


SQL Server:Locks 对象

Microsoft® SQL Server™ 中的 Locks 对象提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。例如，如果一个排它 (X) 锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。尽可能少使用锁可提高并发性，从而改善性能。可以同时监视 Locks 对象的多个实例，每个实例代表一个资源类型上的一个锁。

SQL Server 可以锁定以下资源。

项目 | 描述
数据库 | 数据库。
扩展盘区 | 相邻的八个数据页或索引页构成的一组。
键 | 索引中的行锁。
页 | 8 (KB) 数据页或索引页。
RID | 行 ID。用于锁定一个表中的一行。
表 | 包括所有数据和索引在内的整个表。

以下是 SQL Server Locks 计数器。

SQL Server Locks 计数器 | 描述
Average Wait Time (ms) | 每个导致等待的锁请求的平均等待时间（毫秒）。
Lock Requests/sec | 锁管理器每秒请求的新锁和锁转换数。
Lock Timeouts/sec | 每秒超时的锁请求数，包括对 NOWAIT 锁的内部请求。
Lock Wait Time (ms) | 锁在最后一秒内的总等待时间（毫秒）。
Lock Waits/sec | 每秒要求调用者等待的锁请求数。
Number of Deadlocks/sec | 每秒导致死锁的锁请求数。

请参见

SQL Server 中的锁定介绍


SQL Server:Memory Manager 对象

Microsoft® SQL Server™ 中的 Memory Manager 对象提供计数器，用于监视总体的服务器内存使用情况。监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定：

  • 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。

  • 是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。

以下是 SQL Server Memory Manager 计数器。

SQL Server Memory Manager 计数器 | 描述
Connection Memory (KB) | 服务器正在用来维护连接的动态内存总量。
Granted Workspace Memory (KB) | 当前给予执行哈希、排序、大容量复制和索引创建操作等进程的内存总量。
Lock Blocks | 服务器正在使用的锁块的当前数目（定期进行刷新）。一个锁块代表一个单独的锁定资源，如表、页或行。
Lock Blocks Allocated | 当前分配的锁块数。服务器启动时，分配的锁块数加上分配的锁拥有者块数依赖于 SQL Server Locks 配置选项。若需要更多的锁块，此值会增加。
Lock Memory (KB) | 服务器用于锁的动态内存总量。
Lock Owner Blocks | 当前正在服务器上使用的锁拥有者块的数目（定期进行刷新）。一个锁拥有者块代表一个独立线程对某一对象上的一个锁的拥有权。因此，若三个线程在一个页上各有一个共享 (S) 锁，就会有三个锁拥有者块。
Lock Owner Blocks Allocated | 分配的锁拥有者块的当前块数。服务器启动时，分配的锁拥有者块数和分配的锁块数取决于 SQL Server Locks 配置选项。若需要更多的锁拥有者块，此数值会动态增加。
Maximum Workspace Memory (KB) | 用于执行哈希、排序、大容量复制和索引创建操作等进程的最大可用内存数。
Memory Grants Outstanding | 每秒成功获得一个工作空间内存授权的进程总数。
Memory Grants Pending | 每秒等待获得工作空间内存授权的进程数。
Optimizer Memory (KB) | 服务器正在用于查询优化的动态内存总数。
SQL Cache Memory (KB) | 服务器正在用于动态 SQL 高速缓存的动态内存总数。
Target Server Memory (KB) | 服务器能够使用的动态内存总量。
Total Server Memory (KB) | 服务器当前正在使用的动态内存总量（以 KB 为单位）。

请参见

SQL Server 中的锁定介绍


SQL Server:Replication Agents 对象

Microsoft® SQL Server™ 中的 Replication Agents 对象提供计数器，用于监视当前正在运行的 SQL Server 复制代理程序。监视运行的分发和合并代理程序数，有助于确定发布的数据库正在向多少订户复制数据。可以同时监视 Replication Agents 对象的多个实例，每个实例代表一个复制代理程序（例如，日志读取器、快照、分发及合并）。

以下是 SQL Server Replication Agents 计数器。

SQL Server Replication Agents 计数器 | 描述
Running | 当前正在运行的指定复制代理程序的实例数。


SQL Server:Replication Distribution 对象

Microsoft® SQL Server™ 中的 Replication Dist. 对象提供计数器，用于监视从分发数据库读取并由 SQL Server 分发代理程序传送给订阅服务器数据库的命令和事务数。

以下是 SQL Server Replication Distribution 计数器。

SQL Server Replication Distribution 计数器 | 描述
Dist:Delivered Cmds/sec | 每秒传送到订阅服务器的分发命令数。
Dist:Delivered Trans/sec | 每秒传送到订阅服务器的分发事务数。
Dist:Delivery Latency | 分发滞后时间（毫秒）。事务传送到分发服务器并在订阅服务器上应用所用的时间。

请参见

复制分发代理程序实用工具


SQL Server:Replication Logreader 对象

Microsoft® SQL Server™ 中的 Replication Logreader 对象提供用于监视日志读取器代理程序的计数器。

以下是 SQL Server Replication Logreader 计数器

SQL Server Replication Logreader 计数器 | 描述
Logreader:Delivered Cmds/sec | 每秒传送给分发服务器的日志读取器代理程序命令数。
Logreader:Delivered Trans/sec | 每秒传送给分发服务器的日志读取器代理程序事务数。
Logreader:Delivery Latency | 从事务应用于发布服务器起到它们被传送到分发服务器止，当前所经过的时间，单位为毫秒。

请参见

复制日志读取器代理程序实用工具


SQL Server:Replication Merge 对象

Microsoft® SQL Server™ 中的 Replication Merge 对象提供计数器，用于监视每个 SQL Server 合并执行操作，该操作将数据更改从一个合并复制订阅服务器上移到发布服务器，并从发布服务器下移到订阅服务器。

以下是 SQL Server Replication Merge 计数器。

SQL Server Replication Merge 计数器 | 描述
Conflicts/sec | 发布服务器/订阅服务器上载和下载时每秒出现的冲突数。这一数值应总是为零。出现非零数值时，可能需要报告落选方、替代冲突等等。
Downloaded Changes/sec | 每秒从发布服务器向订阅服务器合并（插入、更新和删除）的行数。
Uploaded Changes/sec | 每秒从订阅服务器向发布服务器合并（插入、更新和删除）的行数。


SQL Server:Replication Snapshot 对象

Microsoft® SQL Server™ 中的 Replication Snapshot 对象提供计数器，用于监视 SQL Server 快照复制。

以下是 SQL Server Replication Snapshot 计数器

SQL Server Replication Snapshot 计数器 | 描述
Snapshot:Delivered Cmds/sec | 每秒传送给分发服务器的命令数。
Snapshot:Delivered Trans/sec | 每秒传送给分发服务器的事务数。

请参见

复制快照代理程序实用工具


SQL Server:SQL Statistics 对象

Microsoft® SQL Server™ 中的 SQL Statistics 对象提供计数器，用于监视发送到 SQL Server 实例的编译和请求类型。通过监视查询编译和重新编译的次数以及 SQL Server 实例收到的批数，可了解 SQL Server 处理用户查询的速度，以及查询优化器处理查询的效率。

编译占一个查询的周转时间的很大部分。高速缓存的目标是通过存储编译过的查询以便再次使用来减少编译，从而在将来执行查询时，不需重新编译它。但是，每个唯一的查询至少需要编译一次。以下因素可造成重新编译查询：

  • 架构更改，包括在表中增加列或索引等基本架构更改，和在表中插入或删除相当数量的行等统计架构更改。

  • 环境(SET 语句)更改。在 ANSI_PADDING 或 ANSI_NULLS 等会话设置中的更改，可能会导致查询的重新编译。

以下是 SQL Statistics 计数器。

SQL Server SQL Statistics 计数器 | 描述
Auto-Param Attempts/sec | 每秒的自动参数化尝试数。其总数应为失败的、安全的和不安全的自动参数化尝试之和。当 SQL Server 实例尝试为以前执行过的查询重新使用高速缓存的计划，而该查询与当前查询相似但又不完全相同时，则会发生自动参数化。有关更多信息，请参见自动参数设置。
Batch Requests/sec | 每秒收到的 Transact-SQL 命令批数。这一统计信息受所有约束（如 I/O、用户数、高速缓存大小、请求的复杂程度等）影响。批请求数值高意味着吞吐量很好。有关更多信息，请参见批处理。
Failed Auto-Params/sec | 每秒自动参数化尝试失败次数。该值应很小。
Safe Auto-Params/sec | 每秒安全自动参数化尝试次数。
SQL Compilations/sec | 每秒的 SQL 编译数。表示编译代码路径被进入的次数。包括由于重新编译而进行的编译。SQL Server 用户活动稳定后，该值也达到某一稳定状态。
SQL Re-Compilations/sec | 每秒的 SQL 重新编译数。计算重新编译被触发的次数。一般来说，重新编译计数器最好保持较低数值。
Unsafe Auto-Params/sec | 每秒不安全的自动参数化尝试次数。此表有防止高速缓存的计划被共享的特性。这些数值被指定为不安全的。

请参见

SQL Server:Cache Manager 对象


SQL Server:User Settable 对象

Microsoft® SQL Server™ 中的 User Settable 对象使您得以创建自定义计数器实例。使用自定义计数器实例，监视服务器上未被现有计数器监视的方面，如您的 SQL Server 数据库独有的组件（例如，已记入日志的顾客订单数或产品存货清单）。

SQL Server User Settable 对象包含查询计数器的 10 个实例：User Counter 1 到 User Counter 10。这些计数器通过 sp_user_counter10 映射到 SQL Server 存储过程 sp_user_counter1。由于这些存储过程是由用户应用程序执行的，所以这些存储过程所设置的值显示在系统监视器中(Microsoft Windows NT® 4.0 中的性能监视器)。计数器可以监视任何单一的整型值，例如，用于计算某产品在一天中获得的订单数的存储过程。

说明 用户计数器存储过程不会由系统监视器自动轮询。它们必须显式地由一个用户应用程序执行，以更新计数器值。使用触发器自动更新计数器的值。例如，要创建一个用于监视表中行数的计数器，在表上创建一个 INSERT 和 DELETE 触发器，执行以下操作：

SELECT COUNT(*) FROM table

每当由于对表进行 INSERT 或 DELETE 操作而激发触发器时，系统监视器计数器就会自动更新。

下面是 SQL Server User Settable 计数器。

SQL Server User User Settable 计数器 | 描述
Query | 由用户定义。

要使用用户计数器存储过程，只需从自己的应用程序中执行它们，并用一个整型参数表示计数器的新值。例如，若要将 User Counter 1 的值设置为 10，执行下面的 Transact-SQL 语句：

EXECUTE sp_user_counter1 10

用户计数器存储过程可从任何可以调用其它存储过程的位置调用，如从自己的存储过程的位置。例如，可以创建以下存储过程，计算自 SQL Server 实例启动后的连接数和尝试连接数：

DROP PROC My_Proc
GO
CREATE PROC My_Proc
AS
   EXECUTE sp_user_counter1 @@CONNECTIONS
GO

@@CONNECTIONS 函数返回自 SQL Server 实例启动后的连接数和尝试连接数。这一数值作为参数传递给 sp_user_counter1 存储过程。

重要 使在用户计数器存储过程中定义的查询尽可能简单。执行大量占用内存且执行相当多的排序或哈希操作的查询，或执行大量 I/O 的查询，开销会很大，并且可能影响性能。


用 SQL Server 企业管理器进行监视

使用 SQL Server 企业管理器查看下列有关当前 Microsoft SQL Server 活动的信息：

  • 当前用户连接和锁。

  • 进程号、状态、锁和活动用户正在运行的命令。

  • 被锁定的对象和当前的锁类型。

若您是系统管理员，可以查看所选进程的附加信息，给当前与运行 SQL Server 实例连接的用户发送消息，或终止所选的进程。

使用 SQL Server 企业管理器中的当前活动窗口，可以对 SQL Server 实例执行特殊监视。这样，一看就可以确定系统上的活动量和活动的一般类型，例如：

  • 当前被阻塞和造成阻塞的事务。

  • SQL Server 实例上当前连接的用户和最后执行的语句。

  • 有效的锁。

SQL Server 活动也可用 sp_who 和 sp_lock 系统存储过程来监视。

以下是当前活动窗口中的图标和图标描述。

图标 | 描述
 | "当前活动"提供特定时间的进程和锁信息。该信息是每次打开或刷新"当前活动"时均会产生的快照。快照的时间显示在左窗格内。"当前活动"提供有关正在运行的进程（连接）、某个连接正在控制或试图获取的锁、以及数据库和表上的当前锁和等待锁的信息。
 | "进程信息"提供有关系统中的当前连接和活动的信息。连接可以处于三种状态：运行、睡眠或后台。另外还会显示数据库环境。有一些服务器进程在 master 数据库联机前启动，因此没有数据库环境。
 | 正在等待锁或用户输入的运行进程。
 | 正在等待锁或用户输入的睡眠进程。
 | 定期唤醒以执行任务的后台进程。SPID 2（锁监视器）、3（惰性写入器）和 6 是后台进程。
 | 正在阻塞一个或多个连接的进程 (SPID)。
 | 被另一个连接阻塞的进程 (SPID)。
 | 未造成阻塞或未被阻塞的进程。
 | 未造成阻塞或未被阻塞的进程。
 | 表锁。若涉及到一个索引，索引名将被列在索引列中。锁定部分的资源定位器显示在资源列中。
 | 数据库锁。

以下是有关"当前活动"窗口中的进程信息的描述。

项目 | 描述
进程 ID | SQL Server 进程 ID。
环境 ID | 用于唯一标识代表单个进程进行操作的子线程的执行上下文 ID。
用户 | 执行命令的用户 ID。
数据库 | 当前由进程使用的数据库。
状态 | 进程的状态（例如，运行、睡眠、可运行和后台）。
打开事务 | 进程的打开事务数。
命令 | 当前正在执行的命令。
应用程序 | 正由进程使用的应用程序名称。
等待时间 | 当前等待时间（以毫秒为单位）。 进程不等待时，等待时间为零。
等待类型 | 表示上次或当前等待类型的名称。
等待资源 | 锁资源的文本化表示法。
CPU | 进程的累计 CPU 时间。当同一会话中的 SET STATISTICS TIME ON 已激活时，只更新代表所执行的 Transact-SQL 语句而执行的进程的项。当已用 SET STATISTICS TIME ON 执行了查询时，则更新 CPU 列。返回零时，SET STATISTICS TIME 为 OFF。
物理 IO | 进程的累计磁盘读取和写入。
内存使用 | 当前分配给该进程的过程高速缓存中的页数。一个负数，表示进程正在释放由另一个进程分配的内存。
登录时间 | 客户端进程登录到服务器的时间。对于系统进程，显示 SQL Server 启动发生的时间。
上次批处理 | 客户端进程上次执行远程存储过程调用或 EXECUTE 语句的时间。对于系统进程，显示 SQL Server 启动发生的时间。
主机 | 工作站的名称。
网络库 | 用于存储客户端网络库的列。每个客户端进程都在网络连接上进入。网络连接有一个与这些进程关联的网络库，该网络库使得这些进程可以建立连接。有关更多信息，请参见客户端和服务器 Net-Library。
网络地址 | 指派给每个用户工作站上的网络接口卡唯一标识符。当用户登录时，该标识符插入到 Network Address 列。
阻塞者 | 阻塞进程的进程 ID (SPID)。
正在阻塞 | 被阻塞进程的进程 ID (SPID)。

以下是有关"当前活动"窗口中的锁信息的描述。

项目 | 类型 | 描述
spid | spid | 当前用户进程的服务器进程 ID。
ecid | ecid | 执行上下文 ID。表示与特定 spid 相关联的指定线程 ID。
锁类型 | RID | 行标识符。用于在表中单独锁定一行。
 | KEY | 键；索引内部的行锁。用于保护可串行事务中的键范围。
 | PAG | 数据或索引页。
 | EXT | 相邻的八个数据页或索引页构成的一组。
 | TAB | 包括所有数据和索引在内的整个表。
 | DB | 数据库。
锁模式 | Shared (S) | 用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。
 | Update (U) | 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生通常形式的死锁。
 | Exclusive (X) | 用于数据修改操作，如 UPDATE、INSERT 或 DELETE。确保不会同时对同一资源进行多重更新。
 | Intent | 用于建立锁的层次结构。
 | 架构 | 在执行依赖于表架构的操作时使用。架构锁有两种类型：架构稳定性 (Sch-S) 和架构修改 (Sch-M)。
 | Bulk update (BU) | 在向表进行大容量数据复制且指定了 TABLOCK 提示时使用。
 | RangeS_S | 共享范围，共享资源锁；可串行范围扫描。
 | RangeS_U | 共享范围，更新资源锁；可串行更新扫描。
 | RangeI_N | 插入范围、空资源锁。用于在将新键插入索引前测试范围。
 | RangeX_X | 排它范围，排它资源锁。用于更新范围中的键。
状态 | GRANT | 已获得锁。
 | WAIT | 锁被另一进程阻塞。
 | CNVT | 锁正在被转换为另一种锁。要被转换为另一种锁的锁会保持在一种模式中，但等待获取更强的锁模式（例如，从 update 模式变为 exclusive 模式）。分析阻塞问题时，将 CNVT 视为与 WAIT 相似。
所有者 | 所有者 | 锁拥有者：xact（事务)、sess（会话）或 curs（游标）。
索引 | 索引 | 与资源关联的索引。若是聚集索引，看到的则是表名。
资源 | RID | 表内已锁定行的行标识符。行由 fileid:page:rid 组合进行标识，其中，rid 是页中的行标识符。
 | KEY | SQL Server 内部使用的十六进制数字。
 | PAG | 页码。页由 fileid:page 组合进行标识，其中，fileid 是 sysfiles 表中的 fileid，而 page 是该文件内的逻辑页码。
 | EXT | 正被锁定的扩展盘区中的第一个页码。页由 fileid:page 组合进行标识。
 | TAB | 由于 ObjId 列已包含表的对象 ID，所以没有提供任何信息。
 | DB | 由于 dbid 列已包含数据库的数据库 ID，所以没有提供任何信息。

查看当前服务器活动

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看连接的上一批命令

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看当前的锁

Transact-SQL

企业管理器

企业管理器

SQL-DMO

给当前连接的用户发送消息

企业管理器

企业管理器

终止进程

Transact-SQL

企业管理器

企业管理器

SQL-DMO


监视错误日志

Microsoft® SQL Server™ 将事件（但只是某些系统事件和用户定义的事件）记入 SQL Server 错误日志和 Microsoft Windows® 应用程序日志。使用错误日志中的信息解决与 SQL Server 有关的问题。

Windows 应用程序日志全面反映了发生在 Windows NT 4.0 和 Windows 2000 系统中的事件以及 SQL Server 和 SQL Server 代理程序中的事件。使用事件查看器查看 Windows 应用程序日志并筛选信息。例如，可以筛选信息、警告、错误、成功审核和失败审核等事件。

这两种日志都会自动给所有记录的事件加上时间戳。

比较错误和应用程序日志输出

可以使用 SQL Server 错误日志和 Windows 应用程序日志来识别问题的原因。例如，在监视 SQL Server 错误日志的同时，可能会发现一个不明原由的消息集。通过比较两个日志中的事件日期和时间，可缩小可能原因的范围。


查看 SQL Server 错误日志

查看 Microsoft® SQL Server™ 错误日志以确定进程是否已成功完成（例如，备份和还原操作、批处理命令或其它脚本和进程）。这在检测任何当前或潜在的问题区域，包括自动恢复信息（特别是 SQL Server 实例已停止并重新启动时）、核心信息等时很有用。

SQL Server 错误日志可用 SQL Server 企业管理器或任何文本编辑器查看。默认情况下，错误日志位于 Program Files\Microsoft SQL Server\Mssql\Log\Errorlog。

每次启动 SQL Server 实例时都会创建新的错误日志，但也可用 sp_cycle_errorlog 系统存储过程循环使用错误日志文件，而不必重新启动 SQL Server 实例。一般来说，SQL Server 保留前六个日志的备份，并给最新的日志备份加扩展名 .1，次新的加 .2，依次类推。当前的错误日志没有扩展名。

查看 SQL Server 错误日志

企业管理器

企业管理器

SQL-DMO

循环使用 SQL Server 错误日志

Transact-SQL


查看 Windows 应用程序日志

Microsoft® SQL Server™ 被配置为使用 Microsoft Windows® 应用程序日志时，每个 SQL Server 会话都将新事件写入该日志。与 SQL Server 错误日志不同，每次启动 SQL Server 实例时，不会创建新的应用程序日志。

使用 Microsoft Windows NT® 4.0 或 Windows 2000 中的事件查看器查看并管理 Windows 应用程序日志。

可以用事件查看器查看三种日志。

Windows日志类型 | 描述
系统日志 | 记录 Windows NT 4.0 或 Windows 2000 系统组件所记录的事件。例如，如果启动时驱动程序或其它系统组件加载失败，该信息将记录在系统日志中。
安全日志 | 记录安全事件，如登录尝试失败。可以帮助跟踪对安全系统的更改，发现对安全的可能的破坏。例如，对系统的登录尝试可能被记录在安全日志中，这取决于用户管理器中的审核设置。 只有 sysadmin 固定服务器角色成员可以查看安全日志。
应用程序日志 | 记录被应用程序记入日志的事件。例如，数据库应用程序可能会将文件错误记录在应用程序日志中。

有关使用事件查看器、管理应用程序日志及理解其表示的信息的更多信息，请参见 Windows NT 4.0 或 Windows 2000 文档。

查看 Windows 应用程序日志

Windows NT


用 Transact-SQL 语句监视

Microsoft® SQL Server™ 提供一些 Transact-SQL 语句和系统存储过程，用于对 SQL Server 实例进行特殊监视。当想要快速查看有关服务器性能和活动的信息时，可以使用这些语句。例如：

  • 当前的锁。

  • 当前用户活动。

  • 用户上次提交的批命令。

  • 表或数据库使用的数据空间。

  • 事务日志使用的空间。

  • 数据库中时间最久的活动事务（包括复制的事务）。

  • 有关 I/O、内存和网络吞吐量的性能信息。

  • 过程高速缓存的使用情况。

  • 关于 SQL Server 活动和使用的常规统计信息，如 CPU 用于执行 SQL Server 操作的时间，或 SQL Server 用于执行 I/O 操作的时间。

还可以使用 SQL Server 企业管理器、SQL-DMO 或系统监视器（Microsoft Windows NT® 4.0 中的性能监视器）监视上述信息中的大多数。

查看当前的锁

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看当前服务器活动

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看连接的上一批命令

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看数据库的数据空间信息

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看数据库的日志空间信息

Transact-SQL

企业管理器

企业管理器

SQL-DMO

查看数据库中时间最久的活动事务

Transact-SQL

查看性能信息

Transact-SQL

查看过程高速缓存的使用情况

Transact-SQL

查看有关 SQL Server 活动和使用的常规统计信息

Transact-SQL

请参见

用 SQL Server 企业管理器进行监视

使用系统监视器进行监视


用 SNMP 进行监视

简单网络管理协议 (SNMP) 是一个提供网络管理服务的应用程序协议。使用 SNMP 可以在不同的平台（如 Microsoft Windows NT® 4.0、Microsoft Windows 98® 和 UNIX）之间监视 Microsoft® SQL Server™ 实例。

在 SQL Server 和 Microsoft SQL Server 管理信息库 (MSSQL-MIB) 中，可以使用 SNMP 应用程序：

  • 监视 SQL Server 安装的状态。SNMP 仅用于监视 SQL Server 的默认实例。

  • 监视性能信息。

  • 访问数据库。

  • 查看服务器和数据库配置参数。


SNMP术语

简单网络管理协议 (SNMP) 术语的定义参见下表。

术语 | 描述
SNMP | 一种应用程序，用于监视 Microsoft® SQL Server™ 安装的状态和性能、浏览已定义的数据库以及查看服务器和数据库的配置参数。
SNMP代理程序 | SQL Server SNMP扩展代理程序 (Sqlsnmp.dll)。用来扩展 SNMP 服务功能的服务器软件。SNMP 代理程序用于处理对本地服务器上的数据和数据对象的请求。


在 SQL Server 上启用 SNMP 支持

如果运行 SQL Server 安装程序时在计算机上安装了 Microsoft Windows NT® 4.0 或 Windows® 2000 对 SNMP 的支持，将自动启用 Microsoft® SQL Server™ 对 SNMP 的支持。如果在执行安装程序时没有在计算机上安装 SNMP，则不会启用 SQL Server 对 SNMP 的支持。


在 Windows 98 上启用 SQL Server 对 SNMP 的支持

如果网络使用简单网络管理协议 (SNMP)，可以监视与运行 Microsoft® Windows® 98 的计算机的远程连接。

由 SNMP 代理程序控制的数据库称为 SNMP 管理信息库 (MIB)。一个 SNMP MIB 中包含的值可与另一个应用程序的 SNMP MIB 共享。

SQL Server 安装程序将 Microsoft SQL Server™ 管理信息库 (MSSQL-MIB)（存储在 Mssql.mib 文件中）和 SQL Server SNMP 扩展代理程序 (Sqlsnmp.dll) 复制到系统，且如果在安装时正在运行 SNMP，则将启用该管理信息库和代理程序。可以随时在"SQL Server 网络实用工具"对话框中选择"启用 SNMP"复选框来激活或停用 SNMP。

有关 SNMP 的更多信息，请参见 SNMP 应用程序文档。

在 Windows 98 上启用 SQL Server 的 SNMP 支持

Windows


启用 SQL Server MIB

由简单网络管理协议 (SNMP) 控制的数据库叫做 SNMP 管理信息库 (MIB)。一个 SNMP MIB 中包含的值可与另一个应用程序的 SNMP MIB 共享。

SQL Server 安装程序将 Microsoft® SQL Server™ 管理信息库 (MSSQL-MIB)（存储在 Mssql.mib 文件中）和 SQL Server SNMP 扩展代理程序 (Sqlsnmp.dll) 复制到系统，如果在安装时正在运行 SNMP，则将启用该管理信息库和代理程序。

有关 SNMP 的更多信息，请参见 SNMP 应用程序文档。

将 MSSQL-MIB 复制到 SNMP 工作站

若要使 SNMP 应用程序能够监视 SQL Server 安装的状态，存储在 Mssql.mib 文件中的 MSSQL-MIB 复本必须放置在监视工作站上并装入 SNMP 应用程序。MSSQL-MIB 使 SNMP 应用程序能够在 SQL Server 实例上访问和监视 SQL Server SNMP 扩展代理程序。

Mssql.mib 文件是一个文本文件，包含 SNMP 工作站可用对象的定义。该文件中包含只读变量，用来监视常规性能计数器，SQL Server 的安装和数据库的状态，以及数量有限的配置选项和数据库文件。Mssql.mib 不定义任何可写对象。

下表描述 SNMP 表。下列各表是 SNMP 表，不是 SQL Server 表。

SNMP表 | 描述
MssqlSrvTable | 包含对 SQL Server 安装的描述。每个 SQL Server 安装（6.5 或更早版本）在其中占一行，每个在服务器上运行的 SQL Server 7.0 或 SQL Server 2000 实例在其中占多行。
MssqlSrvInfoTable | 包含有关活动的 SQL Server 进程的常规信息，包括性能计数器的常规信息。
MssqlSrvConfigParamTable | 列出 SQL Server 的配置参数。
MssqlSrvDeviceTable | 系统中定义的每个 SQL Server 数据库文件在其中为一个条目。
MssqlDbTable | 列出已定义的 SQL Server 数据库。每个数据库在其中占一行。
MssqlDbOptionTable | 列出每个 SQL Server 数据库的数据库选项设置。

有关更多信息，请参见 SNMP 应用程序文档。

将 SQL Server MSSQL-MIB 复制到 SNMP 工作站

Windows NT


使用 Web 助手向导

可以使用 Web 助手向导由 Microsoft® SQL Server™ 数据生成标准的 HTML 文件。Web 助手向导通过使用 Transact-SQL 查询、存储过程和扩展存储过程来生成 HTML 文件。可以使用该向导一次性地或作为一项定期调度的 SQL Server 任务生成 HTML 文件。也可以使用触发器升级 HTML 文件。

使用 Web 助手向导，可以：

  • 调度一个自动更新 Web 页的任务。例如，每当添加新项目或价格发生变化时就更新价格表，从而为客户和销售人员维护动态的存货清单和价格表。

  • 发布和分发管理报表，包括最近销售统计、资源分配或其它 SQL Server 数据。

  • 发布服务器报表，其中包含有关当前谁正在访问服务器、哪些锁正被哪些用户控制的信息。

  • 用扩展存储过程发布 SQL Server 之外的信息。

  • 用 Web 站点收藏表发布服务器跳转列表。

  • 使用 sp_makewebtask 存储过程生成 HTML 文件。这一系统存储过程可由 Transact-SQL 程序调用。还可以调用系统存储过程以运行或除去任务。

可从 SQL Server 企业管理器中运行 Web 助手向导。

请参见

sp_dropwebtask

sp_makewebtask

sp_runwebtask


配置 Web 助手向导

运行 Web 助手向导之前，必须：

  • 设置适当的权限。

  • 选择要发布的数据库。

  • 创建查询。
设置权限

若要运行 Web 助手向导，必须拥有：

  • 所选数据库中的 CREATE PROCEDURE 权限。

  • 对所选列的 SELECT 权限。

  • 在 Microsoft® SQL Server™ 实例的帐户中创建文件的权限。
选择要发布的数据库

Web 助手向导使用由 SQL Server 创建的数据库。在 SQL Server 企业管理器的控制台树中选择要发布的数据库。如果服务器没有出现在此列表中，则运行注册服务器向导。

创建查询

可通过下列方式运行查询：

  • 使用指定的表和列。

  • 用存储过程创建结果集。

  • 用 Transact-SQL 语句选择数据。

Web 助手向导要求命名每个作业，并提供默认名称。对于稍后才运行的作业或连续运行的作业，指定名称有助于记住该查询的主要目的。


使用 Web 助手向导接收查询结果

若要接收查询结果，请使用您自己的 HTML 模板文件。模板文件是包含标记 <%insert_data_here%> 的任意 HTML 文件，该标记用于指出查询结果的插入位置。如果使用了另外的字符集，则必须在 Web 页中手工插入必要的元标记信息以指定所选的字符。