SharePoint 往事之：一句话让 SharePoint 罢工

翻旧账的目



这是一篇 2016 年初的文章，当时 SharePoint 2013 还如日中天，SharePoint 2016 即将发布。在 2013 版本中，SharePoint 产品团队也没有意料到这个世界上会有应用把SiteQuota塞爆，以至于我和产品团队沟通的初期他们一直问我怎么做到的，这个值不可能被塞爆。直到几天后一个产品团队成员翻了SharePoint 2016 即将发布的功能列表，才确定在 SharePoint 2016 中增加了一个每周的 Job 来定时清理SiteQuota，并承诺 2013 版本上会出 hotfix。



塞爆SiteQuota并非偶然，是对 SharePoint 2013 平台长期高效使用的结果，从一个侧面也反应 SharePoint 平台的投资性价比。现在 Office 365 采用周期固定费率的模式，也同样存在单位时间内使用率问题。高效不是一句口号，需要依托 Office 365 平台的基础服务用技术将业务合理构建。



所以，翻出这篇旧账是希望能让大家关注 Office 365 的使用率，一个开放的云平台，更多的业务系统运行其上才是对它的尊重（对投资的尊重），Office 365 能做到。



制造问题

首先将问题呈现在大家面前。

注意：请在开发环境或者测试环境中进行下面的实验。



• 打开 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 2013的内容数据库最多允许大约十亿次左右的数据操作。 这个问题在 SharePoint 2013 以及还未发布的 SharePoint 2016上均存在。



以 SharePoint 2013为例：



• 单个内容数据库建议的列表项上限为六千万条。如果在满载的情况下，平均一条列表项数据允许进行20次左右的操作。

• 从时间序列上来看，如果每秒进行30次左右的数据操作，一年时间也能达到这个上限。



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



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



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



*只有一个高效使用的 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 在高效使用吗？



更多Office 365 开发和应用相关资讯，请关注公众号：

Office 365 漫谈