如何通知Windows服务(c#)的DB Table Change(sql 2005)?

前端之家收集整理的这篇文章主要介绍了如何通知Windows服务(c#)的DB Table Change(sql 2005)?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我在sql2005数据库中有一个负载较重的表(许多插入/更新/删除).我想尽可能接近实时地对所有这些更改进行一些后处理(异步地,以便不以任何方式锁定表).我看了很多可能的解决方案,但似乎找不到一个完美的解决方案.

这种后期处理也很重要,所以Windows监听器服务实际上会将处理过程传递给多台机器.然而,这部分应用程序已经开始运行,完全是异步的,而不是我需要的帮助 – 我只是想提及这一点,只是因为它影响了设计决策,因为我们不能仅仅加载一些CLR对象DB完成处理.

所以,简单的问题依然是:表中的数据更改,我想在远程服务器上的c#代码中进行一些处理.

目前我们已经提出使用一个sql触发器,它执行“xp_cmdshell”来唤醒一个exe,它引发了Windows服务正在侦听的事件.这只是感觉不好

然而,我在网上看过的其他解决方案也是相当复杂的.例如,设置sqlCacheDependency也需要设置Service broker.另一个可能的解决方案是使用CLR触发器,它可以调用Web服务,但是在线上有这么多警告,这是一个坏的方法,特别是在性能至关重要的时候.

理想情况下,我们不会依赖于表的更改,但宁可拦截我们的应用程序内的调用,并从那里通知服务,不幸的是,尽管我们有一些旧的应用程序也对数据进行了更改,并且监视该表是唯一的集中位置此时此刻.

任何帮助将不胜感激.

概要:

>需要实时响应表数据更改
性能至关重要
>预计交通量很大
>轮询和计划任务不是一个选项(或实时的)
>实施服务代理太大(但可能只是解决方案?)
> CLR代码还没有被排除,但是如果建议,需要执行
>侦听器/监视器可能是远程机器(可能是相同的phyisical网络)

您真的没有这么多方法来检测sql 2005中的更改.您已经列出了大多数.

查询通知.这是支持sqlDependency及其衍生产品的技术,您可以在The Mysterious Notification上阅读更多详细信息.但QN旨在使结果无效,而不是主动通知更改内容.你只会知道表有变化,不知道有什么改变.在繁忙的系统上,这将无法正常工作,因为这些通知将会持续不断.

日志阅读这是事务复制所使用的,是检测更改的最简单的方式.不幸的是仅适用于内部组件.即使您设法了解日志格式,问题是您需要引擎支持,将日志标记为“正在使用”,直到您读取它,否则可能会被覆盖.只有事务复制才能做这种特殊的标记.

数据比较.依靠时间戳列来检测更改.也是基于拉,相当凶猛,并有检测删除的问题.

应用层这是理论上的最佳选择,除非在应用范围之外的数据发生变化,在这种情况下,它会崩溃.实际上,在应用范围之外总会发生变化.

触发.最终,这是唯一可行的选择.基于触发器的所有更改机制的工作方式相同,它们将更改通知排队到监视队列的组件.

总是有一些建议,要做一个紧密耦合的同步通知(通过xp_cmdshell,xp_olecreate,CLR,通知WCF,你命名它),但所有这些方案在实践中都失败了,因为它们有根本的缺陷:
– 它们不考虑事务一致性和回滚
– 它们引入了可用性依赖关系(OLTP系统无法继续,除非通知的组件在线)
– 它们执行得非常可怕,因为每个DML操作必须等待某种形式的RPC调用才能完成

如果触发器实际上并没有主动通知侦听器,而只是排队通知,则在监视通知队列时出现问题(当我说’queue’时,我的意思是任何充当队列的表).监视意味着拉入队列中的新条目,这意味着将检查的频率与更改的负载进行正确平衡,并对加载尖峰进行响应.这根本不是微不足道的,实际上是非常困难的.但是,在sql服务器中有一个语句具有阻止的语义,而不会拖动,直到更改可用:WAITFOR(RECEIVE).这意味着Service Broker.你在你的帖子中多次提到SSB,但是你是正确的,因为很大的未知数,所以害怕部署它.但现实情况是,到目前为止,你最适合你所描述的任务.

您不必部署完整的SSB架构,其中通知一直传递到远程服务(即使是Express Express也需要远程sql实例).您需要同谋的所有方法是从通知发送之时(提交更改后)解除变化检测到的时刻(DML触发).为此,您需要的是本地SSB队列和服务.在触发器中,您可以将SEND更改通知给本地服务.在原始DML事务提交之后,服务过程activates并使用CLR传递通知.您可以在Asynchronous T-SQL看到类似于此的示例.

如果您沿着这条路径走下坡路,那么您需要学习实现高吞吐量的一些技巧,并且您不得不在SSB中排序发送消息的概念.我推荐你阅读这些链接

> Reusing Conversations
> Writing Service Broker Procedures
> SQL Connections 2007 Demo

关于检测变更的手段,sql 2008显然增加了新的选择:Change Data Capture and Change Tracking.我强调“显然”,因为它们不是真正的新技术. CDC使用日志读取器,并且基于现有的事务复制机制. CT使用触发器,与现有的合并复制机制非常相似.它们都适用于需要同步的偶尔连接的系统,因此不适合实时更改通知.他们可以填充更改表,但是您将留下任务来监视这些表的更改,这些更改完全来自您所在的位置.

猜你在找的Windows相关文章