SqlDependency Reliablity？

Question

我目前的情况是,我有一个应用程序需要在新数据到达数据库表时得到通知.数据来自外部源(我无法控制 - 这是唯一的集成选项).当新数据到达时,我的应用程序需要采取某些操作 - 基本上查询新数据,处理它,将结果插入本地表等.

我希望尽可能避免轮询,因为预计数据会实时处理.也就是说,确保没有数据丢失是第一优先级.

我的问题:

1. SqlDependency一般被认为是可靠的吗？
2. 我是否需要关注竞争条件,例如我在另一个到来时处理一个变化？
3. 数据库重启后会发生什么？我的应用程序是否会恢复并再次开始接收更改,或者我是否需要某种类型的故障安全计时器来定期重新订阅通知？
4. 我在该主题上阅读的大多数文章都涉及SQL Server 2005.我使用的是SQL Server 2008 R2.是否有一种比SqlDependency更受欢迎的新技术？
5. (编辑)此外,如果应用程序出现故障怎么办？我想我必须在启动时查询错过的数据？

Answer 1

1)是的,我认为它是可靠的,因为它正确地设计了目的(缓存失效)

2)否.这就是为什么你只能通过发出一个查询来订阅,这可以确保在获取数据和通知新的更新之间没有竞争

3)数据库(或实例)重新启动信号所有挂起的查询通知,其SqlNotificationInfo值为Restart.阅读SqlDependency如何基于查询通知以更好地理解.由于SqlDependency始终保持与数据库的开放连接,因此SqlDependency即使在任何显式查询通知之前也将检测到数据库不可用

4)不.更多关于此进一步下来......

5)没有"遗漏数据".查询通知(以及SqlDependency)从不通知您有哪些数据发生了变化.它只通知你它发生了变化.您总是应该返回并阅读所有数据以查看已更改的内容(我将您转回问题/答案2).新启动的应用程序尚未查询数据,因此没有任何更改需要通知.只有在首次查询数据后才能收到通知.

从你的问题的描述我不相信你需要查询通知.在我看来,即使您的应用程序没有运行,您也希望对任何更改采取行动,而不管它何时发生.这当然不是缓存失效,而是变更跟踪.因此,您需要部署更改跟踪技术,例如更改数据捕获或更改跟踪,这两种技术都是SQL Server 2008及更高版本(在SQL Server 2005中不可用).使用SQL Server 2005,部署触发器并为Service Broker排队消息以处理您尝试处理的同一问题(检测更改,对每行新数据做出反应)并不罕见.

Answer 2

从 .net 开发人员的角度来看，只是想将它用于缓存失效，这是一个真正的痛苦并且并不完全可靠。

设置和故障排除特别痛苦，我们让它在一种环境中正常工作，但在另一种环境中却无法正常工作。找出原因既困难又耗时。

即使它都在运行，它也不是完全可靠的。如果 SQL Server 负载过重并且存在重启和通知未恢复的已知问题，则它可以删除通知：http : //connect.microsoft.com/SQLServer/feedback/details/543921/sqldependency-incorrect-behaviour-after-sql -server-restarts。

如果有替代技术可以满足您的需求并且不那么麻烦，我会避免。