存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)

  • 项目

 

适用于： SharePoint Foundation 2010, SharePoint Server 2010

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

本文介绍如何在 Microsoft SharePoint Server 2010 环境中规划和配置存储和 Microsoft SQL Server 数据库层。

本文档中的容量规划信息为您提供规划应用准则。该准则建立在 Microsoft 对实时属性执行的测试的基础上。但是，您的结果可能因使用的设备和针对网站所实施的功能而有所不同。

由于 SharePoint Server 通常在由单独的 SQL Server 数据库管理员管理数据库所在的环境中运行，因此本文档专为 SharePoint Server 服务器场实施者和 SQL Server 数据库管理员联合使用而设计。假定深入了解 SharePoint Server 和 SQL Server。

本文假定您熟悉Capacity management and sizing for SharePoint Server 2010中提出的概念。

SharePoint 2010 产品存储和数据库层的设计和配置过程

建议您将存储和数据库层设计过程分为以下几个步骤。每节提供有关每个设计步骤的详细信息，包括存储要求和最佳实践：

  • 收集存储和 SQL Server 空间以及 I/O 要求

  • 选择 SQL Server 版本

  • 根据容量和 IO 要求设计存储体系结构

  • 估计内存要求

  • 了解网络拓扑要求

  • 配置 SQL Server

  • 验证存储性能和可靠性

收集存储和 SQL Server 空间以及 I/O 要求

多个 SharePoint Server 2010 体系结构因素影响存储设计。内容数量、所用的功能和服务应用程序、服务器场数量和可用性需求是主要因素。

开始规划存储之前，应了解 SharePoint Server 2010 可使用的数据库。

本节内容：

  • SharePoint 2010 产品所用的数据库

  • 了解 SQL Server 和 IOPS

  • 估计核心存储和 IOPS 需求

  • 确定服务应用程序存储和 IOPS 需求

  • 确定可用性需求

SharePoint 2010 产品所用的数据库

