我们正在使用复制,似乎有无穷无尽的问题。它似乎因未知原因而关闭。需要关闭它以删除列,并且只在一半的时间内重新启动。有没有人对如何正确使用复制或其他替代方案有任何建议。
编辑:
我们正在使用Sql Server 2005,我们不能使用数据库镜像,因为我们使用其他数据库进行报告。据我所知,您无法从镜像数据库进行查询。
答案 0 :(得分:3)
如果您只需要数据库中的几个表用于报告,则复制更有用,但您也可以在待机模式下设置辅助服务器的日志传送(特别是如果您需要大部分数据用于报告),然后您可以在辅助服务器上运行报告。您只需记住日志传送会干扰事务日志备份,因此您必须将同一文件夹与日志备份文件一起用于这两个进程。
答案 1 :(得分:2)
我认为数据库镜像和数据库快照的组合将解决您的问题。
首先,数据库镜像很容易设置,我从来没有遇到过任何问题(在过去的4年里使用它)。
其次,在故障转移服务器上创建数据库快照将允许您运行报告。您可以设置sql代理作业,以便在您喜欢的任何可接受的时间间隔内删除并重新创建快照。
当然,这完全取决于您是否需要在实时数据上运行报告,或者是否可能会延迟报告。
答案 2 :(得分:1)
以下是我必须解决以使复制正常工作的问题列表:
1)复制有时对我来说并告诉我这个,即使它工作正常。 “服务器'Bob'不是订阅者。(。Net SqlClient数据提供者)”我试图重新初始化它,认为它被破坏了,它从来没有......
2)重启自己可能需要一段时间,特别是如果您的远程数据库位于地球的另一侧,就在我的情况下。如果您使用慢速网络连接,或者它不是100%可靠,那么您可能会遇到问题。此外,重启过程的作业有时可能需要一段时间才能运行,这也会使事情进一步延迟。
3)有些变化需要完全重新注册,这需要发送新的快照。如果你没有正确的权限,并且你可以手动重新初始化,但它不会自动发生,那么这可能是问题的另一个原因。
答案 3 :(得分:1)
我们有一个SQL事务复制,它可以非常愉快地运行。您似乎在说,当您对发布者进行架构更改时,您会遇到问题。每次我们进行模式更改时,我们都会删除发布,订阅和订阅数据库。做改变,然后重新构建它。我们可以这样做,因为我们可以容忍重新应用快照所花费的时间。有一些方法可以将模式更改应用于发布,并使它们传播给订阅者。看一下sp_register_custom_scripting。我们已经完成了这项工作,如果您需要,我可以提供更多相关信息 正如@Jason所说,您可以使用快照从镜像数据库进行报告。请注意,快照将占用空间,并为镜像服务器带来更多工作。虽然有多少空间取决于数据的变化量和原始数据库的大小。我们确实在镜像数据库上使用快照来处理临时报告,因为我们没有复制整个数据库。
答案 4 :(得分:1)
答案 5 :(得分:0)
您使用的是哪个版本的SQL Server?
我们现在正在为特定解决方案使用复制,而且它似乎每天都在工作。
我会检查你的事件日志,然后SQL Server会记录你是否可以确定它关闭的原因,以及它为什么不启动。 您是否可能修补服务器,或者您是否遇到网络错误?
复制的替代方法是日志传送或数据库镜像。 我个人更喜欢数据库镜像,但它确实取决于你想要做什么,因为其中一些不适合某些情况。
答案 6 :(得分:0)
我们也使用过SQL事务复制。我们在更新架构时遇到了同样的麻烦,这需要在所有服务器上删除发布,执行更新,然后重新初始化复制,并希望获得最佳。有时它不会初始化,或者一个节点会落后,我们几乎没有得到它的警告。有几次我们甚至丢失了所有存储过程的执行权限,导致网站完全失败。
我们有一个相当大的数据库,所以重新初始化可能需要相当长的时间,这意味着所有更新都必须在周日凌晨2点完成 - 不完全是我们清醒和警觉并能够使用我们所有的院系来处理问题可能会出现。
我们正在放弃复制,转而支持SQL 2008上的故障转移群集,但它仍然可以一直回到SQL 2000。