最佳实践:处理链接服务器中的错误

时间:2013-07-02 10:22:49

标签: sql sql-server sql-server-2008 tsql linked-server

我正在使用SQL Server 2008 R2从触发器和存储过程中连接到同一类型的许多其他服务器。这些服务器在地理上分布在世界各地,并且必须记录服务器之间的通信中的任何错误以及应该发送的数据,以便稍后可以重新尝试通信。服务器参与Observer模式,其中一个服务器充当观察者并处理其他服务器之间的消息路由。

我正在寻找有关如何在这种情况下最好地处理错误的具体建议,特别是连接错误以及在远程服务器上执行查询时要注意的任何潜在陷阱。

2 个答案:

答案 0 :(得分:3)

如果您使用链接服务器并通过链接服务器连接将数据发送到其他服务器,则没有固有的方法来记录这些请求,除非您添加应用程序逻辑。

使用链接服务器,如果其中一个服务器出现故障,则应用程序逻辑中会抛出一个错误,即在您的情况下,存储过程或触发器将失败,说服务器不存在或服务器是下来。

为了避免这种情况,我们尝试使用Service Broker来实现Queue Logic,在这种情况下,您始终可以保留日志记录,并确保无论服务器停机时间如何都会传递消息(在如果服务器停机,则消息会一直等到读取完毕。

http://technet.microsoft.com/en-us/library/ms166104%28v=sql.105%29.aspx

希望这有帮助

答案 1 :(得分:0)

链接服务器可能不是您尝试实施的模型的最佳解决方案,因为在链接服务器通信失败的情况下,您很难实现所需的弹性。

根本问题是,在链接服务器通信失败的情况下,数据库引擎会引发严重级为20的错误,该错误足以中止当前正在执行的批处理 - 绕过批处理中的任何错误处理代码(对于例如TRY...CATCH)。

SQL 2005及更高版本包含过程sp_testlinkedserver,它在尝试执行命令之前能够测试链接服务器的可用性 - 但是,这并不能解决在命令期间遇到的通信错误所导致的问题。

您可以考虑使用几个更强大的选项。一个是Service Broker,它提供了一个异步消息排队模型。这不适合观察者模式,但activation功能提供了从中心点实现推送通知的方法。由于您提到了消息传递,Service Broker使用的对话模型可能适合您的目标。

另一个选项是transactional replication;如果数据流纯粹是从中央服务器到观察者,这可能更合适。

相关问题