标签:
这个问题现在有了一些新的发现。
首先,我找到了重现客户那里出现的那个复杂SQL语句的方法。这个现象其实是这样的:
所以客户那里出现那个SQL 语句的原因是 “List View Threshold“调整得太大。而”List View Threshold”调大的原因,是为了让普通用户能够打开文档库。
但是其实我们有更好的办法可以在不调大“List View Threshold“(也就避免了SharePoint使用适合小数据量大SQL语句操作大数据量的文档库,从而造成性能问题)的前提下,让普通用户也打开文档。
方法是执行下面的PowerShell 脚本。
$app=Get-SPWebApplication “http://<site url>”
$app.UnthrottledPrivilegedOperationWindowEnabled=$true
$app.DailyUnthrottledPrivilegedOperationsDuration=24
$app.Update()
这个脚本的目的是修改SharePoint对于大List/Library(也就是list item数量操作 List View Threshold的list )操作的一个开关。SharePoint 2013可以规定一天中某些时段允许普通用户打开大List。默认是不允许的,目的是为了整个系统的Scalability。但是在客户的这个环境中,访问这些大文档库是必须的,所以我们可以修改为一天中24个小时都能够让普通用户访问大list。
这样List View Threshold不再是限制用户访问的一个阈值,而是SQL语句优化的一个阈值。通常List View Threshold 设置5,000是比较合适的。客户那里有约30,000个文档,所以肯定会使用优化的语句。
下面的PowerShell脚本可以比较方便地修改这个值。
$app=Get-SPWebApplication “http://<site url>”
$app.MaxItemsPerThrottledOperation=5000
$app.Update()
遗憾的是SharePoint这些比较高级的调优功能(应该说是设计很巧妙的),缺乏文档说明。所以很少有人知道。MSDN有关于这两些设置的字面解释,但是没有给出生动的范例来说明其用途。我们只能够通过程序的调试,从源代码中看出这些设置的实际用途。
标签:
原文地址:http://www.cnblogs.com/hqbird/p/4257033.html