Question

我们已经在SQL server 2008中找到了XML解析器崩溃之前单个XML节点可以拥有的最大属性数。

我们收到的错误是：

Msg 6303, Level 16, State 1, Line 1
XML parsing: Document parsing required too much memory

这有点误导。将字符串转换为XML数据类型（或表格列）时会发生问题。

SELECT CONVERT(XML, '<DataNode><Data attr1="a" attr2="b" XXXXX /></DataNode>')

其中 XXXXX 实际上是另一个8191属性。

总的来说，我们的数据集包含10,066个属性。当我们将属性数量减少到8,192时，它工作正常。然而，8,193个属性崩溃了。

它似乎没有任何与数据大小有关的任何内容（100MB或60KB无关紧要 - 我们根据属性计数获得相同的失败/成功）

那么，有没有什么可以用SQL服务器来改变这个限制？

我们的C＃应用程序没有此限制，因此C＃中完全有效的XML文档无法存储在SQL Server的XML数据列中。

任何人都可以提供任何帮助将不胜感激。此时无法更改数据结构，因为它需要重新编写具有数百个组件的整个应用程序框架的数据处理功能。

PS：我已经告知管理层，当应用程序将数据存储为单个节点而不是树的属性时，情况会多么荒谬，但这是我必须使用的： - （

编辑：我们在具有2GB RAM的服务器和具有32GB RAM的服务器上对SQL Server 2008 32和64位版本进行了尝试 - 所有版本和环境都存在相同的问题。< / p>

更新

我在SQL Server 2012中尝试了这个，当它有8,193个属性并且字符串的长度也超过给定大小（测试字符串的长度是833K）时失败，但是当相同长度时工作string只有8,192个属性。

但是我有一个更短的字符串（193K），有12,000个属性，它适用于SQL Server 2012和SQL Server 2008）

因此，当投射的字符串超过一定大小时，它似乎是属性数量的组合。这变得更有趣！

感谢您的反馈！

更新2：

在使用较小的字符串（270K）进一步测试后，我仍然达到16,384的属性限制... 16,385属性失败！因此，它肯定会以8K属性的增量发生，具体取决于字符串长度的组合!!

Answer 1

8191属性听起来太多了。如果看起来你试图将实际数据存储在属性中 - 显然SQL Server解析器在这里有一个限制。

当需要验证类型时，验证器会加载它从元数据定义并将其编译为适合的格式快速验证。为了防止任何一种类型使用太多内存，SQL Server将编译类型的大小限制为1兆字节。 SQL Server编译所有类型并在架构时执行此检查导入是为了避免接受超出限制的类型。

我建议更改使用XML的方式并将信息存储在元素中。