SQL Server CE @threshold和身份范围真正发生了什么？

Question

亲爱的，因为这个问题与IDENTITY列和合并复制有关，所以请允许我不要回答“使用GUID”。 我敏锐地意识到两者的优点和局限性，并且自SQL Server 2000开始就在CE中使用SQL复制。偶尔我会感到惊讶。 就是这种情况。

这是对该问题的复杂描述，请耐心等待。

以下是从此处摘录的内容：https://msdn.microsoft.com/zh-cn/library/ms152543.aspx ，这是我一直以来对身份范围和阈值的了解。

“运行SQL Server Compact或早期版本的SQL Server的订户仅被分配了主要范围；新范围的分配由@threshold参数控制。此外，重新发布的订户仅具有@identity_range参数中指定的范围；它必须使用此范围适用于本地更改以及与重新发布的订阅服务器同步的订阅服务器上的更改。例如，您可以为@pub_identity_range指定10000，为@identity_range指定500000，为@threshold指定80％。在8000上在订阅服务器上插入（10000中的80％ ），则为发布者分配了一个新范围。当分配了新范围时，表中的标识范围值将存在一个间隙。指定较高的阈值将导致较小的间隙，但系统的容错性较小：如果如果合并代理由于某种原因而无法运行，则订阅者可能更容易用完身份。”

如果假设这是真的，那么我们现在开始解决我的问题。

为了帮助用户使用我们的应用程序，我们一直在使用以下查询的变体，以使客户知道如果他们继续走下去，他们可能会失去身份，并启动同步以获取新的范围。

SELECT 
    AUTOINC_MAX, AUTOINC_NEXT, AUTOINC_MAX-AUTOINC_NEXT 
FROM 
    INFORMATION_SCHEMA.COLUMNS 
WHERE 
    TABLE_NAME = N'Asset'

AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3081898     |   3080899    |        999

通过评估AUTOINC_MAX - AUTOINC_NEXT （= 999），我们可以看到何时ID降低

在代码中，我们查看的是AUTOINC_MAX - AUTOINC_MIN ，它给出了分配的范围。 使用默认阈值80％和剩余范围，我们可以建议客户端在看起来用完时进行同步。

但是，这是我认为正确的地方，在实践中失败了。 引用上面的Microsoft详细信息，这句话特别突出： “当分配了新范围时，表中的标识范围值将出现间隙。”

我认为这意味着

如果我们的用户的标识范围是0-1000个ID，并且使用的ID最多为801。在下一次同步时，将为该用户分配下一个范围1001-2000（我们假设有一个订户进行说明）。 同步的结果是，下一个使用的ID为1001，与802-1000之间有一个间隔。

首先，请让我知道我的理解是否错误。

其次，这不是我们在实践中看到的。

实际上，根据上面的示例，我们看到的是同步后和随后的插入，这是直到我们完全用尽原始范围之前所使用的ID的平衡。 然后，在扩展范围AUTOINC-MIN，-MAX和-NEXT时，都将更新为新范围。 没有发生其他同步。

下面是一个例子。

在目标表中，最后使用的ID是3080899

为了模拟用法，使用了以下查询

INSERT INTO Asset (lInstID, lTypeID, sUsrName, lUsrID, dCreated, dAudit,  sStatus)
    SELECT 
        lInstID, lTypeID, sUsrName, lusrID, dCreated, dAudit, sStatus
    FROM 
        Asset 
    WHERE 
        lAssetID = 3080899

插入后，下一个使用的ID值是3080900（如预期，例如AUTOINC_NEXT = 3080899，+ 1 = 3080900）

我们重复此插入操作，直到达到分配的标识范围的80％。

SELECT 
    AUTOINC_MAX, AUTOINC_NEXT, AUTOINC_MAX-AUTOINC_NEXT 
FROM
    INFORMATION_SCHEMA.COLUMNS 
WHERE 
    TABLE_NAME = N'Asset'

AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3081898     |   3081699    |           199

我们同步。 我们注意到800个订户更改。 我们查询，这就是我们所看到的。 与预同步没有变化。

AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3081898     |    3081699   |         199

我们继续插入，直到剩余零个ID

AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3081898     |   3081898    |            0

再插入一次，结果是这样

AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3082898     |    3081899   |           999

这是完全出乎意料的，与分配新范围时相反， 表中的标识范围值之间将存在间隙。 实际上，身份范围是连续的。 由于我们不会浪费ID，因此这在某种程度上是可取的。

我在.SDF中找不到下一个分配的范围存储的位置。

我假定这是next_range_start和next_range_end从sysmergearticles服务器表，但没有文件可以发现，暴露在这些值.SDF 。

如果有人知道这里发生了什么，我将不胜感激。

需要注意的一点是，如果您完全消耗了“下一个范围”而不进行同步，则数据库将按预期返回错误。

同步发布错误显示订户上载了1200条新记录（前一个范围为200个，“下一个范围”为1000个）

AUTOINC_MAX | AUTOINC_NEXT | AUTOINC_MAX-AUTOINC_NEXT
------------+--------------+-------------------------
3083898     |    3082898   |          999

亲切的问候

安德鲁

Answer 1

对于那些有兴趣的人，我从Microsoft的管理员那里收到了此答案。

嗨安德鲁，

根据测试，我认为这应该是文档错误。 CE同步应使用运行SQL Server 2005或更高版本的相同方法订户。 那是，

订户将收到两个身份范围。 次要范围的大小等于主要范围； 当主要范围用尽时，将使用次要范围，并且合并代理将新范围分配给订阅服务器。 新范围成为辅助范围，随着订阅服务器使用身份值，该过程继续进行。

因此，假设您将订阅者身份范围设置为10。然后，发布者从1到11的主要范围开始，从11到21的次要范围开始。 对于主要范围，订户从21到31开始，对于次要范围，订户从31到41开始。 如果在消耗完所有订户范围之前没有同步，则将出现错误，这意味着您可以在错误消息之前插入设置为订户数据库的订户范围的双数记录。

对于发布者端，如果您消耗了所有范围，但没有一次使用，则插入触发器将帮助您重新分配新范围。 例如，在同步之前，如果发布者端达到21，并且下一个插入将从42开始，因为22到41属于订阅者。

对于多个订户，该机制是相同的，如果您仍在订户的主要范围内，则不会分配新范围。 如果您已经在辅助范围内，则将分配新范围，并使您的辅助范围变为新的主要范围，并使新范围变为新的辅助范围。

您可以跳过重新发布者的情况，因为CE订阅者不能充当发​​布者。

最好的祝福，

彼得https://social.msdn.microsoft.com/profile/sql%20team%20-%20msft/?ws=usercard-mini

这恰好证实了我们在测试中所看到的。 因此需要明确的是，SQL CE 3.1+的确在第一次同步时收到了主要和次要范围。 扩展第一个范围后，辅助范围将成为主要范围，下一次同步将应用新的辅助范围。

只需要查询来确定SQL CE中的辅助范围是什么...