具有并发运行触发器的 SQL 事务复制

发布于 2024-10-14 19:58:45 字数 172 浏览 1 评论 0原文

我已设置 SQL Server 事务复制以连续运行两个表(父记录和子记录)。在订阅者端,我在两个复制表上都有插入和更新触发器。 这些触发器都具有相同的代码,用于查询复制表中的记录并修改订阅者数据库的其他表中的记录。

我的问题是..这些触发器会同时运行吗?我担心一个表中的触发器会中断另一个表中的触发器完成的处理工作

I have setup SQL Server transactional replication to run continuously for two tables (Parent and child records). At the subscriber end, I have insert and update triggers on both replicated tables.
These trigger all have the same code which queries the records in the replicated tables and modifies records in other tables of the subscriber db.

My question is..Will these triggers run concurrently? My fear is that a trigger in one table will interrupt the processing work done by the trigger in the other table

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦言归人 2024-10-21 19:58:45

触发器将在应用更新的复制代理的上下文中运行。代理使用可配置数量的连接

-SubscriptionStreams [0|1|2|...64]

每个分发代理允许的连接数
并行应用批量更改
给订阅者,同时保持
许多交易的
使用时出现的特征
单线程。对于 SQL Server
出版商,值范围从 1 到
支持 64。这个参数是
仅当发布者和
分发服务器在 SQL Server 上运行
2005 或更高版本。这个参数
不支持或必须为 0
非 SQL Server 订阅者或
点对点订阅。

由于事务语义由复制代理正确维护,因此如果您的更新具有正确的事务语义,那么它们不会在订阅者上发生冲突(因为它们在发布者上没有冲突)。如果确实如此,那么事务边界的设计存在问题,您需要通过返回绘图板并使用正确的事务语义设计应用程序来相应地解决。

The triggers will run in the context of the replication agent applying the updates. The agent uses a configurable number of connections:

-SubscriptionStreams [0|1|2|...64]

Is the number of connections allowed per Distribution Agent to
apply batches of changes in parallel
to a Subscriber, while maintaining
many of the transactional
characteristics present when using a
single thread. For a SQL Server
Publisher, a range of values from 1 to
64 is supported. This parameter is
only supported when the Publisher and
Distributor are running on SQL Server
2005 or later versions. This parameter
is not supported or must be 0 for
non-SQL Server Subscribers or
peer-to-peer subscriptions.

Since transaction semantics are properly maintained by the replication agent, if your updates have correct transaction semantics then they cannot conflict on the subscriber (since they did not conflict on the publisher). If they do, then is a problem with the design of your transaction boundaries and you need to solve accordingly, by going back to the drawing board and designing your application with correct transaction semantics.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文