我有一个托管在 SQL Server 2008R2 Standard 上的生产数据库,该数据库通过订阅生产数据库复制到运行相同版本 SQL Server 的第二台服务器。订阅者数据库用于对数据运行 SQL 报告。删除不会被复制,因此报告数据库与每周清理一次的生产发布数据库相比相当大。
我计划更换托管已发布数据库的服务器,并想知道最好的做法是什么,以确保订阅者数据库不会丢失任何数据。这是要遵循的步骤的合理概述吗:
- 将最新备份的副本从旧生产数据库还原到新服务器
- 使用与旧数据库相同的设置发布此新数据库
- 取消订阅(或任何中断复制的正确术语)旧发布的数据库中的报告订阅数据库
- 订阅报告数据库的新出版物
就这么简单吗?还是我错过了什么,可能会反过来伤害我?我要确保的主要事情是用于报告的数据库(订阅的数据库)不会丢失任何数据,并继续从新数据库接收新的复制数据。
谢谢
答案1
你的计划是正确的,但你需要说明@sync_type的仅支持复制为了附加订阅假设订阅者已经具有已发布表的架构和初始数据,并且不会初始化,从而跳过删除。
如果您使用新订阅向导,则可以通过选择不初始化在初始化订阅页。
答案2
诀窍在于您如何同步。在 sp_addarticle 存储过程中,@pre_creation_cmd 参数的默认值是删除订阅服务器上的表。这对您来说是个问题。以下是我可能执行的操作:
- 尽你所能将已发布的数据库移至新服务器。这可能包括(故意)中断复制。
- 在订阅服务器上,重命名所有表(或将它们放入另一个架构中)。这将保护它们免受在复制重新初始化过程中可能出现的任何灾难。或者,您可以重命名数据库,以便创建一个新数据库作为订阅服务器。
- 重建发布和订阅
- 让发布同步
- 对于设置了此归档条件的每个表,插入在步骤 2 中将表移动到的位置中不存在的数据,这些数据不存在于订阅方的“实时”表中。本质上,在每种情况下,保存的离表和实时表之间都存在左连接
我还建议您借此机会为您的存档数据实现一个更安全的地方。如果复制自行中断(它可以并且确实如此),您在重新初始化方面就会陷入困境。如果我不得不这样做,我会创建一个由复制调用的自定义过程(您可以使用 sp_addarticle 的 @del_cmd 参数指定它),该过程将记录插入存档表,然后从实时表中删除。但有无数种方法可以完成同样的事情。祝你好运。