SharePoint Foundation 2010 的数据库维护

  • 项目

 

适用于： SharePoint Foundation 2010

上一次修改主题： 2016-11-30

**摘要：**了解如何维护承载 Microsoft SharePoint 2010 产品的数据和配置设置的数据库。阅读相关准则并研究建议的数据库维护策略和任务的示例。

**适用范围：**Microsoft SharePoint Server 2010、Microsoft SharePoint Foundation 2010

**作者：**Bill Baer 和 Bryan Porter

**技术审核人：**Paul S. Randal (SQLskills.com（该链接可能指向英文页面）)

目录

  • 简介

  • 使用数据库控制台命令 (DBCC) CHECKDB 检查一致性错误

  • 关于 DBCC CHECKDB

  • DBCC CHECKDB 和性能

  • 度量并减少索引碎片

  • 联机与脱机重新生成索引

  • 度量 SQL Server 2008 或 2005 数据库中的碎片 (sys.dm_db_index_physical_stats)

  • 减少数据库的碎片

  • 减少特定表及其索引的碎片

  • 通过设置填充因子微调索引性能

  • 收缩数据文件

  • 创建 SQL Server 2008 维护计划

  • 结束语

备注

在实现任何数据库维护任务或修改 SharePoint 2010 数据库前，请阅读支持对 Office 服务器产品和 Windows SharePoint Services 使用的数据库进行更改。

简介

数据库例行维护对于 Microsoft SharePoint 2010 数据库的平稳运行是必不可少的。

建议对 SharePoint 2010 数据库的维护任务包括以下内容：

  • 检查数据库的完整性。

  • 通过重新组织或重新生成索引来对索引进行碎片整理。

  • 设置服务器的填充因子。

备注

本文讨论数据库维护，但不讨论对容量或性能的规划。有关容量或容量规划的信息，请参阅存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)。

虽然早期版本的 SharePoint 产品和技术需要手动干预才能对索引执行碎片整理和维护统计信息，但 SharePoint 2010 中的一些 SharePoint 运行状况分析器规则实现了此过程的自动化。这些规则每天都会评估数据库索引和统计信息的运行状况，并自动为以下数据库处理这些项目：

  • 配置数据库

  • 内容数据库

  • User Profile Service 应用程序配置文件数据库

  • User Profile Service Application Social 数据库

  • Web Analytics Service Application Reporting 数据库

  • Web Analytics Service Application Staging 数据库

  • Word Automation Services 数据库

您可通过运行 Transact-SQL 命令或通过运行数据库维护向导来执行数据库维护任务。本文介绍了可使用的 Transact-SQL 命令，然后解释了如何使用 Microsoft SQL Server 数据库维护向导创建数据库维护计划。（详细示例是针对 Microsoft SQL Server 2008 R2 和 Microsoft SQL Server 2005 的。）

使用数据库控制台命令 (DBCC) CHECKDB 检查一致性错误

在执行例行维护操作时首先进行一致性检查，以确保您的数据和索引未损坏。您可使用数据库控制台命令 (DBCC) CHECKDB 语句对数据和索引页执行内部一致性检查。

大部分数据库一致性问题都是由 I/O 子系统错误导致的。但其他因素和事件也会影响数据库一致性；例如，数据库服务器的不正当关闭或驱动器错误。明显的性能和可用性问题有时可能是基础数据库一致性问题的征兆。每周对您的 SharePoint 2010 数据库至少执行一次数据库一致性检查，并且在发生数据库服务器错误或 I/O 子系统错误等事件时执行数据库一致性检查。

关于 DBCC CHECKDB

DBCC CHECKDB 通过执行以下操作来检查指定数据库中所有对象的逻辑和物理完整性：

  • 运行 DBCC CHECKALLOC 的等效项来验证数据库中的分配结构。

  • 对数据库中的每个表和视图运行 DBCC CHECKTABLE 的等效项以验证其逻辑和物理完整性。

  • 对数据库运行 DBCC CHECKCATALOG 的等效项以验证数据库中元数据的一致性。

建议您运行 DBCC CHECKDB 而不是执行单独的操作（DBCC CHECKALLOC、DBCC CHECKTABLE 和 DBCC CHECKCATALOG 命令），因为 DBCC CHECKDB 会标识最大范围的潜在错误，因而在生产环境中运行要安全得多。

