为什么合并复制在设置表的 LOCK_ESCALATION 时会失败？答案

【问题标题】：Why does merge replication fail on setting a table's LOCK_ESCALATION?为什么合并复制在设置表的 LOCK_ESCALATION 时会失败？
【发布时间】：2010-10-23 05:46:03
【问题描述】：

我们遇到了合并复制问题。我们的发布者运行 SQL Server 2008，而我们的两个订阅者运行 2005。我们的发布者正在尝试向我们的订阅者发送ALTER TABLE Foo SET (LOCK_ESCALATION) 命令。我想我记得读过这个命令是 SQL Server 2008 中的新命令，如果是这样，那么该命令在我们的 2005 服务器上会失败是有道理的。但是，我们的合并复制设置为与 2005 兼容。

架构脚本 'if object_id(N'[dbo].[Users]') 不为空 exec('ALTER TABLE [dbo].[Users] SET (LOCK_ESCALATION = TABLE) ')' 无法传播给订阅者。

对我们的出版商为什么会尝试这样做有什么想法吗？

编辑：我们 2008 服务器的兼容级别设置为“Sql Server 2005 (90)”

【问题讨论】：

已确认 SQL Server 2008 中的错误。可能要到 SQL Server 2011 才能修复。(connect.microsoft.com/SQLServer/feedback/details/536571)

标签： sql-server sql-server-2008 replication

【解决方案1】：

它是 sql 2008 中的一项新功能，因此在 2005 年不支持。根据您的设置的复杂程度，您可能需要考虑让您的数据库在兼容性 90 (sql 2005) 下运行，以确保您不会将 sql 2008 功能添加到您的数据库。自从模式数据出现以来，它就一直在复制模式数据方面遇到大问题，所以总是有点沉默寡言。我总是试图让它变得愚蠢并只管理数据 - 必须支持具有 32 个订阅者的合并系统和合并复制，并且当我们推送架构更改时会不断遇到大架构问题。

也就是说，如果它按记录工作，它不应该试图推动你的锁更改。检查订阅是否标记为 sql 2005 兼容。他们可能没有像他们为数据类型（例如）所做的那样创建 2008 年到 2005 年的设置的自动映射

不久前，一位 SQL 开发人员 blogged 介绍了新的锁定类型

【讨论】：

感谢您确认我的怀疑并提醒我该兼容性选项。不幸的是，我们的兼容级别设置为 90。
更新评论；它可能是 2008 年复制中的错误。它没有记录在 msdn 文章 msdn.microsoft.com/en-us/library/ms143241.aspx

【解决方案2】：

发生这种情况是因为该指令与 sql server 2005 不兼容，并且显然当我在正在复制的表中进行架构更改时，会将这条指令放入架构更改中。

有两种方式：删除并重新创建订阅，不适用于生产服务器。第二种方法是转到数据库中的 sysmergeschemachange 表并删除具有以下内容的行：

模式脚本'if object_id(N'[dbo].[Users]') 不是 null exec('ALTER TABLE [dbo].[用户] SET (LOCK_ESCALATION = TABLE) ')' 无法传播到订阅者。

我希望这会有所帮助。

【讨论】：

尽管该表中的 DELETE 行有点吓人，但我尝试了它 - 它对我有用。