我想将生产数据库中的信息添加到阶段数据库中。我有一个生产数据库的 BAK，可以直接从阶段数据库中恢复，但我担心合并复制会对此产生影响。
让我进一步解释一下；我有 15 个用户在内部测试一个有时连接的应用程序。结构是每个系统上都有一个 Local SQL Express，使用 Pull 订阅订阅 Stage SQL 2005 服务器。Stage 服务器充当发布者和分发者。测试人员已请求使用“真实”数据。如果我仅将 BAK 从生产还原到我的 Stage 实例，我的复制集会发生什么？当本地数据库尝试同步时，它们会因为所有 GUIDS 都已更改而“崩溃”吗？
我的想法是将生产数据库以不同的名称恢复到阶段服务器，然后删除 tblPerson 的内容，并从生产 tblPerson 运行 INSERT INTO 到现在为空的阶段 tblPerson。
我希望听到你们对这两者的想法和建议。
恢复 BAK 会导致世界末日吗
和/或
我的第二个解决方案是一个可行的选择吗？
我真需要做那么多吗？我可以删除 tblPerson(Stage) 的内容，然后从 tblPerson(Production) 到 Stage 对应部分执行 Cross DB SELECT INTO 吗？
我主要好奇/担心这会对我现有的订阅产生什么影响。
答案1
您不想使用从生产到阶段环境的复制，尤其是合并复制。
最好的办法是，每当您需要临时数据库中的数据时，备份生产数据库并恢复整个数据库。如果您尝试逐个恢复，您将不得不处理随之而来的所有引用完整性问题。
答案2
恢复数据库将破坏您的复制（至少在我的场景中是如此。如果有人知道不同的请告诉我！
我们基本上按照您的建议做了 - DELETE * FROM myTable 和 INSERT INTO。这花了一段时间，但删除表或删除/恢复数据库会破坏我们场景中的复制。
我不知道这是否重要，但我们在执行此操作时也暂停了所有订阅者的复制。
答案3
INSERT INTO 或 BCP 可能都可以。正如您所提到的，恢复生产数据库需要您在暂存实例中重新创建复制。SELECT INTO 不是一个好主意，因为您不能使用现有表作为 INTO 子句的目标 - 它必须是一个新表 - 因此您必须删除目标表，这又需要修复您的复制。
在另外两种方法中，INSERT 绝对是最简单的，我经常使用该方法。如果需要速度，请尝试 BCP。批量插入通常比标准 INSERT 操作快得多。根据 BOL (http://msdn.microsoft.com/en-us/library/ms151206.aspx），您必须使用开关来强制触发触发器，但听起来否则它应该可以正常工作。