DBCC CHECKDB 使用大量内存、I/O 和 CPU 资源。您不用在生产系统中运行 DBCC CHECKDB，而是可以改为在不同服务器上对 SharePoint 数据库的还原备份运行它，从而从生产系统中卸载一致性检查工作负荷。

建议您先运行 DBCC CHECKDB，如果它显示错误，则使用最新备份还原受影响的数据库。

重要

无法运行 DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS。但是，可运行 DBCC_CHECKDB WITH REPAIR_FAST 和 REPAIR_REBUILD，因为这两条命令仅更新关联数据库的索引。

以下是 DBCC CHECKDB 输出的示例。

DBCC results for 'Contoso_Content_1'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
DBCC results for 'sys.sysrowsetcolumns'.
There are 2663 rows in 21 pages for object "sys.sysrowsetcolumns".
DBCC results for 'sys.sysrowsets'.
There are 309 rows in 4 pages for object "sys.sysrowsets".

...more

CHECKDB found 0 allocation errors and 0 consistency errors in database 'Contoso_Content_1'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

有关如何对 SQL Server 2008 使用 DBCC CHECKDB 的详细信息，请参阅 DBCC CHECKDB (Transact-SQL)。

DBCC CHECKDB 和性能

建议您在非生产时间运行一致性检查，因为 DBCC CHECKDB 会占用大量资源（I/O、CPU、内存和 tempdb 空间）。有这样一个常见误解，认为 DBCC CHECKDB 会获取阻塞锁，但这在 SQL Server 2000 之前是不可能的。有关详细信息，请参阅SQL Server DBA 每日神话：(2/30) DBCC CHECKDB 导致阻塞（该链接可能指向英文页面）。

您可能发现正在运行的 DBCC CHECKDB 使用的生产系统资源过多。在这种情况下，请勿尝试一次对一个表运行一致性检查。减少在生产系统上执行完整性检查的开销的最佳方式为使用以下选项之一：

  • 使用 WITH PHYSICAL_ONLY 选项减少 CPU 和内存使用率。

  • 在单独的 SQL Server 上还原数据库备份，并对还原的数据库副本运行一致性检查。

有关这些选项的详细信息，请参阅 Paul S. Randal 的博客文章各个角度的 CHECKDB：VLDB 的一致性检查选项（该链接可能指向英文页面）。

度量并减少索引碎片

当某个表或索引中的页的逻辑顺序（由索引键定义）与这些页在数据文件中的物理顺序不同时，将会产生索引碎片。它还可能意味着数据文件页上的数据密度较低，从而导致磁盘空间、内存和 I/O 的浪费。索引碎片可能是多次对表执行插入、更新或删除操作的结果。下面的插图将新构建的未碎片化的索引与经过多次插入、更新和删除后已碎片化的索引进行了对比。红色箭头显示索引的物理顺序；黑色箭头显示索引页的逻辑顺序。

图 1. 未碎片化的索引（图像来源：Paul S. Randal）

非碎片化索引

 

图 2. 已碎片化的索引（图像来源：Paul S. Randal）

碎片化索引

 

因为插入、更新和删除操作并不是均等地分布在表和索引的行中，因此每页的填充度（或数据密度）可能会随时间而变化。对于扫描表的部分或全部索引的查询，碎片会导致额外的页读取次数，从而妨碍数据的并行扫描并且可能会显著影响搜索性能。

索引碎片可能导致性能下降和空间使用效率低，并且索引可能会在仅中度使用的数据库上快速碎片化。

在实现索引碎片维护计划之前，确定碎片化程度最大的表和索引。然后，创建维护计划以重新生成或重新组织这些索引。

例如，在 SharePoint 2010 中，AllDocs 表经常会碎片化，该表包含文档库、文档库关联的文档和列表及列表项，以及文档库各自的元数据。

索引的碎片级别是逻辑顺序和物理顺序不相同的索引页的百分比。

联机与脱机重新生成索引

只有 SQL Server 企业版、开发版和评估版中提供了联机重新生成索引功能。本文中介绍的方法考虑了这些限制。如果承载某个特定数据库的 SQL Server 版本不支持联机重新生成索引，或者正在重新生成的索引不符合联机重新生成索引的要求，则本文中的过程将回退到脱机重新生成索引。索引可能会因存在大型对象 (LOB) 列（如数据类型为 NVARCHAR(MAX)、IMAGE 等的列）而不符合联机重新生成的要求。

