我正在使用 SQL Server 2008 R2 从触发器和存储过程中连接到许多其他相同类型的服务器。这些服务器在地理上分布在世界各地,至关重要的是,服务器之间的任何通信错误都会与应该发送的数据一起记录下来,以便以后可以重新尝试通信。服务器参与观察者模式,其中一个服务器充当观察者并处理其他服务器之间的消息路由。
我正在寻找有关在这种情况下如何最好地处理错误的具体建议,特别是连接错误以及在远程服务器上执行查询时要注意的任何潜在陷阱。
我正在使用 SQL Server 2008 R2 从触发器和存储过程中连接到许多其他相同类型的服务器。这些服务器在地理上分布在世界各地,至关重要的是,服务器之间的任何通信错误都会与应该发送的数据一起记录下来,以便以后可以重新尝试通信。服务器参与观察者模式,其中一个服务器充当观察者并处理其他服务器之间的消息路由。
我正在寻找有关在这种情况下如何最好地处理错误的具体建议,特别是连接错误以及在远程服务器上执行查询时要注意的任何潜在陷阱。
如果您使用链接服务器并通过链接服务器连接将数据发送到其他服务器,则没有固有的方法来记录这些请求,除非您添加应用程序逻辑来执行此操作。
对于链接服务器,如果其中一个服务器出现故障,则应用程序逻辑中将引发错误,即在您的情况下,存储过程或触发器将失败,表示服务器不存在或服务器已关闭。
为了避免这种情况,我们尝试使用服务代理,它实现了队列逻辑,在这种情况下,您可以始终保持日志记录,并确保无论服务器停机时间如何都能传递消息(如果服务器停机时间,消息一直等到它被读取)。
http://technet.microsoft.com/en-us/library/ms166104%28v=sql.105%29.aspx
希望这可以帮助
链接服务器可能不是您尝试实施的模型的最佳解决方案,因为在链接服务器通信失败的情况下,您需要的弹性很难实现。
根本问题是,在链接服务器通信失败的情况下,数据库引擎会引发严重性为 20 的错误,这足以中止当前正在执行的批处理 - 绕过批处理中的任何错误处理代码(例如TRY...CATCH
)。
SQL 2005 及更高版本包括sp_testlinkedserver
在尝试执行命令之前测试链接服务器的可用性的过程 - 但是,这并不能解决由在命令期间遇到的通信错误造成的问题。
您可以考虑几个更强大的选项。一个是Service Broker,它提供了一个异步消息队列模型。这并不适合观察者模式,但激活功能提供了一种从中心点实现推送通知的方法。由于您提到消息传递,Service Broker 采用的对话模型可能适合您的目标。
另一种选择是事务复制;如果数据流纯粹是从中央服务器到观察者,这可能更合适。