与 SharePoint Server 2010 一起安装的数据库取决于环境中正使用的功能。所有 SharePoint 2010 产品 环境都依赖于 SQL Server 系统数据库。本节提供了与 SharePoint Server 2010 一起安装的数据库的摘要。有关详细信息，请参阅数据库类型和说明 (SharePoint Server 2010) 和数据库模型 (https://go.microsoft.com/fwlink/p/?LinkId=187968)。

产品版本 数据库

SharePoint Foundation 2010

配置

管理中心内容

内容（一个或多个）

Usage and Health Data Collection

Business Data Connectivity

Application Registry Service（如果从 Microsoft Office SharePoint Server 2007 业务数据目录升级）

Subscription Settings Service（如果已通过 Windows PowerShell 启用）

SharePoint Server 2010 Standard Edition 的其他数据库

Search Service 应用程序：

  • 搜索管理

  • 爬网（一个或多个）

  • 属性（一个或多个）

User Profile Service 应用程序：

  • 配置文件

  • 同步

  • 社会性标签

Web Analytics Service 应用程序

  • 暂存

  • 报告

安全存储

状态

托管元数据

Word Automation Services

SharePoint Server 2010 Enterprise Edition 的其他数据库

PerformancePoint

Project Server 2010 的其他数据库

草稿

已发布

存档

报告

FAST Search Server 的其他数据库

搜索管理

如果要与 SQL Server 更完全地集成，您的环境可能还包括其他数据库，如下面的方案中所述：

  • Microsoft SQL Server 2008 R2 PowerPivot for Microsoft SharePoint 2010 可以用于包括 SQL Server 2008 R2 Enterprise Edition 和 SQL Server Analysis Services 的 SharePoint Server 2010 环境中。如果已经在使用它，您还必须进行规划以支持 PowerPivot 应用程序数据库以及系统上的额外负载。有关详细信息，请参阅在 SharePoint 场中规划 PowerPivot 部署 (https://go.microsoft.com/fwlink/?linkid=186698&clcid=0x804)。

  • Microsoft SQL Server 2008 Reporting Services (SSRS) 插件可以用于任何 SharePoint 2010 产品环境。如果要使用该插件，请规划支持两个 SQL Server 2008 Reporting Services 数据库和 SQL Server 2008 Reporting Services 所需的额外负载。

了解 SQL Server 和 IOPS

在托管 SQL Server 的任何服务器上，服务器从 I/O 子系统获得最快可能响应非常重要。

更多更快的磁盘或阵列可提供足够的每秒 I/O 操作数 (IOPS)，同时在所有磁盘上保持低延迟和少队列。

I/O 子系统的较慢响应速度无法通过添加其他类型的资源（如 CPU 或内存）加以补偿；但是，它会对整个服务器场造成影响应导致出现问题。部署前规划最小延迟并监视您的现有系统。

部署新服务器场之前，建议通过使用 SQLIO 磁盘子系统基准工具检测 I/O 子系统。有关详细信息，请参阅 SQLIO 磁盘子系统基准工具 (https://go.microsoft.com/fwlink/?linkid=105586&clcid=0x804)。

有关如何从 SQL Server 角度分析 IOPS 要求的详细信息，请参阅分析 I/O 特点并调整 SQL Server 数据库应用程序的存储系统大小 (https://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx)。

估计核心存储和 IOPS 需求

配置和内容存储以及 IOPS 是基础层，您必须在每个 SharePoint Server 2010 部署中规划。

配置存储和 IOPS

配置数据库和管理中心内容数据库的存储要求不是很高。建议您为配置数据库分配 2 GB，为管理中心内容数据库分配 1 GB。随着时间的推移，配置数据库会增长超过 1 GB，但是增长速度不是很快，大约每收集 50,000 个网站增长 40MB。

配置数据库的事务日志可能很大，建议您将数据库的恢复模式从完整更改为简单。

备注

如果想要使用 SQL Server 数据库镜像为配置数据库提供可用性，您必须使用完全恢复模式。

配置数据库和管理中心内容数据库的 IOPS 要求最低。

内容存储和 IOPS

估计内容数据库所需的存储和 IOPS 不是一项精确活动。在测试和介绍以下信息过程中，我们要帮助您推导出用于确定部署初始大小的估计值。但是，如果您的环境正在运行，我们希望您根据来自实时环境的数据重新检查容量需求。

有关我们总体容量规划方法的详细信息，请参阅Capacity management and sizing for SharePoint Server 2010。

估计内容数据库存储

下面的过程介绍如何约估内容数据库的存储，无需考虑日志文件：

  1. 计算预期文档数。此值由公式中的 D 代表。

    如何计算文档数将由您使用的功能确定。例如对于“我的网站”或协作网站，建议您计算每个用户的预期文档数，然后乘以用户数。对于记录管理或内容发布网站，可以计算由某个进程管理和生成的文档数。

    如果要从目前系统迁移，可以很轻松地推断出目前增长率和使用率。如果要创建新系统，请查看您的现有文件共享或其他存储库，并根据该使用率进行估计。

  2. 估计将要存储的文档的平均大小。此值由公式中的 S 表示。为不同类型或组的网站估计平均值很有意义。“我的网站”、媒体存储库和不同部门门户的平均文件大小会显著不同。

  3. 估计环境中列表项目数。此值由公式中的 L 代表。

    列表项目相对于文档较难估计。我们通常使用文档数的 (D) 三倍作为估计值，但是根据预计使用网站的方式不同，估计值也将不同。

  4. 确定适当版本数。估计一个库中任意文档将存在的版本数平均值（此值通常会比允许的最大版本数小得多）。此值由公式中的 V 代表。

    V 的值必须大于零。

  5. 使用下面的公式估计内容数据库大小：

    数据库大小 = ((D × V) × S) + (10 KB × (L + (V × D)))

    公式中值 10 KB 是一个常数，粗略估计 SharePoint Server 2010 所需的元数据量。如果您的系统需要大量使用元数据，您可能需要减小此常数。

例如，如果您要使用公式估计具有以下特点的协作环境中内容数据库的数据文件所需的存储空间量，可能大约需要 105 GB。

输入 值

文档数 (D)

200,000

通过假定 10,000 个用户乘以 20 个文档计算得出

文档平均大小 (S)

250 KB

列表项目 (L)

600,000

非当前版本数 (V)

2

假定允许的最大版本数为 10

数据库大小 = (((200,000 x 2)) × 250) + ((10 KB × (600,000 + (200,000 x 2))) = 110,000,000 KB 或 105 GB

影响内容数据库大小的功能

使用下面的 SharePoint Server 2010 功能会显著影响内容数据的大小：

  • 回收站 文档从第一阶段和第二阶段回收站完全删除之前，会一直占用内容数据库空间。每月计算删除的文档数以确定回收站对内容数据库大小的影响。有关详细信息，请参阅配置回收站设置 (SharePoint Server 2010)。

  • 审核 审核数据可以快速复合并使用内容数据库中的大量空间，尤其在是查看审核打开的情况下。不要允许审核数据无限制增长，建议仅在务必满足管理需求或内部控制时启用审核。使用以下准则估计针对审核数据需要保留的空间：

    • 估计网站的新审核条目数，并将此数字乘以 2 KB（条目通常限制为 4 KB，平均大小约为 1 KB）。

    • 根据想要分配的空间，确定想要保留的审核日志数。

  • Office Web Apps。如果正使用 Office Web Apps，Office Web Apps 缓存会显著影响内容数据库的大小。默认情况下，Office Web Apps 缓存配置为 100 GB。有关 Office Web Apps 缓存大小的详细信息，请参阅管理 Office Web Apps 缓存。

估计内容数据库 IOPS 需求

内容数据库的 IOPS 要求会因使用环境的方式、磁盘空间的大小以及拥有的服务器数的不同而显著不同。通常，建议您将环境中的预计工作负荷与已测试的解决方案之一进行比较。有关详细信息，请参阅性能和容量测试结果及建议 (SharePoint Server 2010)。

重要

本节中内容的测试尚未完成。请稍后查看其他信息。

估计服务应用程序存储需求和 IOPS

估计内容存储和 IOPS 需求之后，接下来必须确定环境中正使用的服务应用程序所需的存储和 IOPS。

SharePoint Server 2010 Service 应用程序存储和 IOPS 要求

若要估计系统中服务应用程序的存储要求，必须首先了解服务应用程序以及使用服务应用程序将要采取的方式。SharePoint Server 2010 中提供的具有数据库的服务应用程序在下表中列出。

服务应用程序 大小估计建议

搜索

搜索需要三个数据库。您的环境可能包括多个属性和爬网数据库。

搜索管理数据库通常较小：分配 10 GB。

若要估计属性和爬网数据库所需的存储，请使用以下乘数：

  • 爬网：0.046 × (内容数据库的总和)

  • 属性：0.015 × (内容数据库的总和)

搜索的 IOPS 要求很高。

  • 对于爬网数据库，搜索需要 3,500 至 7,000 IOPS。

  • 对于属性数据库，搜索需要 2,000 IOPS。

有关如何估计搜索所需容量的详细信息，请参阅性能和容量测试结果及建议 (SharePoint Server 2010)。

FAST Search Server 2010 for SharePoint 具有不同的体系结构。爬网数据库具有相同的 IOPS 要求，但属性数据库仅用于人员搜索并且没有其他的搜索管理数据库。有关 FAST Search Server 2010 for SharePoint 的详细信息，请参阅规划搜索拓扑 (FAST Search Server 2010 for SharePoint) 和性能和容量管理 (FAST Search Server 2010 for SharePoint)。

User Profile

User Profile Service 应用程序分配有三个数据库：配置文件、同步和社会性标签。

若要估计数据库所需的存储，请使用以下信息：

  • 配置文件。具有默认设置，在配置为使用 Active Directory 的环境中，配置文件数据库每个用户配置文件大约需要 1 MB。

  • 同步。具有默认设置，在每个用户拥有很少组的环境中，同步数据库每个用户配置文件大约需要 630 KB。90% 的空间将被数据文件使用。

  • 社会性标签。具有默认设置，社会性标签数据库每个标签、注释或评级大约需要 0.009 MB。若要估计用户将创建的标签和注释数，请考虑以下有关网站 del.icio.us 的信息：

    • 大约 10% 的用户被视为活动。

    • 活动用户每月创建 4.5 个标签和 1.8 个注释。

在具有 160,000 个用户配置文件，5 个组，79,000 个标签、注释和评级（2,500 个注释、76,000 个标签和 800 个评级）和默认设置的实时协作环境中，我们发现了以下大小的数据库：

 

数据库名称 数据库大小

配置文件

155 GB

同步

96 GB

社会性标签

0.66 GB

托管元数据

Managed Metadata Service 应用程序有一个数据库。数据库的大小受系统中所用的内容类型和关键字的数量影响。许多环境将包括 Managed Metadata Service 应用程序的多个实例。

Web Analytics

Web Analytics 有两个数据库：临时和报告。许多因素影响数据库的大小。其中包括保持期、每日跟踪的数据量以及正在分析的 Web 应用程序中的网站集数、网站数和子网站数。有关如何估计数据库大小和 IOPS 要求的详细信息，请参阅性能和容量测试结果及建议 (SharePoint Server 2010)。

安全存储

Secure Store Service 应用程序数据库的大小由存储中的凭据数和审核表中条目数决定。建议您为该数据库每 1,000 个凭据分配 5 MB。它具有最低要求的 IOPS。

状态

State Service 应用程序有一个数据库。建议为其分配 1 GB。它具有最低要求的 IOPS。

Word Automation Service

Word Automation Service 应用程序有一个数据库。建议为其分配 1 GB。它具有最低要求的 IOPS。

PerformancePoint

PerformancePoint Service 应用程序有一个数据库。建议为其分配 1 GB。它具有最低要求的 IOPS。

确定可用性需求

可用性是用户认为针对 SharePoint Server 2010 环境可供使用的程度。可用系统是一个弹性系统，即不经常发生影响服务的事件，并且在事件发生时及时采取有效措施。

可用性要求会显著增加存储需求。有关详细信息，请参阅规划可用性 (SharePoint Server 2010)。

选择 SQL Server 版本

虽然 SharePoint 2010 产品可以在 Microsoft SQL Server 2008 R2、SQL Server 2008 或 SQL Server 2005 上运行，但强烈建议您考虑在 SQL Server 2008 或 SQL Server 2008 R2 的 Enterprise Edition 中运行您的环境，以利用它提供的额外性能、可用性、安全性和管理功能。有关使用 SQL Server 2008 R2 Enterprise Edition 的好处的详细信息，请参阅SQL Server 2008 R2 和 SharePoint 2010 产品：关联后功能更强大（白皮书）(SharePoint Server 2010)。

特别考虑对以下功能的需求：

  • 备份压缩 备份压缩可以加速任何 SharePoint 备份，在 SQL Server 2008 Enterprise Edition 或 SQL Server 2008 R2 Standard Edition 中提供。通过在备份脚本中设置压缩选项或在默认情况下通过配置运行 SQL Server 的服务器进行压缩，可以大大减小数据库备份和传送日志的大小。有关详细信息，请参阅备份压缩 (SQL Server) (https://go.microsoft.com/fwlink/p/?LinkId=129381)。

    备注

    SharePoint 2010 产品 不支持 SQL Server 数据压缩，Search Service 应用程序数据库除外。

  • 透明数据加密 如果您的安全要求包括对透明数据加密的需求，则必须使用 SQL Server Enterprise Edition。

  • Web Analytics Service 应用程序 如果您规划使用 Web Analytics Service 应用程序进行大量分析，请考虑使用 SQL Server Enterprise Edition，以便系统可以利用表分区。

  • 内容部署 如果您规划使用内容部署功能，请考虑使用 SQL Server Enterprise Edition，以便系统可以利用 SQL Server 数据库快照。

  • 远程 BLOB 存储 如果想要利用与每个内容数据库关联的文件之外的数据库或位置的远程 BLOB 存储，必须使用 SQL Server 2008 或 SQL Server 2008 R2 Enterprise Edition。

  • 资源调控器 资源调控器是 SQL Server 2008 中引入的一项技术。利用该技术，可以通过指定因传入请求产生的资源消耗的限额，来管理 SQL Server 工作负荷和资源。利用资源调控器，可以区分工作负荷并根据您指定的限额在工作负荷请求时分配 CPU 和内存。资源调控器仅在 SQL Server 2008 或 SQL Server 2008 R2 Enterprise Edition 中提供。有关使用资源调控器的详细信息，请参阅使用资源调控器管理 SQL Server 工作负荷。

    建议结合 SharePoint Server 2010 使用资源调控器执行下列操作：

    • 限制搜索爬网组件的目标 Web 服务器消耗的 SQL Server 资源量。建议的最佳实践是当系统在负载情况下，将爬网组件限制为 10% 的 CPU。

    • 监视系统中每个数据库消耗的资源量。例如，可以使用资源调控器帮助您确定运行 SQL Server 的几个计算机中数据库的最佳放置位置。

  • PowerPivot for SharePoint 2010 使用户可以共享 Excel 和浏览器中用户生成的数据模式和分析并在此方面进行协作，同时自动刷新这些分析。它属于 SQL Server 2008 R2 Enterprise Edition Analysis Services 的一部分。

根据容量和 I/O 要求设计存储体系结构

您为环境选择的存储体系结构和磁盘类型会影响系统性能。

本节内容：

  • 选择存储体系结构

  • 选择磁盘类型

  • 选择 RAID 类型

选择存储体系结构

SharePoint Server 2010 支持直接附加存储 (DAS)、存储区域网络 (SAN) 和网络附加存储 (NAS) 存储体系结构，但是仅在 NAS 与配置为使用远程 BLOB 存储的内容数据库结合使用时支持 NAS。您的选择取决于业务解决方案和您的现有体系结构中的因素。

任何存储体系结构都必须支持您的可用性需求以及必须在 IOPS 和延迟方面表现出色。若要获得支持，系统必须在 20 毫秒 (ms) 内持续返回数据的第一个字节。

直接附加存储 (DAS)

DAS 是一个直接附加到服务器或工作站的数字存储系统，两者之间没有存储网络。DAS 物理磁盘类型包括串行附加 SCSI (SAS) 和串行附加 ATA (SATA)。

通常，建议您在共享存储平台无法保证 IOPS 在平均值和峰值的情况下具有 20 毫秒的响应时间和足够容量时，选择 DAS 体系结构。

存储区域网络 (SAN)

SAN 是一个将远程计算机存储设备（如磁盘阵列和磁带库）附加到服务器的体系结构，以这种方式，设备可以作为本地附加到操作系统的设备出现（例如块存储）。

通常，如果共享存储提供的好处对于您的组织具有重要意义，建议您选择 SAN。

共享存储的好处包括：

  • 更轻松地在服务器之间重新分配磁盘存储。

  • 可以为多个服务器提供服务。

  • 可以访问的磁盘数不受限制。

网络附加存储 (NAS)

NAS 设备是一台连接到网络的独立计算机。它的唯一目的是为网络中的其他设备提供基于文件的数据存储服务。NAS 设备上的操作系统和其他软件提供数据存储、文件系统和文件访问功能以及对这些功能的管理（例如文件存储）。

备注

NAS 仅支持用于配置为使用远程 BLOB 存储的内容数据库。任何网络存储体系结构必须在 1 毫秒内对 ping 作出响应，并必须在 20 毫秒内返回数据的第一个字节。此限制不适用于本地 SQL Server FILESTREAM 提供程序，因为它仅将数据本地存储在同一服务器上。

选择磁盘类型

您在系统中使用的磁盘类型会影响可靠性和性能。其他同等情况下，较大驱动器会增加平均寻道时间。SharePoint Server 2010 支持以下类型的驱动器：

  • 小型计算机系统接口 (SCSI)

  • 串行高级技术附件 (SATA)

  • 串行附加 SCSI (SAS)

  • 光纤通道 (FC)

  • 集成设备电子学 (IDE)

  • 固态硬盘 (SSD) 或闪存盘

选择 RAID 类型

RAID（独立磁盘冗余阵列）通常用于改善各个磁盘的性能特征（通过将多个磁盘内的数据分段）并提供保护避免发生单个磁盘故障。

SharePoint Server 2010 支持所有 RAID 类型；但是，建议您使用 RAID 10 或具有等效性能的供应商特定 RAID 解决方案。

在配置 RAID 阵列时，确保将文件系统与供应商提供的偏移对齐。在缺少供应商指导的情况下，请参阅SQL Server 预部署 I/O 最佳实践 (https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x804)。

有关设置 RAID 和 SQL Server I/O 子系统的详细信息，请参阅 SQL Server 最佳实践文章 (https://go.microsoft.com/fwlink/?linkid=168612&clcid=0x804)。

估计内存要求

SharePoint Server 2010 所需的内存与正运行 SQL Server 的服务器上托管的内容数据库的大小直接关联。

添加服务应用程序和功能时，要求可能会增加。下表提供了建议的内存量的准则。

备注

小型和中型部署的定义在文章 SharePoint Server 2010 的容量管理和调整大小概述的参考体系结构一节中介绍。

内容数据库的总计大小 建议运行 SQL Server 的计算机使用 RAM

小型生产部署的最低要求

8 GB

中型生产部署的最低要求

16 GB

建议最高 2 TB

32 GB

建议在 2 TB 与最大 5 TB 之间的范围内

64 GB

建议大于 5 TB

其他超过 64 GB 的 RAM 可能会提高 SQL Server 缓存速度

备注

这些值高于 SQL Server 的最小建议值，因为 SharePoint Server 2010 环境需要进行数据分布。有关 SQL Server 系统要求的详细信息，请参阅安装 SQL Server 2008 的硬件和软件要求 (https://go.microsoft.com/fwlink/?linkid=129377&clcid=0x804)。

影响所需内存的其他因素包括：

  • 使用 SQL Server 镜像。

  • 频繁使用大于 15 MB 的文件。

了解网络拓扑要求

在服务器场内部和彼此之间规划网络连接。建议使用延迟较低的网络。

下面的列表提供一些最佳实践和建议：

  • 服务器场中的所有服务器都应针对运行 SQL Server 的服务器具有 LAN 带宽和延迟。延迟不应大于 1 毫秒。

  • 建议不要使用广域网 (WAN) 拓扑，其中运行 SQL Server 的服务器通过具有大于 1 毫秒延迟的网络从服务器场的其他组件远程部署。此拓扑尚未测试。

  • 如果规划使用 SQL Server 镜像或日志传送来保持远程网站为最新状态，请规划可用的 WAN 网络。

  • 建议 Web 服务器和应用程序服务器具有两个网络适配器：一个适配器处理最终用户流量，另一个处理与运行 SQL Server 的服务器之间的通信。

配置 SQL Server

以下各节介绍如何规划为 SharePoint Server 2010 配置 SQL Server。

本节内容：

  • 确定需要多少个实例或服务器

  • 配置存储和内存

  • 设置 SQL Server 选项

  • 配置数据库

估计需要多少个服务器

通常，SharePoint Server 2010 旨在利用 SQL Server 向外扩展 — 即相比仅使用几个大型服务器，SharePoint Server 2010 使用大量运行 SQL Server 的中型服务器具有更好的性能表现。

始终将 SQL Server 置于未运行任何其他服务器场角色或托管任何其他应用程序的数据库的专用服务器上，除非您将系统部署在独立服务器上。

以下是何时部署将运行 SQL Server 的其他服务器的一般指南：

  • 存在四个以上 Web 服务器以全容量运行时，添加其他数据库服务器。

  • 当前服务器达到 RAM、CPU、磁盘 IO 吞吐量、磁盘容量或网络吞吐量的有效资源限制时，添加其他数据库服务器。

备注

Microsoft 支持不遵循此指南的服务器配置。

若要在运行 Secure Store Service 应用程序时提升安全凭据存储，建议将安全存储数据库托管在仅限一名管理员访问的单独数据库实例上。

配置存储和内存

在运行 SQL Server 2008 的服务器上，建议每个 CPU 的 L2 缓存最低为 2MB，以提高内存。

遵循供应商存储配置建议操作

若要在配置物理存储阵列时获得最佳性能，请遵守存储供应商提供的硬件配置建议操作，而不要使用操作系统的默认值。

如果未从供应商处获得指南，建议您使用 DiskPart.exe 磁盘配置实用程序为 SQL Server 2008 配置存储。有关详细信息，请参阅预部署 I/O 最佳实践 (https://go.microsoft.com/fwlink/p/?LinkID=105583)。

提供尽可能多的资源

确保磁盘的 SQL Server I/O 通道没有与其他应用程序共享，例如页面文件和 Internet Information Services (IIS) 日志。

提供尽可能多的总线带宽。较大的总线带宽可帮助提高可靠性和性能。考虑硬盘不是总线带宽的唯一用户，例如，您还必须考虑网络访问。

设置 SQL Server 选项

以下 SQL Server 设置和选项应在部署 SharePoint Server 之前配置。

  • 不要在支持 SharePoint Server 的 SQL Server 上启用自动创建统计信息。SharePoint Server会在进行设置和升级时配置必需的设置。自动创建统计信息会显著更改从 SQL Server 的一个实例到 SQL Server 的另一个实例的查询的执行规划。因此，为了向所有客户提供持续支持，SharePoint Server 根据需要为查询提供了编码提示，从而在所有方案中提供最佳性能。

  • 为确保获得最佳性能，强烈建议您将承载 SharePoint Server 2010 数据库的 SQL Server 实例的 max degree of parallelism (MAXDOP) 设置为 1。有关如何设置 max degree of parallelism 的详细信息，请参阅 max degree of parallelism 选项 (https://go.microsoft.com/fwlink/?linkid=189030&clcid=0x804)。

  • 为提高维护的便捷性，请为服务器场中的每个数据库服务器配置 SQL Server 连接别名。连接别名是用于连接到 SQL Server 的实例的备用名称。有关详细信息，请参阅如何：设置 SQL Server 别名 (SQL Server Management Studio) (https://go.microsoft.com/fwlink/?linkid=132064&clcid=0x804)。

配置数据库

下面的指南介绍在环境中配置每个数据库时进行规划的最佳实践。

在各磁盘之间进行数据分隔并设置优先级

理想情况下，应在单独的物理硬盘上放置 tempdb 数据库、内容数据库、使用率数据库、搜索数据库和 SQL Server 2008 事务日志。

下面的列表为设置数据优先级提供一些最佳实践和建议：

  • 在速度较快的磁盘中设置数据优先级时，请使用以下分级：

    1. Tempdb 数据文件和事务日志

    2. 数据库事务日志文件

    3. 搜索数据库（搜索管理数据库除外）

    4. 数据库数据文件

    在着重面向读取的门户网站中，将数据优先级设置为高于日志优先级。

  • 测试和客户数据显示，tempdb 的磁盘 I/O 不足可能会显著抑制 SharePoint Server 2010 服务器场的性能。为避免此问题，请为 tempdb 分配专用磁盘。如果预计存在或监测到高工作负荷（即读取操作或写入操作需要的平均时间超过 20 毫秒），则可能必须通过分隔磁盘上的文件或将磁盘替换为更快的磁盘来消除瓶颈。

  • 为获得最佳性能，请将 tempdb 放在 RAID 10 阵列上。tempdb 数据库文件数应与 CPU 内核数相同，而且 tempdb 数据文件应设置为同等大小。为此，将双核处理器算作两个 CPU。将支持超线程的每个处理器算作一个 CPU。有关详细信息，请参阅优化 tempdb 性能 (https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x804)。

  • 可将数据库数据和事务日志文件分隔到不同的磁盘上。如果由于文件太小而不足以使用整个磁盘或带区，或者您拥有的磁盘空间不足而必须使文件共享磁盘，请将具有不同使用模式的文件放在同一磁盘上，以尽量减少同时访问请求数。

  • 有关如何配置所有日志和搜索数据库以对您的特定存储解决方案进行写入优化的信息，请咨询您的存储硬件提供商。

对内容数据库使用多个数据文件

请遵循以下建议操作以便获得最佳性能：

  • 仅在数据库的主文件组中创建文件。

  • 将文件分布到不同的磁盘上。

  • 数据文件的数目应小于或等于 CPU 内核的数目。为此，将双核处理器算作两个 CPU。将支持超线程的每个处理器算作一个 CPU。

  • 创建大小相同的数据文件。

重要

虽然可以使用 SharePoint Server 2010 的内置备份和恢复工具来备份和恢复多个数据文件，但如果您在同一位置进行覆盖，则这些工具无法将多个数据文件还原到不同的位置。因此，在对内容数据库使用多个数据文件时，我们强烈建议您使用 SQL Server 备份和恢复工具。有关如何备份和恢复 SharePoint Server 2010 的详细信息，请参阅在 SharePoint Server 2010 中规划备份和恢复。

有关如何创建和管理文件组的详细信息，请参阅物理数据库文件和文件组 (https://go.microsoft.com/fwlink/?linkid=117909&clcid=0x804)。

限制内容数据库大小以提高可管理性

规划数据库大小以提高环境的可管理性和性能以及易于环境升级。

为帮助确保系统性能，我们强烈建议将内容数据库的大小限制为 200 GB，除非存在特定使用方案和条件支持更大大小的情况。有关内容数据库大小限制的详细信息，请参阅 SharePoint Server 2010 容量管理：软件边界和限制中的内容数据库限制部分。

我们通常建议网站集不应超过 100 GB，除非它是数据库中唯一的网站集，这样，您可以在需要时使用 SharePoint Server 2010 粒度备份工具，将网站集移至另一个数据库。

有关大型文档库的详细信息，请参阅性能和容量测试结果及建议 (SharePoint Server 2010) 中的“估计大型文档库性能和容量要求”。

主动管理数据和日志文件增长

建议您考虑使用以下建议，主动管理数据和日志文件增长：

  • 尽可能将所有数据和日志文件预先增长至其预期的最终大小。

  • 鉴于安全原因，建议您启用自动增长。不要依赖默认自动增长设置。配置自动增长时，考虑使用以下准则：

    • 在规划超过建议大小 (200 GB) 的内容数据库时，请将数据库自动增长值设置为固定兆字节 (MB) 数，而不是设置为百分比。这样做是为了减少 SQL Server 增加文件大小的频率。增加文件大小是一项涉及用空白页填充新空间的阻止操作。

    • 将 Search Service 应用程序属性存储数据库的自动增长值设置为 10%。

    • 如果计算预期内容数据库的大小在下一年内不会达到建议的 200 GB（最大大小），通过使用 ALTER DATABASE MAXSIZE 属性，将其设置为预期数据库在一年内可达到的最大大小（含 20% 的附加误差限度）。定期查看此设置以确保其始终是基于过去增长率的适当值。

  • 将磁盘中的可用空间保持在 25% 这一级别，以便适应增长和高峰使用模式。如果通过将磁盘添加到 RAID 阵列或分配更多存储空间来管理增长，请密切监视磁盘大小以避免空间不足。

验证和监视存储和 SQL Server 性能

对硬件的性能和备份解决方案进行测试，使您可以满足服务水平协议 (SLA)。尤其对运行 SQL Server 的计算机的 I/O 子系统进行测试以确保性能令人满意。

对用来确保可在可用的维护时段内备份系统的备份解决方案进行测试。如果备份解决方案不能满足您的业务所需的 SLA，请考虑使用增量备份解决方案，如 System Center Data Protection Manager (DPM) 2010。

跟踪运行 SQL Server 的服务器的以下资源组件至关重要：CPU、内存、缓存/点击率和 I/O 子系统。一个或多个组件变慢或超载时，根据当前和预定工作负荷分析适当策略。有关详细信息，请参阅 SQL Server 2008 性能问题疑难解答 (https://go.microsoft.com/fwlink/?linkid=168448&clcid=0x804)。

下节列出性能计数器，建议您用其监视在 SharePoint Server 2010 环境中运行的 SQL Server 数据库的性能。此外还列出每个计数器的运行状况近似值。

有关如何监视性能和使用性能计数器的详细信息，请参阅监视性能 (https://go.microsoft.com/fwlink/?linkid=189032&clcid=0x804)。

要监视的 SQL Server 计数器

监视以下 SQL Server 计数器，确保服务器的运行状况良好：

  • 常规统计信息 此对象提供计数器用以监视常规服务器端活动，如当前连接数以及每秒与运行 SQL Server 实例的计算机连接或断开连接的用户数。考虑监视以下计数器：

    • 用户连接 此计数器显示运行 SQL Server 的计算机上的用户连接数。如果看到这一数字自基线上升了 500%，您会发现性能下降。

  • 数据库 此对象提供计数器用以监视大容量复制操作、备份和还原吞吐量以及事务日志活动。监视事务和事务日志以便确定数据库中发生的用户活动量以及事务日志达到的填满程度。用户活动量决定数据库的性能并影响日志大小、锁定和复制。监视低级日志活动用以衡量用户活动和资源使用率，可帮助您找到性能瓶颈所在。考虑监视以下计数器：

    • 事务数/秒 此计数器显示每秒指定数据库或整个服务器上的事务数。此数字更重要的是为您提供基线，帮助您解决问题。

  • 锁数 此对象提供有关各资源类型上 SQL Server 锁数的信息。考虑监视以下计数器：

    • Average Wait Time (ms) 此计数器显示每个导致等待的锁请求的平均等待时间量。

    • Lock Wait Time (ms) 此计数器显示锁在最后一秒内的等待时间。

    • Lock waits/sec 此计数器显示每秒不能立即达到满意且必须等待资源的锁数。

    • Number of deadlocks/sec 此计数器显示每秒运行 SQL Server 的计算机上的死锁数。此值不能超过 0。

  • 闩锁 此对象提供计数器以监视称为闩锁的内部 SQL Server 资源锁。监视闩锁确定用户活动和资源利用率，可以帮助您找到性能瓶颈所在。考虑监视以下计数器：

    • Average Latch Wait Time (ms) 此计数器显示必须等待的闩锁请求的平均闩锁等待时间。

    • Latch Waits/sec 此计数器显示未能立即授予的闩锁请求数。

  • SQL 统计信息 此对象提供计数器以监视送到 SQL Server 实例的编译和请求类型。监视查询编译和重新编译数以及由 SQL Server 的实例收到的批次数，可为您提供一个 SQL Server 以多快的速度处理用户查询以及查询优化器处理查询的效率的指示。考虑监视以下计数器：

    • SQL Compilations/sec 此计数器指示每秒编译代码路径被进入的次数。

    • SQL Re-Compilations/sec 此计数器指示每秒语句重新编译数。

  • 缓冲区管理器 此对象提供计数器以监视 SQL Server 使用内存存储数据页面、内部数据结构和过程缓存的方式，并提供计数器以监视 SQL Server 读取和写入数据库页面时的物理 I/O。考虑监视以下计数器：

    • Buffer Cache Hit Ratio

    • 此计数器显示在缓冲区缓存中找到而不需要从磁盘中读取的页面的百分比。该比率是缓存命中总数与最近几千次页面访问的缓存查找总数之比。由于从缓存读取比从磁盘读取成本要低得多，因此您需要将此比率设置为较高值。通常，您可以通过增加 SQL Server 可用的内存量提高缓冲区缓存命中率。

  • 计划缓存 此对象提供计数器以监视 SQL Server 使用内存存储对象（如存储过程）、临时和准备的 Transact-SQL 语句和触发器的方式。考虑监视以下计数器：

    • Cache Hit Ratio

    • 此计数器指示规划的缓存命中数与查找数的比率。

要监视的物理服务器计数器

监视以下计数器以确保运行 SQL Server 的计算机的运行状况良好：

  • Processor: % Processor Time: _Total 此计数器显示处理器执行应用程序或操作系统进程（未空闲）所花的时间百分比。在运行 SQL Server 的计算机上，此计数器的值应保持在 50% 与 75% 之间。在不断超载的情况下，调查是否存在异常进程活动或服务器是否需要额外 CPU。

  • System: Processor Queue Length 此计数器显示处理器队列中的线程数。监视此计数器以确保线程数始终小于 CPU 内核数的两倍。

  • Memory: Available Mbytes 此计数器显示计算机上运行的处理器可用的物理内存量（以 MB 为单位）。监视此计数器以确保将总可用物理 RAM 保持在至少 20% 这一水平。

  • Memory: Pages/sec 此计数器显示为解决硬页面错误从磁盘读取页面或将页面写入磁盘的速度。

有关详细信息和内存疑难解答方法，请参阅 SQL Server 2005 监视内存使用量 (https://go.microsoft.com/fwlink/?linkid=105585&clcid=0x804)。

要监视的磁盘计数器

监视以下计数器以确保磁盘运行状况良好。请注意，下列值代表随着时间的推移测量的值（不是突然波动出现的值，也不是基于一次测量的值）。

  • Physical Disk: % Disk Time: DataDrive 此计数器显示所选磁盘驱动器处理读取或写入请求的运行时间的百分比，通常指示磁盘的繁忙程度。如果“PhysicalDisk: % Disk Time”计数器的值很高（超过 90%），请检查“PhysicalDisk: Current Disk Queue Length”计数器以查看等待磁盘访问的系统请求数。等待 I/O 请求数应保持在不超过组成物理磁盘的轴数的 1.5 到 2 倍。

  • Logical Disk: Disk Transfers/sec 此计数器显示在磁盘上执行读取和写入操作的速率。使用此计数器可监视增长趋势并进行适当地预测。

  • Logical Disk: Disk Read Bytes/sec 和 Logical Disk: Disk Write Bytes/sec 这两个计数器显示在读取或写入操作过程中从磁盘传送字节的速率。

  • Logical Disk: Avg. Disk Bytes/Read 此计数器显示在读取操作过程中从磁盘传送的平均字节数。该值可反映磁盘延迟 — 较大的读取操作会导致更长的延迟时间。

  • Logical Disk: Avg. Disk Bytes/Write 此计数器显示在写入操作过程中传送到磁盘的平均字节数。该值可反映磁盘延迟 — 较大的写入操作会导致更长的延迟时间。

  • Logical Disk: Current Disk Queue Length 此计数器显示在收集性能数据时磁盘上未完成的请求数。对于此计数器，值越小越好。若每个磁盘未完成的请求数大于 2，则指示存在瓶颈，并应进行调查。这意味着，对于由 4 个磁盘组成的逻辑单元 (LUN)，可以接受的最大值为 8。瓶颈会造成工作积压，这些工作积压会扩展到正在访问磁盘的当前服务器之外，从而导致用户长时间等待。可以通过以下方法来解决瓶颈：向 RAID 阵列添加更多的磁盘，用速率更快的磁盘替换现有磁盘或将一些数据移动到其他磁盘。

  • Logical Disk: Avg. Disk Queue Length 此计数器显示在采样间隔期间为选定磁盘排队的读写请求的平均数。此规则指明，每个心轴的未完成的读写请求不应超过 2 个，但由于存储虚拟化和各个配置间的 RAID 级别的差异，导致难以测量此请求数。请查找既大于平均磁盘队列长度又大于平均磁盘延迟的情况。此组合可指示存储阵列缓存使用过度或与其他应用程序共享心轴会影响性能。

  • Logical Disk: Avg. Disk sec/Read 和 Logical Disk: Avg. Disk sec/Write 这两个计数器显示对磁盘执行读取或写入操作所花费的平均时间（以秒为单位）。监视这两个计数器，确保二者的值保持在磁盘容量的 85% 以下。如果读取或写入操作大于磁盘容量的 85%，则磁盘访问时间将按指数方式增加。若要确定硬件的特定容量，请参考供应商文档，或使用 SQLIO 磁盘子系统基准工具计算容量。有关详细信息，请参阅 SQLIO 磁盘子系统基准工具 (https://go.microsoft.com/fwlink/?linkid=105586&clcid=0x804)。

    • Logical Disk: Avg. Disk sec/Read 此计数器显示对磁盘进行读取操作所花费的平均时间（以秒为单位）。在经良好调整的系统上，对于日志，理想值为 1 到 5 毫秒（在缓存阵列上，最好为 1 毫秒）；对于数据，理想值为 4 到 20 毫秒（最好是小于 10 毫秒）。在高峰期会出现更长的延迟，但如果定期出现较高的值，则应调查其原因。

    • Logical Disk: Avg. Disk sec/Write 此计数器显示对磁盘进行写入操作所花费的平均时间（以秒为单位）。在经良好调整的系统上，对于日志，理想值为 1 到 5 毫秒（在缓存阵列上，最好为 1 毫秒）；对于数据，理想值为 4 到 20 毫秒（最好是小于 10 毫秒）。在高峰期会出现更长的延迟，但如果定期出现较高的值，则应调查其原因。

    在将 RAID 配置与“Logical Disk: Avg. Disk Bytes/Read”或“Logical Disk: Avg. Disk Bytes/Write”计数器配合使用时，请使用下表中列出的公式以确定在磁盘上进行输入和输出操作的速率。

    RAID 级别 公式

    RAID 0

    I/Os per disk = (reads + writes) / number of disks

    RAID 1

    I/Os per disk = [reads + (2 × writes)] / 2

    RAID 5

    I/Os per disk = [reads + (4 × writes)] / number of disks

    RAID 10

    I/Os per disk = [reads + (2 × writes)] / number of disks

    例如，如果有一个带两个物理磁盘的 RAID 1 系统，则各个计数器将具有下表中显示的值。

    计数器 值

    Avg. Disk sec/Read

    80

    Logical Disk: Avg. Disk sec/Write

    70

    Avg. Disk Queue Length

    5

    可使用以下公式计算每个磁盘的 I/O 值：(80 + (2 × 70))/2 = 110

    可使用以下公式计算磁盘队列长度：5/2 = 2.5

    在此情况下，存在一个边框 I/O 瓶颈。

其他监视工具

也可以使用 SQL Server 2008 中的 sys.dm_io_virtual_file_stats 动态管理视图来监视磁盘延迟并分析趋势。有关详细信息，请参阅 sys.dm_io_virtual_file_stats (Transact-SQL) (https://go.microsoft.com/fwlink/?linkid=105587&clcid=0x804)。

See Also

Other Resources

资源中心：SharePoint Server 2010 的容量管理
资源中心：SQL Server 和 SharePoint Server 2010 数据库