我有一个发布者数据库A，并且有两个订阅者A的订户数据库B和C。我的应用程序本地驻留在站点B和C上，并且通过复制，B和/或C处的更改可以彼此复制。 / p>
问题是自2019年1月31日起C停止订阅A，站点C的IT人员对此一无所知（没有警报）。
更大的问题是，在此期间，使用B处的应用程序的人一直在输入要复制回A的数据。同时，站点C的人一直在将数据添加到数据库C中，而该数据没有被复制回
如果我恢复订阅，它将在A处获取数据并覆盖C，这是一个主要问题，因为在此期间我将丢失在C处添加的数据。由于这是运行状况数据，因此所有数据都已加密并存储在xml中格式，它不只是更新丢失的数据那样简单，因为某些文件在站点B和C之间共享，这意味着它们会将数据添加到保存的xml树中。
例如，如果某人在站点B看到患者并输入便笺，它将更新一个文件。但是，如果下周下同一个病人去站点C，那里的护士将更新在站点B上更新过的文件。
我不知道如何在恢复新订阅之前先同步回C处所做的更新。
如果有人有任何建议，将不胜感激，谢谢！
答案 0 :(得分：2)
多年来，我们一直在使用合并复制，有时（例如，在更新数据库之后）合并合并会出现奇怪的错误，无论我们如何尝试都无法修复。在所有这些情况下，唯一有效的解决方案是重新初始化订阅，甚至删除并重新创建带有所有订阅的发布。
但是由于这是合并复制的情况，并且在未发生同步时在所有末端（即发布者和所有订阅者）都添加了新数据，所以我们不能简单地重新初始化订阅，因为就像您指出的那样，在失败的订户方将丢失。您的案例更加困难，因为您正在使用加密和XML文件来存储数据。您是否将加密的XML作为BLOB / CLOB存储在数据库中？
但是，我将提供对我们有效的解决方案。因此，如果一个或多个合并复制端点失败，则必须采取以下步骤：
使用Red Gate SQL Data Compare（可免费试用14天）或Microsoft的免费SQL Server Data Tools（SSDT）之类的工具，将非同步数据手动添加到所有端点。 Red Gate的工具非常强大。您可以定义数据库之间的表/列的自定义映射以进行比较。虽然此时来自MS的SSDT只能比较具有相同名称和相同架构名称的表。两种工具都可以生成插入/更新/删除脚本，以使数据同步。他们甚至自动禁用然后恢复外键约束检查。
更改发布并将Action if name is in use属性设置为所有文章保持现有对象不变。
重新初始化订阅。
执行步骤2并重新初始化订阅后，复制代理仍然需要一些时间来处理现有记录（并且根据数据集的大小，可能要花费一些时间，因此请考虑将Date过滤器添加到文章中），但不会更改任何数据，如果在步骤＃1之后发布者数据库和订阅者数据库都完全同步，则不会发生删除或插入。该代理将仅将这些现有记录标记为已处理，以在将来运行时跳过它们，因此您将仅在Replication Monitor上看到Update命令计数增加。重新初始化订阅后，您应该会很好，并且在任何一侧生成的新数据都将同步。
您的情况很难，因为您无法轻松地从步骤1开始执行手动数据同步。但这是前提条件，您将需要思考如何做到这一点。您没有提供有关如何实际存储加密数据的详细信息，因此我无法建议详细的计划，但是您需要以某种方式手动解密现有的XML记录，插入丢失的部分，然后再次加密，并确保加密的列完全相等侧面。
希望这可以帮助您解决问题。
PS。无论如何，我都不隶属于Red Gate或Microsoft。