有关联机重新生成索引的信息，请参阅联机索引操作的工作方式。执行脱机重新生成索引时，将在重新生成过程中采用表级别的锁定，这可能阻止写入表或者甚至完全阻止访问表。由于存在 LOB 列，SharePoint 数据库中的很多索引始终是使用脱机重新生成索引来重新生成的。

即使使用联机重新生成索引，在操作过程中仍会在两个时点暂时进行表锁定，从而可能导致阻塞。因此，建议您始终将重新生成索引活动安排在活动较少的时间段。

度量 SQL Server 2008 或 2005 数据库中的碎片 (sys.dm_db_index_physical_stats)

在 SQL Server 2008 或 SQL Server 2005 中，使用 sys.dm_db_index_physical_stats 动态管理视图来确定指定表或视图的索引的碎片情况。

为了度量碎片情况，建议您监控 avg_fragmentation_in_percent 列。avg_fragmentation_in_percent 的值应尽可能接近 0 以获得最大性能。但 0 到 10% 之间的值均可接受。有关详细信息，请参阅 sys.dm_db_index_physical_stats。

下表显示了 sys.dm_db_index_physical_stats 的示例结果，其中一行的 avg_fragmentation_in_percent 值为 9.375。

database_id

index_type_desc

alloc_unit_type_

desc

avg_fragmentation_

in_percent

10

CLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

CLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

CLUSTERED INDEX

IN_ROW_DATA

9.375

使用 sys.dm_db_index_physical_stats 动态管理视图

  1. 在工具栏上单击“开始”，指向“所有程序”，指向“Microsoft SQL Server 2008”，然后单击“SQL Server Management Studio”。

    若要对数据库对象使用 sys.dm_db_index_physical_stats，您必须知道相应的数据库 ID 和对象 ID。

  2. 在对象资源管理器中选择该内容数据库，然后单击“新建查询”。执行以下脚本。

    SELECT DB_ID() AS [Database ID];

    备注

    如果使用 DB_ID 时未指定数据库名称，则当前数据库的兼容性级别必须是 100（SQL Server 2008 数据库）或 90（SQL Server 2005 数据库）。如果您已从早期版本的 SQL Server 升级，则必须在 DB_ID 语句中指定一个数据库名称。有关兼容性级别的详细信息，请参阅 sp_dbcmptlevel (Transact-SQL)。

  3. 对您选择的数据库或对象执行 sys.dm_db_index_physical_stats。您可指定数据库，还可指定表或索引。

    运行 sys.dm_db_index_physical_stats 时使用以下语法。

    sys.dm_db_index_physical_stats ( 
    { database_id | NULL | 0 | DEFAULT }
    , { object_id | NULL | 0 | DEFAULT }
    , { index_id | NULL | 0 | -1 | DEFAULT }
    , { partition_number | NULL | 0 | DEFAULT }
    , { mode | NULL | DEFAULT }
)

    请谨慎使用 sys.dm_db_index_physical_stats DMV，因为它可能会占用大量资源。有关解释使用它的各种方式的全面指南，请参阅 sys.dm_db_index_physical_stats 内幕（该链接可能指向英文页面）。

减少数据库的碎片

使用以下指南减少索引碎片的级别。

运行数据库维护运行状况分析器规则

SharePoint 2010 包含运行状况分析器规则框架。该框架包含许多监控 SharePoint 环境的运行状况的规则，并且，在某些情况下，它还会执行操作来纠正特定类型的问题。

SharePoint 2010 包含若干与内容数据库维护有关的规则。其中，有些规则会自动减少某些 SharePoint 数据库的索引碎片，有些规则会检查过时的统计信息，并在必要时更新这些统计信息。这些运行状况分析器规则替代了适用于 SharePoint 产品和技术的 Service Pack 2 中引入的已更新的“数据库统计信息”计时器作业。默认情况下，这些规则会配置为按照某个计划执行，具体的计划会根据规则目标而变（每日、每周或按需）。

