将大表中的每一行放入 ssb 队列中

发布于 2024-10-04 06:13:23 字数 442 浏览 5 评论 0原文

我有一个包含 250 万行的表,每行有一列 xml 类型。当消息到达另一个队列(触发队列)时,所有记录都应被删除并排入 sqlserver 服务代理队列中。性能非常重要,但现在太慢了。实现这一目标的最佳方法是什么?

目前,我们在触发器队列上使用激活的 sp,它在 while(@message <> null) 循环中执行:

begin transaction
delete top (1) from table output @tempTable
select top 1 @message = message from @tempTable
send on conversation @message
commit transaction

是否有更快的方法来解决这个问题?

顺便说一句:在有人问之前:我们需要从表开始,因为它填充了先前计算的合并语句的输出

I have a table that contains 2.5 million rows, each row has one column of type xml. All records should be deleted and enqueued in a sqlserver service broker queue when a message arrives in another queue (triggerqueue). Performance is very important and now it's too slow. What would be the best way to achieve this?

currently we use an activated sp on the triggerqueue which does in a while(@message <> null) loop:

begin transaction
delete top (1) from table output @tempTable
select top 1 @message = message from @tempTable
send on conversation @message
commit transaction

are there faster ways to tackle this problem?

By the way: before someone asks: we need to start from the table, because it is filled with the output from an earlier calculated merge statement

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

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

发布评论

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

评论(1

浅忆 2024-10-11 06:13:23

所以你的性能问题是在发送端而不是接收端,对吧? (从你的问题来看有点不清楚)。在这种情况下,您需要从尝试开始:

  1. 在单个事务中批处理多个操作。您很可能在提交时受到同步日志刷新的影响最大。
  2. 尝试更有效地处理表(例如,一次选择更多行到临时表中,然后使用游标迭代它并发送消息)

如果您在接收端遇到问题,请查看此Remus 的精彩文章

So your performance problem is on the send side rather than receive side, right? (it's a bit unclear from your question). In this case, you'll want to start with trying:

  1. Batch many operations in a single transaction. You're most likely getting hit the most by synchronous log flushes at commit time.
  2. Try processing the table more efficiently (e.g. select more rows at once into the temp table and then use cursors to iterate over it and send messages)

In case you're experiencing problems on the receive side, take a look at this great article by Remus.

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