适用于:
2013
2016
2019
Subscription Edition
SharePoint in Microsoft 365
使用 Service Pack 1 (SP1) 、SQL Server 2016 或 SQL Server 2017 RTM 在 SQL Server 2014 上配置和维护 SharePoint Server 2016 和 2019 关系数据库时,必须选择提升性能和安全性的选项。 同样,在配置和维护 SQL Server 2008 R2 Service Pack 1 (SP1)、SQL Server 2012 和 SQL Server 2014 上的 SharePoint Server 2013 关系数据库时,需要选择能够提升性能和安全性的选项。
本文中的最佳实践将按照它们应用的顺序进行排列:安装和配置 SQL Server、部署 SharePoint Server,然后维护服务器场。 大部分实践同时适用于 SQL Server 的所有版本。 对于 SQL Server 版本唯一的实践将显示在单独的区域中。
[!注意] 如果计划在 SharePoint Server 2016 服务器场使用 SQL Server 商业智能组件,则必须使用 SQL Server 2016 CTP 3.1 或更高版本。 现在可以使用 SQL Server Power Pivot for SharePoint 外接程序下载 SQL Server 2016 CTP 3.1 或更高版本。 还可以通过在 SharePoint 集成模式下安装 SQL Server Reporting Services (SSRS) 以及从 SQL Server 安装媒体安装 SSRS 前端外接程序来使用 Power View。
有关详细信息,请下载新的
在 SharePoint 2016 中部署 SQL Server 2016 PowerPivot 和 Power View
白皮书。 有关在多服务器 SharePoint Server 2016 服务器场中配置和部署商业智能的详细信息,请下载
Deploying SQL Server 2016 PowerPivot and Power View in a Multi-Tier SharePoint 2016 Farm
(在多层 SharePoint 2016 服务器场中部署 SQL Server 2016 PowerPivot 和 Power View)。
[!注意] 如果计划在 SharePoint Server 2013 服务器场中使用 SQL Server 商业智能组件,必须使用 SQL Server 2012 Service Pack 1 (SP1) 或 SQL Server 2014。 有关 SQL Server 2012 SP1 BI 和 SharePoint Server 2013 的信息,请参阅
将 SQL Server BI 功能随 SharePoint 2013 一起安装 (SQL Server 2012 SP1)
。 有关 SQL Server 2014 和 SharePoint Server 2013 的详细信息,请参阅
安装 SQL Server 2014 商业智能功能
。
本文中的最佳实践适用于带 SharePoint Server 的 SQL Server 的关系数据库管理系统 (RDBMS)。
使用 SQL Server 的专用服务器
为确保服务器场操作的最佳性能,我们建议在不运行其他服务器场角色和不为其他应用程序托管数据库的专用服务器上安装 SQL Server。 唯一的例外是在独立服务器上在Single-Server场角色或 SharePoint 2013 中部署 SharePoint Server 2016 或 2019,该服务器用于开发或测试,不建议用于生产。 有关详细信息,请参阅
SharePoint Server 2016 和 2019 中的 MinRole 和相关服务的说明
和
在一台服务器上安装 SharePoint Server 2016 或 2019
。
将专用服务器用于关系数据库的建议同样适用于部署虚拟环境中的 SQL Server。
为确保一致的行为和性能,请在部署 SharePoint Server 之前配置以下选项和设置。
由于维护多个 SQL 实例的潜在性能问题,建议为每个部署的数据库服务器使用单个 SQL Server 实例。
不要在 SharePoint 内容数据库上启用自动创建统计信息。 启用自动创建统计信息在 SharePoint Server 中不受支持。 SharePoint Server 将在设置和升级期间配置请求的设置。 手动启用 SharePoint 上的自动创建统计信息将显著改变查询的执行计划。 SharePoint 数据库可以使用能够维护统计信息 (proc_UpdateStatistics) 的存储过程或依赖 SQL Server 来执行此操作。
对于 SharePoint Server 2013,维护计划由 SharePoint 管理:
SQL 统计信息由运行状况规则“SharePoint 使用的数据库具有过时的索引统计信息”管理,该规则调用 proc_updatestatics
内容数据库的“自动更新统计信息”属性设置为
False
对于 SharePoint Server 2016 和 2019,SQL 管理员必须为 SharePoint 内容数据库创建
维护计划
:
SQL 统计信息不由运行状况规则管理“SharePoint 使用的数据库具有过时的索引统计信息”
内容数据库的“自动更新统计信息”属性设置为
True
`
将承载 SharePoint 数据库的 SQL Server 实例的最大并行度 (MAXDOP) 设置为 1 以确保单个 SQL Server 过程能够为每个请求提供服务。
将最大并行度设置为其他任何数字将导致应用不是最优的查询计划,进而降低 SharePoint Server 性能。
为了有助于简化维护过程(例如为了能够更轻松地将数据库移动到其他服务器),请创建指向 SQL Server 所有实例的 IP 地址的 DNS 别名。 有关 DNS 或主机名别名的详细信息,请参阅
How to Add a Hostname Alias for a SQL Server Instance
(如何为 SQL 服务器实例添加主机名别名)。
有关这些 SQL Server 设置和选项的详细信息,请参阅
设置 SQL Server 选项
。
在部署 SharePoint Server 之前强化数据库服务器
建议您在部署 SharePoint Server 之前规划和强化数据库服务器。 有关详细信息,请参阅:
保护 SQL Server 的安全
针对 SharePoint Server 配置 SQL Server 安全性
Securing SharePoint: Harden SQL Server in SharePoint Environments
(保护 SharePoint:强化 SharePoint 环境中的 SQL Server)
SQL Server 数据库引擎和 Azure SQL 数据库安全中心
如同在前端服务器和应用程序服务器中一样,数据库服务器的配置将影响 SharePoint Server 的表现情况。 某些数据库必须和其他数据库位于同一服务器上。 相反,某些数据库和其他数据库不能位于同一服务器上。 有关详细信息,请参阅
SharePoint Server 2016 和 2019 中的 MinRole 和相关服务的说明
和存储和SQL Server容量规划和配置 (SharePoint Server)
。
有关使用镜像的高可用数据库指南,请参阅
Database Mirroring (SQL Server)
(数据库镜像 (SQL Server))。
SQL Server 故障转移群集和 Always On 可用性组
SQL Server 2012 引入了Always On可用性组功能。 该功能是一种高可用性和灾难恢复解决方案,可用来替代数据库镜像和日志传送解决方案。 Always On可用性组现在最多支持 9 个可用性副本。
[!注意] 数据库镜像将在未来的 SQL Server 版本中被弃用。 我们建议使用 Always On 可用性组。
Always On可用性组需要 Windows Server 故障转移群集 (WSFC) 群集。 WSFC 资源组是为所有已创建的可用性组而创建的。 有关详细信息,请参阅以下资源:
Always On可用性组 (SQL Server)
Always On可用性组 (SQL Server) 概述
故障转移群集和 AlwaysOn 可用性组 (SQL Server)
为 SharePoint Server 配置SQL Server Always On可用性组
设计存储以获取最优吞吐量和可管理性
我们建议您在数据库服务器上分隔开驱动器间的数据并设置这些数据的优先级。 理想情况下,您应该将 tempdb 数据库、内容数据库、使用率数据库、搜索数据库和事务日志置于单独的物理硬盘上。 以下列表将提供一些指南。 有关详细信息,请参阅
配置数据库
。
对于协作或更新密集型网站,请将以下分级用于存储分布。
排名最高的项目应在最快的驱动器中。
测试和用户数据显示 tempdb 的磁盘 I/O 不足可显著妨碍整个服务器场性能。 要避免此问题,请为存储 tempdb 数据文件的驱动器分配专用磁盘。
要获取最佳性能,请为存储 tempdb 数据文件的驱动器使用 RAID 10 阵列。 tempdb 数据文件的数量应等于 CPU 内核的数量并且必须将每个 tempdb 数据文件设置为相同的大小。
分隔不同磁盘上的数据库数据和事务日志文件。 如果数据和日志文件因空间限制而不得不共享磁盘,那么请将具有不同使用模式的文件放置在同一磁盘上以最小化并发访问请求。
为频繁使用的内容数据库使用多个数据文件并将每个文件置于其自己的磁盘上
要提高可管理性,则根据需要进行监控和调整,让内容数据库保持在 200 GB 以下,而不是限制数据库大小。
如果手动限制 SQL Server 中的数据库大小,在超出容量时将导致意外的系统停机。
合理配置 I/O 子系统对实现 SQL Server 系统的最优性能和操作非常重要。 有关详细信息,请参阅
Monitoring Disk Usage
(监视磁盘使用情况)
[!提示] 认识到数据文件和日志文件之间测量磁盘速度的方式是不同的。 适用于数据库数据的最快驱动器,对于日志文件可能不是最快的。 考虑使用模式、I/O 和文件大小。
主动管理数据的增长和日志文件
下面是针对主动管理数据增长和日志文件的建议:
如果可能,将所有数据文件和日志文件增加到预期的最终大小,或者在固定阶段定期增加它们,例如每个月、每隔 6 个月或在推出新的存储密集型网站集之前(例如,在文件迁移期间)。
启用数据库自动增长作为保护措施,以确保不会耗尽数据和日志文件的空间。 比如以下几种情况:
[!重要说明] 必须考虑与使用自动增长关联的性能和操作问题。 有关详细信息,请参阅
SQL Server 中的自动增长和自动收缩配置注意事项
。
新数据库的默认设置是按照 1 MB 的增量进行增长。 由于此自动增长的默认设置会导致数据库大小增长,因此不要依赖默认的设置。 而是使用
设置 SQL Server 选项
中提供的指南。
将自动增长值设置为固定的字节数而非百分比。 数据库越大,增长的增量也应更大。
[!注意] 设置 SharePoint 的自动增长功能时要格外小心。 如果您将数据库设置为按百分比增长,例如按 10% 的增长率,5 GB 的数据库每次将增长 500MB,这时数据文件就必须要进行扩展。 在这样的情况下,您可能会耗尽磁盘空间。
例如,考虑一下这样的场景,在其中内容将按照 100M 的增量逐渐增长并且自动增长被设置为 10MB。 接着,新的文档管理网站要求非常大的数据存储,可能起始大小为 50 GB。 那么对于这样的大型添加,将增长增量设置为 500MB 比设置为 10MB 要更为合适。
对于托管生产系统,考虑仅将自动增长作为意外增长的应急措施。 不要将自动增长选项用于管理数据和记录每日的增长。 而是将自动增长设置为一年期允许的大致大小,然后添加 20% 的误差。 同时,再设置一个警报以便在数据库运行空间不足或接近最大大小时通知您。
在驱动器间维持至少 25% 的可用空间以适应增长和峰值使用模式。 如果您将驱动器添加到 RAID 阵列或分配更多要管理的存储,请密切监视容量以避免耗尽空间。
我们建议您持续监视 SQL Server 存储和性能以确保每个生产数据库服务器足以处理其承受的负载。 此外,持续监控还允许您建立可用于资源规划的基准。
进行全面的资源监控。 不要将监控限制为特定于 SQL Server 的资源。 跟踪正在运行 SQL Server 的计算机上的以下资源同样重要:CPU、内存、缓存/命中率比率和 I/O 子系统。
当一个或多个服务器资源出现缓慢或超负荷现象时,根据当前和预计的工作负荷考虑以下性能准则。
监视和优化性能
性能监视和优化工具
服务器性能和活动监视
Windows 性能监视器
使用备份压缩加快备份并减小文件大小
备份压缩可以加快 SharePoint 备份操作的速度。 它在 SQL Server Standard 和 Enterprise Edition 中提供。 如果在备份脚本中设置压缩选项或将SQL Server配置为默认进行压缩,则可以显著减小数据库备份和传送日志的大小。 有关详细信息,请参阅
备份压缩 (SQL Server)
和数据压缩
,或
对表或索引启用压缩
SharePoint Server 内容发布团队感谢以下人员对本文的贡献:
Kay Unkroth,高级项目经理,SQL Server
Chuck Heinzelman,高级项目经理,SQL Server
SharePoint Server 2016 和 SharePoint Server 2019 环境中的 SQL Server 概述
存储和 SQL Server 容量规划与配置 (SharePoint Server)
保护 SharePoint:增强 SharePoint 环境中的 SQL Server