所有配置为每日执行的运行状况分析器规则以及与某个特定 SharePoint 服务关联的运行状况分析器规则都由相同的计时器作业执行。调整此计时器作业的计划将会调整配置为每日运行的运行状况分析器规则以及与该服务关联的运行状况分析器规则的每日执行时间。本文中介绍的所有规则均与 SharePoint 定时服务关联。

配置为按不同的时间间隔（如每周）执行的运行状况分析器规则或与不同服务关联的运行状况分析器规则具有不同的计时器作业。如果将某个运行状况分析器规则配置为每周执行，则该规则将与配置为每周为与该规则关联的特定服务执行的计时器作业一起执行。换句话说，该规则将按为该计时器作业定义的计划执行。

您可以单击管理中心的“运行状况分析器规则”页上的功能区中的“立即运行”，手动运行运行状况分析器规则。运行这些规则可评估索引和统计信息的运行状况；它还根据需要重新生成并重新计算索引。

SharePoint 使用的数据库包含零碎索引。运行此规则可执行以下任务：

  • 该规则会将索引报告为碎片。因为评估索引运行状况是一项开销很大的操作，因此，在执行运行状况分析器规则后，该规则始终会将索引报告为碎片以触发纠正操作。

  • 对于每个 SharePoint 数据库，该规则操作都会查找 proc_DefragmentIndices 存储过程，并在找到后执行它。该过程将会生成数据库中所有索引的列表。在每个索引中都将评估碎片的当前级别。任何碎片化超过 30% 的索引都会考虑重新生成。

  • 如果 SQL Server 的版本支持联机重新生成索引，则将对每个索引尝试联机重新生成索引。如果此尝试失败（例如，基础索引可能因 LOB 列而不支持联机重新生成），则将执行脱机重新生成索引。

如前所述，此规则并不适用于 SharePoint 环境中的每个数据库。某些数据库使用其他规则执行类似的维护活动。

**搜索 – 一个或多个属性数据库包含零碎索引。**此规则维护 SharePoint 2010 企业级搜索属性数据库中的索引。默认情况下，此规则配置为每周在服务器场中的所有服务器上执行一次。此规则的所有处理（包括纠正操作）将在规则的 Check 阶段发生。这意味着，如果您要管理企业级搜索属性数据库的索引重新生成，将此规则简单地配置为不自动重新生成索引是不够的。如果您不想 SharePoint 2010 自动运行索引维护操作，则必须完全禁用此规则。

运行 Search - One or more property databases have fragmented indices 可执行以下任务：

  • 此规则确认环境处于可安全执行索引重新生成的状态。

  • 对于针对本地服务器场中的搜索应用程序配置的每个属性数据库，该规则将执行 proc_MSS_DefragSearchIndexes 存储过程，该过程将生成一个其平均碎片率超过 10% 的所有索引的列表。

  • 将重新生成该列表中影响属性数据库的性能的每个索引。如果 SQL Server 的版本支持联机重新生成索引，则将执行联机重新生成索引。如果尝试了联机重新生成索引，但尝试失败，则将脱机重新生成索引。

搜索 – 一个或多个爬网数据库可能包含零碎索引。此规则维护 SharePoint 2010 企业级搜索属性数据库中的索引。默认情况下，此规则配置为每周在服务器场中的所有服务器上执行一次。此规则的所有处理（包括纠正操作）将在规则的 Check 阶段发生。这意味着，如果您要管理企业级搜索属性数据库的索引重新生成，将此规则简单地配置为不自动重新生成索引是不够的。如果您不想 SharePoint 2010 自动运行索引维护操作，则必须完全禁用此规则。

运行 Search - One or more property databases have fragmented indices 可执行以下任务：

  • 此规则确认环境处于可安全执行索引重新生成的状态。

  • 对于针对本地服务器场中的搜索应用程序配置的每个属性数据库，该规则将执行 proc_MSS_DefragSearchIndexes 存储过程，该过程将生成一个其平均碎片率超过 10% 的所有索引的列表。

  • 将重新生成该列表中影响属性数据库的性能的每个索引。如果 SQL Server 的版本支持联机重新生成索引，则将执行联机重新生成索引。如果尝试了联机重新生成索引，但尝试失败，则将脱机重新生成索引。

搜索 – 一个或多个爬网数据库可能包含零碎索引。此规则维护 SharePoint 2010 企业级搜索爬网数据库中的索引。默认情况下，此规则配置为仅按需执行。此规则可在服务器场中的任何服务器上执行。

