我们设置了数据库复制，我们将数据库的所有表复制到多个生产服务器。
数据库中还有视图，存储过程，函数等，它们通过TSQL脚本手动部署到Replicates。
现在，如果例如向发布添加了新表，我们必须通过创建新快照重新初始化所有订阅，并让它通过分发服务器（与发布服务器位于同一服务器上）进行交付。当分发代理想要删除表以便之后重新创建它时，头痛开始，一些表被视图引用，这些视图也被另一个对象引用。分发者不能（或不会）删除对象并遇到Cannot DROP TABLE 'dbo.table' because it is being referenced by object 'thisisafunctionorview'.
过去我们在出版物中也有视图，功能和存储过程，但这会导致更多的痛苦（必须在程序的每次微小更改后进行重新初始化等），然后参考问题真正令人沮丧。
要解决此问题，我们必须删除所有功能和视图（总共约200个对象），并在快照发布后重新创建它们。
有人知道我们如何修改此复制的概念，我们可以更改对象，而不必因为引用而设置大量停机时间（6个重复约2小时）来修复混乱？
完成信息： 我们在所有实例（使用Enterprise和Standard Editions）上使用MS SQL Server 2008 R2。升级到SQL Server 2014计划于今年晚些时候针对发布者和一些订阅者进行升级。 只有出版物要求写入权限。 经常部署数据库模式的更新（大约每月两次），通常只有程序中的更改，但有时会添加/修改表，这就是我们的复制概念似乎崩溃的地方。
欢迎任何建议 提前谢谢！
此致 大卫
答案 0 :(得分：0)
这听起来很奇怪，因为我在复制中有很多存储过程，并且SP更改没有问题。 ALTER PROCEDURE can将在订阅上传播。此外，由于对象依赖性，我认为订阅重新初始化没有问题。我可以记住合并复制中的这些问题，并且有SP来重新安排对象。在大多数情况下，SQL Server很好地处理依赖项。第二，请注意，您可以将\ remove文章添加到事务复制without re-initialization。
我认为如果您在测试环境中重新创建复制并稍微使用它，您将找到一种方法来复制架构更改并且不会经常重新初始化。这是可能的，但需要一些努力。