一句话让 SharePoint 罢工

杨柳 -

注意，题目不是标题党，绝非吸引眼球，这是一个事实描述。

制造问题

首先将问题呈现在大家面前。
注意：请在开发环境或者测试环境中进行下面的实验。

  • 打开 SharePoint 内容数据库所在的 SQL Server 管理工具。
  • 在你希望做测试的内容数据库中运行下面的SQL语句：
DBCC CHECKIDENT(SiteQuota, Reseed, 2147483647)
  • 用浏览器打开 SharePoint任意的界面，一切都挺好不是？接下来随便找到一个列表，新建一条列表项数据试试。一定不会成功，且有如下的错误：

  • 查看系统日志，会得到下面的异常：

    • 中文：将 IDENTITY 转换为数据类型 int 时出现算术溢出错误。发生算术溢出。
    • 英文：Msg 8115, Arithmetic overflow error converting IDENTITY to data type int. Arithmetic overflow occurred.

  • 进而你会发现，整个 SharePoint 系统除了可以查看数据，增删修数据都不行。类似于将内容数据库设置为只读的状态。

究竟发生了什么？为什么会产生这样的情况？

发现问题

当然，问题产生并不是我们真的去SQL Server 中运行这样一句话，而是在日积月累的使用中沉淀下来的。
首先看看SiteQuota表，这是一个记录网站集使用量的表，具体的工作方式不在这里详细介绍，只说一个关键的点，当我们在 SharePoint 中新增 修改 删除一条列表项数据时，这个表的 Identity 会自增长2。表的 Identity 数据类型是INT，4个字节，也就是说 Identity 的最大值为2^31-1，也就是2147483647，简短点翻译就是二十一亿。当然，针对 SharePoint 不只是列表项操作会触发这个 Identity 的增加（比如新建一个列表会增加14），但我们可以这样简单计算，一个 SharePoint 的内容数据库最多允许大约十亿次左右的数据操作。 这个问题在 SharePoint 2013 以及还未发布的 SharePoint 2016上均存在。

以 SharePoint 2013为例：

  • 单个内容数据库建议的列表项上限为六千万条。如果在满载的情况下，平均一条列表项数据允许进行20次左右的操作。
  • 从时间序列上来看，如果每秒进行31次左右的数据操作，一年时间也能达到这个上限。

当然，对于 SharePoint 系统来讲这算是一个很大的数字，但并非不是一个不可触及的数字高度。而且这个数字并非SharePoint 系统软硬阈值之类的设置，这是 SharePoint 一个深层次的问题。

这个问题已经提交给 SharePoint 产品组，产品组进行了几天的确认，确定有这个问题，但属于超出产品的使用范畴（小声嘀咕一下，一个企业级产品，十亿次以上操作应该可以支持吧？）。所以我正在据理力争，希望他们能解决这个问题或者给出合理的用户提示（一个很困扰的数据库层级的异常，查找问题用了大半天时间）。否则到达这个上限后，整个 SharePoint 网站集只是一个能提供莫名异常的只读站点，不能进行任何操作。

在平常生产环境使用中，我们不会手动去设置 Identity，那究竟怎么样使用，需要多长时间，什么样的业务场景才会遇到这个问题？简短概括一下就是：

只有一个高效使用的 SharePoint 系统才配得上这个问题

高效使用

上面的问题是在水杉工作流平台（基于 SharePoint 列表打造的工作流及表单平台）使用过程中呈现出来的。我相信 SharePoint 产品组在全球范围也是第一次接到这个问题，从这个角度说，水杉工作流平台在高效使用 SharePoint 方面已经走到了世界前列。

我们可以看以下一组水杉工作流平台上的实际生产环境数据：

  • 软件环境：Windows Server 2012， SharePoint 2013， Sql Server 2014。
  • 硬件环境：两台 SharePoint 服务器（前端兼应用程序），一台数据库服务器，配置参考微软官方推荐。
  • 服务设置：单台 SP 前端单个应用程序池设置5个独立进程。IIS 的 TCP 连接数设置为500。每台 SharePoint 服务器上有十个 timerjob 实例在支撑水杉工作流调度。
  • 用户使用环境：PC 端，Android 客户端，iOS 客户端。
  • 用户数： 5,000
  • 流程类型数：120
  • 共有流程节点： 2,000
  • 一个月产生的业务数据 (基于 SPList)
    • 总共流程实例： 25,000
    • 运行中的流程实例：7,000
    • 已分配任务数：187,000
    • 已分配任务处理人次：100,000

用户访问系统，比如下面这样一个中等程度的表单（太长，只截取了一半），通过水杉工作流平台对象模型从大约十个左右的 SPList 中获取数据。在日常使用情况下，用户访问表单首次响应时间控制在1,000毫秒内。


那么在这样一个 SharePoint 系统中，一个月能让SiteQuota表的 Identity 增加多少？1.5亿。也就是说维持这样一个量级的业务系统，一个月需要进行七千万次数据操作。达到这个天花板所需要的时间也就是一年半。

解决问题

天花板总有达到的一天，那么遇到这个问题该怎么解决呢？
目前找到最直白的办法就是重新 reset identity。

DBCC CHECKIDENT(SiteQuota, Reseed, 0)

注意：这不是微软官方推荐的解决办法（目前没有其他解决办法），如果你有遇到，请联系微软提供支持。这个问题我也会继续和 SharePoint 产品组沟通下去，一旦有有效的解决办法，我会更新状态。

你的 SharePoint 在被高效使用吗？