此规则将爬网数据库中的索引报告为碎片，因为检查数据库中的碎片是一项开销很大的操作。简单地禁用此规则的“修复”活动会导致生成一个报告，其中显示所有爬网数据库均运行状态不良，即使爬网数据库最近已重新生成索引也是如此。

若要手动维护爬网数据库中的索引，请完全禁用 Search - One or more crawl databases may have fragmented indices 规则。

运行 Search - One or more crawl databases may have fragmented indices 可执行以下任务：

  • 此规则确认环境处于可安全执行索引重新生成的状态。

  • 对于针对本地服务器场中的搜索应用程序配置的每个爬网数据库，该规则将执行 proc_MSS_DefragGathererIndexes 存储过程。

  • 将重新生成列表中的爬网数据库中的每个索引。如果 SQL Server 的版本支持联机重新生成索引，则将执行联机重新生成索引。如果尝试了联机重新生成索引，但尝试失败，则将脱机重新生成索引。

重要

Search - One or more crawl databases may have fragmented indices 规则将重新生成所有爬网数据库中的每个索引，而不管碎片级别如何。如果承载爬网数据库的 SQL Server 版本支持，它还会启用页级别数据压缩。

基于爬网数据库的本质，您通常无需频繁对此数据库进行碎片整理。先对您的内容执行完全爬网，然后再执行此规则。之后，监控爬网数据库中的索引的碎片情况，并在索引碎片增多后执行此规则。突然添加或删除大量已爬网内容时可能会导致出现索引碎片；例如，在由环境清理导致的内容清除期间，或在载入新内容源（如文件共享或大型 SharePoint Web 应用程序）后。

以下数据库没有采用自动化维护机制。这些数据库通常不会有太多碎片。监控这些数据库的碎片情况，当碎片超过 30% 时重新生成这些数据库中的索引。

  • 搜索管理数据库

  • 安全存储数据库

  • 状态服务数据库

  • 配置文件同步数据库

  • 使用情况数据库

  • 托管元数据数据库

  • Business Connectivity Services 数据库

  • PerformancePoint Services 数据库

有关 SharePoint 2010 数据库支持的更改的详细信息，请参阅 Microsoft 知识库中的支持对 Office Server 产品和 Windows SharePoint Services 使用的数据库进行更改。

如果碎片化严重的数据库或表的性能无法通过频繁的碎片整理得到明显改善，则应检查 I/O 子系统的性能。

减少特定表及其索引的碎片

如果您要对与某个特定表而不是整个数据库关联的某个索引进行碎片整理，则可重新组织或重新生成该索引。

  • 重新组织索引指定将重新对索引的叶级别进行组织。索引重新组织将对表和视图的群集和非群集索引进行碎片整理和压缩，从而可以显著提高索引扫描性能。重新组织索引将使用分配给索引的现有空间。重新组织始终是联机执行的，以便使基础表对用户可用。

  • 重新生成索引指定将生成索引的全新副本。因此，在删除旧的零碎索引之前，重新生成操作需要足够的额外空间来生成索引的新副本。重新生成将提高索引扫描和搜索的性能。您可以联机或脱机使用表来重新生成索引。

索引的碎片级别决定了您应该用来对索引进行碎片整理的方法，以及该方法是可以联机进行还是应脱机进行。下表介绍了对不同的碎片级别推荐使用的碎片整理方法。

碎片级别 碎片整理方法

最多 10%

重新组织（联机）

10-75%

重新生成（联机）

75%

重新生成（脱机）

备注

在 SharePoint 2010 数据库上不支持使用 DROP INDEX 和 CREATE INDEX 命令。

您可使用 SQL Server 2008 或 SQL Server 2005 ALTER INDEX 语句，或使用 SQL Server 2008 或 SQL Server 2005 的维护计划向导重新组织和重新生成索引。本文仅详细演示 SQL Server 2008 或 SQL Server 2005 选项。

使用 ALTER INDEX

数据库管理员可以利用 ALTER INDEX 来对表或视图上的索引执行维护操作。您可使用 ALTER INDEX 禁用、重新生成以及重新组织索引。另外，您可使用它设置针对索引的选项。在大多数情况下，您可在数据库联机时重新生成索引，这样使数据对用户可用的程度高于脱机索引重新生成。

