【问题标题】:SQL Server Transactional Replication, and different primary keysSQL Server 事务复制和不同的主键
【发布时间】:2008-12-04 01:11:34
【问题描述】:

使用 SQL Server 2005 和事务复制,我可以删除订阅者的主键约束,同时保留发布者的主键约束吗?

主要我想这样做是因为我想聚集在与现有聚集约束不同的列上。我不认为我可以在不先删除它的情况下将约束从集群转换为非集群,并且复制已经发生了。

【问题讨论】:

    标签: sql-server replication constraints


    【解决方案1】:

    您为什么不保留主键并在订阅者上创建额外的非聚集索引,否则这不能解决您的问题吗?如果在订阅者上索引其他列的原因是性能,那么这应该是一个解决方案。

    【讨论】:

      【解决方案2】:

      这可能适用于快照复制,但我不确定它是否适用于事务复制。允许复制表的唯一要求是存在一个主键以允许唯一标识每一行。

      您可以尝试暂停复制,然后尝试删除主键约束,将其重新创建为非集群 PK,然后取消暂停复制。如果 SQL Server 不允许你放弃 PK,你会在造成任何损害之前发现。

      另一种方法是中断复制并重新初始化它。

      无论哪种方式,您都需要在维护时段内进行更改。

      【讨论】:

        【解决方案3】:

        直接,对于主键是不可能的。反之亦然:当您设置事务复制时,当您选择要复制的文章时,您可以选择不同的属性,例如“检查外键约束”。将该属性设置为 false。在 db1 中,将主键转换为外键,其中包含一些新表 tb1 作为主键。因此,最终,在您的复制数据库 db2 上,外键约束不会被复制,从而允许您做您想做的事情。

        【讨论】:

          【解决方案4】:

          复制过程的基础是在不同服务器之间保持相同的数据库组织。

          您在这里的问题可以被认为是询问是否可以使用复制过程来打破这一基本复制原则。

          所以答案是否定的,但我仍然对让你提出这个问题的原因感兴趣。我应该说这个“双主键”选项被视为解决另一个问题的一种方式吗?我认为您应该回到最初的问题并尝试找到另一种解决方法。

          【讨论】:

            【解决方案5】:

            我自己做了功课,得出的结论是您可以放弃对订阅者的限制。

            我设置了一个简单的事务复制场景,删除了订阅者的主键,然后进行了一些插入、删除和更新,并验证了更改已复制到订阅者。

            我想我一开始就应该这样做。我不知道会这么容易:)。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2021-04-08
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              相关资源
              最近更新 更多