如何改善SQL Server + SharePoint组合性能
日期：作者：
【TechTarget中国原创】当系统性能开始下降时，最初的解决方法通常是添加更多的Web服务器以更好地处理负载。但是前端服务器通常依赖于后端数据库，因此在SharePoint环境中遇到的大多数性能问题都与后端相关，因为它本质上依赖作为其数据库和文件系统。并不是说SQL Server本身存在性能问题，但的确存在这样的隐患，即SharePoint的处理要求往往会凸显出SQL Server最常见的性能瓶颈：磁盘I/O……
我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。
我原创，你原创，我们的内容世界才会更加精彩！
【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
TechTarget中国
理解不同类型的DBMS有哪些特点，以及再何时、何处（场景）使用它们是十分必要的。在这本电子书中，我们就将进行一个详细的介绍，希望能够为您的数据库选型起到帮助、指导作用。
在选择SAP HANA的时候，CIO需要关注哪些问题？在产品的选型、实施与上线阶段，都有哪些经验可以借鉴？在本次的TechTarget电子书中，我们将为您一一解读。它也将成为企业选择HANA时，最有实用价值的参考资料。
很多企业关系自己是否应该从传统数据库转到NoSQL数据库，应该选择什么样的数据库？本书详列了相应的技巧和案例，供您参考。
TechTarget数据库网站每两年就会进行一次“数据库工程师薪酬调查”，对不同行业、不同层次的数据库技术从业者的薪酬待遇情况进行一次摸底。
TechTarget
企业级IT网站群
TechTarget中国 版权所有
All Rights Reserved, Copyright
TechTarget中国 版权所有
All Rights Reserved, Copyright
【TechTarget中国原创】当系统性能开始下降时，最初的解决方法通常是添加更多的Web服务器以更好地处理负载。但是前端服务器通常依赖于后端数据库，因此在SharePoint环境中遇到的大多数性能问题都与后端相关，因为它本质上依赖作为其数据库和文件系统。并不是说SQL Server本身存在性能问题，但的确存在这样的隐患，即SharePoint的处理要求往往会凸显出SQL Server最常见的性能瓶颈：磁盘I/O。　　进行SharePoint长期性能管理规划时，特别要牢记这一点。因此我们要尽可能去减轻或者避免被SQL Server I/O束缚。　　从SQL Server数据库中提取SharePoint的二进制大对象或BLOB(通常是文件附件)，这是用户最常用的操作。SharePoint和 SQL Server都支持微软的(RBS)，它可以让SQL Server把所有的文档(包括Word、Excel等)放到它们所属的NTFS文件系统上。　　NTFS可以快速地读取和写入文件，而SQL Server需要跨越其8KB 的数据库页才能管理它们，这将会吃掉大量的磁盘空间和服务器资源。为避免出现这种情况，RBS技术将文件放在NTFS上，然后将它们的指针提供给SQL Server。这意味着你可以将文件附件放到与数据库所在磁盘不同的位置上，这将有助于减少磁盘争用和保持SQL Server性能。　　高端存储和定期维护　　最佳的SharePoint性能管理投资之一是购买大量的高端存储设备。组织在制定购买计划时首先应注重速度，因为它往往是最昂贵的一个方面。如果负担得起，使用的超高速存储区域网络就可以提供SharePoint所需要的高端存储性能。当然，必须确保有足够的存储容量可存放SharePoint安装过程中创建的所有数据。　　定期维护对当前SQL Server的执行效率也至关重要。SharePoint协作平台会生成大量的数据，尤其是在大量使用版本控制以跟踪文件变更的文档存储中，而且为参考用途而维护多个版本。大量的新数据使得SQL Server无法以最佳方式执行查询。适当的数据库维护，包括重建或重新组织索引并更新SQL Server统计信息，有助于SQL Server保持最佳性能。此外，当碎片率开始超过 7%或8%时，可以有意识地进行数据库文件的碎片整理。　　拆分　　虽然SharePoint本身的可扩展性不存在什么大问题，但是SQL Server恰好相反。这就是为什么许多大型SharePoint系统的管理员会建立多个服务器农场，每个农场对应一个专用的后端系统。例如，一个组织可以有一套SharePoint服务器和三个SQL Server数据库，一个用于公司文档库，一个用于用户博客，一个用于特别项目。这就比让单个SQL Server数据库转储所有东西更富有成效。　　SharePoint系统管理员还应该计划购买几个额外的工具，比如SharePoint的原生备份程序。此外，管理员还应经常访问微软的TechNet网站，网站详细列出了可行的解决方案，从特定的性能问题到维护SharePoint系统速度的最佳实践。　　不过，许多SharePoint性能问题最终还是会被追溯到SQL Server的磁盘I/O。因此你需要从一开始就专注于构建可靠、可扩展且易于管理的后端存储。　　定义、追踪性能指标　　为SharePoint系统定义一些合理和可衡量的性能指标也是非常重要的。关键是要基于最终用户体验来尝试和定义。换句话说，可接受的性能可以根据用户在签出文档、访问博客、或完成另一个SharePoint任务时所期望的最大等待时间来界定。然后这种衡量标准可以细分为很多潜在的后端性能指标，以便评估SQL Server的状况。　　一旦定义了用户体验指标，你就需要定期进行检测，根据结果绘制趋势图。这更易于地判断SharePoint 系统是否能够满足公司的期望。SQLSERVER 数据库性能的基本
很久没有写文章了，在系统正式上线之前，DBA一般都要测试一下服务器的性能
比如你有很多的服务器，有些做web服务器，有些做缓存服务器，有些做文件服务器，有些做数据库服务器
做数据库服务器的那台服务器性能要相对较好，磁盘，内存，CPU等等，
那么在选用其中某一台服务器作为数据库服务器之前需要测试每一台服务器的性能
并且需要设置一些硬件的参数，例如设置磁盘控制器的参数，参考文章：
那么具体怎麽测试呢？怎麽得出测试指标呢？
大家可以参考这篇文章：
随着市场份额的SQL Server的发展随着时间的推移,有越来越多的对SQL服务器性能调优的需求。
有不同的团队和个人采用各种各样的方法提高SQLSERVER服务器的性能,
而且我认为这些记录SQLSERVER&troubleshooting&的基本步骤和提高各种程序性能的文档对SQLSERVER社区是有意义的
为了SQLSERVER能有效运行，监控和优化SQLSERVER的磁盘子系统是一个重要的方面
我们需要非常明确磁盘的性能需求
Avg. Disk Sec/Read 这个计数器是指每秒从磁盘读取数据的平均值
下面的列表显示这个计数器值的范围，并指出这个计数器所处范围的意思
少于 10 ms - 非常好在 10 - 20 ms 之间- 还可以在 20 - 50 ms 之间- 慢，需要关注大于 50 ms &严重的 I/O 瓶颈
磁盘性能测试工具
（1）CrystalDiskMark
（2）HDTUNE 硬盘检测修复工具&
（3）ATTO Disk Benchmark&
辨别I/O瓶颈
PhysicalDisk Object：Avg. Disk Queue：所选物理磁盘在取样期间被排队的磁盘读写请求平均值
如果你的磁盘队列长度经常超出SQLSERVER磁盘使用峰值的2倍，那意味着可能有I/O瓶颈了
Avg. Disk Sec/Read：每秒从磁盘读取数据的平均值&
Avg. Disk Sec/Write：写入数据到磁盘的平均时间，Avg. Disk Sec/Read参考指标
Physical Disk:%Disk Time磁盘时间是所选磁盘驱动器繁忙处理读写请求时所花时间的百分比，一个指标就是如果这个值大于50%，那么就存在I/O瓶颈
Avg. Disk Reads/Sec：在磁盘上的读操作的比率。确保这个数字小于磁盘吞吐量的85%。当这个值超过85%磁盘访问时间会以指数式增长
Avg. Disk Writes/Sec&c：在磁盘上的写操作的比率。确保这个数字小于磁盘吞吐量的85%。当这个值超过85%磁盘访问时间会以指数式增长
对于更多的信息，可以参考&如何创建性能计数器集&：
磁盘驱动器的位置：
为了不同的目的，你需要使用不同的驱动器来存放下面的东西独立的磁盘延时需求：数据库大于15ms
事务日志大于2ms
Tempdb数据库大于2ms
磁盘速度的优先级
意思是说，Tempdb放在单独的物理磁盘，事务日志文件放在单独的物理磁盘，数据文件放在单独的物理磁盘，操作系统放在单独的物理磁盘，
数据库备份文件放在单独的物理磁盘
一般我们的做法：不可能有那么多单独的物理磁盘，一般就是做了磁盘阵列的存储
C盘放操作系统文件
D盘放数据文件和事务日志文件 和Tempdb数据文件和Tempdb日志文件
E盘放数据库备份文件
当格式化磁盘的时候，对于要存放SQLSERVER数据文件和日志文件的磁盘，尽量不要使用默认的磁盘分配单元
使用64k 簇大小 Allocation Unit 来格式化磁盘，至于为什麽大家可以看一下这篇文章：
杀毒软件会对SQLSERVER的一些功能产生问题，使用杀毒软件的排除功能将数据库的文件排除在扫描的范围外是很重要的（放入杀软的扫描例外里）
下面的文件类型是需要排除在外的
*.mdf, *.ndf, *.ldf, *.bak
相关文章：
文章中说到因为杀毒软件扫描备份文件夹并锁住了备份文件夹，导致SQLSERVER备份数据库失败
总是给分配最大的内存给SQLSERVER实例在服务器属性那里设置
注意:最大内存设置只对SQLSERVER的buffer cache部分有效，不包括SQLSERVER的一些需要内存的功能，例如复制
（SQLSERVER2012的最大内存设置已经可以限制buffer cache部分和非buffer cache部分的内存）
为了指明Non-Buffer Pool 的内存占用，使用下面的说明
SQL Server&s buffer pool外的内存需求（这个需求不是说你设置了SQLSERVER最大内存之后，所剩下的内存的需求，不管你有没有设置SQLSERVER的最大内存
下面几项都是服务器固定需要消耗的内存，而无论你的服务器内存是4G,8G还是16G，下面几项都会固定占用服务器的内存）
（1）操作系统需要占用2GB内存，如果是64位操作系统，操作系统占用内存不大于3GB
（2）SQLSERVER工作线程的倍数，你可以在SQLSERVER服务器属性里设置最大工作线程，
每个线程会使用0.5MB内存（X86服务器）
每个线程会使用2MB内存（X64服务器）
每个线程会使用4MB内存（Itanium服务器）
注意：0.5MB内存存放的是线程自身的数据结构和相关信息，不包括数据
为什么各种服务器所分配的线程内存不一样，这个是操作系统分配的，SQLSERVER并没有做特别的设置！
如果你设置最大的工作线程数为10个，服务器是X86，刚好服务器用尽了10个线程，那么占用的内存是10*0.5MB=5MB内存
（3）1GB的&multi-page 内存占用，链接服务器和其他SQLSERVER外围的程序占用
（4）运行在服务器上的程序可能占用1~3GB内存，例如备份程序
&例如，一个8核服务器，16GB内存，运行着SQLSERVER2012 X64，上面运行着第三方的备份程序，你可以参照下面的清单
&（1）3GB 给 Windows (2GB for 32 Bit Windows)
&（2）1GB 给 SQLSERVER 工作线程 (576 & 2MB 大概)
各种CPU和SQLSERVER版本组合自动配置的最大工作线程数CPU数 & & & 32位计算机 & & &64位计算机&=4 & & & & & & 256 & & & & & & & 5128 & & & & & & & & 288 & & & & & & & 57616 & & & & & & & 352 & & & & & & & &70432 & & & & & & & 480 & & & & & & & &960
（3）1GB for MPAs, etc. （multi-page apply）
（4）1~2 GB 给 备份程序.
您能够找到更多信息关于&最大工作线程选项&
(For SQL Server 2008).
开启Lock Pages in Memory 选项
Windows组策略决定哪个Windows账户能使进程将他的数据逗留在物理内存里，防止操作系统把程序数据从物理内存换页换出磁盘上的虚拟内存
这能够给您带来性能上的提升，特别遇到内存压力的时候
TempDB 数据库的优化
默认，Tempdb数据库只有一个数据文件和事务日志文件。然而，为了性能的优化，跟着下面给出的建议最佳实践
TempDB数据库的存储计划
（1）设置Tempdb数据库的恢复模式为简单（默认就是简单的），简单模式能够自动回收日志空间使日志空间的需求保持最小
（2）不要让Tempdb的数据文件自动增长，这可以减少管理动态文件增长的CPU开销
&对于Tempdb数据库，可以分开多个数据文件（总的Tempdb数据库数据文件的数量=CPU逻辑处理器的数量，比如8核服务器可以分8个数据文件）
每个数据文件的大小要一样
（3）尝试将这些数据文件存放在不同的磁盘驱动器上以利用并行I/O
（4）TempDB 数据文件和 日志文件应该存放在较快速度的磁盘上（如果可能推荐放在做了RAID 1的磁盘上）
（5）使用RAID-10 或者 SSD 磁盘
（6）预先定义好Tempdb数据库的文件大小
（7）设置Tempdb总的大小为当前数据库实例中最大的那个数据库的25%&
（8）设置Tempdb数据文件自动增长的固定大小小于200MB
（9）你应该设置Tempdb数据库的数据文件数量跟逻辑CPU的数量一致，最多不超过8个数据文件
设置最大并行度（Max Degree of Parallelism）
定义多少个逻辑CPU能并行执行查询
很多微软的产品，例如SharePoint 和&Dynamics CRM都把这个设置设置为1，这个是推荐的设置
对于 SharePoint &的LOB 应用程序，当你看到有很多CXPACKETS 的等待类型在你的SQLSERVER服务器里，
你应该考虑一下将这个设置（Max Degree of Parallelism）设置为1
索引填充因子
如果你的SQLSERVER服务器有非常高的事务量TPS （transaction per second）
你的索引有比较高碎片级别，考虑一下将填充因子设置为&80%&
并且使用下面的SQL语句检测一下索引碎片
DB_NAME(ps.database_id) AS 'Database Name' ,
OBJECT_NAME(ps.OBJECT_ID) AS 'Database Object' ,
ps.index_id ,
ps.avg_fragmentation_in_percent
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS ps
INNER JOIN sys.indexes AS b ON ps.OBJECT_ID = b.OBJECT_ID
AND ps.index_id = b.index_id
ps.database_id = DB_ID('ReportServerTempDB')
ORDER BY ps.avg_fragmentation_in_percent DESC
使用Performance Monitor (Perfmon.exe)来监控系统性能
为了捕获SQLSERVER特定的性能指标，你需要使用下面的计数器
Processor: % Processor Time &：平均应该低于75% （最好低于50%） &&
System: Processor Queue Length：平均每个逻辑CPU应该低于2，例如在一个2逻辑CPU的机器上，他应该保持在4
Memory&Pages/sec：平均应该低于20（最好低于15%）
Memory&Available Bytes ：可用内存应该保持在50MB以上
Physical Disk&% Disk Time：Physical Disk&Avg. Disk Queue Length ：每个磁盘平均应该低于2，例如：一个RAID5磁盘，这个指标应该平均低于10
Physical Disk&Avg. Disk Reads/sec ：取决于CPU和磁盘的大小，应该低于相对应磁盘的吞吐量的85%
Network Interface&Bytes Total/sec ：用于统计网络带宽方
SQL Server: Buffer Manager&Page Life Expectancy：用于统计内存，应该保持在300秒SQL Server:&一般统计用户的连接数 来估计大概使用的内存SQL Server: Databases& Transactions/sec ：每秒的事务数SQL Server: Databases&Data File(s) Size KB：用于统计数据库数据文件的大小，衡量磁盘子系统的性能SQL Server: Databases&Percent Log ：衡量磁盘子系统的性能
如有不对的地方，欢迎大家拍砖o(&_&)o&
阅读(...) 评论()}