Questions tagged «service-broker»

1
服务代理已备份，现在可以接收，但似乎没有处理
此问题是从Stack Overflow 迁移而来的，因为可以在Database Administrators Stack Exchange上回答。 迁移 4年前。 事件通知有问题。在将消息发送到的机器/驱动器/数据库上（接收者），当没有人看时，驱动器已装满，因此已被整天备份。 现在我们已经释放了驱动器上的空间，它正在接受消息到队列中，但是它似乎没有在处理它们-没有插入新记录，即使队列现在有2200万条消息并且正在增长（！）。队列已启用： is_activation_enabled = 1 is_receive_enabled = 1 is_enqueue_enabled = 1 我在中看到了激活的SP activation_procedure，但是当我查看时SP_WHOISACTIVE，看不到任何活动的阅读器。 在我再次烧毁驱动器之前-我在做什么错？如何获取它来处理或刷新消息？提前致谢。 更新资料 一个想法-自从有了以来is_enqueue_enabled，也许它可以存储所有消息，直到可以处理所有消息为止？如果是这样，我可以安全地关闭它吗？ CREATE PROCEDURE [dbo].[Parse_EN_Messages] AS --mdb 2012/09/05 version 1.2 -- With apologies and thanks to Remus Rusanu, Jonathon Kehayias, Mladen Prajdic, and Jasper Smith for writing -- …
1
Sch-M WAIT阻止SQL Server 2014中的Sch-S，但不阻止SQL Server 2008 R2？
最近，我们将生产实例从SQL 2008 R2迁移到了全新的SQL 2014服务器。我们通过使用Service Broker发现了一个有趣的场景。考虑Broker Enabled = true带有MyService和的数据库MyQueue。在此队列上禁用了毒药消息处理。队列中至少有2条活动会话与消息。 在一个进程（SPID 100）中执行： BEGIN TRANSACTION; DECLARE @conversation_group_id UNIQUEIDENTIFIER; RECEIVE TOP (1) @conversation_group_id = conversation_handle FROM MyQueue; 请注意，我们保持交易未结。想象这是一个.NET程序，它在某些外部资源上等待了很长时间。通过sys.dm_tran_locks我们看到，此SPID已被授予队列上的IX锁。 | type | resource_id | mode | status | spid | | OBJECT | 277576027 | IX | GRANT | 100 | 在一个单独的进程（SPID 101）中执行五次： BEGIN TRANSACTION; …
1
SQL Server缓存刷新和磁盘I / O
我们正在忙于负载测试我们在.NET 4.0中开发的OLTP系统，并在后面运行SQL Server 2008 R2。该系统使用性能非常出色的SQL Server Service Broker队列，但是在处理过程中我们遇到了一种特殊的趋势。 SQL Server处理请求的速度为1分钟，然后增加磁盘写入活动的时间约20秒。下图说明了该问题。 Yellow = Transactions per second Blue = Total CPU usage Red = Sqlsrv Disk Write Bytes/s Green = Sqlsrv Disk Read Bytes/s 在故障排除期间，我们尝试了以下操作，但模式没有任何重大变化： 停止SQL Server代理。 几乎杀死了所有其他正在运行的进程（没有A / V，SSMS，VS，Windows资源管理器等） 删除了所有其他数据库。 禁用所有对话计时器（我们不使用任何触发器）。 从消息队列驱动的方法转移到简单/粗略的表监视设计。 从轻到重使用了不同的负载。 修复了所有死锁。 似乎SQL Server可能正在建立其缓存并以特定的基于时间的时间间隔将其写入磁盘，但是我找不到任何在线资源来支持该理论。 接下来，我计划将解决方案移至我们专用的测试环境，以查看是否可以重现问题。在此期间的任何帮助将不胜感激。 Update 1 根据要求，提供一个图形，其中包括Checkpoint Pages …
3
从插入触发器启动python脚本
我们有一段不错的python，它可以发送一些电子邮件并与云系统进行交互。工作良好。但是我们必须每隔几分钟触发一次以轮询数据库。出于业务目的，我们确实需要实时启动python脚本，因此没有轮询延迟。（这为与客户通电话的销售人员提供服务。） 我们真的不希望有1分钟的轮询循环。或30秒。我们希望该记录显示在数据库中，并让事情立即发生。 快速实现此目标的快速方法是在将特定记录类型插入表中时触发它。 我们可以从触发器中触发python脚本吗？ 根据下面的Aaron注释，我们知道这是Very Bad Thing™，但是此表的使用很少（每天插入0-12次）。轮询表无法满足我们的业务需求（我们需要.py立即运行-它做的不仅仅是发送电子邮件）。 我们认为，满足业务需求的一种方法是在SQL Server上设置python的.net版本，然后让T-SQL以调用C＃的方式调用python脚本... 但是我们不知道如何实际做到这一点！（请问这个问题）。 文档/详细信息？ 我问了有关堆栈溢出的后续问题：如何在SQL Server中创建Python CLR过程？ 问题下的问题：您有一块python。您希望它从SQL触发器中触发，但是您知道这是一件很糟糕的事情。那么，如何在不使用python代码的情况下真正实现相同的效果的SQL操作呢？ 解决此需求的非触发，非轮询方法是什么？ （相同的效果=“在表中发生插入/更新/删除，并且在db事件发生后2秒内触发了python脚本，而没有轮询表”）
1
服务经纪人-对话寿命？
我们正在努力使Service Broker在我们的环境中工作，以解决业务案例。我不知道消息标题是否是一个好标题，但是我的问题在下面。但这可能不是一个好问题，所以在那之后我们要做的就是为什么我认为这是正确的问题。 在结束对话之前，应在对话中发送多少条消息？ 我们要使用Service Broker来异步更新结果表。结果表平坦且快速。我们在基表上具有触发器，该触发器发送带有其表和主键的消息。我们有三个队列： 低延迟-目标是处理15秒。它处理与特定项目有关的更改项目。 批量队列-目标是5分钟的处理时间。它处理何时会影响数百（或数千）个项目的更改。它列出了受影响的项目列表，并将其馈入“延迟的低延迟队列” 延迟的低延迟-目标是30分钟才能处理。这仅处理批量队列中的项目。 基本上，如果客户的信息更新；这会影响许多产品，因此将其发送到批量队列以减慢处理速度。但是，如果产品得到更新，则将其发送到低延迟队列。 我们重用类似于Remus Rusanu的博客http://rusanu.com/2007/04/25/reusing-conversations/的对话，不同之处在于我们是基于主键的模数来进行对话的。这具有辅助主键重复数据删除的附带好处。 因此，我们正在重新使用对话并且在我们的准则之内。通过两个线程，我能够每秒刻录125条消息（人为丢弃几千条消息），这远远超过了保持生产的速度（每秒15条消息）。 但是，我们遇到的问题是，经过一段时间，大约4个小时或120K消息，我们开始在sysdesend和队列表上看到块和高争用。锁是LCK_M_U，是KEY锁。有时，宏块解析为sysdesend，有时解析为特定的队列表（queue_）。 我们已经制定了一个流程，该流程将在闲置24小时或30分钟后结束对话，因此我们可以增加循环讨论之前的时间。 我们正在使用SQL 2016 Enterprise（13.0.4001.0） 触发触发（发送低延迟或批量发送） 查找或创建对话句柄。 发信息 队列激活过程 更新结果表 清理过程每10分钟运行一次，以查看是否有空闲的对话。如果连续超过三遍发现它们，则将其标记为无效并结束对话。 请让我知道是否还有其他可能有益的细节。我在Service Broker方面没有太多经验，所以我不知道我们的消息/秒是低，高还是无动于衷。 更新 因此，我们今天再次尝试，并遇到了相同的问题。我们将对话寿命更改为2小时，但没有任何效果。因此，我们实施了150招；有同样的问题。 大量等待SEND CONVERSATION，等待sysdesend。有人还有其他想法吗？ 更新2 今天我们进行了更长的测试，并且在17分钟的采样期间之一中，我们在4个会话句柄上处理了41K条消息。当sysdesend上的锁和队列表变得过多，并且在停止它之前我们开始向后漂移时，我们能够保持到最后。我们似乎在处理消息方面没有问题，没有任何东西进入队列，我们​​可以将其拉出并以至少5倍的速度处理它们。基于添加消息，我们的速度似乎受到限制。 在以后的测试中，我们删除了占消息总数80％的触发器之一。即使负载大大减少，我们也开始看到相同的等待。 更新3 谢谢Remus的建议（也感谢您发布有关该主题的出色博客文章，它们对于达到这一点很有帮助）。 我们今天再次运行它，并且表现更好（因为在等待之前，我们走了更长的时间，甚至在我们瘫痪之前走了更长的时间）。所以，细节。 我们更改了：*将每个线程的可维护会话数从1：1增加到2：1。基本上，我们有4个线程的8个会话句柄。 合并大容量队列（因为一条传入消息可能意味着数百条传出消息），从而合并为更少，更大的消息。 关于此尝试的注意事项： 禁用目标队列激活过程。阻塞没有变化（我们等待了5分钟），消息确实发送到了sys.transmission_queues。 监视sys.conversation_endpoints。这个数字从0很快就达到了13K，然后全天缓慢上升，直到大约5小时后才达到25K。直到达到16K +/-才开始阻塞 我进入DAC并为队列运行DBREINDEX命令，尽管通过查询，幻象记录在进行清理并将计数降至0之前从未超过200左右。 当我结束测试时，sysdesend和sysdercv的计数相同，为24,932。 我们在5个小时内处理了约310K条消息。 我们走了很长时间，事情才崩溃了，我真的以为这次可以做到。明天我们将尝试强制消息通过网络。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.