标签: sharepoint

此实例承载 SharePoint 2007 数据库 (SP)。针对 SP 内容数据库中一个使用率很高的表，我们遇到了许多 SELECT/INSERT 死锁。我已经缩小了涉及的资源范围，两个进程都需要对非聚集索引进行锁定。
INSERT 需要对 SELECT 资源的 IX 锁，而 SELECT 需要对 INSERT 资源的 S 锁。死锁图描绘了三个资源，1.) 两个来自 SELECT（生产者/消费者并行线程），和 2.) INSERT。
我已附上死锁图供您查看。因为这是 Microsoft 代码和表结构，我们无法进行任何更改。
但是，我在 MSFT SP 站点上读到，他们建议将 MAXDOP 实例级别配置选项设置为 1。由于此实例在许多其他数据库/应用程序之间共享，因此无法禁用此设置。

因此，我决定尝试阻止这些 SELECT 语句并行运行。我知道这不是解决方案，而是帮助进行故障排除的临时修改。因此，我将“并行的成本阈值”从我们的标准 25 增加到 40，即使工作负载没有改变（SELECT/INSERT 频繁发生），死锁也消失了。我的问题是为什么？

SPID 356 INSERT 在属于非聚集索引的页上有 IX 锁
SPID 690 SELECT 执行 ID 0 在属于同一非聚集索引的页上有 S 锁

现在

SPID 356 想要 SPID 690 资源上的 IX 锁，但无法保留它，因为 SPID 356 被 SPID 690 执行 ID 0 S 锁
SPID 690 执行 ID …

我在为此创建的博客文章中解释了我遇到的问题（易于参考和管理 1 个位置的响应/解决方案），可在此处找到：http : //schoennie.blogspot.com/ 2013/09/slow-statman-query-issue-with-sp2010.html

简短的总结是，在 SQL 2008R2（同一服务器）之上安装 SharePoint 2010 的单个服务器在特定时间间隔内（似乎是每天早上）在每次第一次上传时都遇到非常缓慢的响应。分析 SQL 活动后，我发现当您开始上传时，此查询会在上传的“插入部分”之前执行：

SELECT StatMan([SC0], [LC0])
FROM   (SELECT TOP 100 PERCENT CONVERT(VARBINARY, 
                                        SUBSTRING ([Content], 1, 100) + 
                                        +SUBSTRING([Content], CASE
                                                                WHEN LEN([Content]) <= 200 THEN 101
                                                                ELSE LEN([Content]) - 99
                                                            END, 100)) AS [SC0],
                                        DATALENGTH([Content])   AS [LC0]
        FROM   [dbo].[AllDocStreams] WITH (READUNCOMMITTED)
        ORDER  BY [SC0]) AS _MS_UPDSTATS_TBL 

我现在花了几天时间试图获得有关此 StatMan 查询的更多信息，以及为什么它会导致磁盘 i/o 通过屋顶和磁盘队列长度增长到 5 值以上（通常约为 0.01）

请分享您对此的想法，或者为我指明某个方向/资源？我在这个软件领域作为 SharePoint 顾问和 DBA 参与了大约 8 年，但我还没有见过这样的事情！

非常感谢，杰罗恩

我有一个 SQL Server 2012 (SP1) #cu5 (X64) 实例用作 SharePoint 2010 后端，大多数情况下仅使用 10 - 30% 的 CPU，但在运行 FAST 搜索爬网（增量和完整）时 CPU 使用率很高）。

按照 Microsoft 对 SharePoint SQL 实例的建议，自动创建和自动更新统计已关闭，SharePoint 应该使用健康分析器规则和计时器作业来处理统计和索引维护。在大多数情况下，它做得不错，但在调查创建高 CPU 使用率的查询时，我发现缺少统计信息，但我无法创建它们，因为修改 SharePoint 数据库会使它们不受支持。

如果您遇到过类似的情况，请告诉我，任何有用的建议都会被采纳。如果您认为https://sharepoint.stackexchange.com/是发布此内容而不是 DBA SE 的最佳位置，也请告诉我。

SQL Server 环境： HP ProLiant DL385p Gen8、Microsoft Windows Server 2008 R2 Enterprise SP1、AMD Opteron(tm) 处理器 6204（单插槽、2 核、支持 HT）Microsoft SQL Server 2012 (SP1) #cu5 (X64)

SharePoint 环境（我现在没有太多详细信息）：SP 2010 SP2（2 个应用服务器、2 个 Web 服务器、1 个 FAST 搜索服务器）

我使用 SharePoint 2013 和 SQL Server 2012 作为持久层。我需要加密存储在数据库中的数据。我偶然发现了 SQL Server 功能透明数据加密 (TDE)。

使用 TDE 时，文档库中的文件（Office 文档）会发生什么情况？文件也被加密还是只加密表？

我对使用 Waits 和 Queues 进行性能调整还很陌生 - 很吸引人，但也不总是那么直观......

现在，我的一个客户有一个 SQL Server 2008 64 位企业版，目前分配给它 16 GB 的 RAM，在具有 64 GB RAM 的物理服务器上运行（在同一台上还有其他和更改的 SQL Server 实例）机）。

他正在运行的这个应用程序是一个 Sharepoint 2010 解决方案，在大多数情况下，它的性能 - 很好 - 对于 Sharepoint 站点来说还可以。除了搜索，这是非常缓慢的。

现在从 SQL Server 的角度来看，我已经观察了几天的等待统计数据，前三种等待类型是：

1) CXPACKET 约为 49%
2) SOS_SCHEDULER_YIELD 约为 10.5%
3) OLEDB 约为 9.5%