重要

SQL Server 2000 支持使用 DBCC DBREINDEX 和 DBCC INDEXDEFRAG 来进行索引维护。从 SQL Server 2005 以后的版本中已弃用这两条命令，并且在将来的 SQL Server 版本中将会删除它们。请勿使用这两条命令对 SharePoint 2010 数据库执行索引维护。

备注

当以脱机方式重新生成索引时，将会对表执行共享表锁定以阻止除 SELECT 之外的所有操作。SharePoint 2010 数据库将会明确使用群集索引。当以脱机方式重新生成群集索引时，将对表执行排他表锁定以阻止用户访问它。

可以自定义以下示例脚本来在表上重新生成所有索引。

USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON)
GO

通过设置填充因子微调索引性能

若要进一步改进索引数据存储和性能，可使用填充因子。当创建或重新生成索引时，填充因子值 (1-100) 确定每个叶级别页上可使用数据填充的空间的百分比。其余空间将保留给将来的增长。在许多情况下，默认的服务器范围的填充因子的级别 0（将每页 100% 填满）是最好的。但对于 SharePoint 2010，服务器范围的设置最好为 80 以支持增长并最大程度地减少碎片。

备注

建议您不要为单独的表或索引设置填充因子。虽然这是非 SharePoint SQL Server 数据库的首选方法，但测试表明，SharePoint 数据库在使用 80% 的填充因子时性能最佳。

若要查看一个或多个索引的填充因子值，请查询 sys.indexes 目录视图。有关此视图的详细信息，请参阅 sys.indexes (Transact-SQL)。

若要配置服务器范围的填充因子值，请使用 sp_configure 系统存储过程。有关详细信息，请参阅 spconfigure (Transact-SQL)。

收缩数据文件

在 SQL Server 2008 和 SQL Server 2005 中，您可收缩数据库中的每个文件（文件扩展名为 .mdf, .ldf 和 .ndf）以删除未使用的页面并恢复磁盘空间。SharePoint 2010 数据库不会自动收缩数据文件，尽管许多活动会在数据库中创建未使用的空间。可创建未使用的空间的活动包括运行 Move-SPSite Windows PowerShell 命令以及删除文档、文档库、列表、列表项和网站。

图 3. 数据库分配

数据库分配

 

仅从文件末尾释放可用空间；例如，对于一个大小为 60 GB 的内容数据库文件，如果指定目标大小为 40 GB，则将从该数据库文件末尾（在概念上为最右侧）的 20 GB 空间中尽可能多地释放空间。如果末尾的 20 GB 空间中包含已用的页面，则稍后会将这些页面重定位到该文件保留的开头的 40 GB 空间中。可以单独收缩各个数据库文件，也可以将数据库文件作为一个组进行收缩。

仅执行极少次数的收缩操作，而且仅在您执行从数据库中删除大量数据的操作后执行，然后就是仅在您不希望再使用某个可用空间时执行。数据文件收缩操作会产生大量索引碎片，并且会占用大量资源。以下是您可能必须收缩数据库文件的两种示例情况：一种情况是当您将一个内容数据库中的大量网站集重定位到另一个内容数据库时；另一种情况是当您删除大型列表时。这两个操作中的任何一个都会创建大量未使用的空间。数据库文件只能减少至不剩下任何可用空间的程度。因此，您很少删除其中的内容的内容数据库可能不会从收缩中获益，并且它在无任何特定调整就必须增长以容纳其他数据时，可能会遇到性能下降问题。有关详细信息，请参阅数据库文件初始化。

因为收缩会产生索引碎片，因此请勿定期收缩数据库文件。相反，只有在因显著影响数据库中已使用空间的相对数量的操作而导致出现大量未使用的空间时，才应收缩数据库文件。如果有任何可能，应避免收缩数据库。

但是，如果您必须收缩数据库，请使用以下准则：

  • 请勿自动收缩数据库或配置将以编程方式收缩数据库的维护计划。

  • 仅在用户或管理员删除了 50% 或以上的内容并且您不希望重用未使用的空间时收缩数据库。

  • 仅收缩内容数据库。用户和管理员不会从配置数据库、管理中心内容数据库和各种服务应用程序数据库中删除足够的数据来包含大量可用空间。

  • 收缩数据库是一项占用大量资源的操作。因此，如果您确实必须收缩数据库，则请谨慎考虑安排收缩操作的时间。

  • 收缩数据库后，数据库中的索引将碎片化。可使用 ALTER INDEX… REORGANIZE 解决碎片情况。如果您未配置为允许即时文件初始化，则会将数据库收缩到符合您预计的近期增长需要的目标大小。有关详细信息，请参阅数据库文件初始化。

