使用 Sql 服务器复制

Question

我们正在使用复制，但似乎遇到了无穷无尽的问题。它似乎因未知原因而关闭。它需要关闭才能删除一列，并且只在一半的时间内重新启动。有没有人对如何正确使用复制或它的一些替代方案有任何建议。

编辑：

我们使用的是 Sql Server 2005，我们无法使用数据库镜像，因为我们使用其他数据库进行报告。据我所知，您无法从镜像数据库中查询。

Answer 1

我们还使用了 SQL 事务复制。我们在更新架构时遇到了同样的痛苦，这需要在所有服务器上删除发布，执行更新，然后重新初始化复制，并希望获得最好的结果。有时它不会初始化，或者一个节点会落后，我们几乎不会收到任何警告。有几次我们甚至丢失了所有存储过程的执行权限，导致网站几乎完全失败。

我们有一个相当大的数据库，因此重新初始化可能需要相当长的时间，这意味着所有更新都必须在周日凌晨 2 点完成 - 不完全是我们清醒和警觉并且能够使用我们所有的能力来处理问题的时候这可能会出现。

我们正在放弃复制以支持 SQL 2008 上的故障转移集群，但它仍然可以一直完成到 SQL 2000。

http://technet.microsoft.com/en-us/library/cc917693.aspx

Answer 2

日志发送http://msdn.microsoft.com/en-us/library/ms187103.aspx

Answer 3

我们有一个运行良好的 SQL 事务复制。您似乎说，当您对发布者进行架构更改时，您会遇到问题。每次我们进行架构更改时，我们都会删除发布、订阅和订阅数据库。进行更改，然后重新构建它。我们可以这样做，因为我们可以容忍重新应用快照所需的时间。有多种方法可以将架构更改应用于发布并将它们传播给订阅者。查看 sp_register_custom_scripting。我们已经完成了这项工作，因此如果您需要，我可以提供更多相关信息。
正如@Jason 所说，您可以使用快照从镜像数据库中报告。注意快照会占用空间，并为镜像服务器增加工作量。尽管有多少空间将取决于有多少数据正在更改以及您的原始数据库有多大。我们确实使用镜像数据库上的快照来生成偶尔的报告，因为我们的整个数据库没有被复制。

Answer 4

我认为数据库镜像和数据库快照的结合将解决您的问题。

首先，数据库镜像很容易设置，我从来没有遇到过任何问题（过去 4 年多使用它）。

其次，在故障转移服务器上创建数据库快照将允许您运行报告。您可以设置一个 sql 代理作业，以在您喜欢的任何可接受的时间间隔内删除和重新创建快照。

当然，这完全取决于您是否需要在实时数据上运行报告，或者它们是否会有所延迟。

Answer 5

以下是我必须解决的问题列表：

1) 复制有时会欺骗我并告诉我这一点，即使它工作正常。 “服务器 'Bob' 不是订阅者。（.Net SqlClient 数据提供者）”我试图重新初始化它，认为它已经坏了，而且从来没有......

2) 重新启动可能需要一点时间，尤其是当您的远程数据库位于地球的另一端时，就我而言。如果您的网络连接速度较慢，或者它不是 100% 可靠的，那么您可能会遇到问题。此外，重新启动进程的作业有时可能需要一段时间才能运行，这也会进一步延迟。

3) 某些更改需要完全重新初始化，这涉及发送新快照。如果您没有完全正确的权限，并且您可以手动重新初始化，但它不会自动发生，那么这可能是导致问题的另一个原因。

Answer 6

如果您只需要数据库中的几个表用于报告，复制会更有用，但您也可以在 STAND BY 模式下使用辅助服务器设置日志传送（特别是如果您需要大量数据用于报告），然后您可以在辅助服务器上运行报告。您只需要记住日志传送会干扰事务日志备份，因此您必须为两个进程使用包含日志备份文件的同一文件夹。

Answer 7

您使用的是什么版本的 SQL Server？

我们现在将复制用于特定的解决方案，而且它似乎日复一日地工作。

我会检查您的事件日志和 SQL Server 日志，看看您是否可以确定它关闭的原因以及它不启动的原因。 您是否可能正在修补服务器，或者您是否遇到网络错误？

复制的替代方法是日志传送或数据库镜像。 我个人更喜欢数据库镜像，但这真的取决于你想要做什么，因为其中一些不适合某些情况。