这似乎非常一致——随着时间的推移没有大的变化。

• PAGEIOLATCH_SH 排在第七位 - 占总等待时间的 2.5%，平均资源等待时间为 14 毫秒。
• ASYNC_IO_COMPLETION 有八个——不到总等待时间的 2%，但平均资源等待时间高达 38 秒（是的，秒——不是毫秒！）

信号等待时间极短，所以这似乎并不表示 CPU 压力。那么是什么导致了这种模式——我们可以做些什么来 (a) 找到更多相关信息，或 (b) 找到加快速度的解决方案？

有什么想法吗？见解？想法？我对任何事情都持开放态度——我们不能改变的是基本架构（单独的 SQL Server 实例，在物理服务器之间移动——以及基于 Unix 的 SAN，它不能保证数据和登录到单独的物理磁盘上的分离）

再说一遍：这是一个SharePoint网站 …

我是 Sharepoint 的新手，但我曾经经常使用 SQL Server。我意识到 Sharepoint 将一些 SQL Server 设置更改为非默认值。一个是最大并行度，为什么sharepoint不像并行计划执行那样？另外我为什么要关闭“自动更新统计信息？我找不到这两个问题的答案。我在 Sharepoint 2013 上

SharePoint 使用单个表（即dbo.AllUserData），其中包含类似nvarchar1, nvarchar2, ..., nvarchar64或 的int1, int2, ..., int16列（总共 193 列）来存储所有网站集中所有列表中的所有项目。

• 创建新索引、重新计算统计信息等有帮助吗？
  _{让我们暂时忘记它很可能会失去 Microsoft 对像这样修改的 SharePoint 安装的支持。}

• 我是否认为这样的设计使所有经典的数据库调优技术都无用？

• 除了添加更多/更快的硬件之外，有没有人尝试过以任何其他方式解决 SharePoint 的性能问题？

我有一个 8 核（576 个最大工作线程）的 SQL Server 2008 R2 SP3 标准版 64 位实例，32 GB RAM（MaxMem = 28000）。它是 SharePoint 安装的数据存储，具有 218 个数据库。

它收到了数十条“SQL Server 失败，错误代码为 0xc0000000，无法生成线程来处理新的登录或连接。” 每天错误，但没有其他错误。我发现 MAXDOP = 0，这对 SharePoint 不利。我逐渐（数周后）将 MAXDOP 降低到 1。当我这样做时，这些错误的频率在大多数日子里都降到了零。但我还是会偶尔看到他们。

sys.dm_os_wait_stats 关于 THREADPOOL 等待是这样说的：

waiting_tasks_count wait_time_ms    max_wait_time_ms    signal_wait_time_ms
26149               474516          4428                9

服务器上次重启时间为 2018 年 3 月 25 日下午 5:55，当前服务器时间为 2018 年 4 月 20 日晚上 10:07。除了在保存 tempdb 文件的驱动器上使用连接和顺序提示以及慢速存储写入之外，sp_Blitz 没有发现任何有趣的东西。

这是在私有云中的虚拟机上。增加 CPU 的数量会非常昂贵，虽然它被大量使用，但 CPU 使用率似乎不是问题。在这种情况下，增加最大工作线程数是否是一个合理的尝试，我应该不理会它并忍受偶尔的 17189 错误，还是有其他选择？

我使用 SQL Server 2008R2 标准版实例（最近迁移到 Azure VM）的数百个数据库的 SharePoint 数据存储定期遇到 THREADPOOL 等待问题。它一次在许多（可能是所有）这些数据库中运行一个名为 proc_DefragmentIndices 的存储过程。

存储过程无条件地重建数据库中的每个索引。当然，它们是头部阻塞器（因为它是标准版，每个 ALTER INDEX 命令都以 ONLINE=OFF 运行）。因为一次运行的程序太多（每个都在不同的数据库中），并且它们并行运行（这会占用更多的工作人员），所以一切都堆积如山。只是为了增加噪音，Azure Backup 正在备份许多数据库，而这一切都在进行，消耗了更多的工作人员。活动监视器显示 106 个等待任务，以及许多 ALTER INDEX 命令的同一会话 ID 的多个实例（这就是我说它们并行的原因）。

我觉得令人困惑的是，即使实例中的 MAXDOP 设置为 1，这些 ALTER INDEX 语句也会并行运行，这是对 SharePoint 数据库的建议，并且由存储过程执行的 ALTER INDEX 语句没有使用 MAXDOP 选项来覆盖它.

Q1：当 MAXDOP 设置为 1 时，INDEX 重建如何并行？

Q2：活动监视器显示 ALTER INDEX 命令，但 sp_WhoIsActive 没有。有谁知道为什么？

我意识到这可能是一个简单的问题，但如果我包含 SQL Server，我的搜索只会返回驱动器号或数据库名称的结果。请随时向我指出现有的文章或答案，并提前道歉:)

我继承了一个环境，其中包含多个支持多个 SharePoint 2013 和 2016 场的 SQL Server 2014 和 2016 服务器（也有一些是集群服务器）。以前的 SA 为驱动器命名/标记了一些相当模糊的名称，我想通过重命名驱动器来避免自己继续混淆每个包含的内容。这是一个坏主意吗？我似乎无法在我的环境中找到任何专门提到驱动器名称的东西，一切似乎都选择了驱动器号，在某些情况下，驱动器名称被呈现为信息。

驱动器名称只是一个描述，实际上并没有将驱动器本身识别为任何系统，我对吗？