您可以通过在 SQL Server 2008 或 SQL Server 2005 Management Studio 中执行 DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 语句，手动收缩数据库和数据库文件来恢复空间。

有关收缩数据库会损害性能以及如非确实必要不应执行数据库收缩的原因的详细信息，请参阅不应收缩数据文件的原因（该链接可能指向英文页面）。

使用 Transact-SQL 命令收缩数据库

DBCC SHRINKDATABASE 将收缩特定数据库的数据和日志文件。若要收缩各个文件，请使用 DBCC SHRINKFILE。

DBCC SHRINKDATABASE

DBCC SHRINKDATABASE 使用以下语法。

DBCC SHRINKDATABASE 
( 'database_name' | database_id | 0 
     [ ,target_percent ] 
     [ , { NOTRUNCATE | TRUNCATEONLY } ] 
)
[ WITH NO_INFOMSGS ]

database_name | database_id | 0 指定数据库名称或 ID。若要选择当前数据库，请使用 0。

target_percent 是您在收缩数据库后要保留的可用空间（百分比形式）。

NOTRUNCATE 通过将已分配页面从文件末尾移至文件开头的未分配页面，从而压缩数据文件中的数据。

TRUNCATEONLY 将文件末尾的所有可用空间释放给操作系统，但不会在文件中执行任何页面移动。

备注

SharePoint 2010 内容数据库中不支持使用 TRUNCATEONLY 选项。

有关详细信息，请参阅 DBCC SHRINKDATABASE (Transact-SQL)。

DBCC SHRINKFILE

DBCC SHRINKFILE 使用以下语法。

DBCC SHRINKFILE 
(
     { 'file_name' | file_id } 
    { [ , EMPTYFILE ] 
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
    }
)
[ WITH NO_INFOMSGS ]

file_name | file_id 指定文件名或 ID。

EMPTYFILE 将指定文件中的所有数据迁移至同一文件组中的其他文件中。

重要

SharePoint 2010 数据库文件不支持使用 EMPTYFILE 选项。

target_size 是文件的目标大小（以 MB 为单位，用整数表示）。

NOTRUNCATE 通过将已分配页面从文件末尾移至文件开头的未分配页面，从而压缩数据文件中的数据。

TRUNCATEONLY 将文件末尾的所有可用空间释放给操作系统，但不会在文件中执行任何页面移动。

重要

SharePoint 2010 内容数据库中不支持使用 TRUNCATEONLY 选项

有关详细信息，请参阅 DBCC SHRINKFILE (Transact-SQL)。

使用 SQL Server 2008 Management Studio 收缩数据库

请使用以下过程。

使用 SQL Server 2008 Management Studio 收缩数据库

  1. 在任务栏上，选择“开始”、“所有程序”、“Microsoft SQL Server 2008”和“SQL Server Management Studio”。

  2. 在对象资源管理器上，连接到 SQL Server 2008 数据库引擎的一个实例，然后展开该实例。

  3. 展开“数据库”，右键单击要收缩的数据库，选择“任务”、“收缩”和“文件”。

  4. 选择文件类型和文件名。

  5. 选择“在释放未使用的空间前重新组织文件”。您还必须设置“收缩文件”值。选择此选项可将文件中所有未使用的空间释放给操作系统并将相关行重定位到未分配页面。

  6. 单击“确定”。

创建 SQL Server 2008 维护计划

通过实现 SQL Server 维护计划，可以编程方式应用本文中介绍的多个数据库维护操作。维护计划可自动执行并安排基本任务来保护您的数据。通过在 SQL Server 2008 或 SQL Server 2005 中使用维护计划，管理员可安排运行数据库一致性检查、重新组织索引或重新生成索引等操作。有关详细信息，请参阅以下资源：

