从SQL服务器生成事件

Question

我正在寻找一种最佳实践或示例，说明如何能够为给定的SQL Server 2008 R2数据库上的所有更新事件生成事件。为了更具描述性，我正在开发一个POC，我将本质上将更新事件发布到一个队列（本例中为RabbitMq），然后可以由各种消费者使用。这将是通过事件采购实现CQRS只查询数据模型的第一部分。通过放置任何人都可以订阅这些事件以便复制到任意数量的仅限查询的数据模型中。这部分清晰明确。我遇到的问题是确定从SQL服务器生成事件的最佳方法。我已经给出了一些想法，比如监视事务日志和SSIS。但是，我不完全确定这些选项是否可以提供建议或者甚至是可行的。

有没有人对这类事情有过任何经验，或者对如何去探索这样的冒险有任何想法？任何帮助或指导将不胜感激。

Answer 1

不能监控日志，因为即使如果你就可以了解它，你有日志的问题被回收你有机会读它之前。除非日志以某种方式被标记为不被截断，否则将被重用。例如，启用事务复制时，日志将被锁定，直到被复制代理读取，并且只有，然后被截断。

SSIS是一个非常广泛的概念，并且说'使用SSIS来检测变化'类似于说'我将使用编程语言来解决我的问题'。详细信息是如何使用SSIS？无论是否使用SSIS，都无法可靠地检测任意模式上的数据更改。即使是专门设计用于检测更改的数据模型也存在问题，特别是在检测删除时。

但是，有可行的替代方案。您可以部署Change Data Capture并委派给引擎本身来跟踪更改。消费这些检测到的变化并将它们发布给消费者（通过RabbitMQ，如果这是你的想象）是 SSIS将擅长的东西。但是你必须明白，SSIS对于连续性，实时任务来说并不好。它的设计是为了批量定期运行，所以当SSIS作业运行时，您的更改通知消费者将会收到高峰通知，并且延迟很长（分钟）。

对于实时方法，更好的解决方案是Service Broker。一种可能性是SEND来自触发器的Service Broker消息，但我不会推荐它。一个更好的设计是让应用程序自己发布SEND的更改 - 在进行数据修改时明确地显示消息。对于其他SQL Server使用者（包括SQL Server Express），使用SQL Server 2012可能为multicast Service Broker messages。 SSB消息传递完全是事务性的（如果事务回滚，则不发送消息），并且不需要与消息存储资源管理器一起进行两阶段提交。但要通过RabbitMQ进行广播，您需要桥接通信，即。 RECEIVE SSB消息并将它们转换为RabbitMQ通知。