配置 SQL Server 2008 数据库维护计划

  1. 在任务栏上，选择“开始”、“所有程序”、“Microsoft SQL Server 2008”和“SQL Server Management Studio”。

  2. 在对象资源管理器上，连接到 SQL Server 2008 数据库引擎的一个实例，然后展开该实例。

  3. 选择“管理”，右键单击“维护计划”，然后选择“维护计划向导”。

  4. 选择“下一步”直到显示“选择计划属性”页。

    图 4.“选择计划属性”页

    “选择计划属性”页

  5. 在“名称”和“说明”字段中，指定名称和说明。

  6. 确定是配置一个还是多个维护计划。

    • 若要配置一个维护计划，请选择“整个计划统筹安排或无计划”。

    • 若要通过特定任务配置多个维护计划，请选择“每项任务单独计划”。

    如果您的环境有 10 个或以上的内容数据库或超过 200 GB 的内容，则建议您配置不同的维护计划以提供适当的专一性并最大化维护窗口。

    如果为一个数据库配置了多个维护计划，请指定名称或说明，以使您能区分各个计划及其目的，包括其日程安排。

  7. 单击“更改”以设置一个或多个计划的日程安排。

    将出现“作业计划属性”对话框。

    图 5.“作业计划属性”对话框

    “作业计划属性”对话框

  8. 完成计划，单击“确定”，然后单击“下一步”。

  9. 在“选择维护任务”页上，选择要包含在计划中的维护任务，然后单击“下一步”。

    图 6.“选择维护任务”页

    “选择维护任务”页

    考虑以下注意事项：

    • 维护计划应包括索引重新组织或索引重新生成；而不应同时包含二者。

    • 维护计划绝对不应包括收缩数据库。

    • 若要测试每个任务的持续时间，请在将每个任务并入一个计划前单独测试它们。您可能必须根据单独的日程安排定义若干维护计划以使任务能在不严重影响用户的时间内完成。

    • “‘清除维护’任务”将删除在执行计划的维护之后剩下的文件。

  10. 在“选择维护任务顺序”页上，更改维护计划任务的顺序（如果需要）。选择任务，然后单击“上移”或“下移”。对任务进行排序后，单击“下一步”。

    备注

    如果您的数据库非常大，则可能要创建单独的维护计划来按照低于索引维护的频率检查数据库完整性。

    图 7.“选择维护任务顺序”页

    “选择维护任务顺序”页

  11. 接下来，向导将指导您完成对每个任务的详细信息的设置过程。在“定义‘数据库检查完整性’任务”页上，选择要检查完整性的数据库，然后单击“下一步”。

    备注

    您可安全地检查所有 SharePoint 2010 数据库的完整性。

    图 8.“定义‘数据库检查完整性’任务”页

    “定义‘数据库检查完整性’任务”页

  12. 在“定义‘重新组织索引’任务”页上的“数据库”列表中，指定要为其重新组织索引的数据库，选中“压缩大型对象”复选框，然后单击“下一步”。

    图 9.“定义‘重新组织索引’任务”页

    “定义‘重新组织索引’任务”页

  13. 如果您选择重新生成索引而不是重新组织索引，请在“定义‘重新生成索引’任务”页的“数据库”列表中指定数据库。

  14. 选择“更改每页的可用空间百分比”，键入 80，然后单击“下一步”。

    “更改可用空间百分比”将设置数据库的填充因子。

    图 10.“定义‘重新生成索引’任务”页

    “定义‘重新生成索引’任务”页

  15. 在“定义‘清除维护’任务”页上，指定请求值，然后单击“下一步”。

    提示

    建议您删除维护计划文本报告。

    图 11.“定义‘清除维护’任务”页

    “定义‘清除维护’任务”页

  16. 在“选择报告选项”页上，选择“将报告写入文本文件”，再选择文件的位置，然后单击“下一步”直到完成向导。

    图 12. 选择报告选项

    选择报表选项

结束语

一直维护承载 SharePoint 2010 的数据库可明显改进系统的运行状况和性能。

确保您在实施维护操作和维护计划之前具有所有数据库的可靠备份。

在实现维护计划或一直运行的特定维护操作之前，请测试这些操作对系统的影响以及运行这些操作所需的时间。

尽可能地将任何维护操作或维护计划设置为在非工作时间运行，以最小化对用户产生的性能影响。

See Also

Other Resources

本主题还作为下载内容提供